La Gestiã N Integral de Proyectos

LA GESTIN INTEGRAL
DE PROYECTOS
ALBERTO SOLS RODRGUEZ-CANDELA,

ISABEL FERNNDEZ FERNNDEZ y JAVIER ROMERO YACOBI (Eds.)
LA GESTIN INTEGRAL
DE PROYECTOS
2013
Servicio de Biblioteca. Universidad Pontificia Comillas de Madrid

La GESTIN integral de proyectos / Alberto Sols Rodrguez-Candela, Isabel Fernndez
Fernndez y Javier Romero Yacobi (eds.). -- Madrid : Universidad Pontificia Comillas,
2013
452 p. -- (Biblioteca Comillas)
Bibliografa
D.L. M 27401-2013. -- ISBN 978-84-8468-495-4
1. Gestin de proyectos 2. Comunicacin empresarial 3. Liderazgo 4. Aspectos ticos
5. Aspectos econmicos I. Sols Rodrguez-Candela, Alberto II. Fernndez Fernndez,
Isabel III. Romero Yacobi, Javier
Esta editorial es miembro de la Unin de Editoriales Universitarias Espaolas (UNE), lo que

garantiza la difusin y comercializacin de sus publicaciones a nivel nacional e internacional.
2013 De todos los autores

2013 Universidad Ponticia Comillas
Universidad Comillas, 3
28049 Madrid
Diseo de cubierta: Beln Recio Godoy
ISBN: 978-84-8468-495-4
Depsito legal: M - 27401 - 2013
Maquetacin e impresin: Imprenta Kadmos, S.C.L.
Reservados todos los derechos. Queda totalmente prohibida la reproduccin total o

parcial de este libro por cualquier procedimiento electrnico o mecnico, incluyendo
fotocopia, grabacin magntica o cualquier sistema de almacenamiento o recuperacin
de la informacin, sin permiso escrito de la UNIVERSIDAD PONTIFICIA DE COMILLAS.
ndice
PRESENTACIN, Manuel Moreu Munaiz ..........................................................
15
PRLOGO, Alberto Sols, Isabel Fernndez y Javier Romero ..........................
17
CAPTULO 1. INTRODUCCIN A LA GESTIN INTEGRAL DE PROYECTOS,

Alberto Sols Rodrguez-Candela .........................................................................
21
1.
2.
3.
4.
5.
6.
7.
21
26
27
31
33
35
38
Introduccin....................................................................................................
La evolucin de la gestin de proyectos ......................................................
La gestin integral de proyectos ...................................................................
La visin de conjunto.....................................................................................
El gestor o jefe de proyectos.........................................................................
Sntesis del contenido del libro .....................................................................
Referencias ......................................................................................................
CAPTULO 2. EL ALCANCE DEL PROYECTO, Juan Jos Burgaz Fernndez ............
39
1.
2.
3.
4.
39
40
42
44
44
45
47
50
53
57
Introduccin....................................................................................................
Ciclos de vida de proyecto y de sistema ......................................................
Definicin del alcance de un proyecto ........................................................
Determinacin del alcance de un proyecto .................................................
4.1. La necesidad.............................................................................................
4.2. Los grupos de inters o stakeholders..................................................
4.3. Los requisitos ...........................................................................................
5. Contenido del alcance del proyecto .............................................................
6. Descomposicin estructurada de tareas (WBS) del proyecto.....................
7. Control y seguimiento del alcance................................................................
NDICE
8. Verificacin del alcance del proyecto ...........................................................

9. Referencias ......................................................................................................
57
58
CAPTULO 3. TCNICAS DE PLANIFICACIN DE PROYECTOS, Alberto Sols

Rodrguez-Candela y Adriana Molero Alonso...............................................................
59
1. Introduccin....................................................................................................
2. Tcnicas de planificacin de proyectos ........................................................
2.1. Diagramas de Gantt .................................................................................
2.2. Program Evaluation and Review Technique (PERT) .............................
2.3. Critical Path Method (CPM) ....................................................................
3. Gestin de riesgos ..........................................................................................
3.1. Concepto de riesgo..................................................................................
3.2. Origen y tipo de riesgos .........................................................................
3.3. Proceso de gestin de riesgos ................................................................
3.4. Planificacin de la gestin de riesgos ....................................................
3.5. Identificacin de riesgos .........................................................................
3.6. Evaluacin ................................................................................................
3.7. Valorizacin y priorizacin .....................................................................
3.8. Estrategias de mitigacin .........................................................................
3.9. Seguimiento de gestin de riesgos .........................................................
4. Referencias ......................................................................................................
59
60
64
65
73
77
78
79
80
81
82
84
87
87
89
89
CAPTULO 4. TICA PROFESIONAL, Miguel Yaguez Prez .....................................
91
1. Marco terico ..................................................................................................

1.1. La tica. Concepto ...................................................................................
2. La tica y la empresa .....................................................................................
2.1. Razones para una tica empresarial .......................................................
2.2. El administrador y la tica ......................................................................
2.3. La tica de la empresa en el mercado ...................................................
2.4. La organizacin en relacin con los poderes pblicos y la tica ........
2.5. El modelo de gestin orientado a la persona y la tica .......................
3. Responsabilidad social corporativa ...............................................................
3.1. De la tica empresarial a la responsabilidad social corporativa ..........
4. La empresa familiarmente responsable .........................................................
4.1. Flexibilidad ...............................................................................................
4.2. Servicios a los empleados .......................................................................
4.3. Adaptacin del puesto de trabajo y apoyo profesional ........................
4.4. Beneficios extra-salariales .......................................................................
5. Referencias ......................................................................................................
91
91
96
98
99
101
102
102
103
103
105
107
107
108
108
109
CAPTULO 5. RELACIN CON LOS PROVEEDORES Y GESTIN DE

SUBCONTRATACIONES, Jess Morcillo Bellido y Miguel Yaguez Prez ...............
111
1. Introduccin....................................................................................................
2. La cadena de suministro ................................................................................
111
112
NDICE
3.
4.
5.
6.
7.
8.
2.1. Qu es la cadena de suministro? De la mejora de los flujos a la

visin de procesos ...................................................................................
2.2. Estructura de la cadena de suministro ...................................................
La coordinacin en la cadena de suministro ...............................................
Herramientas para mejorar la gestin de la cadena de suministro. La
integracin con clientes y proveedores ......................................................
Modelos de colaboracin entre los miembros de la cadena; las alianzas .
Construyendo cadenas de suministro a prueba de crisis ............................
6.1. Los riesgos en las cadenas de suministro ..............................................
6.2. Categorizacin de los riesgos en las cadenas de suministro ................
La subcontracin ............................................................................................
7.1. El porqu de la subcontratacin ............................................................
7.2. Marco legal de la subcontratacin en Espaa .......................................
7.3. Responsabilidades salariales y con respecto a la Seguridad Social .....
7.4. Responsabilidades tributarias ..................................................................
7.5. Responsabilidades en materia de Prevencin de Riesgos Laborales ...
7.6. Responsabilidades penales ......................................................................
7.7. La subcontratacin en el sector de la construccin ..............................
7.8. Resumen de responsabilidades derivadas de la subcontratacin.........
Referencias ......................................................................................................
CAPTULO 6. GESTIN FINANCIERA, Isabel Fernndez Fernndez y Alberto

Manrique Navas ...................................................................................................
1. Introduccin....................................................................................................
2. Contenido y estructura de la oferta econmica de un proyecto ................
2.1. La descomposicin estructurada de los costes, CBS .............................
2.2. La estimacin de los ingresos .................................................................
2.3. La elaboracin de la oferta econmica ..................................................
3. El flujo de caja del proyecto y el valor temporal del dinero ......................
3.1. El flujo de caja .........................................................................................
3.2. El descuento y la capitalizacin .............................................................
4. El control econmico del proyecto...............................................................
4.1. El anlisis o gestin del Valor Ganado ..................................................
4.2. Los informes de progreso .......................................................................
4.3. El ciclo de control del PERT/COSTE ......................................................
5. Mtodos de anlisis de la rentabilidad de proyectos ..................................
5.1. Mtodos que no utilizan la actualizacin de los flujos de caja:
mtodo de periodo de recuperacin del capital (PAY-BACK).............
5.2. Mtodos que tienen en cuenta el valor del dinero en el tiempo:
criterio del Valor Actual Neto (VAN) .....................................................
5.3. Criterio de la tasa interna de retorno (TIR) ...........................................
5.4. Relacin entre el TIR y el VAN ..............................................................
6. Tasa de descuento a utilizar-coste de capital (Ke) ......................................
7. Fuentes de financiacin de los proyectos ....................................................
7.1. Descripcin de las diferentes fuentes de financiacin..........................
112
114
117
119
120
122
123
123
124
124
126
128
128
128
130
131
131
133
135
135
137
137
140
140
141
141
143
144
144
149
149
151
151
153
154
156
157
159
159
NDICE
7.2. Fuentes de financiacin de capital .........................................................

7.3. Fuentes de financiacin no de capital ...................................................
7.4. Fuentes de financiacin pblica .............................................................
8. Anlisis del nivel de deuda del proyecto .....................................................
9. Referencias ......................................................................................................
CAPTULO 7. FINANCIACIN DE PROYECTOS, Alberto Manrique Navas e igo
Velzquez Prado ..................................................................................................
1. Introduccin....................................................................................................
2. Gestin de los recursos financieros del proyecto: caractersticas de la
financiacin externa .......................................................................................
2.1. Project finance: definicin y caractersticas ...........................................
2.2. Project finance y financiacin corporativa .............................................
3. Anlisis de los riesgos del proyecto..............................................................
3.1. Riesgo de construccin ...........................................................................
3.2. Riesgo administrativo y medio ambiental ..............................................
3.3. Riesgo de operacin y mantenimiento ..................................................
3.4. Riesgo regulatorio ....................................................................................
3.5. Riesgo comercial ......................................................................................
3.6. Riesgo de contraparte ..............................................................................
3.7. Riesgos econmico-financieros: inflacin, tipos de inters, tipos
de cambio.................................................................................................
3.8. Riesgo de fuerza mayor...........................................................................
4. Criterios para determinar la financiabilidad del proyecto..................................
4.1. Criterios econmicos ...............................................................................
4.2. Otros criterios...........................................................................................
5. Entidades intervinientes en la financiacin de un proyecto .......................
5.1. Patrocinador .............................................................................................
5.2. Financiadores ...........................................................................................
5.3. Asesores ....................................................................................................
6. Estructuras tpicas de financiacin ................................................................
6.1. Financiacin bancaria ..............................................................................
6.2. Financiacin en mercados de capitales: bonos y titulizaciones ...........
7. Elementos tpicos de la financiacin externa: garantas y ratios de
control del proyecto .......................................................................................
7.1. Garantas...................................................................................................
7.2. Ratios de control del proyecto ...............................................................
8. Gestin de la financiacin de proyectos ......................................................
8.1. Preparacin de la financiacin ...............................................................
8.2. Peticin de ofertas de financiacin. El Term Sheet...............................
8.3. Mandato de financiacin .........................................................................
8.4. Due diligence, fase de documentacin y cierre financiero ...............
8.5. Gestin financiera en la fase de explotacin ........................................
10
159
159
162
162
163
165
165
166
166
167
168
168
169
170
170
171
171
171
172
174
174
175
176
176
177
181
183
183
185
186
186
187
189
190
192
192
192
193
NDICE
CAPTULO 8. SEGUIMIENTO DE PROYECTOS Y CUADRO DE MANDO INTEGRAL,

Marian Lerga Revuelta, Jos Ponce Lucas y Juan Torres Vzquez ...................
1.
2.
3.
4.
Introduccin....................................................................................................
Objetivos del seguimiento de proyectos ......................................................
Seguimiento de proyectos y estrategia .........................................................
Comisiones de seguimiento ...........................................................................
4.1. Tipos de comisiones ................................................................................
4.2. Funciones de las comisiones de seguimiento .......................................
4.3. Integrantes de las comisiones de seguimiento ......................................
5. El Cuadro de Mando Integral ........................................................................
5.1. Las perspectivas del Cuadro de Mando Integral ...................................
5.2. Los indicadores ........................................................................................
5.3. Elaboracin de un Cuadro de Mando Integral ......................................
6. Informes ..........................................................................................................
6.1. Caractersticas y clasificacin de los informes .......................................
6.2. Realizacin de un informe ......................................................................
6.3. El informe de seguimiento ......................................................................
7. Referencias ......................................................................................................
195
195
195
198
202
202
203
204
205
207
209
211
213
214
215
217
220
CAPTULO 9. TCNICAS DE NEGOCIACIN, Vernica Blanco-Traba HernndezCaizares ..............................................................................................................
221
1. Introduccin....................................................................................................
2. Negociacin ....................................................................................................
2.1. Mtodo de negociacin ...........................................................................
2.2. Competencias bsicas de la negociacin ...............................................
2.3. Negociacin y audiencias........................................................................
2.4. Liderazgo, aspectos ticos y cuestin de gnero ..................................
3. Resolucin de conflictos ................................................................................
3.1. Modelo de conflicto.................................................................................
3.2. Estrategias, tcnicas y formas de resolucin de conflictos ...................
3.3. Medios alternativos de resolucin de conflictos....................................
4. Referencias ......................................................................................................
221
222
222
230
231
232
233
234
235
238
239
CAPTULO 10. DIRECCIN Y GESTIN DE EQUIPOS DE TRABAJO, scar Gonzlez

Martnez ...............................................................................................................
241
1. Introduccin....................................................................................................
2. Revisin histrica............................................................................................
3. El factor humano ............................................................................................
3.1. Inteligencia emocional ............................................................................
3.2. Aspiraciones del ser humano en el trabajo ...........................................
3.3. Aptitudes y roles del ser humano ante el trabajo .................................
3.4. tica ..........................................................................................................
4. Habilidades y tcnicas de gestin y direccin de equipos .........................
5. Las cualidades de un buen director ..............................................................
241
243
248
248
250
251
252
253
256
11
NDICE
6. Resumen..........................................................................................................
7. Referencias ......................................................................................................
258
259
CAPTULO 11. LIDERAZGO Y COMUNICACIN, Alejandro Salado Dez .................
261
1.
2.
3.
4.
Introduccin....................................................................................................
Bases del liderazgo y liderazgo en el proyecto ...........................................
Trada objetivo-equipo-lder ..........................................................................
Cmo liderar ...................................................................................................
4.1. Las necesidades del individuo en el trabajo ..........................................
4.2. Los tipos de personalidad .......................................................................
4.3. Las cualidades del lder ...........................................................................
5. Generacin y gestin de la confianza ..........................................................
6. Influencia y persuasin ..................................................................................
7. Comunicacin en el proyecto y en el equipo .............................................
7.1. Los elementos bsicos de la comunicacin ...........................................
8. Dimensiones de la comunicacin: direccin y formalidad .........................
9. Uso efectivo de los canales de comunicacin .............................................
9.1. Los canales de comunicacin .................................................................
9.2. El plan de comunicacin ........................................................................
10. Gestin de la comunicacin externa ...........................................................
11. Referencias.....................................................................................................
261
262
265
267
269
270
273
274
275
276
276
279
282
282
284
285
286
CAPTULO 12. SISTEMAS DE CLASIFICACIN DE PROYECTOS, Alberto Sols

Rodrguez-Candela ..............................................................................................
289
1. Introduccin....................................................................................................
2. Clasificacin de proyectos segn la naturaleza y el objeto del proyecto ..
3. Clasificacin de proyectos segn el modelo NTCP .....................................
3.1. Sistemas NTCP de clasificacin de proyectos ........................................
4. Implicaciones de la clasificacin de proyectos segn el modelo NTCP ....
4.1. Novedad ...................................................................................................
4.2. Tecnologa ................................................................................................
4.3. Complejidad .............................................................................................
4.4. Ritmo ........................................................................................................
5. Referencias ......................................................................................................
289
290
292
292
295
295
299
303
307
312
CAPTULO 13. GESTIN DE CAMBIOS Y CONTROL DE LA CONFIGURACIN,

Jos Manuel Muoz Palos ...................................................................................
313
1.
2.
3.
4.
5.
Introduccin....................................................................................................
Definicin de gestin de la configuracin ...................................................
Ciclo de vida y lneas-base ............................................................................
La gestin de la configuracin en el marco de la gestin de proyectos ...
Procesos de la gestin de la configuracin ..................................................
5.1. Planificacin y gestin de la configuracin ...........................................
5.2. Identificacin de la configuracin ..........................................................
5.3. Control de la configuracin ....................................................................
12
313
315
318
324
325
325
327
332
NDICE
5.4. Registro de la configuracin ...................................................................

5.5. Verificacin y auditoras de la configuracin ........................................
6. Referencias ......................................................................................................
334
336
337
CAPTULO 14. RECUPERACIN DE PROYECTOS, Enrique Rodrguez Segura..........
339
1. Introduccin....................................................................................................
2. Qu es un proyecto en dificultades ..............................................................
2.1. Cuntos proyectos fallan realmente? .....................................................
2.2. Proyectos de riesgo .................................................................................
2.3. Cundo se detecta un proyecto en dificultades? ..................................
2.4. Por qu se ignoran las seales de alarma? ...........................................
2.5. Sntomas ...................................................................................................
2.6. Causas .......................................................................................................
2.7. Seales de la crisis a travs de la medicin: mtricas ..........................
2.8. Proyectos imposibles, cuando los objetivos superan el 50% de un
proyecto normal.......................................................................................
3. Recuperacin ..................................................................................................
3.1. Opciones y plan de recuperacin ..........................................................
3.2. Guas operativas de recuperacin ..........................................................
4. Recuperacin de proyectos imposibles ........................................................
5. Casos reales ....................................................................................................
5.1. Programa A400M de AIRBUS ..................................................................
5.2. Buque Ferry de pasajeros y camiones para las Islas Feroe (Dinamarca)
de IZAR ....................................................................................................
6. Referencias ......................................................................................................
339
340
340
340
341
341
342
345
345
365
367
CAPTULO 15. PROYECTOS INTERNACIONALES, Alejandro Molns de la Fuente ...
369
1. Introduccin....................................................................................................
2. Elementos clave en la internacionalizacin ..................................................
2.1. Entorno poltico .......................................................................................
2.2. Entorno cultural .......................................................................................
2.3. Entorno legal y geogrfico ......................................................................
3. La negociacion internacional .........................................................................
3.1. Elementos culturales en la negociacin internacional ..........................
3.2. Factores de xito en la negociacin internacional ................................
4. Contrato internacional ....................................................................................
4.1. La importancia del contrato en el mbito internacional .......................
4.2. Los principales riesgos jurdicos derivados de un proyecto
internacional .............................................................................................
4.3. El arbitraje internacional..........................................................................
5. Anlisis de los riesgos en los proyectos internacionales .............................
6. Los recursos humanos en la internacionalizacion........................................
7. Referencias ......................................................................................................
369
370
371
371
375
376
377
378
379
380
13
348
349
349
351
362
364
364
380
381
382
384
386
NDICE
CAPTULO 16. PROYECTOS MULTINACIONALES, Aurora del Castillo Pinela ...........
387
1. Introduccin....................................................................................................
2. Programas de desarrollo multinacional.........................................................
3. Modelos de organizacin de programas multinacionales ...........................
3.1. Empresas multinacionales .......................................................................
3.2. Consorcios multinacionales .....................................................................
3.3. Responsabilidades del consorcio empresarial .......................................
3.4. Subcontratacin/outsourcing ................................................................
3.5. Programas de compensaciones industriales (OFFSET) .........................
4. La gestin de equipos multinacionales .........................................................
4.1. Los equipos globales ...............................................................................
387
388
389
389
394
395
399
402
404
404
CAPTULO 17. CIERRE Y EVALUACIN DE PROYECTOS, Miguel ngel Hernndez

Lpez, Isabel Fernndez Fernndez y Alberto Sols Rodrguez-Candela ..........
409
1. Introduccin....................................................................................................
2. Cierre y evaluacin del proyecto ..................................................................
2.1. Pruebas de aceptacin y acta de recepcin ..........................................
2.2. Facturacin final del proyecto ................................................................
2.3. Anlisis de rentabilidad final del proyecto ............................................
2.4. Informacin econmica de cierre ...........................................................
2.5. Indicadores de la evaluacin del proyecto ............................................
2.6. Personal, lecciones aprendidas y gestin del conocimiento ................
3. Referencias ......................................................................................................
409
410
411
412
414
415
417
421
423
CAPTULO 18. APOYO AL CICLO DE VIDA, Javier Romero Yacobi.........................
425
1. Introduccin....................................................................................................
2. Importancia y ventajas estrategicas de los proyectos de ACV ....................
3. Elementos de un proyecto de ACV...............................................................
3.1. Aspectos clave en los servicios/actividades de ACV .............................
3.2. Recursos ...................................................................................................
3.3. Cooperaciones con socios.......................................................................
4. Tipos de contratacin ....................................................................................
4.1. Basado en costes .....................................................................................
4.2. Contratar resultados .................................................................................
4.3. Contratar capacidades .............................................................................
5. Referencias ......................................................................................................
425
426
428
430
435
436
437
438
440
443
444
BIBLIOGRAFA ....................................................................................................
445
NDICE TEMTICO .............................................................................................
449
14
PRESENTACIN
Manuel Moreu Munaiz
Presidente del Instituto de la Ingeniera de Espaa
Presentar este libro de gestin integral de proyectos es un gran placer

cuando se cree tan firmemente en esa importante y necesaria disciplina
profesional y cuando se contempla una obra tan completa y rigurosa como
la que aqu se trata. Adems en Espaa tenemos un espritu tan improvisador que necesitamos la formacin y las herramientas que nos ayuden a
seguir procesos rigurosos que lleven al xito los cada vez ms complejos y
exigentes proyectos.
Es una suerte para m poder escribir estas lneas de presentacin de este
magnifico trabajo construido por profesionales con amplia experiencia en
este campo. El libro esta redactado por varios autores que cubren diferentes
mbitos y disciplinas, sin embargo la excelente labor de coordinacin de
los editores (tres de los autores del libro) le dotan de un hilo conductor que
dan continuidad y equilibrio al texto. Es precisamente el enfoque sistmico
lo que hace diferente a este libro, cubriendo de esta forma un importante
hueco en la literatura sobre esta materia. Los lectores interesados en adquirir conceptos mas tradicionales de la gestin de proyectos pueden adquirirlos de una gran cantidad de buenos libros sobre todo en ingls, pero muy
pocos en castellano y desde luego ninguno con un enfoque y unos contenidos tan amplios como ste. Actualmente los profesionales de la gestin
de proyectos se desenvuelven en un entorno de incertidumbre, cambiante
y globalizado. Los proyectos se han deslocalizado e internacionalizado. Los
gestores de proyectos no pueden basarse solamente en las clsicas herramientas de gestin para alcanzar el xito sino que tienen que saber liderar
equipos, gestionar la diversidad cultural, conocer los nuevos riesgos sistmicos, tener en cuenta la sostenibilidad de la empresa, el medio ambiente,
la tica, gestionar y satisfacer las necesidades y deseos de los clientes y, en
15
LA GESTIN INTEGRAL DE PROYECTOS
fin, una pltora de conceptos que no es fcil de conocer y administrar. Este

libro trata todos estos temas de una manera sencilla y estructurada.
El trabajo que ahora se presenta al lector ha sido elaborado por un equipo de 21 profesionales de distintos sectores industriales, con un promedio
de 20 aos de experiencia profesional, y que son parte del claustro de
profesores a tiempo parcial del curso on-line de postgrado de dos aos de
duracin Mster en Direccin Integral de Proyectos (MDIP) de la Universidad Pontificia Comillas de Madrid.
En los aos 90 tuve la suerte de trabajar con uno de los editores en varios proyectos offshore de la mxima tecnologa en aquellos aos. Proyectos
como el Petrojarl Foinaven, el Texaco Captain, unidades de almacenamiento y produccin de petrleo que operan en ambientes de extrema dureza,
fueron proyectos extremadamente difciles con unos clientes muy exigentes
y expertos que nos marcaron los pasos en los procesos y herramientas de
la direccin de proyectos. En aquel entonces no existan los textos de los
que afortunadamente hoy disponemos y sin duda esta obra esta llamada a
ser una autntica referencia en la literatura de la gestin de proyectos. La
mayora de los profesionales suelen tener importantes responsabilidades de
gestin en el ejercicio de su carrera profesional y por ello una formacin
especfica en la gestin de proyectos bajo una perspectiva global u holstica
se convierte en algo esencial para que en los proyectos que gestionen se
alcancen los objetivos que se hayan establecido. Los proyectos son cada vez
ms complejos y multidisciplinares en todas sus fases, y por ello su gestin
requiere de mayores recursos y conocimientos. Por eso creo que debemos
felicitarnos por contar con esta nueva obra que, sin duda, facilitar a su
lector un mejor entendimiento de la problemtica de la gestin de proyectos. Los conceptos y mtodos expuestos en este completo libro son de
aplicacin en todos los sectores industriales, por lo que sin duda constituir
una valiosa referencia para los profesionales de cualquier mbito o sector
profesional en el que los proyectos constituyan la base de la actividad.
Doy las gracias a todos los participantes en este proyecto porque tratan
una actividad cuya enseanza esta ausente de la mayora de los planes de
estudio y ponen a disposicin de las personas interesadas en esta materia
un texto de gran talento y de fcil lectura que sin duda cubrir las expectativas del lector. Adems quiero resaltar que Espaa necesita trabajos de
este tipo para crear el conocimiento y la actitud que nos haga estar preparados para este nuevo mundo hipercompetitivo.
Para terminar me gustara desear a los autores el mayor xito en esta
empresa y en su vida profesional.
Madrid, julio de 2013
16
PRLOGO
Alberto Sols, Isabel Fernndez y Javier Romero
Lo mejor en cualquier aventura, iniciativa o viaje son los compaeros

con quienes se comparte. La preparacin de este libro ha sido una singladura apasionante por la extraordinaria profesionalidad desplegada por todas las personas que han estado involucradas. La aventura de escribir este
libro ha vuelto a ponerlo de manifiesto; no podamos haber tenido mejores
compaeros de viaje.
Las empresas e instituciones desarrollan sus actividades en forma de
proyectos y su gestin siempre ha presentado importantes retos. Muchas
veces se logran los contratos deseados pero se fracasa en su ejecucin;
hay desgraciadamente demasiados proyectos fallidos o que terminan con
importantes retrasos, extra-costes y/o insatisfacciones del cliente por deficiencias en las prestaciones del producto o sistema. La formacin de jefes
de proyecto y de los profesionales que deban integrar sus equipos de trabajo sigue siendo un campo en el que hay mucho por mejorar. Este libro
aborda la gestin de proyectos bajo una perspectiva global o sistmica.
La gestin de proyectos es ante todo la gestin de las personas que integren el equipo de trabajo, antes que la resolucin de problemas tcnicos
o financieros. Por ello se tratan aspectos humanos, tcnicos y econmicos,
para dar la visin global que cualquier profesional debe tener. No es que
se deba o pueda ser un experto en todo, pero debe tenerse suficiente conocimiento y sensibilidad de todos los aspectos del proyecto, para saber
buscar e integrar las colaboraciones y aportaciones de quienes s lo sean en
cada parcela requerida en el proyecto. El libro sintetiza los conocimientos
y la experiencia prctica que cada autor ha acumulado en un promedio
de 20 aos de vida profesional; se ha procurado dar un enfoque prctico
17
a los captulos, combinando el mximo rigor acadmico con la necesaria

simplicidad para que los conocimientos expuestos puedan ser fcilmente
entendidos, asimilados y puestos en prctica.
En 2009 ICAI y Structuralia decidieron lanzar un curso on-line de postgrado en gestin de proyectos. En 2010 se imparti la primera edicin del
primero de los dos cursos del Mster en Direccin Integral de Proyectos
(MDIP). El curso se dividi en 50 Temas y cont con un claustro de 42
profesores. A primeros de este ao surgi la idea de publicar un libro,
tomando como base la excelente documentacin preparada por los profesores. El libro no poda abarcar todos los temas del curso por lo que
lo primero fue decidir cules formaran parte del libro, por considerarse
el ncleo de la gestin de proyectos; el resto de temas son magnficos
complementos a esos que integran el ncleo y que pudieron tratarse en el
curso de postgrado por disponerse de suficiente tiempo a lo largo de los
dos aos, mientras que el espacio en el libro est lgicamente muy limitado. Con un alto grado de consenso entre el director y los 10 coordinadores del curso se elabor la lista de los 18 captulos de los que finalmente
consta el libro, que sintetizan los 23 temas del curso que se consideraron
esenciales de entre los 50 existentes. El siguiente paso fue elaborar los captulos desde cero, tomando como referencia la documentacin existente
pero reescribindolos en funcin del objetivo global del libro y siguiendo
unas cuidadas normas editoriales para garantizar la mayor uniformidad
posible en la redaccin.
Queremos tener un recuerdo muy especial con los profesores que integraban el claustro y que, por las razones indicadas, no han podido formar
parte del libro: David Mateos Queiruga (Estructuras organizativas); Begoa
Vitoriano Villanueva (Decisiones multicriterio); Gabriel Andrs Prez (Nuevas tecnologas); David Gmez Fernndez (Equipos de trabajo); Pedro Saturio Carrasco (Propiedad industrial e intelectual); Eloy Carrillo Hontoria
(Pruebas y ensayos); Meritxell Criado Pea (Software de gestin de proyectos); Susana Ortiz Marcos y Mercedes Fernndez Garca (caso prctico
financiero: conservera de atn); Jos Manuel Hesse Martn (caso prctico
T4 Barajas); Jos Miguel Bellido (Proyectos de concesiones); Francisco Orts
Pardo (Proyectos de infraestructuras); Ignacio San Miguel Salazar (Proyectos
de plantas industriales); Frutos Gonzlez Berdejo (Proyectos de software);
Mateo Rodrguez-Snchez Moral (Proyectos de obra civil); Luis Guerrero
Gmez (Inspecciones y certificaciones); Angel Satu de Crdoba Minguet
(Ley de contratos del sector pblico; Estatuto de los trabajadores); Juan
Carlos Parra Gila (Evaluacin de propuestas industriales); Mara Jos Prieto
Gonzlez (Impacto medioambiental y auditoras medioambientales); Miguel
Snchez Martn (Proyectos de investigacin y desarrollo); Gestin de cali-
18
PRLOGO
dad (Juan Campuzano Garca). El alto nivel alcanzado por el MDIP se debi
tambin a su entrega y dedicacin.
Para los tres editores de este libro ha sido un privilegio haber coordinado esta apasionante iniciativa, en la que de nuevo todos los profesores
participantes han colaborado con absoluta entrega y dedicacin. A todos,
nuestro sincero agradecimiento.
Para asegurar la uniformidad de estilos se elaboraron unas estrictas normas editoriales que se dieron a los profesores y se encarg a Manuel Rodrguez Fernndez que hiciera las figuras de todos los captulos, de forma
que tuvieran un estilo homogneo; nuestro agradecimiento a Manuel por la
magnfica labor realizada. Queremos tambin agradecer muy especialmente
a Olga Villareal Galisteo, Manager en Structuralia, su absoluta dedicacin
y entrega al curso, que contribuyeron decisivamente al alto nivel alcanzado. Finalmente queremos expresar nuestro agradecimiento a Beln Recio
Godoy, directora del Servicio de Publicaciones de la Universidad Pontificia
Comillas de Madrid, tanto la magnfica respuesta con la que desde el primer
momento acogi nuestra propuesta editorial, como el extraordinario apoyo
que nos ha dado en todo momento.
Madrid, junio de 2013
19
CAPTULO 1
INTRODUCCIN A LA GESTIN INTEGRAL

DE PROYECTOS
Alberto Sols Rodrguez-Candela
1. INTRODUCCIN
El objetivo de este captulo es presentar la gestin de proyectos bajo la
perspectiva integral o sistmica. Toda empresa requiere de la existencia de
clientes; las empresas desarrollan sus actividades para sus clientes, y stas
actividades pueden estar relacionadas con el diseo, fabricacin y mantenimiento de sistemas, y/o con la prestacin de servicios. Esas actividades
suelen tener un principio y un final, adems de un objetivo. Un proyecto
es una actividad que tiene un propsito concreto y que tiene un comienzo
y un final definidos. Por ello, la mayora de las actividades de las empresas
son proyectos. Otras actividades se desarrollan de manera continua y a stas se las denomina procesos. Las empresas y organizaciones gestionan sus
proyectos, aunque no siempre con resultados ptimos; los frecuentes casos
de proyectos en los que no se alcanzan las prestaciones tcnicas previstas, o
se alcanzan pero con extracostes y/o retrasos considerables son sntoma de
que la gestin clsica de proyectos presenta importantes carencias. Mantener una visin global y gestionar el proyecto de manera integral u holstica
ser determinante a la hora de alcanzar los objetivos tcnicos previstos,
dentro del plazo y el presupuesto fijado.
21
El entorno actual es especialmente complejo y demandante, tal y como

se muestra en la figura 1.1. Es necesaria una visin global para gestionar eficaz y eficientemente los proyectos, con la mxima garanta posible de que
los objetivos de prestaciones tcnicas sern alcanzados en plazo y dentro
del presupuesto establecido. Como indic Peter Drucker, la gestin existe
por la necesidad de alcanzar los objetivos de la institucin; la gestin debe
comenzar con los resultados pretendidos y debe organizar los recursos de
la institucin para alcanzar esos resultados [Drucker, 2001].
Figura 1.1. El entorno actual.
Pocos proyectos comienzan con unos requisitos claros y bien definidos,

que adems se mantienen inalterados durante la ejecucin del proyecto;
lo habitual, desgraciadamente, es que los requisitos iniciales se vean con
frecuencia incrementados y/o modificados durante la ejecucin del proyecto, lo que inevitablemente se traducir en desviaciones en los plazos y
costes inicialmente previstos. Slo as se explica el enorme porcentaje de
proyectos que no acaban en el plazo y presupuesto previstos. Los productos y equipos diseados, denominados sistemas de manera genrica, son
cada vez ms complejos y sofisticados, lo que dificulta la especificacin de
22
INTRODUCCIN A LA GESTIN INTEGRAL DE PROYECTOS
los requisitos a ser alcanzados, la manera de verificar su cumplimiento, y

la estimacin de recursos humanos, econmicos y materiales requeridos.
Lo normal es adems no disponer de todos los recursos necesarios, lo que
presenta retos y dificultades adicionales en la gestin, complicada adems
por la continua evolucin tanto de la legislacin aplicable como de las tecnologas, hace que determinadas partes de los sistemas, o tecnologas empleadas en ellos, se vuelvan obsoletas antes incluso de finalizar el proyecto.
En el mundo globalizado en el que vivimos lo normal es contar con una
larga cadena de suministro y una amplia estructura de proveedores, con
frecuencia de mltiples nacionalidades; eso se une al hecho de que cada
vez ms equipos de proyectos son multiculturales, al estar integrados por
personas de distinta procedencia. Dado que el principal activo de cualquier
gestor de proyectos son los recursos humanos asignados, entender y gestionar esa multiculturalidad tanto dentro como fuera del equipo del proyecto
es esencial para poder alcanzar los objetivos perseguidos. Aunque los proyectos llegan a su fin, hay vida despus del proyecto. El cliente o usuario
necesitar apoyo durante la vida operativa o en servicio del sistema adquirido; la endmica falta de recursos econmicos lleva a muchos usuarios a
prolongar las vidas operativas inicialmente previstas y esas vidas operativas
extendidas presentan complicaciones adicionales de apoyo que hay que
tener presentes para poder satisfacerlas de la manera adecuada, ya que el
verdadero objetivo final es la continua satisfaccin del cliente durante toda
el tiempo que tenga el sistema a su servicio.
Tan importante es tener y mantener la visin de conjunto como evitar la
parlisis, o al menos la ralentizacin en la toma de decisiones, que puede
inducir la sobredosis de informacin; es necesario tener la capacidad de
discriminar aquellos pocos aspectos o elementos que sean verdaderamente
claves o determinantes, esos pocos elementos decisivos que deben constituir la base sobre la que se tome la decisin. Esa importancia de saber
identificar los pocos elementos decisivos y saber trabajar con ellos es lo
que se conoce como solucin Fermi [von Baeyer, 1993]. Como indic Roald
Amundsen, el primer hombre en llegar al Polo Sur, la victoria espera a
quien tiene todo en orden y ha previsto toda posible dificultad, tomando
medidas para evitarlas o mitigarlas buena suerte le llaman a eso; la derrota
espera a quien no ha tomado a tiempo las necesarias precauciones mala
suerte le llaman a eso [Amundsen y Chater, 2004].
En ocasiones se habla de proyectos y en otras se habla de programas y
de portfolios o carteras. En el contexto de este libro por programa se entiende cualquier iniciativa de extraordinaria complejidad y envergadura y que
para llevarse a cabo se descompone en varias partes, cada una de las cuales
tiene su objetivo especfico y se denomina proyecto. Por ejemplo, la unin
de dos ciudades mediante una lnea ferroviaria de alta velocidad puede
23
considerarse un programa, que podra dividirse en los siguientes proyectos:

diseo y construccin de la infraestructura (va frrea y catenaria); diseo y
construccin del sistema de sealizacin; diseo y construccin del material
rodante; diseo y programacin de la aplicacin informtica que permita
gestionar las reservas de plazas y otros servicios relacionados; etc. Por otro
lado, un portfolio o cartera es un conjunto de proyectos gestionados por
una misma entidad y no necesariamente ligados entre s en cuanto a objetivos; el conjunto de proyectos activos en una empresa en un momento dado
constituye su cartera o portfolio. La tabla 1.1 recoge las principales diferencias entre la gestin de proyectos, programas y portfolios o carteras.
MBITO
ASPECTO
PROYECTO
PROGRAMA
Existe un objetivo
y un alcance bien
definidos.
Existe un objetivo
y un alcance bien
definidos, que son la
Objetivo y
unin y la sinergia
alcance
de los objetivos de
los proyectos que
integren el programa.
La planificacin a
La planificacin a
nivel de proyecto es nivel programa es
siempre detallada,
de ms alto nivel.
identificndose las
Se identifican los
actividades necesarias objetivos generales
y los recursos
de cada uno de
requeridos para
los proyectos
alcanzar los objetivos individuales que
establecidos.
integren el programa,
as como el momento
Planificacin
de ejecutarlos.
24
PORTFOLIO
O CARTERA
Todos los proyectos
de la cartera tienen
un objetivo que debe
estar alineado con
los de la empresa u
organizacin.
La cartera de
proyectos de
la empresa u
organizacin se
gestiona de manera
dinmica, segn se
van contratando unos
proyectos y cerrando
otros, teniendo
siempre en cuenta los
recursos disponibles
en la empresa. Los
distintos proyectos
gestionados pueden
no tener vnculo de
objetivos entre s,
pero lo normal es
compartan recursos
(humanos, materiales
y/o econmicos).
MBITO
ASPECTO
Gestin y
seguimiento
xito
PORTFOLIO
O CARTERA
Los gestores o jefes
Los gestores o
Los responsables
de proyecto tienen
jefes de programa
de la empresa u
asignados recursos
coordinan y gestionan organizacin asignan
y los gestionan para
a los jefes o gestores a los gestores o jefes
alcanzar los objetivos de los proyectos
de proyecto y realizan
del proyecto. Les
integrantes del
el seguimiento de alto
compete llevar a
programa. Hacen
nivel de los proyectos
cabo el seguimiento
un seguimiento
de la cartera.
detallado de los
de alto nivel del
proyectos.
cumplimiento de los
objetivos especficos
de cada proyecto.
El proyecto concluye El programa se
El xito de la empresa
satisfactoriamente
considera un
u organizacin
siempre que se
xito si todos los
se cimenta en
alcancen sus
proyectos que lo
la renovacin
objetivos, dentro
integran terminan
constante de su
de los plazos y
satisfactoriamente.
cartera o portfolio
del presupuesto
de proyectos, en
establecidos. Ciertas
el sentido ms
desviaciones en
amplio (nmero
prestaciones, plazo
de proyectos, de
y/o presupuesto
clientes finales,
pueden ser, en
importe global, etc.)
determinadas
y en su satisfactorio
ocasiones, admisibles
cumplimiento.
para el cliente final.
PROYECTO
PROGRAMA
Tabla 1.1. Diferencias de gestin de proyectos, programas

y portfolios o carteras.
La relacin entre los diversos proyectos en los que se descomponga un

programa y las carteras o portfolios de proyectos de las empresas u organizaciones involucradas se muestra en la figura 1.2.
25
Figura 1.2. Programas, proyectos y portfolios o carteras.
2. LA EVOLUCIN DE LA GESTIN DE PROYECTOS

Con frecuencia nos referimos a nuestra especie como la del homo faber,
el hombre que hace o fabrica cosas. El ser humano es el animal que concibe, disea y fabrica cosas para servirse de ellas y alterar el entorno en su
provecho. Desde los jardines colgantes de Babilonia, las pirmides egipcias
o tantas otras creaciones humanas de la antigedad, pasando por la Gran
Muralla china y las catedrales de la Edad Media, a los modernos equipos y
sistemas como los satlites que conforman el Global Positioning System o
el Curiosity Mars Rover enviado por la NASA a Marte, el ser humano siempre ha diseado y construido cosas, cada vez ms sofisticadas y complejas.
Cada una de esas iniciativas fue un proyecto, segn la terminologa actual,
con independencia de cmo fuera denominada la iniciativa en su momento.
Desde siempre han existido proyectos y por lo tanto desde siempre han
sido gestionados, con mayor o menor xito.
La publicacin por Ren Descartes en 1637 de su famoso Discurso del
Mtodo para dirigir adecuadamente la razn e investigar la verdad en las
ciencias supuso la creacin del enfoque reduccionista, denominado as
por el segundo de los cuatro preceptos de Descartes. La idea de tratar los
problemas complejos descomponindolos en partes que s pudieran ser
tratadas y resueltas, el famoso divide y vencers, facilit la gestin de los
proyectos cada ms complejos que se iban acometiendo. A comienzos del
siglo XX los trabajos de Frederick Taylor [Taylor, 1911] sobre la gestin
cientfica del trabajo supusieron un notable adelanto, trabajos que fueron
26
complementados con los de Frank Gilbreth, ms orientados a la reduccin

del nmero de movimientos necesarios en las operaciones de trabajo que
a la reduccin de sus tiempos, aspecto en el que se centr Taylor. A mediados del siglo XX surgi la ingeniera de sistemas y con ella el enfoque
sistmico, caracterizado por la visin de conjunto. La aplicacin a la gestin
de proyectos del enfoque sistmico supuso la gestin bajo una perspectiva
integral, global u holstica.
3. LA GESTIN INTEGRAL DE PROYECTOS

Ingeniera de sistemas es el proceso a travs del cual un conjunto de
objetivos es transformado en un sistema que satisface las necesidades de
los stakeholders (grupos de inters) y que implementa de manera efectiva
y eficiente los adecuados procesos a lo largo de su vida operativa. El concepto de ingeniera de sistemas queda esquemticamente representado en
la figura 1.3.
Figura 1.3. Ingeniera de sistemas.
La ciencia moderna se caracteriza por un nivel de especializacin cada

vez mayor; adems, en cada campo de la ciencia se requieren cada vez ms
datos y se emplean tcnicas ms especficas y sofisticadas. Ello lleva a un
cierto aislamiento de los campos de la ciencia, que hace que de los avances
que se produzcan en un campo no siempre se beneficien adecuadamente
en el resto. Estas inquietudes llevaron a que a principios del siglo XX un
grupo de profesionales, entre los que destacaba el bilogo Ludwig von
Bertalanffy, plantearan la necesidad de una nueva disciplina cuyo propsito
fuera la formulacin de principios que fueran vlidos para sistemas en general, independientemente de la naturaleza de sus componentes o de las relaciones entre ellos. El nombre que acuaron para esa nueva disciplina fue
el de teora general de sistemas. En paralelo a las consideraciones de von
Bertalanffy se encontraron las de otros profesionales como el economista
Boulding, el biomatemtico Rapoport y el fisilogo Gerard. Ellos fueron los
27
promotores de la denominada Sociedad para la Investigacin General de

los Sistemas, en 1954.
Trabajos como Teora de Juegos y Comportamiento Econmico [von Neumann et al., 1944], Cybernetics [Wiener, 1948], La Teora Matemtica de la
Comunicacin [Shannon et al., 1949], Teora General de Sistemas [von Bertalanffy, 1951] e Industrial Dynamics [Forrester, 1961], entre otros, supusieron un esfuerzo por crear una teora interdisciplinar de los sistemas, capaz
de proporcionar mtodos y modelos de aplicacin en todos los campos.
Esta Era de los Sistemas se caracteriza por el enfoque sistmico, paradigma que ha sustituido en la conceptualizacin de los sistemas al enfoque
reduccionista de Descartes [Quints, 1999]. De entre las caractersticas del
enfoque sistmico se pueden destacar como esenciales las ocho siguientes,
mostradas en la figura 1.4.
Figura 1.4. Las caractersticas del enfoque sistmico.
a) Capacidad de generar conocimiento. El enfoque sistmico no slo

permite disear y desarrollar sistemas que satisfacen necesidades determinadas, especificadas mediante un conjunto de requisitos cualitativos y cuantitativos, sino que adems ayuda a modelar sistemas con
28
b)
c)
d)
e)
la finalidad de conocer mejor tanto su estructura como su comportamiento. Permite analizar los resultados previsibles de comportamiento bajo diferentes escenarios, lo que ayuda a generar conocimiento
acerca del propio sistema.
Consideracin teleolgica. La teleologa es la doctrina de las causas
finales; el reconocimiento expreso de que los sistemas diseados y
desarrollados persiguen la satisfaccin de necesidades identificadas
constituye la caracterstica teleolgica propia del enfoque sistmico.
Como se ver ms adelante, el proceso de ingeniera de sistemas que
conduce al diseo y posterior desarrollo y utilizacin del sistema deseado para cubrir una determinada necesidad comienza, precisamente, con la identificacin de esa necesidad y su definicin en trminos
de requisitos.
Consideracin del ciclo de vida. El hecho de que los tiempos requeridos para disear y desarrollar sistemas es cada vez mayor, como
tambin lo es el tiempo durante el que previsiblemente ser utilizado
el sistema, hace que el reconocimiento explcito de toda la vida del
sistema, con las consecuencias que ello implica, tenga una importancia capital. El enfoque sistmico se caracteriza por tener en cuenta,
desde el mismo momento de la identificacin de una necesidad, del
ciclo completo de vida del sistema; ese ciclo de vida comienza con la
identificacin y definicin de la necesidad y termina con la retirada
de servicio del sistema desarrollado. Ello posibilita prever las actividades que ser necesario llevar a cabo en cada una de las fases o
etapas del ciclo de vida para alcanzar los objetivos perseguidos.
Consideracin dinmica. Las necesidades que se identifican en un
determinado momento marcan, como se ha indicado, el comienzo
del proceso de ingeniera de sistemas. Tras las fases de especificacin
de requisitos, diseo y desarrollo, vendr la entrada en servicio del
sistema. Sin embargo, la necesidad sentida puede haber cambiado
en el transcurso de ese tiempo; ms an, durante la vida en servicio
del sistema pueden cambiar tanto algunas caractersticas del sistema
como la propia necesidad a satisfacer. Esa naturaleza cambiante tanto
de los sistemas como del entorno en el que son utilizados constituye
la consideracin dinmica propia del enfoque sistmico.
Concepto de realimentacin. La existencia de una necesidad a satisfacer y la naturaleza dinmica de los sistemas hace necesario reconsiderar de forma continua la medida en la que el sistema, tanto
si est an en fase de diseo o desarrollo como si ya se encuentra
en servicio, sigue satisfaciendo la necesidad identificada. Esa reconsideracin permanente de lo recibido del sistema y lo deseado de l
29
constituye el concepto realimentacin, uno de los pilares del enfoque

sistmico.
f) Multidisciplinariedad. Los problemas a satisfacer son cada vez ms
complejos, por lo que para el diseo y desarrollo de los sistemas es
necesaria la participacin de especialistas en diferentes materias o
disciplinas. Ello presenta a su vez la necesidad de una adecuada comunicacin entre esos distintos especialistas para que la integracin
de las disciplinas sea efectiva y eficaz. El reconocimiento de la multidisciplinariedad que entraa el diseo y desarrollo de los sistemas es
otra de las caractersticas que destaca al enfoque sistmico.
g) Sinergia. Un sistema es, como un todo, ms que la suma de las partes
o elementos integrantes y posee propiedades o cualidades de las que
no goza ninguno de ellos. Ello se debe a que normalmente el efecto
de varias causas es superior a la suma de los efectos de estas, lo que
se conoce como sinergia y cuya consideracin es otra de las caractersticas bsicas del enfoque sistmico.
h) Concepto de utilidad. La creciente concienciacin de lo limitado de
los recursos ha supuesto que el hombre desee obtener sistemas para
cubrir sus necesidades, pero no a cualquier precio. Estamos dispuestos a asumir un cierto coste, en el sentido ms amplio, por un determinado nivel de satisfaccin de una necesidad sentida. Esa relacin
es lo que se conoce como utilidad, cuyo concepto es una de las piedras angulares del enfoque sistmico. La utilidad que un determinado
sistema representa para su usuario es la relacin coste/efectividad,
siendo efectividad el grado o medida en la que el sistema considerado satisface la necesidad del usuario y siendo coste el coste global,
conocido como coste del ciclo de vida, que el sistema representa
para el usuario.
Existe una relacin muy estrecha entre la ingeniera de sistemas y la
gestin de proyectos, como ha sido indicado por numerosos autores [Blanchard, 1991; PMI, 2008; Sage et al. 2009; Sharon et al. 2011]. La ingeniera
de sistemas se centra en entender la necesidad identificada o la oportunidad de negocio detectada, expresarla en forma de requisitos de alto nivel (independientes del concepto de diseo que finalmente se seleccione),
identificar posibles soluciones o conceptos de diseo, seleccionar el ms
adecuado, traducir los requisitos de alto nivel a requisitos detallados especficos para el concepto de diseo seleccionado, y disear el sistemas
segn los requisitos establecidos. Por su parte, la gestin de proyectos se
centra ms en el cmo que en el qu; una vez se ha decidido qu sistema
disear, fabricar o desplegar, la gestin de proyectos se centra en llevarlo a
cabo de manera eficaz y eficiente. Si el dominio de la ingeniera de sistemas
30
es el producto, el de la gestin de proyectos es el del medio de obtenerlo.

Ambos dominios tiene una estrechsima relacin, tal y como se muestra
en la figura 1.5, ya que ambas actividades o disciplinas estn ntimamente
ligadas. A la interseccin de ambos dominios se le denomina gestin de
ingeniera de sistemas.
Figura 1.5. Ingeniera de sistemas y gestin de proyectos.
Un proyecto es cualquier iniciativa que persigue la consecucin de unos

objetivos especificados, dentro de un plazo y un presupuesto determinados.
La ingeniera de sistemas es la disciplina que permite analizar necesidades
identificadas u oportunidades de negocio detectadas y transformarlas en
sistemas que, a lo largo de toda su vida operativa, las satisfagan de manera
eficaz y eficiente. La gestin integral de proyectos es por tanto la aplicacin
del enfoque sistmico a la gestin de proyectos.
4. LA VISIN DE CONJUNTO
Tradicionalmente se ha hablado del tringulo de hierro en la gestin
de proyectos, siendo los tres lados del tringulo las prestaciones tcnicas,
los costes y el calendario, como se muestra en la figura 1.6. El objetivo
en la gestin clsica de proyectos se centraba en alcanzar los objetivos
31
de prestaciones tcnicas dentro de los plazos marcados y del presupuesto

establecido.
Figura 1.6. El tringulo de hierro.
Sin embargo, bajo la perspectiva integral o sistmica hay otros aspectos

que deben ser considerados. Por ejemplo, puede que el objetivo esencial
del proyecto sea fidelizar a un cliente, o demostrarle una determinada capacidad de actuacin, o desarrollar unas capacidades en la empresa, ms
que alcanzar unas determinadas prestaciones tcnicas, en un cierto plazo
y con un determinado presupuesto. Es de la mxima importancia saber
cules son los objetivos que se persiguen en el proyecto y priorizarlos; por
ejemplo, una empresa puede acometer un proyecto de fabricacin de un
lote de piezas para un cliente y su principal objetivo puede ser lograr la
confianza del cliente (entregando en plazo y con la calidad requerida, adems de manteniendo una comunicacin fluida y transparente) y desarrollar
las capacidades internas necesarias para poder fabricar de manera eficaz
y eficiente futuros lotes de piezas, aunque en ese primer lote el aspecto
econmico sea el de menor importancia (pudiendo incluso perderse dinero
y an as ser considerado el proyecto un xito notable si se materializan
los dems objetivos). La figura 1.7 muestra el polgono de hierro definido
por los mltiples aspectos que deben considerarse en la gestin integral de
proyectos.
32
Figura 1.7. El polgono de hierro en la gestin integral de proyectos.
5. EL GESTOR O JEFE DE PROYECTOS

El cometido principal del gestor o jefe de proyectos es entender los
objetivos que se persiguen con el proyecto, ser consciente de las circunstancias o condiciones de contorno que existan, conocer cmo querr el cliente verificar el cumplimiento de sus requisitos, y saber emplear los recursos asignados para alcanzar esos objetivos manteniendo
en todo momento la visin global o de conjunto. Con frecuencia se
toman decisiones que resultan correctas en cierta medida, pero que de
haberse considerado todos sus efectos y consecuencias la bondad de
esas decisiones se habra percibido de manera muy diferente; esa falta
de visin de conjunto est detrs de la mayora de decisiones errneas o
desafortunadas que se toman en los proyectos, no slo ahora sino desde
hace dcadas e incluso siglos, como ha quedado por ejemplo muy bien
documentado en el caso del hundimiento del buque sueco Vasa en el
siglo XVII [Fairley et al., 2003]; desgraciadamente los errores que se cometieron en el proyecto de diseo y construccin del buque Vasa siguen
siendo muy habituales, aunque las consecuencias no sean siempre tan
llamativas o dramticas.
El gestor de proyectos debe ser como un director de orquesta, que no
tiene que saber tocar los instrumentos mejor que cada uno de sus msicos pero s tiene la visin global y es capaz de integrar las aportaciones
33
y contribuciones de los msicos de la orquesta de manera ordenada,

para lograr rendir bien como conjunto y que el resultado musical sea
armonioso. El gestor de proyectos no ser experto en todo, cosa imposible por otro lado, pero s debe saber qu aportaciones son necesarias y
debe saber cmo integrarlas. No obstante, lo normal es que todo gestor
de proyectos haya evolucionado en su carrera profesional y antes de alcanzar esas responsabilidades de gestin haya sido un experto que haya
participado en otros proyectos; es decir, el gestor de proyectos podr
ser experto en una o varias reas, aunque su principal valor aadido
como gestor no est en su calidad de experto en varias reas, sino en la
capacidad de integrar las aportaciones de todos los miembros del equipo. Adems el jefe de proyecto debe tener una visin global de todos
los stakeholders o grupos de inters relacionados con el proyecto, y no
slo del cliente final.
Entre los recursos asignados al proyecto habr medios humanos, materiales y financieros. El capital humano es el principal activo de cualquier
proyecto. Vivimos en la era de los trabajadores del conocimiento. Los conocimientos y experiencia de los integrantes del equipo son el principal
activo del proyecto, por lo que el gestor o jefe de proyecto debe darles
la mxima importancia en su gestin. Los profesionales del conocimiento
quieren sentirse tiles, poner en prctica lo que ya saben y aprender cosas
nuevas que les permitan progresar y crecer personal y profesionalmente.
El jefe de proyecto debe conocer las cualidades y caractersticas de los
miembros de su equipo para asignarles las tareas ms adecuadas a cada
uno, adems de para ofrecerles un entorno estimulante en el que llevar a
cabo esas tareas. Tambin es responsabilidad del jefe de proyectos asegurar
la satisfaccin final del cliente, lo que conlleva conocer y comprender los
medios que se emplearn para verificar de manera objetiva a la finalizacin
del proyecto el cumplimiento de los requisitos. Igualmente debe recopilar
las lecciones aprendidas, para que puedan ser compartidas en su empresa
u organizacin. La tabla 1.2 recoge las principales funciones del gestor o
jefe de proyectos.
34
PRINCIPALES FUNCIONES DEL GESTOR DE PROYECTOS

Conocer y entender los objetivos del proyecto.
Conocer las condiciones de contorno y limitaciones existentes.
Identificar los perfiles necesarios de las personas que deban integrar el equipo del
proyecto.
Identificar las tareas necesarias y planificar su ejecucin.
Identificar y gestionar los principales activos disponibles.
Identificar y gestionar las principales dependencias externas (aspectos en los que
se dependa de un proveedor externo).
Asignar los recursos disponibles a las tareas identificadas.
Gestionar de forma activa los riesgos.
Motivar a las personas del equipo del proyecto y ayudarlas a crecer personal y
profesionalmente.
Realizar el seguimiento del proyecto y actualizar la planificacin segn resulte
necesario.
Informar al cliente y al resto de stakeholders que proceda sobre el progreso y los
riesgos identificados.
Asegurar la consecucin de los objetivos y lograr la satisfaccin del cliente.
Recopilar las lecciones aprendidas y compartirlas con el resto de su empresa u
organizacin.
Tabla 1.2. Las principales funciones del gestor de proyectos.
6. SNTESIS DEL CONTENIDO DEL LIBRO

Esta Seccin resume los principales temas contenidos del libro; al sintetizar aqu el objeto de cada captulo se muestran, de forma resumida,
todos los aspectos clave a ser tenidos en cuenta en la gestin integral de
proyectos. Todo proyecto comienza con la identificacin y definicin del
objetivo perseguido; a continuacin se identifican y detallan las tareas cuya
realizacin es necesaria para alcanzar los objetivos especificados. El captulo 2 aborda la definicin del alcance del proyecto, la identificacin de
las tareas necesarias y su agrupacin en la denominada Descomposicin
Estructurada de Tareas. Posteriormente debe realizarse la planificacin de
la realizacin de las tareas, identificndose los recursos que deben ser
asignados a cada una y las relaciones existentes de precedencia entre ellas;
junto con la definicin detallada de las tareas deben identificarse los riesgos
que puedan dificultar o impedir el logro de los objetivos del proyecto. El
captulo 3 trata de las tcnicas de planificacin de proyectos y de las estrategias de gestin de riesgos; se analizan diversas tcnicas de planificacin
35
de proyectos, identificndose sus ventajas e inconvenientes, y se identifican

tanto los posibles orgenes de los riesgos para el proyecto como las tcnicas para su valoracin y las estrategias para su mitigacin o eliminacin. La
gestin de proyectos bajo una perspectiva global implica mucho ms que
cumplir con la legislacin aplicable; es necesario gestionar los proyectos un
una exigente tica profesional, aspecto tratado en el captulo 4.
El captulo 5 se dedica a la relacin con proveedores y subcontratistas;
lo habitual es que el contratista cuente con otras empresas y esa cadena de suministro presenta tanto oportunidades como riesgos, por lo que
su adecuada gestin es clave en el proyecto. La gestin financiera es un
elemento bsico en cualquier proyecto, tanto si se persigue la realizacin
de un beneficio como si no, ya que los recursos econmicos son siempre
limitados y hay que garantizar su mejor aprovechamiento. El captulo 6 de
dedica a la gestin financiera de los proyectos, analizndose aspectos tan
importantes como su viabilidad econmica y su rentabilidad, y el captulo 7
se centra en la financiacin de proyectos, analizando las distintas opciones
existentes para obtener los recursos necesarios para la realizacin de un
proyecto. Incluso los proyectos en los que no se persiga la obtencin de
un beneficio econmico deben gestionar con acierto los recursos disponibles, siempre escasos, por lo que estos captulos de ndole financiera son
siempre esenciales.
Haber realizado una planificacin y una identificacin de riesgos es
necesario para la gestin del proyecto, pero no es suficiente. Debe realizarse una seguimiento detallado de la marcha del proyecto para detectar
cualquier desviacin respecto a lo previsto, identificar las causas, y tomar las oportunas acciones correctoras. El seguimiento de proyectos es
el tema del captulo 8, que incluye el cuadro de mando integral como
herramienta para facilitar al gestor del proyecto una radiografa fiel y
precisa de la salud del proyecto en cada momento. Las negociaciones
son parte esencial de cualquier proyecto, desde que cliente y contratista negocian el contrato hasta las negociaciones del contratista con sus
suministradores, pasando por las negociaciones internas que puedan
tener lugar en la empresa del contratista e incluso dentro del equipo
del proyecto; el captulo 9 introduce el concepto de negociacin y sus
principales estrategias.
El captulo 10 trata la organizacin y direccin del equipo del proyecto; se identifican los principales perfiles y caractersticas de los miembros del equipo y se analizan sus roles en el equipo. El captulo 11 se
dedica a los temas de liderazgo y comunicacin; en muchos sentidos el
gestor de proyectos debe ser el lder del equipo, que sepa comunicar
y pueda inspirar a los miembros de su equipo para ayudarles a crecer
36
personal y profesionalmente, ms all de simplemente asignarles tareas

para su realizacin.
No todos los proyectos son iguales y, por tanto, ni deben ser gestionados por el mismo tipo de persona, ni deben ser gestionados de la misma
manera. Es esencial entender bien las peculiaridades de cada proyecto para
asignarle el gestor adecuado, quien deber a su vez establecer el oportuno
sistema de gestin basado en la caractersticas del proyecto; el captulo 12
presenta sistemas de clasificacin de proyectos y da directrices para su gestin, en funcin de su clasificacin. Con independencia de la naturaleza del
proyecto es siempre necesario mantener plena visibilidad de la configuracin del producto o equipo desarrollado, o del servicio prestado; la gestin
de la configuracin, tratada en el captulo 13, le da al gestor de proyectos
esa necesaria visibilidad. Igualmente todo proyecto, con independencia de
su naturaleza, puede caer en situaciones que se consideren crticas; en el
captulo 14 se indica cmo detectar si un proyecto est en crisis y necesita
ser recuperado, as como las principales estrategias que pueden adoptarse
para recuperarlo.
En este mundo cada vez ms globalizado es frecuente que cliente y contratista no sean del mismo pas. Ese hecho introduce importantes aspectos
adicionales a la gestin del proyecto, dado que deben considerarse aspectos culturales, idiomticos, legales, etc.; el captulo 15 trata de los aspectos
inherentes a los proyectos internacionales. Un tipo especial de proyectos
son los multinacionales, aquellos en los que existen mltiples clientes y
normalmente tambin mltiples contratistas; la complejidad es an mayor
que en un proyecto internacional. El captulo 16 trata de las singularidades
de los proyectos multinacionales.
Todo proyecto tiene su fin y el captulo 17 est dedicado al cierre de los
proyectos y a las actividades que el cierre conlleva; se abordan temas como
las auditoras de cierre, las actas de replanteo y la verificacin de requisitos.
A pesar de que todo proyecto es finalizado, el trmino del proyecto no significa necesariamente el final de la relacin entre cliente y contratista; ms
all de la garanta legal, la finalizacin del proyecto permite establecer otras
lneas de colaboracin para mantener el sistema entregado en las debidas
condiciones a lo largo de su vida operativa. Este es el concepto de apoyo
al ciclo de vida, cubierto en el captulo 18.
37
7. REFERENCIAS
AMUNDSEN, R. y CHATER, A. G., The South Pole: 1910-1912, Digireads (Kindle Edition), 2004, pp. 209.
BAEYER von, H. Ch., The Fermi Solution, Dover Publications Inc., 1993, pp. 3-12.
BLANCHARD, B., System Engineering Management, John Wiley & Sons, 1991.
DRUCKER, P., The Essential Drucker, Harper Business 2001, pp. 93.
FAIRLEY, R. E. y WILLSHIRE, M. J., Why the Vasa Sank, IEEE Software, ISSN 07407459, 2003, Volume 20, Issue 2, pp. 18-25.
FORRESTER, J., Industrial Dynamics, MIT Press, 1961.
NEUMANN, J. von y MORGENSTERN, O., Theory of Games and Economic Behavior,
Princeton University Press, 1944.
PROJECT MANAGEMENT INSTITUTE, A Guide to the Project Management Body of
Konwledge, Project Management Institute, 2008.
QUINTS ALONSO, G., El Discurso del Mtodo de Descartes, Alianza Editorial, 1999.
SAGE, A. P. y ROUSE, W. B. (eds.), Handbook of Systems Enginering and Management, John Wiley & Sons, 2009.
SHANNON, C. y WEAVER, W., Mathematical Theory of Communication, Illinois University Press, 1949.
SHARON, A., WECK, O. L. de y DORI, D., Project Management vs. Systems Engineering Management: A Practitioners View on Integrating the Project and Product
Domains, Systems Engineering, Vol. 14, No. 4, 2011, pp. 427-440.
TAYLOR, F. W., The Principles of Scientific Management, 1911.
38
CAPTULO 2
EL ALCANCE DEL PROYECTO

Juan Jos Burgaz Fernndez
1. INTRODUCCIN
En el captulo 1 se ha dado una visin global de cmo deben afrontarse
los proyectos, contemplando todos los aspectos relacionados, sin olvidar
ninguno, y se adelant la forma de abordar ms en detalle algunos de esos
aspectos. Concretamente se trataron la necesidad y la ingeniera de sistemas
y se realiz una breve introduccin a la gestin de proyectos.
Este captulo 2 cubre todos aquellos aspectos y consideraciones que deben tenerse en cuenta al inicio de un proyecto para definirlo y delimitarlo.
Se define lo que es el alcance del proyecto, su contenido, y el seguimiento
que debe hacerse del mismo a lo largo del proyecto. Por una parte se identifican de forma exhaustiva todos los elementos que conforman el alcance
del proyecto, y por otra se dan ciertas pautas y aspectos a tener en cuenta
sobre cada uno de ellos. El conjunto de estas consideraciones iniciales
determinar el alcance global del proyecto, que debe quedar fijado de la
forma ms precisa posible.
Conviene recordar que olvidos, decisiones y cambios tardos en el ciclo
de vida de un sistema y de un proyecto dan lugar a costes mucho ms altos
cuanto ms tarde se producen. Fijar claramente los requisitos al inicio del
proyecto servir para evitar, o al menos minimizar, los imprevistos y los
costes asociados a los mismos [Blanchard, 2008].
39
El captulo se ha estructurado comenzando por una visin global, de

manera que se pueda enmarcar el alcance dentro del esquema general
de un proyecto, para pasar luego a describir el contenido del alcance y la
gestin del mismo en detalle. Como parte importante del alcance de un
proyecto, se aborda en este captulo el WBS (Work Breakdown Structure)
o Descomposicin Estructurada de Tareas (DET), fundamental para la planificacin de un proyecto, la cual se trata en el captulo 3.
2. CICLOS DE VIDA DE PROYECTO Y DE SISTEMA

En el captulo 1 se mencion el ciclo de vida de los sistemas o productos, el cual no debe confundirse con el ciclo de vida de un proyecto. La
relacin entre ambos debe tenerse siempre presente, como se explica en
esta seccin. En la figura 2.1 se ilustra el ciclo de vida de los sistemas y las
distintas fases que lo conforman.
Figura 2.1. Ciclo de vida de los sistemas.
Los proyectos a su vez tambin tienen un ciclo de vida, cuyas fases de

alto nivel pueden denominarse como inicial, intermedia y final. En la fase
inicial es cuando se lanza el proyecto, sentando las bases del mismo y estableciendo las caractersticas principales. En la fase intermedia se realizan
los tres procesos principales, que son la planificacin, la ejecucin y el
40
seguimiento y control. En la fase final se hace el cierre del proyecto, se analizan los resultados finales obtenidos, y se documentan dichos resultados
y las lecciones aprendidas. En el captulo 17 se profundiza en los detalles
del contenido de esta fase. En la figura 2.2 se ilustra el ciclo de vida de un
proyecto en forma de diagrama.
Figura 2.2. Fases del ciclo de vida de un proyecto.
El alcance del proyecto debe definirse lo mejor que se pueda en la fase

inicial, denominndose en esa fase alcance preliminar, debido a las indeterminaciones que sin duda existirn. Una vez el proyecto entra en su fase
intermedia, donde la mayora de los requisitos deberan estar claramente
definidos, el alcance pasa a denominarse alcance detallado. Esto no quiere
decir que el alcance quede ya congelado e inamovible durante el resto del
proyecto. De hecho, los procesos de planificacin, ejecucin y seguimiento
y control del proyecto se desarrollan de forma cclica durante la fase intermedia, evolucionando el alcance al mismo ritmo durante esos ciclos.
Los proyectos estn vinculados a alguna o todas las fases del ciclo de
vida de un sistema. Puede haber proyectos de adquisicin, proyectos de
desarrollo, proyectos de mejora o actualizacin, proyectos de enajenacin,
etc, que cubren una o ms fases del ciclo de vida del sistema. Por este
motivo, la vida de un proyecto es normalmente ms corta que la vida de
un sistema [Sage, 1999]. Hay proyectos que no estn necesariamente vinculados a sistemas, sino que tienen como producto final un servicio. Para
estos proyectos, se aplican las mismas consideraciones mencionadas, pero
con las adaptaciones necesarias. En la figura 2.3 se ilustra un ejemplo de la
relacin entre el ciclo de vida de un sistema o producto y el ciclo de vida de
un proyecto, para el caso tpico de un proyecto de adquisicin, desarrollo
o fabricacin de un producto, que suele ser lo ms habitual.
41
Figura 2.3. Ciclo de vida del producto y ciclo de vida del proyecto.
3. DEFINICIN DEL ALCANCE DE UN PROYECTO

Se define como alcance de un proyecto el trabajo que debe realizarse
para entregar un producto, servicio o resultado con las funciones y caractersticas especificadas. Es, por tanto, un conjunto de informacin necesaria, que define y delimita el proyecto. El contenido de la informacin
del alcance es lo que conforma el cuerpo principal de este captulo (ver
seccin 2.5).
El alcance del proyecto, como se mencion anteriormente, est presente
en todas las fases del mismo: inicial, intermedia y final, y en los procesos de
planificacin y seguimiento y control de la fase intermedia.
En la fase inicial debe generarse el alcance preliminar del proyecto, que
bsicamente integra los requisitos de alto nivel, los principales productos
entregables y las hiptesis y restricciones del proyecto. Durante la fase de
inicio del proyecto habr muchas reas donde la informacin no est an
suficientemente madura, o incluso puede que se desconozca, pero debe
completarse el alcance preliminar con la informacin disponible. El alcance
preliminar incluir informacin de alto nivel en relacin con los objetivos
del proyecto y del sistema; los requisitos asociados a ambos; los lmites del
proyecto; los entregables, sus requisitos y criterios de aceptacin; hiptesis
y asunciones en el proyecto; organizacin inicial; hitos principales; desglose inicial de tareas; presupuesto estimado y requisitos de gestin. Dependiendo del rea de aplicacin y la complejidad del proyecto se incluirn
todos o slo algunos de los elementos citados. Durante las siguientes fases
42
del proyecto, se completar, refinar y validar la informacin aportada en

la definicin preliminar a medida que se vayan concretando los distintos
aspectos.
En la fase intermedia del proyecto, el alcance es parte fundamental del
proceso de planificacin, pues una vez desarrollado el alcance detallado,
se genera el WBS o descomposicin estructurada de tareas, que es la base
de la planificacin. Una vez disponible el alcance detallado al inicio de la
planificacin, debe estar sometido a un seguimiento y control durante la
ejecucin del proyecto, para identificar problemas o desviaciones, y poder
as corregir o reconducir el proyecto.
En la fase final del proyecto debe verificarse que se han alcanzado los
objetivos del proyecto y que se ha cumplido con el alcance fijado. Las conclusiones de esta verificacin formarn parte del conjunto de resultados del
proyecto.
En la figura 2.4 se presenta un flujograma que muestra los procesos de
alto nivel en las fases de un proyecto, y se sombrean en los que intervienen
las actividades relacionadas con el alcance del proyecto.
Figura 2.4. Ciclo genrico de procesos iterativos de un proyecto y alcance.
43
4. DETERMINACIN DEL ALCANCE DE UN PROYECTO

4.1. La necesidad
Todo proyecto nace de una necesidad u oportunidad de negocio, cuya
satisfaccin requiere la realizacin de un proyecto. La necesidad puede ser
de disear un sistema, de mejorarlo, de fabricarlo, de investigacin, de procesos, de servicios, o de cualquier combinacin de los anteriores entre ellos
o con otras necesidades de distinta ndole.
La necesidad puede surgir a nivel individual, grupo, empresa, organizacin, etc., o puede ser una oportunidad de negocio detectada y lanzada
ante la expectativa de que el mercado la acepte. La generacin de los requisitos que se derivan de la necesidad u oportunidades es distinta en cada
caso, y el carcter y tratamiento de los requisitos es diferente.
Figura 2.5. De la necesidad al alcance detallado del proyecto.
44
La necesidad debe analizarse y estudiarse detalladamente, y debe expresarse por escrito para que quede claramente identificada. Hay que tener
en cuenta que a partir de ella se identificarn los stakeholders o grupos
de inters que debern participar en la identificacin y definicin de los
requisitos, que son, en definitiva, los que determinarn el alcance del proyecto. Est claro que cuanto ms concisa sea la definicin de la necesidad,
ms sencillo ser acometer todo lo que sigue, pues deriva de ella. En el
diagrama de la figura 2.5 se ilustra la secuencia natural hasta la definicin
del alcance del proyecto.
La necesidad est en la cspide de esta pirmide, y todo mana de ella,
por lo que debe dedicarse el tiempo necesario con las personas adecuadas
hasta llegar al entendimiento y materializacin por escrito de la misma.
4.2. Los grupos de inters o stakeholders
Una vez acordada y expresada la necesidad, deben identificarse todos
los grupos de inters o stakeholders que deben intervenir en la definicin
de requisitos del sistema y del proyecto que cubrir la necesidad [Freeman,
1984]. El conjunto de los requisitos de los stakeholders determinar en gran
medida el alcance del proyecto.
Es muy importante no olvidar ningn stakeholder inicialmente, por lo
que hay que identificar toda persona, grupo o entidad que est implicada
en el proyecto y que deba contribuir al establecimiento de los requisitos. En
la figura 2.6 se ilustra cmo vara tpicamente la intervencin de los stakeholders durante la vida del proyecto, y el impacto econmico que tienen
requisitos nuevos dependiendo del momento en que aparecen. Si bien cada
vez la intervencin es menor, si se produce, el impacto en coste es mayor
cuanto ms tarde ocurra.
Los stakeholders pueden ser de muy distinta ndole y procedencia. Con
carcter general, se puede decir que como mnimo, sern stakeholders
de un sistema las siguientes personas o entidades: el que paga, el que
especifica, el que desarrolla, el que prueba, el que instala, el que utiliza, el que sufre y el que mantiene el sistema. Puede haber ms, y hay
que ser capaz de identificarlos a partir de la necesidad definida. Merece
la pena al inicio del proyecto hacer el esfuerzo de identificarlos todos y
hacerlos partcipes del proyecto en ciernes, para que aporten su parte de
los requisitos.
En la figura 2.7 se ilustra el universo de los stakeholders, centrado
en el equipo de proyecto, donde se deben recoger y centralizar todos los
requisitos. Se identifica explcitamente a quien aporta los fondos (cliente),
por su papel relevante, y al equipo del proyecto, y en el anillo exterior se
recoge al resto.
45
Figura 2.6. Participacin de los stakeholders a lo largo del proyecto.
Figura 2.7. Relacin entre los stakeholders principales de un proyecto.
46
4.3. Los requisitos

Los requisitos son la clave para la definicin del alcance del proyecto.
As como la necesidad puede quedar plasmada en un documento corto,
de una o dos pginas, los requisitos pueden quedar recogidos en documentos extensos, incluso de cientos de pginas para sistemas o proyectos
complejos.
En cierto modo, la necesidad inicial del cliente es ya un requisito, el
requisito original y primigenio, pero que no permite por s mismo definir
completamente lo que hay que hacer. Luego se recogen los distintos requisitos de los stakeholders, que suelen ser requisitos de alto nivel o primarios.
Estos requisitos deben transformarse en requisitos de bajo nivel o detallados, que dan lugar a los requisitos tcnicos o de sistema (especificaciones)
y a los requisitos de gestin o de proyecto.
Esta transformacin es una de las partes ms difciles y delicadas del
proyecto. Se trata de traducir unos requisitos normalmente genricos en
requisitos que permitan realizar materialmente el proyecto, cumpliendo con
los de alto nivel completamente, pero sin excederlos. Para ello es necesario
que se aplique de forma adecuada la ingeniera de sistemas. Se utiliza el
trmino Ingeniera de Requisitos para la aplicacin de tcnicas de ingeniera
en la captacin, entendimiento, redaccin, transformacin, seguimiento y
control del cumplimiento de los requisitos [Sommerville y Sawyer, 1997].
Los ingenieros de sistemas encargados de esta tarea deben conocer y entender los requisitos de los stakeholders y poseer los conocimientos tcnicos y
de gestin necesarios para poder transformarlos en un proyecto realizable.
En cuanto el sistema es mnimamente complejo es necesario un equipo con
distintos especialistas para poder completar este proceso. Sern necesarias
muchas reuniones y varias iteraciones hasta cerrar los requisitos detallados.
Ahora bien, una vez conseguidos, estos requisitos detallados sern el cuerpo principal del alcance del proyecto.
Los requisitos de alto nivel los fijan los stakeholders, que no tienen por
qu estar familiarizados con la ingeniera de sistemas ni de requisitos. Es
labor del ingeniero de sistemas darles precisin y expresarlos debidamente
sin cambiar el sentido original. Para hacer esto bien hay que utilizar el lenguaje, y utilizarlo bien [Alexander y Stevens, 2002]. Este aspecto es crtico,
sobre todo en proyectos internacionales en que no se utiliza la lengua materna, pero tambin ocurre en la propia lengua.
Los stakeholders utilizan el lenguaje natural, el cual no es suficiente para
especificar requisitos adecuadamente. A continuacin se dan diez reglas de
cmo deben ser los requisitos, y cmo deben redactarse.
a) Requisitos claros: un requisito debe ser fcil de leer y entender. Son
preferibles las frases cortas, concisas y sencillas, de manera que se
47
mejore la comunicacin y la retencin de las ideas importantes. Algunas recomendaciones:
Escribir los requisitos como frases afirmativas

Identificar al responsable de realizar la accin
Utilizar un vocabulario limitado. Crear glosario de trminos
No utilizar abreviaturas ni acrnimos (salvo si estn en el glosario)
No utilizar frases que indican excepciones como excepto, a menos
que, pero, etc.
b) Requisitos atmicos: cada requisito debe especificar una sola necesidad o caracterstica. Se recomienda:
Identificar cada requisito con un cdigo nico.
No utilizar conjunciones como y, o.
Minimizar el uso de listas numeradas y tablas, pues es preferible
que cada elemento de la lista o de la tabla constituya un requisito.
c) Requisitos no ambiguos: un requisito debe tener una nica interpretacin. Para esto es importante que no sea subjetivo y que no exista
informacin omitida. El lenguaje utilizado debe ser tal que sea comprensible por todos aquellos que deben leerlo y que el entendimiento de todos ellos sea el mismo.
Se recomienda evitar trminos imprecisos o subjetivos como los
siguientes:
Sujetos indefinidos: voz pasiva o pronombres que no dejen claro
quin realizar lo descrito en el requisito
Adjetivos o adverbios imprecisos como por ejemplo adecuado,
rpido, normal, caliente, mucho, cerca
Otros trminos imprecisos como por ejemplo etc., entre otros, varios, si es posible.
El mismo concepto, sistema o idea debe aludirse siempre con el mismo trmino, evitando el uso de sinnimos y de trminos con varios
significados.
d) Requisitos demostrables: para todos los requisitos debe poder comprobarse su cumplimiento, bien mediante inspeccin, anlisis, demostracin o prueba. No es posible declarar que un sistema es correcto
si los requisitos no son demostrables, y por tanto la aceptacin por el
usuario se ver comprometida o sujeta a criterios no objetivos.
Existen requisitos no demostrables porque estn redactados de forma
ambigua (Ejemplo: La aplicacin mostrar la planificacin en un
48
e)
f)
g)
h)
i)
tiempo aceptable). En este caso ser necesario redactar el requisito de

forma no ambigua, para conseguir que sea demostrable.
Sin embargo, en otros casos los requisitos no son demostrables porque no es posible definir un mtodo de validacin o ste es impracticable por el coste implicado, tiempo u otros. En este caso ser
necesario definir criterios de aceptacin para el requisito.
Requisitos necesarios: un requisito debe trasladar las necesidades de
los usuarios o las obligaciones impuestas por el cumplimiento de
un estndar o las necesidades de integracin con sistemas externos,
etc. En definitiva debe incorporar lo que realmente son necesidades.
Para evitar incluir requisitos no necesarios se recomienda plantearse
las consecuencias de no incluir el requisito y considerar los costes
asociados a ellos.
Requisitos independientes del diseo: los requisitos a alto nivel deben definir qu es necesario, y no cmo ha de conseguirse. Si los
requisitos fuerzan un diseo concreto en vez de determinar las necesidades reales, se impide poder escoger la mejor solucin a estas
necesidades.
Cuando el usuario introduce un requisito no independiente del diseo est condenado a obtener lo que ha pedido. Tomemos como
ejemplo el requisito: el sistema se bloquear al presionar el botn de
bloqueo. Es realmente necesario un botn de bloqueo? El requisito
tal y como est redactado descarta alternativas mejores sin tan siquiera llegar a considerarlas. Yendo al porqu de los requisitos junto con
el usuario, pueden aflorar las verdaderas necesidades subyacentes,
que pueden dar lugar a mejores soluciones.
Requisitos factibles: los requisitos deben ser viables tcnicamente
y alcanzables teniendo en cuenta las restricciones del proyecto en
cuanto a recursos: tiempo, coste, equipo necesario, etc. No tiene sentido escribir requisitos que no se pueden cumplir.
Requisitos completos: cada requisito individual debe tener un significado completo en s mismo sin que exista informacin importante
que se encuentre omitida.
Se recomienda especificar los requisitos con el mayor nivel de detalle del que se disponga en cada fase del proyecto, indicando Pendiente de definir en aquellos aspectos que se desconozcan en cada
momento.
Requisitos correctos: cada requisito debe contener informacin correcta documentada correctamente. Los defectos en los requisitos se
propagan al resto de las fases del sistema. Se recomienda revisar los
requisitos con las personas que los han generado, para que stas validen su correccin.
49
j) Requisitos trazables: los requisitos deben estar relacionados tanto con

la fuente que los ha originado como con los elementos posteriores
que los implantan, o los verifican. Es decir, debe existir trazabilidad
aguas arriba y aguas abajo de un requisito. La trazabilidad posibilita
la identificacin de desviaciones e inconsistencias y facilita la implantacin de cambios. Se recomienda identificar los requisitos con un
cdigo nico.
Adems de que cada requisito de forma individual tenga las propiedades
descritas con anterioridad, es necesario que los requisitos como conjunto
renan tambin una serie de caractersticas.
El conjunto de requisitos debe ser completo. Si no lo es, el sistema no
estar completo, o bien los requisitos aparecern tarde en el ciclo de vida
causando problemas al proyecto. Adems los requisitos deben ser coherentes entre ellos. Si existen requisitos incoherentes, el sistema no podr
cumplirlos todos y el proyecto no podr finalizar con xito.
El conjunto de requisitos debe estar gestionado de tal manera que sea
modificable, puesto que los requisitos, aunque no es deseable, pueden
cambiar a lo largo de la vida del proyecto, y priorizable, puesto que no
todas las caractersticas que se quieren para un sistema son igualmente
importantes.
A lo largo del proyecto deber realizarse un seguimiento de los requisitos, la gestin de los cambios en los requisitos y la verificacin de su
cumplimiento. Los requisitos que se establecen al inicio del proyecto no se
mantienen invariables durante el desarrollo del proyecto. Unas veces dejan
de ser importantes y se puede prescindir de ellos, otras veces cambian,
otras se comprueba que nunca sern alcanzables por imposibilidad tcnica
o incompatibilidad con otros requisitos, y muchas veces surgirn requisitos
nuevos. Todos estos casos implicarn un impacto en el alcance del proyecto, ya sea en aspectos tcnicos, de coste o plazo. Conviene contar con un
procedimiento de seguimiento y control de requisitos que permita tener
trazabilidad de todos y cada uno de ellos durante el proyecto, existiendo
herramientas informticas que facilitan esta tarea.
5. CONTENIDO DEL ALCANCE DEL PROYECTO

El alcance del proyecto debe contener toda la informacin necesaria
para delimitar el mismo, describiendo claramente lo que cae dentro del
proyecto de forma inequvoca, y lo que hay que hacer para completarlo
con xito. Adems el alcance del proyecto cumple las siguientes funciones:
describir en detalle los productos entregables del proyecto, incluyendo los
requisitos asociados que deben cumplir; proporcionar una referencia para
50
el entendimiento comn del proyecto entre los stakeholders; describir los

principales objetivos del proyecto; permitir al equipo del proyecto realizar
una planificacin ms detallada; guiar el trabajo del equipo del proyecto
durante la ejecucin; proporcionar la lnea base para evaluar si las solicitudes de cambio o trabajo adicional estn comprendidas dentro o fuera de
los lmites del proyecto.
El alcance detallado del proyecto incluye, ya sea de forma directa o mediante referencia a otros documentos, los siguientes contenidos:
a) Los objetivos del proyecto. Los proyectos pueden tener una amplia
variedad de objetivos de negocio, de costes, de calendario, tcnicos
y de calidad. Cada objetivo del proyecto tiene atributos (ej. el coste),
una mtrica (ej. euros), y un valor absoluto o relativo (ej. menos de
1.000 ). En cierto modo los objetivos son requisitos de alto nivel y
gran relevancia en el proyecto.
Objetivos tcnicos. Los objetivos tcnicos del proyecto van asociados generalmente a las caractersticas o funciones que tiene que
cumplir un producto o servicio. Estos objetivos darn lugar a un
conjunto de requisitos tcnicos cada uno.
Objetivos econmicos. Estos objetivos describen aspectos econmicos del proyecto, como coste total, precio unitario, coste de
mantenimiento anual, etc.
Objetivos de calendario. Estos objetivos se refieren a plazos y fechas en el proyecto.
Objetivos de calidad. Estos objetivos inciden principalmente sobre
los procesos y procedimientos, y las caractersticas del producto
final. Suelen basarse en normas y regulacin existentes.
b) Requisitos de proyecto. Los requisitos del proyecto pueden agruparse
en dos grandes bloques: los requisitos de los entregables (productos), y los requisitos de gestin del proyecto. Los primeros son los
que se derivan de todos los stakeholders, mientras que los segundos
se establecen normalmente por el equipo del proyecto.
Los requisitos del producto describen las condiciones que deben
cumplir o las caractersticas que deben tener los entregables del proyecto para satisfacer un contrato, norma, especificacin o cualquier
otro documento formalmente impuesto. Estos requisitos deben recoger la totalidad de las necesidades, deseos y expectativas de todos los
stakeholders, y en la medida de lo posible estar priorizados. Como
parte de cada requisito se describir su mtodo de verificacin, incluyendo tipo de test o prueba a realizar, evaluaciones, participacin
en pruebas de validacin del cliente, criterios de aceptacin, etc. El
conjunto de estos criterios relativos a cada producto entregable cons-
51
tituir los criterios de aceptacin del producto. Si no se establecen

claramente estos criterios a nivel entregable surgirn disputas respecto al cumplimiento o no del producto o servicio con los requisitos.
Adicionalmente pueden incluirse, como criterios de aceptacin del
producto, por ejemplo su instalacin en localizaciones predefinidas,
o la imparticin de cursos de formacin a los usuarios.
Los requisitos de gestin del proyecto se establecen para facilitar la
gestin del mismo, y entre ellos se encuentran, por ejemplo, los requisitos de gestin de la configuracin del proyecto, los requisitos de
aprobacin aplicables a objetivos, productos entregables, documentos y trabajo del proyecto, requisitos del WBS, etc.
c) Lmites del proyecto: inclusiones y exclusiones. Se debe identificar
claramente qu est incluido dentro del proyecto. Tambin conviene
escribir explcitamente qu est excluido del proyecto, para eliminar
posibles interpretaciones de que un producto, servicio o resultado en
particular podran ser un componente del proyecto. Este aspecto es
muy importante, pues la descripcin de lo que incluye un proyecto, no siempre deja claro lo que excluye, dando lugar a disputas. Si
ocurre esta circunstancia, el cliente exigir que el proveedor haga el
trabajo por el precio pactado, y el proveedor exigir un cambio de
alcance e incremento del coste para hacerlo. En la figura 2.8 se ilustran los lmites del proyecto.
Figura 2.8. Lmites del proyecto.
d) Entregables del proyecto. Normalmente se denomina entregables

a los productos que recibe el cliente como resultado del proyecto.
Por ejemplo, en un proyecto de desarrollo de vehculos, el prototipo,
los vehculos finales, la documentacin tcnica asociada, cursos de
52
conduccin y cursos de mantenimiento. Adems, en el alcance del

proyecto debe identificarse todo aquello que se deba generar en el
proyecto para completarlo, aunque no sea entregable al cliente. En
el ejemplo anterior podran ser: informes mensuales de progreso,
estudios tecnolgicos, resultados de las pruebas del prototipo, rbol
de configuracin del vehculo, etc.
As pues, desde el punto de vista del alcance del proyecto, los entregables incluyen tanto las salidas que comprenden el producto o
servicio del proyecto, como los resultados y documentos de gestin
que estn recogidos en el alcance del proyecto, tales como informes,
estudios y documentacin de la gestin del proyecto.
e) Restricciones del proyecto. Todo proyecto tiene alguna limitacin
o restriccin, y deben identificarse, enumerarse y describirse. Las
restricciones especficas del proyecto estn asociadas al alcance del
proyecto y pueden limitar las alternativas para acometer el proyecto.
Ejemplos de restricciones pueden ser un presupuesto predefinido o
fechas impuestas (hitos del cronograma) emitidos por el cliente o el
proveedor. Cuando un proyecto se realiza bajo un contrato, generalmente las disposiciones contractuales actuarn como restricciones.
Por ejemplo, el cliente o el proveedor pueden identificar hitos y
pueden colocar fechas impuestas en los hitos del cronograma. Igualmente, el cliente o el proveedor impondrn restricciones en el presupuesto del proyecto. Se debe describir cualquier limitacin aplicada a
la financiacin del proyecto, ya sea en cuanto al valor total o durante
perodos especficos.
f) Hiptesis del proyecto. Se deben enumerar y describir las hiptesis
especficas del proyecto asociadas con el alcance del proyecto y el
potencial impacto de tales hiptesis si resultan ser falsas. Los equipos
del proyecto frecuentemente identifican, documentan y validan las
hiptesis como parte de su proceso de planificacin.
6. DESCOMPOSICIN ESTRUCTURADA DE TAREAS (WBS) DEL PROYECTO

WBS es el acrnimo del trmino anglosajn Work Breakdown Structure, que significa Descomposicin Estructurada de Tareas (DET), o Desglose Estructurado del Trabajo (DET). Se utilizarn en lo que sigue las siglas
WBS, por estar ya muy extendido su uso, y haber sido aceptadas internacionalmente. Hay discrepancia entre los distintos autores sobre si el WBS
forma parte o no del alcance del proyecto. Una parte dice que no, pues argumentan que el alcance del proyecto termina con los requisitos detallados,
y que el WBS se genera a continuacin, como paso previo a la planificacin
53
del proyecto. Otros autores dicen que el WBS forma parte del alcance, pues
sirve para definir la delimitacin del trabajo que forma parte del proyecto,
excluyendo el resto. La verdad es que es difcil aislar requisitos, alcance,
WBS y planificacin, pues suelen solaparse en cuanto a su elaboracin se
refiere, siendo el WBS el puente entre requisitos y planificacin, y que puede considerarse o no como requisito del gestin del proyecto.
El WBS del proyecto es una descomposicin jerrquica del trabajo que
deber ser ejecutado para lograr los objetivos del proyecto y crear los productos entregables requeridos. El WBS organiza y define el alcance total
del proyecto, subdividiendo el trabajo del proyecto en porciones de trabajo
ms pequeas y fciles de manejar, donde cada nivel descendente representa una definicin cada vez ms detallada del trabajo del proyecto. El
trabajo planificado comprendido dentro de los componentes del WBS del
nivel ms bajo puede programarse, supervisarse, controlarse y estimarse
sus costes. El primer nivel suele denominarse Paquete de Trabajo (Work
Package - WP), pasndose luego a actividades, tareas y subtareas en los
niveles subsiguientes, dependiendo del nmero de niveles necesario.
Antes de generar el WBS, lo primero que debe hacerse es identificar todas las tareas que ser necesario realizar en el proyecto. Primero se identifican, y luego se genera el WBS, es decir, se estructuran, se relacionan, se les
asignan recursos, coste, etc. En este captulo se va a profundizar solamente
en la identificacin y estructuracin de las tareas.
El diagrama de la figura 2.9 ilustra una descomposicin genrica de un
proyecto, con la jerarqua de tareas ilustrada a travs de un sistema de codificacin del WBS.
El WBS representa el trabajo especificado del alcance del proyecto. Los
elementos que conforman el WBS ayudan a los stakeholders a ver cmo se
alcanzarn los productos entregables del proyecto.
54
Figura 2.9. WBS genrico con ejemplo de numeracin de tareas.
55
La creacin del WBS generalmente implica las siguientes actividades:

Identificar los productos entregables y el trabajo relacionado.
Estructurar y organizar el desglose de tareas.
Descomponer los niveles superiores del desglose en componentes
detallados de nivel inferior.
Desarrollar y asignar cdigos de identificacin a los componentes.
Verificar que el grado de desglose de tareas es necesario y suficiente.
Cada actividad o tarea debe poseer seis caractersticas para considerarse
completa:
Su estado debe ser medible: en cualquier momento se debera poder
determinar el estado de avance en que se encuentra.
Debe estar acotada: debe poseer eventos de comienzo y fin.
Debe producir un entregable: el entregable es un signo visible de que
la actividad se ha completado, y puede ser un producto, un documento, la autorizacin para continuar con la prxima tarea, etc.
El tiempo y coste deben ser fcilmente estimables: el hacer esto para
las tareas de menor nivel permite luego agregar y calcular el coste y
tiempo total del proyecto.
La duracin debe ser aceptable: en lo posible no trabajar con tareas
demasiado largas.
Debe ser independiente: es importante que cada actividad sea independiente. Una vez que se comience, que pueda continuar razonablemente sin interrupciones y sin la necesidad de entradas nuevas. El
esfuerzo debe ser continuo.
Adems del propio WBS y acompaando a ste, conviene generar el
documento denominado diccionario del WBS. El contenido detallado de
los elementos que se incluyen en el WBS, incluidos los paquetes de trabajo,
deben describirse en el diccionario del WBS. Para cada elemento, el diccionario incluye un identificador de cdigo de tarea, un enunciado del trabajo,
la organizacin responsable de realizarlo y una lista de hitos del cronograma. Cada elemento del WBS tiene en el diccionario una referencia cruzada,
segn corresponda, a otros elementos del WBS. El alcance detallado del
proyecto, incluyendo su WBS y el diccionario relacionado, constituyen la
lnea base del alcance del proyecto.
A menudo se centra el WBS en las tareas tcnicas para llegar al producto
o sistema. Hay que recordar que las tareas de gestin son igualmente importantes y que deben identificarse y desglosarse tambin como parte del
WBS.
Estos trabajos de gestin incluyen la planificacin del proyecto, la gestin
de Ingeniera de Sistemas, el seguimiento y control (reuniones, informes,
56
mtricas de control, control de calidad, control de costes, etc.), las tareas

administrativas (facturacin, gestin de personal, registro), etc. Estas tareas
de gestin a nivel proyecto deben diferenciarse de otras tareas de gestin
asociadas al diseo, desarrollo, fabricacin y pruebas del producto.
7. CONTROL Y SEGUIMIENTO DEL ALCANCE

Los cambios son inevitables en el desarrollo de un proyecto, por lo
cual es necesario establecer un proceso de control de cambios en lo que
se refiere al alcance del proyecto. De este modo se limita el impacto de dichos cambios y se asegura que tanto los cambios solicitados y las acciones
correctivas recomendadas son procesados y gestionados adecuadamente.
En el captulo 8 del libro se aborda todo lo relacionado con el seguimiento
y control de un proyecto, y como parte de esta actividad se contempla el
seguimiento del alcance del proyecto.
Para realizar el control de los cambios en el alcance del proyecto puede
establecerse un sistema de control de cambios dentro del plan de gestin
del proyecto en el que se definan los procedimientos para modificar el alcance del proyecto o del producto. Se incluir la documentacin necesaria
y las aprobaciones necesarias para autorizar los cambios, que pueden ser
de varios niveles en funcin del tipo y magnitud de los cambios.
El sistema de gestin de la configuracin facilita el control del alcance
del proyecto al proporcionar procedimientos para conocer el estado de los
productos entregables. Si existen desviaciones respecto a la lnea base del
alcance del proyecto ser necesario detectar su causa y decidir si son necesarias acciones correctoras. Es posible que las desviaciones o los cambios
aprobados requieran una replanificacin del alcance que afecte incluso al
desglose de tareas del WBS. En el captulo 13 se trata en profundidad la
gestin de la configuracin, y lo que ah se recoge es aplicable al alcance
del proyecto, que debe considerarse siempre como un elemento de configuracin del proyecto.
8. VERIFICACIN DEL ALCANCE DEL PROYECTO

La verificacin del alcance es el proceso por el cual se obtiene la aceptacin formal de los stakeholders sobre el alcance del proyecto completado
y los productos entregables relacionados. Verificar el alcance del proyecto
incluye revisar los productos entregables para asegurarse de que cada uno
se ha completado satisfactoriamente. El proceso de verificacin del alcance
57
del proyecto debe establecer y documentar el nivel y alcance de lo completado.

La verificacin del alcance se diferencia del control de calidad en que la
verificacin del alcance se relaciona principalmente con la aceptacin de
los productos entregables, mientras que el control de calidad se relaciona
principalmente con cumplir los requisitos de calidad especificados para los
productos entregables. Por lo general, el control de calidad se realiza antes
de la verificacin del alcance, pero estos dos procesos pueden realizarse en
forma paralela.
9. REFERENCIAS
BLANCHARD, B. S., System Engineering Management, 4th ed., John Wiley & Sons,
Hoboken, NJ, 2008.
FREEMAN, R. E., Strategic Management: A Stakeholder Approach, Pitman, Boston,
1984.
IAN, A. and STEVENS, R., Writing Better Requirements, Addison-Wesley, 2002.
IAN, S. and SAWER, P., Requirements Engineering: A Good Practice Guide, Wiley,
1997.
SAGE, A. P. and ROUSE, W. B. (eds.), Handbook of System Engineering and Management, John Wiley & Sons, Hoboken, NJ, 1999.
58
CAPTULO 3
TCNICAS DE PLANIFICACIN DE PROYECTOS

Alberto Sols Rodrguez-Candela y Adriana Molero Alonso
1. INTRODUCCIN
El objetivo de este captulo es mostrar tanto las principales tcnicas de
planificacin de los proyectos como las principales estrategias de gestin de
riesgos. En el captulo 1 del libro se habl de la importancia de establecer
con precisin el objetivo del proyecto. En el segundo captulo se trat en
detalle la definicin del alcance del proyecto y su divisin en tareas, que se
agrupan en la denominada descomposicin estructurada de tareas. En este
captulo se identifican las principales tcnicas que pueden emplearse para
planear la ejecucin de las tareas identificadas.
En demasiadas ocasiones se comienza a trabajar con ms entusiasmo
que acierto, por aquello de ir adelantando y ganando tiempo, an sin saber realmente qu se quiere hacer, cmo y por qu. Ese desconocimiento
del objetivo perseguido con el proyecto y/o de la manera de alcanzarlo a
travs de la ejecucin de las necesarias tareas hace que completarlo con
xito, en plazo y forma sea prcticamente un milagro, ya que el citado desconocimiento lleva a tomar acciones innecesarias o, siendo necesarias, a
tomarlas en la forma o momento no adecuados, lo que inevitablemente se
traduce en ineficacias e ineficiencias. Por ello es vital pensar primero y actuar despus, lo que implica que antes de actuar hay que elaborar un plan
de trabajo del proyecto que refleje quin debe hacer qu, de qu manera,
con qu recursos y en qu momento. La elaboracin del plan del proyecto
es una condicin necesaria pero no suficiente, pues no hay garanta de que
59
las tareas vayan a poder desarrollarse de la manera prevista ya que podr

haber errores en la estimacin de recursos necesarios, o podrn presentarse
dificultades con las actividades o suministros de terceras partes, o surgirn
otras dificultades imprevistas. Ello implica que adems de elaborar un plan
para el proyecto ser necesario identificar los riesgos que puedan presentarse, evaluar tanto su probabilidad de ocurrencia como la posible severidad
de sus consecuencias, y adoptar las adecuadas estrategias de mitigacin
para eliminarlos o, al menos, paliar sus consecuencias.
2. TCNICAS DE PLANIFICACIN DE PROYECTOS

Es bien sabido que la fiabilidad del ser humano, entendida como la probabilidad de que sea capaz de llevar a cabo con xito una tarea encomendada, depende de mltiples aspectos como son su formacin, la definicin
del trabajo encomendado y la responsabilidad que se le asigne, adems
de otros aspectos como su motivacin y su grado global de satisfaccin a
definicin del trabajo a realizar y de los objetivos perseguidos es condicin
sine qua non para lograr alcanzarlos de manera efectiva y eficiente. Si no
se define con detalle y precisin qu debe realizar en cada tarea, ser poco
menos que imposible que la persona a la que se asigne esa tarea la lleve
a cabo con xito. La satisfaccin y motivacin de la persona dependen en
parte de factores exgenos a la empresa, como pueden ser las circunstancias personales de cada uno, pero tambin dependen, en gran medida,
de decisiones que se adoptan en el contexto de la empresa o del equipo
del proyecto; es responsabilidad bsica del jefe del proyecto crear el clima adecuado en el que todos los integrantes se sientan satisfechos con su
pertenencia al equipo y con la suficiente motivacin como para aportar sus
mejores esfuerzos y conocimientos de manera integrada y coordinada con
el resto del equipo del proyecto.
Uno de los errores ms habituales en la gestin de proyectos es no definir adecuadamente el trabajo que debe ser realizado por una persona o
equipo, lo que antes o despus se traduce en prdidas de tiempo ante las
necesarias peticiones de clarificacin de los trabajos a ser realizados e, incluso, puede dar lugar a tareas que se ejecuten indebidamente y deban ser
rehechas, con la consiguiente prdida de tiempo y esfuerzo, todo lo cual
implica un aumento de las ineficiencias del proyecto. En el captulo 2 ya se
trat a fondo el tema del alcance del proyecto y de su descomposicin en
tareas, que constituyen los cimientos del proyecto.
Existen diferentes tcnicas de planificacin de proyectos. En general
se dividen en las tcnicas de representacin de actividades por barras y
60
en las tcnicas de representacin de redes de actividades. Para ilustrar sus

conceptos y aplicaciones se va a emplear un ejemplo. Para seguir el ejemplo y entender las tcnicas de planificacin de proyectos no es necesario
estar familiarizado con ningn sector industrial determinado ni poseer
ciertos conocimientos tcnicos; el ejemplo permite ilustrar la aplicacin de
unos mtodos que, contados slo de manera terica, resultaran demasiado abstractos. Considrese una empresa que fabrica tarjetas electrnicas
y que resulta adjudicataria de un contrato para fabricar 10.000 unidades
de un determinado modelo. El cliente otorga el contrato, pero supeditado
a la aprobacin en un plazo determinado de la denominada prueba de
primer artculo (first article inspection), en la que se le demuestre que
el contratista est en condiciones de realizar con xito la fabricacin en
serie de las tarjetas encargadas porque dispone de los medios humanos y
materiales necesarios y porque ha puesto en marcha con xito los procedimientos internos necesarios de fabricacin y prueba. La empresa tiene
experiencia en la fabricacin de tarjetas electrnicas pero la nueva a ser
fabricada supone un importante reto, pues requerir inversiones importantes tanto en contratacin y formacin de personal como en adquisicin
de nuevas mquinas que permitan mejorar la efectividad y eficacia del
montaje y prueba de las tarjetas. Por ello, antes de poder fabricar las tarjetas contratadas la empresa necesita llevar a cabo una importante reforma
de su taller, incrementando su capacidad tanto en los medios humanos
como en los materiales. Se pone por tanto en marcha un proyecto interno
cuyo objetivo es reforzar la plantilla tanto en cantidad como en capacitacin y adecuar los medios materiales del taller para poder llevar a cabo
con xito la fabricacin de las tarjetas contratadas. El proyecto interno se
considerar finalizado cuando se cuente con los medios humanos y materiales necesarios y se haya contrastado que se est en condiciones de
fabricar y probar las tarjetas en cuestin.
Lo primero que hace el jefe de proyecto es, a partir del objetivo establecido, identificar todas las tareas que deben ser llevadas a cabo para
cumplirlo. Unas tareas estarn relacionadas con el refuerzo de la plantilla
del taller en cantidad y cualificacin, otras ser relativas a la adquisicin y
puesta en marcha de nuevas mquinas necesarias, otro bloque de tareas
ser el de preparacin de los manuales requeridos, y finalmente habr
un ltimo grupo de tareas referentes a la validacin del nuevo taller,
certificando internamente su disponibilidad para comenzar la fabricacin
en serie de las tarjetas contratadas. Las tareas necesarias para reforzar y
acondicionar el taller de tarjetas electrnicas y dejarlo preparado para
acometer con xito la fabricacin en serie de las tarjetas contratadas se
muestra en la figura 3.1.
61
Figura 3.1. Descomposicin estructurada de las tareas necesarias para reforzar y acondicionar el taller de tarjetas
electrnicas.
62
A continuacin se explica brevemente el propsito de cada una de las

tareas identificadas. Respecto a las tareas relacionadas con el personal:
a) Contratacin de personal, pues se considera que sern necesarios
ms tcnicos para montar, probar y examinar visualmente las tarjetas.
Ser necesario identificar la cualificacin, formacin y experiencia
previa requerida de las personas que vayan a ser contratadas.
b) Formacin de personal, ya que ser necesario que tanto el existente
como el contratado sea formado en el uso de las nuevas mquinas
a ser adquiridas. Ser necesario identificar la formacin que deber
impartirse tanto al personal existente como al contratado, en funcin
del que actualmente posean y del necesario para utilizar las nuevas
mquinas que se pondrn a su disposicin.
c) Certificacin de personal, ya que las nuevas contrataciones que no
posean ya la certificacin IPC A 610 de criterios de aceptacin o rechazo de tarjetas electrnicas debern recibir la formacin necesaria
para que lo puedan obtener. Por estrategia de empresa y por imagen
ante el cliente que ha encargado las nuevas tarjetas se decide que
todo el personal se acredite segn la citada norma, por lo que la formacin indicada anteriormente deber ir adems encaminada a logar
dicho objetivo.
Los objetos de las tareas relacionadas con la adquisicin de medios materiales son:
a) Compra y puesta en marcha de una pick&place automtica, ya que
la actual pick&place manual resulta lenta y poco precisa. La nueva
mquina reducir de forma dramtica tanto el tiempo de posicionado de los componentes montados en superficie como los rechazos
que se den por montaje incorrecto. Sin embargo su programacin es
complicada, por lo que se requerir jun completo curso de formacin
ad-hoc.
b) Compra y puesta en marcha de un horno fase vapor, ya que la actual
mquina de soldadura por ola no permite controlar con precisin
la temperatura y adems genera un calor uniforme sobre la placa y
algunos componentes no se sueldan correctamente, al tiempo que
otros se calientan en exceso; en el horno fase vapor la temperatura
es absolutamente controlable y es homognea en toda la superficie
de la placa.
c) Compra y puesta en marcha de un sistema de pruebas funcionales
in-circuit test (ICT), ya que el banco de pruebas actual no ofrece
la capacidad de pruebas requerida y adems el ICT permite realizar previamente al chequeo funcional el Manufacturing Defect
Analysis (MDA), que certifica que cada componente montado en
63
la placa sea el que debe ser y, si tiene polaridad, que est montado
correctamente.
Las tareas relacionadas con el desarrollo de documentacin deben alcanzar los siguientes objetivos:
a) Elaboracin del manual de montaje que permita la fabricacin de
las tarjetas con las mquinas adquiridas y las aplicables de las ya
existentes.
b) Elaboracin del manual de pruebas que permita la comprobacin
funcional de las tarjetas con el nuevo banco ICT.
c) Desarrollo sobre el ICT adquirido del protocolo de pruebas funcionales de la tarjeta, segn el manual de pruebas elaborado.
Finalmente, las tareas relacionadas con la validacin del taller respecto a
su capacidad para que las tarjetas sean fabricadas y probadas satisfactoriamente tienen por propsito:
a) Validacin de la fabricacin, consistente en fabricar un lote de tarjetas
siguiendo el manual de montaje previamente elaborado.
b) Validacin de la funcionalidad, consistente en fabricar un lote de
tarjetas siguiendo el manual de montaje previamente elaborado.
En las siguientes sub-secciones se van a exponer los conceptos de cuatro de las principales tcnicas de planificacin de proyectos y se mostrar
cmo se realizara la planificacin de las tareas del ejemplo considerado
de proyecto de refuerzo y acondicionamiento de un taller de fabricacin y
prueba de tarjetas electrnicas. Las tcnicas de planificacin de proyectos
han sido descritas en numerosas referencias [Haugan, 2002; PMI, 2008; Meredith et al., 2009].
2.1. Diagramas de Gantt
Henry L. Gantt se gradu en 1883 en el Stevens Institute of Technology y
en 1903, trabajando para la American Locomotive Company, ide un sistema
de representacin de tareas mediante barras en las que en el eje vertical se
mostraban las tareas a ser realizadas y en el eje horizontal la escala de tiempos
para su realizacin. Su mtodo de representacin de tareas fue rpidamente
adoptado en numerosos sectores industriales y especialmente durante la Primera Guerra Mundial, quedando aos despus completamente documentado
[Wallace, 1922]. En un diagrama de Gantt las barras de las actividades comienzan en el instante ms temprano en el que la actividad puede comenzar,
y terminan en el instante ms temprano en el que puede terminar.
Para el ejemplo considerado de proyecto interno de refuerzo y acondicionamiento de un taller de fabricacin de tarjetas electrnicas, y conside-
64
rando que el tiempo necesario para el desarrollo de todas las tareas sera de
17 semanas, la planificacin de tareas empleando la forma ms simple de
un diagrama de Gantt sera la mostrada en la figura 3.2.
Los diagramas de Gantt presentan numerosas ventajas, as como algunos
importantes inconvenientes o limitaciones; las principales se muestran en
la tabla 3.1.
Ventajas
dan una idea visual fcil de comprender
del alcance del proyecto, de las tareas
necesarias y de las escalas de tiempos.
son fciles de preparar y de actualizar.
son relativamente poco costosos de preparar
usando simples herramientas informticas.
permiten agrupar fcilmente la informacin
de bloques de tareas.
permiten reflejar con distinto nivel de
sombreado de las barras el grado actual de
avance en un momento dado.
constituyen un primer y til paso para
preparar planificaciones ms detalladas y
complejas.
permiten realizar estimaciones fiables
cuando los trabajos son repetitivos y
cuando el producto es fcil de medir
cuantitativamente.
Inconvenientes
no representan las dependencias
entre tareas tan adecuadamente
como
otras
tcnicas
de
planificacin de proyectos.
son complicados de utilizar para
anlisis detallados de calendario.
no muestran los efectos de
comienzos
adelantados
o
retrasados de las tareas.
no reflejan la incertidumbre
existente en la duracin prevista
de las tareas.
no permiten un rpido y fcil
anlisis de las consecuencias de
acciones alternativas.
no
reflejan
fcilmente
los
recursos humanos necesarios y/o
comprometidos en cada tarea.
Tabla 3.1. Principales ventajas e inconvenientes de los diagramas de Gantt.
2.2. Program Evaluation and Review Technique (PERT)

El mtodo Program Evaluation and Review Technique (PERT), o Tcnica
de Revisin y Evaluacin de Programas, fue desarrollado por la Oficina de
Proyectos Especiales de la Armada norteamericana en colaboracin con
Booz, Allen y Hamilton para planificar y controlar el programa de misiles
POLARIS, en el que se contaba con ms de 250 contratistas principales y
ms de 9.000 subcontratistas, lo que da una idea de su complejidad. Los
diagramas PERT son redes en las que las actividades se representan en los
nodos, indicndose adems el tiempo requerido para su culminacin. La
figura 3.3 muestra el diagrama de redes del proyecto interno de refuerzo y
acondicionamiento del taller, reflejando el tiempo requerido para completar
cada tarea.
65
Figura 3.2. Diagrama de Gantt.
66
Figura 3.3. Diagrama PERT del proyecto interno de refuerzo y acondicionamiento del taller, reflejando el tiempo
requerido para completar cada tarea.
67
En un diagrama PERT se considera que el tiempo para completar las

tareas es una variable aleatoria. Una de sus caractersticas bsicas es que
se requiere identificar las relaciones de precedencia entre las tareas. Es un
aspecto importante que no resulta cmodo de mostrar en los grficos de
Gantt; en los diagramas PERT s se hace explcito qu tareas deben terminarse antes de poder comenzar qu otras. El especificar el tiempo requerido para completar cada tarea permite realizar anlisis sobre el tiempo
total requerido para completar el proyecto. Es posible especificar adems el
intervalo de tiempos tanto para el comienzo como para la terminacin de
cada actividad, ya que muchas tareas pueden tener limitaciones en ese sentido, ya sean derivadas de aspectos internos al proyecto o externos. En el
ejemplo considerado, la certificacin de personal segn la norma IPC A610
slo podr realizarse cuando existan convocatorias oficiales al efecto, lo
que se traduce en una ventana de tiempo. Podra igualmente ser que para
las tareas de Validacin de la Produccin y Validacin del Test Funcional,
que debern ser llevadas a cabo por personal del Departamento de Calidad,
existan limitaciones de tiempo debidas a la disponibilidad del personal del
departamento indicado, por lo que habr de ser tenido en cuenta para no
perder esa ventana de disponibilidad de su tiempo.
En los diagramas PERT el tiempo se trata como una variable aleatoria.
Es una tcnica de planificacin muy apropiada para proyectos en los que
exista incertidumbre en la estimacin de tiempo requerido para realizar las
diferentes tareas. Para tratar esa incertidumbre de manera pragmtica se
especifican para cada tarea tres tiempos:
1. Tiempo optimista. Es el tiempo mnimo o ms corto posible en el
cual es probable que sea terminada una actividad si todo resulta perfecto; se simboliza con la letra a.
2. Tiempo ms probable. Es el tiempo que esta actividad sea ms probable que lleve el realizarla (sera la media de los tiempos de ejecucin
mltiples veces de la tarea); se simboliza con la letra m.
3. Tiempo pesimista. Es el tiempo mximo o ms largo posible en el
cual es probable sea terminada una actividad bajo las condiciones
ms desfavorables; se simboliza con la letra b.
A partir de esos valores se calcula el denominado tiempo esperado para
una actividad, que es el valor ponderado (a+4m+b)/6. En ocasiones resulta
necesario u oportuno agilizar al mximo el proyecto, tratando de completar
cada tarea en el menor tiempo posible mediante la concentracin en su realizacin de todos los recursos disponibles. Ese tiempo que llevara completar la tarea de forma agilizada o acelerada se denomina tiempo acelerado.
La tabla 3.2 muestra las tres estimaciones de tiempo para cada tarea, sus
tiempos esperados, varianza y desviacin estndar.
68
Tiempo (semanas)
Ms
probable
(m)
Tiempo
esperado
(TE)
Optimista
(a)
110
1,50
2,00
3,00
2,08
0,06
0,25
120
3,00
4,00
5,50
4,08
0,17
0,42
130
1,00
1,00
1,00
1,00
0,00
0,00
211
1,75
2,00
2,25
2,00
0,01
0,08
212
0,75
1,00
1,50
1,04
0,02
0,13
221
1,75
2,00
2,50
2,04
0,02
0,13
222
0,50
1,00
1,50
1,00
0,03
0,17
231
1,50
2,00
2,50
2,00
0,03
0,17
232
2,25
3,00
4,00
3,04
0,09
0,29
310
3,25
4,00
4,75
4,00
0,06
0,25
320
2,50
3,00
3,50
3,00
0,03
0,17
330
3,25
4,00
4,50
3,96
0,04
0,21
411
2,50
3,00
3,75
3,04
0,04
0,21
412
1,25
2,00
2,50
1,96
0,04
0,21
Pesimista
(b)
Varianza
Desviacin
estndar
Tarea
Tabla 3.2. Tiempos de las tareas del proyecto.
Para cada tarea se indican, como se muestra en la figura 3.4, el tiempo

esperado, la varianza, el tiempo de inicio ms temprano posible, el tiempo
de inicio ms tardo posible, el tiempo de finalizacin ms temprano posible y el tiempo de finalizacin ms tardo posible. A la diferencia entre el
tiempo de inicio ms temprano posible y el tiempo de inicio ms tardo posible se le denomina holgura de la tarea. El conjunto serial de tareas que
constituyen globalmente el tiempo ms largo representa el tiempo mnimo
en el que puede completarse el proyecto; a esas tareas se les denomina
camino crtico y en ellas no puede haber holgura (de haberlo el proyecto
sufrira retraso).
69
Figura 3.4. Representacin de tiempos de una tarea en un diagrama PERT.
Con los tiempos indicados en la tabla 3.2 el diagrama PERT quedara

como se muestra en la figura 3.5; para no sobrecargar la figura slo se
muestran los tiempos de inicio y finalizacin de las tareas que forman el
camino crtico (que resulta ser el definido por las tareas 231-232-320-330412) y el de una rama del proyecto, la definida por las tareas 110-120-130,
a modo de ejemplo. Para calcular los tiempos ms tardos de finalizacin se
comienza por el final del proyecto y se va hacia atrs, fijando el tiempo ms
tardo de finalizacin de la tarea inmediatamente anterior, y a partir de ese
tiempo y el tiempo esperado de la tarea se determina el tiempo ms tardo
de inicio; esa lgica se sigue hacia atrs, hacia la tarea precedente, hasta
llegar al inicio del proyecto. Para determinar los tiempos ms tempranos de
inicio y finalizacin se sigue el orden inverso, comenzndose por el inicio
del proyecto y definiendo en primer lugar el tiempo ms temprano de inicio
de la primera tarea de la rama considerada.
70
Figura 3.5. Diagrama PERT del proyecto.
71
Las dependencias entre tareas vienen determinadas por las relaciones

entre sus comienzos y terminaciones y pueden ser Terminacin-Comienzo
(cuando el Comienzo de la tarea Sucesora depende de la Terminacin de la
tarea Predecesora), Comienzo-Comienzo (cuando el Comienzo de la tarea
Sucesora depende del Comienzo de la tarea Predecesora) y TerminacinTerminacin (cuando la Terminacin de la tarea Sucesora depende de la
Terminacin de la tarea Predecesora). En el ejemplo considerado, y con el
mayor nivel de detalle ofrecido para la Compra de la Pick&Place Automtica, la relacin entre las tareas Recepcin de ofertas (Predecesora) y Anlisis de ofertas (Sucesora) es del tipo Comienzo-Comienzo, pues en cuanto
se vayan recibiendo ofertas puede comenzar su anlisis. Por el contrario
la relacin entre las tareas Seleccin de oferta ganadora (Predecesora) y
Emisin del pedido (Sucesora) es del tipo Terminacin-Comienzo, pues
hasta que no se haya seleccionado la oferta ganadora no se podr emitir
el correspondiente pedido. La relacin entre las tareas Anlisis de ofertas
y Emisin del pedido es del tipo Terminacin-Terminacin, pues ambas
pueden llevarse en paralelo y en cuanto se concluya el anlisis de las ofertas puede emitirse el correspondiente pedido.
Los diagramas PERT presentan numerosas ventajas, as como algunos
importantes inconvenientes o limitaciones; las principales se muestran en
la tabla 3.3.
Ventajas
no se basan en una nica estimacin de duracin
de las actividades o tareas.
requieren la definicin pormenorizada de los
recursos que es necesario asignar a cada tarea
para completarla.
la definicin de relaciones de precedencia entre
tareas ayuda a identificar los interfaces entre ellas
y por tanto entre cliente y contratista, cliente
y proveedores o subcontratistas, y tambin los
internos de la organizacin del proyecto.
permiten realizar anlisis de sensibilidad del
tiempo requerido para completar un proyecto
ante variaciones sufridas por las tareas en alcance,
precedencias o asignacin de recursos.
permiten realizar fciles valoraciones del progreso
alcanzado en un momento dado.
permiten detectar de manera temprana posibles
problemas y causas de eventuales retrasos.
Inconvenientes
puede perderse perspectiva
del tiempo al centrarse
la visualizacin en las
relaciones de precedencia
entre tareas.
es fcil olvidar que pueden
existir desfases de tiempo
entre tareas.
para cada tarea se requieren
tres estimaciones de tiempo.
al tratarse el tiempo como
variable aleatoria lo que se
genera es una estimacin
del tiempo o plazo en el
que, con un cierto nivel de
confianza, se finalizar el
proyecto.
Tabla 3.3. Principales ventajas e inconvenientes de los diagramas PERT.
72
2.3. Critical Path Method (CPM)

El mtodo Critical Path Method (CPM), o Mtodo del Camino Crtico, es
similar al PERT, con la diferencia de que la duracin de las tareas se considera que es una variable determinista, y no aleatoria. El mtodo CPM fue
desarrollado tambin en Estados Unidos por parte de la Compaa DuPont
junto con la Divisin UNIVAC de la Remington Rand, para controlar el mantenimiento de proyectos de plantas qumicas de DuPont y optimizar tanto
el control como los costes de operacin mediante la planeacin efectiva y
eficaz de las actividades o tareas del proyecto. La esencia del mtodo CPM
es identificar la secuencia de tareas cuyo tiempo total de ejecucin sea el
ms largo. Esa secuencia de tareas constituye el llamado camino crtico y
define el menor tiempo en el que es posible completar el proyecto. Para el
ejemplo considerado, el diagrama CPM es el mostrado en la figura 3.6 en la
que las tareas que definen el camino crtico se muestran unidas por flechas
de trazo ms grueso que el resto.
73
Figura 3.6. Diagrama CPM del proyecto interno de refuerzo y acondicionamiento del taller, reflejando el tiempo requerido
para completar cada tarea.
74
Aparentemente, el tiempo mnimo requerido para completar el proyecto

son aparentemente 14 semanas, que es la suma de los tiempos necesarios
para completar las tareas del citado camino crtico. Sin embargo, en el
diagrama de Gantt se apreciaba que el tiempo requerido para completar el
proyecto eran 17 semanas. La razn de esa diferencia y aparente contradiccin radica en el hecho de que entre la terminacin de algunas tareas y
el comienzo de sus sucesoras existe una demora o desfase, que debe ser
considerado; esa demora es ms perceptible en los diagramas de Gantt y
requieren un smbolo adicional en los diagramas PERT o CPM. Las demora
entre el comienzo de una actividad y la terminacin de su predecesora se
representa mediante una barra gruesa superpuestas sobre la flecha que conecte ambas actividades. Con la representacin de las demoras o retardos
entre finalizacin de unas tareas y el comienzo de sus sucesoras se genera
el diagrama de la figura 3.7.
En un diagrama CPM el camino crtico viene definido por aquellas actividades o tareas que no tienen holgura. El jefe de proyecto debe centrarse
especialmente en las tareas o actividades que constituyen el camino crtico
para asegurar el cumplimiento de los objetivos del proyecto. Cualquier
retraso en el cumplimiento de una tarea o actividad del camino crtico se
traducir en un retraso en la terminacin del proyecto. Suele ser til, especialmente en proyectos grandes y complejos, identificar caminos prximos
al crtico, que seran los siguientes caminos crticos por razn del tiempo
requerido para la terminacin de sus tareas o actividades y por la poca
holgura existente en ellas. Los anlisis del camino crtico ayudan a identificar riesgos durante el proyecto y por tanto permiten la adopcin de las
medidas necesarias para eliminarlos o, al menos, mitigar sus posibles efectos. El camino crtico no tiene por qu permanecer invariable durante la
ejecucin del proyecto; el desarrollo de ciertas actividades puede dar lugar
a modificaciones en el camino crtico, al modificarse las escalas de tiempos
para completar ciertas tareas o actividades. Ello obliga a una monitorizacin
continua del estado del proyecto y a una eventual re-planificacin, teniendo
en cuenta entre otros el estado real de progreso de las tareas y las nuevas
estimaciones de tiempos necesarios para su ejecucin.
75
Figura 3.7. Diagrama CPM del proyecto interno de refuerzo y acondicionamiento del taller, reflejando tanto el tiempo
requerido para completar cada tarea como los retardos o demoras existentes entre algunas tareas.
76
Los diagramas CPM presentan numerosas ventajas, as como algunos

importantes inconvenientes o limitaciones; en su mayora coinciden, tanto
las ventajas como los inconvenientes, con los de los diagramas PERT. En lo
que se diferencian es en el tratamiento del tiempo, que es estocstico en los
diagramas PERT y determinista en los CPM. Eso significa que es ms fcil
realizar predicciones del tiempo mnimo requerido para terminar el proyecto si se emplea un diagrama CPM, pero ello requiere que pueda estimarse
con suficiente exactitud el tiempo requerido por cada una de las tareas del
proyecto. Por otro lado, ambos diagramas prestan excesiva atencin tanto
al tiempo como a las relaciones de precedencia entre tareas, y nada se indica en ellos de qu tareas representan los principales generadores de coste
del proyecto o cules estn ms directamente ligadas con el xito final bajo
la perspectiva de satisfaccin del cliente. En el ejemplo considerado podra
entenderse que las tareas relacionadas con el personal, en especial la contratacin, suponen una de las principales partidas de coste del proyecto, y
que el desarrollo del manual de montaje y del protocolo de pruebas estarn
muy ligados al grado de satisfaccin final del cliente con el producto recibido. Ni la tarea de contratacin de personal ni las de elaboracin del
manual de montaje estn en el camino crtico y, sin embargo, son importantes desde esos puntos de vista citados. La gestin integral de proyectos
supone por tanto mantener la visin de conjunto, con independencia de la
tcnica de planificacin que se haya seleccionado y de los aspectos que en
dicha tcnica resulten ms explcitos.
3. GESTIN DE RIESGOS
El objetivo de la gestin de riesgos es identificar y gestionar las amenazas ms significativas asociadas al proyecto. Se estructura en varias fases
y requiere una revisin y actualizacin peridicas enmarcndose dentro
de los anlisis de viabilidad del proyecto y es parte de la planificacin del
mismo.
La gestin de riesgos aplica a todo tipo de proyectos, independientemente de su rea, tamao, etc., pero es claro que a mayor factor de innovacin y originalidad, mayores sern los beneficios de aplicar una gestin
de riesgos sobre el mismo, contribuyendo a un mejor conocimiento del
proyecto, a entender cules son los factores que pueden afectar negativamente al mismo y de qu manera se pueden minimizar sus efectos. Es
un ejercicio, en sus primeras fases, bastante abstracto, incierto y con alto
componente terico, por lo que requiere un esfuerzo un tanto especulativo
de suposiciones y conjeturas que puede llegar a disuadir a los mandos de
su utilidad. Sin embargo, pasada la fase inicial, el ejercicio se esclarece y
77
concreta en hechos precisos vindose entonces el potencial de beneficios

que aporta. Adems de los evidentes a los cuales se har referencia ms
adelante, puede, por ejemplo, contribuir en la fase de licitacin a establecer
clusulas contractuales de sanciones asociadas a, precisamente, los riesgos
identificados. Esto a su vez es de gran ayuda a los contratistas para entender
mejor las contingencias del proyecto y as hacer una estimacin ms precisa
de la oferta.
3.1. Concepto de riesgo
Aunque todo el mundo tiene su propia idea del significado de riesgo,
conviene en primer lugar introducir el concepto de riesgo en el marco de
un proyecto: riesgo es cualquier hecho o circunstancia que, de materializarse, pueda poner en peligro el xito del mismo. Lo primero que debe llamar
la atencin al lector es que riesgo est ntimamente ligado con xito. Es
decir, sin un conocimiento de cul es el xito del proyecto, difcilmente se
podrn identificar y manejar los riesgos asociados a ste. Sobre este asunto
se volver ms adelante, pero es importante adelantar que es una de las
primeras dificultades con las que se encuentra el equipo de trabajo en las
fases iniciales de la gestin de riesgos: el ligar la amenaza con el xito del
proyecto.
La planificacin de un proyecto lleva consigo la gestin de los riesgos
inherentes al mismo. De ah que la gestin de riesgos se realice en las fases
preparatorias del proyecto, previamente, lgicamente, a su ejecucin. Sin
embargo es una actividad que se revisa y realimenta a medida que avanza
el proyecto y las circunstancias varan.
El resultado de la identificacin y evaluacin de riesgos, es decir, el plan
de gestin de riesgos, se incorpora a la fase de seguimiento y evaluacin
del proyecto, con idea de intervenir y modificar circunstancias adversas y
con el objetivo de mitigar los efectos que sobre el proyecto pudieran tener.
Por ejemplo, para modificar el diseo e incluso los requerimientos si fuera
necesario. Dicha solicitud de modificacin de cambios se integrara en el
proceso de control de cambios, con su consiguiente proceso de evaluacin,
aprobacin, etc. Lgicamente, si la gestin de riesgos comienza en una
fase avanzada del proyecto, la capacidad de actuacin se reduce a medida
que se progresa en el tiempo. Sin embargo hay amenazas que slo surgen,
o son conocidas, una vez que da comienzo la ejecucin del mismo; hay
desviaciones sobre la planificacin que se producen como consecuencia de
amenazas no detectadas y hay otras amenazas que slo se detectan tras una
auditora de calidad. De ah la relevancia de hacer un continuo seguimiento
y gestin de los riesgos, porque de nuevo, cuanto antes se identifiquen las
amenazas y se ponga en marcha un plan de mitigacin, mayor ser la ca-
78
pacidad de contribuir a la supresin de la ocurrencia del hecho, si fuera el

caso, o a la atenuacin de sus efectos perjudiciales para la consecucin de
los objetivos del proyecto.
En definitiva, la gestin de riesgos es un proceso continuo, que aunque
es conveniente iniciarlo lo antes posible, se puede comenzar en cualquier
fase del proyecto. Se debe hacer mientras se perciba que los cambios en
las circunstancias que rodean al proyecto son de relativa envergadura, y
siempre y cuando el beneficio que se obtenga del proceso sea mayor que
el coste del mismo.
3.2. Origen y tipo de riesgos
Como se ha mencionado, los riesgos, por definicin, interfieren en la
consecucin de los objetivos del proyecto. Atendiendo a la naturaleza de
estos objetivos: tiempo, coste, alcance, calidad, etc., se pueden clasificar los
riesgos. As pues, puede haber riesgos de tipo tcnico, financiero, humano,
etc.
a) Riesgos financieros. Los ms comunes son los asociados a la financiacin del proyecto (variacin en los tipos de inters), al tipo de
cambio y/o a la inflacin en compra de suministros o en la comercializacin de los productos o servicios, etc. Tambin riesgos asociados
a la disponibilidad de crdito, muy comn en tiempos de crisis.
b) Riesgos laborales, asociados a la salud y seguridad: accidentes, enfermedades o molestias del personal trabajador: radiaciones, ruidos,
temperaturas extremas, vibraciones, inhalaciones e ingestiones de
qumicos, estrs, monotona, desgaste psquico, etc.
c) Riesgos ambientales, asociados a situaciones accidentales ligadas a
la actividad empresarial, que pueden causar daos tales como contaminacin fsica o qumica del medioambiente, sujetas a regulacin
europea, y que pueden llevar asociadas sanciones administrativas.
d) Riesgos asociados al tiempo, como por ejemplo incumplimiento de
plazos de proveedores que ocasionen un retraso en la produccin y
ponga en peligro la venta de la mercanca.
e) Riesgos asociados a la estrategia del proyecto, a los competidores, al
comportamiento del cliente objetivo, a las innovaciones ofertadas por
el mercado, etc.
f) Riesgos operacionales, asociados al funcionamiento del sistema o
producto generado por el proyecto. Pueden llevar asociados riesgos
de salud y seguridad, pero lo habitual es que provoquen fallos que
dejan (total o parcialmente) inoperativo el sistema.
79
Dada la extensin y variedad de riesgos, se recomienda, pues, partir de

los objetivos y requerimientos del proyecto acotar y limitar los tipos de riesgos ms relevantes. Tambin es til agrupar los riesgos en base a la fase del
proyecto a la que afecten. No es lo mismo un riesgo que afecte a las especificaciones tcnicas del diseo (p.ej. encarecimiento de un determinado material que obliga a modificar las especificaciones del sistema) que un riesgo
que afecte a la fase de comercializacin (p.ej. escasa motivacin del equipo
de ventas que ralentice o ponga en riesgo alguna operacin mercantil).
3.3. Proceso de gestin de riesgos
La metodologa de la gestin de riesgos consta de sucesivas fases con
una revisin peridica y actualizacin para adaptar los resultados a los
cambios y nuevas circunstancias. La figura 3.8 representa grficamente las
principales fases de que consta la gestin de riesgos.
Figura 3.8. Fases del proceso de gestin de riesgos.
En definitiva, la gestin de riesgos trata de:

t
t
t
t
t
*EFOUJGJDBSMBTBNFOB[BT
"OBMJ[BSMPTSJFTHPT
&WBMVBSMPTFGFDUPTTPCSFFMQSPZFDUP
%FTBSSPMMBSVOBFTUSBUFHJB
&MBCPSBSVOQMBOEFHFTUJO
80
t 3FWJTBSQFSJEJDBNFOUFDBEBVOPEFMPTQVOUPTBOUFSJPSFT
Como en todo cometido enmarcado en un proyecto, existe una fase
previa al comienzo de la actividad per s, donde se sientan los fundamentos de la tarea a realizar, y que en el caso que nos ocupa determina
el marco de actuacin de la gestin de riesgos. Dicha fase se denomina
fase de planificacin:
3.4. Planificacin de la gestin de riesgos
En la etapa de planificacin se desarrollan las premisas sobre las que se
va a regir la actividad. Establece el contexto sobre el que se realiza la gestin de riesgos, los objetivos que se tratan de alcanzar, los recursos que van
a ser necesarios (humanos, materiales, herramientas, etc.), la periodicidad
con que se va a ejecutar y revisar el ejercicio, especifica los criterios contra
los que se van a evaluar las amenazas identificadas, plazos, etc. Lgicamente esta planificacin tiene que estar en lnea e integrada en la planificacin
del proyecto.
En resumen, el plan de gestin de riesgos desarrolla y documenta una
estrategia organizativa, completa e interactiva para la identificacin y seguimiento de las causas de los riesgos. Desarrolla planes de accin, ejecuta auditoras y asigna recursos a la vez que identifica las mtricas necesarias para
el control de la evolucin de los riesgos. La siguiente figura 3.9 representa
esquemticamente el proceso de planificacin.
Figura 3.9. Proceso de planificacin de la gestin de riesgos.
81
3.5. Identificacin de riesgos

La fase de identificacin determina qu amenazas pueden tener potencialmente un efecto adverso sobre alguno de los objetivos del proyecto. El
proceso de identificacin (figura 3.10) es crucial, pues muchas amenazas
no son evidentes y es conveniente, cuando hay falta de experiencia en
proyectos similares, hacer uso de tcnicas y metodologas establecidas que
a continuacin referiremos. Una vez identificadas las amenazas, se trata fundamentalmente de una tarea de recopilacin de informacin, descripcin
y documentacin de las amenazas y sus efectos. Esta suele ser una tarea
muy ardua y costosa en trminos de tiempo, pues a menudo no hay datos
disponibles y hay que hacer uso de referencias similares o elaborarlos internamente. La siguiente figura representa esquemticamente el proceso de
identificacin.
Figura 3.10. Proceso de determinacin de amenazas en la gestin de riesgos.
El registro de los atributos de los riesgos se suele hacer sobre una tabla,
y contiene habitualmente informacin sobre el tipo de amenaza y entorno
al que pertenece, objetivo al que impacta (si es conocido en sta fase inicial), una breve descripcin, la causa y el escenario o evento que lo puede
desencadenar y el responsable de su gestin. Las tcnicas de identificacin
ms efectivas son las siguientes:
a) Brainstorming: las sesiones de tormentas de ideas son una herramienta muy potente cuando no se dispone de experiencia en pro-
82
yectos similares. Identifica una amplia variedad de amenazas que

lgicamente luego requiere su posterior tarea de criba, y de las consideradas aptas, su clasificacin y ubicacin segn el rea del que
procedan o al que afecten.
b) Lessons learned: Recoge informacin y similitudes con proyectos
anlogos, lecciones aprendidas, datos histricos.
c) DAFO. Anlisis de carcter estratgico que establece los puntos fuertes o Fortalezas, las Debilidades, las Oportunidades y las Amenazas
de una determinada organizacin, proyecto, etc. Se compone de un
anlisis interno (fortalezas y debilidades) y de un anlisis externo
(oportunidades y amenazas). El anlisis DAFO aplicado al proyecto, adems de dar visibilidad del entorno del mismo, debe ser la
base para establecer la estrategia, para confrontar las debilidades
y amenazas detectadas y aprovechar las oportunidades y fortalezas
identificadas.
d) rbol de anlisis de fallo y Anlisis de modos de fallo (FTA y FMECA en su nomenclatura anglosajona) referida a proyectos de diseo,
produccin, instalacin y operacin de sistemas y equipos tcnicos
y se centra en el funcionamiento del sistema en s ms que en la
evolucin del proyecto mismo. FMECA y FTA son dos tcnicas complementarias que abordan los posibles fallos del sistema de abajo a
arriba y de arriba abajo respectivamente.
Para la identificacin de amenazas medioambientales existen mltiples
listados que enumeran, dependiendo de la actividad de la empresa, las
amenazas al medioambiente. Adems la normativa europea enumera cules
son las amenazas sujetas a legislacin.
83
3.6. Evaluacin
La evaluacin de riesgos trata de estimar la probabilidad de materializacin de la amenaza, y los efectos sobre el xito del proyecto. El producto de
ambos factores se denomina severidad del riesgo. La figura 3.11 representa
esquemticamente el proceso de evaluacin de riesgos:
Figura 3.11. Proceso de caracterizacin de riesgos en la gestin de riesgos.
Como se ha apuntado al principio, es importante tener en cuenta que para

determinar los efectos, es primordial definir el objetivo del proyecto, el xito del proyecto, definiendo el alcance y el mbito del anlisis de riesgos. De
esta manera los efectos estn acotados y nicamente se tratarn los que estn
circunscritos dentro de dicho mbito. Por ejemplo, en el caso de una empresa
de generacin y distribucin de energa elica, no es lo mismo valorar las
amenazas sobre la visin de la empresa (p.ej. Ser lderes a nivel nacional,
en la generacin de energa elica), sobre la estrategia (p.ej. Construir una
red de generadores elicos fiables a mnimo coste) o sobre un objetivo especfico de un programa (p.ej. disponibilidad media anual de los sistemas de
generacin elica de un 82%). Ocurre con frecuencia que al valorar el efecto
de cada una de las amenazas obtenidas con la tcnica del brainstorming, no
se halle ningn efecto adverso sobre los objetivos del proyecto sobre los que
se est haciendo el ejercicio de la gestin de riesgos. En principio pareca que
dicha amenaza era evidente, sin embargo al contrastarlo con los objetivos del
proyecto, no se no encuentre ningn efecto adverso.
84
Por otro lado, la evaluacin de riesgos puede ser cualitativa o cuantitativa, pero slo se puede hacer una evaluacin cuantitativa si existen datos de
probabilidad que la permitan, y si es factible cuantificar el efecto. Esto no es
siempre as, y de ah que se acuda a tcnicas de evaluacin cualitativa como
las que a continuacin se detallan. Estas tcnicas establecen escalas para
caracterizar ambas variables, probabilidad de suceso y efecto, y son extremadamente tiles pues permiten una catalogacin y enumeracin de los riesgos,
que servir posteriormente de entrada al proceso de mitigacin de riesgos.
La asignacin de una probabilidad se hace con ayuda de una matriz de
probabilidades (tabla 3.4), asignando valores a cada amenaza, y con una
matriz de efectos (tabla 3.5), que asigna valores asociados al efecto de la
materializacin de la amenaza, agrupados por reas.
Probabilidad
Valor
5
4
3
2
1
Probabilidad de ocurrencia (p)

Cierto
p > 80%
Altamente probable
60% < p 80%
Probable
40% < p 60%
Baja probabilidad
20% < p 40%
Improbable
p 20%
Tabla 3.4. Cuantificacin de la probabilidad de ocurrencia
Continuando con el ejemplo de los aerogeneradores, la probabilidad

de rotura de una pala de un aerogenerador por impacto de un meteorito,
atendiendo a la tabla, se puede estimar como 1. Para cuantificar el efecto
sobre la disponibilidad del sistema (rea operacional), el rango sera probablemente de 3 pues provocara que la disponibilidad de la unidad est por
debajo del objetivo establecido (82%) pero, sin embargo, la disponibilidad
de la red completa no se habr visto seriamente afectada. Como ya se ha
mencionado, una amenaza al materializarse puede causar daos o efectos
en ms de un campo y por ello es importante identificar cada una de las
reas de alcance del dao y valorar su efecto de modo independiente. La
tabla 3.5 puede servir como referencia en estos casos.
Siguiendo con la tcnica matricial de cuantificacin del riesgo, el valor
final para la estimacin de la severidad del riesgo (probabilidad x efecto)
que se debe tomar es el mayor entre todos los identificados. Si, por ejemplo, un riesgo puede producir un dao irreversible sobre la seguridad del
personal (5 = prdida de vidas humanas), aunque sobre el resto de reas
los efectos adversos sean muy inferiores, siempre se tomar el valor 5 como
el correspondiente a consecuencias.
85
EFECTO
1
Incapacidad
para alcanzar
un objetivo
particular pero
los objetivos
no afectados
representan una
parte suficiente
del xito
Incapacidad
para alcanzar
mltiples
objetivos pero
an un mnimo
de xito puede
ser logrado
Incapacidad
para alcanzar
mltiples
objetivos de
manera que
no se puede
justificar ni
siquiera un
mnimo xito
Molestia o
malestar
Incidente de
primeros auxilios,
conforme
a criterios
del OSHA
(Occupational
Safety and Health
Administration)
No hay lesiones
o enfermedades
que causen
baja, conforme
a criterios del
OSHA
Lesiones o
enfermedades
que causan
baja, conforme
a criterios del
OSHA
Prdida de vidas
humanas
Consecuencia
mnima: no
existen signos de
daos fsicos en
los activos
Consecuencia
menor: daos
cosmticos
reparables
Consecuencia
menor: existen
daos pero son
reparables
Consecuencia
mayor: los
activos estn
sustancialmente
daados pero
los daos son
reparables
Prdida total.
Destruccin que
compromete la
recuperacin de
activos
Consecuencia
mnima
Impacto menor.
La desviacin
con respecto a
la programacin
es inferior a diez
das
No existe
desviacin
importante con
respecto a la
programacin
Indeterminacin
dentro de
un rango de
diez das con
respecto a la
programacin.
Programacin
comprometida
Programacin
comprometida.
Uno ms de
un hito no se
pueden alcanzar.
Consecuencia
mnima
Consecuencias
menores.
Variacin coste >
5% del aprobado
para el ao fiscal
Variacin
coste>5% pero
10% del
aprobado para el
ao fiscal
Variacin coste
>10% pero <15%
del aprobado
para el ao fiscal
Consecuencias
mayores.
Variacin coste
>15% al total
aprobado para el
ao fiscal.
Seguridad
humana
Plan
Coste
Consecuencias
menores sobre
los objetivos
Operacin
Activos
Consecuencia
mnima sobre los
objetivos
Tabla 3.5. Cuantificacin de la amenaza sobre distintos aspectos del proyecto

[NASA, 2009].
86
3.7. Valorizacin y priorizacin

Una vez determinada la severidad del riesgo, se procede a elaborar una
lista priorizada de los riesgos con el fin de aplazar o dar preferencia a determinadas actuaciones de mitigacin de riesgos ms necesarias frente a
otras menos perentorias. Como caso ilustrativo, a continuacin se presentan
algunos criterios para la priorizacin de los riesgos enfocado a la gestin de
riesgos en la seguridad en el trabajo. Segn este criterio, prioritariamente
se atendern:
t -PTSJFTHPTNTTFWFSPT
t "OUFSJFTHPTEFMBNJTNBTFWFSJEBE BDUVBSTPCSFMPTRVFUJFOFONByor probabilidad de ocurrencia.
t "OUFSJFTHPTRVFJNQMJDBODPOTFDVFODJBTNVZHSBWFTZFTDBTBQSPCBbilidad de ocurrencia, actuar antes que sobre riesgos con mayor probabilidad de ocurrencia pero que implican consecuencias pequeas.
t &OGVODJOEFMONFSPEFUSBCBKBEPSFTFYQVFTUPT BDUVBSTPCSFMPT
riesgos que afectan a un mayor nmero de trabajadores.
t &OGVODJOEFMUJFNQPEFFYQPTJDJOEFMPTUSBCBKBEPSFTBMSJFTHP BDtuar sobre aquellos riesgos a los que los trabajadores estn expuestos
durante ms horas dentro de su jornada laboral.
3.8. Estrategias de mitigacin
El plan de mitigacin de riesgos determina las actuaciones necesarias
y los objetivos a alcanzar con respecto a cada riesgo. No es ms que un
plan de respuesta a los riesgos identificados y evaluados (figura 3.12). Para
cada riesgo se fija un objetivo de acuerdo no solo a su severidad, pero
tambin al contexto y a sus circunstancias particulares, de manera que,
como se apuntaba en la seccin anterior, para un riesgo de severidad alta
el objetivo puede ser evitar la manifestacin del efecto, o puede ser evitar
la materializacin del riesgo. Es decir, actuar sobre la probabilidad o actuar
sobre el efecto, dependiendo de cmo sea de factible cada una de las dos
opciones.
Por tanto, no necesariamente la respuesta del plan de mitigacin trata
de prevenir su aparicin, ni tan siquiera de evitar sus efectos, simplemente
puede ser la aceptacin del riesgo, determinar no hacer nada (run to failure), dejar que suceda. Esto suele ser comn en la fase operacional. Puede
darse el caso de un riesgo con severidad baja o muy baja, cuyo coste de
prevencin sobrepase el coste de materializacin de la amenaza (p.ej. en la
fase operacional, riesgo de lectura errnea de una variable de una funcin
auxiliar por avera de un piloto luminoso en el tablero de mando y control
en la gndola de un aerogenerador cuya reposicin o instalacin de un
87
sistema redundante implique la parada temporal del sistema. En ste caso

se decide esperar a una parada programada para actuar).
Existe una opcin, vlida en la gestin de riegos, que consiste en transferir el riesgo, normalmente por subcontratacin externa de los servicios a
los que va asociada la amenaza, aunque esto no es siempre posible. Otra
alternativa de transferencia de riesgo es la contratacin de una pliza de
seguros, aunque conviene resaltar que esta opcin slo sirve como medida
paliativa, de proteccin, para cubrir la prdida de activos una vez que se
materialice la amenaza, pero obviamente no tiene ningn efecto sobre la
probabilidad del riesgo o sobre otros efectos distintos de los econmicos.
En resumen, una vez categorizados y priorizados los riesgos, el comit o
el responsable de riesgos decide las medidas a adoptar para:
t
t
t
t
1SFWFOJSMBNBUFSJBMJ[BDJOEFMBBNFOB[B
%JTNJOVJSMBTFWFSJEBEEFMSJFTHP
"DFQUBSFMSJFTHPNBOUFOJOEPMPFOPCTFSWBDJO
5SBOTGFSJSFMSJFTHPBUFSDFSPTNFEJBOUFMBFYUFSOBMJ[BDJOEFMBUBSFB
asociada.
El plan de mitigacin de riesgos (figura 3.12) es pues el proceso de seleccionar las opciones e implementar las medidas para modificar el riesgo.
El tipo de precauciones y medidas que se toman frente a los riesgos est
intrnsecamente ligado a la naturaleza de la amenaza y a su severidad.
Figura 3.12. Proceso de contencin y prevencin de riesgos.
En lneas generales, en funcin de la estimacin que se haya hecho de

la magnitud del riesgo, en el tratamiento del riesgo se pueden dar cuatro
posibles situaciones:
1. El riesgo es intolerable y debe eliminarse.
2. El riesgo es elevado y debe reducirse.
88
3. Aceptacin del riesgo. El riesgo es bajo, por lo que no merece la

pena acometer medidas. El riesgo debe ser aceptado cuando o bien
las consecuencias de su aparicin son tolerables, o bien el riesgo
no puede ser razonablemente mitigado con ninguna accin, pero
tambin cuando, no habiendo riesgos para la salud, la razn coste/
beneficio desaconseje su tratamiento.
4. El riesgo es susceptible de ser transferido a una tercera entidad.
3.9. Seguimiento de gestin de riesgos
El Plan de Gestin de Riesgos debe de convertirse en un instrumento
dinmico de seguimiento y revisin peridica de riesgos. En el caso de
proyectos, se trata de una revisin peridica de los indicadores (KPI, Key
Performance Indicators) que dan idea de la evolucin del proyecto. Si
algn indicador se desva considerablemente de su valor objetivo es necesario analizar si este desvo est provocado por una errnea implementacin del plan de gestin de riesgos, por una inadecuada identificacin de
amenazas, o por cualquier otra circunstancia relacionada con la gestin
de riesgos.
En cualquier circunstancia, pero de manera especial en el caso de riesgos relacionados con la seguridad y la salud, y en caso de que haya
sucedido algn percance, es necesario incluir el resultado de las investigaciones de los accidentes, para poder identificar las causas inmediatas
y la posibilidad de repeticin, y tomar las medidas oportunas para evitar
nuevos accidentes.
4. REFERENCIAS
CLARK, W., The Gantt Chart, a Working Tool of Management, The Ronald Press
Company, 1922.
HAUGAN, G., Project Planning and Scheduling, Management Concepts Inc., 2002.
MEREDITH, J. y MANTEL, S., Project Management: A Managerial Approach, John Wiley & Sons, 2009.
PMI, A Guide to the Project Management Body of Knowledge, Project Management
Institute, 2008.
NASA, Guidelines for Risk Management, S3001, Revision B, 2009.
89
CAPTULO 4
TICA PROFESIONAL
Miguel Yaguez Prez
1. MARCO TERICO
En este captulo se pretende hacer reflexionar al jefe de un proyecto sobre la tica desde un punto de vista empresarial. Para ello, se va a profundizar sobre la definicin de tica de forma que,el responsable de un proyecto,
pueda tener en cuenta ciertas consideraciones no tcnicas, que sin embargo
podran hacer el proyecto inviable.
1.1. La tica. Concepto
De las cinco acepciones que la Real Academia Espaola (RAE) utiliza en
la definicin del vocablo tica, se van a analizar las dos que tienen ms
inters para ser consideradas por los jefes de un proyecto: la acepcin cuarta, define: parte de la filosofa que trata de la moral y de las obligaciones
del hombre. Y la quinta: conjunto de normas morales que rigen la conducta
humana. En esta acepcin la RAE aade: tica profesional. Si se analizan
estos dos significados, se puede concluir que la tica es una materia ligada
a la filosofa y que afecta al comportamiento de las personas.
Al hablar de personas se piensa de una manera inmediata en las personas fsicas, en los seres humanos, y aunque en este captulo se va a considerar principalmente el comportamiento de las personas fsicas, tambin se va
a mencionar el de las personas jurdicas, de las empresas y organizaciones
con nimo de lucro o sin l. Hay que tener presente, que la realizacin
91
de un proyecto no es ms que una parte de la actividad de una empresa

(en ocasiones toda la actividad) o si se prefiere se puede establecer que
la actividad empresarial es la suma de uno o varios proyectos realizados
coordinadamente. En el captulo 1 ya se indic lo que se consideraba como
proyecto y quienes pueden ejecutarlo. Ahora bien al hablar de tica de las
empresas u organizaciones, no se puede considerar el trmino sin tener en
cuenta la tica de los empleados de la empresa o la de las personas que
componen la organizacin, ya que la tica de la organizacin deriva del
comportamiento de esas personas que la componen o de los dirigentes que
establecen las pautas de actuacin en la empresa.
As, si se dice que el comportamiento de una empresa en particular
es poco tico, se est reflejando un sentimiento o una percepcin que la
sociedad tiene hacia esa empresa debido a algn acto que ha realizado y
que la sociedad no admite. Pero en realidad, dicho acto est promovido o
dirigido por personas de esa empresa y llevado a cabo por los empleados
de la misma. Por tanto la pregunta a plantearse es: Es la empresa poco tica
o lo son sus empleados? A lo largo de los prximos prrafos se va a tratar
de responder a esta pregunta.
En la acepcin de tica que la RAE une a tica profesional se mencionan las normas morales. Es decir se liga la tica a la moral. Para mejorar la
comprensin de ambos trminos (tica y moral) se ha de volver a la definicin que de ste ltimo establece la propia Real Academia Espaola de
la Lengua, eligiendo entre las diferentes acepciones del trmino la primera:
Perteneciente o relativo a las acciones o caracteres de las personas, desde
el punto de vista de la bondad o malicia. Por tanto se estn uniendo los
conceptos tica, moral y bondad o malicia.
Si se retoma el concepto de empresa u organizacin en general se
hace referencia a un conjunto de personas con unos medios materiales con
los que realizan una actividad que genera riqueza. Es precisamente esta
actividad la que puede realizarse con bondad o malicia o si se prefiere
de una manera tica o poco tica, moralmente aceptable o moralmente
rechazable. Lo que s es importante es que la sociedad entienda que es la
actividad de las empresas la que crea riqueza. Sin creacin de riqueza no
hay desarrollo posible.
Lo que es evidente es que la generacin de riqueza no debe realizarse de cualquier manera, vulnerando principios ticos. Pero quin define
cules son los principios ticos que no hay que vulnerar? En el mundo hay
diversas culturas, diversas costumbres y diversas creencias religiosas que
establecen normas ticas de actuacin y no puede utilizarse un criterio general para todos los mbitos o para todas las culturas. En la India, en una
reunin entre tcnicos espaoles e indios en el despacho de una fbrica se
detuvo la reunin porque uno de los espaoles mat una cucaracha dndo-
92
TICA PROFESIONAL
le un pisotn. Los indios rezaron por la prdida de una vida y los espaoles
hubieron de pedir perdn. Sin embargo, en esa misma fbrica, en donde se
trabajaba con plomo, obligaban a la persona que barra el suelo a hacerlo
en cuclillas, ya que el trabajo de barrer slo poda hacerlo una persona
que perteneciera a la casta de los parias, pero por pertenecer a esa casta su
cabeza no poda estar a la altura de la de los dems. El plomo depositado
en forma de polvo en el suelo pasara con ms facilidad a los pulmones del
trabajador y era seguro que contraera saturnismo (plomo en el cuerpo).
Desde un punto de vista tico, qu deberan hacer los espaoles en una
cultura totalmente diferente? Deberan aceptar la forma de trabajar que
imponan al paria? Habra que tratarlo como a los dems trabajadores y dotarlo de una escoba con palo que le permitiera barrer de pi, enfrentndose
as a los socios y al resto de trabajadores indios? Debera barrer la fbrica
una persona de otra casta y privar a los parias de la posibilidad de acceder
a un puesto de trabajo? La decisin que deban tomar no era fcil ya que
si aceptaban la forma de trabajar del barrendero lo condenaban a muerte y
si lo trataban como a los dems trabajadores podran incurrir en las iras de
los socios indios al tratar de cambiar un statu quo que llevaba funcionando
aos y que estaba impregnado en la cultura de ese pas. Los indios valoraban la situacin con unos principios ticos totalmente diferentes de los
que se tienen presentes en la cultura occidental. Finalmente la solucin que
adoptaron los espaoles fue respetar a los insectos y cambiar al barrendero
todos los meses para que no tuviera tiempo de contraer la enfermedad.
Incluso esta solucin podra ser discutible desde el punto de vista tico,
porque esa persona estaba condenada a perder un trabajo, simplemente
por pertenecer a una casta inferior.
Por tanto es necesario considerar al hablar de tica, que es un concepto
subjetivo. Es decir, cada persona tiene, en funcin de su educacin y de su
cultura, un concepto determinado de lo que es la tica y de lo que es tico y
lo que no lo es. Y, aunque las organizaciones estn formadas por personas,
no todas participan en la determinacin de la forma en que se van a hacer
las cosas en la empresa. Normalmente es la cpula de mando de la empresa
u organizacin la que establece la visin y los valores de la misma.
Y el primer planteamiento que se debe hacer, es conocer para quin se
hace el proyecto: Es un proyecto nico para el que se ha constituido un
equipo determinado? Se est trabajando en el seno de una empresa y se
va a realizar el proyecto desde all? Se ha constituido una UTE y hay que
hacer el proyecto para ella? Lgicamente es fundamental tener en cuenta
para quin se trabaja. Las empresas, las organizaciones en general, tienen
definida una visin (lo que quieren ser) de la que se deriva una misin (lo
que van a hacer para alcanzar la visin) y en base a lo anterior se definen
93
unos valores. Estas relaciones entre visin, misin valores y tica se muestran en la figura 4.1.
Figura 4.1. Relacin visin-tica
Cada vez hay ms empresas que tienen definidos sus valores y que los
dan a conocer entre sus empleados y sus clientes, proveedores, accionistas
y otros grupos sociales del entorno en el que desarrollan su actividad. Si el
proyecto se va a realizar para una empresa determinada es sencillo conocer sus valores (siempre que los hayan definido) y tenerlos en cuenta a la
hora de realizarlo. Si el proyecto se realiza para varias empresas (en forma
de UTE, como se comentaba anteriormente o mediante cualquier otro tipo
de asociacin) habr que conocer las visiones, misiones y valores de las
distintas empresas y tratar de buscar coincidencias y puntos de acuerdo en
donde no las haya. Si fuera preciso, habra que definir una visin de la UTE,
la misin derivada y establecer los valores.
Por tanto la definicin de los valores en los que se ha de basar la actividad para la realizacin del proyecto es el primer paso necesario para que
se desarrolle una misin que permita alcanzar la visin en unas condiciones adecuadas y, sobre todo, aceptadas por la empresa u organizacin. La
definicin de la visin, misin y valores da paso al cdigo tico que es un
documento en el que se detallan aquellos comportamientos que la organizacin espera de sus empleados. Este cdigo tico se suele distribuir entre
los distintos colectivos afectados por la actividad normal de la empresa y los
agentes externos de la sociedad donde se ubica sta, entre los que se podran
94
TICA PROFESIONAL
citar a las autoridades municipales, los responsables de seguridad en la zona,

etc. Con esta difusin la organizacin se asegura que las relaciones que mantiene o mantendr con todos los agentes con los que se relaciona o va a relacionarse, estarn guiadas por unos patrones de comportamiento encuadrados
en una forma determinada de hacer las cosas que se considera tica.
Se puede establecer que el desarrollo de la sociedad desde el punto
de vista empresarial se basa en tres soportes, generalmente denominados
agentes sociales. Por un lado estn las empresas. Los generadores de
riqueza. Pero estas empresas generan la riqueza con el trabajo de sus empleados, de donde surge la necesidad de otro agente social: Los sindicatos.
Estos han de vigilar que la actividad de las empresas no se haga vulnerando
los derechos de los trabajadores. De aqu la importancia de que los trabajadores estn representados por unos delegados que establezcan con la
empresa las condiciones en las que se basarn las relaciones trabajadores
empresario y vigilen el cumplimiento de las mencionadas condiciones.
Una vez que la empresa ha generado riqueza ha de ser justamente distribuida. Es evidente que los trabajadores han de tener una retribucin
econmica (y quiz de otra ndole), pero no slo se ha de retribuir a los
trabajadores. Los accionistas de la empresa tambin han de sentirse justamente retribuidos. Y ha de haber una parte importante de la riqueza que
se genera en las empresas que vaya destinada a la creacin de servicios
pblicos que mejoren la vida de los ciudadanos de la sociedad en la que la
empresa desarrolla su actividad, adems de proporcionar a la empresa unas
infraestructuras necesarias para que la empresa pueda desarrollar su actividad en condiciones aceptables. En la figura 4.2 se muestran las relaciones
mencionadas entre los agentes sociales.
Figura 4.2. Los agentes sociales.
95
Sin creacin de riqueza no seran precisos los sindicatos, pues no habra

nada que vigilar, ni los poderes pblicos, pues no habra nada que repartir.
Si se acepta la premisa de la creacin de riqueza, hay que volver necesariamente al concepto tica. Cmo generan la riqueza las organizaciones o las
empresas? Lo hacen mediante un comportamiento tico? Cmo vigilan los
sindicatos la posible vulneracin de derechos de los trabajadores mientras
generan riqueza en la empresa? Lo hacen con comportamientos ticos?
Cmo establecen los poderes pblicos la parte de la riqueza generada por
la empresa que van a distribuir? Cmo la distribuyen posteriormente? Lo
hacen estableciendo unas normas ticas? En las siguientes secciones se tratar de dar respuesta a estas preguntas.
2. LA TICA Y LA EMPRESA
En este apartado se van a mencionar los principios ticos que han de
regir la generacin y reparto de la riqueza que se genera, ya que una parte
de esa riqueza ha de ir a los empleados de la misma, es decir a los trabajadores que desarrollan la actividad empresarial. Hay que tener en cuenta
no solo la retribucin econmica de los trabajadores sino tambin otros
tipos de retribucin, a veces intangible, que los empleados precisan para el
correcto desarrollo profesional y personal. Formacin, carrera profesional,
conciliacin de las vidas familiar y laboral, etc. son aspectos importantes de
la distribucin de riqueza que se genera. Pero otra parte de la riqueza ha
de ir a los accionistas de la empresa. stos se tienen que sentir justamente
retribuidos por la inversin que han realizado, pues si piensan que no estn
correctamente retribuidos, podran retirar la inversin y poner a la empresa
en dificultades de continuidad con las consecuencia nocivas que eso tiene
para los empleados. Y finalmente los poderes pblicos modulan las retribuciones de accionistas y empleados exigiendo el pago de impuestos con
los que deben atender a las necesidades de infraestructuras, lo que se suele
denominar las atenciones sociales (pensiones, sanidad, educacin) y de
seguridad.
Y nuevamente aqu la tica tiene un papel fundamental en todos los
niveles. La generacin de la riqueza tiene que ajustarse a unos principios
ticos bsicos. La empresa est obligada (y no debera estarlo nicamente
por la legislacin) a tener un comportamiento respetuoso con la seguridad
de sus empleados en el trabajo y a respetar el medio ambiente en todas
sus facetas de la actividad. Si consideramos un proceso productivo hay que
pensar que todo proceso tiene un origen y un final en la naturaleza. Se extraen materias primas que son transformadas en equipamiento que ayuda a
realizar tareas. Ya en esta extraccin es preciso tener en cuenta cmo se va
96
TICA PROFESIONAL
a hacer para no daar el medio ambiente. Pero si al disear el equipo no se

proyecta convenientemente cmo va a reabsorber la naturaleza el equipo
cuando alcance el fin de su vida til, se estar actuando sin tener en cuenta
las demandas de la sociedad en el campo medioambiental. Sin embargo,
la sociedad no va a pensar que estn atentando contra el medioambiente
sino que por no respetar el medioambiente no tienen principios ticos. En
la figura 4.3 se muestra el proceso productivo y las posibles repercusiones
del mismo en la naturaleza
Figura 4.3. Proceso general de produccin.
Tambin es preciso que la vigilancia que los sindicatos deben hacer sobre la actividad empresarial y, especialmente, sobre aquellos aspectos que
97
afecten a la seguridad y a la dignidad de los empleados, se realice siguiendo unos principios ticos. Y es evidente que los principios ticos bsicos
deberan regir en las actuaciones de los Poderes Pblicos de manera que
se proporcione la seguridad y tranquilidad necesarias para la creacin de
riqueza en la empresa.
2.1. Razones para una tica empresarial
Una de las razones (al menos la ms frecuente) que una empresa puede
tener para disponer de un cdigo tico que le permita actuar de una manera
determinada en la que primen los valores definidos por la empresa, es la
fidelizacin del cliente. Y aqu ha aparecido por vez primera el elemento
bsico de la creacin de riqueza: el cliente. Sin clientes no hay empresa y,
por tanto, no hay creacin de riqueza. El cliente es en el que la empresa ha
de enfocar su manera de ser, lo que hace, su actividad. Sin un cliente que
quiera pagar por el trabajo que desarrolla la empresa para fabricar un bien
o para prestar un servicio, la empresa no tiene razn de ser.
El cliente va a exigir que aquello por lo que paga est realizado conforme a unas especificaciones que l define (explcita o implcitamente). Si la
empresa es capaz de proporcionar al cliente el bien o el servicio que ste
solicita y en las condiciones que precisa, el cliente volver, se fidelizar, hablar bien de la empresa y la demanda del producto que fabrica o servicio
que presta aumentar. Y esto ocurre cuando la empresa busca mejorar sistemticamente sus sistemas de gestin, entrando en un proceso de cambio
continuo en busca de la excelencia empresarial. Excelencia empresarial que
ha de contemplar una serie de principios ticos. Pero si el cliente se siente
engaado, y el engao ya representa una falta de tica, no volver, hablar
mal de la empresa, pondr en guardia a otros clientes que buscarn alternativas para proveerse del producto que precisan. Es decir la falta de tica
en la empresa afecta negativamente a la rentabilidad de la misma. Como
se coment anteriormente, no es la empresa la que acta con falta de tica
cuando engaa al cliente: son sus directivos y/o empleados.
Si la propiedad o la direccin de la empresa no establecieran un cdigo
tico y exigieran su cumplimiento, los empleados de la empresa tendran
que actuar en funcin de sus propios criterios o conciencias, lo que permitira que la imagen de la empresa hacia el mercado se deteriorara o, en
el mejor de los casos, no estuviera clara para los clientes potenciales. Si la
propiedad o la direccin de la empresa establecen un cdigo tico no basta
quedarse en eso. Hay que difundirlo y preocuparse de hacerlo cumplir, no
slo estableciendo normas, sino predicando con el ejemplo. Si lo incumplen deliberadamente, el cdigo tico deja de servir para su propsito y si
hubiera algn empleado deshonesto que actuara sin seguir los principios
98
TICA PROFESIONAL
del mismo, el dao a la organizacin puede ser importante y afectar no slo

a los que lo incumplen sino a todos los componentes de la organizacin.
2.2. El administrador y la tica
Siguiendo la lnea de argumentos trazada en la Subseccin anterior,
debe haber, por todo lo expuesto, al frente de las empresas personas cuyos
actos se guen por principios ticos. Y al frente de las empresas estn las
personas que deciden los directivos y los dueos de las mismas, sus socios
o accionistas. Por ello, estos principios ticos deben guiar el proceso de
seleccin de los directivos.
Ichak Adizes estableci hace aos [Adizes, 1988], que las organizaciones
tienen determinados ciclos de vida (lo defini como el ciclo PAEI) y que los
responsables de las mismas han de tener presente cuatro funciones gerenciales que son producir (P), administrar (A), emprender (E) e integrar (I). Es
decir, las virtudes que debe poseer un director (entendiendo por director
toda persona que detenta un cierto grado de responsabilidad en la empresa) son las mencionadas anteriormente. Pero es necesario aclarar el significado completo que comprenden dichas funciones gerenciales. La funcin
producir no se refiere tanto a la produccin como a buscar resultados.
Y no solamente se produce en la planta de fabricacin, sino que produce
la secretaria que contesta a un telfono o escribe una carta. Igualmente
produce el contable cuando hace asientos en los libros de contabilidad o
emite pagars. Es decir es la funcin que permite conseguir el QU de la
organizacin y por tanto es la que proporciona eficacia. Es decir las cosas
se hacen. Pero no basta que se hagan ya que hay que seguir los principios
ticos al hacerlas. Por tanto aunque un director ha de tener presente la obtencin de resultados no puede obtenerlos de cualquier manera.
La funcin administrar no se refiere slo a lo que debe hacer el departamento de administracin, sino que administra todo aqul que sigue unas
normas, unos protocolos, unos manuales, el cdigo tico de la organizacin. Por tanto un operario que produce piezas en una mquina est administrando si las produce de acuerdo con las especificaciones establecidas.
La secretaria que escriba la carta estaba administrando si segua las normas
dadas por el manual de identidad visual corporativa, o el contable administra cuando los apuntes los hace conforme al Plan General de Contabilidad.
Es decir esta funcin gerencial es la que define el CMO tiene que hacer
las cosas la organizacin y por tanto proporciona la eficiencia. Es decir las
cosas se hacen al menor coste posible y teniendo en cuenta las consecuencias de hacerlo de una manera u otra. Por tanto aunque un director debe
establecer normas para realizar un trabajo, esas normas tienen que respetar
unos principios ticos.
99
La funcin gerencial emprender es la que precisa un gestor para anticiparse al cambio. Es la que est relacionada con la innovacin. Emprende
todo empleado que presenta sugerencias, que propone modos diferentes
para hacer las cosas. Es el que no se escuda en el aqu siempre se han
hecho las cosas as. Es la funcin gerencial que permite responder al PORQU? se hacen las cosas en la empresa. Y al igual de las anteriores cuando
se trata de innovar, de investigar, hay que tener presentes ciertos principios
ticos. Cuando se empez a investigar sobre las clulas madres se suscit
una fuerte polmica entre partidarios y detractores. Ambos grupos argumentaban cuestiones ticas para hacer valer sus posturas.
Y, finalmente est la funcin integrar. Esta funcin gerencial es la que
se ocupa de atender al factor humano en la organizacin. Es la que procura
la motivacin, la formacin, los planes de carrera, la fidelizacin de los empleados, la conciliacin de las vidas familiar y laboral, etc. Es en definitiva
la funcin que responde al QUIN. Y la motivacin y fidelizacin de los
empleados no va solo en funcin de su salario sino de ciertos principios
ticos, de ciertas normas morales en las que creen y que no quieren que
sean vulneradas en la empresa para la que trabajan.
Las dos primeras funciones gerenciales (producir y administrar) son las
que aseguran el corto plazo de la empresa ya que proporcionan los resultados y establecen normas de actuacin que permiten realizar el trabajo actual,
mientras que las dos segundas aseguran el largo plazo ya que la innovacin
permite nuevos desarrollos y la motivacin y formacin de las personas permiten afrontar el futuro con bases ms slidas. En la figura 4.4 se resumen
estas funciones gerenciales y lo que representan en la empresa.
Figura 4.4. Las funciones gerenciales segn I. Adizes.
100
TICA PROFESIONAL
Por tanto, en todas y cada una de las cuatro funciones gerenciales ha de

estar presente la tica. Todo lo que se hace como respuesta a lo que demanda cada una de las funciones generales ha de estar impregnado de unos principios ticos relacionados con los valores definidos por la organizacin.
2.3. La tica de la empresa en el mercado
La actividad de la empresa est orientada hacia el cliente, tal como ya
se ha apuntado. Al cliente hay que localizarle, informarle de manera que
entienda el mensaje que se le quiere enviar, y generar en l el deseo de
que adquiera el servicio o producto que ofrece la empresa. Pero la empresa
no est sola en el mercado sino que hay otras empresas tratando de que el
cliente los elija como proveedores. Por tanto no queda ms remedio que
hacer frente a los competidores haciendo llegar al cliente el mensaje necesario para que elija nuestro producto frente al de la competencia. cuando
se lanza un mensaje informando al cliente sobre las caractersticas del producto que se fabrica se van a establecer unas relaciones con dos grupos de
inters en el mercado:
t $POMPTDPNQFUJEPSFT&MDMJFOUFWBBDPNQBSBSMBTEJTUJOUBTPQDJPnes que se le presenten reflexionando sobre lo que ms le conviene.
Lo primero que hay que hacer es informar al cliente de la empresa
y de los productos que fabrica o servicios que proporciona. Y aqu
juega un papel fundamental la publicidad. Sin la publicidad el cliente no podr incluir el producto de la empresa en la valoracin que
pueda hacer, simplemente porque no la conoce. Pero la publicidad
ha de estar basada en la verdad. Si cuando se informa del producto
se miente, ms temprano que tarde se descubrir la mentira (los competidores van a poner un empeo especial en que as se haga) y los
efectos en el mercado van a ser nocivos. Por otro lado, tampoco es
tico hablar mal del competidor. Hay que respetarle, pero haciendo
nfasis en las propias caractersticas.
t $POFMQCMJDP:DVBOEPTFIBCMBEFMQCMJDP OPOFDFTBSJBNFOUF
coincide con el cliente, ya que hay pblico que no es cliente. Si el
producto que se pone en el mercado afectara negativamente a la
salud o seguridad de las personas, podra producirse un rechazo del
pblico hacia la empresa con lo que sta se pondra en riesgo de
supervivencia. El pblico, la sociedad en general rechaza sistemticamente los productos que afectan negativamente al medio ambiente.
Por tanto, adems de la seguridad y la salud, se ha de considerar las
implicaciones que tiene el producto en la naturaleza. En todos estos
casos los principios ticos de la organizacin van a tener un papel
destacado.
101
2.4. La organizacin en relacin con los poderes pblicos y la tica

Ya se analiz el papel que tienen los poderes pblicos en la distribucin
de la riqueza que crean las empresas. Ellos, mediante las leyes pueden
determinar dos cosas: primero la parte de la riqueza creada que van a administrar las propias empresas y segundo el destino de la parte que administrarn los poderes pblicos. stos tienen una influencia fundamental en
la vida de las empresas. Para constituir una empresa hace falta disponer de
licencias y permisos adems de comunicar la actividad a los organismos
que gestionan los impuestos o las prestaciones sociales de los trabajadores.
Pero no es slo durante la fase de inicio cuando hay que considerar los
efectos de la actuacin de la Administracin. A lo largo de la vida de la empresa se van a producir una serie de hechos que pueden afectarla positiva
o negativamente.
Si los poderes pblicos proporcionan la seguridad necesaria, se ocupan de disponer los medios para la sanidad, invierten en infraestructuras,
regulan los mercados, etc. la empresa va a poder desarrollar en mejores
condiciones su actividad. Sin embargo es en la educacin, en la formacin
de las personas en donde se pueden apreciar mejor los beneficios de la
actividad de los poderes pblicos en las empresas. Ya se ha comentado anteriormente que las empresas las forman personas y que su capacitacin es
fundamental para lograr un alto nivel de eficiencia. Por tanto la educacin
tiene una influencia decisiva en la empresa. El futuro de cualquier organizacin se basa en la cantidad de conocimiento que se pueda gestionar desde
la misma.
Tomando como base todo lo anterior, se llega a un punto en el que
cambia el enfoque empresarial y adquiere un protagonismo especial la persona. Teniendo como base este concepto apareci el modelo de gestin
orientado a la persona.
2.5. El modelo de gestin orientado a la persona y la tica
Este modelo empez a difundirse a principios de este siglo. En Espaa
ha tenido una difusin mayor a raz del estudio que apoyado por Inmobasque, realiz un equipo de profesionales dirigidos por Sabin Azua en
2012. Este modelo se basa en la motivacin de las personas que desarrollan
su actividad laboral en la organizacin o empresa. Una persona motivada
produce ms y mejor que una que no lo est. Cuando se consigue que un
empleado de una empresa se centre en su trabajo porque tiene la motivacin suficiente para hacerlo, hay ms probabilidades de que ese trabajo se
haga bien y a la primera.
102
TICA PROFESIONAL
En las plantillas de las organizaciones hay cada vez ms personas que

tienen escalas de valores en las que consideran no solo su desarrollo profesional, sino tambin sus desarrollos personal y familiar. Si una persona
encuentra en una empresa la forma de compatibilizar los desarrollos mencionados, trabajar con ms ilusin, ms motivada y por tanto su productividad ser mayor. La posibilidad de trabajo a tiempo parcial, trabajo con
responsabilidad compartida, teletrabajo y algunas otras que se analizarn
con ms detenimiento en el punto 4.4 siguiente, ayudan a que el empleado
se integre ms y mejor en la empresa, con los beneficios asociados que eso
conlleva para la empresa. El directivo productor (el que est centrado en
los resultados) comprender que facilitando la conciliacin mencionada
anteriormente, conseguir unos resultados mejores y el valor de su empresa
aumentar ms de lo que aumentara sin empleados motivados.
3. RESPONSABILIDAD SOCIAL CORPORATIVA

3.1. De la tica empresarial a la Responsabilidad Social Corporativa
La Responsabilidad Social Corporativa (RSC) tiene cada vez una influencia mayor en el gobierno de las sociedades de capital y es considerada
como parte integrante de la gestin global de la empresa. Se entiende como
Responsabilidad Social Corporativa, aquellas actuaciones de la empresa que
no van directamente encaminadas a proporcionar los productos o servicios
que realizan, sino a actividades sociales. Por ejemplo, hay una empresa
minera que apoya a una fundacin de asistencia a personas con algn
tipo de desorganizacin neurolgica o lesin cerebral. No hay leyes que
les obliguen a realizar tal apoyo. Sin embargo entienden que una parte
de la riqueza que generan debe destinarla a una actividad en la que sus
administradores creen y con la que proporcionan servicios adicionales a la
sociedad.
Nuevamente aparece el concepto tica. Los accionistas han de renunciar
a una parte de su retribucin con objeto de que se puedan destinar fondos
a una actividad que no proporciona ms que gasto a primera vista. Pero
si se analiza con profundidad el hecho de apoyar a una actividad de asistencia social (o de otro aspecto considerado social) se observa que se producen varios hechos conectados con la actividad principal de la empresa:
Por un lado se da una imagen tica de sus administradores y directivos que
permiten y potencian la accin social, lo que redunda en la mejora de las
relaciones con los administradores y directivos de otras empresas clientes
o proveedores suyos. Por otro lado sus empleados se sienten ms implicados sabiendo que trabajan en una empresa socialmente responsable. La
103
empresa como consecuencia est consiguiendo fidelizar a sus empleados y

mantener, por tanto, su conocimiento intacto.
Pero, adems, cuando llega al pblico la noticia de que hay una empresa
que proporciona asistencia social a un determinado colectivo considerado
como desfavorecido, se crea una corriente de simpata hacia esa empresa
lo que hace que mejoren sus relaciones con el entorno social en el que
desarrolla su actividad, etc., y al conocerse mejor los productos o servicios
que ofrece se piensa en ella como proveedor. Como adems la noticia
ha llegado al pblico a travs de canales no publicitarios (ya que no han
sido precisas costosas campaas publicitarias), el coste de la difusin de
actividades ha sido muy reducido. Basado en lo anterior con actividades
que se podran encuadrar dentro de la Responsabilidad Social Corporativa se est consiguiendo mejores ambientes de trabajo, fidelizacin de los
empleados, ilusin por el desempeo de las tareas asignadas cosas que
unidas a la actitud y aptitud de los empleados llevan al incremento de la
productividad.
La manera de implantar un modelo de Responsabilidad Social Corporativa que tienen las empresas vara de unas a otras pues depender de los
criterios del empresario (o de lo que le admitan los socios o Consejo de
Administracin) y de la situacin econmica de la empresa. Por tanto a la
Responsabilidad Social Corporativa se pueden aproximar las organizaciones
desde distintas perspectivas:
a) Perspectiva del beneficio: en este caso las exigencias ticas no son estrictamente por convencimiento, por el deseo de prestar un servicio a
la sociedad, sino por el resultado que se deriva de la actividad social.
Es decir, se miran los beneficios econmicos que la RSC induce en la
empresa.
b) Perspectiva de la normativa (llamada en ocasiones perspectiva jurdica): en este caso la empresa considera accin social todos aquellos
beneficios que tiene el personal de la empresa pero que no estn
ligados a una obligacin legal. Utilizan diversos acuerdos alcanzados
con sus empleados a lo largo de los aos para la mejora de las condiciones laborales como actos de RSC. Por ejemplo una empresa que
lleva tiempo ofreciendo a sus empleados una guardera la lleva al captulo de la memoria en la que se trata de RSC en lugar de mantenerla
en el informe socio-laboral.
c) Perspectiva de la reputacin: estas empresas utilizan las actividades
sociales para mejorar su imagen. En general esta perspectiva se utiliza
por empresas que con anterioridad han tenido algn tipo de problema social o medioambiental que ha deteriorado su imagen.
104
TICA PROFESIONAL
d) Perspectiva de la visin: en este caso la empresa considera que para

alcanzar de una manera ms decidida la visin que tienen, las actividades sociales que puedan encuadrarse dentro de la Responsabilidad
Social Corporativa van a ayudarles en su empeo. Por tanto entienden que para llegar a ser lo que quieren ser (visin) lo van a hacer
de una forma en la que se consideren tambin actividades sociales
que puedan ser consideradas como RSC, y por tanto las incorporarn
a su estrategia. En la figura 4.5 se muestra el esquema de las distintas
aproximaciones a la RSC
Figura 4.5. Distintas aproximaciones a la RSC.
4. LA EMPRESA FAMILIARMENTE RESPONSABLE

Se denomina empresa familiarmente responsable a la que aplica estrategias o medidas que contribuyen a conciliar los intereses de las vidas familiar
y laboral.
105
El cambio profundo que se ha operado en la sociedad, proviene de la

incorporacin masiva de la mujer a la vida laboral y la modificacin que sufren las familias por muy diversas razones. Hoy la estructura familiar no es
la misma que la de hace unos aos. Hay familias monoparentales, familias
formadas por parejas del mismo sexo, familias en las que se agrupan tres
generaciones, etc.
Estas familias en las que los dos miembros de la pareja trabajan fuera de
casa generan unas necesidades absolutamente diferentes de las que haba
hace unos aos. Los horarios a los que tiene que ajustarse los miembros
de una familia en sus diferentes ocupaciones no siempre son compatibles.
Cuando adems hay hijos en edad de escolarizacin la vida se complica
porque los horarios escolares tampoco estn coordinados con los diferentes
horarios laborales.
Otro fenmeno que se est produciendo es el retraso en la edad de maternidad. La necesidad de encontrar trabajo y la sensacin que se percibe de
que con hijos es ms difcil encontrar trabajo, provocan que la pareja deje
para ms adelante la procreacin. Este retraso de la edad de maternidad, es
seguro que tendr una incidencia en la sociedad, aunque todava slo se
vislumbran ciertos efectos. Uno de los efectos ms evidentes es el nmero
de hijos en la familia. Encontrar familias numerosas no es una tarea fcil. Y
este fenmeno produce una modificacin de la pirmide de poblacin que
puede llega a ser insostenible si no se encuentra la manera de incorporar
ms jvenes a la poblacin laboral. Por tanto se precisa conciliar horarios,
conciliar las vidas familiar y laboral y sobre todo establecer las bases para
que la pirmide poblacional cambie.
Estas son las razones principales por las que cada da se reclaman a las
empresas frmulas de trabajo que permitan la conciliacin de las vidas laboral y familiar y que posibiliten el desarrollo de las personas que trabajan
en la organizacin en los campos profesional, familiar y laboral. Adems, la
conciliacin entre las vidas familiar y profesional no son ya un asunto que
atae exclusivamente a las mujeres. Los padres de familia se estn implicando cada vez ms en la defensa de su rol de padre y pareja, ampliando
el papel que haban tenido hasta hace unos aos como sustentador econmico de la familia.
Hay que establecer, por tanto en las empresas que quieran ser familiarmente responsables ciertas medidas que faciliten esa conciliacin para
evitar problemas tales como estrs, ansiedad, rotacin excesiva de los empleados, desmotivacin, absentismo, etc. Es evidente que los problemas de
conciliacin de la vida laboral y familiar pueden afectar al rendimiento de
los empleados y es por ello por lo que la empresa deber implementar una
serie de medidas que contribuyan a evitar que los empleados no se centren
en su trabajo por tener problemas familiares que recaben su atencin. Entre
106
TICA PROFESIONAL
las medidas que pueden ayudar a solucionar los problemas mencionados

estn las siguientes:
4.1. Flexibilidad
Con la flexibilidad de los horarios se puede conseguir un avance importante en la solucin de problemas de conciliacin. Si los empleados
pueden ajustar el horario a sus necesidades familiares conseguirn mejorar
la atencin a los miembros de la familia que lo precisen. Qu se hace tanto
tiempo en el trabajo? Por qu nuestros vecinos de otros pases son capaces
de producir ms cuando estn menos tiempo en la empresa? Lo que est
claro es que presencia en el trabajo y productividad no son lo mismo. Y
se ha de retribuir a los empleados por su tiempo de presencia o por su
productividad? Por ejemplo, en Espaa suele haber ms horas de presencia
en las empresas que en los otros pases de su entorno, pero sin embargo es
uno de los que tienen la productividad ms baja.
Cada empresa, cada organizacin tiene que aplicar la frmula ms adecuada. Es evidente que los puestos de trabajo que exigen una presencia
determinada no pueden tener el mismo tratamiento que aquellos que no
la precisan. Lo que es evidente que la aplicacin de horarios o jornadas
flexibles, horarios reducidos, etc. van a permitir que los empleados puedan
conciliar de una manera efectiva sus vidas familiar y laboral.
Tambin es posible aplicar flexibilidad concediendo una reduccin de
jornada a personas que lo soliciten con el fin de atender sus necesidades
personales o familiares. En este caso los empleados solo tienen que estar
trabajando las horas que acuerden con el empresario. Aunque pueda parecer que la actividad empresarial pudiera verse perjudicada, el trabajo con
jornada reducida proporciona ventajas adicionales. De hecho una empresa
que tena un director de marketing por la maana y otro por la tarde, encontr ventajas adicionales, pues adems de ser dos personas las que analizaban los problemas, podan asistir a reuniones convocadas en el mismo
da en distintas ciudades.
4.2. Servicios a los empleados
Bajo esta denominacin se agrupan aquellos servicios que se ofrecen
a los empleados para reducir su carga de trabajos fuera de la empresa y
as poder disponer de ms tiempo libre para atender a la familia. Hay empresas que proporcionan conductores que llevan al taller el coche de los
empleados cuando tienen que pasar una revisin o hacerles un lavado.
Otros proporcionan cuidadores para los hijos si tienen algn problema con
el cuidador habitual. Hay incluso empresas que facilitan a sus empleados
107
la realizacin de la compra diaria. Como ejemplo merece la pena considerar el acuerdo que alcanzaron los trabajadores y directivos de un hospital
al que le sobraba personal en el rea de lavado y se iba a despedir a los
trabajadores que no eran necesarios. Se propuso y la direccin acept que
los empleados del hospital pudieran traer su ropa de casa a lavar en el tren
de lavado del hospital, mediante el pago de una cantidad razonable. Los
beneficios fueron evidentes, ya que se mantuvo el nivel de ocupacin y
los empleados no tenan que lavar y planchar la ropa de casa al llegar a la
misma, con lo que disponan de ms tiempo para la familia, el estudio o
sus aficiones.
En definitiva hay que buscar frmulas innovadoras que ayuden a la empresa manteniendo un nivel alto de la motivacin de los empleados para
que stos puedan realizar su trabajo bien y a la primera.
4.3. Adaptacin del puesto de trabajo y apoyo profesional
Hay que adaptar la carga de trabajo a las situaciones especficas de la
persona y capacitar a quin lo precise determinando las necesidades de formacin o motivacin. Entre los mtodos que ms estn utilizando las empresas para apoyar profesionalmente a sus empleados estn los seminarios
sobre el control del estrs, lo que quiere decir que la formacin que se da a
los empleados no se limita a una formacin tcnica que les permita conocer
las exigencias tcnicas de su puesto de trabajo sino la formacin complementaria que precisan para el desempeo de su tarea en unas condiciones
psicolgicas ms adecuadas. Esto le proporcionar una vida familiar ms
agradable al saber separar las obligaciones laborales de las familiares, que
es el primer paso para compaginarlas.
4.4. Beneficios extra-salariales
Hay empresas que proporcionan a sus empleados beneficios extra-salariales tambin llamados sociales con el objetivo de motivar a los trabajadores y que stos se centren en el trabajo que realizan. Entre stas se encuentran el seguro mdico para la familia, ayudas a familiares discapacitados,
planes de jubilacin, coche de la empresa, etc.
Sin embargo, aunque la empresa suele incluir todos estos beneficios
en el captulo de acciones de una empresa familiarmente responsable, no
siempre los empleados lo valoran como tales. El hecho de que la mayora
de estas acciones se consideran salario en especie, provoca que haya un
grupo importante (especialmente entre los que perciben salarios ms bajos)
que solicita que le cambien por salario algunas de esas medidas.
108
TICA PROFESIONAL
5. REFERENCIAS
ADIZES, I., Corporate Lifecycles: How and Why Corporations Grow and Die and
What To Do About It. Englewood Cliffs, NJ: Prentice Hall, 1988, 361 pp.
PREZ, J. L. Polticas orientadas a la direccin de las personas, Universidad de Deusto, 2009.
AZUA, S., Dinmicas de gestin orientadas a las personas, Inmobasque, 2012.
ESCOLA, R. y MURILLO, J. I., tica para Ingenieros, Ediciones Universidad de Navarra,
S.A. 2004.
GOI, J. L. tica Empresarial y Cdigos de Conducta. La Ley-Actualidad, 2011.
CHINCHILLA, N. y MORAGAS, N., Dueos de nuestro Destino. Cmo conciliar la vida
profesional, familiar y personal, Ariel, 2007.
NAVARRO, F., Responsabilidad Social Corporativa. Teora y prctica, ESIC Editorial,
2012.
109
CAPTULO 5
RELACIN CON LOS PROVEEDORES

Y GESTIN DE SUBCONTRATACIONES
Jess Morcillo Bellido
Miguel Yaguez Prez
1. INTRODUCCIN
En este captulo se tratarn los temas relacionados con algo tan fundamental en cualquier proyecto como es la relacin con los proveedores y
la gestin de la relacin de la subcontratacin. En todo proyecto los proveedores adicionan un gran porcentaje del valor aadido total y a travs
de la aportacin de los bienes y servicios que proporcionan estn condicionando factores claves para que el proyecto sea un xito, o un fracaso,
en trminos de calidad, prestaciones, coste y por lo tanto viabilidad del
proyecto.
Dentro del captulo, en primer lugar se tratan los aspectos necesarios
para comprender en qu consisten las cadenas de suministro, cmo funcionan las mismas y los retos a considerar en su desarrollo y organizacin para
que contribuyan a mejorar los resultados de los proyectos. A continuacin,
se desarrolla un tema de especial relevancia en la ejecucin de los proyectos
como es la gestin de la subcontratacin que permite llevar a cabo muchos
proyectos que por su dimensin y complejidad no seran abordables por
organizaciones que actuaran aisladamente. Dentro de la subcontratacin
se estudian los mecanismos precisos para su puesta en marcha y se dan
recomendaciones para que esta actividad sea una herramienta de creacin
111
de valor aadido, evitando potenciales riesgos o problemas que pudieran

aparecer si no se tuvieran en cuenta.
2. LA CADENA DE SUMINISTRO
En la segunda dcada del siglo XXI, las organizaciones se enfrentan con
un nivel de requerimientos ms acentuado que nunca en trminos de coste,
servicio y calidad. El cumplimiento de los mismos requiere trabajar para
conseguir procesos ms integrados desde el cliente al proveedor que soporten el cumplimiento de los compromisos que la organizacin ha tomado
con sus clientes. Toda esa estructura de procesos vista y entendida como
una red es la que al final consigue cumplir los objetivos de una organizacin determinada en temas tan claves como suministrar en el momento
previsto, alcanzar un nivel de coste integral ptimo y garantizar la calidad
prometida al cliente.
En un mercado tan competitivo, abierto y global como el actual los
clientes buscan el mejor precio, la mejor calidad, un diseo atractivo, soluciones innovadoras, correr menos riesgos y un excelente servicio, entre
otros factores relevantes a la hora de tomar su decisin. Para hacer frente
a todos estos retos de una manera eficaz, se ha desarrollado el concepto
de cadena de suministro, que entiende que los procesos que condicionan
el resultado de una organizacin van ms all de los lmites de la propia
organizacin para extenderse a sus proveedores y clientes, de tal forma que
alcanzar un alto resultado en uno de los parmetros claves anteriormente
enumerados no depende solo de como trabaje la propia organizacin sino,
en gran medida, de cmo lo hagan el resto de los miembros de la cadena
en la que se encuentre inmersa.
2.1.
Qu es la cadena de suministro? De la mejora de los flujos a la

visin de procesos
Todas las organizaciones aunque no sean conscientes de ello forman

parte de una o varias cadenas de suministro, esencialmente formadas por
una serie de empresas que, como eslabones de una cadena, permiten llevar
el bien o el servicio, hasta el cliente final de la forma ms eficiente y fiable.
La gestin de la cadena de suministro engloba todas las actividades precisas
desde el diseo de los productos y transformacin de los materiales hasta
la entrega y el servicio posventa. En definitiva, incluye a todos aquellos que
trabajan en la satisfaccin de las necesidades de un cliente desde el diseo
del producto hasta la puesta en marcha y el mantenimiento posterior, si este
fuera preciso.
112
RELACIN CON LOS PROVEEDORES Y GESTIN DE SUBCONTRATACIONES
Sin embargo, este concepto que es ahora comnmente aceptado ha sido

el resultado de una importante evolucin en los ltimos aos del siglo pasado. Al final de los aos 50 las empresas empezaron a tener en cuenta las
interrelaciones entre la gestin de los almacenes y la funcin de transporte.
Con la creacin del Consejo Nacional de Distribucin Fsica en Estados
Unidos en 1963, estas dos funciones se integraron bajo el nombre de gestin de la distribucin fsica. Los ejecutivos de las grandes empresas vieron
en la gestin de la distribucin fsica una actividad esencial para mantener
la imagen de marca y la cuota de mercado de sus compaas ya que les
permita diferenciarse de la competencia [Gattorna y Walters, 1996] las actividades que fueron consideradas como incluidas en el ncleo de la gestin
de la distribucin fsica son: gestin del inventario, transporte, almacenaje
y comunicacin.
La gestin de la distribucin fsica se extendi gracias a la mejora de las
comunicaciones entre los distintos niveles de almacenes (de planta, local,
regionales y nacionales), la disponibilidad de una mejor informacin y el
uso de tcnicas analticas ms avanzadas. Este periodo abarc aproximadamente desde 1960 a 1975 y el objetivo era equilibrar la produccin con la
demanda. La gestin de la distribucin fsica estaba basada en una filosofa
push, que implicaba que las fbricas confeccionaban los productos y los
departamentos de Marketing y Ventas los empujaban hacia el mercado,
esperando que los clientes los compraran. Dado que se estaba mejorando
en parte el problema del servicio a los clientes pero el enfoque era solo
parcial, en un momento determinado comenz a reconocerse la necesidad
de integrar ms los procesos de negocio de la empresa. As en un momento dado y partiendo de un mayor uso de los sistemas de informacin, se
integr la distribucin fsica con la produccin, los aprovisionamientos, la
planificacin y la gestin de las compras dando lugar a un concepto ms
amplio que se conoci como logstica.
Esta mejora se apoyaba, en gran medida, en el uso extensivo de nuevas
herramientas disponibles como el intercambio electrnico de datos y la
amplia extensin de las comunicaciones. Ello permiti que las empresas
comenzaran a cambiar su forma de trabajar de un enfoque push a otro pull,
tratando de seguir la demanda de los consumidores en vez de fabricar esperando que los clientes demandaran exactamente el producto que estaba
en los almacenes. Es en esta etapa el poder de decisin ya estaba en manos
de los clientes finales que podan elegir entre una amplia oferta de proveedores lo que oblig a las compaas a orientarse ms hacia el cliente. Esta
etapa se extendi hasta aproximadamente la ltima dcada del siglo pasado
[Quinn, 1997].
Se considera que el siguiente paso comenz a finales de la dcada de
los 80, con la irrupcin paulatina del concepto de gestin de la cadena de
113
suministro [Chopra y Meindl, 2001] basado en la asuncin de que si todas

las actividades necesarias para entregar el producto al cliente final se enfocaban como un proceso, que era gestionado como tal, se podan alcanzar
unas significativas reducciones de costes adems de un aumento en el
nivel de servicio. Esto era algo diferente porque ya la optimizacin del
conjunto del proceso primaba sobre las sub-optimizaciones de cada uno
de sus elementos, incluso ms all de las paredes de la organizacin propia. El cambio fundamental fue pasar de la gestin logstica, cuyo objetivo
era la mejora interna de la empresa, a la integracin de las actividades
a lo largo de la cadena incluyendo a todos los que tomaban parte en la
cadena de suministro, as las relaciones tanto con proveedores como con
clientes se estrecharon para conseguir la integracin de todos los eslabones dentro de una misma cadena. Uno de los cambios ms significativos
en los negocios modernos es que se considera que las empresas ya no
compiten como entidades autnomas sino que compiten como miembros
de cadenas.
Se considera que la direccin de las empresas ha entrado en la era de
la competencia entre redes y el xito de una red depender de la habilidad
de sus directivos para gestionar la integracin de las intrincadas relaciones
inter-empresariales que forman su red, segn Drucker [1997] quin es considerado como uno de los primeros autores en tratar este tema. De hecho
la gestin de las mltiples relaciones a lo largo de la cadena de suministro
es lo que se denomina gestin de la cadena de suministro.
Estrictamente la cadena de suministro no es simplemente una cadena
de negocios entre empresas que interaccionan una a una, negocio a negocio, sino que es una red de mltiples relaciones de colaboracin. La
gestin eficiente de una cadena de suministro ofrece la oportunidad de
aprovechar las sinergias consecuencia de la integracin de todos los que
intervienen en la misma y persigue alcanzar la excelencia en los procesos
de negocio. Esto representa una nueva manera de dirigir los negocios a
travs de la eficiencia y excelencia en las relaciones entre los miembros
que forman la cadena.
2.2. Estructura de la cadena de suministro
Las cadenas de suministro son en el fondo redes que trabajan y colaboran en uno o varios proyectos pero que no cabe considerar como estructuras permanentes ya que solo se mantienen estables en el tiempo en
cuanto a la composicin de sus miembros si eso les sigue dando valor y
competitividad. En un mundo tan globalizado como el actual es bastante
frecuente la colaboracin en mltiples redes, incluso pertenecer a redes
que compiten entre ellas por un determinado negocio.
114
Es fundamental a la hora de gestionar la red conocer su estructura y

comprender como est configurada. Se considera que hay tres elementos primarios que determinan esta estructura (Lambert, Cooper y Pagh,
1998):
1. Los miembros que conforman la cadena de suministro. Integrar
y gestionar todas las relaciones de procesos con todos los miembros involucrados a lo largo de la cadena es una tarea complicada,
por lo tanto la clave es identificar las bases o los postulados sobre
los cuales se identificar a los miembros claves para el xito de la
cadena.
2. Las dimensiones estructurales de la red. Es necesaria una clasificacin de estos miembros, segn la importancia que tienen en el
desarrollo de la cadena. Autores como Porter (1984) y Davenport
(1993), establecen una serie de principios para definir los miembros
principales de la cadena. Se consideran miembros principales a aquellos que desempean un rol estratgico en la realizacin de actividades operativas o de gestin en los procesos de negocio incluidos
en la cadena. Siendo los elementos de apoyo las compaas que
simplemente proporcionan recursos o conocimientos, no crticos, a
los miembros principales
3. Los distintos tipos de relaciones de colaboracin. Como se ha comentado anteriormente, tratar de integrar y gestionar todos los procesos de una cadena de suministro es una tarea muy compleja e incluso
los niveles de integracin sern distintos dentro de cada relacin y
variarn en el tiempo.
En la figura 5.1, se puede ver la estructura de una cadena de suministro
donde se enumeran una serie de procesos habitualmente relevantes:
115
Figura 5.1. Estructura de la una cadena de suministro.

Fuente: Cooper et al. [1997].
En trminos generales, la gestin de la cadena de suministro es un enfoque conceptual que propone la integracin y coordinacin de todos los
procesos clave de la empresa, comprendidos entre el usuario final y los
proveedores iniciales, con el fin de crear y agregar el mximo valor a ese
usuario final en forma de productos y servicios.
116
3. LA COORDINACIN EN LA CADENA DE SUMINISTRO

Frecuentemente se habla de coordinacin entre los diferentes miembros
de una cadena y sin duda esto no sucede por generacin espontnea. Requiere dedicacin e incluso de un acuerdo implcito y explcito para que se
admita por los propios miembros de la cadena que una optimizacin parcial
no permite conseguir el ptimo en el rendimiento global de la cadena y que
esto, en definitiva, es lo que asegura que la cadena mantenga su fortaleza
y viabilidad en el tiempo. Se entiende como causa u obstculo para la coordinacin cualquier factor que lleve a un ptimo parcial en alguna de las
etapas de una cadena de suministro o que incremente la distorsin de la informacin y variabilidad dentro de la misma. La variabilidad no creada por
el propio mercado es un problema que se manifiesta bsicamente en tres
focos (Chopra y Meindl, 2001): variabilidad en la demanda, variabilidad en
el proceso y variabilidad en el suministro. Y se denomina efecto bullwhip
al resultado que se produce cuando pequeas oscilaciones en la demanda
real del mercado se traducen en importantes niveles de distorsin de la
informacin aguas arriba eslabones de la cadena ms alejados del mercado lo que provoca decisiones errneas y costosas de esos miembros, ocasionando al conjunto de la cadena un coste integral superior al que hubiera
existido si la informacin se hubiera transmitido sin distorsiones, a la vez
que se empeora el servicio al cliente. Al estudiar las causas que provocan
estas distorsiones se distinguen las cinco categoras siguientes:
1. Sistema de incentivos: aquellas situaciones en las que los incentivos
ofrecidos en las diferentes etapas de la cadena llevan a acciones de
los miembros que aumentan la variabilidad. Existen principalmente
dos casos que crean este tipo de conductas: i) incentivos centrados
exclusivamente en el resultado individual de una parte del proceso
y que mejoran los resultados en un eslabn de la cadena pero incrementando globalmente los costes, ii) Un caso particular de esta situacin se produce cuando una estructura de incentivos en el equipo
de ventas provoca situaciones no deseables desde el punto de vista
de mejora en el flujo de los procesos. As, las polticas de gratificaciones que estn basadas en la cantidad de ventas realizadas durante
un perodo como mes o trimestre, sin ninguna otra consideracin,
fomenta que se incremente la cantidad vendida a distribuidores o detallistas, o sell-in, pero no necesariamente aumenta la cantidad vendida al consumidor final, o sell-out. Es decir los vendedores habrn
trasladado el inventario a los clientes, pero estos al tener un nivel de
stock excesivo no comprarn durante un periodo prolongado y por
consiguiente se combinan periodos de mucha actividad con otros de
117
actividad muy limitada, esto genera costes extras tanto por exceso
de trabajo en los picos de pedidos como por falta de ocupacin en
otros periodos. La variabilidad generada por incentivos basado en un
enfoque sell-in resulta mayor que la variabilidad de la demanda real
del cliente, por lo que se estn introduciendo distorsiones adicionales
en el flujo.
2. Forma de procesar y compartir la informacin: se produce cuando
la informacin de la demanda se distorsiona en las diferentes fases de
una cadena de suministro generando un incremento en la variabilidad de los pedidos dentro de la cadena. Puede haber diversas causas
para que se produzca este obstculo, como es el caso en el que las
previsiones estn basadas en los pedidos recibidos de los distribuidores y no siguen los movimientos de la demanda del consumidor final.
Cualquier variacin de los pedidos recibidos es interpretada como
un movimiento del mercado y no es as, por lo que las decisiones
tomadas en base a esa informacin suelen ser equivocadas. Un problema con efectos similares puede ser originado por la carencia de
informacin compartida entre los diferentes miembros de la cadena.
3. Operacionales: aquellas acciones que tienen lugar en el transcurso
de la preparacin y el envo de los pedidos, por la forma en que
son ejecutados. Se pueden distinguir factores como: i) si la poltica
de la empresa es maximizar el tamao del lote con el fin de reducir
el impacto de ciertos costes fijos, puede incurrir en un alto coste derivado de las posibles diferencias entre el tamao del lote en que
fabrican o transportan los productos y el tamao de los pedidos
de la demanda, lo que provoca stock adicional ii) los largos plazos de suministro aumentan la probabilidad de que se produzca el
efecto de distorsin, iii) cuando haya escasez de un producto, los
esquemas de racionamiento que asignan una produccin limitada
en proporcin de los pedidos recibidos por el fabricante llevan a
una magnificacin de las oscilaciones de los pedidos. Esta situacin
es frecuente en los lanzamientos de nuevos productos y tiene como
consecuencia un crculo vicioso en el que se alternan roturas de stock
con muy altos inventarios.
4. Precio: situaciones en las que las polticas de precio para un producto generan un incremento en la variabilidad de los pedidos. Dos
razones fundamentales: i) cuando se realizan descuentos por cantidad basados en lotes grandes se incrementa el tamao de lote de los
pedidos realizados dentro de la cadena de suministro, creando una
situacin similar al punto anterior, ii) fluctuaciones de precio debidas
a promociones y descuentos estacionales ofrecidos por el fabricante,
los distribuidores se aprovisionan con grandes lotes durante el pero-
118
do de la oferta pero reducen posteriormente sus compras durante un

amplio periodo hasta la bajada del nivel de los inventarios excesivos
y esto genera unas oscilaciones que nada tienen que ver con los movimientos de la demanda en el mercado.
5. Comportamiento: estos problemas se relacionan a menudo con la
propia estructura de la cadena de suministro y su forma de compartir
y distribuir la informacin a lo largo de las diversas etapas y entre los
diversos socios. Entre las causas que lo provocan, destaca la falta de
confianza entre los socios que lleva a un comportamiento oportunista
a costa del desempeo o resultado del conjunto.
4. HERRAMIENTAS PARA MEJORAR LA GESTIN DE LA CADENA DE SUMINISTRO.

LA INTEGRACIN CON CLIENTES Y PROVEEDORES
Una vez conocidas las barreras que impiden una adecuada coordinacin
en la cadena, cabe tratar sobre las acciones que una empresa puede tomar
para superarlas. Las siguientes medidas tratan de superar los obstculos y
mejoran los resultados totales de la cadena:
a) Metas e incentivos: ciertas acciones pueden mejorar la coordinacin y
por tanto el resultado de la cadena de suministro a partir de medidas
que ayudan a que cada participante o miembro trabaje en la misma
direccin y con el objetivo comn de maximizar el beneficio total de
la cadena. Tales como: i) alineacin de incentivos entre los socios y
funciones, ii) polticas estables de precio, iii) incentivos, muy en especial al equipo de ventas, basados en la demanda final del cliente,
evitando situaciones en las que nicamente se producen movimientos de un almacn a otro.
b) Mejora de la exactitud de la informacin: evitar informacin de la
demanda que no proceda directamente del mercado, reforzando la
fiabilidad de la informacin que se maneja y que circula a travs de
todos los miembros de la cadena. El principal problema, cuando esto
no se lleva a cabo, es que cada etapa realiza la previsin de su futura
demanda basndose en los pedidos que recibe y no en lo que est
realmente ocurriendo en el punto de venta
c) Mejora del funcionamiento operacional: buscando mejorar las polticas operacionales y as mejorar la gestin con prcticas tales como la
reduccin del tiempo de ciclo de aprovisionamiento y la reduccin
del tamao del lote. Si se reduce el tamao del lote se provocar
un decremento de la fluctuacin que se puede acumular entre dos
etapas consecutivas de la cadena. Un ejemplo tpico que conduce a
119
una disminucin del tamao del lote son las acciones encaminadas a
reducir los costes asociados con los pedidos, transporte y recepcin
de cada lote.
d) Cambiar de descuentos basados en tamao de lote a descuentos basados en mejoras compartidas: todo aquello que fomente los tamaos
de lote ms pequeos conduce a reducir la variabilidad, ya que el
resultado total durante un cierto periodo ser el factor clave y no el
volumen de un cierto pedido.
e) Fomentar las alianzas y la confianza: la confianza y las relaciones de
colaboracin a largo plazo entre los miembros de la cadena ayudaran
a mejorar la coordinacin y lograr as una cadena ms eficiente.
5. MODELOS
DE COLABORACIN ENTRE LOS MIEMBROS DE LA CADENA.
LAS
ALIANZAS
Las alianzas se han convertido en una herramienta cada da ms importante en la estrategia corporativa de las organizaciones y en particular para
conseguir mejoras en su cadena de suministro. Las dos ltimas dcadas del
siglo pasado ha significado un incremento explosivo de este tipo de relaciones, segn De Man [2005] han pasado de generar el 2% de la cifra de
negocio de las grandes corporaciones en el ao 1980 a un 35% en el ao
2004. Una de las principales razones para llevar a cabo una alianza es la
bsqueda de una situacin en la que el riesgo quede limitado al compartirlo
con otros socios. Las alianzas se han mostrado tiles en entornos con alto
nivel de incertidumbre y en mercados con oportunidades de crecimiento,
siempre considerando que la compaa no quiere o no puede llevar adelante los proyectos por si sola.
Sin embargo, el fenmeno de la cooperacin no es algo nuevo, pero es
a partir de los aos setenta del siglo XX cuando se produce el pleno desarrollo de la cooperacin entre empresas. La economa espaola tampoco
ha sido ajena a la creciente importancia de los acuerdos de cooperacin
empresarial y aunque con cierto retraso, tambin en nuestro pas se ha producido un importante incremento de estas prcticas empresariales, cuyas
tendencias son consonantes con las observadas a nivel europeo o mundial
[Garca Canal, 1998].
Ahora bien, conviene distinguir entre lo que es una alianza y lo que
no lo es, as [Yoshino y Rangan, 1996] hacen una diferenciacin entre las
relaciones que consideran alianzas y otras relaciones empresariales que
consideran como meros acuerdos de cooperacin pero que, en su opinin,
no cabe considerarlas alianzas. Tal como se sintetiza en la figura 5.2, existe
120
una gran variedad de relaciones entre compaas, entre las cuales algunas
alcanzan el nivel de alianzas:
Fig 5.2. Tipologa de relaciones entre empresas. Fuente: elaboracin propia a

partir de Yoshino y Rangan.
En el grfico anterior estn destacados, con lneas de puntos, los tipos de

relaciones entre compaas que los autores mencionados consideran alianzas. Incluyen todas aquellas que superan los simples contratos comerciales,
tales como los acuerdos de desarrollo conjunto de I+D, de desarrollo de
nuevos productos, acuerdos de suministro a largo plazo y otros que incluyen participaciones minoritarias de capital, hasta llegar a acuerdos muchos
ms formales como las joint-venture1 y excluyen las que implican una toma
de control societario por parte de cualquiera de los socios y los contratos
comerciales habituales en las transacciones comerciales diarias.
Al hablar de alianzas, como forma particular de mejorar e integrar la
Cadena de Suministro, debemos de considerar que deben de reunir una serie de caractersticas tales como: i) son un acuerdo de colaboracin formal
Joint-venture: desarrollo de un proyecto conjunto.
121
entre dos o ms organizaciones, ii) en algunos casos se formalizan a travs

de participaciones accionariales y en otros con meros acuerdos de colaboracin sin constitucin de sociedades, iii) comparten recursos para cooperar
en una o varias reas de negocio, iv) suponen un compromiso temporal,
v) suponen que los socios consiguen mejores resultados a travs del trabajo
en colaboracin que los que conseguiran por separado y vi) los beneficios
son repartidos en forma acordada.
Las alianzas estratgicas son ampliamente utilizadas para reforzar las
cadenas de suministro y algunos autores (Jolly, 2002) indican unas condiciones adicionales que deben tener lugar en un acuerdo de colaboracin
que refuerce los resultados del conjunto de la cadena. Jolly menciona que
cada uno de los socios debe aceptar que est perdiendo algo de autonoma para conseguir una mejora en algn rea o tramo de la cadena, cabe
destacar que esta es una de las condiciones ms relevantes de las alianzas,
ya que implica una cesin de autonoma a cambio de poder conseguir beneficios que no es posible conseguir de forma aislada. Adems, cada socio
debe aportar una fraccin de sus propios recursos y/o conocimientos para
que la cooperacin tenga lugar. Tambin incluye que la accin conjunta
debe producir resultados superiores a los que ocurriran en el contexto de
una accin independiente. Asimismo es condicin imprescindible, para
que sea considerada alianza, que fuera de la misma cada socio mantenga
una parte significativa de su autonoma en su negocio, de tal forma que
el negocio principal de cada una de las empresas que participan en la
alianza contine funcionando sin interferencias apreciables por el hecho
de haberla realizado y el resultado de esta no debera condicionar la actividad principal.
6. CONSTRUYENDO CADENAS DE SUMINISTRO A PRUEBA DE CRISIS

En una situacin como la actual de incertidumbre y cambios constantes
en los mercados y las industrias, la posible vulnerabilidad de una cadena
de suministro se ha convertido en un tema clave para las compaas, que
no pueden permitirse el riesgo de tener un problema inesperado en un momento determinado que les impida continuar con un proyecto en marcha
e incumplir los compromisos adquiridos con sus clientes. Esto es especialmente relevante en unos momentos en los que una parte muy importante
de los flujos de materiales proceden de fuentes de suministro globales, es
decir que estn en cualquier punto del planeta y no siempre las compaas
han considerado los riesgos de esta situacin ni han tomado las suficientes
medidas preventivas como para poder reaccionar rpido en caso de un
problema.
122
6.1. Los riesgos en las cadenas de suministro

Las organizaciones que habitualmente consideramos como las mejores
prcticas y por lo tanto han trabajado profundamente en la mejora de sus
cadenas de suministro lo han hecho para conseguir que estas sean eficientes e integradas, tratando de que constituya la herramienta para garantizar
la mejora de su competitividad. Sin embargo, muchas de estas empresas
han conseguido que sus cadenas de suministro sean todo menos seguras
y menos an robustas, en el sentido de ser capaces de reaccionar y recuperase ante un problema imprevisto. Las organizaciones no son islas que
viven aisladas de los problemas que surgen en cualquier parte del planeta,
desde un incendio en un proveedor de segundo nivel hasta un terremoto
en Asa.
Pero para entender mejor la extensin del problema caben otras situaciones ms cotidianas en la situacin econmica actual como es la posibilidad de que algunos elementos de la cadena tengan problemas econmicos
que repercutan en otros, as cuando el fabricante UPF-Thompson declar
un concurso de acreedores en el ao 2001 el impacto que esto tuvo en algunos de sus clientes fue muy grave ya que era el proveedor nico de los
chasis del producto ms vendido por LandRover, el modelo Discovery. En
ese momento LandRover se vio confrontada con la parada de la produccin
con la consiguiente prdida de negocio y la peticin, por parte de los
administradores concursales, de ms de 35 millones de libras al contado si
quera seguir recibiendo chasis para montar. De esta forma LandRover se
vio obligada a tener que parar la produccin hasta que una sentencia judicial les permiti encontrar alguna salida. Al final una sentencia permiti a
LandRover negociar para poder implicar a otro proveedor que comprara el
negocio fallido. Pero adems de las prdidas econmicas provocadas, en
este caso se produjeron muchos efectos negativos como fue el despido de
1.400 trabajadores en la propia empresa y muchos otros en proveedores,
adems de la multitud de problemas que tuvieron con los clientes que haban comprado un vehculo.
6.2. Categorizacin de los riesgos en las cadenas de suministro
Los riesgos en las cadenas de suministro pueden categorizarse de diferentes formas, segn varias perspectivas. Sin embargo una forma ampliamente aceptada es la establecida por Mason-Jones y Towill [1998] que
sugieren cinco categoras de riesgos, dentro de tres grandes reas.
a) Internas a la organizacin: riesgos de proceso y riesgos de control.
b) Externas a la organizacin pero imbricadas en su cadena de suministro: riesgos de demanda y de suministro.
123
c) Externas a la cadena de suministro: riesgos provocados por el entorno.

En el rea de procesos estn las actividades de valor aadido bajo la
directa ejecucin de la organizacin y que supervisa a travs de los mecanismos de control establecidos. Mientras que las dos categoras externas a la
organizacin indicadas estn relacionadas con actividades que se ejecutan
fuera del control directo, pero es responsabilidad directa e inexcusable de
la propia organizacin conocer, familiarizarse y controlar aquellos procesos que, siendo crticos en su cadena de suministro, un eventual problema
podra tener graves consecuencias. Estos pueden ir desde no considerar
el riesgo de ubicar fbricas en pases con situacin poltica de alto riesgo
poltico o decidir comprar a proveedores situados en zonas conflictivas del
planeta, hasta no tomar ninguna medida para evitar que los proveedores
utilicen materiales cuyo uso est prohibido en la elaboracin de productos
o sean agresivos para el medio ambiente.
Estos riesgos deben de ser primero identificados, luego medidos y posteriormente controlados. Es decir, aunque es imposible controlar la totalidad
de los riesgos de una cadena de suministro ya que un acontecimiento como
el 11 de septiembre de 2001 no es previsible, si deben de crear las organizaciones una cultura que identifique los riesgos, los minimice y cuente con
planes de contingencia para cuando algo suceda. Esta forma de trabajar,
basada en no solo hacer bien las cosas en la cadena de suministro sino
tambin en identificar los factores de riesgo que pueden bloquearla, es un
paso ms avanzado en la mejora de los procesos de la cadena que algunas
compaas han comenzado a dar.
7. LA SUBCONTRACIN
Una vez desarrollado el concepto de la cadena de suministro interesa
tratar aquellos aspectos relacionados con la subcontratacin de obras o servicios que un jefe de proyecto precisa conocer para evitar las consecuencias
derivadas de una subcontratacin realizada sin tener en cuenta los aspectos
legales y la responsabilidad en la que se incurre derivada de aquellos. El
diccionario indica que contratacin es la accin y efecto de pactar, convenir, hacer contratos o contratas. La subcontratacin aparece cuando una
vez que se ha contratado un trabajo con una persona (fsica o jurdica), se
cede parte de o todo aquello por lo que se ha establecido el contrato a un
tercero.
Pero hay tambin otro tipo de subcontratacin que no precisa la consecucin de un pedido y la cesin de parte del mismo a otra empresa. Se les
suele llamar implant o outsourcing empleando trminos anglosajones.
En ocasiones una empresa a la que se le haya encargado un proyecto, tiene
124
que desplazar a parte de su plantilla a casa del cliente para realizar una
determinada tarea. Este caso se puede dar cuando hay que hacer una toma
de datos voluminosa, o recabar informacin especializada en un campo.
Las personas de la empresa que va a hacer el proyecto se implantan en
las instalaciones de la empresa que les ha contratado el mismo. Tambin
podra ocurrir que al realizar un proyecto que precise ciertas tareas que son
auxiliares el jefe de proyecta decida cederlas a otra empresa, pero pidindole que desplace su personal a la sede en la que se realiza el proyecto. A
esto se le suele llamar implant y quiz el ms comn es el despacho que
se cede a una agencia de viajes para que organice los viajes de aquellos
proyectistas que deban desplazarse. La empresa que se implanta en las
instalaciones de otra, no suele aportar ni mobiliario ni equipos, sino que
usa los de la empresa contratante.
La otra figura que se conoce como outsourcing es la que resulta de la
externalizacin de una parte de la actividad cedindola a otra empresa que
tiene su propio local, sus propios empleados y sus medios de trabajo y que
realiza el trabajo de acuerdo con las directrices que emanan de la empresa
contratante. Un caso que se suele dar en la gestin de proyectos es externalizar la gestin de los costes, ya que hay empresas especializadas en realizar
el trabajo en cuestin. No obstante esta actividad no es fcil que se deslocalice a otro pas, ya que sera preciso que conocieran el plan general de
contabilidad espaol. Sin embargo hay otros casos que se precisan menos
en la gestin de los proyectos como la atencin telefnica, pues esta actividad, en concreto tiene la caracterstica que puede ser situada en cualquier
parte del mundo, por lo que es llamada deslocalizacin, especialmente
cuando afecta a una empresa con el ncleo de la actividad situado en un
pas y el centro de llamadas subcontratado en otro.
7.1. El porqu de la subcontratacin
El origen de la subcontratacin se basa en el viejo dicho zapatero, a
tus zapatos. Es decir, se pretenda que cada compaa, cada organizacin,
cada persona haga aquello que conoce a fondo, aquello en lo que es especialista.
Desgraciadamente, esta razn inicial de la subcontratacin est siendo
modificada por otra ms poderosa: la econmica. En general cuesta menos
dinero, (y da menos problemas si la subcontrata se elige bien) la subcontratacin de ciertas actividades que acometerlas con personal propio. En los
casos de implant es especialmente importante estar pendiente de las obligaciones legales, porque este tipo de actividad puede ser calificada como
cesin de trabajadores, actividad que es ilegal salvo que se realice a travs
de una empresa de trabajo temporal o ETT.
125
En la subcontratacin que se ha denominado outsourcing las responsabilidades son ms difciles de establecer ya que la actividad se realiza en
otro centro de trabajo y es ms fcil que sea considerado como pedido
que como subcontratacin. Y si el centro de trabajo est en otro pas, la
responsabilidad sobre los salarios o la seguridad social (si es que la hay en
ese pas) es nula.
El problema fundamental de cualquier tipo de subcontratacin est
en que el cliente que ha contratado el trabajo, entiende que la responsabilidad de dicho trabajo es de su proveedor (con el que ha firmado
el contrato) y no del proveedor del proveedor (o subcontratista). Es la
empresa que ha contratado el trabajo con el cliente, a quin ste paga,
la responsable de que las cosas se hagan de acuerdo con un proyecto,
con unas especificaciones, independientemente si ese trabajo est hecho
por personas de la propia empresa contratada o si sta decide realizarla
subcontratando toda o parte de la misma a otra u otras empresas, organizaciones o personas.
Por tanto lo primero que hay que asegurar en la realizacin de un proyecto es la capacidad que tiene la propia empresa para hacer el trabajo, qu
partes del mismo est en condiciones de ejecutar (por capacidad tcnica o
por poltica de empresa) y qu partes va a subcontratar.
El principal problema de la subcontratacin no est en la bsqueda de
un subcontratista que pueda hacer el trabajo en las condiciones que exige
el proyecto de calidad y precio, sino en las particularidades legales que el
hecho de la subcontratacin tiene y que un jefe de proyecto ha de tener
presente cuando decida hacer una subcontratacin.
7.2. Marco legal de la subcontratacin en Espaa
Una vez decidido quin puede ser el subcontratista que por capacidad
tcnica y/o econmica, puede hacer el trabajo hay que recabar del mismo
la informacin que establece el artculo 42 del texto refundido de la Ley
del Estatuto de los Trabajadores, que es la base de las responsabilidades
derivadas de una subcontratacin, especialmente en los campos de posibles deudas con la Seguridad Social y salariales con los trabajadores de la
subcontrata.
En la redaccin actual del artculo, (hay que tener presente que hay cambios bastantes frecuentes en la legislacin laboral en general y en especial
en la que se produce en relacin con la Prevencin de Riesgos Laborales,
por lo que conviene estar al tanto de las modificaciones que se produzcan),
se indica que los subcontratistas tienen que estar al corriente del pago de
sus cuotas a la seguridad social. Si no lo estuviera la empresa que los contrate sera la responsable del pago de la deuda.
126
Sin embargo hay una condicin para que afecte esa responsabilidad: se
han de subcontratar obras y servicios correspondientes a la propia actividad de la empresa contratante. E inmediatamente surge la pregunta: qu
quiso decir el legislador con el trmino propia actividad? Para responder
a la misma no queda ms remedio que ir a los documentos que aclaran
las interpretaciones que se pueden dar a las leyes: las sentencias de los
tribunales.
Y los tribunales han definido el concepto propia actividad a travs de
una sentencia del Tribunal Supremo de 24 de noviembre de 1998:
Caben en principio dos interpretaciones de dicho concepto: a) la que
entiende que propia actividad es la actividad indispensable, de suerte que
integrarn el concepto, adems de las que constituyen el ciclo de produccin
de la empresa, todas aquellas que resulten necesarias para la organizacin
del trabajo; y b) la que nicamente integra en el concepto las actividades inherentes, de modo que slo las tareas que corresponden al ciclo productivo
de la empresa principal se entendern propia actividad de ella. En el primer
caso, se incluyen como propias las tareas complementarias En el segundo,
estas labores no nucleares quedan excluidas del concepto y, en consecuencia de la regulacin del art. 42 ET.
ha de acogerse la interpretacin que entiende que propia actividad de
la empresa es la que engloba las obras y servicios nucleares de la comitente,
entendiendo, de acuerdo con la sentencia referida que nos encontraramos
ante una contrata de este tipo cuando de no haberse concertado sta, las
obras y servicios debieran realizarse por el propio empresario comitente so
pena de perjudicar sensiblemente su actividad empresarial.
Por tanto para saber si se va a subcontratar propia actividad o no, es

conveniente conocer cul es el objeto social de la empresa con la que se
va a subcontratar (figura en los estatutos de la misma), los epgrafes por
los que cotiza en el Impuesto de Actividades Econmicas (IAE) y los epgrafes de la Clasificacin Nacional de Actividades Econmicas (CNAE). Si
hay coincidencia entre los de la empresa que subcontrata y la subcontratista, ya se tiene un indicio importante para que sea considerada propia
actividad y que un juez determine si hay responsabilidades derivadas de
la misma o no.
Adems el artculo mencionado exige que a la hora de subcontratar se
informe a los trabajadores. As la empresa contratante ha de informar a sus
trabajadores de las subcontratas que tiene pensado realizar y la empresa
subcontratada tiene que facilitar a sus trabajadores los datos identificativos
de la empresa que les contrata. Eso permite, y esto no lo dice el legislador,
que los trabajadores de la empresa principal puedan prever la evolucin
del empleo y los de la subcontrata sepan a quin reclamar si su empresa
no abona sus salarios.
127
Pero esta es la informacin econmica. Hay otra informacin que es

preciso facilitar a los trabajadores sobre las medidas de coordinacin entre
las diferentes empresas para la prevencin de riesgos laborales.
7.3. Responsabilidades salariales y con respecto a la Seguridad Social
Son las que se derivan del artculo anteriormente comentado del Estatuto
de los Trabajadores.
El empresario principal es responsable de los salarios y cuotas a la Seguridad Social que no pagara el subcontratista, a los trabajadores de ste que
estuvieran trabajando para el empresario principal durante el tiempo que lo
hicieron. Por tanto hay que establecer un control de entrada en el recinto
de la empresa principal (siempre que se pueda) en el que quede registro
de quines entraron, a qu empresa subcontratista pertenecen y durante
cunto tiempo. Y, en cualquier caso, no hay que pagar los trabajos realizados, sin haberse asegurado de que el subcontratista ha pagado los salarios
a sus trabajadores y las cuotas a la Seguridad Social (cuotas de empresa y
de trabajadores).
7.4. Responsabilidades tributarias
La Ley 58/2003 de 17 de diciembre (General Tributaria) con entrada
en vigor el 1 de julio de 2004, establece en su artculo 43, apartado f)
que sern responsables de la deuda tributaria aquellas personas o entidades que contraten o subcontraten trabajos o servicios correspondientes
a la actividad econmica principal. Nuevamente en este caso se ligan las
responsabilidades a que los trabajos o servicios encomendados sean de
la propia actividad de la empresa que los contrata. No obstante, en este
caso, es ms fcil liberarse de esta responsabilidad, pues basta pedir el
correspondiente certificado a la Administracin Tributaria, para obviar las
responsabilidades durante doce meses. Transcurrido el ao hay que volver a pedir el certificado.
7.5. Responsabilidades en materia de Prevencin de Riesgos Laborales
Un responsable de la realizacin de un proyecto est obligado a realizar
el plan de emergencias correspondiente en funcin de la actividad que vaya
a desarrollar, y en particular, segn el artculo 20 de la Ley de Prevencin
de Riesgos Laborales (PRL), deber analizar las posibles situaciones de
emergencia y adoptar las medidas necesarias en materia de primeros auxilios, lucha contra incendios y evacuacin de los trabajadores, designando
128
para ello al personal encargado de poner en prctica estas medidas y comprobando peridicamente, en su caso, su correcto funcionamiento.
El artculo 24 de la misma Ley establece la coordinacin que debe existir entre las diferentes empresas que desarrollen actividades en un mismo
centro de trabajo. El empresario titular del centro es el que debe adoptar
las medidas necesarias para eliminar o minimizar los riesgos y los otros
empresarios debern vigilar el cumplimiento de dichas medidas. Por ello
el responsable de un proyecto, ha de programar las actividades que deben
realizar las distintas empresas en el mismo recinto de trabajo y establecer
las medidas de coordinacin que sean necesarios en cuanto a la proteccin
y prevencin de riesgos laborales y la informacin sobre los mismos a sus
respectivos trabajadores.
Para dar cumplimiento a lo dispuesto en el punto 6 del artculo 24 de
la Ley de Prevencin de Riesgos Laborales, el da 31 de enero de 2004 se
publica en el BOE el Real Decreto 171/2004, de 30 de enero por el que se
desarrolla el artculo 24 de la Ley 31/1995, de 8 de noviembre, en materia
de coordinacin de actividades empresariales. (La correccin de errores del
RD 171/2004, se publica el 10 de marzo de 2004 en el BOE).
Los empresarios que trabajen en el centro de trabajo han de considerar toda la informacin recibida de los otros empresarios y la han de
incluir en la evaluacin de los riesgos y en la planificacin de su actividad
preventiva, poniendo especial atencin en aquellos riesgos que puedan
agravarse por las circunstancias de concurrencia en el desarrollo de las
actividades. Una vez establecidos los riesgos y realizada la planificacin
de la accin preventiva, cada empresario informar a sus trabajadores de
los nuevos riesgos o del agravamiento de los mismos que aparecen por
la concurrencia de actividades. De una manera genrica indica que los
medios de coordinacin han de establecerse en funcin de lo que consideren necesario los empresarios en funcin del grado de peligrosidad de
los trabajos, el nmero de trabajadores que van a concurrir y la duracin
de la concurrencia.
El tercer artculo de la Ley de PRL que afecta a la subcontratacin es el
42 que establece las responsabilidades y dice expresamente que:
el incumplimiento por los empresarios de sus obligaciones en materia
de prevencin de riesgos laborales dar lugar a responsabilidades administrativas, penales y civiles.
Es evidente que las responsabilidades se limitan a los hechos acaecidos

en el recinto de la empresa principal durante el tiempo que dure la contrata.
129
7.6. Responsabilidades penales

El Cdigo Penal en su artculo 316 dice que Los que con infraccin de
las normas de prevencin de riesgos:
t FTUBOEPMFHBMNFOUFPCMJHBEPT
t OPGBDJMJUFOMPTNFEJPTOFDFTBSJPT
t QBSBRVFMPTUSBCBKBEPSFTEFTFNQFFOTVBDUJWJEBEDPOMBTNFEJEBT
de seguridad adecuadas
t EFGPSNBRVFQPOHBOBTFOQFMJHSPHSBWFTVWJEB TBMVEFJOUFHSJEBE
fsica.
t TFSODBTUJHBEPTy
Hay que tener presente que este artculo habla del delito de peligro. Es
un delito de peligro, no de resultado o lo que es lo mismo, se comete delito
por poner a alguien en peligro, aunque no le pase nada. Se trata de un delito doloso por lo que debe existir conocimiento y voluntad de la realizacin
del tipo objetivo, esto es, actuando con conocimiento de que se infringe la
norma reglamentaria.
Este delito contra los derechos de los trabajadores es aplicable a aquellos
supuestos en los que no se hayan producido lesiones como consecuencia
de la falta de medidas de seguridad a las que el artculo se refiere. Si se
produjeran lesiones se aplicara el tipo penal ms grave, que sera el de
lesiones o, en su caso, el de homicidio imprudente. Es decir este artculo se
refiere a un delito de peligro, pero cuando el peligro se convierte en lesiones hay que aplicar un delito de resultado.
El Artculo 318 del Cdigo Penal establece las penas que se han de imponer (y a quienes) en el caso de personas jurdicas.
Se impondr la pena:
t "MPTBENJOJTUSBEPSFTPFODBSHBEPTEFMTFSWJDJPRVFIBZBOTJEPSFTponsables.
t "RVJFOFT DPOPDJOEPMPZQVEJFOEPSFNFEJBSMP OPIVCJFSBOBEPQtado medidas para ello.
Y volviendo al 316 se observa que las sanciones principales que se aplicarn en el caso anterior por infraccin de dicho artculo son de prisin de
6 meses a 3 aos y multa
t .VMUBEFBNFTFT
Y el artculo 127 y siguientes de dicho Cdigo Penal establecen la posibilidad de penas accesorias.
Fundamentalmente es el artculo 129 del Cdigo Penal el que establece
que puede:
130
t
t
t
t
t
TFSDMBVTVSBEBMBFNQSFTB
EJTPMVDJOEFMBTPDJFEBE
TVTQFOTJOEFBDUJWJEBEFT
QSPIJCJDJOEFPQFSBDJPOFT
JOUFSWFODJOEFFNQSFTB
Incluso durante la tramitacin de la causa podra haber una clausura

temporal y suspensin de actividades de la empresa.
7.7. La subcontratacin en el sector de la construccin
Lo mencionado hasta ahora es vlido para cualquier sector de la actividad empresarial. No obstante, hay que tener presente que en el sector de la
Construccin hay una legislacin especfica (Ley 32/2006 de 18 de octubre
y otras disposiciones que la desarrollan) que establece algunas obligaciones
adicionales cuando se ha de subcontratar (El subcontratista tiene que figurar
en un registro, p.ej.) y durante el desarrollo de los trabajos de la subcontrata
(Hay que tener un libro registro de subcontratistas, p.ej.).
Esta Ley, as como las disposiciones que la desarrollan estn sufriendo
cambios frecuentes a los que hay que estar atentos antes de acometer un
proyecto en el sector de la construccin.
7.8. Resumen de responsabilidades derivadas de la subcontratacin
Sobre los salarios
La empresa principal tiene responsabilidad sin el lmite legal de los que
le correspondera si se hubiese tratado de su personal fijo en la misma categora o puesto de trabajo, al haberse eliminado esta limitacin en el RDL
5/2001 de 2 de marzo.
Sobre la informacin
La empresa debe informar en los trminos establecidos en el artculo 42
del Estatuto de los Trabajadores, a los representantes legales de los trabajadores, de los supuestos de subcontratacin (contratas y subcontratas).
Sobre las cuotas a la Seguridad Social
El empresario principal y durante el ao siguiente a la terminacin de su
encargo, responder solidariamente del pago de las deudas con la Seguridad Social, adems de las de naturaleza salarial, contradas por los subcon-
131
tratistas respecto de sus trabajadores durante el periodo de vigencia de la

contrata o subcontrata.
Tributaria
Se es responsable si no se cerciora el contratante de que el contratado
est al corriente de pago de sus obligaciones fiscales mediante la aportacin
de un certificado expedido por la Administracin Tributaria. Este certificado
tiene un plazo de validez de doce meses por lo que hay que renovarlo a su
expiracin, si el contratista o subcontratista sigue en la obra.
Administrativa
Esta responsabilidad es la que se refiere al carcter sancionador por
parte de la Administracin a travs de la Autoridad Laboral. (Por ejemplo:
El hecho de no informar a los representantes de los trabajadores de los
supuestos de subcontratacin se considera como falta grave con multa de
300 a 3.000 euros).
Penal
Derivada de la gravedad del accidente que pueda producirse. En general
puede determinarse por el establecimiento de una definicin de responsabilidades en los distintos niveles de autoridad dentro de la empresa. Como
ya se ha visto, existe otro tipo de delito que establece el Cdigo Penal en
su artculo 316, el delito de peligro. Es decir puede existir delito aunque
no haya lesiones, simplemente por poner en peligro la integridad fsica de
una persona. Es evidente que la responsabilidad penal puede derivarse en
pena de crcel, y las empresas no van a la crcel. Son los administradores y
encargados del servicio quienes pueden ser condenados a penas de prisin.
Los organigramas y manuales de gestin de las empresas ayudan a determinar quin es el responsable de un hecho.
Disciplinaria
La empresa puede y debe sancionar a quien no cumpla las instrucciones
dadas por la Direccin en materia de prevencin de riesgos laborales.
Es difcil hacer comprender a la autoridad laboral que el deber de vigilancia se cumple cuando no se ha sancionado a nadie por incumplimiento
de la normativa vigente sobre prevencin de riesgos laborales. Quiz lo
aconsejable sea amonestar en una primera ocasin (que no represente
un incumplimiento grave) y si hay reincidencia podra sancionarse. En
132
cualquier caso conviene analizar lo que disponga el Convenio Colectivo

aplicable.
8. REFERENCIAS
BLANCHARD, D., Supply chain management best practices, Wiley, 2010.
BURT, D., DOBLER, D. and STAERLING, S., World class supply management. The key
to supply chain management, McGraw-Hill, 2003.
COYLE, J., BARDI, E. and LANGLEY, C. J., The management of business logistics: a
supply chain perspective, 7th Eddition, Thomson South-Western, 2003.
CHOPRA, S. and MEINDL, P., Supply chain management: strategy, planning and operation, Prentice Hall, Upper Saddle River, NJ, 2001.
GARCA, B. R. y GALLARDO, K., El outsourcing como ventaja competitiva: el impacto
de la subcontratacin en la flexibilidad y los costos, Editorial Acadmica Espaola, 2011.
GATTORNA, J.L. and WALTERS, D. W., Managing the supply chain: a strategic perspective, Basingstocke, Mc Millan, 2001.
PREZ DE LOS COBOS, F., Contratacin Temporal, Empresas de Trabajo Temporal y
Subcontratacin en la Negociacin Colectiva, Ministerio de Asuntos Sociales,
2010.
WISNER, D., KEONG, G. and TAN, K.-C., Principles of supply chain management: a
balance approach, Thomson South-Western, 2005.
133
CAPTULO 6
GESTIN FINANCIERA
Isabel Fernndez Fernndez
Alberto Manrique Navas
1. INTRODUCCIN
Habitualmente, esperamos que un proyecto sea capaz de generar fondos
no slo para recuperar el capital invertido, sino para obtener un beneficio
adicional que permita a la empresa incrementar sus activos y acometer
futuros proyectos. Para ello, se debe asegurar el beneficio esperado, optimizando los recursos disponibles (materiales y humanos) implicados en el
proyecto, sin olvidar que, tal y como se menciona en el captulo 1, hay proyectos donde el objetivo no es estrictamente econmico sino que responde
a aspectos sociales o estratgicos de la empresa como la bsqueda de nuevos mercados, el desarrollo de determinadas capacidades, o la realizacin
de un servicio pbico al mnimo coste posible.
En este captulo se analizar como, a travs de un exhaustivo control
econmico y de una eficaz gestin financiera durante todo el ciclo de vida
del proyecto, se podr, si no asegurar, al menos velar para que se cumplan
al mximo los objetivos sociales, econmicos y de rentabilidad esperados a
la finalizacin del proyecto.
Como se vio en el captulo 3, al analizar las distintas tcnicas de planificacin de proyectos, para lograr una gestin eficaz no slo se debe considerar el factor tiempo, sino que se deber tener una visin de conjunto que
permita, entre otros aspectos, detectar las principales tareas generadoras de
costes. As, para gestionar eficazmente un proyecto, no es suficiente reali-
135
zarlo en el tiempo previsto y con la calidad deseada por el cliente, sino al

mnimo coste posible. Por este motivo, es imprescindible que en el presupuesto del proyecto no se olvide ninguna partida de coste, y que se realice
la estimacin de su importe de manera exhaustiva y rigurosa. A este fin, es
imprescindible realizar una detallada descomposicin estructurada de los
costes del proyecto (CBS, Cost Breakdown Structure, en su terminologa
inglesa) que, aunque ser diferente para cada tipo de proyecto, presenta
elementos comunes que permiten su utilizacin como gua del proceso de
elaboracin del presupuesto.
Una vez calculados los costes, se podr proceder a la estimacin de los
ingresos previstos, y de esta forma se estar en condiciones de elaborar la
oferta econmica del proyecto. Si bien es cierto que en muchas ocasiones
las condiciones del mercado (competencia, limitaciones presupuestarias,
etc.) imponen el precio final de venta de un proyecto, la forma lgica de su
clculo ser el resultado de aplicar a la suma de todos los costes estimados
del proyecto, el tanto por ciento de margen o beneficio que se desea obtener con su ejecucin.
La parte crtica de la gestin financiera en un proyecto, se desarrollar
durante la ejecucin del mismo. Las herramientas que se describen en este
captulo permitirn llevar a cabo un mejor seguimiento y control de los
costes previstos (presupuestados), a fin de analizar y poner solucin a las
posibles desviaciones que se vayan produciendo en el transcurso de la vida
del proyecto.
Cuando se habla de gestin financiera, conviene recordar que no es
posible llevar a cabo un proyecto si no existen fuentes de financiacin,
bien sean propias (aportaciones de capital, beneficios empresariales, etc.)
o ajenas (prstamos, crditos, promotores externos, etc.) que nos permitan
cubrir los desfases de tesorera entre los pagos a realizar, por los costes
incurridos, y los cobros (ingresos) recibidos por las facturaciones al cliente.
Por ello, y a modo de introduccin al captulo 7 siguiente, se describirn
estas fuentes y se analizarn los costes financieros que tendr que asumir el
proyecto para garantizar su viabilidad.
Por lo anterior, en este captulo se tendr tambin muy en cuenta que,
por lo general, el beneficio econmico que los promotores (inversores, empresarios, accionistas) esperan obtener en los proyectos, deber ser siempre
superior al que se obtendra si el capital estuviese depositado en renta fija
en una institucin financiera. Por ello, ante la posibilidad de afrontar proyectos alternativos, se debern utilizar mtodos que nos permitan analizar
y comparar la rentabilidad prevista de los diferentes proyectos a fin de
seleccionar aqul que ms convenga a los intereses de la empresa y sus
accionistas.
136
GESTIN FINANCIERA
2. CONTENIDO Y ESTRUCTURA DE LA OFERTA ECONMICA DE UN PROYECTO

Previamente a cualquier actuacin, la direccin de la empresa deber (bien se trate de un proyecto interno de la empresa o de una posible
contratacin con un cliente externo) autorizar el presupuesto inicial para
la elaboracin y presentacin de la oferta de un determinado proyecto.
En cualquiera caso, y dado que el escenario de un proyecto externo sera
fcilmente extrapolable al interno, se asume, en el resto del captulo, la
existencia de un cliente externo
Como se muestra en la figura 6.1, basndose en la oferta tcnica donde
se define, no slo el alcance de los trabajos, sino el personal y los medios
necesarios para llevarlos a cabo, se proceder a realizar un desglose de costes (CBS) que nos permitir elaborar el presupuesto de costes del proyecto
que, a su vez, con la aplicacin del correspondiente margen, configurar los
precios de venta que nos permitirn calcular el volumen de ingresos. Con
stos ingredientes se estar en condiciones de elaborar la oferta econmica
del proyecto.
Figura 6.1. Proceso de elaboracin de la oferta econmica de un proyecto.
2.1. La descomposicin estructurada de los costes, CBS

La descomposicin estructurada de los costes, o CBS, es una relacin
exhaustiva y detallada de todos los costes que se producen durante la vida
del proyecto (desde su inicio hasta su finalizacin). Este desglose ser una
magnfica gua para no olvidar ningn elemento generador de coste que,
a la postre, pudiera producir una desviacin presupuestaria no prevista.
En este punto, conviene recordar, tal y como se vio en los captulos 2 y 3,
137
que es fundamental definir con precisin el objetivo y alcance del proyecto

desde el punto de vista tcnico, ya que una mala estimacin de tareas y/o
de tiempos puede conducirnos a extracostes no deseados.
Segn las diferentes prcticas de anlisis y el tipo de proyecto, el desglose de los costes puede variar. En muchas ocasiones, se realizar por la
naturaleza del coste: personal (costes de mano de obra directa e indirecta);
compras; subcontrataciones; otros costes directos, etc. No obstante, la forma de descomposicin de costes ms utilizada desglosa los mismos en cada
una de las fases del ciclo de vida del proyecto, en los siguientes grupos:
Costes iniciales:
En los costes iniciales, se incluyen las inversiones necesarias para la
puesta en marcha del proyecto. Entre ellas estaran los costes de planificacin inicial y anlisis de mercado; los de adquisicin o alquiler de activos
fijos necesarios (terrenos, oficinas, elementos informticos y dems equipos
de inmovilizado necesarios para el desarrollo del proyecto); los costes de
instalacin y puesta en marcha de los equipos. En los proyectos ms novedosos, se incluiran los costes investigacin y desarrollo (panificacin, diseo, ingeniera, documentacin, pruebas, etc.). La imputacin de los costes
iniciales al proyecto, se puede realizar el primer ao o se puede repartir
entre los aos de vida del proyecto a travs de las amortizaciones.
Costes de produccin o construccin:
Estos costes tambin dependern de la naturaleza del proyecto, pero
habitualmente se componen de las siguientes partidas: materias primas;
mano de obra; subcontrataciones; suministros y servicios exteriores (energa, agua, etc.); seguros, impuestos y alquileres; construccin de instalaciones auxiliares; pruebas y puesta en funcionamiento; control de calidad de
la produccin; logstica inicial (apoyo inicial al cliente, repuestos, equipo de
pruebas necesario, etc.). Desde el punto de vista de la rentabilidad de un
proyecto, estos costes, son los de mayor importancia y los que, por tanto,
van a incidir directamente en el potencial beneficio. Adems, son los ms
difciles de estimar ya que ser necesario extrapolar situaciones actuales a
los distintos aos de duracin del proyecto.
Costes de operacin y mantenimiento:
Aunque, tradicionalmente stos costes slo eran caractersticos en los
proyectos que involucraban grandes sistemas, en la actualidad existe una
tendencia, cada vez ms acentuada a incluir en el coste de los proyectos
las fases posteriores a la puesta en funcionamiento de mismo. Si ste es un
requisito de nuestro proyecto, debemos aadir todos los costes necesarios
138
GESTIN FINANCIERA
para la operacin y mantenimiento del mismo durante su ciclo de vida. Entre stos estarn: los costes de operacin de los sistemas/productos incluidos en el proyecto por parte del usuario; costes de mantenimiento durante
el ciclo de vida del proyecto (servicio al cliente, revisiones del sistema/
producto, equipos de prueba, etc.) ; costes de distribucin y transporte;
costes de apoyo logstico durante el ciclo de vida del proyecto (inventarios,
repuestos y apoyo al material); costes debidos a las modificaciones y mejoras del proyecto; coste de la documentacin tcnica de operaciones, de
mantenimiento y de mejoras introducidas; coste de las subcontrataciones.
Costes de financiacin y amortizacin:
No slo se incluirn los costes financieros para hacer frente a las inversiones iniciales de la puesta en marcha de un proyecto, sino tambin los
necesarios para cubrir los desfases de tesorera durante la vida del proyecto. Los costes financieros a imputar al proyecto, revestirn la forma de
intereses, cuotas, etc., segn la fuente de financiacin elegida, tal y como
veremos en el captulo 7.
Los costes de amortizacin son aquellos que imputamos al proyecto
como consecuencia de la prdida de valor que experimentan los activos
fijos al ser utilizados en el proyecto. Tendremos que diferenciar, en este
punto, los activos que siendo propiedad de la empresa van a ser utilizados
en el proyecto, de aqullos que se adquieren para el proyecto y pasaran a
ser propiedad del cliente. En el primer caso es normal trasladar al proyecto
nicamente la amortizacin y, en su caso la financiacin, durante la vida
del proyecto. Sin embargo, cuando se adquieren exclusivamente para el
proyecto, se deben imputar a ste por su monto total.
Costes de eliminacin y cierre del proyecto:
Se denominan costes de eliminacin o retirada a aquellos que se producen durante el ciclo de vida del proyecto como consecuencia de la eliminacin, reciclaje o restauracin de los activos utilizados en el mismo. Pocas
veces son tenidos en cuenta ya que, habitualmente son absorbidos por el
cliente, no obstante, siempre se deben analizar, y en su caso, incluirlos en
el presupuesto ya que en ocasiones representan un importante coste que
puede incidir negativamente sobre el margen esperado. Entre otros, estaran los de eliminacin de elementos no reparables a lo largo de la vida del
proyecto y los de retirada y/o reciclaje, al cierre del proyecto, del material,
instalaciones etc. utilizadas en el mismo. Tambin se debe tener en cuenta
que, al final de un proyecto, algunos activos pueden tener un valor residual
que genere, con su venta, un saldo positivo.
Este CBS, como se ha indicado anteriormente, es una relacin jerarquizada y exhaustiva de los costes de materiales y mano de obra de un pro-
139
yecto a lo largo de su ciclo de vida, no obstante, habr que tener en cuenta

que, el mayor o menor peso de uno y otra depender de la naturaleza del
proyecto. As, en aquellos proyectos en los que la parte de materiales pesa
poco o incluso es nula, como es el caso de los proyectos de ingeniera o
servicios, el CBS se transforma en un desglose de actividades y tareas que
dan lugar a los paquetes de trabajo (Work Breakdown Structure WBS
cuyo concepto ya ha sido visto en el captulo 2. Dado que este desglose se
configura en forma de rbol (de tal forma que se incluyen en cada paquete
todos los costes materiales y humanos precisos para la realizacin de las
tareas relacionadas en el mismo), es fundamental que el 100% de los costes recogidos en la descomposicin de cada elemento de la WBS, en nivel
inferior o hijo, contenga el 100% de los costes aplicables al nivel superior
o elemento padre. Es habitual que en este tipo de proyectos, se hagan
coincidir los paquetes de trabajo con los hitos contractuales o entregables
al cliente.
2.2. La estimacin de los ingresos
La asignacin de los costes al proyecto dar en la mayora de los casos
el principal input o dato de entrada para el clculo del precio de la oferta
(coste + margen = precio). No obstante, la fijacin del precio por parte de
la empresa puede no tener en cuenta este clculo, siendo la competencia
u otros factores (precios convenidos, por resultados, flexibles, regulados,
etc.), los que condicionen el precio final del proyecto.
Con los precios calculados se procede a estimar los ingresos del proyecto, los cuales vendrn determinados por la facturacin realizada en cada
fase o hito contractual del proyecto, en base a la aplicacin de los precios
de venta sobre la parte ejecutada (trabajos realizados, volmenes de produccin, etc.).
2.3. La elaboracin de la oferta econmica
Con la realizacin del presupuesto de costes y la estimacin de ingresos,
estaremos en condiciones de preparar la oferta econmica, la cual deber
considerar todos los aspectos recogidos en la oferta tcnica. En este sentido,
es habitual establecer los precios del proyecto bsico junto con alternativas
que incluyen posibles mejoras presentadas como opcionales.
El contenido habitual de una oferta econmica queda reflejado en los
siguientes puntos:
t %FTDSJQDJOEFUBMMBEBEFMDPOUFOJEP FTUSVDUVSB VOJEBEFT DPNQPTJcin, caractersticas, etc.) incluidas en el precio del proyecto bsico.
140
GESTIN FINANCIERA
t &MQSFDJPEFWFOUBEFMQSPZFDUPCTJDP$POVODJFSUPEFTHMPTFTFHO
el detalle anterior.
t %FTDSJQDJOEFUBMMBEBEFQPTJCMFTNFKPSBT QSFTFOUBEBTDPNPPQDJPnales) no incluidas en el proyecto bsico.
t &MQSFDJPPDPUJ[BDJOEFMBTNFKPSBTNFODJPOBEBTFOFMQVOUPBOUFSJPS
t -BTDPOEJDJPOFTEFMQSFDJPPGFSUBEP
Fecha de validez del precio y frmula de revisin (si procede)

Inclusin, o no, de impuestos en el precio (IVA y otros).
Instrumento de pago: transferencia, cheque, pagar, letra, etc.
Forma de pago: contado, a plazo, por hitos contractuales, etc.
Plazos y condiciones de entrega: calendario de entregas y condiciones de transporte.
3. EL FLUJO DE CAJA DEL PROYECTO Y EL VALOR TEMPORAL DEL DINERO

3.1. El flujo de caja
En los proyectos, es preciso analizar la evolucin de los costes e ingresos a lo largo de la duracin del mismo. Por la misma razn todo el mundo
entiende que 1 de hoy vale ms que 1 maana, y es necesario considerar
la importancia de introducir el factor tiempo en el anlisis de un proyecto:
La inflacin reduce el valor del dinero y por tanto el poder de compra
futuro con respecto al actual. Debemos considerar por tanto la inflacin de todos los elementos del coste.
La incertidumbre aumenta a medida que el proyecto se alarga, por
lo que en proyectos de larga duracin debemos incorporar un factor
para contingencias o riesgos futuros.
Los costes del capital o costes financieros del proyecto cambiarn, al
hacerlo los tipos de inters, a lo largo de la vida del proyecto por lo
que tendremos que estimar su evolucin.
Denominamos, Flujo de Caja, Flujo Monetario o Flujo de Tesorera (en
ingls Cash-Flow) a la cantidad de efectivo disponible en cada periodo
(meses, trimestres, aos, etc.) del proyecto. Esto es, a la diferencia entre las
entradas de fondos (cobros) y las salidas (pagos) de cada periodo.
Conviene en este punto aclarar la diferencia entre los saldos contables y
saldos de caja (reales). Los primeros reflejan los costes en el momento en
que se conocen, mientras que los segundos lo hacen en el momento en que
se pagan. Por ejemplo: se compra un material a un proveedor y se acuerda
su pago a 60 das; el coste se contabiliza en el momento que se compra (el
141
mes de la adquisicin) pero el pago se retrasa dos meses. De igual forma

las fechas de ingreso y cobro suelen ser diferentes ya que, exceptuando
operaciones al contado, la fecha de emisin de la factura al cliente (fecha
contable) es siempre anterior a la fecha de cobro de la misma (fecha de
ingreso en caja).
En la mayora de las ocasiones y ante la dificultad de poder obtener los
clculos del Flujo de Caja del proyecto con precisin, se suele estimar su
valor, tal y como refleja el ejemplo de la figura 6.2, como el resultado de
la suma del beneficio, neto de impuestos, ms las amortizaciones ya que
stas, son el nico elemento de coste que no representar una salida real
de dinero.
Tabla 6.1. Cash-Flow del Proyecto.
Como podemos apreciar, el Cash-Flow es una primera estimacin fiable

de la rentabilidad esperada de un proyecto, pero es evidente que el concepto tiempo tiene una significativa influencia en su clculo. Por ello, a la
hora de analizar los costes futuros de un proyecto, que tendrn lugar a lo
largo de un periodo de tiempo, es fundamental familiarizarse con el concepto de valor presente y valor futuro.
142
GESTIN FINANCIERA
3.2. El descuento y la capitalizacin

Definimos el valor futuro FV,(Future Value), como el valor que una
cantidad actual PV (Present Value) va a tener en un periodo de tiempo determinado, t, si se le aplica una tasa de inters i.
Para su clculo utilizamos la conocida frmula de inters compuesto.
FV=PV(1+i)t.
Se denomina capitalizar, al proceso de determinacin del valor futuro
de una cantidad actual. Ejemplo: Una valor actual de 10.000 a un inters
anual del 3%, durante 5 aos, dara un valor futuro de [10.000(1,03)5]=
11.592,74.
A la inversa, el valor presente PV (Present Value) ser el resultado de
despejar ste, en la frmula anterior, PV = FV / (1 + i)t.
Se denomina descontar, al proceso de calcular el valor actual de una
cantidad futura. Ejemplo: Si al cabo de 5 aos esperamos obtener una suma
de 10.000 y queremos conocer cul sera su valor actual, podemos calcularlo descontando el importe con el tipo de inters del 3% (tasa de descuento) que sera la rentabilidad que se querra obtener por esa cantidad en ese
periodo. El resultado sera que el valor actual de los 10.000 a la fecha de
hoy tan slo sera de [10.000/(1,03)5]= 8.626,08.
Este clculo ser especialmente til en el caso de que tengamos que
decidir sobre alternativas de diferentes proyectos ya que, para poder compararlos, debemos hacerlo en las mismas bases (habitualmente al momento
actual o del anlisis). Para ello, cuando se quiere conocer el valor actual
de un proyecto, tendremos que descontar los beneficios futuros esperados
(Flujos de Caja) a la tasa de rentabilidad (conocida como tasa de descuento)
que podramos obtener con proyectos similares. La determinacin de la tasa
de rentabilidad con la que debemos descontar los flujos de caja futuros de
un proyecto, suele ser decisin de la direccin de la empresa en base a la
rentabilidad esperada por los promotores del proyecto, al coste de su capital, o al obtenido en proyectos similares. Esto lo veremos con ms detalle
en las secciones 6.5 y 6.6.
143
4. EL CONTROL ECONMICO DEL PROYECTO

Una vez aprobada y adjudicada la oferta de un proyecto, la labor fundamental del gestor financiero (habitualmente el jefe de proyecto) ser la
de velar para que se cumpla el objetivo econmico del mismo a fin de
obtener el margen o beneficio previsto inicialmente. Para ello, no slo se
debe controlar la evolucin de los costes que se van produciendo a medida
que el proyecto avanza (detectando y corrigiendo sus posibles desviaciones
respecto al presupuesto inicial), sino la correcta ejecucin, en el tiempo, de
los trabajos previstos.
En muchas ocasiones es complejo conocer el avance real de un proyecto
ya que las tcnicas basadas en comparar el nmero de horas trabajadas, o
el de paquetes de trabajo terminados, dan estimaciones de avance confusas
por la razn de que no todas las horas rinden igual, ni todas las tareas suponen el mismo esfuerzo. Por ello, es conviene utilizar ms de un mtodo de
control entre los que destacamos el anlisis del valor ganado, los informes
de progreso y el ciclo del control en el PERT/COSTE.
Hay que destacar que, desde el punto de vista econmico del proyecto,
cualquiera de las herramientas a utilizar tiene limitaciones e imprecisiones
que conviene conocer ya que los nmeros, si no estn debidamente contrastados y fundamentados, pueden conducir a una toma de decisiones
errnea. Por ello, no se debe informar del estado de un proyecto por el
comportamiento de 4 o 5 indicadores por muy bien fundamentados que
estn, sino que deber siempre realizarse en base a un anlisis ms profundo de los resultados en el que no se debe obviar la comunicacin con los
responsables del proyecto.
4.1. El anlisis o gestin del Valor Ganado
A la hora de controlar la ejecucin de un proyecto se debe contar con
herramientas que permitan una buena aproximacin a su estado real y por
tanto conocer las desviaciones, tanto en costes como en tareas, respecto a
lo inicialmente presupuestado y planificado. Esto se logra con el anlisis
del Valor Ganado (EVM, Earned Value Management) que es un mtodo de
gestin de proyectos que integra coste, tiempo y trabajo realizado (o alcance) y permite, adems, realizar predicciones sobre los resultados finales del
proyecto.
En la gestin del proyecto, el EV es el que se obtiene a medida que se
van ejecutando las tareas o actividades del proyecto y nos permite, por
tanto, establecer un mtodo para determinar el estado del proyecto y el progreso conseguido a una determinada fecha con relacin a lo previamente
planificado. Tambin permite obtener la base para el anlisis de rendimien-
144
GESTIN FINANCIERA
to de costes y, as estimar con precisin el coste del proyecto antes de que

se complete.
Como fcilmente puede deducirse, para poder obtener una medicin
de lo actualmente conseguido contra una base de referencia, es fundamental preparar una WBS completa del proyecto donde para cada tarea estn
definidas las fechas de inicio y fin, se tenga asignado un coste especfico,
y se pueda evaluar objetivamente. Adems, es imprescindible disponer de
un mtodo eficaz para recopilar la informacin acerca de los costes reales
incurridos a la fecha (llamada fecha de corte) en la que se quiera realizar el
anlisis del EV. Por ello, los tres pilares en los que se asienta el mtodo son:
El WBS, la planificacin de tareas en el tiempo, y el presupuesto.
La norma estndar americana ANSI/EIA-748 EVMS (Earned Value Management Systems) del 2007 es el documento bsico para implementar el
sistema de valor ganado en una organizacin. La metodologa dispone de
su propio lxico y conceptos que son los que a continuacin se citan y cuya
representacin grfica aparece en la figura 6.2.
t #"$ #VEHFUBU$PNQMFUJPO
QSFTVQVFTUPQSFWJTUPJOJDJBMNFOUFQBSB
el proyecto total.
t &7 &BSOFE7BMVF
WBMPSNPOFUBSJPEFMUSBCBKPBMDBO[BEPFOFMQFSPdo de evaluacin.
t "$ "DUVBM$PTU
DPTUFSFBMEFMUSBCBKPSFBMJ[BEPBMBGFDIB EFDPSUF

del anlisis.
t 17 1MBOOFE7BMVF
WBMPSNPOFUBSJPQSFWJTUPFOFMQMBOEFQSPZFDUP
para una tarea determinada de la WBS:
t $7 $PTU 7BSJBODF
NFEJEB RVF JOEJDB MB EFTWJBDJO EF MPT DPTUFT
respecto del presupuesto previsto. CV = EV-AC. Si CV<0 estaremos
por encima del presupuesto y si CV> 0 estaremos por debajo.
t 47 4DIFEVMF7BSJBODF
NFEJEBRVFJOEJDBFMQPSDFOUBKFEFBWBODF
respecto del plan inicialmente previsto: SV=EV-PV. Si SV<0 indica
que nos estamos retrasando y si SV> 0 estaremos por delante del
tiempo programado.
Estas dos magnitudes CV y SV son valores absolutos que indican si la
situacin es favorable o desfavorable pero no dan idea de magnitud por lo
que es conveniente expresarlas en % para que se pueda ver el valor relativo
de la situacin en la fecha del anlisis. Esto lo vemos a travs de los ndices
de desempeo CPI y SPI, que debern siempre ser 1.
t $1* $PTU1FSGPSNBODF*OEFY
OEJDFEFMSFOEJNJFOUPEFDBEBVOJEBE
monetaria invertida en el proyecto. CPI= EV/AC. Un CPI de 0,9 indica
que por cada euro de los fondos del proyecto, obtenemos slo 90
cntimos.
145
t 41* 4DIFEVMF1FSGPSNBODF*OEFY
QPSDFOUBKFEFBWBODFSFTQFDUPEFM
plan previsto (ndice de eficiencia relativa a cunto valor se ha conseguido realmente respecto del que est programado para ser llevado
a cabo) SPI = EV/PV.
Si nos encontramos en una situacin con un CPI desfavorable, tendramos que analizar las medidas a tomar para poder finalizar el proyecto dentro del presupuesto. Para ayudar en este proceso contamos con un ndice
que en los ltimos aos se ha mostrado como altamente eficaz en el anlisis del Valor Ganado [J.Alsina, 2011] y que es el ndice de desempeo por
concluir, TCPI.
t 5$1* 5P $PNQMFUF 1FSGPSNBODF *OEFY
OEJDF EF EFTFNQFP QPS
concluir. Se calcula como el cociente entre lo que nos queda de
trabajo por realizar y los fondos que nos quedan disponibles. As si
calculamos el TCPI para completar el proyecto segn el presupuesto
inicial sera TCPI = (BAC-EV) / (BAC-AC).
Adems del anterior, y a travs de los ndices EAC, ETC y VAC, el analista podr predecir que pasara en el proyecto de continuar la tendencia
actual.
t &"$ &TUJNBUFBU$PNQMFUJPO
QSFWJTJOEFMDPTUFUPUBMBMGJOBMJ[BSFM
proyecto segn los datos actuales. EAC = BAC/CPI.
t &5$ &TUJNBUF 5JNF UP $PNQMFUF
FTUJNBDJO EFM UJFNQP UPUBM OFcesario para poder completar el proyecto. ETC = [(BAC/SPI)/(BAC/
tiempo)].
t 7"$ 7BSJBUJPO BU $PNQMFUJPO
WBSJBDJO B MB UFSNJOBDJO JOEJDB MP
que nos hemos excedido del presupuesto autorizado. VAC = EAC-BAC.
La variacin relativa al presupuesto aprobado calculado como porcentaje ser. VAC% = VAC/BAC.
146
GESTIN FINANCIERA
Figura 6.2. Representacin grfica, conceptos EV.
Ejemplo: Se desarrolla el siguiente ejemplo con el objeto de facilitar su

aplicacin: En un Proyecto determinado, que debe ser realizado (consideramos para simplificar que todas las tareas se realizan de forma lineal en el
mismo perodo de tiempo) en 24 meses, se cuenta con un presupuesto total
(BAC) de 50.000. Transcurridos 10 meses desde el inicio de los trabajos, el
avance del proyecto es del 32,50% y el coste real incurrido a la fecha (AC)
asciende a 17.500. Realizamos el anlisis del valor ganado midiendo cada
una de las siguientes magnitudes:
1. Se calcula el Valor Planificado para la fecha de corte. PV = 20.833;
[50.000 x (10/24)].
2. Se calcula el Valor Ganado en los 4 meses. EV = 16.250;
(50.000*0,325).
3. La Variacin en Coste da un resultado negativo CV = EV-AC = -1250,
lo que, al ser inferior a cero (CV<0), indica que se esta por encima
147
del valor planificado del presupuesto a la fecha, es decir, la situacin

es desfavorable ya que el coste es superior al planificado.
4. La Variacin en Tiempo, de igual modo, es desfavorable ya que tambin es inferior a cero (SV<0), SV = EV-PV = -4.583 lo que indica un
retraso en el cronograma.
5. % de Variacin Coste. CV (%) = CV/EV = 0,0769. Esto indica que se
est en una desviacin de costes del 7,7% por encima de la cantidad
prevista
6. % de Variacin Tiempo. SV (%) = SV/PV = - 0,2199 Esto indica que
se lleva un retraso del 22% del tiempo previsto a la fecha.
7. ndice de rendimiento (desempeo) del Coste CPI = EV/AC = 0,9285.
Al ser menor que 1, indica que el rendimiento de cada unidad invertida en el proyecto, ha perdido un 7% del valor.
8. ndice de rendimiento (desempeo) del Tiempo SPI= EV/PV = 0,780.
Al ser menor a la unidad, indica que la cantidad de valor que se ha
conseguido realmente es un 78% respecto del que est programado
para ser llevado a cabo.
Con estos datos podemos predecir qu pasara en el proyecto de
continuar la tendencia actual. Para ello se realizan los siguientes
clculos.
9. El ndice de desempeo para concluir TCPI = (BAC-EV)/(BAC-AC)
= 33.750/32.500 = 1,038, lo que significa que para poder terminar el
proyecto debemos tomar acciones para lograr incrementar la productividad del proyecto.
10. Coste Estimado a la Finalizacin del proyecto EAC = BAC/CPI =
53.850.
11. Tiempo Estimado para Finalizar el proyecto ETC = [(BAC/SPI)/(BAC/
tiempo)] = 30,77 meses lo que significa que vamos a tardar casi 7
meses ms de los previsto.
12. A la finalizacin, si no hemos tomado las medidas oportunas nos
habremos excedido en VAC= EAC-BAC = 3.850 del presupuesto autorizado.
Como vemos, a travs del ejemplo, el anlisis del valor ganado permite
detectar los desfases en tiempo y coste de un proyecto en marcha, al tiempo que ofrece una prediccin final del resultado, por ello es un mtodo
muy utilizado entre los gestores econmicos del proyecto. No obstante,
conviene recordar que, para ello, el mtodo requiere de: La identificacin
de cada hito (entregable) del proyecto; El desarrollo de un cronograma para
la terminacin de cada paquete de trabajo que complete el hito; La asignacin de un valor de coste para cada paquete (entregable).
148
GESTIN FINANCIERA
No obstante, tal y como se deca al inicio, no se debe olvidar que todas

las herramientas tienen limitaciones. Las mayores crticas a esta metodologa
se basan en su falta de perspectiva financiera ya que no tiene en cuenta
el carcter financiero de los costes dado que los pagos anticipados y los
diferidos alteran el resultado del CPI. Adems, no sirve para analizar los
proyectos una vez finalizados ya que, a su terminacin el ndice de desempeo SPI siempre es igual a 1.
4.2. Los informes de progreso
Otra herramienta habitual y sencilla para llevar a cabo el control econmico del proyecto y poder, por tanto, comparar los valores reales con
las estimaciones iniciales, es la que nos proporcionan los informes de progreso. Estos, deben realizarse con la periodicidad necesaria para mantener
un exhaustivo control del proyecto y deben contener al menos la siguiente
informacin:
Fechas reales de inicio y finalizacin del proyecto.
Coste de los recursos consumidos (mano de obra, materiales, gastos,
etc.) a la fecha del informe.
Ingresos generados (facturacin realizada a la fecha del informe).
Desviaciones respecto al presupuesto asignado a la fecha.
Con esta informacin, podremos elaborar un resumen econmico como
el que muestra la tabla 6.2.
Este sencillo informe nos ofrece una valiosa perspectiva acerca de la
marcha del proyecto ya que, adems de la informacin antes citada, podremos ver: el porcentaje de horas por categoras consumidas; el tiempo
(horas) pendientes para la terminacin de los trabajos; el remanente con el
porcentaje de facturacin pendiente; los costes agregados reales del proyecto a la fecha; los ingresos reales con detalle de las facturaciones realizadas,
etc.
No obstante, esta herramienta no ser til para la direccin si no se
acompaa de un informe escrito donde se detallen y expliquen las desviaciones ms significativas, profundizando sobre las causas que las han
ocasionado y proponiendo las oportunas medidas correctoras.
4.3. El Ciclo de Control del PERT/COSTE
El PERT/Coste fue en su momento una extensin del PERT/Tiempo (ya
visto con anterioridad) y se ha demostrado como un sistema muy eficaz
para minimizar los costes de un proyecto. Aunque el sistema tiene multitud
149
150
Tabla 6.2. Informe de progreso econmico de un proyecto.

RESULTA DO (B-A )
Margen del proyecto a la Fecha
341
341
341
A .4 Subtotal Otros Gas tos

TOTA L COSTES (A .1 + A .2 + A .3 + A .4)
Pers onal A dtivo

G.Financieros
A .3 Subtotal Compras y Otros Cos tes

M aterias Primas
A lquileres
Energia,Luz,Tfno
3
Empres a Y
A .2 Subtotal , Subcontrataciones
Empres a X
A .1. Subtotal Pers onal Directo

Categoria
Jefe Proyecto
Ingeniero Senior
Ingeniero Junior
3
PRESUPUESTO TOTA L
PRESUPUESTO TOTA L
PRESUPUESTO TOTA L
HORA S
COSTE
PREVISTO FECHA
PREVISTO FECHA
PREVISTO FECHA
HORA S
COSTE
REA L FECHA
REA L FECHA
REA L FECHA
HORA S COSTE
HORAS
FECHA FIN:
FECHA INICIO:
FECHA INFORM E
A . COSTES DEL PROYECTO
REFERENCIA
RESPONSA BLE
PROYECTO:
CLIENTE:
COS TE
REM A NENTE A FECHA
REM A NENTE A FECHA
REM A NENTE A FECHA

HORA S
COSTE
GESTIN FINANCIERA
de variantes dependiendo del proyecto, el ciclo de control comprende, habitualmente, las siguientes fases:
Aprobacin del presupuesto.
Fecha acordada (con el cliente) para el comienzo de los trabajos.
Registro y archivo cronolgico de todos los informes sobre tiempos
reales, costes incurridos y facturaciones realizadas.
Elaboracin y anlisis de los informes del PERT/Coste.
Evaluacin de la situacin del proyecto.
Propuesta y decisin, si procede, sobre acciones correctoras.
Revisin, cuando sea necesario, de la programacin y presupuesto.
La periodicidad del control la marcar el jefe del proyecto y ser diferente dependiendo del tipo y complejidad de proyecto. As, habr proyectos
que requieran un control mensual mientras que otros servir con un informe trimestral, semestral o anual.
De todo el ciclo de control, la fase fundamental es la de preparacin de
informes. Aunque el tipo y contenido de los informes este ligado al tipo de
proyecto, podemos establecer los cinco informes considerados bsicos del
PERT/Coste: Mano de obra; Coste del proyecto; Previsin; Puntos crticos;
Informe de resumen a direccin.
5. MTODOS DE ANLISIS DE LA RENTABILIDAD DE PROYECTOS

Existen dos grandes grupos de mtodos de anlisis de inversiones:
t "RVFMMPTRVFOPUJFOFOFODVFOUBRVFFMWBMPSEFMPTGMVKPTFDPONJcos depende del tiempo.
t "RVFMMPTRVFTDPOUFNQMBOEJDIBDBSBDUFSTUJDB
Pese a que el primer grupo cuenta con un importante error de partida,
se va a describir uno de ellos debido a su amplia utilizacin entre inversores como mtodo rpido de decisin. En general, los inversores no suelen
utilizar un nico mtodo de valoracin sino que se contrastan los resultados
obtenidos con diferentes mtodos, procurando que la decisin final tenga
en cuenta cada uno de los mtodos.
5.1.
Mtodos que no utilizan la actualizacin de los flujos de caja:

mtodo de periodo de recuperacin del capital (PAY-BACK)
Se define el periodo de recuperacin del capital como el tiempo que ser

necesario para recuperar el importe inicial desembolsado en una inversin.
El modo de calcularlo es determinar la suma de todos los flujos de caja del
151
proyecto (sin descontar) en cada periodo de proyecciones y observar cuando cambia de signo dicha suma tal y como se observa en la figura 6.3.
Figura 6.3. Ejemplo de flujos de caja para el mtodo Pay Back.
El Pay-Back de la inversin ser de 3,15 aos (suponiendo que los ingresos del ltimo ao son obtenidos de forma lineal). Utilizando este mtodo,
un inversor aceptar una inversin si el periodo de recuperacin calculado
es menor que el lmite establecido para sus inversiones. En el ejemplo se
aceptar la inversin si el periodo de recuperacin mximo es superior a
3,15 aos.
El mtodo de Pay-Back da la misma importancia a todos los flujos de
caja, con independencia de cundo se produzcan, y no considera todos los
flujos de caja que se obtienen despus de producirse la recuperacin del
capital (uno de los principales defectos de este mtodo). El criterio prima
la liquidez de la inversin frente a su rentabilidad, lo que supone dar mayor prioridad a los proyectos con menor duracin. Tiene como ventajas su
facilidad de clculo y lo intuitivo de su resultado. Su uso se suele limitar a
anlisis iniciales de viabilidad.
152
GESTIN FINANCIERA
5.2.
Mtodos que tienen en cuenta el valor del dinero en el tiempo:

criterio del Valor Actual Neto (VAN)
El valor actual neto (VAN) mide el valor actual del resultado de los cobros menos los pagos de cada periodo de un proyecto. El VAN es la suma
del valor presente de todos los flujos que se obtendran por el proyecto en
el horizonte de funcionamiento del mismo.
Supongamos un proyecto en el que se invierte A unidades en el periodo inicial, y del mismo se obtienen F1, F2, , Fn, en cada uno de los
periodos siguientes. Matemticamente:
Frmula 6.1
y si i1=i2 == in
Frmula 6.2.
Una empresa podr acometer nicamente las inversiones que tengan

un VAN positivo y entre stas, sern preferibles las inversiones con el VAN
superior.
Supongamos los siguientes proyectos:
Gastos
Ingresos
0
1.000
1
1.000
200
3
100
300
4
400
5
500
6
500
7
500
500
Proyecto 1. Proyecto estratgico para la empresa.
Pagos
Cobros
0
3.000
2
700
3
700
4
700
5
700
6
700
Proyecto 2. Proyecto de actividad tradicional.
153
7
700
500
El resultado del VAN en funcin de la tasa de descuento utilizada es el

siguiente.
Proyecto 1
Tasa de descuento
3%
5%
7%
Proyecto 2
Tasa de descuento
8%
10%
12 %
VAN
478
296
136
VAN
527
305
104
Tabla 6.3. Resultados VAN con diferentes Tasas de descuento.
En funcin de las tasas de rentabilidad exigidas a cada tipo de proyecto

por la empresa, la eleccin ser diferente (Un mismo inversor puede utilizar
tasas de descuento diferentes para diferentes proyectos en funcin de las
caractersticas de los mismos). As por ejemplo, si el criterio del inversor es
exigir un 5% a las inversiones estratgicas y un 10% a las inversiones rutinarias, el proyecto elegido como prioritario sera el proyecto 2.
Partiendo del VAN se puede calcular la tasa de rentabilidad del Proyecto:
Frmula 6.3.
5.3. Criterio de la tasa interna de retorno (TIR)

La Tasa Interna de Retorno (TIR) de un proyecto es la tasa de descuento
que hace que el valor actual neto de un proyecto sea igual a cero. Matemticamente:
Frmula 6.4.
siendo r la TIR del Proyecto. De la expresin anterior se puede deducir:
Frmula 6.5.
154
GESTIN FINANCIERA
expresin que coincide con la amortizacin por el mtodo de anualidad

constante de un prstamo de cantidad A, a un tipo de inters r tal y
como se muestra en la figura 6.4 donde A es igual a 3.313.
Figura 6.4. Ejemplo de Flujos de Caja para el mtodo TIR.
La TIR del Proyecto es del 10% ya que:
Frmula 6.6.
Si dicho proyecto se financiase con un prstamo de 3.313 a un 10% de

inters compuesto, el resultado para el accionista sera igual a cero, es decir,
el proyecto slo proporcionara caja para amortizar el prstamo y pagar los
intereses.
Periodo
1
2
3
Capital vivo
principio
3.313
2.644
908
Intereses
Anualidad
331
264
92
Amortizacin
principal
1.000
2.000
1.000
Tabla 6.4. Cuotas de amortizacin de un prstamo.
155
669
1.736
908
En general, el criterio de aceptacin de un proyecto ser que la TIR sea

superior al coste de los recursos utilizados para la inversin y se elegir de
entre los proyectos, aquel que mayor TIR tenga.
5.4. Relacin entre el TIR y el VAN
Los mtodos de VAN y TIR suelen coincidir a la hora de determinar qu
inversiones son realizables y cules no. Sin embargo, pueden diferir a la
hora priorizar entre varios proyectos. Supongamos dos proyectos (Uno y
Dos) cuyos flujos de caja se representan en la tabla 6.5:
Proyecto
Uno
Dos
1
-180
-180
2
15
150
3
90
75
165
15
Tabla 6.5. Flujos de caja de proyectos Uno y Dos.
Usando el VAN con una tasa de descuento del 10%, elegiramos el proyecto Uno:
VAN(Uno) = 32
VAN(Dos) = 29,6
Sin embargo, calculando el TIR seleccionaramos el proyecto Dos.
TIR (Uno): 17,4
TIR (Dos): 22,8
La figura 6.5 representa grficamente el VAN de ambos proyectos variando la tasa de descuento:
156
GESTIN FINANCIERA
Figura 6.5. Comparacin entre TIR y VAN.
6. TASA DE DESCUENTO A UTILIZAR-COSTE DE CAPITAL (Ke)

Como se ha comentado anteriormente, a la hora de decidir si la rentabilidad obtenida por un proyecto es adecuada es necesario conocer, como
referencia, cul es el coste del capital invertido en un proyecto. Para ello
el modelo ms utilizado es el denominado del Capital Asset Pricing Model
(CAPM), que trata de determinar ese coste estimando la rentabilidad que
se obtendra invirtiendo ese capital en acciones con un nivel de riesgo similar al proyecto. Para ello utiliza la frmula 6.8:
Ke = rf + x rm
Frmula 6.7.
Siendo:
Ke = Coste de los recursos de los accionistas
rf = Tasa de inters sin riesgo
= Volatilidad de la accin respecto al mercado
rm = Prima de riesgo del mercado de acciones
157
La frmula 6.7 refleja que el coste de los recursos de los accionistas es

igual a la rentabilidad esperada en una inversin sin riesgo (rf) ms una
prima que se obtiene multiplicando:
t MB SFOUBCJMJEBE BEJDJPOBM EF JOWFSUJS FO BDDJPOFT TPCSF MB SFOUB GJKB
(rm)
t QPSVOGBDUPSCFUB i) que ajusta dicha prima global a la situacin
concreta de la empresa o proyecto en el que se realiza la inversin;
Ms concretamente:
t -BUBTBEFJOUFSTEFVOBJOWFSTJOTJOSJFTHP irf), que se suele utilizar es la deuda del estado. Tradicionalmente se suele usar el tipo de
las Obligaciones del Estado a 10 aos.
t -BSFOUBCJMJEBEBEJDJPOBMEFJOWFSUJSFOBDDJPOFT PQSJNBEFSJFTHP
del mercado (rm), es la rentabilidad adicional que se requiere a una
inversin en acciones sobre una inversin considerada sin riesgo. Es
un valor medio de mercado (no para una accin concreta) que se
suele fijar como la rentabilidad histrica adicional que ha ofrecido el
mercado de acciones sobre la deuda del estado en un periodo prolongado de tiempo. Esta prima vara dependiendo de las diferentes
fuentes consultadas (analistas de acciones, estudios de las sociedades
de Bolsa, estimaciones de estudios acadmicos, etc.). Histricamente
en el mercado espaol la prima se ha movido en un rango de entre
el 4% y el 7%.
t &MGBDUPS se calcula comparando la volatilidad de las acciones de
una empresa concreta con respecto a la volatilidad del mercado. Es
una medida estadstica histrica de la volatilidad de la accin con
relacin a la volatilidad del mercado: cuanto mayor volatilidad tenga
la variacin del precio de la accin respecto a la variacin media del
mercado, ms riesgo tiene esa accin y, por tanto, ms rentabilidad
se le debe exigir. El valor lo publican Reuter, Bloomberg, etc., para
todas las compaas cotizadas.
As por ejemplo, si la de la compaa es igual a 1, querra decir que si
el mercado de acciones sube, la accin de esa compaa sube en la misma
medida, y si el mercado de acciones baja, la accin hace lo mismo. Cuanto
ms se aleje la del valor 1 quiere decir que la accin es ms sensible que
el mercado ( > 1) o amortigua las variaciones del mercado en su conjunto
( < 1).
Si la compaa proyecto sobre la que se quiere calcular el coste de
capital no cotiza en mercado (es lo habitual), la , se suele estimar comparndola con las de compaas cotizadas similares (del mismo sector,
tamao, etc.).
158
GESTIN FINANCIERA
7. FUENTES DE FINANCIACIN DE LOS PROYECTOS

7.1. Descripcin de las diferentes fuentes de financiacin
Como toda actividad empresarial, el desarrollo de proyectos requiere la
financiacin de los mismos, bien en forma de aportaciones de los socios
(capital o instrumentos asociados al capital) o bien por aportaciones externas. Una forma simplificada de clasificar las diferentes fuentes de financiacin puede ser la indicada en la figura 6.6.
Adicionalmente a las mencionadas, existen fuentes de financiacin mixtas como por ejemplo la deuda subordinada, los prstamos participativos,
los instrumentos hbridos de capital, etc. La descripcin de dichas fuentes
de financiacin excede en principio el objetivo del presente captulo. Siguiendo esa clasificacin, a continuacin describiremos las principales caractersticas de las fuentes de financiacin ms utilizadas.
7.2. Fuentes de financiacin de capital
El capital es el importe arriesgado por el inversor en el desarrollo del
proyecto. En el caso de que el proyecto se desarrolle en una sociedad (empresa) especfica, el capital estar representado por las acciones de dicha
sociedad. Tienen tambin consideracin de capital otras figuras como los
prstamos participativos de accionistas o los beneficios generados por el
proyecto y no distribuidos.
Desde el punto de vista de los flujos de caja su principal caracterstica es
que no puede exigir una retribucin obligatoria de los fondos del proyecto
(frente a la deuda que tiene un calendario prefijado de pago de intereses y
amortizacin).
7.3. Fuentes de financiacin no de capital
a) Financiacin bancaria: prstamos y cuentas de crditos
Importes aportados por terceros (normalmente entidades financieras)
a cambio del pago de unos intereses y con una calendario fijo de devolucin. Los prstamos y las cuentas de crdito son los instrumentos
habituales utilizados por las entidades financieras para la financiacin de
empresas y proyectos existiendo gran variedad de opciones (diferentes
plazos, garantas requeridas, facilidades de disposicin, forma de pago de
intereses, etc.).
159
Figura 6.6. Fuentes de financiacin.
160
GESTIN FINANCIERA
b) Leasing
El leasing es un contrato cuyo objetivo es la cesin a un usuario del uso
de bienes a cambio del abono peridico de unas cuotas. El contrato incluye
siempre una opcin de compra a su trmino, a favor del usuario por un
precio denominado valor residual.
En un leasing la entidad financiera adquiere un bien (previamente seleccionado por el cliente) y cede su uso por un perodo de tiempo determinado al cliente que podr adquirirlo al final del periodo por el valor
residual. Las cuotas de leasing son la contraprestacin que paga el cliente
por la cesin del bien.
La operacin leasing presenta ciertas ventajas para el usuario que vale
la pena destacar:
t -BTDVPUBTTPOEFEVDJCMFTDPNPHBTUPTBFGFDUPTGJTDBMFT BIPSSPGJTDBM

t -BTDVPUBTQFOEJFOUFTEFQBHPOPTFSFHJTUSBODPNPEFVEBFOFMCBlance del usuario.
c) Financiacin con deuda de mercados organizados (bonos)
Los bonos constituyen una alternativa de financiacin externa para un
proyecto. La compaa emite obligaciones de cara a terceros (inversores
normalmente fondos de inversin, compaas de seguros, etc.) para la captacin de fondos y se compromete a pagarlos en una fecha futura junto con
los intereses acordados (denominado cupn del bono).
Las caractersticas de dichos bonos suelen ser:
Plazos normalmente superiores al ao (normalmente 3-5 aos).
Tiene un coste de emisin superior al de la deuda bancaria pero, sin
embargo, el coste financiero (intereses) suele ser menor.
Una vez emitidos tienen reducida flexibilidad para cambiar cualquier
caracterstica.
Suele requerir la intervencin de una agencia de calificacin para
asignarle un rating de calidad crediticia (el cual a su vez determina el
tipo de inters del bono).
Puede cotizar en mercado de renta fija (de forma similar a los mercados de acciones).
d) Project Finance (Financiacin de Proyectos)
Modelo de financiacin que se sustenta en la capacidad de un proyecto
para generar flujos de caja suficientes para atender la devolucin de la deuda. Es analizado en profundidad en el captulo 7.
161
7.4. Fuentes de financiacin pblica

Cada pas cuenta con organismos encargados del fomento y apoyo de
actividades empresariales que se consideran de inters nacional. En Espaa, tanto a nivel nacional como autonmico, existen diferentes organismos
cuyo principal objetivo es la financiacin de actividades empresariales y
proyectos de inversin normalmente mediante prstamos con condiciones
favorables o subvenciones.
La obtencin prctica de este tipo de financiacin requiere que las caractersticas del proyecto se acomoden a los requisitos de cada organismo
y, en ese caso, una tramitacin administrativa para su consecucin. En las
pginas web de cada Ministerio y organismo pblico suelen venir detallados los requisitos y documentacin necesaria para la tramitacin.
8. ANLISIS DEL NIVEL DE DEUDA DEL PROYECTO

Sin tratar de realizar un estudio completo de la estructura ptima de
capital (proporcin de capital y deuda), analizaremos a continuacin el
efecto de la deuda sobre la rentabilidad de los proyectos. Supongamos un
Proyecto que, tras la realizacin del anlisis del fujo de caja operativo proyectado, presenta:
t 6OBTOFDFTJEBEFTEFGJOBODJBDJOEF..EF&VSPT
t 6O'MVKPEF$BKBEF0QFSBDJPOFT DBTIGMPXPQFSBUJWP
EF..EF
Euros.
Dichas necesidades debern ser satisfechas mediante una combinacin
de deuda y capital. Analicemos el efecto de utilizar diferentes proporciones
de deuda y capital (la proporcin entre deuda y capital se la suele denominar apalancamiento o en ingls leverage) en el cash flow final del
Proyecto.
En un primer ejemplo (incluido en la tabla 6.6) supongamos que el coste
financiero de la deuda es del 5% anual y que dicho coste no depende de la
cantidad de deuda del proyecto.
162
GESTIN FINANCIERA
Tabla 6.6. Clculo de rendimiento del capital.
De esta manera puede apreciarse cmo un mayor endeudamiento aumenta de la rentabilidad financiera debido a que la reduccin del importe
del capital invertido compensa con creces la disminucin del beneficio neto
asociada al coste financiero.
Sin embargo, este efecto matemtico debe ser matizado por las siguientes razones:
El coste de la deuda no es independiente de la cantidad de deuda.
La simplificacin realizada de que el coste de la deuda se mantiene constante a medida que aumenta el apalancamiento no es realista (ni siquiera
en la pocas de abundancia de crdito bancario). Las entidades financieras
considerarn que a partir de cierto nivel de deuda el proyecto tiene un riesgo
mayor y, consiguientemente subirn el precio de la deuda.
No se puede conseguir deuda si se trata de apalancar demasiado el

proyecto.
El aumento indefinido de la deuda no es posible en la prctica debido a
que las entidades financieras no estarn dispuestas a prestar por encima de
cierto nivel deuda que, segn su estimacin, el proyecto no pueda repagar.
9. REFERENCIAS
ALSINA, J. PMP., Gestin de valor ganado EVM, Project Charter S.A., 2011.
KLASTORIN, T., Project Management: Tools and Trade-Offs, Profit Editorial I, 2010.
LUKAS, J. A., Earned Value Analysis-Why it Doesnt Work, PECCE, 2008.
163
CAPTULO 7
FINANCIACIN DE PROYECTOS
Alberto Manrique Navas
igo Velzquez Prado
1. INTRODUCCIN
El objetivo del presente captulo es profundizar en los aspectos fundamentales de la financiacin de proyectos para que el gestor de los mismos
conozca las implicaciones de sus decisiones a la hora de financiarlos. Especficamente analizaremos las implicaciones cuando la financiacin se realiza
bajo una estructura denominada Project Finance.
En concreto, los aspectos que se desarrollan en el presente captulo son:
t 3FRVJTJUPTRVFEFCFDVNQMJSVOQSPZFDUPQBSBTFSGJOBODJBEPCBKPVO
esquema Project Finance.
t %FTDSJQDJOEFMBTEJTUJOUBTQBSUFTJOUFSWJOJFOUFTZTVTGVODJPOFTFO
este tipo de financiacin.
t "MUFSOBUJWBTEFGJOBODJBDJOQBSBMPTQSPZFDUPTZFMFDDJOEFMBFTtructura de financiacin ms adecuada.
t 5BSFBT RVF TF EFCFO DPNQMFUBS QBSB MB GJOBODJBDJO EFM QSPZFDUP
(cierre de la financiacin) y posterior seguimiento financiero del
mismo en su fase de explotacin.
El Project Finance tuvo su origen en Inglaterra y en su uso cotidiano se
suelen utilizar los nombres originales en ingls para varios de sus conceptos. Por esa razn se ha decidido emplear la terminologa original inglesa
sin su traduccin al castellano.
165
2. GESTIN DE LOS RECURSOS FINANCIEROS
DEL PROYECTO: CARACTERSTICAS
DE LA FINANCIACIN EXTERNA
Los recursos propios de los que dispone una empresa para la financiacin de un proyecto son limitados. En caso de querer acometer nuevos
proyectos y no disponer de recursos financieros propios suficientes, existen
dos posibilidades para poder crecer: incrementar los recursos propios va
ampliaciones de capital o solicitar financiacin ajena.
La financiacin ajena se suele clasificar en dos tipos: Financiacin Corporativa o con estructura Project Finance.
2.1. Project Finance: definicin y caractersticas
Una financiacin con estructura Project Finance toma nicamente en
consideracin los flujos de caja (cash flow) que ste genera y no (o solo
de forma limitada) el patrimonio de sus accionistas (tambin llamados promotores o spnsors). Sus caractersticas son:
Recurso limitado a los accionistas del proyecto: en principio los financiadores del proyecto no cuentan con la garanta del patrimonio
de los accionistas para el repago de la deuda aportada (a esto se le
denomina no tener recurso a los accionistas). La responsabilidad de
los accionistas se limita al capital aportado sin garantas adicionales
salvo para mitigar aquellos riesgos que la entidad financiera no est
dispuesta a asumir y se acuerden previamente.
Plazos largos de financiacin: limitados por el tiempo que requiera el
proyecto para generar ingresos y repagar la deuda (en funcin de la
vida til de los activos, de la duracin de los contratos de concesin,
etc.).
Estructura de financiacin (forma de repago, garantas requeridas,
etc.) hecha a medida para cada proyecto (en funcin del sector, de
la predictibilidad de los ingresos, etc.).
Slo los proyectos con flujos de caja estables y predecibles en el largo
plazo son susceptibles de financiacin con estructura Project Finance, por
lo que son sectores tpicos de aplicacin el de las infraestructuras de transporte (carreteras, ferrocarril, aeropuertos, puertos), los servicios pblicos
(sector sanitario, educacin), el de medio ambiente (plantas de residuos,
depuradoras de aguas residuales) y el sector energtico (renovables, generacin elctrica convencional, petrleo, gas).
166
2.2. Project Finance y financiacin corporativa

A efectos de comprensin, vamos a comparar la forma de financiacin
Project Finance con la denominada financiacin corporativa, entendiendo
por esta ltima la financiacin a una empresa de forma directa utilizando
para ello cualquier producto de financiacin (prstamos, lneas de circulante, etc.).
La financiacin corporativa se suele denominar financiacin con recurso debido a que los acreedores cuentan como garanta para la devolucin
de su deuda con todos los activos de la empresa. De forma muy simplificada, en el caso de que la empresa no pueda devolver su deuda se pondra
en marcha un proceso de venta de los activos de la compaa hasta poderla
devolver. El importe mximo de la financiacin corporativa se dimensiona
atendiendo a la capacidad de generacin de flujos de caja y al valor de los
activos de la empresa.
La financiacin corporativa puede tener un carcter general (en contraposicin a una financiacin especfica para el desarrollo de un proyecto
concreto) y permite una mayor autonoma a los gestores de la empresa en
su gestin y direccin financiera. Como contrapartida de esa mayor flexibilidad, los plazos de las financiaciones corporativas son menores que los
del Project Finance.
Por el contrario, la financiacin con estructura de Project Finance estar
garantizada fundamentalmente por los flujos de caja del proyecto y su importe mximo se determina en funcin de los mismos.
Para asegurar a los acreedores que la generacin de los flujos de caja se
mantendr hasta la devolucin de la deuda, en el Project Finance se prohbe cualquier transferencia o traspaso de los activos del proyecto. A esta accin se la denomina establecer un permetro de garantas (o tener unas garantas ring fence) sobre los activos del proyecto, con los que se generar
el flujo de caja del mismo, durante toda la vida de la financiacin. La forma
prctica de hacerlo es crear una sociedad de propsito nico (Special Purpose Vehicle o SPV) donde se incorporan los activos del proyecto.
Depender de la poltica interna financiera y de los objetivos de cada
compaa el acudir a financiacin corporativa o a financiacin con estructura Project Finance para financiar un proyecto concreto.
Conviene tambin tener en cuenta el tiempo necesario para la obtencin
de la financiacin (el cierre de la financiacin) y costes fijos inherentes a la
obtencin de un Project Finance.
El proceso de anlisis del proyecto que realizan los financiadores (denominado habitualmente due diligence) que evala aspectos tcnicos,
financieros, legales, fiscales, medioambientales, seguros y la complejidad
167
de los contratos asociados a estas financiaciones, hace que el cierre de un

Project Finance requiera un plazo no inferior a tres meses.
Igualmente, el Project Finance tiene unos costes fijos elevados (honorarios de asesores y comisiones de estructuracin, principalmente) que desaconsejan su utilizacin en proyectos que no tengan un tamao mnimo (se
suele fijar en el entorno de los 10 millones de euros).
En definitiva, aun siendo la estructura Project Finance una herramienta
adecuada para la financiacin de proyectos, ser la estrategia financiera de
cada compaa la que decida la idoneidad de su utilizacin, pudiendo optar
por otras herramientas (como la financiacin corporativa) para la financiacin de proyectos.
3. ANLISIS DE LOS RIESGOS DEL PROYECTO

Cuando se enfrenta a un nuevo proyecto, el gestor debe evaluar los diferentes riesgos que existen en el mismo. De la correcta mitigacin de estos
riesgos depender en gran medida la rentabilidad futura del proyecto y la
posibilidad de captar la financiacin sin recurso en el mercado financiero. A
continuacin se describen los principales grupos de riesgos y cules son los
instrumentos habituales para mitigarlos, as como qu agente debe soportar
cada riesgo, bajo el principio de que cada riesgo debe ser soportado por
aquella parte que mejor puede controlarlo.
3.1. Riesgo de construccin
El riesgo de construccin es un riesgo que generalmente es asumido por
el constructor, a travs del contrato EPC (Engineering, Procurement and
Construction) y por los sponsors (si hubiera riesgos abiertos que no estuvieran cubiertos en el mencionado contrato).
Los riesgos inherentes a la construccin, principalmente la desviacin
en el presupuesto de la obra, los retrasos en los plazos previstos y los
defectos, son mitigados a travs del contrato EPC, en el cual el contratista
asume:
t 1SFDJP DFSSBEP NJUJHB FM SJFTHP EF TPCSFDPTUFT
6OB QSFNJTB
fundamental del Project Finance es que, en el momento de cierre
de la financiacin, debe estar totalmente cubierto el riesgo de
que todos los fondos necesarios para la puesta en marcha del
proyecto sean aportados, y debern estar, por tanto, comprometidos y asegurados.
168
Los accionistas aportarn anticipadamente los fondos propios, o garantizarn su desembolso simultneo con las disposiciones del crdito
(esta segunda opcin mejorar su rentabilidad frente a la primera).
El riesgo de un mayor coste de la inversin ser asumido por el
contratista en el contrato EPC. Si el EPC no existiera, este riesgo ser
cubierto por los accionistas que garantizan la eventual aportacin
de los fondos adicionales necesarios para la puesta en servicio del
proyecto.
t 1MB[PEFGJOBMJ[BDJOEFMBTPCSBT NJUJHBFMSJFTHPEFSFUSBTPT
-PT
retrasos en el calendario de construccin pueden suponer perjuicios
econmicos, ya que el retraso respecto a la fecha prevista de puesta
en marcha del proyecto en el caso base puede conllevar prdidas
de ingresos, o cuando menos un retraso en su obtencin, lo cual
puede afectar al repago de la deuda. Los eventuales perjuicios ocasionados por retrasos deben ser cubiertos por el contratista en el
contrato EPC, y si no estuvieran cubiertos por l, sern asumidos
por el accionista.
Es habitual el incluir en los contratos financieros una fecha lmite
de puesta en marcha del proyecto, que una vez superada originar
el derecho de las entidades financieras a reclamar la devolucin
de su deuda de forma anticipada.
t $BMJEBE EFM EJTFP Z MB DPOTUSVDDJO &M SJFTHP UFDOPMHJDP WBSB Z
tendr mayor o menor relevancia segn la tipologa de los proyectos.
Este riesgo es asumido por el promotor o el contratista a travs de las
garantas de ejecucin y de rendimiento. Tambin puede ser asumido
por los fabricantes de equipos que dan garantas de los mismos.
Las entidades financieras se apoyan en el informe de un asesor tcnico
independiente para la valoracin de estos riesgos. Los proyectos experimentales, prototipos, proyectos de I+D, o con equipos tecnolgicos sin
suficiente experiencia en fase de explotacin comercial a gran escala, no
son susceptibles de ser financiados mediante Project Finance por no estar
mitigado el riesgo tecnolgico y no cumplir, por tanto, el principio de fiabilidad en la prediccin de los ingresos del proyecto.
3.2. Riesgo administrativo y medio ambiental
El riesgo administrativo y medio ambiental consiste en la posibilidad de
no obtener o (no conservar) todas las licencias, autorizaciones o permisos
necesarios para la construccin y explotacin del proyecto.
Generalmente este riesgo es asumido por el promotor hasta la puesta
en marcha del proyecto aunque, si superado este hito existiesen litigios
169
pendientes, generalmente se exige que este riesgo siga estando garantizado por el promotor hasta la extincin del mismo por una sentencia firme
desestimatoria.
Se puede incluir dentro de esta categora, por su carcter administrativo,
el riesgo expropiatorio, que tiene dos vertientes fundamentales:
t 3JFTHPEFRVFOPTFQVFEBOBDPNFUFSMBTFYQSPQJBDJPOFTEFUFSSFOPT
necesarias para la ejecucin y funcionamiento del proyecto.
t 3JFTHPEFTPCSFDPTUFTFOFMQSFTVQVFTUPQBSBFYQSPQJBDJPOFT
En ambos casos, si este riesgo no est cubierto en su totalidad por la
Administracin (que es la parte que mejor puede controlarlo) las entidades
financieras exigirn que sea asumido por el sponsor en la parte no cubierta
por la Administracin.
3.3. Riesgo de operacin y mantenimiento
Las entidades financieras asumen generalmente el riesgo de explotacin
del proyecto sin ningn tipo de recurso a los accionistas una vez puesto en
marcha el proyecto. No obstante, para la asuncin de este riesgo deber
haber sido presentado un programa (o en su caso un contrato a largo plazo
con tercero especializado) de Operacin y Mantenimiento (O&M) que ser
validado por el asesor tcnico de las entidades financieras.
Este riesgo se suele mitigar en la estructura financiera con el establecimiento de una Cuenta de Reserva de Operacin y Mantenimiento. El dimensionamiento de esta cuenta vara segn el proyecto, pero generalmente
se exige que esta cuenta est dotada por el importe total de gastos de O&M
en el periodo anterior al que se produzcan esos gastos. La cuenta se va
dotando progresivamente con fondos provenientes del proyecto que en
la cascada de pagos del proyecto van despus del pago del servicio de la
deuda y antes del reparto de dividendos.
Puede suceder que el proyecto tenga previstos, a lo largo de su vida,
mantenimientos puntuales de gran envergadura o grandes inversiones de
capital. En este caso deber estar contemplado el establecimiento de una
reserva adicional que se va acumulando a tal efecto, para contar con los
fondos necesarios para realizar estas inversiones.
3.4. Riesgo regulatorio
Consiste en el riesgo de que cambios en la regulacin puedan afectar
al proyecto. En general en casi todos los ordenamientos jurdicos occidentales existe el amparo del principio de irretroactividad que protege frente
a actuaciones discrecionales de las administraciones que puedan poner en
170
peligro las inversiones realizadas al amparo de un marco normativo. Existen

coberturas de riesgo poltico para cubrir este riesgo.
3.5. Riesgo comercial
Consiste en el riesgo de que los ingresos reales que genere el proyecto
sean inferiores a los previstos en el caso base que se us para el dimensionamiento de la deuda.
Este riesgo es compartido por los accionistas y los financiadores (pues la rentabilidad del capital invertido depender de la generacin de estos ingresos).
Para mitigar el riesgo de desviacin de ingresos respecto a los previstos
en el modelo financiero, se establecen importes de reserva en el proyecto.
Tambin pueden usarse plizas de seguro contratadas en fase de explotacin para mitigar el impacto de la prdida de ingresos por eventos que sean
asegurables.
3.6. Riesgo de contraparte
En muchas ocasiones la viabilidad del proyecto queda condicionada por
el cumplimiento de las obligaciones de terceros que intervienen en el marco contractual del proyecto: contratistas, suministradores, administraciones
pblicas o privados que asumen obligaciones de pago con el proyecto a
travs de marcos concesionales o contratos privados de compraventa de
bienes o servicios
El anlisis crediticio de todos los intervinientes en un Project Finance es,
por tanto, esencial para una correcta evaluacin de todos sus riesgos.
La exigencia de avales financieros que garanticen el cumplimiento de las
obligaciones financieras de las contrapartes mitigan este riesgo.
3.7. Riesgos econmico-financieros: inflacin, tipos de inters, tipos de
cambio
La evolucin de la inflacin a lo largo de la vida del proyecto puede
influir negativamente en su capacidad de repago de la deuda. Hay que analizar su influencia en los ingresos y en los gastos del proyecto. Es bastante
habitual que los proyectos tengan una cobertura (o hedge) natural frente
al riesgo de inflacin. Esto sucede cuando tanto sus ingresos como sus gastos estn inflactados y el efecto de la inflacin sobre los ingresos compensa
de forma suficiente la inflacin de los gastos. En otros casos el riesgo de
inflacin debe ser cubierto con un derivado de inflacin (es decir un derivado financiero que fije el tipo de inflacin o que la site en un rango con
un techo y un suelo).
171
En una financiacin estructurada con esquema Project Finance se pretende

que el proyecto quede aislado de una forma razonablemente del riesgo de
evolucin de los tipos de inters. Para ello se contratarn instrumentos derivados de tipos de inters que cubran el riesgo de incremento de tipos de inters
durante la vida de la financiacin.
En determinadas ocasiones los proyectos pueden tener el riesgo de contar con flujos monetarios en diferentes monedas. El principio general de
la financiacin de proyectos para mitigar este riesgo consiste en que la
financiacin debe realizarse en la misma moneda en la que se reciben los
ingresos del proyecto.
Existen ocasiones en que esto no ser posible como por ejemplo, financiaciones de proyectos en pases en los que el mercado de financiacin en
moneda local no est lo suficientemente desarrollado. En este caso el riesgo
de moneda no debera ser asumido por el proyecto sino por la administracin concedente, garantizando un tipo de cambio fijo de la moneda local y
la divisa de la financiacin.
En otras ocasiones existirn componentes de la inversin o de la Operacin y mantenimiento que se hagan en una moneda distinta a la de la
financiacin y habr que contratar un derivado de tipo de cambio para fijar
el cambio entre las dos monedas y aislar el proyecto de este riesgo.
La contratacin de cualquier instrumento derivado (ya sea de tipos de inters, de inflacin o de tipos de cambio) tiene un coste financiero adicional
para el proyecto, que se traduce en un margen o spread, que compensa
el riesgo de crdito que asume el proveedor del derivado con la SPV.
3.8. Riesgo de fuerza mayor
Existen una serie de riesgos, catalogados como riesgos de fuerza mayor
(incendio, robo, accidentes) que por su naturaleza sern asegurables por
compaas de seguros. Habr que verificar en el due diligence de seguros
que estos riesgos estn debidamente cubiertos en las plizas de seguros contratadas con compaas de seguros de primer nivel.
En el sistema concesional espaol existe la figura de la Responsabilidad
Patrimonial del Estado (RPA), que constituye un mitigante importante que
brinda la administracin ante la terminacin anticipada de una concesin.
Por la RPA, la Administracin reembolsa el valor patrimonial al concesionario en determinados eventos.
Es recomendable, para el anlisis o diseo de cualquier proyecto, el
desarrollo de una matriz de riesgos en la que se describan todos los riesgos
del proyecto, sus mitigantes y quin es la parte que soporta ese riesgo. La
tabla 7.1 muestra un ejemplo genrico de matriz de riesgos.
172
Riesgo
Descripcin
Desviacin al alza del coste

de la construccin del
Sobrecostes
proyecto
(Construccin)
Mitigantes
t i%VF%JMJHFODFw5DOJDP
t $POUSBUP&1$
t 4FHVSPT
Quin lo
soporta
Constructor /
Administracin/
Accionistas
t $PNQFOTBDJPOFTQPSGVFS[BNBZPS
Retrasos en la construccin
que puedan implicar prdida
Retrasos
de ingresos (incluso no
(Construccin)
aceptacin de la obra o
prdida de concesin)
t i%VFEJMJHFODFw5DOJDP
Defectos en la construccin
(o en los equipos) que
Defectos
afecten a la generacin de
(Construccin)
ingresos o puedan impedir
la aceptacin de la obra.
t (BSBOUBTTVNJOJTUSBEPSFT
t $POUSBUP&1$
Constructor /
Administracin/
t 4FHVSPT
Accionistas
t $PNQFOTBDJPOFTQPSGVFS[BNBZPS
t $POUSBUP&1$ZHBSBOUBT
Constructor /
Suministradores
t i%VFEJMJHFODFw"ENJOJTUSBUJWP
Accionista /
Licencias
Obtener (y mantener)
los permisos y licencias
necesarios para la
construccin y explotacin
del proyecto
t i%VFEJMJHFODFw.FEJPBNCJFOUBM
Medio
Ambiental
Obtener (y mantener) los

permisos medioambientales
necesarios para la
construccin y explotacin
del proyecto
t i%VFEJMJHFODFw
Expropiatorio
Retrasos en los plazos (que

supongan un perjuicio
econmico) o incremento
en el coste de las
expropiaciones
t $POUSBUPTTFSWJDJPT0.ZTVNJOJTUSPT SPV
(precio cerrado y garantas)
Operacin
Incremento de gastos de
O&M o prdida de ingresos
(mala gestin, incremento
de precios de servicios o
materias primas)
SPV
Accionista /
SPV
Administrativo
Administracin
/ Accionista
t i%VFEJMJHFODFw5DOJDP
t $VFOUBTEF3FTFSWB0.
Regulatorio
Cambios en la regulacin
t $MVTVMBTEFSFFRVJMJCSJP
que puedan afectar
econmicamente al Proyecto
Comercial
Obtencin de menores
ingresos de los previstos en
la explotacin del Proyecto.
t i%VFEJMJHFODFw USGJDP SFDVSTP

mercado)
t "WBMFTGJOBODJFSPT
Contraparte
Incumplimiento de
obligaciones contractuales
de partes en el Proyecto
Inflacin
Impacto econmico negativo t %FSJWBEPTGJOBODJFSPT

de la evolucin de la
t *OEFYBDJOEFJOHSFTPTSFHVMBEPT
inflacin en el proyecto
Administracin
/
SPV
SPV
t $VFOUBTEFSFTFSWB
173
SPV
Administracin/
SPV
Riesgo
Descripcin
Quin lo
soporta
Mitigantes
Tipos de
Inters

del incremento de tipos de
inters en el proyecto
Administracin/
Tipos de
cambio

de la evolucin de tipos de
cambio en el proyecto
Administracin/
Fuerza mayor
Prdida de ingresos por

eventos de fuerza mayor
SPV
SPV
t i%VF%JMJHFODFwEF4FHVSPT
Administracin/
t 4FHVSPT
SPV
Tabla 7.1. Matriz de riesgos.
4. CRITERIOS PARA DETERMINAR LA FINANCIABILIDAD DEL PROYECTO

Un adecuado anlisis de los riesgos junto con sus mitigantes por parte
del gestor del proyecto determinar si ste es financiable, pero adems,
influirn otros criterios.
4.1. Criterios econmicos
En pocas de crecimiento econmico y mercados financieros en entorno favorable, ser ms fcil la financiacin de los proyectos. En entornos
menos favorables, con menor liquidez en los mercados financieros, habr
mayor dificultad para la financiacin de los mismos. y slo los mejores proyectos y los que tengan las estructuras financieras ms robustas conseguirn
la financiacin. Esta situacin de mercado determinar el que los proyectos,
para ser financiables, tengan que contar con menores plazos de financiacin, mayores ratios de cobertura, sponsors de contrastada experiencia y
solvencia y menor apalancamiento (relacin de deuda sobre el total del
capital invertido).
Las entidades financieras, al tener recursos econmicos de inversin limitados, los destinarn a aquellos productos que les reporten una mayor
rentabilidad. El Project Finance como producto para la entidad financiera
tiene las siguientes ventajas:
t .SHFOFTEFSFNVOFSBDJOBUSBDUJWPTZBTFHVSBEPTFOFMMBSHPQMB[P
t &T QPDP IBCJUVBM FO HFOFSBM RVF MB GJOBODJBDJO FTUSVDUVSBEB DPO
Project Finance presente incumplimientos (default) y, por tanto,
tiene una tasa de morosidad baja en relacin con otros activos de
la cartera de las entidades financieras (hipotecas sector inmobiliario,
174
prstamos corporativos, adquisiciones apalancadas). Esto en general viene motivado por la minuciosidad con la que se estudian las financiaciones, los escenarios estrs a los que se someten y el carcter
no cclico de algunos sectores que se financian con Project Finance.
t -FQFSNJUFBMBFOUJEBEGJOBODJFSBUSBCBKBSDPOHSBOEFTDPSQPSBDJPOFT
que demandan este producto frente a competidores que no ofrecen
soluciones con estructura Project Finance.
t &TVOQSPEVDUPRVFQPSEFGJOJDJOFTTVTDFQUJCMFEFUJUVMJ[BDJOZ QPS
tanto, da flexibilidad a la gestin financiera del balance de la entidad.
Por el contrario, las desventajas que se suelen asociar al Project Finance
son las siguientes:
t $PNQSPNJTPEFSFDVSTPTBMBSHPQMB[PGSFOUFBPUSPTBDUJWPTEFMCBOco. Esto provocar que en situaciones de mercado con menor liquidez, los plazos ofertados en la estructuracin del Project Finance se
reduzcan.
t -BGJOBODJBDJOQSPQJBEFMBTFOUJEBEFTGJOBODJFSBTTFIBDFDPOQMB[PT
mucho ms cortos que los que exige el Project Finance, lo que puede
provocar desequilibrios en la estructura financiera de las entidades
(en determinados mercados el regulador impone por ello un consumo de recursos a las entidades en funcin del plazo). El diferencial
del margen del Project Finance debe compensar ese desequilibrio,
pero ha habido situaciones puntuales de mercado de gran liquidez
con fuerte competencia en este producto que provocaron la existencia de financiaciones Project Finance, con mrgenes anormalmente
bajos que se han demostrado insuficientes para compensar ese desequilibrio en el largo plazo.
4.2. Otros criterios
Existen otros factores no econmicos que pueden influir en la financiabilidad de los proyectos.
Una regulacin estable es un requisito necesario para la financiacin
con estructura de Project Finance. Una regulacin sectorial en permanente
cambio o incluso con modificaciones retroactivas es un fuerte impedimento
para la consecucin de la financiacin de los proyectos.
La situacin poltica del pas en el que se encuentre el proyecto influir
en las posibilidades de financiacin del mismo (principalmente para las
entidades financieras internacionales). Una situacin de inestabilidad parlamentaria, o de elecciones con posibilidad de llegada al poder de partidos
radicales, son factores que dificultarn el acceso a los mercados de financiacin. Estos riesgos pueden ser cubiertos en ocasiones con las coberturas de
175
riesgo poltico mencionadas. Habr que considerar el impacto de su coste

en la rentabilidad del proyecto.
5. ENTIDADES INTERVINIENTES EN LA FINANCIACIN DE UN PROYECTO

En una financiacin con estructura Project Finance aparecen un gran
nmero de intervinientes. Esto se produce tanto por la complejidad contractual que exige la estructura financiera como por la necesidad del proceso de
due diligence que imponen las entidades financieras como requisito para
otorgar la financiacin. Los principales intervinientes son los siguientes:
5.1. Sponsor
Los promotores, sponsors o accionistas del proyecto se pueden clasificar
atendiendo a la naturaleza de su actividad principal en:
a) Industriales
Se trata de los grandes grupos empresariales cuya actividad principal
est en el campo de la construccin o de la energa. El desarrollo de proyectos se enmarca dentro de su actividad principal.
En el caso de las constructoras, el desarrollo de proyectos crea sinergias
con su actividad de construccin, por lo que la rentabilidad global del proyecto no se valora exclusivamente por la rentabilidad del mismo, sino tambin por los beneficios que aporta a otras reas de la empresa, como por
ejemplo el negocio cautivo que genera para sus reas de construccin.
b) Financieros
Existen inversores financieros especializados en los diferentes sectores
del Project Finance. La tipologa de estos inversores es muy variada, pudiendo ser reas especializadas dentro de entidades financieras, fondos de
pensiones, fondos de inversin que pueden estar especializados geogrficamente o sectorialmente, family offices
Este tipo de sponsor no tiene otros intereses accesorios al proyecto ms
all de la rentabilidad econmica del mismo.
Los sponsors financieros generalmente no dan garantas al proyecto ms
all de la aportacin del capital necesario para su puesta en marcha ya que
habitualmente no pueden exigir aportaciones de fondos contingentes a los
partcipes de los fondos y, a diferencia de los sponsors industriales, al no
176
participar activamente en la actividad de construccin del proyecto, no estn dispuestos a asumir riesgos en este sentido.
c) Agrupaciones de Inters Econmico y Joint Ventures
En numerosas ocasiones sponsors financieros e industriales se agrupan
para desarrollar un proyecto. Tambin pueden establecer acuerdos para desarrollar ms de un proyecto o constituir compaas con el objeto especfico
de desarrollar y gestionar proyectos en un sector especfico.
Como se ha explicado anteriormente, los intereses de ambos tipos de
sponsor no son los mismos por lo que pueden surgir mltiples conflictos
entre los diferentes tipos de accionistas. Es por ello que tiene una gran
trascendencia la negociacin de un buen acuerdo de socios que contemple
y de solucin a los posibles conflictos que puedan tener lugar durante el
desarrollo de los proyectos.
En principio la asociacin resulta interesante para ambas partes:
t 1BSBFMTPDJPJOEVTUSJBMSFTVMUBJOUFSFTBOUFMBBTPDJBDJO QVFTFMTPDJP
financiero aporta el capital necesario para desarrollar un mayor nmero de proyectos, lo cual le reporta beneficios adicionales por las
sinergias comentadas que le aporta a su organizacin;
t 1BSBFMTPDJPGJOBODJFSPFTUBNCJOBUSBDUJWBMBBMJBO[B QVFTJODSFmenta las posibilidades de xito en procesos competitivos en sectores
en los que su capacidad de influencia es limitada; adicionalmente en
el caso de que el proyecto requiera aportacin de garantas de construccin puede conseguir que stas recaigan en el socio-constructor.
5.2. Financiadores
La captacin de financiacin externa para el desarrollo de un proyecto
no est limitada exclusivamente a la banca comercial. Existen mltiples
fuentes de financiacin externas, describindose a continuacin las ms
frecuentemente utilizadas en el mbito del Project Finance.
a) Bancos
Es muy importante conocer el perfil de los bancos comerciales para conocer cules se ajustan mejor al proyecto que se trata financiar. No todos
los bancos tienen equipos especializados en Project Finance, ni dentro
de los que tienen experiencia en este producto, tienen las mismas apetencias. Hay bancos especializados en determinados sectores por los que otros
apenas tienen apetito, igualmente las limitaciones de plazo son distintas
segn qu bancos o segn las normas bancarias de cada pas.
177
Aunque en el pas en el que se vaya a desarrollar un proyecto no haya

banca local especializada en Project Finance, existen alternativas de financiacin como la banca internacional, y la banca multilateral de desarrollo.
b) Entidades multilaterales y Agencias de Crdito a la Exportacin
Los bancos multilaterales son entidades supranacionales (sus accionistas
son grupos de pases) que apoyan el desarrollo econmico a travs de la
concesin de financiaciones en condiciones favorables. Los bancos multilaterales tienen su territorio natural en regiones de pases emergentes, pero
tambin existen estas entidades en mbitos geogrficos desarrollados como
el Banco Europeo de Inversiones cuyos accionistas son los 27 pases de la
Unin Europea y que financia en condiciones favorables proyectos acordes
con los objetivos polticos de la UE (mejora de infraestructuras, suministro
de energa, proyectos medioambientales) as como proyectos en pases
vecinos o pases en desarrollo.
Los instrumentos de financiacin de las entidades multilaterales para los
proyectos son variados, siendo los ms relevantes los siguientes:
t 'JOBODJBDJOEJSFDUBDPOSJFTHPEFQSPZFDUPBUSBWTEFFTUFJOTUSVmento las entidades multilaterales financian el proyecto asumiendo el
riesgo del mismo para el repago de la financiacin.
t 'JOBODJBDJOEJSFDUBBWBMBEB TJOBTVNJSSJFTHPEFQSPZFDUP
BUSBvs de este instrumento las entidades multilaterales financian el proyecto, pero obteniendo una garanta de bancos comerciales, que
son los que asumen el riesgo del proyecto en caso de impago. Es
habitual que en este tipo de financiacin se establezcan mecanismos para que el requisito de aval desaparezca si el proyecto evoluciona favorablemente.
t 'JOBODJBDJOJOEJSFDUBMBFOUJEBENVMUJMBUFSBMQVFEFPUPSHBSGJOBODJBcin a bancos comerciales para que stos destinen esos fondos a la
financiacin de proyectos concretos o a proyectos que cumplan con
los objetivos descritos por las entidades multilaterales.
t &TUSVDUVSBT"#FTUBFTUSVDUVSBUBNCJOEFOPNJOBEBiQBSBHVBTwDPOsiste en la financiacin directa al proyecto de la entidad multilateral a
travs de un tramo A que coexiste con un tramo B sindicado de banca comercial. Al tener la entidad multilateral acuerdos como acreedor
preferente con los gobiernos de los pases en los que opera, los
bancos comerciales participantes en el tramo B se benefician tambin
de este estatus, lo cual conlleva el beneficio aadido de eximirles de
provisin por riesgo pas en sus pases de origen.
178
Las ventajas de la financiacin multilateral son:

t
t
.TDPNQFUJUJWBTFOQSFDJPRVFMBCBODBDPNFSDJBM
1MB[PTNTMBSHPT FONFSDBEPTJONBEVSPT
Como desventajas frente a la financiacin bancaria se puede sealar:

t 3FRVJFSFNTUJFNQPQBSBTVPCUFODJOiEVFEJMJHFODFwNTSHJEP
plazos de informacin pblica
t .FOPSGMFYJCJMJEBEFOMBOFHPDJBDJOEFMPTDMBVTVMBEPTEFMBEPDVmentacin financiera.
Las Agencias de Crdito a la Exportacin o Export Credit Agencies
(ECAs) son entidades aseguradoras participadas por capital pblico y privado cuya funcin primordial es la de favorecer las exportaciones de las
empresas de sus pases de origen.
En las operaciones de Project Finance en el extranjero las ECAs pueden
otorgar coberturas de riesgos polticos y comerciales tanto para el capital
como para la deuda:
t 1MJ[B EF 4FHVSP EF DSEJUP FTUF JOTUSVNFOUP GJOBODJFSP HBSBOUJ[B
a los acreedores del proyecto el cobro del crdito en determinados
eventos. Los riesgos cubiertos que se pueden contratar pueden ser
de tipo comercial (los inherentes a la propia actividad del proyecto)
y polticos.
Los principales riesgos polticos que se cubren en este tipo de plizas
son:
Riesgo de expropiacin (cubre tambin los incumplimientos contractuales de autoridades gubernamentales o expropiacin encubierta).
Riesgo de convertibilidad de la divisa del pas en el que sita el
proyecto.
Riesgo de transferencia de fondos fuera del pas asegurado.
Riesgo de guerra, revuelta, terrorismo, orden pblico en el pas
objeto de la cobertura.
t 1MJ[BEF4FHVSPEF*OWFSTJPOFTFTNVZTJNJMBSBMBQMJ[BEFTFHVSP
de crdito con la diferencia de que no cubre riesgos comerciales, sino
exclusivamente polticos.
Los requisitos ms habituales para acceder a los instrumentos de financiacin de las ECAs son:
t &YJTUFODJBEFDPOWFOJPDPOFMQBTEFTUJOBUBSJPEFMBFYQPSUBDJO Z
lmite disponible de financiacin para ese pas).
179
t &YJTUFODJBEFTVNJOJTUSPNBUFSJBMEFCJFOFTEFFRVJQPFOFMQSPZFDUP
con origen en el pas o regin de la ECA.
t 2VFPCJFOFMQSPNPUPSEFMQSPZFDUPPVOQSPWFFEPSEFTFSWJDJPTP
un suministrador de equipos, sea del pas o regin de la ECA.
Las plizas de seguro de la inversin o del crdito nunca garantizan
el 100% de los importes de capital o de deuda invertidos en el proyecto,
establecindose los porcentajes mximos de cobertura en un rango del 97
al 99% segn las distintas ECAs. El motivo principal de este dficit en la cobertura es el estmulo al acreedor o inversor garantizado para solucionar los
conflictos asegurados pues de esta forma comparte con la ECA potenciales
prdidas.
La negociacin de los seguros de crdito e inversin es simultnea a la
negociacin de la financiacin con los bancos. Estos instrumentos tienen
unas Clusulas Generales aplicables para todos los proyectos y unas Clusulas Particulares que sern las que recojan las peculiaridades de la cobertura especficas para cada proyecto.
La prima que se paga por la contratacin del Seguro de Crdito generalmente se abona en un pago nico y por anticipado, por lo que puede
ser financiada como otros gastos del proyecto en su fase de construccin.
Esta prima se calcula como un porcentaje del importe total del crdito
asegurado.
5.2.1. Otros financiadores: inversores institucionales, bonistas, etc.
La financiacin con Project Finance no est restringida a los bancos a
travs de los prstamos tradicionales sino que otras figuras como las titulizaciones o las emisiones de bonos amplan el abanico de financiadores a
otros inversores.
Los inversores naturales para los ttulos con riesgo subyacente de Project
Finance son las compaas de seguros y fondos de pensiones, a los cuales
resulta interesante un instrumento de inversin con un perfil de riesgo moderado con vencimientos a largo plazo, tipos fijos y remuneracin atractiva
respecto a las alternativas de deuda pblica.
5.2.2. Agencias de Rating
Aunque no son financiadores, la intervencin de las Agencias de Rating
en el Project Finance es relevante en el mbito de la financiacin a travs
de emisiones de bonos o titulizaciones. Los bancos no exigen informes de
rating para los prstamos con estructura Project Finance.
Las agencias de rating miden el riesgo de impago y la solvencia de un
emisor de deuda.
180
El rating de una emisin de bonos con estructura de Project Finance es

la referencia que utilizan los inversores institucionales para asignar un perfil
de riesgo a la emisin. El rating que obtenga el proyecto determinar la
base de potenciales inversores interesados en la adquisicin del bono, as
como el precio del mismo.
5.3. Asesores
Las entidades financieras son expertas en riesgos financieros y, a pesar
de contar con departamentos especializados de Project Finance, necesitan
de asesores externos especializados que les ayuden en el anlisis de los
distintos riesgos del proyecto en los exhaustivos procesos de auditora o
due diligence. La contratacin de los asesores es consensuada entre las
partes (bancos y sponsors). Generalmente se acuerda una terna de asesores
en cada campo, a los que se pide oferta por los trabajos requeridos para la
estructuracin de la financiacin. Los gastos de asesores son asumidos por
el proyecto, no por las entidades financieras. Se describen a continuacin
los principales asesores que intervienen en un Project Finance.
a) Legales
Es fundamental la labor de los despachos de abogados para el xito del
Project Finance. Se seleccionar un despacho de abogados con especialistas
en Project Finance con experiencia en proyectos similares al que se est
tratando financiar.
Su labor fundamental es la de asesorar al financiador en la elaboracin
de los contratos de financiacin.
Generalmente el mismo despacho de abogados seleccionado como asesor de las entidades financieras ser el encargado de elaborar el due diligence legal-administrativo que incluir la revisin de las autorizaciones y
licencias necesarias para el desarrollo del proyecto, as como todos los aspectos legales concernientes a la SPV y a todos los contratos del Proyecto.
b) Tcnicos
Aunque las entidades financieras se especializan en sectores del Project
Finance, necesitan de la ayuda de asesores tcnicos independientes para
poder valorar todos los aspectos tcnicos de los proyectos.
Dentro de la asesora tcnica se pueden distinguir distintas funciones y
labores de due diligence:
t i%VFEJMJHFODFwUDOJDP*ODMVZFMBFWBMVBDJOUDOJDBEFMEJTFPEFM
proyecto, valoracin de la idoneidad de los equipos y sus suministra-
181
dores, revisin de los procesos y cronograma de construccin, evaluacin de las implicaciones medioambientales del proyecto, revisin
del programa de operacin y mantenimiento (incluyendo la valoracin de mantenimiento preventivo y correctivo, grandes reposiciones
y vida til de los activos) y valoracin econmica del presupuesto de
construccin y de operacin y mantenimiento.
t i%VFEJMJHFODFwEFUSGJDPSFDVSTPNFSDBEPTFUSBUBEFMBJNQPSUBOte tarea de revisar la fiabilidad de los ingresos que va a generar el
proyecto. Segn el sector en el que se site el proyecto se acudir
a distintos especialistas de trfico, de recurso (elico, solar) o de
mercado (precios de energa, precios de materias primas).
c) Seguros
Para valorar que los riesgos asegurables estn correctamente cubiertos
se contratan los servicios de una compaa de seguros para que emita un
informe en el que debern quedar identificados los principales riesgos
que pueden afectar al proyecto en su fase de construccin y en su fase
de explotacin. Se deber reflejar la probabilidad de ocurrencia de los
riesgos identificados, as como la prdida mxima esperada de cada uno
de ellos.
A la vista de los riesgos identificados, el asesor de seguros deber proponer en su informe el programa de seguros ms eficiente para el proyecto
debiendo incluir en todo caso los seguros ms habituales: el Seguro Todo
Riesgo, Construccin, el Seguro de Prdida de Ingresos y el Seguro de Responsabilidad Civil.
El asesor de seguros debe supervisar la implantacin del programa de
seguros propuesto.
Si existiesen plizas ya contratadas con anterioridad a la emisin del informe, el asesor de seguros deber revisar si stas se ajustan al programa de
seguros propuesto y si no fuera as, deber recomendar su modificacin.
d) Otros (financieros, fiscales, auditores)
Segn la naturaleza del proyecto, la tipologa del sponsor y la complejidad de su estructura de financiacin puede resultar necesaria la intervencin de otros asesores.
t "TFTPSGJOBODJFSPFOEFUFSNJOBEBTPDBTJPOFT DPNPDVBOEPFMTQPOsor no tiene un departamento financiero especializado en Project Finance, o cuando acude a un mercado financiero desconocido para
l, resulta recomendable la contratacin de un asesor financiero. El
asesor financiero es contratado por el sponsor para defender sus inte-
182
reses y le aconsejar la estructura de financiacin que mejor se ajuste

a sus necesidades, elaborar el modelo financiero y le ayudar en la
seleccin y negociacin con las entidades financieras, as como en el
proceso de due diligence.
t "TFTPS'JTDBMDVBOEPMBFTUSVDUVSBGJOBODJFSBUJFOFVOBDPNQMFKJEBE
fiscal significativa puede resultar conveniente la contratacin de un
asesor fiscal.
t "VEJUPSFTFOGJOBODJBDJPOFTTJOEJDBEBTFOMBTRVFJOUFSWJFOFOFOUJdades financieras extranjeras (respecto al pas en el que se desarrolla
el proyecto) suele ser habitual la contratacin de un auditor que
compruebe el correcto funcionamiento del modelo financiero y verifique que las hiptesis contables y fiscales que contiene respetan la
legislacin aplicable.
6. ESTRUCTURAS TPICAS DE FINANCIACIN

Tanto para una financiacin bancaria tradicional como para una financiacin en los mercados de capitales a travs de titulizaciones o emisiones
de bonos, la estructuracin de un Project Finance ser muy similar.
6.1. Financiacin bancaria
La financiacin bancaria es la financiacin ms conocida y habitual con
estructura Project Finance. Las estructuras de financiacin son hechas a
medida para cada financiacin, pues se ajustan a sus flujos de caja y a los
riesgos del proyecto. Se podra hacer una clasificacin segn el plazo y las
garantas de la financiacin:
a) Financiacin de largo plazo
La financiacin se estructura teniendo en cuenta toda la vida til del
activo y/o todo el plazo concesional o contractual en el que generar sus
ingresos. La totalidad de la deuda ser repagada en el plazo que contempla
la financiacin y ste est condicionado por la vida til de los activos, y la
duracin de la concesin o contrato en el que se sustenta la generacin de
ingresos.
Normalmente se calcula que el repago de la deuda se realizar antes
que la finalizacin del periodo de la concesin (a ese periodo restante de
le denomina cola de la financiacin) para contar as con un margen en
el supuesto de que algn imprevisto impidiera la generacin de ingresos
durante un periodo de tiempo.
183
b) Financiacin de corto/medio plazo

En determinadas ocasiones, por circunstancias financieras de mercado, o
por peculiaridades de sectores especficos, se restringen los plazos de financiacin, lo cual imposibilita el que la financiacin sea repagada enteramente
durante el plazo de la financiacin.
En este caso, no toda la deuda habr sido repagada al vencimiento del
plazo de la financiacin sino que quedar un porcentaje de la misma pendiente de reembolso en esa fecha. Existir por tanto, un riesgo de refinanciacin ya que los flujos de caja generados por el proyecto no habrn sido
capaces de repagar toda la deuda en el plazo de la financiacin y habr
que acudir nuevamente al mercado para refinanciarla y as poder repagar
la deuda pendiente.
c) Financiacin IVA
Las peculiaridades del pago, devolucin y garantas de este impuesto
permiten el optimizar la financiacin del proyecto con una lnea estructurada con este fin especfico. Esta financiacin tendr un plazo que abarcar
el periodo de devengo y pago de este impuesto (generalmente coincidente
con la fase de construccin) y el de su devolucin. Tendr garantas separadas de las de la financiacin principal pues contar con la garanta de la
cuenta de IVA con la Administracin, su margen tendr en cuenta tambin
su plazo sensiblemente inferior al de la financiacin principal a largo plazo,
por lo que la utilizacin de esta financiacin especfica en la financiacin
del proyecto generalmente optimiza su coste.
d) Financiacin puente
En ocasiones la necesidad de inversin del proyecto surge antes de poder cerrar el Project Finance, generalmente por el requisito de cierre de un
due diligence limpio y satisfactorio. En ese caso, se puede solicitar una
financiacin temporal (denominada puente) de corto plazo que contar
con la garanta de los accionistas del proyecto y ser refinanciada con la
financiacin Project Finance.
El importe de la financiacin puente suele ser menor que el del Project
Finance definitivo y se dimensionar segn la inversin prevista hasta la
fecha estimada de cierre del Project Finance.
Lgicamente, la financiacin puente contar con la garanta corporativa
de los accionistas y, por tanto, su obtencin depender de su solvencia.
184
e) Deuda subordinada
En ocasiones se establecen tramos de deuda que estn subordinados en
garantas a la financiacin principal (denominada senior). Est financiacin tambin est generalmente subordinada en los pagos del proyecto respecto a la financiacin senior, es decir, nicamente se pagarn intereses y
principal de la financiacin subordinada en un periodo, una vez que hayan
sido satisfechas todas las obligaciones de pago de la financiacin principal
de ese mismo periodo.
La estructuracin de un tramo de deuda subordinada permite incrementar la deuda total del el proyecto, y por tanto, aumentar la rentabilidad del
accionista. Las entidades financieras proveedoras de deuda subordinada
asumen mayores riesgos que la deuda senior y, por tanto, exigen una mayor remuneracin que compense ese diferencial de riesgo. Normalmente
existen entidades financieras especializadas en proporcionar este tipo de
deuda.
6.2. Financiacin en mercados de capitales: bonos y titulizaciones
Existen inversores institucionales (compaas de seguros, fondos de inversin, etc.) para los que la rentabilidad y el perfil de riesgo que ofrecen
los activos tpicamente financiados con Project Finance encajan perfectamente con sus objetivos de inversin. Se puede canalizar la participacin
de estos inversores en la financiacin, tambin con estructura de Project
Finance, con emisiones de bonos o titulizaciones.
La estructura de financiacin de un proyecto con bonos es en esencia
muy similar a la financiacin con deuda de entidades financieras. La financiacin con bonos presentar una mayor complejidad contractual (es
decir de los contratos a firmar entre las partes involucradas y los bonistas),
principalmente en lo referente a la organizacin de los bonistas, cuyos
intereses sern defendidos por un representante de los bonistas, y segn
jurisdicciones se constituirn fideicomisos para garantizar sus derechos.
El cierre de la financiacin tambin generalmente es ms complejo al requerir la intervencin de agencias de rating que analicen el riesgo de la
emisin.
185
7. ELEMENTOS TPICOS DE LA FINANCIACIN EXTERNA: GARANTAS Y RATIOS DE

CONTROL DEL PROYECTO
7.1. Garantas
Toda financiacin externa exige garantas al deudor para la devolucin
de la misma. En el caso de la financiacin con estructura Project Finance,
la estructura de garantas se basa en el esquema de ring fence que se
crea en torno al proyecto. A continuacin se describen las garantas ms
habituales que constituyen el conjunto de garantas (denominadas security
package).
a) Garantas reales (hipotecarias y pignoraticias)
Constituyen la esencia del esquema Project Finance, que pretende ser
un esquema de financiacin bajo el principio de que el flujo de caja del
proyecto es el que dimensiona la deuda y por tanto todos los elementos
necesarios para la generacin de ese flujo de caja sern objeto de garanta
real para los financiadores. As, se podrn inscribir garantas hipotecarias
sobre los activos fijos del proyecto y dentro del paquete de garantas se
incluirn garantas pignoraticias de las cuentas del proyecto, las acciones de
la acreditada y los contratos del proyecto.
b) Garantas personales de los accionistas
Como se ha explicado anteriormente, la financiacin Project Finance
puede tener recurso limitado a los accionistas para mitigar algunos de sus
riesgos. Estas garantas estarn limitadas en cuanta (hasta un mximo del
importe de la deuda del proyecto) y en su duracin temporal (hasta que
desaparezca el riesgo que cubren). Las garantas ms habituales que se suelen requerir a los accionistas, y de las que responden con su patrimonio,
son las siguientes:
t (BSBOUB EF TPCSFDPTUFT HBSBOUB EF FKFDVDJO EF MB PCSB QPS FM
importe mximo presupuestado. En caso de superarse este coste,
los accionistas se comprometen a aportar los fondos adicionales
necesarios.
t (BSBOUB EF QVFTUB FO NBSDIB HBSBOUB EF RVF FM QSPZFDUP FTUBS
en servicio antes de una fecha lmite determinada. Generalmente se
establece una fecha prevista de puesta en marcha, a partir de la
cual, los accionistas garantizarn el aportar los fondos adicionales
necesarios que compensen la prdida de ingresos por retrasos; y una
186
fecha lmite de puesta en marcha, superada la cual los acreedores

podrn reclamar la devolucin de la deuda a los accionistas garantes
del proyecto.
t (BSBOUBEFSFOEJNJFOUPHBSBOUBRVFDVCSFFMSJFTHPEFRVFFMQSPyecto no rinda segn las especificaciones previstas en su diseo y de
acuerdo a unos mnimos establecidos en el caso base. Garanta de
desembolso de fondos propios: cuando los accionistas desembolsan
su capital de forma simultnea y proporcional a la deuda (pari
passu), garantizan personalmente su desembolso.
t (BSBOUBEFMJUJHJPTFOFMTVQVFTUPEFRVFFYJTUBOMJUJHJPTBCJFSUPTRVF
sobrevivan al cierre financiero, se suele exigir a los accionistas una
garanta sobre los mismos hasta su resolucin en ltima instancia.
Segn la solvencia de los accionistas se aceptar el riesgo corporativo
para estas garantas o se exigirn avales bancarios.
7.2. Ratios de control del proyecto
Como ya se ha comentado en la propia definicin del Project Finance,
esta estructura de financiacin se disea en funcin del flujo de caja generado por el proyecto, por lo que la mayora de los ratios ms importantes
utilizados en Project Finance se fundamentan sobre el criterio de caja.
a) Ratio de Cobertura del Servicio de la Deuda (RCSD)
El Ratio de Cobertura del Servicio de la Deuda (RCSD) es el ratio primordial de la estructuracin de un Project Finance. Este ratio se define como el
cociente resultante de dividir la caja disponible para el servicio de la deuda
en un periodo entre el servicio de la deuda (capital ms intereses) de ese
periodo.
Este ratio se expresa en veces el servicio de la deuda, as un proyecto
con un RCSD medio de 1,2x quiere decir que tiene un RCSD que en promedio de todos sus periodos cubre un 120% el servicio de la deuda de cada
periodo.
El importe de deuda que soporta un proyecto (apalancamiento) se determinar en funcin del RCSD mnimo y medio requerido para ese proyecto. Aunque conviene matizar que, suponiendo un caso extremo en el
que el flujo d caja del proyecto permitiese financiarlo en su totalidad con
deuda (apalancamiento del 100%), aun as, en la prctica, los financiadores
exigiran una aportacin mnima de capital al accionista (como incentivo y
muestra de compromiso del mismo con el proyecto). Ese capital mnimo
exigido, en todo caso, se puede situar en el entorno del 10% de las necesi-
187
dades de fondos del proyecto pudiendo elevarse hasta el 25% en entornos

financieros complicados o sectores de mayor riesgo.
Si la financiacin de un proyecto se estructura con un RCSD constante
en todos sus periodos, su RCSD mnimo ser igual a su RCSD medio.
Si el RCSD es inferior a uno quiere decir que para ese periodo el proyecto no genera caja suficiente para pagar los intereses y el principal de la
deuda en ese periodo, por lo que el proyecto estar en situacin de incumplimiento (tambin denominado default).
Por lo anterior, siempre hay que conocer el RCSD mnimo de un proyecto en todos sus periodos para evitar que el proyecto en su estructuracin
contemple algn periodo en el que no se generen fondos suficientes para
el pago de la deuda.
As como el RCSD mnimo nos indica en qu momento del proyecto puede haber tensiones de tesorera puntuales, es necesario conocer el
RCSD medio (promedio de todos los periodos de clculo de RCSD) para
conocer el grado de solvencia del proyecto.
El RCSD se utiliza para estructurar la financiacin del proyecto en su
caso base, pero tambin se utiliza en el seguimiento y gestin financiera del
proyecto, ya que servir de criterio para la activacin de mltiples obligaciones de los contratos de financiacin:
t 0CMJHBDJOEFTVQFSBSVOEFUFSNJOBEP3$4%FOUPEPTMPTQFSJPEPT
de clculo: si no se supera, supone un incumplimiento que constituye causa de resolucin de la financiacin. El nivel de este RCSD se
suele situar entre 1,00x y 1,05x.
t 1SPIJCJDJO EF SFQBSUP EF EJWJEFOEPT TJ FM 3$4% FT JOGFSJPS B VO
nivel determinado: El RCSD mnimo requerido para el reparto de
dividendos se sita entre el RCSD medio del caso base y el RCSD de
incumplimiento. Con esta obligacin se pretende evitar que en situaciones de potencial incumplimiento de pago de deuda (el RCSD est
bastante por debajo del proyectado) se destinen fondos del proyecto
para el pago a los accionistas. Generalmente se establece que si el
RCSD es inferior al mnimo para el reparto de dividendos durante dos
periodos de clculo consecutivos, la caja acumulada y no distribuida,
se destine a amortizar deuda de forma anticipada.
t 0CMJHBDJO EF DPOTUJUVDJO EF IJQPUFDB DVBOEP MBT IJQPUFDBT OP
estn constituidas de inicio sino que existe promesa de constitucin de las mismas) si el RCSD baja de determinado nivel que
puede indicar que el proyecto est prximo a una situacin de incumplimiento.
En la estructuracin del proyecto el RCSD es el termmetro para el
clculo de las diferentes sensibilidades que debe superar el proyecto. Al
188
RCSD = 1,00x se le denomina punto de equilibrio (o break even) del

proyecto. Todas las sensibilidades practicadas (disminucin de ingresos,
incremento de gastos de O&M, inflacin, subida de tipos de inters) deben demostrar superar el break even en niveles razonables de estrs, y
calculadas de forma individual y combinada.
b) Ratio de Cobertura de la Vida de la Deuda (RCVD)
El Ratio de Cobertura de la Vida de la Deuda (RCVD)) se calcula para
un periodo como el valor presente del flujo de caja disponible para el
servicio de la deuda del proyecto durante todo el plazo que resta hasta el
vencimiento contractual de la financiacin dividido entre el saldo vivo de
la deuda en ese periodo.
Este ratio nos muestra la solvencia del proyecto en el plazo de la deuda.
c) Ratio de Cobertura de la Vida del Proyecto (RCVP)
El Ratio de Cobertura de la Vida del Proyecto (RCVP) se calcula como el
valor presente del flujo de caja disponible para el servicio de la deuda del
proyecto durante toda la vida que le queda al mismo (considerando como
vida del proyecto el plazo menor de la vida til de los activos del proyecto
y duracin de la concesin o contrato equivalente) dividido entre el saldo
vivo de la deuda.
El RCVP tiene en cuenta la capacidad de generacin de flujo de caja del
proyecto ms all del plazo contractual de la deuda y ser mayor, por tanto,
que el RCVD (excepto casos extraordinarios, como por ejemplo proyectos
en los que hubiera grandes gastos de desmantelamiento del mismo).
Sirve para valorar solvencia del proyecto ms all de la vida de la deuda
y, por tanto, la capacidad de reestructuracin de la deuda del proyecto ms
all de la fecha de vencimiento contractual de la deuda.
8. GESTIN DE LA FINANCIACIN DE PROYECTOS

En este apartado del captulo se desarrolla el proceso de la financiacin
de un proyecto pasando por su estudio, su materializacin y la gestin financiera durante la vida del mismo.
8.1. Preparacin de la financiacin
En una primera fase se debe analizar internamente el proyecto antes
de la solicitud de financiacin externa ya que de sus caractersticas depen-
189
der la eleccin de la estructura de financiacin ms conveniente para el

mismo. Se elaborar un documento (llamado coloquialmente infomemo
como abreviatura de Information Memorandum) que describa el proyecto
y contenga todos los aspectos que los financiadores deban conocer para su
anlisis preliminar. El contenido mnimo que debe contener el infomemo
incluye:
Descripcin tcnica del proyecto
Estructura contractual del proyecto
Principales datos econmicos: inversin, facturacin anual prevista, gastos anuales de O&M
Informacin financiera de los accionistas
Credenciales en proyectos similares.
8.2. Peticin de ofertas de financiacin. El Term Sheet
Conviene hacer una preseleccin de las entidades financieras ms adecuadas para el proyecto a las que se solicitar financiacin: entidades de
relacin, entidades especializadas en el sector, especializadas en Project
Finance, entidades con experiencia en emisiones y colocaciones de bonos
de proyectos de infraestructuras
Los trminos y condiciones indicativos de la financiacin que estn en
disposicin de ofrecer las entidades financieras se recogen en un documento resumen de condiciones denominado Term Sheet. Estos trminos
y condiciones son indicativos, pues estn condicionados generalmente a
la finalizacin de un due diligence satisfactorio y a la aprobacin definitiva y en firme de los rganos de decisin internos de las entidades
financieras.
El Term Sheet detalla todas las condiciones de estructuracin del caso
base que determinarn la financiacin mxima del proyecto siendo las ms
importantes el plazo y el RCSD mnimo y medio.
Se ofertarn en l todas las condiciones econmicas de la deuda:
Margen de la financiacin: expresado como un tanto por ciento o
puntos bsicos (siendo 1% equivalente a 100 p.b.) sobre el tipo de
inters de referencia (Euribor, Libor) y se aplica sobre el saldo vivo
dispuesto de la financiacin. Aunque el margen puede ser constante
para toda la vida de la deuda, habitualmente presenta un escalado en
funcin de la evolucin real del RCSD o es creciente segn avanza el
plazo de la financiacin.
Comisiones: las comisiones ms habituales son:
190
t MBTDPNJTJPOFTEFFTUSVDUVSBDJO EFBQFSUVSB EFFTUVEJPZEFEJseo son comisiones que se pagan en el cierre de la financiacin

en un solo pago (upfront) y se calculan como un porcentaje de
la financiacin total del proyecto;
t MBDPNJTJOEFEJTQPOJCJMJEBEFTVOBDPNJTJORVFTFQBHBFOMB
fase de disposicin de la deuda y se calcula como un porcentaje
del margen de la operacin aplicado sobre el importe no dispuesto de la deuda;
t DPNJTJOEFBTFHVSBNJFOUPTFQBHBBMBTFOUJEBEFTBTFHVSBEPSBT
de la financiacin, si existiera esta figura. Se calcula como un porcentaje sobre el importe total de la deuda sindicada.
t DPNJTJOEFBHFODJBDPNJTJORVFTFQBHBBOVBMNFOUFBMCBODP
Agente en una financiacin sindicada por el desempeo de las
funciones de Agencia (no aplica en la financiacin bilateral). Suele
ser un importe fijo anual.
El Term Sheet recoger la cascada de cuentas cash flow waterfall que
regula todo el funcionamiento de las cuentas del proyecto describiendo su
prelacin de uso y su disponibilidad. En este apartado del Term Sheet,
est regulado el uso y destino de cada euro (u otra moneda) que ingresa o
gasta el proyecto.
En el Term Sheet quedarn tambin recogidas todas las garantas del
security package de la financiacin.
Segn el apetito que despierte la operacin en el mercado y segn el
tamao de la misma, se abren diferentes alternativas: financiacin bilateral
(una nica entidad suscribe todo el importe de la financiacin) o financiacin sindicada (el importe financiado se reparte entre dos o ms entidades
financieras).
La financiacin bilateral no es muy habitual en Project Finance y generalmente se restringe su uso a financiaciones de tamao reducido. En
grandes financiaciones, los bancos prefieren repartir el riesgo con otras
entidades.
La financiacin sindicada puede contener aseguramiento. En este caso,
se seleccionar un grupo de entidades que garantizarn la totalidad de la
deuda del proyecto. Este grupo de entidades abrir posteriormente un proceso de sindicacin en el que la entidad o entidades aseguradoras cedern
parte de la financiacin a otras entidades (participantes). Las entidades aseguradoras cobran una comisin de aseguramiento por el riesgo que asumen
de no conseguir vender el importe de crdito previsto y excederse de su
toma final deseada.
En la financiacin sindicada sin aseguramiento en formato Club Deal,
cada una de las entidades financiadoras se compromete a desembolsar un
191
porcentaje de la financiacin sin correr riesgo de aseguramiento y sumando

entre todas el 100% de las necesidades de financiacin.
En la financiacin sindicada es relevante la figura del Banco Agente
que ser aquella entidad del sindicato bancario designada para gestionar
en nombre del sindicato las cuestiones operativas del da a da de la financiacin. Las cuestiones no contempladas en el contrato de crdito o las
extraordinarias que surjan en la vida de la financiacin necesitarn ser decididas por el conjunto del sindicato y se regirn por el rgimen de mayoras
establecido en los contratos de crdito.
8.3. Mandato de financiacin
Una vez acordados los trminos y condiciones de la financiacin con
una entidad o un grupo de ellas, generalmente se firma un Mandato de
Financiacin en el cual se incluir el Term Sheet acordado junto con otras
clusulas como la exclusividad y plazo de vigencia del mandato.
Los bancos que firman el mandato asumen la responsabilidad de estructurar, organizar y ejecutar la financiacin sindicada del proyecto. Cuando
exista aseguramiento, se indicar el reparto porcentual del mismo entre los
bancos aseguradores.
8.4. Due diligence, fase de documentacin y cierre financiero
A continuacin se deber llevar a cabo el proceso de due diligence de
las entidades financieras. Se proceder a la seleccin de los distintos asesores. Normalmente se piden ofertas a ternas de asesores consensuadas entre
las entidades financieras y los promotores del proyecto.
Una vez cerrado el proceso de due diligence de forma satisfactoria, las
entidades financieras deben obtener la aprobacin definitiva de la financiacin por sus comits pertinentes. Algunas entidades financieras pueden
obtener aprobacin definitiva sujeta a due diligence satisfactorio con lo
que la finalizacin del due diligence puede ser paralela a los procesos de
aprobacin por comits de la entidad financiera. Esta aprobacin normalmente est condicionada a la finalizacin de una documentacin satisfactoria de los contratos financieros que recojan los trminos y condiciones del
Term Sheet.
Tras obtener la aprobacin formal de las entidades se abre la fase de negociacin de los diferentes contratos financieros (crdito principal, crdito
IVA, prendas, contrato de garantas de los accionistas, contrato de coordinacin entre acreedores).
192
La firma de los contratos se hace ante notario (en el caso de proyectos

en Espaa) y una vez firmados, se puede proceder al desembolso de la
financiacin, siempre que se hayan cumplido todas las condiciones precedentes para el primer desembolso de la misma. La revisin de estas clusulas es de especial relevancia pues si alguna no se cumpliera podra llevar a
la imposibilidad de desembolso del crdito firmado.
Es habitual que inmediatamente despus de la firma del crdito se cierre
el derivado de tipos de inters para evitar diferencias con los tipos contemplados en el modelo financiero cerrado con anterioridad.
Lo ms relevante para la financiacin en la fase de construccin, es vigilar el cumplimiento de las condiciones para los desembolsos peridicos del
prstamo. Es una fase en la que se requiere gran cantidad de informacin
de la inversin que debe ser verificada por el asesor tcnico para cada
una de las disposiciones.
Es tambin de gran relevancia la definicin de puesta en marcha del
proyecto en los contratos de financiacin pues esta tendr implicaciones de
gran importancia como la liberacin de las garantas que en su caso hubieran tenido que otorgar los accionistas. Generalmente los proyectos tendrn
una puesta en marcha provisional (que coincidir habitualmente con la
finalizacin de la obra del proyectos) y una puesta en marcha definitiva
(tras la verificacin de la obtencin de todos los trmites administrativos y
licencias y el correcto funcionamiento del proyecto).
8.5. Gestin financiera en la fase de explotacin
La fase de explotacin debera ser ms aburrida en cuanto a la gestin financiera del proyecto, pues los contratos de financiacin delimitan
la actividad financiera de la SPV, estableciendo las inversiones financieras
permitidas para la caja disponible en el proyecto, limitando endeudamientos adicionales y regulando todo el movimiento de fondos de la SPV cash
flow a travs de la cascada de cuentas. En definitiva, los contratos de financiacin sern el libro de cabecera para la administracin financiera del
proyecto en su fase de explotacin.
Ser tambin importante para la gestin financiera en la fase de explotacin que los contratos financieros hayan recogido un rgimen de mayoras
que facilite la toma de decisiones. Es aconsejable limitar las decisiones por
unanimidad a la modificacin de aspectos sustanciales de los contratos de
crdito (como renuncia de garantas o modificaciones de plazos y precios)
e incluso incluir clusulas que permitan sustituir a minoras de bancos que
bloqueen la toma de decisiones.
A modo de resumen, la figura 7.1 describe las relaciones contractuales y
flujos de caja ms habituales en una estructura Project Finance.
193
Figura 7.1. Esquema contractual y flujos de caja de una estructura Project Finance.
194
CAPTULO 8
SEGUIMIENTO DE PROYECTOS
Y CUADRO DE MANDO INTEGRAL
Marian Lerga Revuelta
Jos Ponce Lucas
Juan Torres Vzquez
1. INTRODUCCIN
Este captulo aborda el seguimiento de proyectos que es la parte de la
gestin que se encarga de velar para que la planificacin que se ha establecido se cumpla, as como gestionar las desviaciones para mantener el
proyecto en lo que se haba establecido o planificado. El captulo analiza
el seguimiento de proyectos centrado principalmente en el punto de vista
organizacional, y de manera prctica para que pueda ser utilizado en el
trabajo diario. Se busca una serie de objetivos que ayuden a comprender y
a poner en prctica la tarea de seguimiento. El captulo se va a estructurar
en tres bloques que se explican brevemente a continuacin.
En la primera parte del captulo se pretende dar a conocer cules son
los objetivos del seguimiento en cada fase que compone un proyecto. Asimismo se dan pautas de cmo establecer una organizacin de seguimiento, cul es la labor de los jefes de proyecto en el mismo. Por otro lado, la
segunda parte del captulo muestra las herramientas de seguimiento como
es el cuadro de mando integral que servir para monitorizar el proyecto. Y
por ltimo se dan una serie de pautas para poder confeccionar un informe
de seguimiento de proyectos.
195
Antes de entrar de lleno en el captulo, es conveniente saber un poco de

historia. Se tiende a pensar que la gestin y el seguimiento es una disciplina
moderna, pero sus conceptos principales tienen sus races a finales del siglo XIX. La gestin de proyectos en su forma moderna, comenz hace slo
unas dcadas. Comenzando a primeros de los 60, en los que se empezaron
a establecer teoras sobre la gestin de los sistemas en el mundo de los negocios y de otras organizaciones, se comprob el beneficio de organizar el
trabajo alrededor de proyectos.
Esta forma de visin de la organizacin centrada en proyectos se desarroll ms cuando las organizaciones empezaron a entender la necesidad
crtica para su personal de comunicarse, y colaborar mientras integraban su
trabajo en mltiples departamentos y disciplinas y, en algunos casos, en la
empresa en su conjunto. Todos los modelos tuvieron una estructura comn,
un jefe de proyecto dirige un proyecto, aglutina a un equipo, y asegura la
integracin y comunicacin del flujo de trabajo horizontalmente a travs de
diferentes departamentos.
La gestin de proyectos que se ha desarrollado en las ltimas dcadas
se basa en la planificacin del trabajo y en el posterior seguimiento y control de la ejecucin. Se trata de una gestin predictiva que se desarrolla a
travs de un plan inicial que establece las caractersticas de tiempo, recursos, costes y secuencia de operaciones. La planificacin se realiza sobre
un anlisis detallado del trabajo descomponiendo el mismo en tareas.
Sobre esta informacin se desarrolla un plan de recursos y tiempos y se
siguen de cerca las desviaciones para tomar medidas y corregirlas, como
muestra la figura 8.1.
Figura 8.1. Diagrama de seguimiento de proyectos.
196
SEGUIMIENTO DE PROYECTOS Y CUADRO DE MANDO INTEGRAL
2. OBJETIVOS DEL SEGUIMIENTO DE PROYECTOS

El seguimiento de proyectos consiste, a nivel general, en supervisar de
una manera constante la evolucin y ejecucin de un proyecto para verificar si se est desarrollando en lnea con lo que se haba previsto en su
planificacin, tal y como se ha explicado en el captulo 3 del libro. Al hilo
de este propsito se debe de hacer un anlisis de las desviaciones que se
produzcan en todos los aspectos, e interpretar sus causas para poder hacer
una propuesta de acciones correctivas que las minimicen y permitan conseguir el objetivo del proyecto. En definitiva, contribuir a que los proyectos
se realicen de manera exitosa, maximizando el beneficio del cliente y el
margen para la empresa.
Antes de abordar detalladamente este captulo, es interesante establecer
de una manera general cuales son los objetivos especficos del Seguimiento.
Con esta definicin se entiende el control de los resultados comprometidos,
en los plazos establecidos y con el personal asignado para el mismo. Para
conseguir estos objetivos, se debe de recabar la informacin relevante de
los proyectos en cada una de sus fases, una vez recogida hay que procesarla de manera crtica y sistemtica y realizar un diagnstico eficaz. Esa informacin se entregar a los agentes involucrados en el proyecto de manera
oportuna y veraz.
Grficamente se puede establecer el seguimiento de proyectos como un
proceso de retroalimentacin en aras de conseguir el objetivo marcado por
el proyecto, ver figura 8.2.
Figura 8.2. Pautas para el seguimiento.
197
3. SEGUIMIENTO DE PROYECTOS Y ESTRATEGIA

Siguiendo con el contenido del captulo, es interesante analizar de qu
manera afecta y se interrelaciona el seguimiento con la estrategia de un proyecto o programa. La estrategia del proyecto, el plan de lo que se lograr
y cmo se har, es el punto de partida de la ejecucin y el establecimiento
del sistema de seguimiento. Asimismo es la base para determinar las operaciones que son necesarias para llevar a cabo las actividades de una manera
eficiente y eficaz. La evolucin del seguimiento y las medidas adoptadas
durante el mismo obligan a la revisin de la estrategia y la planificacin a
lo largo de todo el proyecto.
Es fundamental orientar la estrategia del proyecto al logro del mismo,
garantizar la eficacia de las operaciones que se realicen. Es una manera de
triunfar y de ir modificando y adaptando la estrategia en funcin de la labor
del seguimiento Hay que crear un entorno idneo para realizar esta tarea,
como queda reflejado en la figura 8.3.
Antes de comenzar a analizar el seguimiento de proyectos en s mismo,
es necesario explicar brevemente cul es la funcin del Seguimiento de Proyectos en cada fase de proyecto. Los proyectos se desarrollan normalmente
en distintas fases y en cada una de ellas los hitos ms importantes. Los hitos
quedan plasmados y validados en una serie de documentos especficos. La
correcta administracin del proyecto y la calidad del mismo quedan reflejadas en esos documentos que se realizan en el momento en que se produce
la validacin de los hitos.
La cadena de etapas y validaciones entre el surgimiento de la necesidad
y la entrega del proyecto se denomina ciclo de vida del proyecto. El proyecto se puede establecer bsicamente en tres fases:
a) Fase preparatoria, inicial o de lanzamiento del proyecto
Esta fase permite a los participantes lograr el entendimiento y acuerdo
sobre la manera de acometer el proyecto, en definitiva, la definicin clara
y explcita del mismo. Queda definida en el tiempo como la fase que se
encuentra entre la firma del contrato y la de implementacin propiamente
dicha. En ella se establece la estructura organizativa del seguimiento del
proyecto, e incluso se realizan las primeras planificaciones del mismo.
Aunque el seguimiento y control no es una tarea especfica de esta fase,
en muchos casos es interesante que al menos alguna de las personas que
van a participar posteriormente en la ejecucin del proyecto, se encuentre
en las reuniones de la fase preparatoria, para que de este modo pueda
entender e interiorizar el mismo desde su gnesis comercial, pero con mentalidad de ejecucin de proyecto.
198
Figura 8.3. Expresin grfica de estrategia y seguimiento de un proyecto.
El objetivo principal de la participacin es exponer ideas con mentalidad

de proyecto, que puedan ser provechosas en el futuro durante la ejecucin
del mismo, o incluso poner lmites a puntos que pueden dar problemas
posteriores, siempre y cuando stos sean factibles. De hecho es deseable
que la gerencia de proyectos participe en todas las fases del proyecto.
En esta fase inicial de diseo y formulacin de un proyecto, hay una
serie de tareas de seguimiento que deben llevarse a cabo, como establecer
claramente cul es el alcance del seguimiento, cul va a ser la organizacin
que va a acometerlo, qu personal debera de formar parte del equipo de
seguimiento y control, y cmo va a funcionar. En el caso de proyectos de
199
gran envergadura donde sea necesaria una organizacin compleja hay que
establecer una serie de comisiones de seguimiento y su marco de actuacin. Adems hay que marcar el calendario de reuniones de seguimiento,
la agenda orientativa de esas reuniones, y por ltimo hay que dejar estructurado el presupuesto indicativo del seguimiento.
Es indispensable establecer el tiempo que se destina a cada tarea de
seguimiento, y analizar las desviaciones que se vayan produciendo. De hecho, la puesta en marcha de un proyecto genera mucha incertidumbre, ya
que muchas veces sus caractersticas no se han formalizado en ese momento. Por eso es muy importante identificar y anticipar los riesgos del proyecto
lo antes posible y prever medidas para minimizarlos y corregirlos, tarea que
recae en el seguimiento de proyectos.
b) Fase de implementacin
Esta es la fase operativa del proyecto, es decir donde se realiza el trabajo
de proyecto propiamente dicho.
Durante toda esta fase se produce la labor de seguimiento, ya sea a travs de las reuniones de seguimiento del equipo, plasmados en los informes,
o las reuniones de los comits de seguimiento y de direccin. Tambien en
esta fase hay que establecer claramente cules son los indicadores clave
(KPIs) que integraran el cuadro de mando integral que se explica posteriormente.
La tarea de seguimiento durante esta fase debe de ser exhaustiva y tenaz.
A pesar de que los informes y las reuniones se produzcan en momentos
puntuales establecidos, el equipo de proyecto debe de monitorizar constantemente el mismo evitando las desviaciones y tomando decisiones siempre
y cuando sean de su mbito de actuacin, o convocando, si as lo considera, reuniones extraordinarias con los distintos comits.
La fase de implementacin del proyecto tiene dos sub-fases claramente
definidas, por un lado la de puesta en marcha del proyecto justo despus
de haberse dado la luz verde al mismo y por otro la de ejecucin del proyecto propiamente dicho. En cada una de ellas la labor de seguimiento
implica tareas diferentes aunque complementarias.
La fase de puesta en marcha del proyecto obliga al equipo de seguimiento a hacer una revisin del diseo del proyecto en lo que respecta al
seguimiento con los principales agentes involucrados. Tambin se debe de
elaborar un plan detallado de seguimiento, as como fijar el esquema de
funcionamiento de trabajo de los componentes del seguimiento o de las
comisiones, marcando el calendario de reuniones (el cual se debera validar desde su inicio), la estructura de agenda, la forma de realizacin de los
informes de seguimiento a lo largo de la ejecucin del proyecto. Es muy
200
importante la elaboracin de un acta de reunin despus de cada una de

ellas y hacerla circular entre los asistentes para recepcin de comentarios,
as como su actualizacin posterior.
La fase de ejecucin propiamente dicha implica la realizacin de una
serie de tareas para poder llevar a cabo el seguimiento. A nivel general hay
que asegurarse de que se satisfacen las necesidades de informacin para la
gestin, para ello es muy importante coordinar la recogida, el procesamiento y la gestin de toda la informacin relativa al proyecto. Para poder transmitir las conclusiones que se van generando durante la monitorizacin del
proyecto, hay que preparar las agendas y los contenidos de las reuniones
peridicas del seguimiento, tanto si hay comisiones de seguimiento como
si no las hay. En cada reunin de seguimiento se debera de prestar apoyo
a los agentes encargados de llevar a cabo la ejecucin del proyecto.
Por otro lado el equipo encargado del seguimiento de proyectos debe
de llevar a cabo las labores de supervisin del proyecto, preparando y facilitando la revisin anual y el informe de ejecucin y desarrollo correspondiente. Es importante que este equipo comunique los resultados de cada
reunin peridica o extraordinaria a cada parte interesada, y que ayude a la
reprogramacin del proyecto, si fuera necesario de acuerdo a los resultados
tomados en las reuniones de seguimiento.
c) Fase de finalizacin
Este es el punto de entrega del proyecto, ya sea para su explotacin
posterior, en el caso de una instalacin, o simplemente para su finalizacin. Esta fase es muy importante desde el punto de vista del seguimiento
de proyectos, es el momento de ver los frutos de labor del seguimiento.
En esta fase se suelen producir discrepancias con el cliente a la hora de
traspasar la responsabilidad en un proyecto con arranque o la entrega final
para su explotacin por ejemplo en una instalacin, y es labor del equipo
de seguimiento del proyecto minimizar los problemas de ese trasvase. Las
reuniones y principalmente las actas de seguimiento son de especial ayuda
en estos momentos.
Adems la finalizacin de un proyecto suele estar asociado a la aceptacin por parte del cliente del mismo, y suele conllevar pagos asociados.
Por lo tanto la labor del equipo de seguimiento de proyecto se vuelve fundamental en esta fase, mostrando cual ha sido la evolucin del mismo, y
convenciendo al cliente de la buena ejecucin realizada. En esta fase hay
que cerrar todos los puntos y acciones abiertas durante el desarrollo del
proyecto, realizar las reuniones de cierre finales y, en caso de que el proyecto debiese llevar una memoria final, realizarla, todas estas tareas deben
de ser realizadas por el equipo de seguimiento del proyecto.
201
4. COMISIONES DE SEGUIMIENTO
El trmino comisin, segn el diccionario de la Real Academia de la Lengua Espaola, proviene del trmino latn comisin-onis, que se interpreta
como accin de cometer, asimismo proporciona las siguientes definiciones:
orden y facultad que una persona da por escrito a otra para que ejecute
algn encargo o encargo que una persona da a otra para que haga alguna
cosa y conjunto de personas encargadas por una corporacin o autoridad
para entender en algn asunto. Por lo tanto, la comisin de seguimiento de
un proyecto es un rgano que vela por el cumplimiento de los objetivos de
evaluacin y control de las actuaciones planificadas en el proyecto.
4.1. Tipos de comisiones
Las comisiones en general constituyen los brazos ejecutores del seguimiento de los proyectos, son de muy distinta ndole y cada una reporta a
diferentes estamentos u rganos dependiendo del tipo de estructura organizativa de la empresa que promueve el proyecto. En la creacin de una
comisin es fundamental establecer los trminos de referencia de la misma,
es decir, la definicin de las responsabilidades, el cometido de las mismas,
subordinacin o la jerarqua de los informes que se generen. En un proyecto se presentan varios tipos de comisiones diferenciadas. Existen comisiones temporales o permanentes, tambin comisiones internas del equipo
del proyecto o externas en las que aparecen miembros ajenos al equipo del
proyecto como son el cliente, o los stakeholders.
En este captulo se definen una serie de comisiones o comits que pueden conformar un proyecto dependiendo de la envergadura, la complejidad
del mismo o incluso la fase en que el proyecto se encuentre. Como se acaba
de explicar, las comisiones estn formadas por un conjunto de personas
que se renen y se comprometen a discutir, decidir y resolver los problemas que van surgiendo a lo largo de un proyecto, las ventajas de trabajar
en comisiones es que se forman grupos multidisciplinares de representantes
de varios estratos, como pueden ser administracin, bancos, entidades que
promueven los proyectos, otros organismos, etc. Como desventaja, la toma
de decisiones a veces es ms costosa pues los intereses entre miembros son
contrapuestos. Se pueden clasificar los comits o comisiones de la siguiente
manera:
a) Comit directivo. Representan a la propiedad y se encarga de defender los intereses de la misma.
b) Comit ejecutivo. Es nombrado por el comit directivo para ejecutar
los acuerdos que se hagan en el seguimiento de los proyectos. Es el
202
mximo rgano de decisin del proyecto y se encarga de revisar peridicamente los compromisos contrados por cada una de las partes,
evaluando la consecucin de los objetivos e hitos propuestos por
cada uno de los participantes, aprobando la continuidad o cancelacin del proyecto, y en general, llevando a cabo todas las acciones
relacionadas con la aprobacin y control de actuaciones necesarias
para el buen desarrollo del proyecto.
c) Comit consultivo (o asesor). Est integrado por especialistas que emiten dictmenes sobre asuntos que le son consultados. Este comit no
tiene pre-establecido un calendario de reuniones y se rene cuando
es necesario para desbloquear temas muy concretos.
Existen tambin los comits tcnicos que son los encargados de la puesta en funcionamiento del proyecto a nivel tcnico y departamental.
Atendiendo a las distintas fases que conforman un proyecto, se puede
establecer otra clasificacin de la comisiones, temporales o permanentes.
Durante la fase inicial en la que todava no se ha diseado y aprobado
completamente el proyecto, puede ser necesaria una comisin de evaluacin del proyecto de acuerdo a los criterios ms relevantes del mismo. Esa
comisin debera de estar compuesta por tcnicos y expertos que sean capaces de valorar la idoneidad y factibilidad del proyecto.
Dependiendo del tipo de imprevistos que puedan surgir a lo largo de
la ejecucin del proyecto se pueden definir dos tipos de comisiones. La
comisin permanente del proyecto, en la que tienen cabida las comisiones
y comits que se han definido anteriormente y que permanecen vivos a lo
largo del proyecto, y, las comisiones ad-hoc, que surgen cuando se presentan problemas puntuales y se disuelven una vez resueltos. Si lo que las fija
son los integrantes de las mismas, pueden ser internas del equipo proyecto
o tener miembros externos, cliente o stakeholders relevantes.
4.2. Funciones de las comisiones de seguimiento
Las comisiones de seguimiento son utilizadas en la gestin y ejecucin
de proyectos para poder realizar un mejor control y seguimiento de proyectos, principalmente en proyectos complejos o de gran envergadura. Como
se acaba de explicar las comisiones tienen como principal objetivo la coordinacin, el control y el seguimiento as como la resolucin de cualquier
problema que se presente durante la ejecucin del mismo y que no pueda
ser resuelto por el equipo de seguimiento correspondiente. Es fundamental
establecer los trminos de referencia de las mismas, es decir, definir sus responsabilidades, su cometido, marcar la subordinacin o marcar la jerarqua
de los informes que se emitan.
203
A pesar de que su principal objetivo es el arriba mencionado tienen

otras funciones que son tambin de gran importancia en el seguimiento
de proyectos. Las comisiones de seguimiento pueden poner en prctica las
directrices marcadas por el comit de direccin, junto al equipo de proyecto. Dependiendo de su naturaleza realizan labores de asesoramiento sobre
calidad, gestin de organizacin, metodologa de trabajo o herramientas de
soporte para el seguimiento. Si es preciso pueden hacer de interlocutores
entre los distintos agentes externos e internos del proyecto, as como difundir, en colaboracin con el equipo de seguimiento, las distintas medidas a
ejecutar e lo largo del proyecto.
Las Comisiones de Seguimiento suelen estar formadas por personas con
un amplio bagaje profesional por lo que ayudan en la previsin de posibles
desviaciones que intuyen pueden aparecer, evaluando riesgos y planteando
acciones correctivas. Pueden asesorar al equipo de seguimiento de proyectos sobre el dimensionamiento de los esfuerzos y los recursos que hay que
asignar a cada tarea.
Asimismo, al ser comisin, pueden ayudar en la coordinacin de las tareas que precisen de varios agentes. Al no pertenecer al equipo de proyecto
directamente, y realizar en parte labores de auditora, pueden plantear o
recomendar al comit de direccin ideas o iniciativas que consideren necesarias u oportunas para la mejora del proyecto.
4.3. Integrantes de las comisiones de seguimiento
Una vez analizadas qu son y para que se utilizan las comisiones en
el seguimiento de proyectos se va a estudiar cuales son los principales
integrantes de dichas comisiones en un proyecto. Como se ha explicado
anteriormente, los representantes de las comisiones son profesionales con
una amplia experiencia en la gestin de proyectos, y pueden venir de muy
distintos mbitos, no obstante, una parte de las comisiones suele estar establecida previamente.
Lo ideal es que el director tcnico y el jefe del proyecto (aunque a veces son la misma persona) formen parte de la comisin de seguimiento. El
director o gerente de la empresa que realiza el proyecto, y el representante
de la empresa que lo contrata tambin deberan de estar dentro de esta
comisin. En el caso de proyectos pblicos sera un representante del departamento que lo lidera, y en el caso de que el proyecto est financiado,
un representante de la entidad que financia el mismo. Este grupo de profesionales son los que forman el ncleo de una comisin de seguimiento.
Durante las reuniones, uno de los representantes de la empresa que promueve el proyecto actuar como secretario del comit/comisin de seguimiento, y se encargar de las convocatorias de las reuniones as como de
204
levantar el acta de las mismas con los acuerdos que se hayan alcanzado.
La manera en la que fluye la informacin entre los comits queda reflejada
en la figura 8.4.
Figura 8.4. Flujo de informacin entre comits

dentro del marco de un proyecto.
5. EL CUADRO DE MANDO INTEGRAL

Para llevar a cabo un buen seguimiento de proyectos hay que apoyarse en algunos mtodos y tcnicas existen en la actualidad, a travs
de los cuales y estableciendo indicadores estratgicos o KPIs (Key Performance Indicators) se pueda verificar el correcto funcionamiento del
proyecto. La primera de ellas sera a travs del desarrollo de un Cuadro
de Mando Integral (CMI) que tiene como objetivo final la correcta ejecucin de la estrategia establecida en la empresa a travs de una definicin
de objetivos, eficazmente relacionados, alineados y medidos directa o
indirectamente.
Esta teora, que se desarroll para empresas y que supera los conceptos
tradicionales en los que todo se fundamentaba en los resultados econmi-
205
cos, se empez a implantar en los aos 90 a travs de la teora del Balanced Scorecard [Kaplan et al., 2000], englobando estos objetivos bajo cuatro
perspectivas: el servicio a los clientes, los procesos internos, la formacin y
el crecimiento, y por ltimo la econmica, de tal manera que se consiguiera
tener presente otras consideraciones diferentes a las econmicas, y todo
ello como su propio nombre indica de una manera integral.
Por ello, para las empresas que los emplean debe ser algo ms que un
sistema de medicin o meramente de control, y transformarse en un nuevo
marco o estructura para crear indicadores (KPIs) derivados de la estrategia.
En este sentido, se considera tambin un buen mtodo para el seguimiento
de proyectos, tanto a corto plazo como aquellos que sean a ms largo plazo, siempre y cuando se asuma la importancia del concepto de la integracin anteriormente citada (como por ejemplo: costes, plazos de ejecucin,
personal disponibles), ya que permitir a la direccin del proyecto tomar
decisiones en tiempo real.
Su finalidad debe ser establecer los pilares para poder ejecutar la estrategia de una manera eficiente, estableciendo una meta [Goldratt, 2005] clara
que permita definir el rumbo que debe seguirse para alcanzarla. Para definir
esta meta la organizacin debe tener presente:
t -BNJTJOEFMBPSHBOJ[BDJO PMPRVFFTMPNJTNP{QPSRVFYJTUF
t 4VTWBMPSFTQSPQJPT
t -BWJTJORVFMBPSHBOJ[BDJOUJFOFEFTNJTNBEFOUSPVOPT P
15 aos.
Una vez aprobada la meta que la organizacin se propone alcanzar hay
que establecer una estrategia para conseguirla, determinando una serie de
objetivos intermedios enlazados bajo relaciones causa-efecto entre ellos. Si
bien no hay un nmero clave exacto de objetivos, la experiencia aconseja
que el nmero de objetivos que un cuadro de mando integral contiene
debe ser limitado, entre 10 y 15, pues hay que valorar que no todo es estratgico en una organizacin y, adems, que un nmero superior se convierte
en inmanejable ya que por lo menos para cada objetivo habr un indicador
que lo mida. En este punto conviene hacer una pequea reflexin sobre la
dificultad en acertar con estos indicadores, puesto que si bien los objetivos normalmente se suelen tener ms o menos claros, podra darse el caso
de que si se yerra demasiado en la eleccin de los indicadores, la organizacin se aleje de alcanzar su meta y as, la aplicacin de un CMI sera ms
perjudicial que beneficioso, o incluso que, acertando, no se establezcan
bien las valoraciones de la causa-efecto entre ellos y haya un desvo en el
rumbo establecido.
Otras herramientas tienen su foco en el establecimiento exclusivamente de indicadores, en este caso indicadores de seguimiento, a travs de
206
los cuales se pueden ir validando los resultados de ciertos objetivos. El

principal inconveniente de utilizar estos indicadores es la prdida de la
perspectiva integral de todos los elementos que una organizacin disponer
(humanos, materiales o econmicos) y el no establecer la influencia de cada
uno de ellos en los dems, cuestiones que el CMI ha superado.
5.1. Las perspectivas del CMI
Tal y como se ha mencionado en captulos anteriores (captulos 2 y 3)
una vez establecidos los objetivos y el alcance el proyecto y se ha planificado la ejecucin de las tareas conviene elaborar un mapa de dichos objetivos, que no es otra cosa que la representacin grfica de la estrategia, y
que al final ser el armazn de la herramienta informtica que de visibilidad
al proceso.
Es importante tener presente cuando se vayan a determinar dichos objetivos dos caractersticas innatas de ellos, puesto que estos deben ser:
t .FEJCMFT ZBRVFTJOPGVFSBBTOPTFQPESBONFKPSBSZTFSBEJGDJMmente posible implementar los indicadores necesarios para comprobar los resultados que se desean;
t "MDBO[BCMFTBMFOMB[BSMPTDPOMPTSFDVSTPTEJTQPOJCMFTFOMBPSHBOJ[Bcin, tales como los humanos, econmicos o materiales, imprescindible si se quiere ser realista.
La necesaria interconexin causa-efecto de un proceso integral como
este hace que los objetivos deban elegirse recordando que todas las partes
que integran el proyecto influirn en mayor o menor grado en el resultado
final. Para ayudar a no perder este enfoque una buena ayuda es incorporarlos en cada una de las perspectivas del CMI que proponen Norton y Kaplan
y que a continuacin se describen.
En la figura se establece un ejemplo de cmo se van relacionando los
objetivos en las perspectivas que ms adelante se describen y cmo se
relacionan entre ellos, de tal manera que mejorando un objetivo se puede
comprobar su efecto en otro.
207
Figura 8.5. Relacin causa-efecto entre perspectivas.
a) Perspectiva cliente
Todo proyecto debe satisfacer las necesidades del cliente, por ello bajo
esta perspectiva se engloban aquellos objetivos que permitirn validarlas,
debiendo responder a tres preguntas:
t {2VJOFTTPOOVFTUSPTDMJFOUFT
t {2VFTQFSBOOVFTUSPTDMJFOUFTEFOPTPUSPT
t {2VWBMPSQVFEFBQPSUBSOVFTUSBBDUVBDJO
b) Perspectiva de procesos internos
Esta perspectiva debe identificar los procesos internos clave en los que
la organizacin necesita destacar para poder ofrecer el mayor servicio posible a los clientes, siendo muy importante en esta perspectiva saber conjugar
los procesos a corto plazo con la innovacin en aqullos a medio y largo
plazo.
208
c) Perspectiva de formacin y crecimiento/recursos

Las perspectivas hasta ahora citadas identifican los factores ms crticos
para el xito actual y futuro; sin embargo, la de formacin y crecimiento
identifica los recursos que la empresa ha de disponer para conseguir una
mejora a futuro. Incluye las personas o los sistemas de informacin. La
idea de mejora continua que debe presidir la organizacin tendr como
resultado final la mejora de los procedimientos y de los sistemas de gestin.
En el sector pblico tiende a denominarse perspectiva de recursos, en lo
que se englobaran tanto aspectos tangibles y por tanto mesurables y otros
intangibles, como la calidad de los conocimientos del personal o la calidad
de los sistemas de informacin, difcilmente mesurables ni no es a travs de
aproximaciones.
d) Perspectiva econmica
Incluye indicadores financieros que permitan disponer de visibilidad sobre las consecuencias econmicas, fcilmente medibles, de la ejecucin
de los presupuestos. En esta perspectiva es importante validar la eficiencia del gasto, no exclusivamente la ejecucin del presupuesto del que se
ha dispuesto, de tal manera que no se valore ms como restriccin que
como objetivo.
Teniendo en cuanta la separacin entre proyectos en los que haya nimo de lucro con respecto a proyectos en los que no exista tal necesidad,
esta perspectiva debe dejar claramente definida la eficiencia mencionada,
ya que la optimizacin de los recursos econmicos puestos a disposicin
del proyecto debe ser gua continua del comit ejecutivo del proyecto.
5.2. Los indicadores
Establecidos los objetivos que se deben alcanzar para lograr la meta de
la organizacin, es necesario evaluar si se estn alcanzando. Bajo la premisa de que lo que no se puede medir no se puede mejorar, es necesario
el establecimiento de indicadores que permitan validar dicha consecucin.
En Espaa se dispone de la Norma UNE 66175: 2003 Gua para la implantacin de sistemas de indicadores, que determina los distintos puntos que
hay que considerar para su correcta definicin y que puede servir de modelo a la hora de establecer indicadores, siempre teniendo en consideracin
ciertas caractersticas propias de los indicadores como son:
t 4JNCPMJ[BOVOBBDUJWJEBEJNQPSUBOUFPDSUJDB
t /PEFCFOTFSBNCJHVPT
t 5JFOFORVFTFSGDJMFTEFFOUFOEFS NBOUFOFSZVUJMJ[BS
209
t 4VTSFTVMUBEPTTPODVBOUJGJDBCMFT
t %FOUSP EF MB PSHBOJ[BDJO P FRVJQP EF QSPZFDUP TF FTUBCMFDFS EF
antemano el responsable de su medicin y con qu criterios.
t %FCFOTFSGJBCMFTFTEFDJSDBQBDFTEFQSPQPSDJPOBSDPOGJBO[BBMPT
usuarios sobre la validez de las sucesivas medidas.
El proceso de definicin de los indicadores requiere que se defina con
claridad:
t 2VNFEJS EFGJOJFOEPQFSGFDUBNFOUFZDPOMBNBZPSDMBSJEBEQPTJCMF
la finalidad del indicador.
t $NP NFEJS QSFDJTBOEP BM NYJNP EFUBMMF QPTJCMF MB GSNVMB FNpleada, de tal manera que no hay posible ambigedad en la interpretacin.
t $VOEPNFEJS FTEFDJS MBQFSJPEJDJEBEEFMBFYUSBDDJOEFMPTEBUPT
que podr ser diaria, semanal, mensual, o incluso con mayor perodo
de tiempo, dependiendo del valor que nos aporten los datos para un
perodo de tiempo concreto.
t -B GVFOUF EF MB NFEJDJO EF UBM NBOFSB RVF UPEB MB PSHBOJ[BDJO
sepa la procedencia de los datos.
t -PTSFTQPOTBCMFTEFBMDBO[BSMPTWBMPSFTQSPQVFTUPTQBSBDBEBJOEJcador as como los responsables de llevar a cabo el seguimiento de
los mismos.
t :MBTNFEJEBTDPSSFDUPSBTBJOUSPEVDJS RVFQFSNJUBODPSSFHJSMBTQPsibles desviaciones que se produzcan en los valores a alcanzar para
cada uno de los indicadores.
Muchas veces se cree tener claro qu indicadores se deben poner
sin saber el por qu de los mismos. Nada ms lejos de la realidad y que
seguramente llevarn a una calle sin salida, por ello es importante tener
presente que en ningn momento debe definirse el indicador y luego establecer el objetivo que se pretendera alcanzar. Al contrario, es necesario
aclarar primero cul es el objetivo buscado, establecer el o los indicadores
necesarios y determinar los valores a alcanzar en cada indicador. En todo
momento, estos indicadores tendrn por objeto proporcionar informacin
sobre los parmetros ligados a actividades o a los procesos implantados y
permitirn validarlos. En este sentido, su gestin consistir por una parte
en desarrollar los objetivos segn una estrategia de mejora continua previamente definida y, por otra, efectuar los ajustes necesarios para alcanzar
esos objetivos.
En los apartados anteriores se ha puesto de manifiesto la importancia de
corregir posibles desviaciones de no alcanzarse los objetivos propuestos, y
para ello los indicadores funcionarn a modo de seales o guas indicadoras, siendo imprescindible establecer como apartado dentro de la definicin
210
de los indicadores, una propuesta de medidas correctoras que permitan

adelantarse a dichas desviaciones y poder actuar lo antes posible para mejorar los valores a alcanzar por los indicadores. Servirn tambin de utilidad
en las reuniones de las Comisiones de Seguimiento para verificar si dichas
medidas estn teniendo resultados o proponer otras medidas.
Ejemplos de indicadores para un gestin integral de proyectos se consideran:
t
t
t
t
t
t
%FTWJBDJPOFTEFFKFDVDJOEFMQSFTVQVFTUP
3FUSBTPTFOFMQSPZFDUP
/NFSPEFEJTDPOGPSNJEBEFTEFMDMJFOUF
1PSDFOUBKFEFJODJEFODJBTTJOSFTPMWFS
&TUBEPEFMBEPDVNFOUBDJOUDOJDBBFOUSFHBSBMDMJFOUF
/NFSPEFIPSBTIPNCSFVUJMJ[BEBTQBSBDPNQMFUBSUBSFBTQSPHSBmadas.
t 7BMPSBDJOEFSJFTHPTEFMQSPZFDUP
5.3. Elaboracin de un Cuadro de Mando Integral
Cuatro ideas son las que deben estar presentes a lo hora de llevar a cabo
un CMI. La primera de ellas es la necesidad de conseguir el consenso de la
organizacin, de este modo, todo el personal estar involucrado y se sentir
partcipe de la consecucin de los objetivos; de tal manera que el personal
se encuentre motivado, ya que cada persona puede comprender la utilidad
de su participacin y apreciar el impacto de su esfuerzo. La segunda es la
comunicacin del proyecto a toda la organizacin; es decir, conseguir el
alineamiento y que la estrategia aprobada sea conocida, que permitir que
todos los departamentos que la conforman sepan hacia dnde deben bascular y priorizar sus esfuerzos. Si tan importante es establecer una buena estrategia lo es tambin la necesidad de controlar su cumplimiento, cuestin
que se considera fundamental para realimentar el sistema y llevar a cabo
pequeos ajustes. Por ltimo, se conseguir disponer de una cadena de valor de alto rendimiento, ya que se identificarn las iniciativas que realmente
aportar un valor estratgico, desechando lo superfluo y que aade ruido
en la organizacin.
a) Equipo de Trabajo
Un Cuadro de Mando Integral no puede ser realizado nicamente por
una sola persona, sino que lo habitual es conformar un grupo de trabajo
que rena las siguientes capacidades: anlisis, desarrollo y experiencia. El
equipo de anlisis estar formado por personal cercano a la direccin de la
organizacin, ms personal de consultora si fuera necesario. Sus cometidos
211
sern la definicin de los requisitos operativos del cuadro de mando

integral, mientras que el equipo de consultora interpretar esas necesidades operativas que permitir, entre otras cuestiones, la bsqueda de
datos con los que definir los indicadores y proponer ciertas acciones de
mejora. Este equipo debe estar presente en la fase preparatoria o inicial
del proyecto, de tal manera que pueda tener un mejor conocimiento de
la finalidad del mismo, as como formar parte del equipo de seguimiento
del proyecto, al objeto de poder dar una respuesta lo ms rpida posible
a travs del CMI.
Para el equipo de desarrollo es conveniente, si no se dispone de personal en la organizacin, que el mismo personal de consultora elabore la
herramienta informtica, siempre bajo los criterios del equipo de anlisis.
Al igual que el equipo de anlisis, debe estar muy inmerso a lo largo de la
duracin del proyecto, puesto que la herramienta se desarrollar para ser
de utilidad al personal que maneje los correspondientes informes. Por ltimo, es fundamental el establecimiento de un equipo de expertos a tiempo
parcial, que integre personal de distintos departamentos de la organizacin,
con la experiencia necesaria en los diferentes campos, y que validen tanto
los objetivos como los indicadores que se vayan estableciendo.
b) Proceso para la elaboracin de los KPIs
Una vez que se ha establecido el equipo de trabajo, el proceso que se
debera seguir es el siguiente. Por parte del equipo analista y una vez definida la finalidad y los objetivos a alcanzar en el proyecto por parte del
comit directivo, se debe empezar el proceso de comunicacin a toda la organizacin para conseguir la necesaria sinergia en los trabajos de cada departamento que facilitar su coordinacin, siendo necesario el alineamiento
y coordinacin de las acciones, ya que iniciativas aisladas que pueden resultar beneficiosas, a veces solo consiguen ptimos locales y no ptimos
globales, razn de ser de la estrategia implementada.
A partir de este momento se deben comenzar a definir los indicadores
estratgicos (KPIs), ya que es cuando se dispone de un verdadero prisma
integral, y presentarse al comit directivo para aprobacin a medida que
se vayan estableciendo. Acordados los indicadores se debe iniciar el trabajo del equipo de desarrollo para la implantacin de la herramienta que
de visibilidad al CMI, y que permitir ir definiendo los diferentes informes de
seguimiento a partir de los datos extrados y poderlos presentar en las reuniones de las Comisiones de Seguimiento que posibilitarn la monitorizacin
del proyecto, como ayuda inestimable para el seguimiento del mismo y la
actuacin temprana en caso de desviaciones.
212
Para la determinacin de los indicadores (KPIs) se deben llevar a cabo

tantas reuniones del personal componente de los diferentes equipos (analista, de desarrollo y de expertos en su caso) como sea necesario, dada la
complejidad de su concrecin. Si bien debe buscarse que los indicadores
sean lo ms automticos posibles y no haya probabilidad de intervencin
humana en su resultado, puede darse el caso de que al principio y para
alguno de ellos, el resultado/indicador pueda modificarse de manera manual al intervenir el conocimiento y experiencia del personal del equipo de
trabajo. As, si por valor automtico el resultado del indicador saliera por
debajo del valor que se considera adecuado, pudiera darse el caso que no
se considerara contraproducente y variar el cdigo de colores de manera
manual.
6. INFORMES
Durante el desarrollo y ejecucin de un proyecto se toman diferentes
decisiones en funcin de distintas circunstancias. Las justificaciones de cada
una de estas decisiones y el escenario presente a la hora de tomar esa decisin, son parte de la historia de dicho proyecto, y deben quedar en el
conocimiento del equipo de proyecto o de la empresa tanto como parte
del conocimiento, como para formar parte de las evidencias del proyecto.
La forma de dejar constancia de estos hechos es por medio de uno o varios
informes.
Un informe es un documento escrito que presenta informacin y datos
relevantes a personas con capacidad de toma de decisiones sobre un tema
que es de su inters. Un informe siempre est elaborado por personas con
autoridad tcnica en la materia de modo que, al comunicarse con otro grupo, el receptor, que tambin posee un cierto conocimiento de la materia de
que se trate, ambos tengan una visin similar o idntica del tema. El informe siempre se elabora pensando en el receptor, por lo que tanto el nivel de
detalle de la informacin aportada como el lenguaje empleado deben estar
adaptados a quien lo recibe para que le sea til. Slo existe un criterio para
establecer la extensin de un informe, y no es otro que el contener nicamente la informacin necesaria y suficiente para su propsito. Un informe
demasiado corto o excesivamente largo puede producir en el lector una
sensacin de insatisfaccin que le haga rechazarlo, con lo que, se lograra
el efecto contrario al deseado.
Este concepto ni limita el alcance de contenidos ni el de la distribucin
del mismo, ya que esta toma de decisiones puede estar en la alta direccin
de la empresa cliente para adoptar una decisin econmica, o en el responsable de un grupo tcnico que tenga que evaluar una solucin. Tampoco
213
impone un formato de entrega, es decir, no se impone que est en soporte

fsico papel, pudiendo, cada vez ms, entregarse en formato electrnico,
incluso con firmas digitales que aseguren la integridad y autenticidad del
documento.
Por medio del informe de seguimiento, el equipo de proyecto deja constancia de la evolucin del proyecto o de una parte de l en un momento
determinado del tiempo y en un rea concreta de actividad. Es, por tanto,
la va de comunicacin de un equipo de proyecto con el mundo exterior,
siendo ste todo aquel grupo o individuo, fuera del equipo, que tenga
intereses en el proyecto, como pueden ser nuestro cliente, organismos pblicos, administraciones, proveedores, o, incluso, otras partes o grupos de
nuestra propia empresa. Este tipo de informes suele tener una periodicidad
previamente establecida.
6.1. Caractersticas y clasificacin de los informes
Un informe nunca es un documento annimo, siempre tiene un autor o
autores conocidos que se hacen responsables de su contenido, de las opiniones incluidas, de los hechos narrados o de los datos expuestos, por lo
que su integridad debe ser preservada y estar convenientemente revisados
para evitar interpretaciones incorrectas.
Independientemente de para qu se elabore y del tipo, de lo que nos
ocuparemos posteriormente, cualquier informe contiene datos verificados
por el autor, junto con los procedimientos y metodologa utilizados para
la obtencin de dichos datos de forma que se facilite su verificacin y su
comprensin por parte del lector y, en caso necesario, las recomendaciones
que estime necesarias o convenientes.
El informe se elabora siempre bajo la ptica del autor, es decir, presenta
un grado se subjetividad elevado, aspecto que no se puede obviar de cara
a una posterior revisin, siempre necesaria antes de su entrega. Si bien se
pueden considerar mltiples aspectos para clasificar un informe, podra
decirse que cualquier informe se puede encuadrar en uno de los siguientes tipos, independientemente de su contenido: expositivo, interpretativo y
demostrativo.
El informe expositivo es una mera narracin de hechos acontecidos
sin plantear conclusin alguna, pero siempre bajo la ptica del autor, por
el contrario, el interpretativo, tras una narracin de hechos, presenta unas
conclusiones segn el criterio del autor, mientras que el ltimo tipo, demostrativo lo que trata es de demostrar una tesis por medio de unos datos
y procedimientos que permiten verificar las conclusiones expuestas en el
informe. En todos los casos, existe un cierto grado de subjetividad, mayor
214
o menor segn el tipo, y en todos se cuenta con el conocimiento o pericia

del autor.
En cuanto a la clasificacin por temas, evidentemente existen muchos
tipos, dependiendo si tratan un tema concreto, en cuyo caso pueden ser de
temas econmicos (costes, flujo de caja, etc.), de recursos humanos (por
ejemplo, evolucin de la plantilla asignada al proyecto), tcnicos (riesgos,
anlisis de soluciones, procesos, etc.), calidad, legales, o bien que traten varios temas a la vez, como puede ser el caso de los informes de seguimiento,
que en un solo informe pueden abarcar todos estos aspectos en lo que a un
proyecto y el equipo que lo desarrolla se refiere.
Como caractersticas fundamentales se citan algunas consideradas como
necesarias a la hora de abordar su elaboracin:
Responde a una peticin, ocasional o peridica.

Aporta informacin especfica.
Est organizado y estructurado.
Es autocontenido, no debe requerir documentacin complementaria
para permitir la toma de decisiones, si requiere de informacin adicional, por ejemplo, un informe tcnico que sea preciso para valorar
una solucin, debe aadirse como un anexo.
El lenguaje y nivel de contenido tcnico deben estar adaptados al receptor, de modo que su formacin y nivel de conocimientos lo hagan
inteligible.
Debe ser simple y comprensible, aportando la informacin estrictamente necesaria por una parte, y por otra usando cualquier procedimiento que facilite el entendimiento de la informacin, como pueden
ser ejemplos prcticos, tablas, figuras, etc.
Si el informe resultase, por cualquier motivo, muy extenso, se recomienda la generacin de un Resumen Ejecutivo, corto, no ms de 2 o 3
pginas, que permita obtener una visin global del contenido y facilitar su
lectura.
6.2. Realizacin de un informe
La realizacin de cualquier informe pasa por las mismas fases:
Determinacin del tipo, en funcin de la informacin que queramos
transmitir, porque esta informacin condicionar el enfoque de las
etapas posteriores.
Identificacin del receptor o receptores, lo que nos permite proporcionar un nivel de detalle y lenguaje adecuados para que sea til.
215
Obtencin, verificacin y filtrado de la informacin, plasmando slo

lo necesario, que est verificado y sin redundancias ni informacin
superflua. Este filtrado se hace bajo el criterio del autor.
Elaboracin del informe; este es el punto de no retorno, es el momento en que la imagen del autor se hace visible a los dems.
Estas fases pueden representarse en el diagrama representado en la figura 8.6
Figura 8.6. Proceso de elaboracin de un informe.
216
Es necesario, aunque no se presente fsicamente en papel, cuidar tanto

el aspecto (organizacin del texto, tipografa, estructuracin de la pgina,
estilo de redaccin, ortografa, etc.) como su forma, debiendo estar bien
estructurado y con la informacin bien organizada, los grficos y tablas
deben ser legibles con tamao de letra adecuado y las imgenes claras y
visibles.
El informe tiene un cierto paralelismo con una obra literaria en el sentido de que debe constar de tres partes bien diferenciadas, y que responden,
cada una de ellas, a una serie de cuestiones:
Introduccin: es el inicio del informe y permitir a quien lo lee centrarse en el tema y condiciones de contorno que existen para ser
capaz de situarse en la escena y entender el resto. Respondera a
cuestiones del tipo: por qu se ha elaborado?, cul es el objetivo del
informe?, con qu datos y medios se ha elaborado?
Desarrollo o nudo: cuerpo central del informe, donde se vierte la
informacin que debe mantener coherencia y flujo lgico de la misma para una correcta interpretacin. Es en esta parte donde grficos,
tablas, etc. cobran importancia. Respondera a la cuestin del qu se
ha hecho?, cmo?, qu hemos obtenido?
Conclusiones: fase de cierre del informe, en la que se pueden verter
conclusiones, recomendaciones o resultados, siendo, adems, la terminacin lgica del informe.
Pero ese paralelismo mencionado anteriormente no debe separarnos de
la caracterstica, quizs, ms importante: la simplicidad. El informe debe ser
escueto, no ms (ni menos) de lo necesario, pero a la vez, entendible, con
lenguaje adecuado a los destinatarios.
6.3. El informe de seguimiento
Anteriormente se ha visto la necesidad de efectuar un seguimiento del
proyecto para asegurar la consecucin de los objetivos previstos en calidad,
coste y plazo, pero esto sirve de poco, dentro de la comunidad del proyecto
(cliente, empresa y grupo de proyecto) si no fluye la informacin de estado
que nos permita evaluar la situacin en un momento detrminado y compararla con la esperada. La forma ms prctica de transmitir esta informacin
es por medio de los informes de seguimiento o progreso, que pueden contener informacin de todo tipo relacionada con la vida de nuestro proyecto,
es decir, no limitarlo a datos tcnicos o econmicos.
Cuando, al inicio de la seccin, se dice que el informe est elaborado
por personas con autoridad tcnica en la materia, debe interpretarse, en el
caso de los informes de seguimiento, que stos se elaboran por diferentes
217
miembros del equipo de proyecto, cada uno en su parcela de responsabilidad, y quedando consolidado por parte del Jefe de Proyecto como mxima
autoridad. Una adecuada estructuracin del mismo, permitir al receptor,
por una parte, conocer qu es lo que est hecho en un momento dado, por
qu se ha decidido hacerlo de esa forma, qu est previsto para un prximo
perodo de tiempo, riesgos, problemas, etc., as como datos econmicos,
calendarios, evolucin de personal, compras o cualquier otro aspecto relevante, y por otra parte, con la secuencia de dichos informes, conocer con
un cierto nivel de detalle, la evolucin del proyecto.
El informe de seguimiento suele estar solicitado en los contratos como
parte de, o requisito previo a, las reuniones de las comisiones de seguimiento del proyecto, de modo que se puede analizar la evolucin, comparar con
los planes previos y tomar las decisiones adecuadas. Una vez realizado el
primer informe de seguimiento en la vida de un proyecto, y acordado con
el cliente, este informe puede convertirse en la plantilla o modelo para los
siguientes, lo cual proporciona una gran ventaja al tener estructurada la informacin de la misma forma en todos, pudiendo localizarse con facilidad
un determinado tipo de informacin en cualquier versin del mismo. Esto,
con ser una gran ventaja, presenta el riesgo de hacer un copia y pega de
informacin que conduzca a componer un informe incorrecto, con informacin inadecuada u obsoleta para el receptor. A la vista de este riesgo,
se hace ms patente la necesidad de una revisin profunda del informe de
seguimiento por parte tanto del autor como de un revisor diferente antes
de ser enviado.
Considerando la estructura dada en la subseccin 6.2, puede decirse que
en la seccin de Introduccin, se indican, adems de los datos del contrato
y objetivo del proyecto, la ventana temporal en la que se han desarrollado
las acciones descritas a lo largo del informe. Esto tiene su importancia debido a que va a permitir establecer la secuencia adecuada de acciones y comprobar, entre uno y otro, el cumplimiento o desviacin de previsiones.
Dentro del ncleo central del informe, o nudo, evidentemente se van a
detallar los hitos cumplimentados, las acciones realizadas en la ventana de
tiempo indicada, con los problemas encontrados y las soluciones adoptadas
en su caso, riesgos detectados, acciones mitigadoras, etc., as como la previsin en cada uno de estos aspectos para el perodo siguiente.
El CMI puede incluirse como un captulo ms en cuanto que permite ver
la situacin y/o evolucin en un momento determinado, pudiendo ser de
gran valor en determinadas etapas de la vida del proyecto. Otro captulo
interesante o conveniente puede ser el tema econmico, evolucin de compras, costes, etc, siempre en funcin de los intereses del proyecto. En cada
uno de estos apartados, la parte de previsin puede tener poca precisin,
por lo que la informacin futura aportada puede presentar menor nivel de
218
detalle, y hay que establecer claramente que se trata de estimaciones. Pueden usarse tablas o grficos? S, cualquier formato de informacin que aclare la situacin, que facilite la comprensin, y, en suma, permita obtener una
imagen clara del estado y de la evolucin de nuestro proyecto. El uso de
estos recursos estar orientado a facilitar la comprensin del informe, pero
los datos debern estar contrastados y verificados por los autores, como se
dijo anteriormente. Finalmente, en las conclusiones, el equipo de proyecto
plasmar sus impresiones, conclusiones y recomendaciones para la toma de
decisiones si es que hay alguna.
El informe de seguimiento debe realizarse con una determinada periodicidad, normalmente acordada entre ambas partes, pero sin perder de
vista que es una actividad adicional que requiere una cierta dedicacin
para la recopilacin y verificacin de los datos, as como para su realizacin, revisin y emisin, de modo que una periodicidad baja, por ejemplo,
mensualmente, acorta el perodo de informacin y proporciona poca informacin nueva, sin embargo, el esfuerzo de la recoleccin, verificacin y
preparacin de los datos, as como la propia preparacin del informe y su
emisin formal, suponen un porcentaje de tiempo relativamente apreciable
dentro de la ventana de tiempo que abarca el informe que se distraera de
las labores diarias. Por el contrario, si la periodicidad se sube a 6 meses, el
volumen de informacin puede ser considerablemente mayor, mientras que
el esfuerzo de preparacin no se incrementa en la misma proporcin, sin
embargo, en este caso, la reaccin ante situaciones no deseadas sera muy
lenta al identificarse tardamente.
En consecuencia, la periodicidad de entrega de este tipo de informe es
algo que se recomienda acordar al inicio del desarrollo del proyecto con el
cliente dependiendo dicha periodicidad, adems de los requisitos establecidos, de la envergadura y duracin del proyecto, de modo que sea til y
no entorpezca la labor de desarrollo y gestin del proyecto y que resulte
en una relacin esfuerzo-resultado aceptable para ambas partes. Si se trata
de perodos cortos, se tiene un exceso de carga de trabajo en la preparacin del informe con respecto al perodo de cobertura, con poco aporte
de informacin nueva, permitiendo una reaccin rpida ante situaciones
o eventos no deseados o la aparicin de nuevos riesgos, mientras que un
perodo largo, requiere proporcionalmente menos esfuerzo de preparacin
con respecto al perodo de cobertura, aportando gran cantidad de informacin nueva, pero la reaccin ante un evento no deseado sera ms lenta
al detectarse ms tardamente. Evidentemente un evento de consecuencias
graves o crticas para el proyecto debe ser tratado tan pronto se detecte, sin
esperar a la emisin del siguiente informe de seguimiento.
Dependiendo de la envergadura del proyecto, es fcil deducir que el volumen de este informe de seguimiento, mxime si los perodos de entrega
219
son largos, puede adquirir tamaos elevados, lo cual, a ciertos niveles de

decisin puede generar una reaccin de rechazo y no ser ledos. Esto no
quiere decir que para el personal operativo no sean vlidos y perfectamente
tiles, sino que a niveles de alta direccin, pueden ser excesivos, siendo
altamente recomendable la preparacin de un Resumen Ejecutivo, este s,
como mximo de unas 2-3 pginas, en el cual se planteen los puntos clave
del informe, hechos relevantes, para que la alta direccin pueda valorar el
desarrollo en un momento dado y pueda adoptar las decisiones que juzgue
necesarias. Este Resumen Ejecutivo no sustituye al informe completo, sino
que actuara como el prlogo de la obra literaria que se cit anteriormente,
dando una visin de conjunto del mismo, facilitando su entendimiento, y
orientando al receptor a la lectura de aquellos apartados de detalle que
realmente sean necesarios o de inters para l.
7. REFERENCIAS
GOLDRATT, E. M., La Meta, Ediciones Daz de Santos, 2005.
KAPLAN y NORTON., Cuadro de Mando Integral, Ediciones Gestin 2000, S.A. Barcelona (Edicin 2), 2000.
220
CAPTULO 9
TCNICAS DE NEGOCIACIN
Vernica Blanco-Traba Fernndez-Caizares
1. INTRODUCCIN
La negociacin y la resolucin de conflictos forman parte de nuestra
vida, tanto a nivel personal como profesional, integrando distintos aspectos y saberes. Desde la tica a la relacin con proveedores y clientes, la
definicin de objetivos, gestin de equipos y trabajos, liderazgo y comunicacin, aspectos culturales y contratos y acuerdos, entre otros. Todos ellos
en el mbito profesional y, en concreto, en la gestin integral de proyectos, pero que trasladados al mbito personal seguiran siendo vlidos. La
negociacin tiene una dimensin intrnseca y una dimensin extrnseca.
La negociacin entraa siempre la existencia de dos o ms personas o
partes con sus propios intereses, que buscan cada uno un beneficio y que
si no llegan a un acuerdo, ninguno obtendr lo que desea. El objetivo de
la negociacin es el acuerdo entre las partes, y es la interaccin el elemento primordial.
Hoy en da es fcil acceder, a travs de las distintas herramientas posibles, a las teoras clsicas de las tcnicas y estilos de negociacin y de resolucin de conflictos, a la descripcin de los distintos perfiles del negociador
y, por tanto, las distintas situaciones con las que nos podemos encontrar,
y todo ello bajo la ptica de la razn. Difcilmente se encuentra el enfoque
emocional, a pesar de que nuestras emociones y deseos pueden dificultar
o facilitar las comunicaciones entre las partes que interactan. Si, como se
ha mencionado, se tiene la capacidad de gestionar y filtrar las emociones,
221
y la negociacin tiene un papel integrador, el objetivo de este captulo es

darle su lugar prctico; es decir, conseguir que los distintos y numerosos
procesos de negociacin que implica la gestin integral de un proyecto no
sean procesos aislados o independientes, sino que sirvan tambin como
herramienta integradora de la gestin integral del proyecto, siendo la base
para establecer una relacin a largo plazo.
2. NEGOCIACIN
Existen numerosas y variadas definiciones pero, bsicamente, se puede
decir que la negociacin es la bsqueda del encuentro de los intereses
de las partes hasta conseguir su fusin en un inters superior y comn:
el acuerdo entre las mismas, del que han de derivarse los beneficios que
stas desean. Dentro de la visin global de la gestin integral de proyectos
se abordar la negociacin comenzando por la definicin del mtodo de
negociacin y sus competencias bsicas, para continuar con la negociacin
y finalizar con la mencin de los aspectos ticos, el liderazgo y la cuestin
de gnero.
2.1. Mtodo de negociacin
Los mtodos de negociacin [Costa et al., 2004] son los diferentes modos
de obrar o proceder para alcanzar los objetivos que la negociacin persigue. El mtodo de negociacin, como se ve en la figura 9.1, inspirada en
[Costa et al., 2004] engloba siempre dos aspectos complementarios, y que
son, el estilo y la tcnica.
t Estilo de negociacin. La actitud general o filosofa con que se aborda
el proceso negociador. Tambin llamado orientacin. Son los componentes ms subjetivos del mtodo.
t Tcnica de negociacin. El procedimiento con que se desarrollan las
distintas fases del proceso negociador, desde la preparacin al cierre.
Se corresponde con aquellos elementos que se pueden aprender de
modo sistemtico.
222
Figura 9.1. Mtodo de negociacin.
La clave consiste en abordar la negociacin como el equilibrio adecuado

entre los estilos de negociacin, situados en el plano de las actitudes y las
tcnicas que se aplican. El estilo u orientacin negociadora es el que hace
referencia a la actitud con la que el negociador se sita respecto al proceso
y respecto a la interaccin con la otra parte negociadora. Existen varios
estilos de negociacin.
a) Negociacin distributiva o competitiva. Es el estilo tradicional en el
que cada una de las partes adopta una determinada posicin negociadora,
aboga a su favor, hace concesiones a la otra parte y, en base a las mismas,
redefine nuevamente su posicin. Es un ciclo interactivo que se repite sucesivamente hasta poder alcanzar un acuerdo. Este estilo representa las
intenciones de las partes, en funcin de la proporcin de satisfaccin, con
respecto al asunto. Es una dimensin de dar o tomar, o de suma cero. El
modelo bsico es el yo gano - tu pierdes, pudiendo deteriorar las relaciones.
b) Negociacin integradora o cooperativa. El objetivo no es ganar, sino
alcanzar resultados satisfactorios para las partes. Es una alternativa a la negociacin posicional (distributiva o competitiva), que recomienda negociar
en base a los intereses. Representa las intenciones de las partes respecto
a la satisfaccin total de los asuntos de todas las partes. No suma cero, al
ganar todas las partes, fortaleciendo las relaciones pues el modelo bsico es
yo gano - tu ganas. Se puede incluir la solucin conjunta de problemas
[Ury, 1993] como una variante.
223
En la siguiente tabla 9.1, inspirada en [Domnguez & Garca, 2003] se

resumen y se contraponen los distintos elementos, que se desarrollaran ms
adelante, y que caracterizan ambos estilos de negociacin.
Contraste entre los elementos de la negociacin

Elementos de la negociacin
Elementos de la negociacin distributiva
integradora
Fomenta los aspectos comunes
Focaliza las diferencias
Satisface necesidades e intereses
Mantiene las posiciones
Convergencia de las necesidades de
nfasis en los objetivos de cada uno
todos
Uso estratgico de la informacin
Intercambio de informacin e ideas
Criterios partidarios para evaluar los
Criterios objetivos para evaluar los
resultados
resultados
Tabla 9.1. Contraste entre los elementos de la negociacin
Una alternativa a los dos estilos anteriores sera la negociacin mixta:

distributiva e integradora, en la que los distintos puntos a negociar se tratan tanto desde una perspectiva distributiva como integradora. Es aquella
que define las negociaciones que, comenzando por un estilo distributivo,
acaban con uno integrador y viceversa. Una vez definidos los estilos es necesario establecer los criterios para la eleccin de un estilo u otro. A mayor
complejidad, frecuencia de relaciones, igualdad de poder y necesidad de
llegar a acuerdos, se optar por un estilo integrador, mientras que el estilo
distributivo quedara definido por aquellas negociaciones sencillas, rpidas,
poco frecuentes.
Si a lo largo de la historia, el ms fuerte ha ganado y las negociaciones
se abordaban con un enfoque yo gano - tu pierdes. Hoy en da se habla
de negociaciones ganar - ganar, mediante las cuales se busca que todas
las partes ganen equitativamente. No obstante, este enfoque reciente puede
incluso estar anticuado, puesto que cada vez ms se valora como resultado
de una buena negociacin la obtencin y consolidacin de las relaciones,
el establecer relaciones a largo plazo.
La tcnica de negociacin consta de tres fases claramente diferenciadas;
la preparacin o prembulo, correspondera a la apertura; los elementos de
la negociacin, su desarrollo y el eplogo o acuerdo. En la siguiente figura
9.2, se reflejan de forma muy simple, pero muy grfica, las fases del proceso, que seguidamente se analizarn.
224
Figura 9.2. Fases del proceso de negociacin.
a) Preparacin o prembulo. El proceso de negociacin comienza mucho antes de que las partes se encuentren. Todo entra en juego:
educacin, experiencia, el conocimiento de uno mismo, la actitud
ante la vida, qu se pretende obtener de la negociacin y cmo reaccionamos, tanto emocional como racionalmente, ante los retos. En
definitiva, estamos en constante preparacin, que ser ms exhaustiva si consideramos de una forma integrada y estructurada todos estos
elementos, como se describir en el siguiente apartado. En la siguiente tabla 9.2, inspirada en [Nieremberg & Ross, 1984], se detallan las
distintas partes a considerar en la preparacin.
Negociando con uno mismo: Conocindose a uno mismo se
podr evaluar de antemano la actitud ante la negociacin y estar
preparado para afrontar la responsabilidad del resultado.
Mapa negociador: Como se puede ver en la figura 9.3, cada vez
que se inicie una negociacin se repasar el mapa doblemente;
una, desde el punto de vista propio, y otra, desde el supuesto
punto de vista de la parte contraria.
PREPARACIN
o
PREMBULO
Caminar con los zapatos del otro: Se deben conocer desde un

principio los temas que de verdad interesan a la otra parte, sin
perder el control de los propios, pero con voluntad de cambio si
el inters mutuo lo garantiza.
La agenda negociadora: Engloba los objetivos, intereses, asuntos a
negociar, mrgenes, estrategia, etc., que deben plasmarse (aun de
un modo esquemtico) en la agenda. No confundir con la agenda
de la reunin, que slo designa los elementos formales: asunto,
calendario, etc.
Tabla 9.2. Partes de la preparacin.
El Mapa Negociador [Nieremberg & Ross, 1984] se elabora con la

intencin de plasmar las directrices para una buena preparacin y
ayudar a centrar los elementos que conforman una negociacin.
225
Figura 9.3. Circularidad del mapa negociador.
226
Definir los objetivos puede parecer una tarea sencilla si se sabe lo que se quiere obtener de la negociacin, pero
muy posiblemente ello est limitando la posibilidad de conseguir otras posibles mejoras y cerrando la puerta a la
negociacin en caso de no obtenerlos.
Como complemento a los objetivos, se definen los conceptos de: alternativa que permite realizar otra negociacin;
la opcin o el posible acuerdo a aceptar y la propuesta como una oferta especfica orientada a la obtencin del
acuerdo.
Es necesario obtener y disponer de toda la informacin que permita defender la propia posicin, pero tambin
lo es el conocer todo lo ms posible sobre la parte contraria. Un segundo paso ser analizar lo que la otra parte
considera de inters, determinando lo que son hechos y lo que son supuestos en ambas partes.
OBJETIVOS
HECHOS Y
SUPUESTOS
227
El clima es cambiante y requiere una atencin constante, ya que es el resultado de las distintas personalidades,
estilos, emociones, sentimientos y actitudes de las personas involucradas. Es muy importante establecer un clima
apropiado desde el principio.
La estrategia es la definicin de los medios para lograr los objetivos, el plan general, y la tctica, acciones a corto
plazo, la forma de utilizarlos para lograr posiciones de ventaja, frente a los argumentos de la parte contraria. Este
elemento se desarrollar a continuacin.
CLIMA
ESTRATEGIAS
Y TCTICAS
Tabla 9.3. Elementos de la negociacin.
Una vez determinado que la negociacin es necesaria, es primordial determinar las necesidades, tanto las propias
como de la parte contraria. Es importante saber que existen necesidades variadas: econmicas, afectivas, de
recursos, sociales, etc. Y que no tiene por qu coincidir con las de la otra parte. No se debe confundir el inters
en la negociacin con la necesidad de la negociacin.
NECESIDADES
E INTERS
DISCREPANCIA
Si se consigue que la otra parte se identifique con nuestra posicin se estar en va de obtener un acuerdo.
Y POSICIN
Puede parecer que el asunto o materia a negociar est claro y que ambas partes estn de acuerdo. Es crucial no
asumir o dar por hecho que lo est y asegurarse que se comparte el objeto de la negociacin.
ASUNTO
ELEMENTOS DE LA NEGOCIACIN
El mapa facilita de manera visual todo el proceso de una preparacin

eficiente, desde el principio al fin, permitiendo el anlisis desde los
dos puntos de vista de la temtica o asunto, clarificando objetivos,
diferenciando hechos y supuestos, aislando posibles discrepancias,
identificando posiciones a adoptar, determinando las necesidades,
y todo ello dentro de un clima favorable que permita planificar de
forma flexible las distintas estrategias. En la figura 9.3 se refleja la
circularidad del proceso del mapa negociador.
b) Elementos de la negociacin. Los elementos que componen el proceso de negociacin y, por tanto, el mapa negociador se detallan en
la tabla 9.3, inspirada en [Nieremberg & Ross, 1984].
Dentro del uso de las estrategias y tcticas, puede haber un dilema, ya
que algunas de ellas son controvertidas y, dependiendo de su utilizacin,
pueden ser positivas o destructivas. El uso de unas u otras depender de la
actitud y tica personal y, sin duda, de la legalidad del plan.
El abuso de distintas tcticas puede empaar el proceso de negociacin
y convertirlo en menos creativo y flexible, dentro de esta tipologa, y ms
asociadas a las negociaciones distributivas, se encuentran las tcticas duras
(hardball tactics) que son de dudoso resultado y que generalmente daan
al que las utiliza. Las estrategias y tcticas simplemente son herramientas
a utilizar conjuntamente con el resto de los elementos del plan y pueden
utilizarse indistintamente. Es decir, una estrategia puede ser una tctica y
viceversa. Por existir una gran variedad con una extensa bibliografa, slo
se citarn alguna de ellas, en base a los tres grandes tipos.
t Preparacin. Crean el clima adecuado para que la otra parte acepte
las condiciones para llegar al acuerdo que se pretende obtener. Destacan entre otras:
Salami: Presentar un aspecto negativo entre dos positivos, para
minimizar el impacto.
Seuelo: Atraer o despistar al oponente con argumentos falsos.
Es una tctica dura.
Gran Muralla: Desgastar a la otra parte siendo inflexible y no
cediendo.
t Argumentacin. Se utilizan para negociar concesiones. Destacan entre otras:
El bueno y el malo: Tctica dura demasiado transparente y conocida.
228
Asalto Directo: Tctica dura diseada para presionar e impresionar con argumentos poderosos y contrastados que provocan
intimidacin.
La mordida: Tctica dura con obtencin de concesiones proporcionalmente pequeas, que se exigen para cerrar el trato, pudiendo dar la impresin de mala fe.
t Desviacin. Sirven para evitar un tema que no interesa tratar en ese
momento. Destacan entre otras:
El banco de niebla: No entrar en afirmar o negar un planteamiento duro.
El disco rayado: Insistir en la expresin de los propios objetivos.
El receso: Solicitar un aplazamiento corto de tiempo para una
reconsideracin.
c) El eplogo o acuerdo. El acuerdo, objetivo ltimo (y a veces no
nico) de la negociacin, ha de ser especfico, determinado y claro.
Una vez finalizada la negociacin, las partes en su caso debern determinar el contenido del acuerdo, reflejndolo en un texto escrito. La
redaccin ha de ser lo suficientemente clara para evitar el problema
ms frecuente en el cumplimiento de un acuerdo: las posteriores discrepancias en la interpretacin de su contenido. Mayor cuidado an
exige la redaccin en dos o ms idiomas.
A modo de conclusin convendra resaltar que la mayora de las negociaciones ocurren sobre la marcha, sin posibilidad de realizar una
preparacin exhaustiva. Para ello es de gran utilidad recordar el mapa
negociador, en su forma abreviada, con objeto de poder reaccionar rpidamente, tal y como muestra la figura 9.4, inspirada en [Nieremberg &
Ross, 1984].
Figura 9.4. Negociacin abreviada.
229
2.2. Competencias bsicas de la negociacin

Las competencias bsicas en la negociacin son tres: comunicacin, manejo emocional adecuado y tratamiento de los roles difciles del proceso de
comunicacin.
a) Comunicacin. Por comunicacin se entiende el intercambio de informacin y transmisin de significados, que tienen como condicin
necesaria la retroalimentacin. La negociacin se basa en el intercambio comunicativo en el que intervienen multitud de factores que
tratan de hacer llegar el mensaje que se desea, para conseguir los
efectos que se quieren.
Para estudiar la negociacin como proceso de comunicacin y los
distintos recursos de cada interlocutor, se examinarn en la figura 9.5,
inspirada en [Costa et al., 2004], los distintos elementos que combinados entre s, son responsables del efecto de persuasin.
Figura 9.5. Proceso de comunicacin.
t Preguntar y escuchar: hay que hacer un uso inteligente de las

preguntas, herramientas bsicas para obtener informacin, para
despus observar y escuchar activamente todo lo que el interlocutor manifieste en su respuesta.
t Empata: es la capacidad para conocer a la otra persona con una
certera percepcin de sus estados emocionales con una buena
disposicin para su percepcin. Para ello es necesario ponerse
en el lugar del otro, combinar un adecuado manejo emocional y,
al mismo tiempo, transmitir empata.
t Responder: en las negociaciones el lenguaje opera en dos niveles:
un nivel lgico y otro pragmtico. No slo importa lo que se dice
230
y cmo se dice, lenguaje verbal y no verbal, sino tambin qu informacin adicional, velada o encubierta, es deseada, transmitida
y percibida en recepcin.
t Persuasin: es la capacidad de influir en los dems; convencer y hacerlo por medio de nuestros fundamentos y razones; no de nuestra
fuerza, porque eso es imponer. En esto radica la esencia de la negociacin. La mejor forma de persuadir es el auto-convencimiento.
b) Manejo emocional adecuado. Casi cualquier negociacin implica relacionarse con las personas. Esto quiere decir que hay emociones implicadas: las propias y las de los otros. Por ello, una preparacin cuidadosa de las emociones puede mejorar la eficacia de las negociaciones.
c) Tratamiento de los roles difciles. El rol es el papel que desempea
una persona en la negociacin y nos indica su actitud, funcin, su
poder y su capacidad de decisin. Es importante determinar el rol de
la otra parte para saber si estamos negociando con la persona adecuada. Tambin lo es saber manejar o afrontar los denominados roles
difciles sin que por ello frustremos la negociacin.
2.3. Negociacin y audiencias
La negociacin es un proceso complejo en el que se ven implicados diferentes actores en distintos niveles y estructuras, tanto en el mbito externo
con clientes y proveedores como en el intracorporativo, pasando de dos
negociadores a un equipo negociador.
a) Audiencias. Segn [Lewicki y Litterer, 1985] el entorno social de la
negociacin incluye todas las partes presentes, aquellas afectadas por
los resultados de la negociacin, aunque de hecho no hayan estado
negociando, y los observadores de la negociacin. Es primordial que
el negociador conozca cuntas personas y grupos pueden estar implicados y sus posibles posiciones: los a favor (audiencias favorables);
los contrarios (audiencias adversas); y la proporcin de indiferentes
o sin una posicin definida (audiencias neutrales).
b) Situaciones especficas. Cada situacin especfica representa una
oportunidad potencial que hay que saber identificar y aprovechar.
Algunas situaciones podran ser de cierta complejidad.
t Negociaciones en grupo: las negociaciones en grupo poseen una
mayor complejidad, derivada, entre otras, de la diversidad de opiniones, intereses, necesidades, posiciones y formacin.
231
t Terceras partes: Llas terceras partes pueden desempear roles formales: conciliador, mediador, rbitro, o informales: intermediario
y enviado especial.
t Alianzas y coaliciones: en una coalicin, varios actores o individuos se unen unos en contra de otro. En una alianza, varios actores o individuos se unen para alcanzar ms fcilmente un objetivo
comn.
2.4. Liderazgo, aspectos ticos y cuestin de gnero
El liderazgo y los aspectos ticos son factores diferenciales dentro de
las negociaciones, mientras que la cuestin de gnero es un tema de actualidad.
a) Liderazgo. Tradicionalmente el liderazgo se ha explicado como el
equilibrio entre la preocupacin por el logro de objetivos y la preocupacin por el equipo de trabajo que tena que lograrlos.
b) Aspectos ticos. La tica aporta a la empresa los principios generales
de actuacin, y su lugar en la direccin de empresas, puede concretarse tres aspectos, la definicin de la naturaleza y finalidad de
la empresa, la propuesta de principios de actuacin y el proceso de
toma de decisiones.
c) Cuestin de gnero. Los estudios tradicionales se han orientado hacia
la diferencia de sexo como categora biolgica, mientras que, desde
la dcada de los ochenta, se hace nfasis en los roles sexuales y, por
tanto, en la diferenciacin de gnero. En 1994, Carol Watson [Watson,
1994] lanz la hiptesis, posteriormente confirmada por los resultados,
de que lo significativo no es el sexo, sino la diferencia de poder.
En los aos 1960 y 1970 se consideraba que la mujer era un negociador menos efectivo, poniendo en duda las habilidades femeninas, principalmente en el campo del liderazgo. Considerando que el liderazgo es
muy similar a la negociacin en cuanto a la capacidad de influenciar en
otros, los resultados obtenidos en los numerosos estudios sobre Investigacin y Liderazgo relacionados con la diferencia de gnero son perfectamente aplicables. En el caso de la negociacin nos llevara a asumir
que los negociadores con mucho poder compiten y los negociadores
con poco poder cooperan, actitud tradicionalmente asociada y reservada
a las mujeres.
La conclusin es que el poder sera un factor ms fiable que la diferencia
de gnero a la hora de evaluar el comportamiento y resultados de una negociacin, ya que el impacto de este ltimo es ms difcil de demostrar.
232
3. RESOLUCIN DE CONFLICTOS
Interpretando el conjunto de definiciones de conflicto y siempre dentro
del mbito de la gestin integral de proyectos se puede decir que un conflicto es un problema, una materia de discusin y/o una situacin de difcil
salida. Una posible sntesis de una situacin conflictiva sera aquella en la
que los intereses de dos personas o grupos parecen ser incompatibles. Una
situacin de enfrentamiento provocada por una contraposicin de intereses, real o aparente, que puede producir verdadera angustia cuando no se
vislumbra una salida satisfactoria.
Desde esta ptica, el conflicto generalmente es evaluado como negativo y, por tanto, luchamos para evitarlo. Sin embargo, un conflicto puede
conducir a grandes cambios y mejoras; por tanto, considerando el enfoque
inicial, es imprescindible estudiar y desarrollar destrezas y capacidades individuales para abordar y manejar de una manera positiva las situaciones
conflictivas.
Se abordar la resolucin de conflictos a travs del modelo general de
conflicto, las estrategias y tcnicas, y formas de resolucin, concluyendo
con los medios alternativos de resolucin de conflictos. Hay tres tipos bsicos de conflictos; enfrentamiento o ideas opuestas que confluyen ante un
mismo problema o solucin, la interrupcin del proceso de colaboracin de
distintas partes y por ltimo la dificultad en la consecucin de los objetivos
por alguna persona o circunstancia. En la figura 9.6 se describen los tres
tipos distintos de conflictos.
Figura 9.6. Tipos de conflicto.
233
3.1. Modelo de conflicto

Se analizar el Modelo General del Conflicto de Kenneth Thomas [Thomas, 1992] por ser el que trata de integrar el mayor nmero de elementos
con distintas perspectivas, lo que le confiere el grado de generalidad, pero
carece de cierto grado de integracin. Otro posible modelo de conflicto sera el Modelo de Escalada/des-Escalada del Conflicto, que enfoca el
conflicto desde una perspectiva dinmica, lo que le confiere una menor
generalidad.
El objetivo principal del modelo es identificar los elementos principales
del conflicto y sus implicaciones en el entorno. El conflicto es un proceso
o secuencia de eventos que se traducen en episodios, unidad de referencia, o fases conflictivas entre las partes, como se expresa en la figura 9.7,
inspirada en [Thomas, 1992].
t Estructura y proceso del conflicto. El proceso se desarrolla dentro
de un entorno o contexto, quedando conformado por dichas condiciones. stas pueden ser de tipo organizativo o presiones de otros
departamentos.
t El proceso, da lugar a un resultado de conflicto que incluira, como
consecuencia, el logro de las tareas, dentro del contexto.
La intervencin de terceras partes, mediacin o arbitraje entre otros,
pueden modificar las condiciones que crean los conflictos o que mejoren
su percepcin y manejo por las partes.
Figura 9.7. Modelo general de conflicto.
234
Un conflicto, independientemente de si la escala es personal o internacional, est vivo, se mueve; presenta lo que se llama una dinmica propia,
teniendo que controlar sus diversas fases y cmo se gestiona.
a) Fases. Aunque muy similares entre ellas, existen distintas clasificaciones de las fases del conflicto, de las cuales se expondr el
Resumen de las Fases del Conflicto y que se detalla en la tabla 9.4,
inspirada en [Domnguez & Garca, URJ].
Resumen de las fases de conflicto
Fases pre conflictuales
Desencadenante
Fases pos
conflictuales
Fases conflictuales
Factores individuales y
grupales
Situacin
antecedente
Conflicto
latente
Factores de contexto social

Factores de la tradicin del
conflicto
Intensificacin o escalada
Factores estructurales
Estancamiento
Conceptualizacin
Desintensificacin o
desescalada
Resolucin, control
y consecuencias
Determinacin de la
conducta
Contexto de la conducta
interactiva
Tabla 9.4. Resumen de las fases de conflicto.
b) Gestin. El conflicto se puede gestionar bien a nivel general, mediante el acercamiento preventivo, o bien a nivel especfico, en la
disolucin y resolucin del conflicto. El acercamiento preventivo
consiste en intervenir para modificar la concepcin del conflicto
como algo negativo e introducir concepciones constructivas. En la
resolucin se atacara directamente al ncleo del mismo, mientras
que en la disolucin se extrae el esquema del conflicto del foco de
atencin.
3.2. Estrategias, tcnicas y formas de resolucin de conflictos
El conflicto puede tener una concepcin negativa o positiva en funcin
de su percepcin, lo que a su vez conllevara el desarrollo de las respectivas
estrategias de eliminacin de conflictos y de gestin positiva.
235
Las estrategias de eliminacin son las que buscan terminar con el

conflicto rpidamente a travs de medidas impuestas que restan las posibilidades de accin de las personas y de los grupos. Por el contrario, las
de gestin positiva analizan el contexto en el que ha surgido el conflicto
con el fin de buscar un acuerdo, involucrando de forma creativa a las
partes implicadas.
Sin el marco anterior, las tcnicas de resolucin de conflictos quedaran
en simples estrategias que dependeran de la moralidad de la meta propuesta por las partes en conflicto, como muy bien defini Kant y sus tres
imperativos hipotticos; consejos de una razn prudencial que obligan nicamente a las personas que quieren alcanzar un fin determinado [Cortina,
N257]. Dos siglos despus esta distincin sigue vigente.
t Consejos de habilidad. Es importante definir bien la meta y recordar que
no prima el propio beneficio, sino la ganancia a medio y largo plazo.
t Consejos de prudencia. Se pueden tomar los conflictos como juegos
de suma cero, en los que lo que uno gana, lo pierde el otro; o, como
no suma cero, en los que todos pueden ganar.
t Mandatos de moralidad. Se trata de encontrar soluciones justas para
los implicados en los conflictos, urgiendo aprender a resolverlos haciendo justicia.
En las formas de resolucin de conflictos, El Instrumento Thomas-Kilmann de Modos de Conflicto [Thomas, 1981] evala la conducta del individuo en situaciones de conflicto, en las que los intereses de dos personas
o partes parecen ser incompatibles. En estas situaciones podemos definir
la conducta de la persona o la parte segn las dos dimensiones bsicas de
asertividad y cooperacin.
t Asertividad. La medida en la que la persona intenta satisfacer sus propios intereses. Trmino utilizado en psicologa para definir el comportamiento afirmativo.
t Cooperacin. La medida en que la persona intenta satisfacer los intereses de la otra, es sinnimo de colaborar.
Estas dos dimensiones se pueden utilizar para definir el estilo de manejo
o las cinco formas de abordar o de resolucin de conflictos, que se reflejan
en la figura 9.8, inspirada en [Thomas, 1981].
t Competidor. Ser asertivo y no cooperador. Cuando la persona trata
de satisfacer sus propios intereses a expensas de la otra persona, con
el estilo yo gano - tu pierdes. Est orientado al poder, en el que la
persona usa cualquier medio que le parezca apropiado para que su
postura gane.
236
t Complaciente. No ser asertivo y ser cooperador (lo opuesto a competir). Al complacer, la persona se olvida de sus propios intereses
para satisfacer los de la otra persona; tu ganas, yo pierdo. Existe un
elemento de sacrificio en este mtodo. El complacer puede tomar la
forma de una generosidad desinteresada o caritativa.
t Eludir. No ser asertivo y no cooperador. La persona no satisface de
inmediato sus propios intereses ni tampoco los de la otra. No controla ni confronta la situacin, la evita. La evasin puede ser una forma
diplomtica de posponer un problema o retirarse de una situacin
amenazadora.
t Colaborador. Significa ser tanto asertivo como cooperador. Lo opuesto a eludir. Colaborar implica un intento de trabajar con la otra persona para encontrar alguna solucin que satisfaga plenamente los
intereses de ambos. Significa profundizar en un problema con el fin
de identificar los intereses subyacentes y encontrar una alternativa
que satisfaga a ambos; yo gano - tu ganas.
t Compromiso. Significa un punto intermedio entre asertividad y cooperacin. El objetivo es encontrar una solucin adecuada y mutuamente aceptable que satisfaga parcialmente a las partes. Puede
significar dividir las diferencias, intercambiar concesiones o buscar
una rpida postura intermedia.
Figura 9.8. Formas de resolucin de conflicto.
237
3.3. Medios alternativos de resolucin de conflictos

Los conflictos pueden ser individuales, cuando es la propia persona
quien se debate entre dos opciones, y, en segundo lugar, puede ser interpersonal e incluso intergrupal, cuando son grupos enteros. Es decir,
donde hay personas hay conflicto y la negociacin es slo una manera
de solucionarlos. Los medios alternativos por los cuales se pretende dar
solucin a intereses contrapuestos, sin recurrir al litigio, se mencionan en
la tabla 9.5.
No existe una tercera persona, el conicto es resuelto por
NEGOCIACIN las partes. En realidad, no se fuerza a nadie a llegar a un
acuerdo.
MEDIACIN
Existe una tercera parte, el mediador, que induce a las partes

a resolver el conicto, pero sin proponer soluciones.
CONCILIACIN
Medio extrajudicial en el que la tercera parte tiene una

presencia ms fuerte, ya que propone soluciones.
ARBITRAJE
Medio extrajudicial en el que el rbitro emite un laudo que

es vinculante para las partes.
Tabla 9.5. Medios alternativos de resolucin de conflictos.
Una vez definidos los roles, es interesante resaltar las principales diferencias entre ellos.
t Conciliacin y mediacin. Ambas situaciones connotan la presencia de un tercero, que interviene en el conflicto con distintos roles.
Mientras que el conciliador propone soluciones no obligatorias, el
mediador no hace proposiciones, slo facilita la comunicacin entre
las partes, evitando una mayor conflictividad.
t Conciliacin y arbitraje. La principal diferencia entre el conciliador y el rbitro es que este ltimo resuelve; es decir, ni propone
ni sugiere.
Se han mencionado los medios alternativos, dejando fuera la posibilidad
de evitar dar respuesta al conflicto, como solucin ms informal, y el litigio
como solucin ms reglada e impositiva, en la que un juez, mediante la
aplicacin de una ley general, dicta una sentencia en la que uno gana y el
otro pierde. Existen tambin soluciones al margen de los cauces normalizados y relacionadas con el uso de la violencia, aunque de signo contrario:
238
beligerancia ejercida mediante la violencia y la beligerancia pacfica o no

violencia. En cualquier caso, ambas estaran fuera de la ley.
4. REFERENCIAS
CORTINA, A., Resolver conflictos, hacer justicia, en Cuadernos de Pedagoga, N
257, abril.
COSTA, M., GALEOTE, M. P. y SEGURA, M., Negociar para Con-vencer, Madrid, 2004.
DOMNGUEZ, R. R. & GARCA, S., Estructura y procesos de la negociacin: estrategias, tcticas y procesos psicosociales. Working papers 2002/52, Madrid, Universidad Rey Juan Carlos, 2002.
DOMNGUEZ, R. R. & GARCA, S., Introduccin a la Teora del Conflicto en las Organizaciones, Madrid, Universidad Rey Juan Carlos.
LEWICKI, R. J. y LITTERER, J. A., Negotiation, 1985.
NIERENBERG, J. & ROSS, S., Women and the Art of Negotiating, United States of America, 1985.
THOMAS, K. W., The Thomas-Kilmann Conflict Mode Instrument, 1981.
THOMAS, K. W., Conflict and negotiation processes in organizations. DUNNETE, H.
D. & HOUG, L. M. (eds.), Handbook of industrial and organizational Psychology, Palo Alto, 1992.
URY, W., De la negociacin al acuerdo. Claves para superar cualquier negociacin,
Bogot, Colombia, 1993.
WATSON, C., Gender versus power as a predictor of negotiating behaviour and
outcomes, Negotiating Journal, 1994.
239
CAPTULO 10
DIRECCIN Y GESTIN DE EQUIPOS DE TRABAJO

scar Garca Martnez
1. INTRODUCCIN
Una de las partes si no ms importantes s ms crticas de un proyecto es
la direccin y gestin de un equipo de trabajo. Un equipo de trabajo es un
recurso humano asignado al proyecto. En el captulo 2 se identifican todas
las tareas necesarias del proyecto y en el captulo 3 se definen en detalle, se
estiman los recursos necesarios, y se asignan a personas para su realizacin.
Si eso se ha hecho bien y las tareas estn bien definidas, cabra pensar que
la gestin de las personas asignadas puede ser anloga al resto de los recursos. Pero no es as. La gran diferencia entre gestionar este recurso humano
y cualquiera otro de los recursos necesarios (econmicos, materiales, etc.)
es que el recurso humano tiene dos premisas nicas, que aunque parecen
obvias se tienden a olvidar:
t &MTFSIVNBOPUJFOFFNPDJPOFTRVFJOGMVZFOFOFMEFTBSSPMMPEFTV
actividad racional y por tanto en su desempeo profesional, independientemente de su coeficiente intelectual o de su aptitud.
t &MTFSIVNBOPCVTDBPOFDFTJUBDPOTFHVJSBMHPFOFMUSBCBKP&TEFcir los recursos humanos asignados a un equipo utilizan el proyecto
como un medio para conseguir su propio fin. Este fin no tiene por
qu ser el mismo para todos. En unos casos el fin ser econmico, en
otros ser reconocimiento, prestigio, tiempo, o lo que comnmente
se llama hacer lo que nos gusta o de manera ms cientfica la auto-
241
realizacin. Lo ms probable es que sea una combinacin de todas

ellas y seguramente no sea constante y evolucione con el tiempo.
Ser por tanto necesario, para conseguir un eficiente uso de los recursos humanos asignados al proyecto, conocer las tcnicas necesarias que
nos permitan tanto gestionar las emociones propias y de los integrantes
del equipo como alinear los intereses del proyecto con los de los recursos humanos asignados a l. Palabras como delegar, motivar, inteligencia
emocional o conceptos como el de la pirmide de Maslow cobrarn sentido a lo largo del captulo y nos aportarn un mtodo til y pragmtico de
gestionar el equipo. Todo ello envuelto en la tica que debe acompaar
cualquier relacin con personas tal y como se describi en el captulo 4
del libro.
En efecto y como en todos los rdenes de la vida es necesario estudiar las tcnicas y conocimientos de una determinada materia para poder
ponerla correctamente en prctica. Puede que una persona tenga grandes
cualidades para ser un excelente director, pero si desconoce la doctrina y
las tcnicas de la gestin de equipos y no ha sido entrenado para ponerlas
en prctica difcilmente lograr llegar a serlo. Este suele ser un error muy
frecuente cuando a profesionales que destacan en el desempeo tcnico se
les convierte en responsables de un rea o una tarea con personas a su cargo, sin haberles formado previamente. Incluso alguno de los profesionales
de gestin de proyectos y coaching (entrenamiento de equipos) han dado
nombre a este tipo de fracasos.
Un matiz importante en gestin empresarial es la diferencia entre direccin y liderazgo. Si bien semnticamente en castellano son sinnimos,
ya que la descripcin que se hace del verbo liderar en el diccionario de la
lengua espaola es dirigir a una persona, a un grupo, movimiento, y la
definicin que se hace en el mismo diccionario de lder es director, en el
rea empresarial internacional existe una diferencia entre dirigir y liderar y
por lo tanto entre director y lder. Tal vez la explicacin ms ntida la hace
John P. Kotter [Kotter 1999], titular de la ctedra de liderazgo Konosuke
Matsushita de la Harvard Business School, aclarando que cuando hablamos
de liderazgo no hablamos de nada mstico ni privilegiado sino que se trata
de gestionar el cambio y de sealar un rumbo frente a lo que comnmente
suele ser asociado a la direccin que es planificar y presupuestar. Podemos
pues concluir que por direccin entendemos una gestin rodeada de un
entorno estable y conocido, con experiencias previas y sin grandes cambios
y por liderazgo una gestin con un entorno ms inestable y desconocido
donde adems de las tcnicas necesarias en la direccin se hace necesario
ms capacidad de visin, estrategia y comunicacin. Es por eso que, en este
libro, se ha separado en dos captulos diferentes la direccin y gestin de
242
equipos de trabajo y el liderazgo y comunicacin que se trata en el captulo

siguiente.
Este captulo se centra en hacer una revisin histrica que nos permita entender y sintetizar cuales son los puntos comunes que han utilizado
distintas organizaciones a lo largo de la historia para dirigir a personas.
Se describir despus el factor humano del equipo para llegar a entender
y aprender a gestionar esas dos premisas nicas que se han mencionado
que caracterizan a los recursos humanos. Se entrar despus a describir las
habilidades y tcnicas propias de una buena gestin y direccin de quipos.
Y finalmente se relacionarn las cualidades que deben ser exigibles a un
buen director, independientemente de cul pueda ser su carcter o estilo
de direccin. Para finalizar el captulo se ha incluido un breve resumen que
sirva a la vez de sntesis y de reflexin.
2. REVISIN HISTRICA
Durante miles de aos el ser humano ha dirigido equipos de trabajo a
travs de mltiples organizaciones y formas para conseguirlo. Revisar esa
historia puede ensear las distintas maneras en las que se puede dirigir
un equipo, y lo que es an ms importante, permite encontrar tanto las
mejores prcticas como los elementos comunes que tienen las diferentes
maneras de dirigir al ser humano.
A lo largo de la historia se pueden encontrar, entre otras, y sin ser excluyentes entre s, las siguientes formas de direccin:
a) Jerrquicas: marcadas fuertemente por la estructura piramidal de la
organizacin. Las rdenes fluyen de arriba a abajo de la pirmide
y se acepta voluntariamente este liderazgo. Un ejemplo tpico es la
Iglesia.
b) Dictatoriales: se dirige a las personas imponiendo la voluntad de uno
o varios. La manera de imponerla suele ser algn tipo de opresin o
violencia, por lo que aunque no se acepta voluntariamente la direccin, sta se acata.
c) Democrticas: en este caso la direccin se ejerce mediante un consenso de las personas dirigidas, esto no implica que las personas
estn de acuerdo con la direccin tomada y las formas de tomarla,
pero se acepta a travs de un pacto previo.
d) Funcionales: esta forma de dirigir se caracteriza porque prioriza las
funciones frente a la jerarqua. En una empresa se suelen utilizar
matrices para representar el nexo de las tareas y responsables. Como
ejemplo pensemos en una empresa espaola con una sede y varias
243
delegaciones. Los diferentes directores habituales (financiero, comercial, marketing, logstica, administracin, etc.) no son los nicos responsables de sus reas ya que existe la figura del delegado o gerente
regional. Cada uno de los trabajadores involucrados en las delegaciones realizan funciones que dependen de los directores y a la vez de
los delegados. La jerarqua no est tan marcada, ya que priman las
funciones.
e) Adictivas: en este caso se dirige a las personas, consiguiendo su
mximo rendimiento, aprovechando e incluso promoviendo alguna
adiccin. Sorprendera saber que en muchas organizaciones, consciente o inconscientemente, se crea la base del xito mediante una
adiccin al trabajo. En uno de los libros [Daniel Ammann, 2009] que
habla sobre el fundador de una de las mayores multinacionales del
comercio de materias primas se puede leer lo siguiente La gente de
Rich corresponda a su jefe con un alto nivel de lealtad y voluntad de
rendimiento por encima de la media. Tenan pocas titulaciones, pero
tica empresarial de sobra. No era habitual que los empleados de una
empresa trabajaran quince o diecisis horas diarias. Me encantaba mi
trabajo me explic un operador cuando me habl de su labor en la
empresa. Llegaba a la oficina a las 7.45 de la maana. Me marchaba
de all a la 1.00 de la madrugada. Tambin trabajaba sbados y domingos. Iba a la oficina el veinticinco de diciembre y el uno de enero.
Y todos los dems hacan lo mismo. Despus, me confes que haba
tenido que someterse a un tratamiento por adiccin al trabajo.
f) Alienantes: se dirige a las personas a travs de la modificacin de la
realidad en la que viven e induciendo fuertes sentimientos de ego y
culpabilidad. No slo algunas sectas o extremismos religiosos utilizan
este tipo de direccin, recientemente algunas organizaciones de marketing multinivel americano demasiado agresivas han sido prohibidas en varios pases por utilizar estos mtodos. Estas organizaciones
tienden a aislar al individuo de su entorno inicial, crean una jerga y
unas siglas exclusivas y sustituyen gran parte del trabajo directo por
un sinfn de reuniones.
Todas ellas parecen muy diferentes, algunas se consideran ticas y otras
no, pero cul es el denominador comn y cules son las mejores prcticas?
En las siguientes organizaciones se puede ver con nitidez alguna sntesis
interesante.
Ejrcitos: es una organizacin, marcada por su jerarqua, que ha existido siempre a lo largo de la historia y en todas las partes del mundo. Se
han utilizado para conseguir territorios, riquezas y defensa y todo ello dirigiendo equipos a los que les iba la propia vida en su funcin o trabajo. La
244
historia ha consagrado a grandes militares que consiguieron grandes logros.

Alejandro Magno, Anbal, Napolen Por qu fueron los mejores y qu
denominador comn se encuentra en sus prcticas sobre la direccin de
equipos? Sin pretender extendernos en demasa en este punto, s se puede
concluir que todos ellos tenan un gran conocimiento en materia de estrategia militar, por lo que eran muy respetados por sus subordinados, y eran
grandes comunicadores. Adems es famosa la forma en la que Anbal consegua integrar a su ejrcito y motivar a personas de los pueblos dominados.
Tambin es sabido que trazar un plan de batalla y seguir su evolucin es
una prctica bsica en estas organizaciones.
Estados: suelen ser democracias o dictaduras y pueden ser mas o menos funcionales o jerrquicas. Se puede pensar que hay diferentes tipos de
estados y por tanto maneras de dirigir un pas. Pero, existe algo en comn
entre una repblica y un reinado? Y entre una democracia y una dictadura? Y entre una poltica de derechas y una de izquierdas? La organizacin
de los estados no es tan diferente, es ms tienen algunas importantes caractersticas de direccin similares. Puede variar la manera en la que se
consigue alcanzar la direccin, bien mediante la violencia estableciendo
una dictadura, bien mediante la eleccin por todos los ciudadanos en una
democracia. Puede nombrarse el jefe del estado por sucesin dinstica o
por eleccin democrtica. Pueden establecerse polticas (planes) liberales
o intervencionistas. Pero en todos los estados se divide la gestin en reas
y se delega en responsables a los que normalmente se llama ministros. As
se observa que la gestin del estado se divide en reas como economa,
defensa, agricultura, sanidad etc. De igual forma en todos hay un consejo o
comit formado por los mximos responsables de las reas y por su director
en el que se hace seguimiento de los objetivos, y se tratan los problemas y
dificultades as como nuevas acciones a tomar. Otra caracterstica comn es
que se dejan claras las reglas de actuacin de los miembros del estado (leyes) y en teora se comunica hacindolas pblicas. Tambin se dejan claras
las recompensas (bonificaciones) y los castigos (penalizaciones) que ganan
o sufren los miembros que cumplan o no las leyes.
Equipos deportivos: suponen una mezcla de direccin jerrquica y funcional, en la que no pocas veces los fuertes egos provocan conflictos. Son
hoy en da un claro ejemplo de proyectos elitistas y del mximo nivel en
los que se involucra gran cantidad de dinero, prestigio, fama, imagen de
marca, etc. Y en los que no hay hueco para los segundos. Parece clara la
enorme empresa que puede suponer una copa de Amrica de vela, un
campeonato de frmula 1 o un campeonato de ftbol, por poner algn
ejemplo. Slo vale la victoria y los requerimientos exigidos para ella son
extremos en todos los niveles de conocimiento, preparacin, dedicacin,
245
recursos econmicos Pero qu es lo que hace que los mismos equipos

sean ganadores con un director y no lo consigan con otro? Pensemos en un
equipo de ftbol, hay varios hechos evidentes que diferencian la direccin
de un equipo cuando llega a ser ganador y del mismo equipo cuando no
lo consigue:
La motivacin es mxima, parece que todo funciona y hay empata.
El entrenador consigue sacar el mximo de cada uno. Los jugadores
muestran una actitud perfecta y se sienten valorados. Su objetivo y el
del equipo es el mismo.
El entrenador consigue que los jugadores le respeten y hace que
crean en el plan de juego, no hace falta imponerlo.
El seguimiento del plan de juego es perfecto, cualquier mnima desviacin se corrige inmediatamente y no hay errores de concentracin
sobre el plan.
Organizaciones mafiosas: aunque obviamente ningn proyecto tico,
honrado y legal quisiera parecerse a este tipo de organizaciones, s es bueno estudiar alguna de las caractersticas que hacen que el nivel de compromiso de sus miembros sea tan alto. Por qu lo dan todo, incluso la vida,
por la organizacin? Y Por qu lo dan con tanta fidelidad, sin cambiar de
organizacin durante toda su vida? Se puede pensar que es porque si no lo
hacen les matan. Pero la respuesta no es tan fcil. En primer lugar qu es
lo que hace que una persona pertenezca a una organizacin mafiosa y no
se cambie a la rival? cosa que s ocurre en la vida empresarial. En una organizacin mafiosa si te cambias a la rival ests amenazado de muerte, pero
tambin lo estas si permaneces en la misma. Y porqu ingresas si sabes
que al ingresar ya ests amenazado de muerte? Este tipo de organizaciones
tiene una serie de premisas que debemos tener en cuenta:
Ofrecen a la persona todo aquello que desearan tener, y puede que
de otra manera fuera difcil o imposible. Primero cubren sus necesidades primarias (bsicamente alimentos, casa, sanidad, etc.). Luego
les dan un estatus econmico muy por encima de su entorno, alcanzando el de las clases ms favorecidas. Despus garantizan esto de
por vida, incluso, en algunas organizaciones, tanto para ellos como a
sus familias en caso de fallecimiento.
Los objetivos, la funcin y responsabilidad de cada uno as como las
reglas de comportamiento estn muy claros. Nadie tiene lugar a equivocacin.
Si cambias de organizacin no vas a obtener nada ms ni mejor de lo
que deseas y tienes.
246
Nadie tiene lugar a equivocacin.

En sntesis se puede concluir que, independientemente de la forma de
direccin y del tipo de organizacin, la historia de todas ellas muestra que
la clave para el xito en la direccin de los equipos de trabajo se basa en el
esquema representado en la figura 10.1.
Figura 10.1. Clave para el xito en la direccin de equipos de trabajo.
247
3. EL FACTOR HUMANO
Tal y como se remarc en la introduccin al captulo, el recurso humano tiene dos premisas nicas que lo diferencian del resto de los recursos
asignados al proyecto: el ser humano tiene emociones que influyen en el
desarrollo de su actividad racional y por tanto en su desempeo profesional
y las personas utilizan el proyecto como un medio para conseguir algo concreto en cada momento de su vida. Como director de un proyecto es esencial manejar esta y otras consideraciones para conseguir designar el mejor
trabajador a cada tarea y la continua motivacin de los mismos durante el
desarrollo del proyecto.
3.1. Inteligencia emocional
Daniel Goleman, en su libro Inteligencia emocional [Goleman 1995],
explicaba que la emocin es fundamental para pensar eficazmente y con
claridad, y tomar decisiones inteligentes. Este libro, que casualmente se
convirti en un superventas a pesar de ser un ensayo de psicologa, desarrolla la forma que tiene el ser humano de interactuar con el mundo
teniendo en cuenta los sentimientos y englobando habilidades como el
control de los impulsos, la motivacin o la empata. Tan importante como
esto es el hecho de que la inteligencia emocional se puede cuidar y desarrollar.
Por qu no depende el desarrollo profesional slo del coeficiente intelectual de las personas? El desarrollo humano ha hecho que nuestro cerebro
haya evolucionado de una parte primitiva emocional a una parte posterior
pensante o racional. Una parte del cerebro es la evolucin de la otra y ambas estn interconectadas. En esta parte del cerebro primitiva tenemos una
memoria en la que se almacenan relacionados hechos y emociones. Esto nos
permita reaccionar inmediatamente ante situaciones en funcin de nuestra
memoria de emociones asociada a situaciones anteriores. Los primeros aos
de nuestra vida son aos de aprendizaje emocional. Las conexiones entre
las dos partes del cerebro gestionan la relacin sentimientos-pensamientos.
Podemos decir que nuestro comportamiento vital est ligado por la inteligencia racional y la emocional. Como consecuencia de eso no podemos
predecir el xito de una persona o de un colectivo slo por su coeficiente
intelectual o el de sus integrantes (medida de la parte racional), ya que ste
no da cuenta de la capacidad de la persona para motivarse, para aguantar
la frustracin, para conocer su comportamiento ante la presin, la pasin, el
miedo, los conflictos con compaeros etc. El repertorio emocional de una
persona influir en el xito o fracaso de las empresas que intente. La figura
10.2 resume este concepto.
248
Figura 10.2. Desarrollo funcional del ser humano.
Por lo tanto las personas tienen una capacidad intelectual marcada por
su inteligencia racional pero limitada por su capacidad de gestionar las
emociones. Sirva como ejemplo el fracaso que sufri un aspirante a operador de central nuclear, que tras dos aos de formacin suspendi el acceso
final al bloquearse durante la prueba de simulacro de incidente. La inteligencia emocional es la capacidad de sentir, entender, controlar y modificar
estados anmicos propios y ajenos. Para qu debe servirle a un director de
un equipo de trabajo?: El director de un equipo de trabajo debe ser capaz
de reconocer sentimientos en s mismo y en otros, siendo hbil para gestionarlos.
Este conjunto de habilidades socio-emocionales que Goleman defini
como inteligencia emocional se puede dividir claramente en dos reas:
t Inteligencia INTRA-personal: aquellas internas, de autoconocimiento.
1. Autoconciencia o capacidad de saber qu est pasando en nuestro cuerpo y qu estamos sintiendo.
2. El control emocional, es decir regular la manifestacin de una
emocin y/o modificar un estado anmico y su exteriorizacin.
3. La capacidad de motivarse y motivar a los dems.
t Inteligencia INTER-personal: aquellas externas, de relacin.
1. La empata o entender qu estn sintiendo otras personas, ser capaz de analizar situaciones desde su perspectiva
2. Las habilidades sociales. Estas habilidades estn ligadas a la popularidad, el liderazgo y la eficacia en las relaciones interpersonales,
y que pueden ser usadas para persuadir y dirigir, negociar y resolver disputas.
249
Es muy importante no olvidarse de que el ser humano ha desarrollado

el cerebro al igual que todo su cuerpo adaptndolo a la supervivencia, por
lo que en ningn caso se trata de mutilar ningn mecanismo desarrollado
de manera natural, en este caso el mecanismo de las emociones. Se trata de
tener conocimiento de ellas, tanto en uno mismo como en los dems, para
adaptarlas y mejorar el desempeo propio y del equipo. En efecto, controlar las emociones no es reprimirlas ya que estaramos reprimiendo un mecanismo natural del cuerpo humano. Controlar las emociones es conocerlas
y adaptar su expresin en tiempo, forma e intensidad al contexto en el que
uno se encuentre, para potenciar la suma de la emocin y el pensamiento.
Las emociones son un mecanismo de supervivencia y como tal se deben
tratar. En principio no existen emociones positivas ni negativas sin analizar
el contexto en el que surgen.
3.2. Aspiraciones del ser humano en el trabajo
Como ya se ha dicho el ser humano utiliza el trabajo, en este caso el
proyecto, para conseguir su propio fin. La pregunta es: est ese fin estandarizado o hay infinitos fines? A esa pregunta dio respuesta Maslow
[Maslow, 1943] al describir su teora sobre la motivacin humana, en la
que propone cinco eslabones de necesidades que el ser humano necesita cubrir. Estas necesidades estn jerarquizadas. A medida que uno va
satisfaciendo las necesidades de un nivel inferior, uno aspira a satisfacer
las necesidades del nivel superior. Las necesidades inferiores son de pura
supervivencia y las superiores son de desarrollo de la persona. El primer
eslabn se refiere a la necesidad de comer, dormir etc. El siguiente a las
necesidades de seguridad (fsica, salud). En el tercer nivel se encuentran
las necesidades sociales y de pertenencia a un grupo (amistad, afecto).
En el cuarto nivel se alcanzan la necesidades de ego y reconocimiento
(xito, respeto). Finalmente, una vez cubiertos estos eslabones, se llega
al ltimo que corresponde a la auto-realizacin. Alcanzando la auto-realizacin el ser humano desarrolla lo mximo que pueden dar de s sus habilidades o cualidades. Se podra llegar a afirmar que el ser humano busca
ser lo que necesita ser. El pintor necesita pintar y el msico hacer msica.
Con esta pirmide de necesidades como premisa el gestor de un equipo
de trabajo tiene una clave para la motivacin de las personas: determinar
qu necesidades tienen satisfechas y facilitar el logro del siguiente eslabn
a travs del proyecto. En la figura 10.3 se puede observar la jerarqua que
ocupan estas necesidades.
250
Figura 10.3. Jerarqua de las necesidades descritas por Maslow.
La motivacin har que las personas tengan la actitud adecuada y sta

no depende slo del dinero. Donald Keough, en su libro The 10 commandments to business failure [Donald 2008], establece que a las personas hay
que pagarles lo adecuado y bastante como para que el dinero deje de ser
su preocupacin y se centren en ser productivos en su trabajo. Para motivar, habr que analizar lo que busca cada componente del equipo en ese
momento y ayudarle a conseguirlo a travs del xito del proyecto. De otra
forma el proyecto, como mucho, ser rutinario u obligatorio para mantener
lo ya conseguido y no tendr una motivacin excepcional. Una simple y
buena forma de motivar es elogiar el trabajo bien realizado, de esta forma
estamos cubriendo las necesidades de ego y reconocimiento.
3.3. Aptitudes y roles del ser humano ante el trabajo
A la hora de asignar tareas a los recursos humanos del equipo, y una
vez estudiada la seccin anterior, es fundamental preguntarse si existen
251
determinadas aptitudes o perfiles humanos predeterminados que les hagan

estar ms predispuestos que otros a desempear un determinado rol de
trabajo. O lo que es lo mismo, como gestor de un equipo, asignar el trabajo adecuado a cada persona en funcin de sus habilidades y capacidades,
y donde sta se sienta cmoda y tenga tendencia a realizarse, ya que,
adems, se estara logrando motivar. Se cometera un error si se dedicara
a una persona con una aptitud emprendedora a gestionar un sistema de
reclamaciones donde abunda la labor administrativa. En cambio, s se le
podra encomendar la tarea de que implementara el sistema, si no existiera,
y una vez implementado liberarle de la responsabilidad de gestionarlo sustituyndolo por una persona con un perfil administrativo. En el captulo 11,
donde se tratar el liderazgo y la comunicacin, se explicar ms sobre la
personalidad de los miembros del equipo y como permitir una comparativa
a travs del indicador de tipos de Myers-Briggs, una herramienta altamente
extendida. Tambin existen otro tipo de roles, como los roles de Belbin,
que se estudian en reas de recursos humanos.
Sin profundizar ms sobre esos tipos de roles en esta seccin, s conviene recordar que cada persona tiene un perfil humano que le hace estar
predeterminado para encontrar la auto-realizacin en determinados roles
de trabajo. Incluso, si es necesario, se debe hacer una descripcin detallada
de los puestos de trabajo a cubrir en el proyecto, para elaborar el perfil del
candidato ideal. En este punto hay que diferenciar entre el perfil ideal y el
imprescindible. Las competencias, habilidades y destrezas junto con las aspiraciones personales deben de servir para asignar los diferentes roles. Puede que estas capacidades y aspiraciones evolucionen a lo largo del tiempo.
Pero la observacin, empata y comunicacin del director del equipo debe,
en cada momento, intentar averiguar tanto lo que busca cada miembro del
equipo como aquello para lo que es ms apto. De esta forma tendr xito
al asignar las tareas del proyecto, evitando la costumbre de nombrar a las
personas para los puestos que habitualmente desempean, sin preguntarse
si realmente son las ms adecuadas.
3.4. tica
Hoy en da es impensable gestionar personas en cualquier orden de la
vida si no es con los ms altos estndares de tica y respeto a la persona.
No tiene cabida ningn tipo de conducta que suponga una aberracin
de la direccin y se convierta en una manipulacin de las personas para
lograr el objetivo del proyecto. Actitudes como entrenadores utilizando
el dopaje para lograr el fin son rechazadas por la sociedad. Ya se ha dedicado el captulo 4 de este libro a tratar este tema, pero merece la pena
252
hacer hincapi en esta seccin para no olvidar su importancia al gestionar

seres humanos.
4. HABILIDADES Y TCNICAS DE GESTIN Y DIRECCIN DE EQUIPOS

Puede pensarse que un buen director nace y no se hace. Como ya se ha
comentado en la introduccin del captulo, es habitual el fracaso de excelentes profesionales cuando llegan a la etapa en la que tienen que gestionar
un equipo de trabajo, dado que no suelen recibir una formacin previa que
complemente la faceta tcnica y que les eduque sobre la gestin especfica
del recurso humano. Es cierto que con cualidades innatas se puede llegar a
ser excepcional, pero para ello se requerir conocimiento y experiencia. Un
tenista profesional, dotado de grandes habilidades naturales, necesitar conocer las reglas y tcnicas y entrenarlas durante aos para llegar a los puestos ms altos. De esta misma forma en la direccin y gestin de equipos de
trabajo no basta con tener gran capacidad de comunicacin para conseguir
la mejor actitud de las personas, ser necesario, entre otros, conocer los
factores humanos estudiados en la seccin anterior y desarrollar la empata
necesaria para acostumbrarse a gestionar los sentimientos y aspiraciones
ajenas y alinearlos con los objetivos del proyecto.
A continuacin se describirn algunas tcnicas y habilidades imprescindibles para una buena direccin y gestin de equipos de trabajo. Como ya
se ha estudiado en los captulos 2 y 3 del libro la primera herramienta necesaria para una buena gestin del equipo humano es la planificacin.
t La planificacin: es una herramienta bsica en la funcin de direccin. Steiner en su libro La planificacin de la alta direccin [Steiner 1979] resalta ampliamente esta herramienta. La planificacin es
el ejercicio de pensar a fondo, elegir y descartar, organizar y como
resultado establecer un plan. En la planificacin se tiene que definir
el objetivo y concretar el plan para alcanzarlo. El plan es el resultado
de la planificacin. En el plan se explica y se concreta cmo se va a
alcanzar el objetivo, qu hitos hay que ir consiguiendo y en qu tiempos, qu recursos (humanos, econmicos y materiales) se necesitan
y cundo se necesitan. El plan es el diseo de la accin, con detalles
precisos y especficos. La planificacin es un pensamiento a travs
del cual se comprueba aquello que se desea alcanzar y la manera de
lograrlo y los planes son la evidencia tangible del pensamiento del
planificador.
En la planificacin se ir aumentando el detalle del plan conforme se
pasa de la estrategia a la tctica y finalmente a la planificacin operativa, donde deben quedar asignados todos los recursos.
253
t Asignacin de recursos: una vez definido el plan, en el cual se han

marcado los caminos, actividades e hitos necesarios para alcanzar el
objetivo y se han definido los recursos temporales, materiales, econmicos, y lo que ms interesa en este captulo, los recursos humanos
necesarios, es el momento de asignar cada una de las tareas a las
personas, en funcin de sus aptitudes y habilidades. Los recursos
humanos se definirn teniendo en cuenta lo descrito en la seccin
anterior sobre el perfil de los candidatos y las caractersticas requeridas para cada tarea. Si no existe exactamente el perfil perfecto se
debe utilizar el que mejor se adapte, sustituyendo la falta de aptitud
por actitud y formacin, si fuera necesario. Para ello se utilizar la
motivacin, la persuasin y la comunicacin. Ser necesario emplear
los conocimientos de inteligencia emocional y las necesidades del ser
humano descritas por Maslow anteriormente. El objetivo de un director es conseguir el xito del proyecto con los recursos humanos que
la empresa pone a su alcance, uniendo aptitudes y requerimientos y
consiguiendo la mejor actitud a travs de la motivacin.
t El arte de delegar: delegar es dejar hacer pero no es ni dejar ni
hacer, sino las dos cosas juntas. Realmente no es una tarea fcil.
Hay que dejar que las personas a las que se les ha asignado el trabajo
lo realicen y evitar la tentacin de hacer o involucrarse demasiado
en partes aisladas del trabajo, pensando que as se hara de mejor
manera. Pero a la vez hay que asegurarse de que esas tareas se llevan
a cabo eficientemente, logrndolas en tiempo, calidad y coste segn
el plan, ya que el hecho de delegar no exime de responsabilidad al
director del proyecto.
Las personas en las que se delega deben de contar con la confianza
plena de su responsable. Se mantendr un seguimiento de su progreso y se intentar mantener intacta la mejor actitud manteniendo la
motivacin. Se debe ser exigente y comprensivo a la vez utilizando
la empata. Para delegar hay que formar un equipo de confianza,
mantenerlo motivado, dejarlo trabajar, y asegurarse de que se van
logrando los hitos marcados. El mximo responsable si fracasa el
proyecto y probablemente el nico es el director, por lo que delegar
se convierte en una necesidad para desarrollar el proyecto. Ms all,
delegar es utilizar la vieja estrategia divide y vencers.
t Motivacin: motivar es una de las habilidades que debe adquirir y
dominar un director para obtener lo mejor de su equipo de trabajo.
En efecto, dominar la motivacin es bsico para conseguir y mantener la mejor actitud de los trabajadores hacia la consecucin del objetivo del proyecto. Ya se ha visto que las personas utilizan el trabajo
como un medio para conseguir su propio objetivo o necesidad vital
254
y que para motivar a las personas hay que ofrecerles la posibilidad

de cubrir las necesidades de la pirmide de Maslow que no tengan
totalmente cubiertas, o lo que es lo mismo lograr alinear el objetivo
personal de cada trabajador con el objetivo del proyecto. Para una
adecuada motivacin se requiere por tanto:
1. EMPATA: el primer paso para motivar es tener la suficiente capacidad para detectar lo que sienten y necesitan los colaboradores o
subordinados.
2. OBJETIVOS COMUNES: el segundo paso es conseguir que el objetivo del proyecto sea conocido por todos y se convierta en un
medio para lograr las necesidades individuales alineando ambas
cosas.
3. COMUNICACIN: la capacidad de comunicacin continua del director o lder debe servir para mantener permanentemente los dos
primeros puntos.
t El seguimiento del proyecto: a esta tcnica se ha dedicado por completo el captulo 8 de este libro. Conviene recordar, especialmente,
que aquello que no se puede describir no se puede medir y que
aquello que no se puede medir no se puede controlar. Para controlar
la evolucin del proyecto y la desviacin que puede surgir entre el
plan y la realidad, se describen los indicadores de seguimiento (en
ingls KPI o Key performance indicator), que constituirn el cuadro
de mando integral. Entre estos indicadores seguro que se encuentran
los relacionados con calidad, tiempo y coste, vitales en el logro de
cualquier proyecto. El cuadro de mando integral, junto con las reuniones de seguimiento de proyecto, permitirn al director detectar
las desviaciones y tomar las acciones oportunas para corregirlas.
t Gestin del tiempo: conviene aclarar primero que este punto se refiere a la gestin del tiempo del director y de los integrantes del
equipo, y no a la de los hitos o actividades del proyecto. Es una de
las primeras tcnicas que se debe aprender, ya que, aunque es obvio,
hay que recordar que es un recurso que no se puede comprar, y se
hace necesario gestionar en 24 horas el tiempo para las necesidades
vitales (comer, dormir), las sociales (familia y entorno) y la dedicacin al proyecto. A continuacin se enumeran algunas tcnicas que
pueden ser tiles en esta gestin:
1. Trabajar el tiempo propio como si el de un proyecto se tratara,
planificando actividades y priorizando. Ser capaz de hacer en cada
momento lo que se tiene que hacer, lo importante, evitando las
interferencias y las urgencias.
255
2. Las reuniones de trabajo son necesarias pero bajo las reglas de

la eficiencia: toda reunin tiene que tener un fin u objetivo, una
agenda con los puntos a tratar, se deben apagar los mviles y tiene que tener una duracin mxima definida al convocarla. En una
reunin cada minuto perdido se multiplica por el del nmero de
asistentes. Al finalizar la reunin es necesario hacer un breve acta
(donde impere el pragmatismo al redactarlo) con los acuerdos
alcanzados, los puntos de accin, el responsable de cada punto y
la fecha lmite para cada punto.
3. Hay que invertir todo el tiempo necesario en informarse, sintetizar, discutir, descartar, pensar y ser gil ejecutando las acciones
planificadas.
4. Contar con un cuadro de mando integral til y pragmtico del
proyecto ayudar a ahorrar mucho tiempo.
5. Delegar.
6. El 80% de su tiempo tiene que estar dedicado al 20% de las actividades crticas y de real importancia, el resto se deben seguir con
poco tiempo.
5. LAS CUALIDADES DE UN BUEN DIRECTOR

Ya se ha descrito que, independientemente de las cualidades innatas
que tenga una persona, se necesita una formacin especfica en gestin de
los equipos de trabajo para logar dirigirlos exitosamente. Pero cul seran
esas cualidades ideales que debera tener una persona para, desarrollndolas, llegar a ser un excelente director de equipo? Qu se le debera pedir a
un director para considerarlo un buen gestor del equipo de trabajo?. Cundo se utiliza la palabra pedir se denota tanto lo que van a demandar las
personas jerrquicamente superiores y las subordinadas, como lo que se
tiene que auto-exigir el propio director. Idealmente las siguientes cualidades seran necesarias en un buen director de equipos de trabajo.
Experto: debe poseer tanto conocimiento terico como prctico. ste
permitir dominar diferentes situaciones estratgicas, garantizar el respeto con superiores y subordinados y favorecer el contacto e intercambio
de ideas e informacin con ellos, dar capacidad para sintetizar y permitir aprovechar al mximo el nico recurso que no podemos comprar
(tiempo). El conocimiento y la experiencia son la base sin las que no se
debera permitir dirigir el trabajo de otros para conseguir alcanzar un objetivo comn.
Implicado: el director es el mximo responsable del proyecto, participa en la creacin del plan del mismo, en la asignacin y control de los
256
recursos, en el seguimiento, en la creacin del equipo humano, etc. Por

todo ello se le debe exigir que el proyecto sea para l de las mximas
prioridades en su vida. Que se convierta en una necesidad para realizarse.
Debe dedicarle gran tiempo a pensar sobre l, a comunicar, a informarse, a
anticiparse. Incluso debera tener cierta obsesin con el proyecto. Por otro
lado al ser la persona que debe guiar y el mximo motivador se convierte
en una especie de espejo. El resto de integrantes del proyecto van a percibir
totalmente su implicacin y dedicacin.
Ejemplar: somos lo que hacemos y debemos hacer lo que decimos. El
director debe hacer cumplir los valores y las pautas de comportamiento
definidas, probablemente incluso haya participado en su definicin, por lo
tanto debe ser un ejemplo en ellas. Un director ejemplar no slo motiva,
sino que arrastra. Aunque est ampliamente admitido que el ser ejemplar
es una de las formas ms efectivas de direccin, tambin es claro que es de
las ms difciles.
tico: una persona que puede tomar decisiones sobre la direccin que
deben tomar un grupo y su plan de actuacin y que no tenga los valores
adecuados puede producir un desenlace desastroso y traumtico. Esto se
agrava si se trata de un lder que conduce y moviliza masas. Un ejemplo
claro y reciente es el de Hitler, aunque tambin existen multitud de entrenadores deportivos, sobre todo visibles ltimamente en ciclismo, que han
motivado y consentido el dopaje para conseguir el objetivo.
Enrgico: dirigir requiere de una buena dosis de energa sin la cual no
ser capaz de soportar el ritmo y la exigencia del puesto. Menos an de
trasmitirla.
Visionario: el director y ms an el lder necesitan ver ms lejos de lo
habitual. Se requiere que sean capaces de ordenar y resumir su entorno
para posicionarse en el horizonte adecuadamente. En el caso del liderazgo
a veces es necesario imaginar un futuro y una forma de llegar a l.
Analtico: con la capacidad de anlisis y sntesis que permita manejar
tanto la cantidad de informacin que recibe, como la comunicacin con
eficacia. Esa capacidad para sacar la esencia de las cosas es vital para planificar la solucin a problemas y ser capaces de gestionar el escaso tiempo.
Motivador: un buen directivo tiene que ser capaz de sacar el mximo
de sus colaboradores, consiguiendo que stos tengan la mejor actitud para
el proyecto.
Comunicador: hoy en da no se concibe que un lder no tenga un dominio de todas las formas y medios de comunicacin (orales, escritos, electrnicos, presentaciones, gestos, etc.) De hecho es una de las facetas sobre las
que los polticos elegidos para liderar una campaa entrenan y se asesoran.
Es muy importante darse cuenta que comunicar implica tanto saber trasmitir
como escuchar.
257
Persuasivo: no solo se debe ser capaz de comunicar eficazmente sino

de persuadir. La diferencia est en la bsqueda del argumento correcto que
consiga convencer.
Emptico: disponer de la capacidad de detectar los estados de nimo de
las personas y de entenderlos permitir motivar y utilizar adecuadamente la
inteligencia emocional.
Constante: los proyectos suelen ser arduos, en cierto modo se podra
asimilar a una carrera de maratn, por lo que se har necesaria la constancia, esa capacidad para superar continuamente los momentos de frustracin
y seguir hasta el final.
En la tabla 10.1 se sintetizan las cualidades deseables de un buen director.
Experto
Enrgico
Comunicador
Implicado
Visionario
Persuasivo
Ejemplar
Analtico
Emptico
tico
Motivador
Constante
Tabla 10.1. Cualidades deseables de un buen director de equipo.
6. RESUMEN
Como se ha visto durante el captulo el director de un proyecto o el
responsable de un equipo humano tiene como misin hacer hacer a las
personas a su cargo. Es labor suya asignar las tareas planificadas en funcin
de las diferentes aptitudes y competencias de los integrantes del equipo,
delegar para que esas tareas se lleven a cabo, conseguir la adecuada actitud
ante el trabajo a travs de la motivacin y realizar un seguimiento continuo,
a travs de los indicadores de desarrollo y de las reuniones de seguimiento,
para comprobar que se van alcanzando los objetivos de tiempo, calidad y
coste.
Para ello es necesario ser consciente de que el equipo humano va a
tener emociones que pueden influir en el desempeo profesional. Hay que
ser capaz de tener la empata suficiente para detectarlas y saberlas gestionar, sin mutilarlas, para que no afecten negativamente al proyecto. O lo que
es lo mismo tener una buena inteligencia emocional. Ser tambin imprescindible darse cuenta de que los integrantes del equipo buscan un objetivo
personal y utilizan el trabajo para intentar conseguirlo. Alinear este objetivo
personal con los objetivos del proyecto es clave para la motivacin y por lo
tanto para la adecuada actitud de las personas en el proyecto.
258
Es impensable que todo esto no se realice de acuerdo a la tica y respeto al ser humano. Hoy en da no tiene ningn sentido utilizar mtodos o
tcnicas de direccin que olviden esto y se centren slo en la consecucin
del objetivo de proyecto. Por supuesto se requerir conocer qu aptitudes
son las que poseen los miembros del equipo para asignarles las tareas
adecuadas. El mximo responsable de la consecucin del objetivo es el responsable del equipo, por lo que el seguimiento del desempeo del equipo
y de los logros de los hitos marcados ser un proceso vital para la buena
direccin. Se debe ser consciente de que para llegar a alcanzar la direccin
de un equipo de trabajo y tener xito ante superiores y subordinados se demandar conocimiento, dedicacin, ejemplaridad, valores, energa, visin,
capacidad de anlisis y sntesis, persuasin, empata, constancia y ser capaz
de comunicar y motivar.
Tomando como base los conocimientos y tcnicas de direccin y gestin
de equipos humanos se hace necesario el estudio de las claves para el liderazgo y la comunicacin cuando el entorno del proyecto es ms inestable y
desconocido como se ver en el siguiente captulo.
7. REFERENCIAS
AMMANN, D., Marc Rich el rey del petrleo, Ediciones Planeta, 2011, p. 121.
GOLEMAN, D., Inteligencia emocional, Editorial Kairos, 1995.
KEOUGH, D., The 10 commandments to business failure, Penguin, 2008.
KOTTER, J. P., Qu hacen los lderes, Ediciones Deusto, 1999.
MASLOW, A. H., Una teora sobre la motivacin humana, 1943, Motivacin y Personalidad, Daz de Santos, 1991.
STEINER, G. A., Planificacin de la alta direccin, Ediciones Universidad de Navarra, 1979. Manuales IESE. EUNSA.
259
CAPTULO 11
LIDERAZGO Y COMUNICACIN
Alejandro Salado Dez
1. INTRODUCCIN
El liderazgo y la gestin de proyectos tienen muchos aspectos en comn. Por ejemplo, tanto el lder como el jefe del proyecto ayudan a los
integrantes de sus equipos a crecer personal y profesionalmente, pero, sin
embargo, liderazgo y gestin no dependen el uno del otro. Esto es, se puede ser un buen jefe de proyecto sin ser un lder, que ya es importante en
s mismo, y se puede ser lder en (de) un equipo sin un puesto de gestin
o direccin formal. Ahora bien, el liderazgo es de importancia capital para
el jefe de proyecto. Debido a sus connotaciones emocionales e inherente
autoridad moral en las relaciones para con los miembros de un equipo, el
liderazgo no slo facilita ciertos aspectos de la gestin, sino que adems
eleva al jefe de proyecto a un estadio de reconocimiento superior, algo as
como un super-jefe. Una combinacin adecuada de gestin y liderazgo en
el jefe del proyecto es uno de los ingredientes clave para la formacin de
equipos de trabajo de alto rendimiento y, por consiguiente, para la realizacin de proyectos de gran xito.
Este captulo trata los aspectos del liderazgo en el proyecto desde dos
puntos de vista: cmo liderar mejor y cmo gestionar el liderazgo. Se hace
especial hincapi en la dependencia del tipo de liderazgo con los objetivos
a cumplir y el equipo a liderar, as como en el uso de la inteligencia emocional para generar confianza y ser aceptado como lder, introduciendo la
medida de perfiles psicolgicos MBTI (Myers-Briggs Type Indicator) como
261
herramienta para el entendimiento y planificacin de equipos. Por otro

lado, el captulo describe cmo se desarrolla la comunicacin en el proyecto, entendida sta como el intercambio de informacin entre los miembros
del mismo, y establece las pautas para gestionar de manera eficaz la comunicacin interna y externa del proyecto.
En concreto, los objetivos principales de este captulo son los siguientes:
t $POPDFSFORVTFGVOEBNFOUBFMMJEFSB[HPZDNPHFTUJPOBSMP
t &OUFOEFSMBUSBEBPCKFUJWPTFRVJQPMEFS
t $POPDFSMPTUJQPTEFQFSTPOBMJEBEFTFOVOFRVJQPZDNPHFTUJPnarlos.
t $POPDFS FO RV TF GVOEBNFOUB MB DPNVOJDBDJO FO FM QSPZFDUP Z
cmo gestionarla.
t $POPDFS MPT NFDBOJTNPT FYJTUFOUFT QBSB FTUBCMFDFS VOB DPNVOJDBcin efectiva.
2. BASES DEL LIDERAZGO Y LIDERAZGO EN EL PROYECTO

Un lder es, segn la Real Academia de la Lengua Espaola, una persona
a la que un grupo sigue, reconocindola como jefe u orientadora. Esta
definicin contiene los dos aspectos ms importantes del liderazgo con respecto a la gestin. En primer lugar, al lder no se le obedece, sino que se le
sigue. Y en segundo lugar, el lder no se impone, sino que se le reconoce.
Eso s, tanto el seguimiento como el reconocimiento han de ser crticos,
esto es, en cualquier momento cualquier integrante del equipo puede cuestionar las decisiones o comportamientos del lder. De lo contrario, la falta
de pensamiento crtico puede llevar a una fe ciega en el lder, lo que podra
fcilmente ser nocivo para un proyecto, como demostraron en tan dispares
mbitos los primeros aos de Steve Jobs al mando de Apple y NeXT a nivel
tecnolgico o Adolf Hitler y el movimiento nazi a nivel poltico.
Desde el punto de vista de la gestin de proyectos, es importante entender la amplitud del liderazgo en el proyecto, as como dominar su gestin
para utilizarlo como herramienta que contribuya al xito del mismo. El gestor del proyecto deber tratar y enfocar el liderazgo desde dos puntos de
vista principalmente. Por un lado, intentando seguir las pautas necesarias
para actuar como lder adems de gestor, en la medida de lo posible; es
decir, conseguir ser el punto de referencia informal en el proyecto (lder),
adems del punto de referencia formal (gestor). Por otro lado, colocando a
lderes en distintos puestos de la organizacin del proyecto, atendiendo a
las necesidades del mismo.
La primera pregunta que surge al hablar de liderazgo es si el lder nace
o se hace. Aunque muchos autores y profesionales de diferentes mbitos
262
han tratado de dar respuesta a esta pregunta desde hace bastante tiempo,
no existe todava una base aceptada por todos [Kotter, 1990; Bennis, 2009;
Gentry et al., 2012]. Sin embargo, hay varios aspectos en los que la mayor
parte de la comunidad cientfica y profesional est de acuerdo. En primer
lugar, est demostrado que todas las personas tienen el potencial de ser
lderes, aunque no de liderar a cualquier persona. Esto es, el liderazgo no
es una capacidad dicotmica, sino que todas las personas cuentan con dicha capacidad en mayor o menor medida, si bien el rol de lder o seguidor
depender finalmente del contexto, el equipo y las circunstancias en que
el individuo desarrolle y ponga en prctica sus capacidades personales y
sociales. En segundo lugar, se sabe que la gentica favorece ciertas caractersticas que facilitan el surgimiento como lder, por lo que unas personas
estarn por lo general ms predispuestas a liderar y otras a coger el rol de
seguidor. Por ltimo, la experiencia dice que se puede aprender a ser mejor
lder. Estas conclusiones son positivas desde el punto de vista de la gestin
de proyectos, pues por un lado aseguran que se tenga el nivel de liderazgo
que se tenga, en cualquier caso, se dispone de la capacidad de mejorarlo;
y por otro, se tiene la oportunidad de estructurar un equipo de personas
de forma que se saque el mximo rendimiento de cada miembro, desde un
punto de vista de liderazgo.
El liderazgo puede entenderse como el conjunto de habilidades que
posee y, sobre todo, pone en prctica un lder. [Maxwell, 2009] propone un
conjunto de leyes que explican qu debe existir para que haya liderazgo y
dan base a las habilidades que un lder ha de tener, las cuales se presentarn en la seccin 4.3. Los aspectos ms importantes de las 21 leyes de
Maxwell se describen a continuacin:
t La confianza es el fundamento del liderazgo. El liderazgo se basa en
la confianza bidireccional entre el lder y sus seguidores. Si un lder
no consigue generar confianza, jams le seguirn los miembros de
su equipo. De la misma forma, si un lder no consigue confiar en sus
seguidores, jams generar confianza en ellos.
t La medida real del liderazgo es la influencia. Por definicin un lder
influye, inspira para que otros compartan su visin con el objetivo de
llevar el barco en la direccin correcta.
t El liderazgo se desarrolla da a da, no en un da. Un lder ha de ser
lder siempre, es decir, ser coherente comportndose de igual modo
en cualquier circunstancia.
t Cualquier persona puede gobernar un barco, pero se necesita un lder para marcar el rumbo. El gestor dice qu hay que hacer, el lder
dnde hay que ir. Esto es fundamental para que los integrantes del
263
t
t
t
t
t
t
t
equipo entiendan por qu hacen lo que estn haciendo y trabajen

por los mismos objetivos.
Los lderes aaden valor sirviendo a otros. El liderazgo no se centra
en promocionarse uno mismo, sino en hacer mejores a los dems,
valorando a los miembros del equipo y lo que hacen, as como sabiendo qu es lo que valoran ellos.
La gente normalmente sigue a lderes que estn ms capacitados que
ellos. El lder ha de ser ntegro y ganarse el respeto profesional de sus
seguidores, que puede conseguirse bien poseyendo un nivel tcnico
considerablemente ms alto del resto de los integrantes del equipo, o
bien, siendo consciente de sus limitaciones y confiando en la opinin
de los expertos de su equipo.
Los lderes evalan todo con un prejuicio de liderazgo. Los lderes se
caracterizan por prever lo que va a ocurrir, es decir, hacen un buen
uso de su intuicin, que se alimenta desde cinco fuentes de informacin con la perspectiva de liderazgo: su situacin, la del proyecto y la
de su equipo; encontrar tendencias en vez de hechos; saber de qu
recursos puede disponer en vez de qu puede hacer l mismo; ser
consciente de qu piensan las personas de su equipo; y conocerse a
s mismos.
El lder ha de atraer. La atraccin ocurre normalmente por compartir
valores, ideas, etc. Por tanto, el lder ha de tener en cuenta que sus
seguidores sern un reflejo de lo que l proyecte.
Los lderes llegan al corazn antes de darte la mano. Un lder ha de
inspirar, pues las personas le siguen, estn con l, no son simplemente subordinados.
Slo los lderes seguros de s mismos dan poder a otros. Delegar genera
confianza. Y la confianza permite el liderazgo.
La gente hace lo que ve. Ms all de las palabras, mensajes o visin,
las personas hacen lo que ven a su alrededor. Por tanto, el lder ha
de ensear con el ejemplo.
264
3. TRADA OBJETIVO-EQUIPO-LDER
El liderazgo puede ejercerse de varias formas, siendo una de las caractersticas principales que los diferencian la forma en que se toman las
decisiones, como muestra la tabla 11.1 para los estilos de liderazgo ms
extendidos [Goleman, 2000; Goodnight, 2004]. Si bien todos los estilos de
liderazgo son vlidos, unos funcionan mejor que otros dependiendo principalmente de dos factores: las personas que forman el equipo y los objetivos
que dicho equipo persigue [Goleman, 2000]. El punto clave para el gestor
de proyectos es por tanto discernir qu estilo de liderazgo debe ejercer,
en qu momento y qu estilos de liderazgo establecer en los equipos del
proyecto. Por tanto, la efectividad de un equipo depender en gran medida
del producto entre los dos factores mencionados y el lder, tal y como se
observa en la figura 11.1.
Estilo
Descripcin
En el liderazgo participativo o democrtico las decisiones se toman
de forma colectiva en el equipo, si bien el lder gua la toma de
Participativo
decisiones. Normalmente, todos los miembros del equipo tienen la
misma capacidad de influencia en las mismas.
En el liderazgo coactivo o autocrtico las decisiones se toman de
forma autocrtica o dictatorial. Si bien puede consultar al equipo, el
lder toma la decisin de manera unilateral, es decir, no se requiere
Coactivo
consenso. No se debe confundir con fe ciega, ya que en este caso
al lder se le acepta concienzudamente y se le confa la decisin
unilateral debido al contexto en que se toma la misma.
En el liderazgo Laissez-Faire la toma decisiones se delega directamente
Laissez-Faire
a cada individuo.
En el liderazgo transaccional la toma de decisiones se liga a incentivos
Transaccional
y penalizaciones que el equipo acepta.
En el liderazgo transformativo se involucra al siguiente nivel
Transformativo
jerrquico en la decisin, como si tambin fuera parte del equipo.
Tabla 11.1. Estilos de liderazgo.
Para establecer el tipo de liderazgo que maximizara la eficacia de

un equipo no es suficiente determinar nicamente el resultado final que
se espera, sino adems saber en qu contexto el equipo ha de realizar
el camino. Por ejemplo, conseguir ajustar los costes de un proceso de
desarrollo, reparar un servicio crtico o modificar un producto existente
para mejorar el ofrecido por la competencia funcionan mejor con tipos de
liderazgo distintos.
265
Figura 11.1. Trada objetivo-equipo-lder
Una vez los objetivos estn aclarados, hay que establecer un equipo que
realice las tareas necesarias para conseguir los resultados esperados y un
lder que asegure que se dan los pasos necesarios para arribar a buen puerto. A la hora de definir paquetes de trabajo es habitual, aunque no norma,
que el gestor se centre nicamente en el perfil tcnico que se necesita. Sin
embargo, si bien la capacidad de una persona para realizar una tarea puede
basarse en su perfil tcnico (lo que sabe), la capacidad para realizarla en un
contexto determinado se basa en su perfil psicolgico (cmo es).
Ejemplo 1. El equipo A debe desarrollar una arquitectura de un satlite
que reduzca en un 20% el consumo de potencia con respecto a versiones
anteriores del mismo satlite. El equipo B debe mantener un satlite operativo tras una reduccin del 10% en la energa disponible debido a un fallo
en un panel solar.
Ambas tareas requieren del mismo perfil tcnico, ya que ambas estn
relacionadas con la arquitectura de gestin de potencia de un satlite. Sin
embargo, el equipo A tiene el objetivo de desarrollar algo nuevo y por lo
tanto requiere de ideas nuevas, dispone de tiempo para realizar sus actividades y los errores no tienen un impacto econmico significativo en el proyecto. Ello llevara a elegir personal creativo, dialogante, con capacidad de
escuchar y sin opiniones crticas. Por su parte, el equipo B debe reaccionar
rpido ante un problema en un sistema existente, por lo que requiere de
266
rapidez en el anlisis, disciplina en el seguimiento de procesos establecidos

y capacidad para asumir toma de decisiones. Ello llevara a elegir personal
con facilidad de toma de decisiones bajo estrs, rpido, seguro y disciplinado.
Por tanto, los objetivos a cumplir por un equipo influyen en cmo debe
ser el perfil psicolgico de sus miembros. La eleccin del tipo de liderazgo
sigue el mismo camino.
Ejemplo 2. El equipo A se enfrenta a un incendio en un edificio, por lo
que se ha de organizar su evacuacin e informar a las autoridades con el
objetivo de salvar el mayor nmero posible de vidas. El equipo B ha de tomar
una decisin sobre si invertir o no cierta cantidad de dinero en renovar las
escaleras o en construir una piscina nueva para el edificio con el objetivo de
satisfacer al mayor nmero de vecinos.
Para el equipo A es necesario reaccionar con rapidez y seguridad, pues
el tiempo es crtico para salvar el mayor nmero posible de vidas. Por tanto,
es preferible contar con alguien que se yerga como lder y tome las decisiones sin necesidad de consulta, antes que realizar debates y votaciones
mientras el fuego se extiende por el edificio. Por tanto, un liderazgo de estilo coactivo resultara ms efectivo. El equipo B por el contrario, dispone de
tiempo para tomar la decisin y adems, sta influye directamente en cada
uno de los miembros del equipo. Por tanto, es probablemente preferible un
debate o votacin. Por tanto, un liderazgo de estilo participativo resultara
ms apropiado.
As, los objetivos a cumplir por un equipo influyen en cmo debe ser
el tipo de liderazgo. Por ltimo, el tipo de liderazgo debe cuajar con las
personalidades de los miembros del equipo. Es decir, stos deben estar en
disposicin de someterse al tipo de liderazgo; en definitiva, de aceptar al
lder como tal.
Concluyendo, el gestor de proyectos debe definir sus equipos de trabajo y elegir a sus lderes atendiendo siempre a los objetivos que se deben
conseguir, a las personalidades de los miembros del equipo y al tipo de
liderazgo.
4. CMO LIDERAR
Partiendo de las leyes descritas anteriormente en este captulo, se puede
establecer que el liderazgo se ejerce desde tres perspectivas: centrado en las
personas, siendo profesional y siendo positivo [Owen, 2009].
El lder ha de centrarse en las personas porque son el fundamento del
liderazgo en s mismo: un equipo de trabajo es equipo cuando hay varias
267
personas; un lder slo puede ser lder si hay personas que lo sigan. El lder ha de ser profesional, pues se debe a su equipo y, en ltima instancia,
es un reflejo de la profesionalidad del mismo. Por ltimo, un lder ha de
ser positivo porque ha de mantener a su equipo motivado. Ser positivo es
una forma de ver la vida y enfrentar los problemas. Consiste en encontrar
soluciones en vez de buscar problemas. Ser profesional tiene que ver con
la integridad, con la capacidad de trabajo y de cumplir lo que se promete.
Ambas formas de ser dependen de tener en mayor o menor medida ciertas
cualidades personales. stas se explicarn ms adelante.
Figura 11.2. Perspectivas del liderazgo.
Ahora bien, para liderar personas, el foco est en los dems, en conocerlas. As, el lder debe tener en cuenta dos factores: la personalidad del
individuo con el que trata y sus necesidades. Es importante conocer la
personalidad de cada uno de los miembros del equipo, pues esto ayudar
a entender comportamientos tales como la forma de relacionarse con los
dems, la manera de participar en decisiones o la aptitud y actitud frente a
diferentes tipos de tareas. Esto es necesario tanto para conseguir un buen
ambiente de trabajo como para mejorar el rendimiento de un equipo, por
ejemplo asignando tareas que vayan acorde al carcter. Del mismo modo,
conocer las necesidades de las personas proporciona informacin valiosa
que el lder debe utilizar tanto para complacer en la medida de lo posible a
su equipo y ganar y mantener su confianza, como para resolver conflictos
internos si existen.
268
4.1. Las necesidades del individuo en el trabajo

Basndose en el modelo de las necesidades humanas de Maslow [Maslow, 1943] [Owen, 2009] propone una pirmide modificada que refleja las
necesidades del individuo como miembro de una empresa o proyecto (figura 11.3).
Figura 11.3. Pirmide de Owen de las necesidades del individuo

como miembro de una empresa (adaptado de [Owen, 2009]).
El lder de un equipo tiene por norma general poca influencia en los dos
primeros niveles, ya que habitualmente no tiene poder directo ni sobre el
salario ni sobre las condiciones laborales de cada individuo de su equipo, si
bien es cierto que puede influir indirectamente mediante evaluaciones independientes de su trabajo o apoyando causas especficas que stos puedan
tener, por ejemplo. Respecto al vrtice de la pirmide, que corresponde con
la sensacin de estar trabajando en algo importante para la sociedad, en
algo especial o en algo que quede despus de que el trabajo haya concluido,
depende ms del proyecto en s mismo que del trabajo que se realice. Por
ejemplo, proyectos como el alunizaje del hombre, el desarrollo del walkman o la edificacin de la Sagrada Familia, proporcionan una satisfaccin
269
especial, probablemente superior al desarrollo de alarmas para comercios

o radios para coches. Sin embargo, el liderazgo tanto a nivel de proyecto
como a nivel de alta direccin s tiene algo de poder en este nivel, pues
independientemente del proyecto, es posible encontrar razones para estar
orgulloso de haber contribuido a ellos. En los ejemplos anteriores, puede
pensarse en las familias que se est protegiendo tanto fsicamente como a
nivel econmico por disponer de dichas alarmas o en las muchas personas
que alegran sus maanas yendo al trabajo con msica en el coche.
Ahora bien, es en los niveles intermedios donde el lder es el principal
responsable de cubrir las necesidades de los miembros de su equipo. En
primer lugar, el lder ha de conseguir que su equipo sea, se comporte y
trabaje como un equipo y no simplemente como un grupo de personas.
Esto es, que adems de existir unos enlaces entre ellos profesionalmente
correctos, cada individuo tenga un sentimiento de pertenencia, de formar
parte de algo superior a s mismo. Es un objetivo de conjunto que se puede
conseguir evitando la existencia de aislamientos dentro del equipo, proporcionando una configuracin adecuada del lugar de trabajo, fomentando
la participacin de todos los miembros del equipo en las discusiones de
equipo, valorando las contribuciones que cada uno de los miembros y eliminando la existencia de clanes dentro del equipo.
Una vez el objetivo de pertenencia se ha cumplido, el lder ha de conseguir que cada miembro de su equipo se sienta reconocido, es decir, que
sienta que su trabajo aade valor al proyecto, que hace que el proyecto
funcione y, por tanto, que el proyecto podra verse afectado sin su contribucin. Es un objetivo individual y de conjunto: el reconocimiento personal
dentro de un equipo. Esto se puede conseguir reconociendo en privado las
aportaciones del individuo, fomentando tambin dicho reconocimiento en
pblico dentro del equipo y hacia arriba (con los superiores) y aceptando e implementando propuestas de los miembros del equipo. Por ltimo,
el reconocimiento horizontal de las aportaciones del individuo, esto es, el
reconocimiento, ya sea pblico o privado, que nace de los propios compaeros del equipo y no del lder, supone un nivel superior en el liderazgo
del equipo, ya que los seguidores tambin asumen roles de liderazgo para
fomentar la cohesin del equipo.
Por supuesto, estas reglas no implican que todas las aportaciones deban
ser difundidas, sino que todas deben existir y es el lder quien ha de elegir
cules se han de difundir, a quin y cundo hacerlo.
4.2. Los tipos de personalidad
En cuanto a las personalidades, es importante contar con un mtodo
de clasificacin que pueda tanto dar una idea de cmo es cada persona,
270
como permitir una comparativa entre los distintos miembros de un equipo.

Una de estas herramientas altamente extendida es el Indicador de Tipos de
Myers-Briggs (MBTI-Myers-Briggs Type Indicator) [Hirsh, Hirsh, and Krebs
Hirsh, 2003]. Bsicamente el MBTI clasifica al individuo como una combinacin de los siguientes parmetros:
t &YUSPWFSUJEPWTJOUSPWFSUJEP &*&YUSPWFSU*OUSPWFSU
RVFNJEFDNP
se enfoca la energa.
t 4FOTPSJBMWTJOUVJUJWP 4/4FOTJOH*OUVJUJPO
RVFNJEFDNPTFQFScibe la informacin.
t 3BDJPOBM WT FNPDJPOBM 5'5IJOLJOH'FFMJOH
RVF NJEF DNP TF
toman decisiones.
t +V[HBS WT QFSDJCJS +1+VEHJOH1FSDFJWJOH
RVF NJEF MB GPSNB EF
vivir.
Aunque la clasificacin tipo MBTI es de las ms extendidas, el mismo
modelo se puede utilizar con otros pares de indicadores como tradicional
vs no tradicional, dominante vs sumiso, progresivo vs conservador o abierto
vs defensivo, a discrecin del analista [Owen, 2009]. En cualquier caso, no
hay un tipo de personalidad mejor que otra, sino que todas tienen aspectos
positivos y negativos, tal y como se muestra en la tabla 11.2, y por tanto, lo
que interesa es su adecuacin a los objetivos a cumplir.
Tipo
E
I
S
N
T
F
J
P
Aspectos positivos
Aspectos negativos
Imprudente a la hora de hablar, no
Distribuye energa y entusiasmo.
incluye a otra gente.
A menudo tiene la sensacin de
Razonado, da espacio a otros.
que no tiene nada interesante que
decir; mal relaciones pblicas.
Prctico, concreto, detallado.
No imaginativo.
Creativo, imaginativo.
Imprctico, irrealista, soador.
Lgico, racional, intelectual.
Fro, sin corazn.
Emptico, entendedor.
Complejo, distrado.
Alta tica laboral, centrado y
Inexible, rgido.
able.
Disfruta del trabajo, balance
Vago, catico, no able, sin
vida-trabajo.
objetivos.
Tabla 11.2. Diferencias entre los tipos de personalidad segn MBTI.
Los cuatro indicadores no se miden de forma dicotmica como todo o

nada, sino que toda persona por norma general se encuentra en algn pun-
271
to intermedio, es decir, todos tenemos de todo en mayor o menor medida.

As, no se trata de decir si alguien es extrovertido o introvertido, sino ms
bien el nivel relativo de extroversin e introversin que posee con respecto
al equipo. Adems, es posible desarrollar en cierta medida cada cualidad
o atributo [Katz, 1974]. Al aumentar el espectro de comportamientos, una
persona tendra mayor facilidad para adaptarse a una variedad ms amplia
de equipos, incluso modificar su comportamiento segn sus objetivos personales en un determinado equipo. Para ello, la utilizacin del siguiente
tipo de grfico resulta muy conveniente, ya que tambin permite comparar
cualitativamente distintas personas.
Figura 11.4. Brjula de personalidad segn MBTI [Owen, 2009].
272
Una de las aplicaciones ms interesantes de estos anlisis es la toma

de decisiones, pues atendiendo a la personalidad de cada individuo en el
equipo se puede optimizar su contribucin a la decisin y, por tanto, maximizar la calidad de sta [Huitt, 1992]. Por ejemplo, siendo conscientes de
que personas introvertidas pueden no participar activamente en reuniones
en las que se necesiten ideas, el lder puede decidir mantener una reunin
personal previa con cada uno de dichos miembros para obtener ideas que
l pueda inyectar durante la reunin con el resto del grupo, mitigando el
riesgo de que buenas ideas queden ocultas. De la misma forma, este tipo
de indicadores proporciona informacin valiosa para conseguir realizar una
comunicacin efectiva [Berney, 2010]. Tambin permite aumentar las probabilidades de xito en negociaciones, ya que facilita saber las fortalezas y
debilidades de la otra parte [Brown y Chadwick, 1986]. Por ltimo, como
se ha introducido anteriormente, los indicadores se pueden utilizar como
base para crear equipos que aumenten la efectividad y eficiencia de tareas
en un proyecto que se beneficiaran de perfiles especficos, como podran
ser por ejemplo fases conceptuales donde primara la creatividad o fases de
produccin donde se necesitase introspeccin y cuidado del detalle.
4.3. Las cualidades del lder
Para ser positivo, profesional y centrado en las personas, los lderes cuentan con y desarrollan una serie de cualidades que les ayudan a erigirse como
lderes. Es importante para el gestor de proyectos saber detectarlas, pero es
necesario mencionar que los lderes no poseen todas ellas, sino un conjunto
de ellas, desarrolladas en mayor o menor medida. Aunque no existe una ley
que gobierne dichas cualidades, [Maxwell, 1999] propone una lista indispensable de ellas obtenida tras el estudio de un nmero considerable de lderes
reconocidos, algunas de las cuales se muestran en la tabla 11.3 en relacin
con las tres dimensiones del liderazgo. Se ha de recordar, que conocer estas
cualidades no hace mejor lder, slo ayuda a identificar a un lder.
Centrado en personas
Generoso
Escucha
Comunicativo
Carisma
Bueno en las relaciones
personales
Profesional
Competente
Resolutivo, seguro
Centrado
Solucionador de problemas
Responsable, disciplinado
Aprendizaje constante
Positivo
Resolutivo, seguro
Coraje
Con iniciativa
Pasin
Solucionador de
problemas
Visin
Tabla 11.3. Cualidades del lder.
273
5. GENERACIN Y GESTIN DE LA CONFIANZA

Como se ha descrito a lo largo de este captulo, la confianza es una
premisa bsica para que el lder pueda ser aceptado como tal. Por ello, es
fundamental que el lder domine el arte de la confianza. En liderazgo, la
confianza debe ser gestionada desde tres perspectivas: la generacin de
confianza, es decir, cmo conseguir que sus seguidores confen en el lder;
su mantenimiento a lo largo del tiempo; y la confianza recproca en sus
seguidores y cmo stos la perciben.
Figura 11.5. Pilares de la confianza.
Contrariamente a lo que se cree, la confianza en el contexto de un

proyecto no se genera mediante la seguridad que desprende uno mismo
o su lenguaje corporal. Si bien es cierto que estos elementos ayudan en la
velocidad con que sta se genera (y esto es bueno para ventas, firmas de
contratos, negociaciones, etc.), no son generadores de confianza para relaciones a largo plazo, como las existentes en los equipos de un proyecto.
La confianza se genera principalmente demostrando: el lder cumple con lo
274
promete, se comporta como dice y predica con el ejemplo, independientemente del tipo de lder que se sea. Una vez conseguida, el lder ha de
mantener la confianza depositada en l. Ntese que cuesta mucho menos
perder la confianza en alguien que gestarla. En esencia, existen tres leyes
fundamentales que son necesarias para mantener la confianza. La primera
es no faltar a los valores. Los principios marcados en el equipo son inquebrantables. Respetar los valores y principios muestra al lder como una
persona coherente e ntegra, cualidades necesarias para la aceptacin como
lder. La segunda es no fallar a los subordinados. El lder ha de cumplir su
palabra y anteponer el beneficio de sus subordinados al suyo propio. La
tercera y ltima es reconocer los fallos con humildad. El fallo humaniza al
lder y su reconocimiento le solidariza con el equipo.
Ahora bien, la confianza ha de ser recproca y, por tanto, el lder no slo
debe confiar en sus seguidores, sino que debe hacerles saber que tienen
la suya. Actitudes que permiten a los seguidores reconocer y sentir que se
confa en ellos incluyen dejarles hacer las cosas a su manera (siempre y
cuando no influyan negativamente en los objetivos comunes del equipo),
evaluando resultados en vez de prejuzgando planes, dando libertad en el
trabajo, es decir, no controlando detalladamente ni al minuto, respetando la
profesionalidad, esto es, no poniendo en duda las opiniones en los campos
en que son expertos y, por ltimo, defendiendo sus puntos de vista fuera
del equipo.
6. INFLUENCIA Y PERSUASIN
Como se ha presentado en la seccin 2 el lder influye y persuade por
definicin. La influencia y persuasin se realizan en dos direcciones. Hacia
abajo, el lder debe conseguir que sus seguidores vayan en la direccin que
el proyecto necesita. Hacia arriba, el lder ha de luchar por sus seguidores
para conseguir que sus superiores acepten las ideas de sus seguidores.
Ahora bien, influir y persuadir no es sinnimo de mandar. Por tanto, el lder
no pide o exige a sus seguidores que hagan algo, sino que toca las teclas
necesarias para que stos lo hagan pensando que es su propia decisin. As,
la influencia y la persuasin se basan en tres actitudes bsicas segn [Borg,
2007]. En primer lugar, es obligatorio ser sincero y emptico, pues se ha de
conseguir en primer lugar que los seguidores se abran al lder. En segundo
lugar, es necesario recabar toda la informacin posible sobre los seguidores, de manera que se sepa qu teclas hay que tocar en cada momento. Por
ltimo, conviene utilizar una comunicacin abierta y conciliadora, con el fin
de ofrecer soluciones y evitar reacciones defensivas o inmviles.
275
7. COMUNICACIN EN EL PROYECTO Y EN EL EQUIPO

En este captulo se abarca la comunicacin en el proyecto desde el
punto de vista del intercambio de informacin entre los miembros de un
equipo. El objetivo es, por consiguiente, dar las pautas a seguir para conseguir una comunicacin efectiva tanto en un equipo de trabajo como en
un proyecto. Es fundamental que el gestor de proyectos conozca cmo se
realiza la comunicacin, de qu canales y medios dispone tanto para transmitir mensajes como para recibirlos, y cmo se define una buena estrategia.
En definitiva, se trata de proporcionar al gestor de proyectos las herramientas adecuadas para que realice una buena gestin de la comunicacin en
su proyecto. Adems, tal y como se ha visto en los puntos anteriores, la
comunicacin es un aspecto clave del liderazgo. El lder ha de mandar los
mensajes adecuados, saber captar la informacin necesaria, distribuir cierta
informacin en el momento adecuado a las personas adecuadas, etc.
Es pertinente por tanto, comenzar por explicar cmo se realiza la comunicacin. sta requiere siempre de dos o ms personas para llevarse a
cabo y consiste en intercambiar informacin entre las mismas. La figura
11.6 muestra los diferentes elementos que participan en dicho intercambio
[Shannon y Weaver, 1949; Lazega, 1992; White y Chapman, 1996].
Figura 11.6. Elementos bsicos de la comunicacin.
7.1. Los elementos bsicos de la comunicacin

Los elementos bsicos de la comunicacin se describen a continuacin.
a) Mensaje: el mensaje es la razn de ser de la comunicacin. Es la informacin que el emisor desea transmitir al receptor. Es importante
276
que el mensaje sea consistente y coherente. El gestor de proyectos

ha de evitar, en la medida de lo posible, la existencia de mensajes
contradictorios, pues esto puede resultar en desconfianza y desmotivacin, as como provocar retrasos en los plazos, problemas en
el diseo o un incremento en los costes. Debido a la existencia de
elementos de comunicacin entre emisor y receptor se distingue
entre mensaje transmitido, aqul que el emisor tiene intencin de
transmitir, y mensaje recibido, aqul que el receptor entiende al
recibirlo.
b) Emisor: es el elemento que transmite la informacin. ste puede ser
una o varias personas. En el caso de ser varias, el gestor de proyectos
ha de asegurar el acuerdo en el mensaje, como se ha discutido anteriormente.
c) Receptor: es el elemento que recibe la informacin. ste puede ser
una o varias personas. La recepcin del mensaje puede ser de dos
tipos:
1) Conjunta: cuando todos los receptores reciben el mensaje al mismo tiempo (discurso) y compartiendo lugar. Es ms eficiente, pero
la atencin de los receptores es menor.
2) Aislada: cuando los receptores reciben el mensaje por separado.
Es menos eficiente, pero la atencin de los receptores es mayor.
Ejemplos: telfono, correo electrnico personalizado o reunin
personal.
d) Cdigo: es la manera en que se expresa un mensaje. Es vital para que
receptor y emisor entiendan la informacin de la misma manera, es
decir, para que el receptor entienda el mensaje que el emisor intenta
transmitirle. Se compone de cuatro elementos principales:
1) El lenguaje (verbal y no verbal) o idioma. En proyectos internacionales es habitual que al menos emisor o receptor utilicen un
idioma que no es materno, por lo que tanto la gramtica como el
vocabulario estn limitados. Adems, pueden utilizarse palabras
errneamente y malinterpretarse el mensaje. Incluso la diferencia
de culturas conlleva muchas veces a variaciones en los tonos de
voz en que se dialoga e incluso ciertos aspectos del lenguaje no
verbal que no son entendidos de la misma manera entre personas
diferentes, lo que se conoce como componente contextual de un
idioma. Es importante que en este tipo de proyectos los interlocutores mantengan la comunicacin en un tono estndar y objetivo,
evitando as el uso de tcnicas del lenguaje como la indirecta o la
irona.
277
2) Adecuar los tecnicismos: un proyecto se compone de individuos o

equipos con diferentes roles o perfiles. Esto supone normalmente
el uso de tecnicismos que, si bien para un determinado perfil
forman parte de su vocabulario diario, no es as para el resto de
miembros del proyecto. De la misma forma que en el aspecto
anterior, el uso de dichos tecnicismos puede dar como resultado
la imposibilidad de entender el mensaje completamente y puede
llevar a frustracin por falta de consenso e impactos negativos
en plazos y costes. As, es importante que los miembros de un
equipo aprendan a comunicarse entre las distintas disciplinas:
tcnicos con gestores, gestores con abogados, ventas con ingenieros, etc.
3) Perseguir los mismos objetivos: en un proyecto gran parte de la
comunicacin est orientada a la toma de decisiones multidisciplinares. Por norma general, cada grupo de trabajo posee una
visin limitada del proyecto y, por esto, considera sus propios
objetivos como aqullos de mayor importancia o los que el
proyecto debera cumplir. Por tanto, ya que compartir los objetivos es una premisa bsica para una correcta toma de decisiones, es responsabilidad del gestor de proyectos conseguir que
los miembros del proyecto realicen su trabajo con los mismos
objetivos en mente.
4) Compartir la visin: en un proyecto o empresa, si los objetivos
son importantes, la visin es la piedra fundamental en que stos
se sustentan. Por consiguiente, el gestor de proyectos ha de conseguir mantener en todo momento a los miembros del proyecto
alineados con la visin del proyecto, empresa o equipo.
e) Canal: es el medio por el que se transmite la informacin. Es uno de
los elementos que ms afecta a la efectividad de la comunicacin,
ya que se comporta como un filtro y, por tanto, siempre introduce
prdidas o variaciones en el mensaje y puede estar sujeto a trfico
y latencia. La efectividad del canal de comunicacin est altamente
relacionada con el cdigo, ya que cuanto ms rico es el cdigo empleado o necesario para entender el mensaje, mayor ancho de banda
ha de tener el canal, es decir, ms insensible ha de ser a aspectos no
verbales de la comunicacin. Adems, el tiempo y forma de entrega
del mensaje afectan a la percepcin y atencin del receptor, lo que
puede disminuir la efectividad de la comunicacin si las caractersticas del canal no se ajustan a dichos objetivos. Los aspectos ms importantes de los canales ms comunes se explican en la seccin 9.1.
278
f) Ruido: el ruido es todo aquello que afecta a la fidelidad de la informacin que se transmite, tanto al contenido en s mismo, como a la
intencin. Las fuentes de ruido se encuentran en todos los elementos
de la comunicacin:
1) Emisor: por ejemplo, si el emisor olvida parte del mensaje que
quiere transmitir o no es capaz de articular lo que quiere transmitir.
2) Mensaje: por ejemplo, si se aaden elementos innecesarios a la
informacin y la hacen confusa, o carece de elementos necesarios
para su completo entendimiento.
3) Receptor: por ejemplo, si el receptor no est atento al mensaje o
simplemente no lo recibe.
4) Cdigo: por ejemplo, si el emisor no es capaz de transmitir la intencionalidad deseada o el receptor no es capaz de captarla debido a problemas con el idioma o falta de habilidades personales o
sociales, si el receptor recibe el mensaje modificado por prejuicios
propios (por ejemplo, no cree en las directrices de su empresa
por falta de confianza), o si el uso de tecnicismos emborrona el
objetivo del mensaje.
5) Canal: debido a no elegir el medio de comunicacin adecuado,
por ejemplo, un correo electrnico enviado en masa cuando se
busca la reaccin de cada individuo.
g) Realimentacin: en una buena comunicacin no es suficiente con
entregar el mensaje, sino que el emisor debe asegurarse de que su
mensaje ha sido correctamente recibido y entendido por el receptor.
8. DIMENSIONES DE LA COMUNICACIN: DIRECCIN Y FORMALIDAD

La comunicacin en el proyecto se realiza en dos dimensiones: una en
base a la direccin de la comunicacin y la otra en base a la adecuacin
con respecto a la estructura jerrquica del proyecto. La informacin puede
transferirse en tres direcciones, segn muestra la figura 11.7.
279
Figura 11.7. Direccin de la informacin.
La comunicacin vertical es aquella que fluye entre distintos niveles

de la organizacin. sta puede ser descendente, cuando la informacin se
pasa de directivos a mandos intermedios y de stos a sus subordinados; o
ascendente, cuando la informacin se da en sentido contrario. Existen dos
riesgos principalmente, en relacin con la cantidad de niveles jerrquicos
en el proyecto: (1) en sentido descendente el mensaje se distorsiona o
incluso no llega, lo que se podra detectar mediante un uso efectivo de la
realimentacin; y (2) en sentido ascendente no funciona y los gestores pierden la nocin de la realidad en el proyecto.
La comunicacin horizontal es aquella que fluye entre miembros de un
mismo nivel jerrquico, por ejemplo entre los miembros de un equipo. Presenta principalmente un riesgo: la informacin queda aislada si el equipo
no comparte resultados o no solicita informacin de otros niveles jerrquicos o reas.
La comunicacin diagonal o transversal es aquella que fluye entre distintas reas y niveles al mismo tiempo. Existen casos en los que es conveniente, como para toma rpida de decisiones, aunque hay que tener en
cuenta que este tipo de comunicacin genera caos y por tanto presenta
riesgos sobre la validez de la informacin intercambiada, ya que no est
sujeta a filtros de mandos superiores. Un tipo especial de esta comunicacin
es la lateral, emergente en proyectos de organizacin plana, en la que la
comunicacin se realiza al mismo nivel jerrquico pero entre personas que
pertenecen a distintos grupos.
280
En cualquier direccin en que se realice la comunicacin, sta puede

hacerse de modo oficial (formal) o como conversacin de pasillo (informal). La comunicacin formal se realiza segn los patrones y protocolos
establecidos por el proyecto y est siempre debidamente documentada. La
informacin transmitida de esta manera debe considerarse oficial, ya sea
verdica o supuesta (cuando su veracidad no se pueda contrastar), que no
falsa. La comunicacin informal surge espontneamente entre los miembros
del proyecto y no est sujeta a ninguna estructura jerrquica. La informacin transmitida no est necesariamente documentada, aunque en ningn
caso est controlada, y es siempre no vinculante. La veracidad puede encontrarse en extremos opuestos, pudiendo representar fidedignamente las
opiniones de los emisores o, por el contrario, ser informaciones infundadas
por rumores.
En todo proyecto, ambos tipos de comunicacin coexisten siempre.
Ahora bien, el objetivo no es eliminar o limitar la comunicacin informal,
sino saber utilizarla adecuadamente para el beneficio del proyecto. Es por
tanto importante no caer en el error de asociar formal con bueno e informal con malo. Ms bien todo lo contrario. La comunicacin formal puede
convertirse en un monstruo burocrtico que limite la creatividad del equipo
o que ralentice considerablemente la toma de decisiones. Por su parte, la
comunicacin informal, utilizada y seguida concienzudamente, puede ser
una herramienta a favor del gestor de proyecto para contribuir al xito del
mismo.
La importancia de la comunicacin formal crece directamente con el
tamao del proyecto. Es importante para controlar la informacin que deben utilizar distintos equipos en el proyecto, as como para disponer de
justificacin formal en asuntos de ndole vinculante. Sin embargo, el uso de
la comunicacin formal debe estar limitado para que sta se mantenga eficiente. El gestor debe asegurar que la comunicacin formal aade valor al
proyecto en todo momento y no acta nicamente como una herramienta
puramente burocrtica. Situaciones en las que este tipo de comunicacin
es recomendable incluyen acuerdos legales o econmicos, decisiones de
diseo que involucran a varios equipos de trabajo, convocatorias y minutas
de reuniones o informacin oficial del proyecto como puedan ser plazos o
riesgos.
La comunicacin informal refleja la realidad que viven los miembros
del proyecto. Como este tipo de comunicacin no necesita de mecanismos
oficiales de documentacin y control, es particularmente interesante para
resolucin de problemas que necesitan creatividad o contundencia, pues
permite una interaccin altamente eficiente entre los miembros del proyecto, as como para la toma rpida de decisiones. Adems, el gestor de proyectos debe utilizar esta informacin para varios fines. Como emisor, para
281
generar confianza. Como receptor, para conocer qu ocurre realmente en

su proyecto, con el objetivo principal de detectar riesgos y oportunidades
emergentes, para conocer las aspiraciones con respecto al proyecto de los
miembros del proyecto, sus problemas, sus necesidades, etc., y para recibir
informacin filtrada por mandos intermedios.
9. USO EFECTIVO DE LOS CANALES DE COMUNICACIN

9.1. Los canales de comunicacin
Como se ha descrito anteriormente los canales de comunicacin se utilizan principalmente para repartir y recabar informacin del proyecto. El
lder, adems, los utiliza para motivar, acercarse a sus seguidores, influir,
generar confianza y recabar informacin que no pertenece de forma explcita al proyecto, pero que puede afectarle. Es decir, la diferencia del uso
que un lder hace de los canales de comunicacin con respecto a un gestor
es que, mientras el gestor los utiliza para intercambiar informacin sobre el
proyecto, el lder los utiliza para influir en el proyecto en un sentido amplio.
A continuacin, se proporcionan consejos para el uso efectivo de los canales de comunicacin ms utilizados principalmente en la actualidad.
a) Carta: se recomienda su utilizacin cuando se desea personalizar la
informacin o enfatizar la importancia del mensaje a transmitir.
b) Fax: actualmente el fax se utiliza nicamente como soporte legal, que
evidencia la informacin intercambiada en una comunicacin. Sin
embargo, su uso y archivo es bastante engorroso y por tanto se recomienda sustituirlo por el correo electrnico. En este caso, se debe
acordar previamente de forma oficial la validez del correo electrnico
como documento legal y proveerlo de elementos de fiabilidad como
la firma electrnica, confirmacin de recepcin, etc.
c) Correo electrnico: el correo electrnico es probablemente el medio
de comunicacin ms utilizado, a da de hoy, en los proyectos de
ingeniera. Sin embargo, su coste prcticamente inexistente, as como
su facilidad de uso, han trivializado su utilizacin, haciendo que en la
actualidad su efectividad est bastante limitada con respecto a su potencial. El correo electrnico se puede utilizar, bien como sustitucin
del fax y la carta en tono formal, o bien como medio de intercambio
de informacin en un tono ms informal. Es una buena herramienta
para la organizacin de reuniones y distribucin de notas o minutas,
as como para solicitar y recoger informacin. No se debe utilizar en
cambio para debatir o sustituir conversaciones, ya sean formales o de
282
d)
e)
f)
g)
pasillo, pues para ello el telfono, el chat o las redes sociales resultan
ms efectivos.
El aspecto clave para un uso efectivo del correo electrnico es que
todos los miembros de un proyecto adopten las mismas reglas de uso
y sigan procesos de organizacin similares. El gestor de proyectos
debe responsabilizarse de fijar y formalizar dichas reglas y procesos
mediante el Plan de Comunicacin, as como realizar el seguimiento
de su puesta en prctica. Algunas recomendaciones de buen uso
incluyen el limitar nmero de destinatarios, utilizar tipologa de destinatarios y mantener una bandeja de entrada y un archivo limpios.
Telfono: el uso del telfono disminuye actualmente en favor del
correo electrnico, ya que este ltimo permite la comunicacin asncrona y no requiere la disponibilidad inmediata del receptor para
enviar el mensaje. Ahora bien, el telfono sigue siendo un canal importante para la comunicacin en el proyecto y se recomienda su uso
cuando se necesita una confirmacin de la recepcin de informacin
inmediata y cuando sea necesario mantener una discusin sobre un
tema. En cualquier caso, es recomendable que el emisor documente
los puntos discutidos, por ejemplo mediante un correo electrnico,
para poder asegurar trazabilidad si fuera necesario o evitar repetir
discusiones en el futuro.
Teleconferencia: consiste en una reunin de tres o ms personas
por telfono, por tanto las recomendaciones para la efectividad en
reuniones tambin son vlidas en este caso. Eso s, debido a la particularidad del uso del telfono y la falta de contacto visual es imprescindible respetar los turnos de palabra y seguir estrictamente la
agenda acordada.
Videoconferencia: es una reunin virtual que hace uso de herramientas de telecomunicaciones como el telfono, el vdeo e Internet.
Es particularmente interesante para ahorrar costes de viaje y en casos
en los que fuera necesario discutir material audiovisual o escrito,
donde la teleconferencia no sera efectiva.
Reunin: en la mayor parte de ocasiones se abusa de la reunin, utilizndola simplemente para difundir informacin. Esto es altamente
ineficaz, pues o bien no todo el mundo est en la reunin, o bien
la informacin intercambiada no queda documentada. Por tanto, la
reunin siempre ha de realizarse cuando haya objetivos claros para
la misma. Siempre ha de constar de una invitacin y de una agenda,
as como de acciones y notas que resuman lo discutido. Adems, es
preciso realizar un seguimiento de la misma para asegurar que las
acciones se cierran.
283
h) Reunin personal: la reunin personal es aquella que se realiza entre

dos personas. sta puede ser formal e informal, pero es siempre de
carcter ntimo, lo que puede llevar a las personas a expresarse ms
abiertamente. Es por ello, que este tipo de reunin se recomienda
para extraer informacin de personas introvertidas, para otorgar seriedad o confidencialidad al encuentro, o para asegurarse de que el
mensaje llega correctamente.
i) Chat: el chat es una alternativa al correo electrnico y al telfono
que se utiliza para comunicaciones cortas o que no necesitan en
principio ser documentadas, si bien el chat ofrece esta posibilidad.
El objetivo final del chat es evitar el uso masivo del correo electrnico, proporcionando, al mismo tiempo, una alternativa asncrona
al telfono.
j) Red social: todava casi no utilizado en la empresa, pero muy til
para informacin punto-multipunto y efectivo para priorizar la informacin que se desea recibir. Permiten una comunicacin muy efectiva para informaciones como viajes, disponibilidad, publicacin de
documentos, asistencia a seminarios, reuniones de carcter general,
etc. El funcionamiento bsico consta de tres pasos:
1) El proyecto o la empresa establece las diferentes categoras de
informacin a utilizar, as como las reglas que deben cumplir.
2) Cada individuo es responsable de publicar su informacin, siempre y cuando tenga importancia para el proyecto, asocindola a
una o varias de las categoras prestablecidas.
3) Cada individuo se suscribe a las personas o categoras que son de
su inters.
9.2. El plan de comunicacin
Para extender un uso efectivo de los canales de comunicacin entre los
miembros de un equipo es recomendable trazar un plan de comunicacin
al que todos los miembros del proyecto se adhieran. En l se establecen los
canales de comunicacin oficiales, sus usos y las reglas de comunicacin,
es decir, se establece la normativa de la comunicacin formal. El plan ha de
estar listo al inicio del proyecto, evitando as vicios que seran difciles de
corregir una vez el proyecto est en marcha. Dicho plan podra estructurarse con la informacin siguiente:
1.
2.
3.
4.
Introduccin.
Documentos aplicables y de referencia.
Elementos externos al proyecto.
Organizacin interna del proyecto.
284
5. Normas para la comunicacin externa.

6. Canales de comunicacin internos.
a. Comunicacin formal.
b. Reglas de comunicacin segn la direccin.
c. Lista de canales y sus usos.
7. Uso de tecnicismos.
8. Otros canales especficos (planificaciones, anlisis, etc.).
10. GESTIN DE LA COMUNICACIN EXTERNA

En un proyecto existen principalmente tres interlocutores externos (figura 11.8): el cliente, el pblico y la empresa.
Figura 11.8. Comunicacin externa.
Aunque la comunicacin externa no influye directamente en los miembros de un proyecto, s que les afecta, ya que mensajes contradictorios
entre la comunicacin interna (proyecto) y la externa pueden llevar a
prdida de confianza y mensajes irreales al exterior pueden resultar en
compromisos no realizables para el proyecto. Es, por tanto, responsabilidad del gestor de proyecto controlar que la comunicacin externa se
285
realice conforme a normas prestablecidas con el objetivo de evitar o paliar

los efectos descritos anteriormente. As, toda informacin relevante que
vaya a fluir al exterior ha de compartirse primero con los miembros del
proyecto, lo que ayuda a reforzar la confianza entre los distintos niveles
del mismo.
Por ltimo, es importante tener en cuenta que el proyecto puede trabajar
con informacin que cuenta con prohibicin formal de ser distribuida fuera
de ciertas normas, como puede ser la informacin confidencial (aquella que
puede afectar a la competitividad de la empresa y, por tanto, est reglamentada por la misma empresa) o la informacin clasificada (aquella que puede
afectar a la seguridad de un pas y, por tanto, est regulada por las leyes
del pas). Cuando se maneje informacin confidencial o clasificada, es recomendable contar con personal especializado en dichas reas que puedan
establecer los mecanismos adecuados para trabajar con dicha informacin,
controlar su flujo de comunicacin y formar a los miembros del equipo en
el manejo de dicho tipo de informacin.
11. REFERENCIAS
BENNIS, W., On Becoming a Leader, New York: Basic Books.
BERNEY, L., Using the Myers-Briggs Type Indicator to enhance workplace communication, The Stepping Stone, July 2010, Issue 39, pp. 18-19.
BORG, J., Persuasion. The art of influencing people, 2nd edition, Harlow, Reino Unido: Pearson Education Limited, 2007.
BROWN, A. R. y CHADWICK, G. S., Using psychological type to enhance negotiation
skills, Developments in Business Simulation & Experiential Exercises, Volume
13, 1986, pp. 39-42.
GENTRY, W., DEAL, J. J., STAWISKI, S. y RUDERMAN, M., Are leaders born or made?,
Perspectives from the Executive Suite, QuickView Leadership Series, Center for
Creative Leadership, Marzo 2012.
GOLEMAN, D., Leadership that gets results, Harvard Business Review, 10 de marzo
de 2000.
GOODNIGHT, R., Laissez-Faire Leadership, Encyclopedia of Leadership, 2004. SAGE
Publications.
HIRSH, E., HIRSH, K. W. y HIRSH, S. K., Introduction to Type and Teams, 2nd Edition,
Mountain View, California, EEUU: CPP, Inc., 2003.
HUITT, W., Problem solving and decision making: Consideration of individual differences using the Myers-Briggs Type Indicator, Journal of Psychological Type,
24, pp. 33-44, 1992.
KATZ, L., Skills of an effective administrator, HBR Classic, September-October 1974,
Number 745009, pp. 23-35.
KOTTER, J. P., A Force for Change: How Leadership Differs from Management (New
York: Free Press, 1990), 124-125.
286
LAZEGA, E., The micropolitics of knowledge-Communication and indirect control in

workgroups, New York: Aldine de Gruyter, 1992.
MASLOW, A. H., A theory of human motivation, Psychological Review, 1943, Vol.
50 4, pp. 370-396.
MAXWELL, J. C., The 21 indispensable qualities of a leader, Nashville, Tennessee,
EEUU: Thomas Nelson, Inc., 1999.
OWEN, J., How to lead, 2nd edition, Harlow, Reino Unido: Pearson Education Limited, 2009.
REAL ACADEMIA DE LA LENGUA ESPAOLA, <http://www.rae.es>, accedido el 15 de
abril de 2013.
SHANNON, C. E. y WEAVER, W., The mathematical theory of communication, Urbana,
IL: University of Illinois Press, 1949.
WHITE, K.W. y CHAPMAN, E. N., Organizational communication - An introduction
to communication and human relations strategies, Needham Heights, MA: Simon and Schuster Custom Publishing, 1996.
287
CAPTULO 12
SISTEMAS DE CLASIFICACIN DE PROYECTOS

1. INTRODUCCIN
Todos los proyectos comparten ciertas caractersticas comunes, como la
existencia de unos objetivos de prestaciones tcnicas, a ser alcanzados en
un determinado plazo y a un determinado coste; no obstante, no todos los
proyectos son iguales y por lo tanto no todos deben ser gestionados de la
misma manera. Las caractersticas necesarias del jefe de proyecto diferirn
de unos tipos de proyectos a otros y personas que puedan ser eficaces gestores de determinados proyectos no tendrn por qu serlo necesariamente
de otros. La identificacin de las caractersticas diferenciales de un proyecto
permitir adecuar tanto la estructura de gestin como la seleccin de la persona encargada de su gestin y de su equipo de trabajo para asegurar que
es gestionado con la mxima eficacia y eficiencia, lo que ayudar a alcanzar
en tiempo y forma los objetivos del cliente.
En concreto, los objetivos de este captulo son:
t $POPDFSMBUJQPMPHBEFQSPZFDUPTZ FOQBSUJDVMBS DNPQVFEFODMBsificarse.
t $POPDFS MBT JNQMJDBDJPOFT RVF FO MB HFTUJO EF QSPZFDUPT UJFOF MB
clasificacin de un proyecto.
289
2. CLASIFICACIN
DE PROYECTOS SEGN LA NATURALEZA Y EL OBJETO DEL
PROYECTO
La clasificacin ms sencilla y convencional es la que divide los proyectos segn la naturaleza de su objeto. En unos proyectos es ms fcil que en
otros definir el objetivo y especificar los requisitos que deben cumplirse,
junto con los mtodos que se emplearn para su verificacin. Tambin diferir de unos casos a otros el grado de coincidencia con proyectos anteriores
de similar naturaleza. La medida en la que el jefe de proyecto deba tener
conocimientos tcnicos especficos, capacidad de organizacin, habilidades
sociales y capacidad de comunicacin, entre otros, depender del tipo de
proyecto a ser gestionado. La mayora de los proyectos podrn encuadrarse
en alguno de los siguientes tipos:
a) Proyectos de obra civil. Estos son los proyectos de construccin de
infraestructuras, como puentes, tneles, edificios, presas, lneas de
ferrocarril, aeropuertos, etc. Cada uno tendr sus propios requisitos
y en ciertos aspectos ser diferente al resto de obras similares que se
hayan realizado, pero habr otros muchos aspectos en los que s sea
similar a ellos. La definicin del objetivo del proyecto es relativamente
sencilla y pueden definirse con precisin los requisitos a ser satisfechos
y la manera en la que sern verificados. Esa similitud con obras anteriores facilita la elaboracin de las estimaciones de tiempos y recursos
requeridos por las tareas, que podrn realizarse por mtodos paramtricos o por analoga con otras obras similares. Es deseable que
el jefe de proyecto tenga conocimiento de la normativa y legislacin
aplicable, aunque debe ser ante todo un buen organizador.
b) Proyectos de investigacin y desarrollo. En estos proyectos es muy
difcil, por su naturaleza, definir con exactitud el alcance del proyecto
y establecer los requisitos. Cualquier actividad de investigacin supone desarrollar algo nuevo, por lo que no siempre puede anticiparse
qu prestaciones ser posible alcanzar, qu madurez alcanzarn las
tecnologas requeridas, qu tiempo y coste implicarn, etc. En este
tipo de proyectos ms que en ningn otro se convive con la incertidumbre. Por ello es esencial que el jefe de proyecto tenga elevadas
competencias tcnicas en el mbito de ejecucin del proyecto y que
sepa gestionar bien la incertidumbre.
c) Proyectos de industrializacin y/o fabricacin en serie. Con frecuencia
los diseos y desarrollos acaban materializndose en producciones
en serie. Para ello las empresas deben primero desarrollar y poner a
punto los medios necesarios, tales como lneas de montaje, instalaciones de prueba, herramientas y tiles especiales, procedimientos,
290
cursos de formacin de operadores, etc. En proyectos de esta naturaleza lo deseable es que el jefe de proyecto tenga, ante todo, grandes
capacidades de organizacin.
d) Proyectos de consultora. Estos son proyectos en los que lo que se
le entrega al cliente no es un producto o sistema, sino una serie de
recomendaciones. El contratista asesora al cliente en las labores encomendadas y, fruto de su experiencia y de los anlisis y estudios
que realice, le recomienda al cliente las acciones a tomar. En estos
proyectos la definicin del objetivo y del alcance suelen ser complejos, porque es mucho ms difcil concretar cmo ha de ser el producto entregable (las recomendaciones). Preguntas como: cuntas
recomendaciones?, cmo de elaboradas o detalladas? o ? son tan
fciles de entender como difciles de responder. El jefe de proyecto
deber ser capaz de percibir la importancia del estudio de consultora encargado, ms all de los requisitos que se hayan formulado. Si
en cualquier equipo de proyecto el principal activo son las personas
que lo integran, en stos es adems prcticamente el nico activo, lo
que lo convierte en ms importante an. Para gestionar un proyecto
de esta naturaleza es por tanto esencial que el jefe de proyecto tenga
conocimientos tcnicos en el rea objeto del trabajo de consultora y
que tenga muy desarrolladas las habilidades sociales, mostrando gran
capacidad de comunicar y empatizar.
e) Proyectos de diseo y desarrollo de software. Estos proyectos requieren que el jefe de proyecto tenga grandes capacidades de organizacin y ciertos conocimientos del entorno en el que se vaya a
desarrollar la aplicacin.
Los anteriores tipos de proyectos podran adems diferenciarse en funcin de la existencia o no de mltiples clientes o contratistas, de si los
clientes son pblicos o privados, y de si son de la misma nacionalidad
o diferentes. Cuando cliente y contratista son de diferentes pases se habla de proyectos internacionales, tema tratado en el captulo 15. Cuando
existen mltiples clientes de distintas nacionalidades se habla de proyectos multinacionales, tema tratado en el captulo 16. Si en cualquiera de
los tipos mencionados de proyectos el alcance incluye todo lo necesario
para que el cliente pueda comenzar a utilizar directa e inmediatamente
el sistema o producto recibido (por ejemplo incluyendo la formacin de
personal, procedimientos desarrollados, etc.) se dice que es un proyecto
llave en mano.
291
3. CLASIFICACIN DE PROYECTOS SEGN EL MODELO NTCP

Esta seccin refleja el sistema de clasificacin de proyectos NoveltyTechnology-Complexity-Pace (NTCP), o Novedad-Tecnologa-ComplejidadRitmo desarrollado por Aaron Shenhar y Dov Dvir en la primera dcada del
siglo XXI [Dvir et al., 1998; Shenhar et al., 2001; Shenhar et al., 2007] y las
implicaciones de la clasificacin de un proyecto. La primera subseccin expone el modelo de clasificacin propuesto por ambos autores y la segunda
detalla sugerencias de cmo debe tomarse en cuenta la clasificacin realizada en la seleccin del jefe de proyecto, de su equipo y de la estructura
de gestin ms adecuada.
3.1. Sistema NTCP de clasificacin de proyectos
La clasificacin de proyectos segn el sistema NTCP permite identificar
las peculiaridades de cada proyecto y adecuar tanto la eleccin del jefe de
proyecto y su equipo, como la estructura de gestin adecuada para afrontarlo con xito. Para ello se clasifican los proyectos segn cuatro dimensiones, como se muestra en la figura 1: Novelty (Novedad) - Technology
(Tecnologa) - Complexity (Complejidad) - Pace (Ritmo).
Las cuatro dimensiones del sistema NTCP son:
a) Novedad. Esta dimensin se refiere a aspectos como la incertidumbre
en los objetivos del proyecto, la incertidumbre en el mercado, o ambas cosas. Hay proyectos en los que, por su grado de innovacin, no
hay seguridad de cmo responder el mercado; hay otros proyectos
de desarrollo de equipos o servicios en los que, por su naturaleza,
no pueden precisarse con detalle los objetivos desde el principio.
Esta dimensin refleja por tanto el grado de novedad que el proyecto presenta tanto para quienes lo ejecutan como para los posibles
clientes. En esta dimensin los proyectos se clasifican en una de las
siguientes categoras:
Desarrollo. El objeto del proyecto es conocido tanto para el equipo como para el cliente o usuario; en trminos relativos, la inseguridad es baja. Se trata de una evolucin natural o desarrollo de
algo ya conocido.
Plataforma. El objeto del proyecto es en principio conocido tanto
para el equipo como para el cliente o usuario, aunque incorpora elementos o aspectos novedosos que no pueden considerarse
como una simple evolucin natural; en trminos relativos, la inseguridad es media.
292
Figura 12.1. El sistema NTCP de clasificacin de proyectos de Shenhar y Dvir.
293
Innovacin. El objeto del proyecto no es conocido ni para el equipo ni para el cliente o usuario; supone una innovacin o salto
cualitativo frente a lo conocido y tiene por tanto una importante
componente de investigacin y desarrollo. En trminos relativos,
la inseguridad es alta.
b) Tecnologa. Esta dimensin representa el grado de incertidumbre
asociado con las tecnologas necesarias para la ejecucin del proyecto. Puede que algunas de las tecnologas requeridas no hayan
alcanzado an el nivel de madurez necesario, o que no hayan sido
empleadas an por el contratista, o que no hayan sido utilizadas en
un determinado entorno o aplicacin. En esta dimensin los proyectos se clasifican en una de las siguientes categoras:
Tecnologa baja. Todas las tecnologas necesarias tienen el nivel
de madurez adecuado y han sido previamente utilizadas por el
contratista.
Tecnologa media. Todas las tecnologas necesarias tienen el nivel
de madurez adecuado, aunque algunas no hayan sido previamente utilizadas por el contratista.
Tecnologa alta. Alguna de las tecnologas necesarias no tiene todava el nivel de madurez adecuado.
Tecnologa muy alta. Varias de las tecnologas necesarias no tienen todava el nivel de madurez adecuado y se tienen dudas sobre
su rendimiento real al ser aplicadas en el proyecto.
c) Complejidad. Esta tercera dimensin no se refiere a la complejidad
del producto, equipo o servicio a ser desarrollado en el proyecto,
sino a la organizacin necesaria para llevarlo a cabo. Hay desde proyectos de un nico cliente y un nico contratista, a proyectos que
una empresa asume por iniciativa propia, a proyectos con mltiple
clientes y mltiples contratistas, incluso con mltiples entornos (idiomas, legislaciones, culturas, etc.). En esta tercera dimensin los proyectos se clasifican en una de las siguientes categoras:
Conjunto. Slo hay un cliente y un contratista.
Sistema. Puede haber varios contratistas, o varios clientes, normalmente en un mismo entorno.
Sistema de sistemas. Multiplicidad de clientes, contratistas y entornos.
d) Ritmo. Esta cuarta y ltima dimensin representa la necesidad de
terminar el proyecto en unos plazos determinados. En algunos casos
no existe una urgencia especial, tan slo el plazo marcado por el
contratista; en otros puede ser necesario terminarlo lo antes posible
294
por existir competencia en el mercado al que se quiere acceder; y en

otros las circunstancias pueden obligar a actuar con toda urgencia,
sin pasar necesariamente con todo rigor por ciertas fases de la ejecucin del proyecto, En esta dimensin los proyectos se clasifican en
una de las siguientes categoras:
Normal. No existe otra urgencia que el propio plazo fijado por el
contratista.
Rpido/competitivo. Las condiciones del mercado requieren que
el proyecto se complete rpidamente.
Crtico. Pueden existir factores que determinen unas determinadas
fechas como inaplazables (por ejemplo, una ventana de oportunidad para lanzar un satlite, el final de 1999 para resolver el
problema informtico Y2K de transicin al ao 2000, etc.).
Relmpago. Algunas situaciones excepcionales, como las catstrofes naturales, requieren de la ejecucin de un proyecto de manera
expeditiva, incluso obviando aspectos formales de planificacin o
seguimiento.
Hay que evitar la tentacin de considerar que todo proyecto est en los
niveles ms altos en cada una de las cuatro dimensiones. Es necesario saber
clasificar adecuadamente los proyectos segn la taxonoma establecida en
las cuatro dimensiones, para que ello sirva de ayuda a la determinacin de
la adecuada estructura de gestin y a la identificacin de las caractersticas
necesarias del jefe del proyecto y de los miembros de su equipo.
4. IMPLICACIONES DE LA CLASIFICACIN DE PROYECTOS SEGN EL MODELO NTCP

En funcin de cmo se haya clasificado un proyecto en la cuatro dimensiones del modelo NTCP se podrn establecer unas recomendaciones
relativas tanto a las caractersticas deseables del jefe de proyecto como a las
de la estructura u organizacin del proyecto. En las siguientes subsecciones
se detallan esas recomendaciones segn se haya clasificado el proyecto en
cada dimensin. Una vez se haya analizado cada una de las dimensiones
por separado y se hayan elaborado las recomendaciones correspondientes,
ser necesario integrarlas para tener el perfil deseable de la persona adecuada para gestionar el proyecto.
4.1. Novedad
La Novedad de un proyecto se refiere a cmo de novedoso es el producto (o servicio) para el mercado, los clientes, y en cierta medida tambin
295
para el propio equipo del proyecto. La novedad del producto afecta a

aspectos fundamentales del proyecto tanto para empresas que desarrollan
productos que esperan sean aceptados por el mercado, como para clientes
que quieren encargar desarrollos especficos. Entre estos aspectos estn la
fijacin de requisitos para el desarrollo del producto y la estrategia de marketing para su comercializacin.
La clasificacin de un proyecto en la dimensin Novedad tendr implicaciones tanto en la eleccin del jefe de proyecto como en su organizacin.
Hacia el lado derecho del eje (extremo derivada) los objetivos del proyecto sern, en trminos relativos, ms fciles de establecer inicialmente y
ser ms probable que se mantengan sin cambios durante la ejecucin del
proyecto; por el contrario, hacia el extremo de la izquierda (innovacin),
ser mucho ms difcil precisar desde el comienzo los requisitos, y muy
probablemente los requisitos vayan sufriendo cambios significativos a medida que se desarrolla el proyecto y se tiene ms visibilidad y conocimiento
tanto del potencial del producto como de las posibles exigencias o deseos
de los futuros usuarios. No todo el mundo se siente igual de cmodo con
requisitos iniciales algo difusos y cambiantes con el tiempo, y por tanto
personas que sean magnficos gestores de proyectos tipo derivada podran
tener serias dificultades para dirigir un proyecto tipo innovacin.
Los productos denominados derivadas son evoluciones naturales y mejoras de productos existentes. Esas mejoras pueden ser mejoras de prestaciones, reducciones de coste de adquisicin y/o utilizacin, interfaces ms
amigables, etc. El usuario o cliente ya est familiarizado con el producto y
no le cuesta asimilar las caractersticas de la nueva versin. Con productos
de esta naturaleza es fcil establecer sus requisitos, que adems puede
suponerse que permanecern bastante estables durante el desarrollo del
producto.
Consideremos por ejemplo los telfonos mviles de segunda generacin, sin llegar a ser los smartphones. Los primeros telfonos mviles s
representaban una novedad para los usuarios, que hasta ese momento
dependan de lneas fijas. Las subsiguientes generaciones de mviles podan significar terminales ms baratos, con bateras de mayor duracin,
mayores funcionalidades, etc, pero suponan en esencia un producto conocido. Por ello tanto esas segundas generaciones de mviles pueden
considerarse derivadas.
Si la nueva generacin de un producto incorpora cambios importantes
en tecnologa, funcionalidad o algn otro aspecto relevante, estaremos hablando de plataformas. Por ejemplo, la primera generacin de aviones que
emplearon la tecnologa fly-by-wire constituyeron un cambio significativo
para los pilotos, que ya no experimentaban el esfuerzo necesario al actuar
sobre las palancas que, conectadas con cables, accionaban entre otros los
296
alerones y el timn de cola. Ello supuso la necesidad de reentrenarse en el

manejo de esas nuevas aeronaves. Los aviones comerciales con tecnologa
fly-by-wire pueden por tanto ser considerados como plataformas.
Existen productos que llegan por primera vez al mercado, que por tanto desconoce su posible necesidad o conveniencia, y cuyo uso representa
un reto para los que deciden adoptarlo. Hoy todos estamos familiarizados con dispositivos porttiles de reproduccin de msica, pero cuando
Sony lanz el Walkman al mercado supuso una autntica novedad y Sony
tuvo que disear una extraordinaria campaa de marketing para mostrar
las bondades y el potencial de ese dispositivo que lanzaba al mercado.
Todo producto innovador no se convierte necesariamente en un xito y
una de las grandes dificultades asociadas a la innovacin es la dificultad
de imaginar los requisitos o caractersticas deseables para el producto, ya
que de ningn anlisis de mercado saldrn esos requisitos, al desconocer por definicin el mercado dicho producto y su posible uso. El xito
del Walkman es ya historia y rpidamente fue seguido tanto de nuevas
versiones como de otros productos anlogos lanzados por competidores,
que entraran en categoras de derivadas o plataformas, pero no seran
ya innovaciones. La figura 12.2 muestra la clasificacin en la dimensin
Novedad de los ejemplos citados.
Figura 12.2. Ejemplos de proyectos en la dimensin Novedad.
297
Es esencial por tanto prestar la mxima atencin a la tipologa de un

nuevo proyecto y a su clasificacin para elegir con criterio a la persona
adecuada para dirigirlo. Por otro lado, la flexibilidad en el sistema de gestin no ser la misma en ambos extremos. Para proyectos tipo derivada,
en los que el objetivo y requisitos estn claros y fijados desde el principio,
ser en trminos relativos menos necesario ser flexible con el sistema de
gestin, al estar todas las tareas claramente definidas y planificadas desde
el principio; por el contrario, para proyectos tipo innovacin las tareas
y la planificacin, que ser consecuencia de los requisitos y objetivo,
cambiarn con frecuencia y ser necesaria una mayor flexibilidad en la
gestin.
No debe organizarse ni gestionarse de la misma manera un proyecto
que tienda a estar en un extremo del eje Novedad, que otro que tienda a
estar en el extremo opuesto. La falta de sensibilidad hacia ello, ya sea en la
eleccin (por sus cualidades y caractersticas) del jefe de proyecto, as como
en la adopcin por parte de ste de su sistema de gestin (ms o menos
flexible) se traducir en ineficacias e ineficiencias en el proyecto. La figura
12.3 resume alguna de las implicaciones en la gestin de proyectos de la
clasificacin en la dimensin Novedad.
Figura 12.3. Implicaciones de la clasificacin segn Novedad.
298
Tambin es importante tener en cuenta cmo de novedoso es el producto a ser desarrollado en el proyecto a la hora de seleccionar a los miembros
del equipo, ya que ello determinar el grado de creatividad necesaria en al
menos algunos de ellos; esa creatividad ser tanto ms necesaria cuanto ms
innovador sea el producto. Las labores de marketing del producto vendrn
dictadas tambin por su grado de novedad, siendo necesarias campaas de
marketing ms imaginativas cuando se trata de productos novedosos para
el mercado, que cuando son derivadas o nuevas generaciones de productos
ya suficientemente conocidos. La habilidad y capacidad de una empresa de
establecer un producto innovador como futuro estndar ser determinante
para establecer su xito a medio y largo plazo.
4.2. Tecnologa
La Tecnologa es la segunda dimensin del sistema NTCP de clasificacin de proyectos. Esta dimensin se refiere al grado de incertidumbre
o de falta desarrollo de tecnologas necesarias en el proyecto. Hay proyectos en los que todas las tecnologas requeridas ya estn disponibles
y han sido empleadas con xito, por lo que resultan conocidas, mientras
que en otros proyectos el xito est ligado al desarrollo satisfactorio de
ciertas tecnologas que por el momento estn en un nivel insuficiente de
madurez. La clasificacin que realiza la NASA de los niveles de madurez
de la tecnologa (technology readiness levels, TRLs) se ha convertido en
un clsico, fcilmente adaptable a cualquier entorno o tipo de proyectos;
la figura 12.4 muestra los 9 niveles de madurez de la tecnologa establecidos por la NASA.
Proyectos clasificados como baja tecnologa son aquellos que slo
utilizan tecnologas maduras y bien conocidas; hay por tanto muy baja
incertidumbre con respecto a sus prestaciones y a las posibilidades que
ofrecen. Ejemplos tpicos de proyectos de ste tipo son en general los
de obra civil, los de fabricacin bajo plano (como por ejemplo la fabricacin de tarjetas electrnicas bajo plano, ya que ello implica que han
sido previamente fabricadas por su diseador y las tecnologas requeridas
son conocidas y tienen la adecuada madurez), etc. Los considerados media tecnologa son los proyectos que utilizan en su mayora tecnologas
maduras y bien conocidas, aunque pueda haber algunas que necesiten
desarrollar alguna nueva capacidad o mejorar una existente; hay por tanto
baja incertidumbre con respecto a sus prestaciones y a las posibilidades
que ofrecen. Ejemplos tpicos de proyectos de ste tipo son en general
los asociados a productos derivados, o los nuevos modelos en industrias
ya consolidadas (como por ejemplo los equipos electrodomsticos). El
diseo de un nuevo modelo por parte de una fabricante de automviles
299
podra en general considerarse como proyecto de media tecnologa, salvo

que pretendiera incorporar funcionalidades nuevas aportadas por tecnologas an en desarrollo.
Figura 12.4. Los niveles de madurez de tecnologa de la NASA.
Los proyectos clasificados como alta tecnologa son los que requieren
de un nmero significativo de tecnologas de reciente desarrollo y que no
tienen por tanto el nivel de madurez suficiente; hay por tanto una incertidumbre significativa con respecto a sus prestaciones y a las posibilidades
que ofrecen. Ejemplos tpicos de proyectos de ste tipo son en general los
asociados a productos en industrias muy sofisticadas, como son entre otros
los sectores electro-medicina, aeroespacial, nuclear o defensa. El diseo
300
de un buque de guerra que incorpore sensores y armas del estado del arte
puede considerarse un proyecto de alta tecnologa.
Finalmente, los considerados como muy alta tecnologa son los proyectos que requieren de algunas tecnologas que no estn an desarrolladas
ni tienen por tanto el nivel de madurez suficiente en el momento del lanzamiento del proyecto; hay por tanto una elevada incertidumbre con respecto a los plazos en los que las tecnologas estarn listas, sus costes y sus
prestaciones. No hay muchos proyectos que merezcan esta clasificacin,
porque pocos proyectos son puestos en marcha con semejante grado de
incertidumbre respecto a las posibilidades de xito por lo que a madurez
de tecnologas requeridas se refiere. Proyectos como el de desarrollo de
la bomba atmica (Proyecto Manhattan), o el proyecto de trasbordadores
espaciales, son ejemplos de proyectos de muy alta tecnologa, pues en el
momento de su puesta en marcha no se contaba con muchas de las tecnologas necesarias, que hubo que desarrollar expresamente para esos proyectos (por ejemplo, el enriquecimiento de uranio para la fabricacin de la
bomba, o su sistema de detonacin por implosin).
Es importante que el jefe de proyecto sea consciente de qu tipo de
proyecto debe gestionar, qu tecnologas son necesarias y qu grado de
desarrollo o madurez tienen, ya que de ello (y de la evolucin de esas
tecnologas) va a depender en gran medida el xito final del proyecto. La
figura 12.5 muestra algunos ejemplos de proyectos en los diversos niveles
de clasificacin segn la dimensin Tecnologa.
Si la clasificacin de un proyecto en la dimensin Novedad tena importantes implicaciones, con la dimensin Tecnologa ocurre otro tanto. Cuanto ms a la izquierda est un proyecto en la dimensin Tecnologa (es decir,
ms cercano al extrema baja tecnologa), menor en trmino relativo ser
el esfuerzo necesario de diseo, pruebas y desarrollo, por estar ya maduras
las tecnologas requeridas; eso tendr su reflejo en la identificacin de las
tareas necesarias, en la estimacin de los recursos necesarios para llevarlas
a cabo, y en la planificacin global del proyecto (incluyendo los oportunos
anlisis de riesgos). Por contra, si el proyecto est ms cercano al otro extremo, el derecho (muy alta tecnologa), ser mucho mayor la incertidumbre
existente en cuanto si las tecnologas llegarn a desarrollarse en tiempo
y alcanzar la madurez suficiente, y si las prestaciones que alcanzarn se
correspondern con las previstas y necesitadas; esa mayor incertidumbre
asociada a un menor nivel de desarrollo y madurez de las tecnologas necesarias deber verse reflejado en las tareas identificadas con aspectos de
diseo y pruebas, que representarn esfuerzos tanto mayores cuanto menor
sea el nivel de madurez partida de las tecnologas necesarias.
301
Figura 12.5. Ejemplos de proyectos en la dimensin Tecnologa.
De forma anloga, si el proyecto se encuentra hacia el extremo izquierdo

(mayor nivel de desarrollo y madurez de las tecnologas necesarias), la exigencia de formacin, capacidad y habilidades sociales y de comunicacin
del jefe de proyecto no sern tan elevadas como si el proyecto est hacia el
extremo derecho (menor nivel de desarrollo y madurez de las tecnologas
requeridas). El jefe de proyecto debe tener ante todo la visin y comprensin global del proyecto (anlisis de riesgos incluido) y debe actuar de director de orquesta, siendo capaz de conocer y entender las capacidades de
cada uno de los miembros del equipo y su necesaria contribucin de forma
coordinada para la consecucin de los objetivos del proyecto. En proyectos
de alta complejidad es necesario que el jefe de proyecto tenga una altsima
cualificacin y preparacin, sin que eso quiera decir que deba saber ms
de todo que cualquier miembro de su equipo. La figura 12.6 refleja parte de
las implicaciones que tiene la clasificacin de un proyecto en la dimensin
Tecnologa.
302
Figura 12.6. Implicaciones de la clasificacin segn Tecnologa.
De manera anloga a lo dicho en la dimensin Novedad, no todo el

mundo est igualmente preparado (no slo por formacin y experiencia,
sino por cualidades) para dirigir cualquier tipo de proyecto. Personas que
hayan dirigido magnficamente proyectos de baja o media tecnologa no
tienen por qu poder dirigir con el mismo nivel de eficacia proyectos de
alta complejidad tecnolgica, y no slo por la tecnologa en s, sino por
lo que la inmadurez de las tecnologas conlleva en cuanto a esfuerzos de
desarrollo, interlocucin con los expertos, redefinicin de objetivos (en
prestaciones, plazos, costes, etc.).
4.3. Complejidad
La Complejidad de un proyecto se refiere a la complejidad de su organizacin, y no a la complejidad del producto. La complejidad de la organizacin del proyecto va con frecuencia unida a la complejidad del producto
o servicio, pero en esta tercera dimensin el nfasis est en los aspectos
organizativos. El presupuesto del proyecto o el nmero de personas involucradas podran dar una idea de la complejidad, pero no son los nicos
303
aspectos a considerar. Por ejemplo, un costoso proyecto de obra civil, en

el que trabajen muchas personas, puede ser desde el punto de vista organizativo mucho menos complejo que un proyecto de investigacin y
desarrollo, como por ejemplo el de un sistema detector de iones, substancias voltiles y partculas nanomtricas, en el que participen mltiples organismos y universidades de diferentes pases. Por lo tanto, la complejidad
de la organizacin de un proyecto viene dada no slo por el presupuesto
y el nmero de personas, sino por el nmero de entidades participantes,
sus interrelaciones, las diferentes legislaciones que apliquen, los distintos
idiomas y culturas, etc.
Los proyectos clasificados como conjunto son aquellos en los que
bsicamente se trata con un producto, que tiene una funcionalidad bien
definida y forma parte a su vez de algo de mayor entidad, o que es
un producto o servicio independiente, con su propia funcionalidad final.
Normalmente se trata de proyectos con un cliente y un contratista, con
una reducida cadena de suministro, o de una entidad que disea y desarrolla un producto para ser integrado por otro (integrador de sistemas),
como parte de su cadena de suministro. En proyectos de esta naturaleza
lo normal es que las personas del equipo del proyecto estn trabajando
en una misma localidad, se conozcan bien y tengan un alto grado de
comunicacin, no siempre formal. Por ejemplo, podemos pensar en una
empresa dedicada a la fabricacin de electrodomsticos que decida lanzar
un nuevo modelo de lavadora. Para ello pondr en marcha un proyecto
que involucrar a una reducido grupo de personas, que probablemente
trabajarn en el mismo entorno geogrfico, y que tendrn una limitada
cadena de proveedores.
Los productos clasificados como sistema representan un nivel mayor
de complejidad organizativa que los tipo conjunto. Normalmente se trata
de proyectos que requieren la participacin activa de ms de una entidad,
empresa u organizacin, lo que inmediatamente se traduce en mltiples
equipos de proyecto, trabajando en distintas ubicaciones. Ello a su vez repercutir en la frecuencia, fluidez y formalidad de sus comunicaciones. Y
si el desarrollo del producto es ms complejo en ese sentido, igualmente
lo ser el de todos los medios asociados que apliquen (documentacin,
equipos de apoyo y prueba, instalaciones especficas, simuladores, etc.).
El diseo y construccin de un buque de guerra puede considerarse como
un proyecto de complejidad nivel sistema; el diseo y la construccin la
realizar un astillero, pero tendr una amplia cadena de suministro, con empresas en varios pases, y algunas de ellas debern desarrollar los equipos
especficos que les hayan contratado (que sern en cuanto a complejidad
de nivel conjunto).
304
El nivel superior de complejidad organizativa es el de los productos

considerados como sistemas de sistemas, que son conjuntos de sistemas que trabajan conjuntamente para satisfacer un gran objetivo global,
aunque cada sistema tiene y mantiene su propia entidad y ha sido en s
un proyecto. Es frecuente denominar tambin Programas a este tipo de
proyectos, que por su naturaleza dan cobertura a mltiples iniciativas o
proyectos individuales, coordinados entre s bajo un enfoque global o
paraguas proporcionado por el programa. La complejidad organizativa es
mxima, pues los sistemas individuales que lo integran tendrn su propia
organizacin y el colectivo de todos ellos supondr una extraordinaria red
de clientes y/o contratistas, con mltiples proveedores en sus cadenas de
suministro, probablemente radicados en distintos pases, con diferentes
idiomas, culturas y legislaciones, etc. El diseo y construccin del tren
de alta velocidad que conecta Pars y Londres, puede considerarse como
un sistema de sistemas, ya que est constituido por mltiples elementos
que en s podran considerarse como sistemas, como lo son las estaciones,
los tneles bajo el Canal de la Mancha, los trenes (el material rodante), el
sistema de sealizacin ferroviaria, las vas con su alimentacin elctrica y
la red de subestaciones, etc. La figura 12.7 muestra ejemplos de proyectos
segn la clasificacin Complejidad.
La clasificacin de un proyecto en la dimensin Complejidad tiene claras
e importantes implicaciones en su organizacin. Cuanto ms arriba est
clasificado un proyecto en esa dimensin, ms compleja ser en todos los
sentidos su organizacin y mayor formalismo habr en todos los procesos y
en la manera en la que se desarrollen e integren las actividades del proyecto. Cuanto ms compleja sea la organizacin por la existencia de mltiples
clientes y/o contratistas, con amplias cadenas de suministro, y trabajando
en mltiples entornos (idiomas, legislaciones, etc.), mayor ser la exigencia
formal del proyecto.
En proyectos tipo conjunto la organizacin es en general ms informal,
los miembros del equipo del proyecto trabajarn de manera relativamente
distendida, lo normal es que en gran medida se conozcan previamente y
que no requieran excesivo formalismo ni en las comunicaciones ni en la
gestin del proyecto (convocatorias de reuniones, etc.). En este tipo de
proyectos no suele establecerse una definicin estricta de responsabilidades
dentro del equipo del proyecto. Se gestiona de una manera ms informal,
sin necesidad de una planificacin detallada explcita (estar en la cabeza
del jefe de proyecto, pero no ser siempre compartida en detalle con los
miembros del equipo).
305
Figura 12.7. Clasificacin segn Complejidad.
En proyectos tipo sistema hay mucha ms formalidad y rigor en la

organizacin; es necesario definir mbitos de responsabilidad dentro del
proyecto y normalmente se crea una oficina de proyecto que coordine los
trabajos de los diferentes grupos o equipos participantes. Debido a que
en este tipo de proyectos habr importantes actividades de integracin, la
gestin del proyecto prestar ms atencin a actividades administrativas, de
coordinacin y de planificacin, que debern ser ms detalladas en cuanto
a definicin de responsabilidades y ms explcitas para todos los miembros
del equipo de proyecto. La adecuada planificacin y gestin de reuniones
ser ms exigente en proyectos de este nivel de complejidad y habr ms
tipos de documentos, y ms formales, que en uno clasificado como conjunto. La figura 12.8 refleja parte de las implicaciones que tiene la clasificacin
de un proyecto en la dimensin Complejidad.
306
Complejidad de
la organizacin
del proyecto
Capacidad de
comunicacin
y habilidades
sociales del jefe
de proyecto
Figura 12.8. Implicaciones de la clasificacin segn Complejidad.
4.4. Ritmo
El Ritmo al que puede o debe ejecutarse un proyecto constituye la cuarta
y ltima dimensin del sistema de clasificacin NTCP; en esta dimensin
se refleja el grado de urgencia que exista para terminar el proyecto. Todos
los proyectos, por definicin, deben terminar en algn momento, pero no
por ello todos han de ser terminados de manera urgente o expeditiva. Las
exigencias de tiempo en el proyecto pueden provenir de orgenes tan diferentes como pueden ser el cliente, el mercado, la competencia, la estrategia
de la empresa, o amenazas.
Un proyecto se clasifica como normal en la dimensin Ritmo si debe
ser terminado en el plazo previsto, sin que exista razn alguna por la que
su terminacin deba acelerarse o completarse antes de determinada fecha
inamovible. Incumplir el plazo previsto puede conllevar algn tipo de penalizacin econmica, pero en trminos relativos es una circunstancia que
puede ser aceptada pues el xito del proyecto no se ve seriamente disminuido por el retraso. La mayora de los proyectos de obra civil son de
307
esta categora, pues en general un pequeo retraso en su finalizacin es

algo asumible, aunque nunca deseable, y es algo que por tanto no conlleva mayores problemas. La construccin por ejemplo de un tramo de alta
velocidad ferroviaria o de un determinado museo deben estar completados en un determinado plazo, pero un pequeo retraso no tiene mayores
implicaciones. Sin embargo, si se tratara por ejemplo de infraestructuras
requeridas para un determinado momento, como la construccin de las
villas olmpicas en una ciudad que va a albergar unos Juegos Olmpicos,
entonces el tiempo pasara a tener mayor criticidad y se requerira de otra
clasificacin.
Hay proyectos que deben completarse lo antes posible porque se trata
de acceder al mercado para aprovechar una oportunidad de negocio y
capturar una cuota de mercado, o para posicionarse estratgicamente, o
por alguna razn anloga. Esa presin se traduce en la necesidad de completar el proyecto lo antes posible, pues cualquier demora en finalizarlo
puede afectar negativamente a las perspectivas de negocio de la empresa. Estos son los proyectos clasificados como rpido/competitivo. Por
ejemplo, el desarrollo de vehculos elctricos (o hbridos motor elctrico
- motor de explosin) requiere del desarrollo de algunos elementos clave
como son las bateras, o sus mecanismos de carga o reemplazo. Se estn
considerando mltiples tecnologas para la recarga rpida o continua de
bateras, desde la recarga convencional a baja tensin, a recargas extrarpidas a tensiones muy elevadas, pasando por otras soluciones como la
recarga por induccin magntica, o la simple sustitucin automatizada de
bateras. La empresa que est desarrollando alguna de esas soluciones
querr tenerla lista lo antes posible, pues eso podr darle una ventaja
decisiva en el mercado (si las prestaciones, coste y otros atributos relevantes de su solucin son los adecuados!), incluso registrando la oportuna propiedad intelectual o industrial y consolidndose como la solucin
estndar.
Hay proyectos que deben estar terminados en una fecha concreta y
el hecho de que hayan podido comenzar con retraso no implica que sea
admisible terminar con el mismo retraso; la fecha o rango de fechas de
finalizacin no es alterable, y en ese sentido la ejecucin del proyecto es
crtica desde el punto de vista temporal; estos son los proyectos crticos.
Por ejemplo, la construccin de las villas olmpicas en una ciudad que vaya
a albergar unos Juegos Olmpicos debe estar finalizada en determinada fecha antes de las olimpiadas; no tendra sentido que se terminaran un poco
despus de acabados los Juegos Olmpicos! Otro ejemplo puede ser la necesidad de solucionar el clebre problema informtico de final del milenio
(el conocido como Y2K); muchas aplicaciones software que gestionaban
instalaciones, empresas, servicios, etc. haban sido programadas usando dos
308
dgitos para representar el ao y con el cambio de milenio las operaciones

de resta de fechas dara errores que podran tener consecuencias severas en
esas instalaciones, empresas o servicios. El problema deba quedar resuelto
antes del final de 1999, con independencia de cundo se hubiera comenzado a trabajar en cada empresa en su resolucin.
El ltimo nivel en la clasificacin Ritmo corresponde a aquellos proyectos que hay que terminar de manera urgente y expeditiva, primando la
rapidez por encima de cualquier otra consideracin; estos son los proyectos
relmpago. Ello tiene importantes implicaciones en la manera en la que
debe planificarse, ejecutarse y seguirse el proyecto. Suelen ser casos excepcionales, derivados normalmente de catstrofes o situaciones de autntica
emergencia. En todos los proyectos el tiempo es importante, como lo es
el identificar las tareas y organizarlas en una descomposicin estructurada,
que sirva de base a una planificacin detallada, a una asignacin de responsabilidades, etc.; pero hay situaciones en las que la absoluta urgencia de
tiempo no permite seguir con el mismo rigor y formalismo todo el proceso
de identificar, planificar, ejecutar, etc. Hay que actuar sin demora, con el
mayor criterio posible, y ms bien rindiendo cuentas a posteriori que explicando a priori qu se va a hacer, cmo y por qu. El reciente accidente
sufrido por la central nuclear japonesa de Fukushima, en la que varios de
los reactores estuvieron en peligro de sufrir una fusin, supuso una necesidad absolutamente urgente de controlar la situacin para evitar una catstrofe, o al menos para mitigarla en lo posible. En un caso as no hay tiempo
que perder creando una comisin para estudiar alternativas, pedir ofertas a
posibles empresas de rescate y salvamento, etc.; hay que poner al frente a
alguien en quien se confe por preparacin, experiencia y cualidades y hay
que actuar sin prdida de tiempo. El desastre de la plataforma Deepwater
Horizon en el Golfo de Mjico o la situacin en la que unos mineros se
vieron atrapados en la mina chilena de San Jos de Copiap, ambos eventos
en 2010, son ejemplos de proyectos relmpago (contener el vertido en el
primer caso, rescatar a los mineros en el segundo). La figura 12.9 muestra
ejemplos de proyectos segn la clasificacin Ritmo.
La clasificacin de un proyecto en la dimensin Ritmo tiene tambin
importantes implicaciones en su organizacin. Cuanto ms abajo est clasificado un proyecto en esa dimensin (es decir, cuanto ms se acerque a
ser un proyecto relmpago), mayor deber ser la flexibilidad tanto en la
organizacin como en el sistema de reporte. En los proyectos Relmpago
no se dispone, por definicin, del tiempo necesario para llevar a cabo las
tareas de planificacin y de seguimiento e informacin con el mismo nivel de detalle y ortodoxia que en otros proyectos ms convencionales en
cuanto a esta dimensin. El nivel de exigencia en lo relativo a informacin
y seguimiento entre el Jefe del Proyecto y los miembros de su equipo, as
309
como del primero hacia los stakeholders, deber tener en cuenta su clasificacin en la dimensin Ritmo. En proyectos del tipo Rpido/Competitivo la
exigencia ser muy alta y en los del tipo Crtico la exigencia ser mxima,
ya que disponer de informacin actualizada y al da es vital para la toma
de decisiones, que pueden ser determinantes para asegurar el xito del
proyecto.
Figura 12.9. Clasificacin segn Ritmo.
Por otra parte, la clasificacin de un proyecto en la escala Ritmo tendr

tambin consecuencias en cuanto a su organizacin. Para proyectos tipo
normal una organizacin matricial podra ser adecuada, pero a medida
que el proyecto se desplaza hacia el extremo (rpido/competitivo; crtico;
relmpago) se ir haciendo ms imprescindible adoptar una estructura
convencional, con miembros del equipo dedicados al 100% al proyecto.
310
En organizaciones matriciales las personas pueden estar simultneamente

asignadas a varios proyectos en distintos porcentajes de dedicacin y ello
no suele ser compatible con proyectos en los que el tiempo es una variable
especialmente importante, porque las dedicaciones a tiempo parcial podran comprometer seriamente el xito del proyecto; cuanto mayor sea la
exigencia temporal en un proyecto, ms importante es que los miembros
del equipo estn absolutamente concentrados en l y dedicados a l. La
figura 12.10 muestra las principales implicaciones de la clasificacin de un
proyecto segn la dimensin Ritmo.
Figura 12.10. Implicaciones de la clasificacin segn Ritmo.
Unas reflexiones finales relacionadas con la clasificacin de un proyecto

en las cuatro dimensiones, ques es sin duda una cuestin subjetiva, aunque
desde luego no es arbitraria. Segn el Diccionario de la Real Academia de la
Lengua Espaola, subjetivo es lo perteneciente a nuestro modo de pensar o
sentir, y no al objeto en s mismo; por otro lado, arbitrario se refiere a proceder de forma contraria a la justicia, la razn o las leyes, dictado solo por la
voluntad o el capricho. La clasificacin de un proyecto depende de la percepcin de quien la realice, pero al explicitarla podr explicar sus motivos
311
y comentarlos y discutirlos con otras personas, lo que permitir finalmente

una clasificacin deseablemente consensuada, o al menos explicitada.
Las fronteras de las clasificaciones en la diferentes dimensiones podrn
ser por tanto difusas en algunas ocasiones (es un proyecto de tecnologa
media, o de alta tecnologa?; es normal, o rpido/competitivo?; etc.). La
mencionada naturaleza subjetiva de la clasificacin hace que en ocasiones
sea imposible establecer con absoluta claridad y consenso la naturaleza de
un proyecto en alguna o varias de las dimensiones, pero ello no repercutir
sensiblemente en los aspectos citados relativos al jefe de proyecto, a su
equipo, al sistema de organizacin y reporte, etc. Que la clasificacin sea
subjetiva y que algunas fronteras puedan ser difusas no le resta validez al
hecho de que no todos lo proyectos son iguales, y que por tanto no deben
ser gestionados ni por el mismo tipo de persona ni de la misma manera.
Lo importante es por tanto no slo entender que no todos los proyectos
son iguales; lo necesario es saber clasificarlos en las cuatro dimensiones,
saber decidir en funcin de esa clasificacin cmo debe ser gestionado, y
mantener actualizada si procede esa clasificacin a lo largo de la vida del
proyecto (especialmente en proyectos de larga duracin, ms sensibles a
sufrir cambios en alguna de sus dimensiones).
La clasificacin de un proyecto no tiene por qu ser realizada por una
sola persona. Lo normal es que en la clasificacin intervengan los principales stakeholders. Al intervenir varias personas es normal que no se produzca siempre, al menos de manera inmediata, un consenso pleno sobre
cmo clasificarlo. Para ello se puede recurrir a distintas tcnicas, desde
los intercambios abiertos de opinin en reuniones organizadas al efecto,
hasta la celebracin de sesiones siguiendo el mtodo Delphi, que da
mayor seguridad a que todas las opiniones sean escuchadas y valoradas,
evitando discusiones directas para que no prevalezcan opiniones slo por
la ascendencia jerrquica de quienes las emitan, o por su personalidad
ms fuerte y su mayor capacidad de razonar y exponer verbalmente sus
argumentos.
5. REFERENCIAS
DVIR, D., LIPOVETSKY, S., SHENHAR, A. y TISHLER, A., In search of project classification - a non-universal approach to project success factors, Research Policy 27
(1998), pp. 915-935.
SHENHAR, A. y DVIR, D., Reinventing Project Management: the Diamond Approach
to Successful Growth and Innovation. Harvard Business School Press, 2007.
SHENHAR, A.; DVIR, D., LEVY, O. y MALTZ, A. C., Project success - a multidimensional strategic concept. Long Range Planning 34 (2001), pp. 699-725.
312
CAPTULO 13
GESTIN DE CAMBIOS Y CONTROL

DE CONFIGURACIN
Jos Manuel Muoz Palos
1. INTRODUCCIN
El presente captulo tiene por objeto facilitar una visin general de la
gestin de la configuracin, sus procesos y el cometido que desempea
como parte integral de la gestin de proyectos.
La gestin de la configuracin naci como disciplina desarrollada en el
marco de la ingeniera de sistemas. sta ltima constituye un proceso riguroso y ordenado que tiene por objeto la utilizacin de tcnicas cientficas y
de ingeniera para transformar una necesidad operativa en un producto o
sistema concreto. Dentro de este proceso, la gestin de la configuracin es
la disciplina encargada de garantizar la consistencia fsica y funcional entre
un producto, su documentacin tcnica y los requisitos tcnicos, operativos
y logsticos que lo originaron.
Conviene sealar, que el inicio en el uso de las prcticas ligadas a la gestin de la configuracin se remonta a finales de los aos 50 con el desarrollo de los grandes programas espaciales y los complejos sistemas de defensa
en los Estados Unidos (EE.UU.). La complejidad tecnolgica de aquellos
sistemas junto con la diversidad de empresas y organismos involucrados
en su concepcin, desarrollo, produccin y utilizacin hicieron necesaria la
definicin, establecimiento y estandarizacin de los procesos relativos a
la gestin de la configuracin.
313
Ya en los aos 60, el Departamento de Defensa de EE.UU. desarroll las

llamadas Military Standards 480 que establecen la gestin de la configuracin tal y como la entendemos en la actualidad y que han marcado desde
entonces los desarrollos de los programas espaciales y de los sistemas de
armas por parte de la NASA y el Departamento de Defensa norteamericano,
respectivamente. Posteriormente, la serie de normas 480 fue consolidada en
la MIL-STD-973. Esta fue sustituida finalmente por la ANSI/EIA-649, National Consensus Standard for Configuration Management, la cual se encuentra actualmente en vigor. Asimismo, el citado Departamento dispuso la gua
MIL-HDBK 61B - Configuration Management Guidance, que complementa
a la norma ANSI/EIA-649.
En la actualidad, la gestin de la configuracin es de aplicacin en todos
los sectores industriales. Sin embargo, su aplicacin tiene especial importancia en:
t 4JTUFNBTDPNQMFKPTDPOHSBODBOUJEBEEFDPNQPOFOUFT
t 4JTUFNBTRVFFWPMVDJPOBONVZSQJEBNFOUFFOFMUJFNQP OVNFSPTBT
versiones).
t 4JTUFNBTRVFIBOEFJOUFSBDUVBSDPOPUSPTQBSBQPEFSGVODJPOBS OVmerosas interfaces).
t 4JTUFNBTDPOQBSUFTJOUFSDBNCJBCMFT
t 4JTUFNBTFODVZBDPODFQDJO EJTFP EFTBSSPMMPZQSPEVDDJOJOUFSvienen un cierto nmero distinto de organizaciones.
t 4JTUFNBTRVFSFRVJFSFOEFVOBFYUSFNBEBGJBCJMJEBE ZBRVFVOGBMMP
en su funcionamiento puede tener efectos catastrficos.
Aquellos sectores en los que la seguridad, disponibilidad, mantenibilidad y fiabilidad del sistema tienen una especial importancia (por
ejemplo: sector espacial, defensa, aeronutico, ferroviario, energtico,
automocin, telecomunicaciones, desarrollos de software, etc.) la aplicacin de los procesos relativos a la gestin de la configuracin es obligada constituyendo un mtodo disciplinado de trabajo, con una serie de
procesos claramente establecidos, a los que el Jefe de Proyectos debe
prestar su debida dedicacin desde las primeras fases del inicio del proyecto. Su desatencin suele ser fuente frecuente de problemas, retrasos
y sobrecostes del proyecto.
En lo referente a la estructura del captulo, en la seccin 13.2 se definirn los conceptos de configuracin, documentacin de la configuracin y
gestin de la configuracin. Estos conceptos son necesarios para entender
la gestin de la configuracin y sus procesos.
Por su parte, la seccin 3 est dedicada a explicar, de forma genrica, el
proceso de concepcin, diseo, desarrollo y produccin de un producto o
sistema. En lo referente a la gestin de la configuracin, se ver como, a lo
314
GESTIN DE CAMBIOS Y CONTROL DE CONFIGURACIN
largo de las fases que componen dicho proceso, se van estableciendo las
llamadas lneas-base que servirn de puntos de control en los que comprobar que el producto o sistema cumple los requisitos tcnicos, operativos y
logsticos que lo originaron y que servirn tambin para auditar la consistencia entre la documentacin tcnica y la configuracin del producto en
los citados puntos.
Por ltimo, la seccin 4 estar dedicada a revisar el papel de la gestin
de la configuracin en la gestin de proyectos para, finalmente, en la seccin 5 y sus subsecciones explicar con cierto detalle los distintos procesos
que integran esta disciplina.
2. DEFINICIN DE GESTIN DE LA CONFIGURACIN

Antes de definir el propio concepto de gestin de la configuracin es
necesario introducir los conceptos de configuracin, documentacin de la
configuracin y ciclo de vida.
t 4FEFGJOFDPOGJHVSBDJODPNPFMDPOKVOUPEFQSFTUBDJPOFT DBSBDUFSTticas fsicas y funcionales del hardware, software, firmware o, combinacin de stos, que constituyen un producto.
t 1Pr su parte, la documentacin de la configuracin constituye el conjunto de documentacin tcnica que identifica, define y determina la
configuracin de un producto.
t &MUSNJOPDJDMPEFWJEBEFVOQSPEVDUPPTJTUFNBFTVOUSNJOPHFnrico que se utiliza para expresar las distintas fases por las que transita un producto desde su concepcin hasta su retirada o sustitucin.
Como se coment en el captulo 1, tradicionalmente la ingeniera de
sistemas ha dividido el ciclo de vida de un producto o sistema en las
siguientes fases: identificacin de la necesidad, estudios de viabilidad, diseo conceptual, diseo detallado y desarrollo, calificacin y
produccin, servicio y retirada o sustitucin.
Teniendo en consideracin estos tres conceptos anteriores, se define la
gestin de la configuracin como un grupo de procesos de gestin cuyo
objetivo es establecer y mantener la consistencia de las prestaciones de un
producto, sus funcionalidades y atributos fsicos, a lo largo de su ciclo de
vida, de acuerdo con los requisitos que lo originaron, as como con su documentacin tcnica de diseo, desarrollo, produccin y operativa.
La gestin de la configuracin tiene dos objetivos principales:
1. Que la configuracin del producto a lo largo del ciclo de vida cumpla
en todo momento con los requisitos que lo originaron.
315
2. Que la documentacin tcnica sea fiel reflejo de la configuracin del

producto en todo momento.
La relacin entre los distintos conceptos que intervienen en la definicin
de la gestin de la configuracin es ilustrada en la figura 13.1 mostrada a
continuacin:
Figura 13.1. Relacin entre requisitos, configuracin del producto

y documentacin tcnica.
Conviene sealar que la gestin de la configuracin, como se establece

en su definicin, lo constituye un grupo de procesos. En concreto, son cinco los procesos siguientes los que intervienen. Estos son:
t Planificacin y gestin: es el primero de los procesos y engloba
las actividades de planificacin y la aplicacin de las tcnicas de
gestin necesarias para la implantacin, durante las distintas fases
del ciclo de vida del producto, de los procesos que se describen a
continuacin.
t Identificacin de la configuracin: consiste en la identificacin y seleccin de las prestaciones, atributos fsicos y funcionales del producto que van a constituir su configuracin junto con su documentacin
tcnica asociada.
t Control de la configuracin: tiene por objeto el establecimiento de
los mecanismos que permiten el control de la configuracin. Entre
316
ellos, se encuentran los procesos para aprobar o rechazar posibles

cambios que afecten a la configuracin del producto as como aquellos que se han de seguir para implementar los cambios de la configuracin aprobados.
t Registro del estado de la configuracin: mediante este proceso se
establecen los mecanismos para conocer en todo momento el estado de la configuracin. Ello conlleva conocer y mantener registro
de la configuracin inicial, los cambios aprobados y rechazados, as
como, el estado en que se encuentra la implementacin de los cambios aprobados. Es el proceso encargado de mantener identificada en
todo momento la documentacin aprobada que constituye la documentacin vlida de la configuracin del producto.
t Verificacin y auditoras de la configuracin: el objetivo de este
proceso es verificar que los procesos establecidos relativos a la gestin de la configuracin son efectivos y que las prestaciones y atributos del producto satisfacen los requisitos, a partir de los cuales el
producto fue concebido. ste es un proceso de comprobacin de la
consistencia entre producto, requisitos y documentacin.
Los procesos anteriores sern explicados con mayor detalle en la
Seccin 4. Llegados a este punto y a modo de ejemplo prctico que permita
ofrecer una idea del mbito, alcance y cometido de la gestin de la configuracin y sus procesos, considrese una aeronave de pasajeros de largo
recorrido. Una aeronave de este tipo est compuesta por varios millones de
piezas, fabricadas por ms de un millar de empresas establecidas en varias
decenas de pases del mundo. En la fabricacin, operacin y actividades
relativas al apoyo al ciclo de vida (mantenimiento, entrenamiento de tripulaciones y tcnicos, simuladores, etc.) hay involucradas varias decenas
de miles de personas y su documentacin tcnica puede suponer varias
toneladas de papel. Ante un proyecto de tal magnitud, conviene formularse
cuestiones como las siguientes:
t {$NPFTQPTJCMFRVFUPEBTMBTQJF[BTFODBKFOQFSGFDUBNFOUF
t {2V QSPDFTPT TF VUJMJ[BO QBSB RVF MB EPDVNFOUBDJO VUJMJ[BEB QPS
un piloto o por un tcnico de mantenimiento en cualquier parte del
mundo sea la misma y sea siempre la ltima versin vlida de la configuracin del sistema?
t {$NPFTQPTJCMFHFTUJPOBSMPTDBNCJPTFONJMMPOFTEFQJF[BTRVF
se van produciendo a lo largo de su ciclo de vida y la influencia de
dichos cambios en el resto de componentes en la aeronave?
t {$NPFTQPTJCMFBDPUBSVOGBMMPUDOJDPFOFMTJTUFNBEFGPSNBJOmediata?
317
t {$NPHFTUJPOBFMGBCSJDBOUFMBTEJTUJOUBTDPOGJHVSBDJPOFTEFMBWJO
que operan las distintas compaas areas?
t {2VQSPDFTPTEFTFHVSJEBEZNFEJPBNCJFOUBMFTIBZRVFBQMJDBSQBSB
dar de baja a el avin y desguazar el mismo?
t {2VJOHBSBOUJ[BRVFFMBWJOIBTVQFSBEPUPEBTMBTQSVFCBTEFDFStificacin y su utilizacin es totalmente segura?
A stas y a otras muchas preguntas da respuesta la gestin de la configuracin. Esta disciplina es la encargada de mantener un producto perfectamente documentado asegurando que el mismo ha pasado todas las pruebas
de verificacin que garantizan el cumplimiento de los requisitos tcnicos,
operativos y logsticos. En este sentido, conviene hacer notar que el control
sobre el cumplimiento de los requisitos y la documentacin del producto
cubre tambin todos los componentes que forman parte de su apoyo logstico como son los elementos asociados a la operacin y mantenimiento
del producto o sistema como pueden ser, entre otros, los manuales de
operacin, los procesos de mantenimiento, la formacin, los equipos de
prueba, tiles, herramientas, repuestos, recursos informticos, instalaciones
o simuladores.
3. CICLO DE VIDA Y LNEAS-BASE

Una vez se ha introducido el concepto de gestin de la configuracin en
la seccin anterior, a continuacin se revisar brevemente el proceso de
ingeniera de sistemas seguido en proyectos orientados a la obtencin
de un producto fsico, como puede ser un telfono mvil, un automvil o,
incluso, un desarrollo de software. No obstante, en la seccin 4 se ampliar
el mbito de su aplicacin a cualquier otro tipo de proyectos.
La ingeniera de sistemas recurre al concepto del ciclo de vida definido
en la seccin anterior y establece una serie de fases por las que transita el
producto desde que se identifica una necesidad hasta la retirada o sustitucin del mismo (identificacin de la necesidad, estudios de viabilidad,
diseo conceptual, diseo detallado y desarrollo, calificacin y produccin,
servicio y retirada o sustitucin).
A lo largo del citado proceso y como terminacin de una fase y comienzo
de la siguiente, se establecen lo que se denominan lneas-base. Una lneabase no es ms que la configuracin del producto en un momento dado de
su ciclo de vida. Utilizando un smil fotogrfico, una lnea-base sera como
una fotografa del producto en un momento dado de su ciclo de vida. Las
lneas-base constituyen puntos de control en los que se comprueba que la
configuracin del producto en dicho momento cumple los requisitos tcnicos, operativos y logsticos originarios y que la documentacin tcnica
318
es fiel reflejo del producto en ese momento. Las diferentes lneas-base son
aprobadas en las correspondientes reuniones de revisin.
Por otro lado y en lo referente a la gestin de la configuracin, conviene sealar que para facilitar la gestin de un producto o sistema complejo
como puede ser el ejemplo de la aeronave de la Seccin anterior, se recurre
al concepto de elemento de configuracin. Un elemento de la configuracin es toda aquella porcin de hardware, software, firmware o combinacin de stos que forma parte de un producto o sistema, cuya configuracin
es gestionada como un ente nico y discreto. En la prctica, para facilitar
la gestin, lo que se hace es descomponer el producto o sistema en elementos ms pequeos de forma que, controlando la configuracin de stos,
se consigue controlar la configuracin del producto final. De esta forma,
cuando hay que efectuar un cambio o se produce el fallo de alguno de los
componentes del producto o sistema es ms sencillo acotar la documentacin sobre la que hay que efectuar las modificaciones de diseo pertinentes
o identificar la posible causa del fallo producido. En este sentido, conviene
sealar que los procesos de identificacin, control, registro y verificacin y
auditoras de la configuracin que forman parte de la gestin de la configuracin son de aplicacin a nivel de elementos de la configuracin.
A continuacin se va a revisar el proceso de ingeniera de sistemas y se
van a identificar las distintas lneas-base establecidas a lo largo del citado
proceso. La figura 13.2 muestra grficamente el proceso seguido.
El proceso comienza con la aparicin de una necesidad a la cual se debe
dar respuesta para satisfacer la misma. El proceso empieza con la identificacin de una necesidad u oportunidad de negocio a la cual siguen los
correspondientes estudios de mercado para identificar si existen soluciones
disponibles que den respuesta a la citada necesidad. En el caso de que no
existan soluciones en el mercado o se opte por desarrollar una solucin
nueva, el siguiente paso consiste en transformar la necesidad en forma de
requisitos de alto nivel que permitan realizar los correspondientes estudios
de viabilidad de las posibles soluciones y seleccionar aquella ms apropiada, teniendo en cuenta criterios tales como las prestaciones tcnicas, el
coste, la efectividad o los requisitos logsticos.
Elegida la solucin ms apropiada, se irn detallando los requisitos fsicos, operativos y logsticos para dicha solucin y se lleva a cabo un anlisis
funcional para determinar las acciones o funciones que ha de realizar el
producto o sistema. Para cada requisito, se determinan las acciones o funciones que ha de realizar el producto o sistema. Estas funciones se irn,
a su vez, descomponiendo en funciones de nivel inferior que dar como
resultado una arquitectura funcional del producto o sistema. sta quedar
recogida en la llamada lnea-base funcional del sistema que ser aprobada
319
Figura 13.2. Ciclo de vida de un sistema y lneas-base.
320
en la revisin de los requisitos del sistema y que servir de referencia para

el posterior diseo del producto o sistema.
Establecida la lnea-base funcional del sistema, se lleva entonces a cabo
entonces un proceso de asignacin de funciones a componentes fsicos
que sern los encargados de realizar cada una de las funciones que ha de
realizar el producto o sistema. Estos componentes de ms bajo nivel se
integran en equipos, que a su vez componen las unidades que constituyen
los subsistemas que, a su vez, integran el producto o sistema final. De esta
forma, se establece una configuracin bsica o preliminar del producto
(arquitectura fsica y funcional preliminar). sta configuracin bsica se denomina lnea-base asignada y es aprobada en la llamada revisin de diseo
preliminar. Esta configuracin, sirve de referencia para llevar a cabo la fase
de diseo detallado y desarrollo del sistema.
El siguiente paso es el refinamiento de las especificaciones fsicas y
funcionales de cada uno de los componentes del sistema que dan como resultado la llamada lnea-base de diseo. Esta configuracin, aprobada en la
llamada revisin crtica de diseo, incluye las especificaciones del sistema,
los materiales necesarios para la produccin del mismo y los procesos productivos que han de seguir los materiales para obtener los distintos componentes que constituyen el producto. A partir de este punto, se establece la
lnea-base del producto preliminar y antes de lanzar la produccin en serie
del mismo, suele producirse el llamado lote de calificacin, o lote piloto, el
cual es sometido a un programa de pruebas para verificar que las prestaciones y la configuracin fsica del sistema, cumple las especificaciones de
los requisitos del sistema. Adems, permite a su vez calificar las lneas de
produccin de los distintos elementos de la configuracin. Una vez que las
unidades del lote de calificacin han pasado con xito el paquete de pruebas y existe garanta del cumplimiento de las especificaciones, se aprueba
la lnea-base del producto definitiva.
A modo de ejemplo y a fin de mostrar las distintas lneas-base establecidas en el proceso de gestacin un producto o sistema, considrese que
el cuerpo de bomberos necesita un artilugio capaz de realizar labores de
vigilancia para prevenir incendios en zonas montaosas de difcil acceso.
Imagnese que no existe un producto en el mercado que satisfaga este requisito y que se decide desarrollar uno nuevo.
Analizada la necesidad, se opta por desarrollar un artefacto que ha de
ser capaz de volar de forma autnoma siguiendo una ruta previamente programada. Este podra ser un requisito de alto nivel a partir del cual se llevar a cabo un anlisis funcional determinar las funciones que ha de realizar
para cumplir el mismo. En este sentido, para que el artefacto pueda volar
autnomamente siguiendo una ruta prestablecida ha de ser capaz, o debe
realizar la funcin, de calcular su posicin en el espacio en todo momento.
321
De esta forma, podr comparar su posicin en vuelo con la ruta prestablecida y tomar las acciones necesarias para seguir la misma. El artilugio ha
de ser capaz, por tanto, de calcular las coordenadas X, Y y Z as como los
ngulos de deriva, inclinacin y alabeo e integrar dichos datos para hallar la
posicin. Volar de forma autnoma sera un requisito de alto nivel. Mientras que calcular las coordenadas y ngulos sern funciones integrantes de
la lnea-base funcional.
Llegados a este punto, el siguiente paso ser racionalizar y asignar funciones a elementos fsicos que sern los encargados de realizar dichas funciones. En el ejemplo, para el clculo de las posiciones X, Y y Z y los
ngulos de deriva, inclinacin y alabeo podran utilizarse acelermetros y
girscopos. Asimismo, para integrar los datos puede utilizarse una tarjeta
electrnica. El conjunto de componentes fsicos que desarrollaran las distintas funciones formarn parte de la lnea-base asignada y la especificacin
detallada de los citados componentes para su diseo constituir la lneabase de diseo. A partir de aqu se desarrollarn los componentes o se adquirirn en el mercado. Una vez desarrollados y aprobada su configuracin
para producir los mismos obtendremos la lnea-base del producto.
En el caso de que se adquieran en el mercado, la adquisicin se realizar
en base a una especificacin especfica obtenida a partir de la lnea-base
del producto que ser entregada al suministrador correspondiente. Desde
el punto de vista de la gestin de la configuracin deberemos verificar y
asegurar que el suministrador entrega la documentacin tcnica requerida y
que el suministro cumple la especificacin indicada anteriormente.
Retomando el proceso, conviene sealar tras la lnea-base de producto
ste entra en su fase de utilizacin o servicio. Sin embargo, el producto no
permanecer invariable en el tiempo sino que ir evolucionando ya sea para
incorporarle nuevas tecnologas, dotarle de mayores prestaciones, subsanar
posibles errores de diseo que afecten a su fiabilidad, disponibilidad, mantenibilidad o seguridad; o simplemente para adaptarle a los nuevos gustos
de los posibles clientes. Un ejemplo de ello, lo constituye la evolucin de
los modelos de automviles que suelen sufrir una modificacin profunda o
sustitucin cada ocho aos. No obstante, a los cuatro aos suele realizarse
una remodelacin parcial adaptando el modelo a la variacin de los gustos
de los potenciales clientes, equiparando, en ocasiones, las prestaciones o el
equipamiento del vehculo a la competencia y realizando mejoras o subsanando fallos detectados durante los aos previos en servicio.
De igual forma, en la fase de retirada o sustitucin, la gestin de la configuracin juega un papel muy importante ya que la documentacin tcnica
del producto contempla tambin los procesos que deben utilizarse para
reutilizar los componentes del sistema aprovechables y eliminar de forma
segura y, de acuerdo con las normativas de la gestin medioambiental,
322
Figura 13.3. Aplicacin transversal de los procesos los procesos de la gestin de la configuracin.
323
aquellos que son desechables. De igual forma, cuando se retira un sistema,

la gestin de la configuracin permite mantener la trazabilidad de aquellos
componentes del apoyo logstico integrado que deben ser dados de baja
junto con el producto. Un ejemplo concreto, puede ser la baja de inventario
de un misil para lo cual deben utilizarse procedimientos especficos de desmilitarizacin de sus componentes activos como son el motor y la carga de
guerra. Asimismo, junto con la baja del sistema, deben darse de baja, entre
otros, los equipos de prueba para su mantenimiento, simuladores, utillajes
para su manejo, etc.
Una vez mostrado el proceso seguido en la obtencin de un producto
o sistema, conviene sealar que los procesos relativos a la gestin de la
configuracin son de aplicacin transversal a las distintas fases del ciclo
de vida y permiten asegurar que la documentacin tcnica de las distintas
lneas-bases establecidas (funcional, asignada, de diseo y producto), refleja fielmente la configuracin del producto en dichas fases y que este cumple en todo momento con los requisitos originarios. La figura 13.3 sintetiza
grficamente esta idea.
4. LA GESTIN DE LA CONFIGURACIN EN EL MARCO DE LA GESTIN DE PROYECTOS

Si bien, podra parecer que la aplicacin de la gestin de la configuracin se circunscribe nicamente a proyectos cuyo resultado es un producto, lo cierto es que el resultado de un proyecto puede ser otro, como por
ejemplo, un servicio de atencin al cliente de una compaa o un proyecto
concreto de consultora organizacional con una compaa. Independientemente de la naturaleza del proyecto, los procesos relativos a la gestin de
la configuracin son de igual aplicacin.
Todo proyecto se traduce en una serie de entregables con una configuracin especfica, nica, soportada por una documentacin. Los servicios, al
igual que los sistemas o productos fsicos, se disean y desarrollan, pueden
ser divididos en elementos de la configuracin, al igual que un producto
fsico, y pueden establecerse lneas-base o configuraciones determinadas a
lo largo de su ciclo de vida. stas han de ser perfectamente documentadas
(procesos, procedimientos operativos, herramientas informticas, cursos de
formacin de personal, etc.). Igualmente, se han de controlar y registrar todos los cambios que la configuracin del servicio vaya sufriendo a lo largo
de la aplicacin del mismo.
De igual forma, se opera en el caso de proyectos cuyo resultado es
otro, distinto a productos o servicios como podran ser los proyectos de
consultora, cuyos resultados finales pueden ser un informe o estudio sobre
un tema concreto. stos se elaboran normalmente utilizando metodologas
324
especficas dependiendo del resultado buscado. Los resultados que se van

obteniendo derivados de la aplicacin de tales metodologas y que formarn parte del entregable o entregables del proyecto, han de ser igualmente
documentados y controlados.
Como parte de la gestin de proyectos, el jefe de proyecto debe asegurar que el proyecto cuenta con un sistema de gestin de la configuracin
que garantice la integridad entre los productos o entregables del proyecto,
sus configuraciones y documentacin que los definan y describan. La gestin de la configuracin es, por tanto, una disciplina ms de la gestin de
proyectos aplicable a cualquier tipo de proyecto y como tal, las tareas a
desarrollar quedarn recogidas en el correspondiente Plan de Gestin de la
Configuracin del Proyecto (PGCP), que formar parte del Plan de Gestin
del Proyecto.
5. PROCESOS DE LA GESTIN DE LA CONFIGURACIN

Hasta el momento, se han enumerado los procesos que constituyen la
gestin de la configuracin de un proyecto. A continuacin, en esta Seccin, se explicarn con mayor detalle los mismos. La figura 13.4 enumera
los citados procesos y sintetiza las relaciones entre ellos.
5.1. Planificacin y gestin de la configuracin
El proceso de planificacin y gestin es el primero de los procesos y,
como su nombre indica, engloba las tareas de planificacin y gestin de
los otros cuatro procesos: identificacin, control, registro y verificacin y
auditoras de la configuracin.
El Plan de Gestin de la Configuracin del Proyecto (PGCP) se elabora
una vez ser recibe la instruccin de iniciar el proyecto y contempla la planificacin de tareas, calendario, asignacin de recursos humanos y materiales
as como los costes necesarios para establecer los procesos involucrados,
relativos a la gestin de la configuracin durante el ciclo de vida del producto. La planificacin tendr en consideracin los requisitos contractuales
que guarden relacin con la gestin de la configuracin y que formar parte
del Plan de Gestin del Proyecto.
Realizada la planificacin, se obtendr como resultado una lista de
requisitos a satisfacer para poder implantar el sistema de configuracin.
stos pueden ser: recursos humanos, materiales (software y hardware),
econmicos, etc. De esta actividad, tambin resultar la elaboracin de los
procedimientos operativos del resto de procesos (identificacin, control,
registro y verificacin y auditoras de la configuracin), que permitirn
325
Figura 13.4. Procesos de la gestin de la configuracin y sus relaciones.
326
al equipo del proyecto desarrollar las tareas asociadas a la gestin de la

configuracin.
El PGCP incluir tambin los requisitos de gestin exigidos por el rgano contratante, como puede ser la presentacin de informes y reuniones
de seguimiento.
5.2. Identificacin de la configuracin
Establecido el PGCP, el primero de los procesos operativos es la identificacin de elementos de configuracin que integran el producto y la documentacin que define las distintas configuraciones a lo largo del ciclo de
vida (funcional, asignada, de diseo y producto).
El proceso de identificacin de la configuracin comprende las siguientes actividades:
a) Establecer la estructura del producto descomponindolo jerrquicamente en elementos ms pequeos.
b) Seleccionar los elementos de la configuracin en los niveles apropiados de la estructura de producto.
c) Determinar la documentacin de la configuracin requerida para
cada elemento de configuracin que defina sus prestaciones, atributos fsicos y funcionales incluyendo los interfaces internos y externos
del elemento.
d) Asignar identificadores a los elementos de configuracin y a la documentacin que los define.
e) Aprobar y poner a disposicin del proyecto la documentacin de la
configuracin del producto y, establecer y documentar las distintas
lneas-base a lo largo del ciclo de vida.
La figura 13.5 siguiente muestra las actividades que componen el proceso de identificacin as como las relaciones entre ellas.
La identificacin de la configuracin es esencial para poder implementar eficientemente el resto de procesos de la gestin de la configuracin
(control, registro y verificacin y auditoras de la configuracin). Si los elementos de configuracin y su documentacin asociada no son identificados
apropiadamente, ser imposible controlar la trazabilidad de los cambios
realizados sobre dichos elementos, mantener el registro del estado de la
configuracin y llevar a cabo las correspondientes auditoras para validar
la configuracin del producto. Asimismo, las faltas o deficiencias a la hora
de documentar la configuracin, puede ser origen de defectos del producto, retrasos o sobrecostes de su operacin y mantenimiento. Los puntos
siguientes describen cada una de las tareas que constituyen el proceso de
identificacin de la configuracin.
327
Figura 13.5. Procesos de la gestin de la configuracin y sus relaciones.
328
a) Establecimiento de la estructura del producto

El proceso de ingeniera de sistemas permite ir definiendo la arquitectura fsica y funcional del producto hasta un nivel de detalle que permita
especificar y controlar las prestaciones de cada uno de los elementos que
constituyen el producto.
Como se indic en la seccin 3, los elementos de la configuracin son
las unidades bsicas de la gestin de la configuracin. Por tanto, determinar
la estructura del producto sirve de referencia y facilita la seleccin de los
elementos cuya configuracin va a ser controlada y gestionada. El control
de la configuracin de los citados elementos permite garantizar, por integracin a niveles superiores, la configuracin del producto.
Una forma grfica de visualizar la estructura de un producto es a
travs de los llamados diagramas de rbol y las descomposiciones estructuradas de producto que permiten la seleccin, identificacin y trazabilidad de los distintos elementos de la configuracin que componen
el producto.
Hasta qu nivel de detalle se ha de descomponer el producto? El nivel
de configuracin mnimo al que se ha de llegar depender del compromiso
entre la complejidad de gestionar un gran nmero de elementos y la necesidad de llegar hasta un nivel, lo suficientemente bajo, que permita acotar
posibles cambios o fallos de stos. En muchas ocasiones, el nivel de detalle
queda determinado por la poltica de mantenimiento y reparacin del producto que se determine y, por lo tanto, vendr dado por el mnimo nivel de
mantenimiento que se establezca.
b) Seleccin de los elementos de la configuracin
Establecida la estructura del producto, el siguiente paso es la seleccin
de los elementos de la configuracin que sern controlados y documentados. Conviene sealar que no todos los componentes de un sistema han
de ser elementos de la configuracin. Sin embargo, aquellos seleccionados
como tales debern tener una documentacin de configuracin asociada y
sobre ellos se aplicarn el resto de procesos, como son: el control de los
cambios de su configuracin, el registro continuado del estado de su configuracin y, sobre ellos, se realizarn las correspondientes auditoras para
verificar que las prestaciones de los distintos elementos cumplen con las
especificaciones que los originaron.
En principio deben seleccionarse todos aquellos elementos que tengan
influencia en las especificaciones asociadas a las prestaciones del producto.
Adicionalmente, deben considerarse como elementos de la configuracin
329
aquellos componentes del producto que cumplan alguna de siguientes condiciones:

t $PNQPOFOUFTDSUJDPT OVFWPTPRVFNPEJGJRVFFMEJTFP
t $PNQPOFOUFTVUJMJ[BEPTFOWBSJPTTJTUFNBT
t $PNQPOFOUFTRVFJOUFSBDUFODPOPUSPTTJTUFNBT FRVJQPTPBQMJDBciones de software.
t "RVFMMPTDPNQPOFOUFTRVFTFBOJOUFSDBNCJBCMFT
t $PNQPOFOUF RVF SFRVJFSBO VOB FOUSFHB P JOTUBMBDJO TFQBSBEB EFM
sistema principal.
t $PNQPOFOUFT DVZBT QSFTUBDJPOFT TFBO JOEFQFOEJFOUF EFM TJTUFNB
principal.
t $PNQPOFOUFTDSUJDPTPEFBMUPSJFTHPRVFQVFEBJOGMVJSFOMBQMBOJGJcacin, coste o calidad del producto.
t 5PEPTBRVFMMPTDPNQPOFOUFTRVFTFBOJNQPSUBOUFTEFTEFFMQVOUP
de vista del mantenimiento o de otros aspectos del apoyo logstico
del producto.
Durante las primeras fases conceptuales del proyecto, en las que se
establece la arquitectura preliminar del producto y se desarrolla la descomposicin estructurada del producto, los elementos de la configuracin
principales son seleccionados. sta primera seleccin sirve de base para la
posterior seleccin de elementos a niveles inferiores de la arquitectura del
producto.
c) Determinacin de la documentacin de la configuracin
Una vez seleccionados los elementos de la configuracin del producto,
el siguiente paso es la identificacin y seleccin de la documentacin que
contiene la informacin que define las prestaciones, atributos fsicos y funcionales de cada uno de los elementos de la configuracin.
Como parte de la documentacin de los elementos de configuracin,
tienen especial importancia las distintas especificaciones que se van estableciendo a medida que se avanza en su diseo y desarrollo (especificacin
del sistema y especificaciones de procesos, productos y materiales).
La configuracin final del producto ha de contener, entre otros, los siguientes documentos:
t
t
t
t
&TQFDJGJDBDJPOFTEFMPTFMFNFOUPTEFMBDPOGJHVSBDJO
&TQFDJGJDBDJPOFTEFNBUFSJBM
&TQFDJGJDBDJPOFTEFQSPDFTPT QSPEVDDJO FOTBNCMBKFZQSVFCBT

1MBOPTEFJOHFOJFSBEFMQSPEVDUPZMJTUBTBTPDJBEBT MJTUBEFQBSUFT
lista de datos, lista de subcontratistas, lista de cableados, etc.).
t %PDVNFOUPTEFSFRVJTJUPTEFQSVFCB
330
t
t
t
t
Documentos de requisitos de inspecciones.

1MBOPTEFMFRVJQBNJFOUPEFJOTQFDDJPOFTFTQFDJBMFT
1MBOPTEFVUJMMBKF
1MBOPTBVYJMJBSFT
El conjunto de la documentacin del producto (especificaciones, planos

de ingeniera y listas asociadas, requisitos de prueba, etc.) constituye el
llamado paquete de datos tcnico. En principio, cualquier empresa que disponga de los medios productivos requeridos, podra producir el producto
con esta documentacin.
Otros documentos asociados al producto, como son los manuales de
operacin y mantenimiento, ilustraciones y descomposiciones del producto, forman tambin parte de la documentacin de la configuracin.
d) Asignacin de identificadores
Una vez identificada la documentacin de la configuracin de cada elemento seleccionado, el siguiente paso es la asignacin de identificadores
que permitan relacionar de forma nica la documentacin de un elemento
con ste.
Identificar de forma clara y precisa los elementos y su documentacin
es esencial para gestionar la configuracin de forma efectiva a lo largo
del ciclo de vida, particularmente durante la fase de servicio del sistema,
ya que gracias a los identificadores es posible la eficiente gestin de los
repuestos, la identificacin de los elementos a mantener o sustituir, disponer de los manuales de instalacin, operacin y mantenimiento de estas
partes, etc.
En principio, en un proyecto se pueden utilizar identificadores propios
para la documentacin y los elementos de la configuracin de un producto.
Normalmente, las organizaciones tienen establecidos procedimientos operativos a la hora de relacionar unos elementos de la configuracin con su
documentacin. Lo importante es relacionar de forma nica la documentacin de la configuracin de un elemento con ste.
En general, al elemento de la configuracin se le asigna un Nmero de
Parte o PN). Este PN contiene el identificador del documento relativo a
la especificacin de ingeniera original del elemento. Los nmeros de documento y PNs son asignados por el departamento de ingeniera de diseo.
e) Aprobacin y publicacin de la documentacin de configuracin
El ltimo paso en la identificacin de la configuracin, es el registro y
publicacin de la documentacin aprobada de cada elemento de configuracin. Este proceso permite, a las partes involucradas en el diseo, desarrollo
331
y produccin de un producto, conocer cul es la ltima documentacin

vlida de cualquier elemento de configuracin y, por tanto, del producto
final. Permite, asimismo, el registro y control de la documentacin y de los
sucesivos cambios que se van produciendo y sirve tambin de base para
llevar a cabo las auditoras de la configuracin de un producto.
5.3. Control de la configuracin
Como se mostr en la seccin 3, el proceso de ingeniera de sistemas
seguido desde la identificacin de una necesidad hasta que se obtiene un
producto que satisface la misma conlleva el establecimiento de distintas
lneas-base. Sin embargo, stas no son fijas si no que van evolucionado a
medida que se avanza en tal proceso de tal forma que un cambio en la fase
de produccin puede llevar a que tengamos que modificar un requisito inicial y, por consiguiente, a readaptar la configuracin funcional, la asignada,
la de diseo y la de producto. stas modificaciones se relazan mediante las
los llamados cambios de ingeniera.
El control de la configuracin es el proceso encargado de la gestin,
preparacin, justificacin, evaluacin, coordinacin, disposicin e implantacin de los cambios de ingeniera que afecten a la configuracin de los
elementos de la configuracin y la documentacin de las lneas base. Su
primer objetivo es establecer y mantener un proceso de gestin de cambios
durante el ciclo de vida del producto.
Los cambios pueden deberse a naturaleza diversa como por ejemplo:
mejoras, cambios de material, interferencias, requisitos de certificacin/homologacin, nuevas necesidades, peticiones del cliente, deficiencias en el
diseo, mejora de la capacidad operativa, mejora de la seguridad del personal, eficacia y mejora de la fiabilidad, etc.
La incorporacin de cualquier cambio a la documentacin aprobada
de las lneas-base del producto debe realizarse a travs de la llamada Propuesta de Cambio de Ingeniera (PCI). ste es un documento que contiene
informacin tcnica y otros datos que permiten soportar la aprobacin e
implementacin de un cambi de ingeniera. Asimismo, este documento
permite mantener registro y control de todos los cambios de ingeniera
propuestos.
Conviene sealar que los cambios de ingeniera se clasifican en los cambios de clase I y clase II. Los cambios de clase I son cambios que tienen
un impacto importante en el proyecto y que requieren de la aprobacin
del cliente para su implantacin. Por su parte, los cambios de clase II se
corresponden con cambios menores que normalmente son implementados
con la puesta en conocimiento del cliente pero que no requieren su aprobacin expresa.
332
Con relacin a los cambios de clase I, conviene sealar que se consideran como tales aquellos que afecten a cualquiera de las lneas-base o
que puedan tener un impacto importante en la seguridad, operatividad,
mantenibilidad, efectividad del producto o sistema. Tambin son cambios de clase I todos aquellos que puedan tener un impacto negativo
en el coste, calendario, entregas, hitos y/o condiciones contractuales del
proyecto.
El proceso de gestin de los cambios de ingeniera se compone, bsicamente, de las siguientes acciones:
a) Identificacin de la necesidad de realizar un cambio. Las propuestas
de cambio pueden venir de cualquiera de los actores del proyecto ya
sea, el propio departamento de ingeniera, el usuario, el cliente, los
tcnicos de mantenimiento, el personal tcnico que opera la lnea de
produccin, etc.
b) Revisar y evaluar el impacto de implementar el cambio (prestaciones,
coste, calendario, etc.) y la viabilidad, o no, de implementar el mismo.
c) Preparacin de la correspondiente PCI.
d) Presentacin de la PCI para su aprobacin o rechazo.
e) En el caso de su aprobacin, implementacin del cambio de ingeniera y verificacin de su incorporacin en las lneas base.
La figura 13.6 muestra grficamente el proceso de gestin de una propuesta de cambio de ingeniera.
333
Figura 13.6. Proceso de anlisis y decisin de una Propuesta de Cambio de

Ingeniera.
5.4. Registro de la configuracin

El registro de la configuracin es el proceso de la gestin de la configuracin encargado de proveer de una fuente fiable de informacin relativa a
la configuracin del producto que sirve de referencia para el desarrollo de
334
las actividades tcnicas y de gestin del proyecto, as como para el apoyo

logstico del producto.
Las actividades que comprende en este proceso son
a) Registro de la documentacin aprobada y de los identificadores asignados a cada elemento de configuracin o del sistema.
b) Registro y remisin de informes del estado de los cambios de ingeniera propuestos desde la solicitud formal del cambio hasta la aprobacin final e implementacin.
c) Registro y remisin de informes del estado de todas las solicitudes
mayores y crticas de desviaciones que afectan a la configuracin de
los elementos de configuracin o del sistema.
d) Registro y remisin de informes de los resultados de las auditoras de
configuracin incluyendo el estado y disposicin final de las discrepancias identificadas y las acciones propuestas.
e) Registro y remisin de informes del estado de implementacin de los
cambios autorizados.
f) Facilitar la trazabilidad de todos los cambios acometidos desde que la
documentacin original de la configuracin de cada elemento o del
sistema fue aprobada y puesta a disposicin del proyecto.
g) Facilitar informes de la efectividad y estado de implantacin de
los cambios de configuracin de todos los elementos de configuracin o del sistema, en cualquier localizacin incluyendo
los cambios de diseo, produccin, modificacin, actualizacin
y mantenimiento.
h) Registrar todos los identificadores de los archivos de datos digitales
y representaciones de todas las revisiones y versiones de cada documento y del software que hayan sido entregadas o puestas a disposicin del proyecto por va electrnica.
El registro de la configuracin constituye el repositorio fiable de toda
la documentacin aprobada relativa a la configuracin de los distintos elementos y, por ende, del producto y se encarga de mantener al
da, para cada elemento de la configuracin, el estado de los cambios
y desviaciones propuestas y aprobadas.
335
5.5. Verificacin y auditoras de la configuracin

Los ltimos procesos de la gestin de la configuracin que se aplican al
final del desarrollo de un producto, antes de establecer definitivamente la
lnea base del producto y previamente al comienzo de su produccin en
serie son:
a) Verificacin de la configuracin. Este proceso tiene por objeto garantizar que los elementos de la configuracin y el producto final
cumple con las prestaciones detalladas en las especificaciones y que,
fsicamente, coincide con el diseo realizado por el departamento de
ingeniera. Este proceso se implementa mediante las llamadas pruebas de verificacin de la configuracin. La verificacin de la configuracin se realiza fsica y funcionalmente.
La verificacin funcional de los elementos de la configuracin y del
producto, conlleva la ejecucin de un plan de pruebas y demostraciones para asegurar los aspectos del aseguramiento de la calidad establecidos en las especificaciones relativas a las prestaciones. El plan
de pruebas comprende las correspondientes pruebas de calificacin
y certificacin. Una vez pasadas stas, se puede asegurar que los elementos de la configuracin y por ende, el producto cumple con los
requisitos originarios.
Por su parte, la verificacin fsica de los elementos y el producto
permite certificar que el producto, tal y como finalmente ha sido
fsicamente fabricado (as-built configuration), coincide con el diseo (as-designed configuration). Esta verificacin se lleva a cabo
mediante inspeccin fsica, uso de pruebas dimensionales, el control
de los procesos, etc.
b) Auditoras de la configuracin. El objeto de este proceso es garantizar que los elementos de configuracin y el producto final han
pasado todas las pruebas de verificacin, garantizndose as, que el
producto cumple los requisitos de las especificaciones, y que stos,
quedan completamente documentados.
Al igual que en la verificacin, se llevan a cabo dos tipos de auditoras: las auditoras funcionales y las auditoras fsicas. stas se realizan
antes de la aceptacin de los elementos de configuracin y previamente al establecimiento de la lnea-base del producto final.
Las auditoras funcionales de la configuracin se utilizan para verificar que las prestaciones de los elementos de la configuracin y el
producto final cumplen con los requisitos establecidos en la especificacin inicial de prestaciones. Para ello, se comprueba en primer lugar que los requisitos funcionales de los elementos de configuracin
y del producto han sido sometidos a las correspondientes pruebas
336
de verificacin funcional. En segundo lugar, se comprueba que los

elementos y el producto han pasado satisfactoriamente estas pruebas.
La verificacin se realiza auditando la documentacin que registra los
planes, procedimientos y resultados de las citadas pruebas.
Las auditoras fsicas de la configuracin tienen por objeto verificar
que el producto ha sido fsicamente como fue diseado y, para ello,
se examina que los elementos de la configuracin y el producto final
han sido sometidos a las pruebas de verificacin fsica, y los resultados de las mismas son satisfactorios. Para ello se auditan los planes,
procedimientos y resultados de las citadas pruebas, que obviamente
estn relacionados con las especificaciones, planos, modelos y datos
tcnicos elaborados por el departamento de ingeniera en las fases de
diseo y desarrollo.
Normalmente las auditoras fsicas se realizan con posterioridad a las
auditoras funcionales de la configuracin y, como se ha indicado
anteriormente, una vez pasadas satisfactoriamente las auditoras funcionales y fsicas se establece la configuracin final del producto.
Completada y aprobada la auditora, se puede asegurar entonces la consistencia entre el producto, configuracin y su documentacin tcnica; cometido ste de la gestin de la configuracin.
6. REFERENCIAS
ANSI/EIA-649, National Consensus Standard for Configuration Management.
MIL-HDBK 61B, Configuration Management Guidance, Septiembre 2002.
MIL-STD-973, Configuration Management.
IS0 10007, Quality Management-Guidelines for Configuration Management.
ANSI/EIA-632, Processes for Engineering a System.
NASA-STD-0005, NASA Configuration Management Standard.
ASME Y14-100M, Engineering Drawing Practices.
MIL-STD 490, Specification Management.
WATTS, F. B., Engineering Documentation Control Handbook, Third Edition, Editorial William Andrew, 2008.
HASS, A. M. J., Configuration Management Principles and Practice, Editorial Addison-Wesley, 2003.
PROJECT MANAGEMENT INSTITUTE (PMI), Practice Standard for Project Configuration
Management, 2007.
ESA, Training Small-Medium Sized Enterprises (SME) Initiative, http://www.esa.int/
SPECIALS/Events_Training/SEMNNWK8IOE_0.html.
NASA, Systems Engineering Handbook, NASA/SP-2007-6105, Rev.1, 2007.
INTERNATIONAL COUNCIL ON SYSTEMS ENGINEERING (INCOSE), Systems Engineering
Handbook, Ver. 2.0, July 2000.
337
CAPTULO 14
RECUPERACIN DE PROYECTOS
Enrique Rodrguez Segura
1. INTRODUCCIN
La realidad muestra que en ocasiones los proyectos no logran alcanzar
los objetivos previstos o se producen importantes desviaciones en costes
y plazo sobre las previsiones iniciales de la propia compaa o las de los
clientes. El xito de un proyecto es de difcil definicin, habitualmente
se ha considerado la exigencia de cumplir con coste, plazo y calidad del
producto o servicio esperado por el cliente, pero en un sentido holstico
deben considerarse otras dimensiones adicionales como son el prestigio,
o ser un paso importante en las estrategias de la compaa. Cuando se
tiene que hacer frente a situaciones complicadas en los proyectos la perspectiva depender del papel que se juega: si es de lder en un proyecto
se necesita desarrollar una solucin, si el rol es ser el responsable de rea
de proyectos necesitar saber si estn realmente en dificultades y orientar
a cmo resolver la situacin y en el caso de ser usuario o cliente de un
proyecto se precisar reconocer la importancia de las dificultades y crearse una opinin, para saber si son adecuadas las medidas que el equipo
del proyecto est tomando.
En todos estos casos, una vez analizada la situacin y posibilidades, hay
que enfrentarse a la decisin ms importante: cancelar el proyecto o abordar su recuperacin. Este captulo desarrolla una estructura metodolgica
para detectar los sntomas de un proyecto en dificultades, la evaluacin de
la situacin, las posibles estrategias a adoptar y el desarrollo de los pasos
339
pertinentes para elaborar la recuperacin de proyectos en varios supuestos, especificando los elementos necesarios que ha de contener el plan a
desarrollar. Las actuaciones dirigidas a culminar el proyecto con xito se
denominan Recuperacin de proyectos o por su denominacin en ingls
poner el proyecto Back on track.
2. QU ES UN PROYECTO EN DIFICULTADES
2.1. Cuntos proyectos fallan realmente?
La investigacin ms exhaustiva sobre el tema que desde hace aos se
viene realizando es la del Standish Group International Inc., sobre proyectos de Sistemas de Informacin, que son proyectos que suelen presentar
ms problemas que los industriales o de servicios, esto muestra que en los
ltimos aos ha mejorado el porcentaje de los proyectos que han terminado
con xito. Los ltimos datos disponibles, del ao 2009, indican que el porcentaje de proyectos fracasados fue del 44%; los que han tenido problemas
y que han terminado tarde, ms costosos o con menores funcionalidades de
las inicialmente requeridas fue del 24% y los que han tenido xito, fueron
el 32%. Un nmero muy importante sin duda.
2.2. Proyectos de riesgo
En este mismo estudio para el Standish Group International Inc, los
proyectos que presentaron menor riesgo son aquellos de corta duracin,
menos de seis meses, con equipos de menos de seis personas y con un
presupuesto menor de 750.000 $.
Por otro lado, segn los datos disponibles al analizar los proyectos fallidos o que presentaron dificultades, se concluye que los problemas se
dan ms frecuentemente en los que tienen un gran tamao, lo que implica
gran complejidad; en aquellos que incorporan tecnologas en un estado de
madurez precaria al comienzo del proyecto y en aquellos que no cuentan
con un decidido apoyo de la direccin. Este tipo de proyectos los podemos
calificar de proyectos de riesgo.
340
2.3. Cundo se detecta un proyecto en dificultades?

En general, los proyectos sufren a lo largo de su vida diversos avatares.
Todos, en algn momento, presentan problemas o dificultades aunque en
la mayora de los casos se solventan con medidas concretas y acciones
del equipo de proyectos. Sin embargo, en muchos casos, trascurre mucho
tiempo hasta que se toma conciencia de que realmente el proyecto est en
dificultades.
Una referencia la encontramos en el trabajo llevado a cabo por el Cutter
Consortium en 2005, realizado sobre proyectos de sistemas de informacin,
acerca de conocer en qu momento o etapa del proyecto se detecta que
estn en serios problemas. Los datos indican que la mayora, el 39%, los
problemas se descubren cerca del fin previsto o cuando termina; el 29% en
la primera mitad o cuarto del proyecto y el 15% despus de una ampliacin
o ms del proyecto.
A la vista de los datos se puede comprobar que la mayora de las organizaciones no son sensibles a las seales de dificultades en los proyectos,
concluyendo que se identifican o se toma conciencia de ellos, en general,
demasiado tarde.
2.4. Por qu se ignoran las seales de alarma?
Los equipos que ejecutan los proyectos cuentan con herramientas eficaces de gestin, sin embargo, cuando los problemas aparecen no se acta
en consecuencia en la mayora de la ocasiones. Puede parecer un cierto
contrasentido, pero tiene mucho que ver con las actitudes humanas. Estas
tienden a esconder los problemas o a dificultar el reconocimiento de una
situacin problemtica. Se denominan distractores a: la negacin de la realidad; al miedo a ser considerado el culpable de la situacin; al miedo a que
se considere que no se est preparado o capaz para el cometido; a la actitud
de soberbia para no reconocer que se est equivocado; al sndrome de que
la culpa siempre es de otros o que el cliente pide la luna
Los equipos que realizan los proyectos en general adquieren un importante compromiso personal con lo que hacen, cmo van a responder con
objetividad si el proyecto empieza a fallar? es una conducta humana. En los
aos cincuenta, en la Universidad de Stanford, [Festinger, 1957] explicit la
tendencia de las personas a ignorar los conflictos o problemas cuando aparecen si colisionan con sus creencias. Su teora denominada la Teora de
la disonancia cognoscitiva indicaba que cuando se apoya con intensidad
el proyecto en el que se est implicado, se tiene la tendencia a ignorar los
signos negativos que aparecen y, sin embargo, se amplifica los pequeos
xitos aunque sean irrelevantes para el fin global del proyecto, con el obje-
341
tivo de reconfortarse o bien inspirar confianza. Esta aproximacin lleva a no

tomar medidas adecuadas hasta que el proyecto falla completamente.
Adicionalmente la cultura de las empresas puede ser una causa para no
reconocer los problemas. Uno de los casos ms famosos y estudiado ha sido
el los problemas de la NASA con la sonda MARS [Sauser, 2009], llegando a
la conclusin de que la cultura en aquella poca de la NASA, junto con su
poltica de reduccin de costes aplicada a ultranza, llevaron a la gerencia a
obviar las seales y los fallos con graves consecuencias para el proyecto. El
diagnostico acorde a una cultura determinada impidi ver los problemas
a travs de los signos que aparecieron.
Ante estas dificultades, que en muchos casos provienen de la actitud
de las personas y de las organizaciones, se ha de utilizar una metodologa
objetiva que permita identificar las seales de alarma.
2.5. Sntomas
Los proyectos en dificultades son aquellos que presentan sntomas recurrentes que hacen sospechar que la situacin no es un mero problema
puntual o pasajero, sino de fondo. Estos sntomas se pueden agrupar en:
Gestin del proyecto: no parece haber una idea clara de cundo se
terminar o cunto costar el proyecto.
El proyecto presenta problemas para conocer cundo se terminar y
cules son los costes reales del proyecto: en el caso ms extremo, es cuando el equipo de proyecto o su lder, manifiestan claramente su inseguridad
o incapacidad de dar una fecha de terminacin con argumentos convincentes y verificables.
Un proyecto que presenta en su primer tercio del plazo deslizamientos
o retrasos en la finalizacin de actividades o en sus hitos, tiene grandes
posibilidades de no acabar en los plazos previstos, ya que la recuperacin
de plazo en las etapas posteriores, es mucho ms difcil. Hay que prestar
especial atencin a la aparicin de continuos deslizamientos de plazo, que
en la mayora de las ocasiones se resta importancia por parte del equipo
de proyecto, argumentando que hay mrgenes internos y que no afectar
a la fecha final. Cuando estos deslizamientos se dan en actividades criticas
del proyecto o que se pueden convertir en crticas, se debe actuar decididamente para evitar mayores problemas.
Problemas con los costes del proyecto: cuando aparecen nuevas partidas de coste que no estaban consideradas, o partidas con costes reales muy
dispares sobre los previstos, tanto excesos como defectos, que indican una
previsin inicial errnea dar la seal de intervenir.
342
Se prestar atencin especial a los deslizamientos de plazo ya que inciden directamente en un incremento de coste: A mayor prolongacin ms
coste y se denominan costes dependientes del tiempo y han de ser tenidos
en cuenta cuando el proyecto presenta retrasos o deslizamientos.
Producto: el producto o sistema generado, tiene muchos errores o fallos,
o los requerimientos cambian o se modifican con frecuencia.
Se entiende por el producto como las diferentes formas del resultado final generado por el proyecto: un producto fsico, un programa de software
o la creacin de un servicio o programa de ayuda, etc.
Los problemas de calidad del producto pueden aparecer desde el principio, al revisar los diferentes entregables que el proyecto genera a lo largo
de su vida, como son los estudios o diseos del producto final. Tambin se
revisar si por motivos de retrasos, se han acortados periodos de pruebas
de los diversos subsistemas dando por hecho que estn bien y sin embargo
pueden ocasionar problemas adicionales en el ltimo periodo de integracin por ser de compleja y larga solucin.
Por otro lado un sntoma es tambin la peticin de cambios o modificacin en los requerimientos contractuales del proyecto por parte del cliente.
La carencia de estabilidad de requerimientos, que puedan afectar a requerimientos bsicos o principales, es una fuente de conflicto segura y pueden
hacer peligrar el proyecto. La vigilancia o comprobacin de este hecho es
importante para detectar si puede o est afectando a un proyecto.
Cliente: el cliente ha perdido la confianza.
Cmo se pierde la confianza del cliente en un proyecto? Se pierde no
slo por los problemas que puedan aparecer en un proyecto o los fallos en
el producto, sino por la incorrecta comunicacin y la falta de transparencia
y credibilidad provocada por la continua informacin errnea o tergiversada, que se le facilita al cliente. En el actual mundo competitivo es muy
frecuente que los equipos del proyecto atenen la gravedad en determinados momentos del proyecto, o que se oculten parte de la informacin de
la situacin y ofrezcan al cliente una visin optimista que posteriormente
no se cumple, generando una desconfianza extrema y esta no es la forma
adecuada de tratar los problemas. Adicionalmente si los fallos o errores en
el proyecto son detectados antes por el cliente, junto con la falta de capacidad de respuesta y la no resolucin, es causa de la prdida de confianza
del cliente.
Equipo del proyecto: los sntomas centrados en el equipo del proyecto
podemos describirlos como: los miembros del equipo trabajan demasiadas
horas, no es posible realizar un seguimiento del proyecto, el equipo adopta
una actitud defensiva, la rotacin de los componentes del equipo o la comunicacin es muy deficiente.
343
Cuando un equipo de proyecto presenta un nivel importante de estrs,

visible por una desmesurada dedicacin y en muchos casos una actitud de
irascibilidad, trasluce problemas. Puede ser causado por un dimensionamiento inadecuado del equipo del proyecto, por los problemas existentes
o por la personalidad del director del proyecto, pero en cualquier caso es
un aviso de problemas.
Esta situacin suele venir acompaada con una actitud defensiva del
equipo, al ser requerido para dar explicaciones o bien culpa a terceros de
la situacin: cliente, suministradores o subcontratistas. En ocasiones el sntoma se descubre por una rotacin excesiva de los miembros del equipo
de proyecto que indica el efecto de abandono de barco y es una seal de
alarma que debe poner en la pista para investigar las causas de tal efecto.
Por ltimo, se detectan problemas de comunicacin cuando miembros
del equipo ignoran elementos o instrucciones que les ataen, por falta de
comunicacin. El caso del autismo como forma de gestin de algunos
tipos de responsables, es un ejemplo de ello.
Las relaciones entre diversos actores son malas: en un proyecto se
presentan dos conjuntos de actores: por un lado los que corresponden a la
organizacin que ejecuta el proyecto y por el otro a los actores externos.
En la organizacin del proyecto se distinguen: el director del proyecto,
su equipo, las organizaciones funcionales o los recursos que lo ejecutan directamente, los subcontratistas, la organizacin de trabajadores y sindicatos,
y la direccin de la compaa.
En la organizacin cliente puede existir una organizacin tambin de
direccin de proyecto, en forma de espejo a la del proyecto que supervisa
la ejecucin o bien ser su usuario, y la direccin o jerarqua que ha encargado el proyecto.
Por ltimo, estn los actores externos que pertenecen a otros grupos de
inters y que pueden tener una determinada influencia por verse afectados de alguna manera por la ejecucin del proyecto o sus resultados. Son
ejemplos de este grupo los ciudadanos u organizaciones que pueden verse
influenciados por el resultado y la puesta en marcha del proyecto.
Adems, cuando las relaciones entre los actores empiezan a deteriorarse bien por razones de diferentes intereses u objetivos contrapuestos,
deficiente o nula comunicacin o por un deterioro de las relaciones personales se presenta un problema que tambin puede poner en riesgo el
proyecto.
En resumen, la lgica de una situacin problemtica de un proyecto se
debe identificar por medio de los Sntomas, que deben de dar una alerta.
Estos apuntan a los problemas del proyecto y, profundizando en ellos, se
debe llegar a las razones que los originan. Mitigar o eliminar los problemas
nos llevar a corregir la situacin del proyecto.
344
2.6. Causas
Ahora se concentra la atencin, en la estructuracin de las causas que
hacen que un proyecto presente serios problemas:
Las causas son diversas y en la mayora de las ocasiones no se presentan
solas sino en combinacin, complicando la situacin. Se agrupan en seis
situaciones principales que permiten ilustrar la casi totalidad de los casos
posibles.
t 1SPZFDUPTDVZPTPCKFUJWPTTPOEFNBTJBEPBNCJDJPTPTPJOBMDBO[BCMFT
(En comparacin con otros proyectos anteriores de la compaa o de
la competencia).
t Proyectos a los que se les ha asignado recursos insuficientes
(humanos o materiales).
t 1SPZFDUPTRVFQSFTFOUBOFSSPSFTEFHFTUJO
(Inadecuadas tcnicas de gestin para ese tipo de proyecto).
t 1SPZFDUPTDPOJOBEFDVBEPFRVJQPEFHFTUJO
(El lder o el equipo no tienen el conocimiento tcnico o la preparacin de gestin requerida).
t 1SPZFDUPTRVFOPDVFOUBOPRVFQJFSEFOFMBQPZPEFMBEJSFDDJOEF
la compaa.
(Falta del apoyo o incluso la amenaza de toda o parte de la direccin).
t 1SPZFDUPTFORVFMBBQBSJDJOEFVOBOVFWBUFDOPMPHBEFVOQSPEVDto de la competencia que lo hacen intil, superado o inservible.
Ante estas situaciones hay que reconsiderar la situacin de proyecto,
estableciendo un anlisis que lleve a un diagnstico de sus causas y de las
posibilidades de recuperacin.
2.7. Seales de la crisis a travs de la medicin: mtricas
Las seales tambin pueden ser objetivas y cuantificables y las denominamos mtricas. Lo constituyen el conjunto de valores numricos que
podemos obtener de un proyecto y que ayudaran a observar posibles valores de crisis. Las mtricas se contienen en los informes de seguimiento del
proyecto y se refieren a los siguientes conceptos:
Planificacin: indica cul es la situacin de avance en plazo del proyecto, si se encuentra en lo previsto, dentro de un margen estrecho y razonable
o por el contrario presenta una importante desviacin.
Mtrica de planificacin: desviacin en tiempo del proyecto completo o
de sus actividades principales, respecto a la previsin. Si el proyecto cuenta
con una planificacin detallada observar si la cadena crtica (Critical Chain
345
Project Management, CPM) del proyecto, presenta desviacin del plazo

puede ser muy significativo.
Avance fsico del proyecto: el sistema de avance del proyecto, de sus
tareas o paquetes de trabajo, ha de ser mediante un sistema objetivo. Siempre que sea posible debe basarse en un elemento fsico a realizar, as el
avance es medible y objetivo. Todos los proyectos contienen elementos a
realizar como planos, estudios, informes, pedidos de compra, elementos a
construir como toneladas de acero o de hormign, instalaciones, lneas de
cdigo a programar en proyectos de Software o mdulos de programas, un
servicio a crear, prototipos o pruebas de subsistemas y sistemas, etc, por lo
que se puede medir.
Mtrica de avance fsico: las magnitudes fsicas consideradas en el proyecto y su porcentaje de realizacin. No es preciso tomar todas sino las ms
significativas.
Coste: el control presupuestario se realiza por la comparacin entre la
imputacin al proyecto de los costes incurridos con la previsin presupuestaria inicial. La extrapolacin a fin del proyecto no tiene por qu ser lineal
pero muestra una referencia de la situacin.
Mtrica de coste: la mtrica a considerar es la desviacin en coste de
las tareas realizadas tanto en magnitud como en porcentaje sobre el presupuesto total.
Recursos: los recursos humanos disponibles en el proyecto. Se comparar la previsin de recursos con la disponibilidad de recursos.
Mtrica de recursos: se utiliza como medida, el grado de utilizacin de
recursos respecto a la previsin hasta la fecha y el ratio de trabajo pendiente
de realizar y los recursos disponibles.
Pedidos de compras y contratos: los pedidos a realizar y los contratos previstos son una parte significativa del proyecto, las empresas compran servicios, componentes o equipos tanto para realizar el producto,
como para las instalaciones para fabricarlos. Si los pedidos y los contratos estn realizados en la fecha prevista implica que se han realizado
las actividades previas de definicin y seleccin, y estarn listos en su
momento.
Mtrica de compras: la mtrica a considerar es el nmero de pedidos y
contratos realizados y los que no, en fecha y el tiempo medio de desviacin
sobre la previsin.
Calidad: la situacin de la calidad del proyecto se ve reflejada en los
ndices de calidad que presenta y que se registran. Tanto las No conformi-
346
dades internas o del cliente, como los fallos detectados que llevan a repetir
trabajos realizados.
Mtricas de calidad: nmero de no conformidades y nmero de retrabajos o defectos.
Fig. 14.1. Esquema de mtricas ms significativas.
Como resumen, las mtricas de planificacin y costes son las ms significativas en cuanto a sealar la situacin del proyecto y el resto de mtricas
nos ayuda a perfilar donde se reflejan los problemas, aunque las causas
puedan estar detrs de las mtricas que son la consecuencia. La obtencin
de mtricas significativas es ms sencilla y visible si el proyecto tiene un
sistema de seguimiento basado en el valor ganado, mediante el cual, como
se ha visto en el captulo 6, las posibles desviaciones en la programacin y
en el coste del proyecto, son evidenciadas a travs de la comparacin de
los valores de los coeficientes Schedule variance (SV) y Cost variance
(CV).
Es importante una vez consultadas estas magnitudes, enfrentar la referencia con los estndares actuales de la compaa para juzgar si la situacin
se mantiene en los niveles habituales o si realmente son seales de alerta.
347
2.8.
Proyectos imposibles, cuando los objetivos superan el 50%

de un proyecto normal
Existe un grupo especfico y diferencial del conjunto de los proyectos en

problemas y cuyo tratamiento es diferente al resto. stos son los denominados proyectos imposibles:
Los Proyectos imposibles, que existen en mayor nmero de lo que podramos imaginar, se definen como aquellos que superan los requisitos considerados habituales en un 50%. Esta referencia se refiere a la comparacin
con proyectos anteriores de la compaa o de la competencia. Los casos
que se pueden encontrar se agrupan por sus caractersticas, en:
t 1MB[PFODVBOUPBMQMB[PSFRVFSJEPFTDMBSBNFOUFJOGFSJPSBMBNJUBE
de lo que racionalmente o por comparacin se precisa.
t -PTSFDVSTPTIVNBOPTFMQFSTPOBMBTJHOBEPFTDMBSBNFOUFJOGFSJPSB
la mitad del que se asignara a un proyecto de estas caractersticas.
t -PTSFDVSTPTFDPONJDPTFMQSFTVQVFTUPFTMBNJUBEEFMRVFIBCJtualmente se asignara a un proyecto de estas caractersticas, o bien
se ha recortado a la mitad del inicial.
t -BTGVODJPOBMJEBEFTSFRVFSJEBT MPTSFRVJTJUPT VPUSPTBTQFDUPTUDOJcos son superiores al doble de lo normal.
t &M QSPZFDUP QMBOUFB VOPT PCKFUJWPT OVODB DPOTFHVJEPT QFSP TF IB
planteado el proyecto como si fuera un desarrollo conocido.
Entre el espectro de razones para que se produzcan, las ms habituales
son:
t 3B[POFTQPMUJDBTRVFTPOMBTPSJHJOBEBTFOFMTFOPEFMBTFNQSFTBT
o instituciones, que en un momento dado por las circunstancias se
embarcan en esta aventura, sin evaluar las consecuencias o considerar que no tienen otra opcin, con el consiguiente riesgo de suicidio
empresarial.
t 3B[POFTEFQSPNFTBTJODPOTDJFOUFTFODVBOUPBTVUSBOTDFOEFODJB P
ingenuas realizadas por los directivos de la empresa a clientes.
t -PDVSBDPSQPSBUJWB FTEFDJS SFQFUJSMPTNJTNPTFSSPSFTZFTQFSBSRVF
lo resultados sean mejores.
t &MPQUJNJTNPKVWFOJMDBQB[EFDSFFSEFTFSDBQBDFTEFBMDBO[BSDPUBT
inimaginables, y luego hay que hacer frente a la cruda realidad.
t -BNFOUBMJEBEFNQSFOEFEPSB UBOOFDFTBSJB RVFFOPDBTJPOFTFYDFde los lmites posibles.
t .FOUBMJEBEEFBWFOUVSFSPPEFiMFHJPOBSJPwOPWJPEFMBNVFSUF"VUP
explicativo.
t $PNQFUFODJBNVZJOUFOTB HMPCBMJ[BDJO OVFWBTUFDOPMPHBTy
&TUF
caso es importante y habitual, y suele ser motivado por amenazas
348
muy graves a la rentabilidad de una empresa, ocasionando una respuesta, no siempre sensata.
t $SJTJTJOFTQFSBEBTZOPQMBOJGJDBEBT"MJHVBMRVFMBBOUFSJPS BMTPbrevenir circunstancias no planificadas que requieren de respuestas
extraordinarias.
t &TUPT QSPZFDUPT JNQPTJCMFT RVF QSFTFOUBO PCKFUJWPT EJGDJMFT P BQBrentemente inalcanzables en ocasiones hay que acometerlos, en cuyo
caso el problema no est solo en los objetivos sino en abordarlos
como si fueran proyectos normales y no concebirlos de una forma
adecuada a su riesgo, con los medios y recursos adecuados.
3. RECUPERACIN
3.1. Opciones y plan de recuperacin
Cuando hay que enfrentarse a una situacin de recuperacin de proyectos se ha de tener en cuenta, en primer lugar, cules son las condiciones del
mandato recibido de la compaa o institucin, en los trminos en los que
se ha producido y qu se espera exactamente. Las condiciones impuestas
son las que marcarn el tipo de decisin posible, en cuanto a continuar o
sugerir cancelar el proyecto, y en el caso de continuar, darn la pauta para
escoger la estrategia ms adecuada a implantar. Una primera regla a seguir
es sin duda la trasparencia de la informacin como base fundamental de la
relacin, tanto respecto a la direccin que encomienda el mandato, como
hacia el equipo del proyecto. La verdad puede ofender, pero no ofrecer la
verdad es mucho ms daino. La tica debe ser la norma que gue en todo
momento la actuacin.
La primera duda a despejar es si el proyecto debe cancelarse, si bien
hasta no tener un conocimiento amplio de la situacin, la precipitacin no
es aconsejable.
Si el proyecto hay que recuperarlo, no necesariamente se podrn cumplir las expectativas iniciales, pero s acercarse a ellas, las cuatro estrategias
de recuperacin posibles como indica la figura 14.2 bsicamente son:
t
t
t
t
3FEVDJSMBFOWFSHBEVSBEFMQSPZFDUP
*ODSFNFOUBSMBQSPEVDUJWJEBE
"TVNJSRVFFMQSPZFDUPOPUFSNJOBSBUJFNQP
6OBDPNCJOBDJOEFMPTUSFT
La primera estrategia consiste en la reduccin de la envergadura del proyecto para establecer una dimensin o amplitud abordable y viable a conseguir en el marco de coste y tiempo dados. Para ello, hay que disminuir
349
la amplitud del proyecto, rebajando las especificaciones o requerimientos a

alcanzar del producto o servicio. En este supuesto debe de acordarse con
el cliente y con la direccin de la empresa, la disminucin de las expectativas iniciales hasta un nivel que sea aceptable para ellos y basndose en un
planteamiento de viabilidad.
La segunda estrategia consiste en mantener el proyecto en sus expectativas iniciales de especificaciones o requerimientos, su coste y su plazo,
ya que podra ser viable y aumentar la productividad con la que se realiza. Es aplicable a proyectos donde es manifiesto que el equipo que ha
desarrollado el proyecto no ha aplicado las tcnicas de gestin adecuadas
a este tipo de proyectos, o bien los recursos son escasos y es francamente mejorable su ejecucin, pero tcnicamente es alcanzable. Deberemos
centrarnos en actividades clave del proyecto para conseguir mejoras en
el corto plazo y apoyarnos en estos xitos a corto plazo, para volver a la
senda correcta.
La tercera estrategia se aplica en aquellos casos en que el proyecto es
viable, pero precisa un plazo mayor y seguramente un mayor coste. Es importante que se adopten las oportunas medidas de control de daos, es
decir, que minimicemos el impacto en coste y plazo de aquellas actividades
que estn en peligro o ya se han desviado del plan inicial. Esa estrategia
tambin impone un acuerdo con el cliente y con la direccin que encarga
el proyecto, y demostrar que es la alternativa ms viable en cuanto a recuperacin.
Estas son las estrategias que podemos considerar puras, en cuanto a
qu hay que hacer para recuperar un proyecto. Ahora bien, en muchos
proyectos, hay que adoptar una estrategia mixta de combinacin de las
anteriores. Esta estrategia consiste en eliminar funciones o caractersticas
reduciendo la envergadura sin perder las claves, aumentar la productividad
de las actividades y ajustar el programa aumentando el plazo y el coste,
para ello combinamos las tres estrategias anteriormente descritas. Estas estrategias son indicadas para proyectos que son prcticamente viables pero
sus previsiones de plazo y coste son cortas y la gestin no hay sido con la
productividad requerida.
350
Fig. 14.2. Esquema de etapas de la Gua de recuperacin de Proyectos.
En cualquiera de las situaciones el plan tiene que estar pactado con todos los diferentes actores y apoyado por todos. No es aconsejable tomarse
mrgenes excesivos, ya que puede ser que superen los lmites que podra
aceptar el cliente y, por conservadores, arruinemos el proyecto y una marcha atrs restara toda credibilidad a la propuesta. Por ltimo un equipo
motivado, convencido del plan y con el apoyo de gerencia y cliente es la
base del xito.
3.2. Guas operativas de recuperacin
A continuacin se desarrolla una gua operativa que muestra el proceso
de una forma holstica, es decir, completa e integral, por donde se debe
transitar para ejecutar el trabajo.
Gua operativa de recuperacin

Reconocimiento
de sntomas
Evaluacin
de situacin
Plan de
recuperacin
Decisin
Ejecucin
del Plan
Revisin
a posteriori del Plan
Fig. 14.3. Esquema de etapas de la Gua de recuperacin de Proyectos.
351
a) Reconocimiento de sntomas
En primer lugar hay que considerar si realmente el proyecto puede presentar una situacin instantnea de dificultades o realmente tiene que ser
intervenido. En el punto 2.5 se han revisado los diferentes sntomas y sus
descripciones que se pueden observar en los proyectos candidatos. Se incluye a modo de ayuda un listado de los sntomas que anteriormente se haban establecido, desarrollndolos, para reconocerlos y ordenarlos a modo
de lista de comprobacin, constituyendo una gua de identificacin y nos
permita valorar la importancia de la situacin mediante la siguiente tabla:
rea a revisar
Gestin del
proyecto
Producto
Cliente
Contenido
Sntoma
Dudas en fecha finalizacin

Desviaciones en primera parte del
proyecto y continuas
Planificacin
Desviacin en actividades crticas
Ver mtricas
Aparicin nuevas partidas coste
Desviaciones sobre previsiones
Costes
Rendimientos deficientes
Deslizamientos por plazo
Insuficiente o pobre definicin de
requerimientos
Errores en entregables
Calidad e
Frecuente correccin de trabajos
incumplimientos
Problemas en pruebas subsistemas
Cambios de requerimientos
Deficiente control configuracin
Informacin sesgada
Ocultacin de problemas
Dudas. Desconfianza Desconfianza
Enfrentamiento con el equipo del
proyecto
352
S/NO
rea a revisar
Contenido
Organizacin del
trabajo y recursos
humanos
Equipo del
proyecto
Seguimiento del
proyecto
Actitud del equipo

Comunicacin
Relaciones con
stakeholders
Sntoma
S/NO
Recursos insuficientes (inadecuada

estimacin del trabajo)
Composicin inadecuada del equipo
Exceso de horas trabajadas
Rotacin excesiva del personal
Dependencia de bomberos
ilustrados
Falta de estructura de seguimiento
Informacin inadecuada o incompleta
Periodos de seguimiento muy
espaciados
Carencia de gestin de riesgos
Actitud defensiva y no transparente
Enfrentamientos entre el equipo
Falta de comunicacin entre las reas
diferentes
Falta de soporte de la direccin
Problemas con los funcionales, los
subcontratistas o sindicatos
Enfrentamientos con las autoridades o
grupos locales
Problemas por diferentes objetivos o
expectativas
Tabla 14.1. Lista de comprobacin para la identificacin

de sntomas de un proyecto.
La utilizacin de esta lista de chequeo, no implica que un proyecto presente todos los sntomas. En cada caso hay que encontrar varios de estos
sntomas ya que no suelen aparecer solos, sino simultneamente. Estos
elementos son la base de la evaluacin a desarrollar.
b) Evaluacin de la situacin
La primera etapa se ha centrado en si existan o no sntomas de problemas en el proyecto, ahora se trata de evaluar la amplitud o importancia de
los diferentes elementos. El proceso para la evaluacin se realizar mediante los siguientes pasos, observando la mayor objetividad posible:
353
c) Evaluacin cualitativa
Revisin de la informacin escrita, oficial del proyecto, tanto los informes
de avance, los informes internos, actas de reunin del proyecto, as como
los informes a la direccin y las actas de las reuniones con el cliente.
Entrevista con el director del proyecto y con el equipo del proyecto.
Pueden ser con el equipo completo, pero con las personas claves se recomienda que se realicen entrevistas individuales.
Entrevista con la direccin, tanto el responsable inmediato del proyecto
como el resto de la direccin que puede estar afectada por el resultado del
proyecto.
Entrevista con el cliente: esta se realizar con la aprobacin previa de la
direccin de la compaa.
Entrevistas con otros posibles grupos externos que tuvieran inters si
procediera y tambin previa aprobacin con la direccin.
Este proceso de entrevistas ha de realizarse estructuradamente, apoyndose en la lista de comprobacin (ver tabla 14.2) para la evaluacin. La
lista est elaborada de forma que cubra todos los aspectos ms relevantes y
permita un orden en la evaluacin que servir para hacerse ms fcilmente
con la situacin. Cuando se realiza se revisa el estatus de estos elementos, y
en simultneo, se evala la magnitud del problema del elemento revisado.
Cada elemento se calificar como problema o no, y se adicionan los detalles
y su magnitud. Por ltimo, al igual que los sntomas se proceder a estructurarla en los mismos grupos de elementos: gestin del proyecto; producto,
equipo del proyecto, cliente y grupos de inters.
La ltima columna se refiere a la evaluacin de cada elemento, que
puede hacerse cualitativamente pero es aconsejable mediante puntuacin
(en %, del 1 al 5). As podemos obtener una referencia de cumplimiento
segn la escala elegida.
354
rea
Elemento
NO S
Contrato y Especificacin (C. y E.):

definicin adecuada y precisa del
producto/servicio
C. y E.: interpretaciones diferentes
de requisitos contractuales y/o
tcnicos con el cliente
C. y E.: seguimiento de requisitos
del clientes: sistemas y grado de
cumplimiento
C. y E.: cambio de requisitos:
situacin e impacto
Utilizacin de los procedimientos
de empresa por el Equipo de
Proyecto
Adecuacin y cumplimiento de
procesos: diseo, revisiones de
diseo, produccin y pruebas de
subsistemas y sistemas
Sistema de seguimiento del
proyecto y situacin:
Gestin del - WBS (Estructura de tareas)
Proyecto
- Planificacin general
- Cadena crtica
- Coste
- Valor ganado
Sistemtica de informacin:
precisin y frecuencia
- Gestin de riesgos
- Control de configuracin
- Dimensionamiento de recursos/
tareas
Compras: adecuacin de contratos,
su planificacin, su seguimiento,
reclamaciones
Subcontratacin: adecuacin
de contratos, adecuacin de los
subcontratistas en calidad, recursos,
planificacin e integracin con el
proyecto. Reclamaciones
Relaciones y eficacia de las
direcciones funcionales
355
Detalle/
Evaluacin
Magnitud
Plan de calidad: adecuado, efectivo

y homologado
Datos de calidad: no
conformidades, fallos, etc.
Costes de no calidad
Producto
Prototipos: situacin y
retroalimentacin a diseo
Cumplimiento de requisitos
funcionales
Validez tecnolgica del producto
Liderazgo y adecuacin del director
del proyecto
Miembros del equipo adecuados a
tareas
Equipo de Adecuacin del plan de formacin
del equipo
Proyecto
Comunicacin entre el equipo y
con el cliente
Posibles conflictos en el equipo
Actitud del equipo
Estado de relaciones con el cliente
Cliente
Desavenencias y conflictos tcnicos
o econmicos
Evaluar el soporte de la direccin
Gerencia de
la compaa Alineacin con la poltica de la
empresa
Otros
Conflicto o choque de intereses con
colectivos
terceros
con inters
Tabla 14.2. Lista de comprobacin para la evaluacin del proyecto.
Evaluaciones cuantitativas
Una vez realizada la evaluacin cualitativa se ha de evaluar de forma
cuantitativa. En el apartado 2.7 de mtricas, se han revisado cules son
recomendables y cmo se calculan. Las magnitudes ms relevantes son, la
planificacin, el coste y la calidad, y no se puede realizar una evaluacin
completa sin medir como estn estas magnitudes. Mediante las curvas del
sistema de valor ganado (ver captulo 6) se puede evaluar la situacin actual, tanto en la planificacin como el coste, mediante sus coeficientes y
tendencias.
Tambin hay que revisar la disponibilidad de recursos del proyecto para
evaluar la adecuacin de las previsiones de necesidad a la disponibilidad.
356
Para completar la evaluacin de magnitudes se revisarn los aspectos de calidad mediante las no conformidades y de compras los pedidos y contratos
mediante la comprobacin del estatus de emisin de pedidos en funcin de
las previsiones tanto para las compras de elementos y equipos del producto, as como de instalaciones si se requieren.
Hay que tener presente que si se sigue haciendo de la misma forma,
obtendremos los mismos resultados que antes.
d) Decisin
La decisin a tomar tendr un componente subjetivo, pero no ser arbitrario y se basar en los principios de gestin de la compaa. No obstante,
podemos establecer unos trminos de referencia que nos orienten en la
toma de la decisin:
La evaluacin ha de realizarse con rigor y basada en datos para terminar
con conclusiones claras. En funcin de las desviaciones que el proyecto
presenta sobre la previsin, junto con las causas y la filosofa de la compaa, hacen que se concluya razonadamente con una propuesta de las
posibles: el proyecto no presenta una situacin de intervencin sino precisa
de ajustes para corregir algunos problemas; el proyecto debe ser cancelado;
por ltimo el proyecto requiere una intervencin y puede recuperarse.
Intervencin del proyecto para una recuperacin
Desviaciones en planificacin o costes:
La situacin citada puede darse bien por la incapacidad de la gestin,
la dificultad tcnica o cuando los recursos humanos o econmicos no son
capaces de llevar el proyecto sobre la planificacin prevista. Algunos autores establecen que un proyecto entra en crisis cuando su planificacin o su
coste exceden un 30%. Sin embargo, no se debe permitir que un proyecto
llegue a estas cifras sin intentar una recuperacin, ya que un nivel del 30%
puede ser ya una situacin irreversible, unas cifras del 5-10% es una desviacin que da la seal de intervencin, segn el tipo de proyecto. Las desviaciones en la cadena crtica, aunque sean pequeas o el incumplimiento
de algn hito importante del proyecto, requieren la accin de intervencin
inmediata por la dificultad de recuperacin.
357
Errores en el producto
La previsin o dudas de cumplimiento de requerimientos de primer nivel, los continuos cambios o falta de estabilidad en los requerimientos por
parte del cliente o la repeticin de falta de calidad en los entregables aconsejan la intervencin.
Cliente
Si el cliente manifiesta la falta de confianza en el equipo o en la empresa,
o por incumplimientos por ser ste un elemento clave, es aconsejable la
intervencin.
Equipo de proyecto
Segn la situacin del equipo: la falta de seguridad y convencimiento
de que no lideran y controlan el proyecto, la falta de asuncin de responsabilidad culpando a los actores externos (cliente, suministradores, etc)
y que no se cumplen los planes previstos, nos indica que el proyecto debe
de intervenirse.
En caso de la recuperacin, debe indicarse cuales seran las lneas maestras o claves del Plan de recuperacin y la estrategia posible. No se trata de
realizar un plan detallado de recuperacin pero si de orientar y soportar la
conclusin elegida. En este momento, una vez obtenidas las conclusiones
del informe de evaluacin, ha de tomarse la decisin. sta deber proponerse a la Direccin y acordarse con ella. Si ha de proponerse al cliente
depender en cada proyecto de cul es la relacin con ste, ya que la
continuidad o viabilidad pueda depender en gran medida de la posicin
que tome. Igualmente se aplicara a algn grupo de inters cuya influencia
pueda resultar decisoria en la toma de una decisin final.
Cancelacin
Hay varias situaciones en las que la cancelacin es inevitable y podemos
enunciar las principales:
Se producir cuando las prdidas que se prevn en el proyecto exceden
el lmite soportable por la empresa. En segundo lugar, si aparece una tecnologa que puede batir el proyecto en curso superndolo y hacindolo intil.
Tambin cuando el proyecto presenta objetivos inalcanzables y la gestin
realizada no es capaz de dirigir el proyecto obteniendo pasos firmes en la
consecucin del objetivo. Por ltimo, si el proyecto ha perdido el soporte
de la direccin de la compaa es lgica su cancelacin.
358
e) Elaborar plan de recuperacin

Para elaborar el plan se establecen una serie de condiciones previas a
tener presentes:
El planeamiento de la recuperacin ha de estar bien sustentado en una
correcta evaluacin tanto cualitativa como cuantitativa y estar diseada para
su implantacin rpida.
La ejecucin debe de ser perfecta, por lo que se requiere una planificacin slida y detallada. Es muy importante la motivacin del equipo elegido
para la recuperacin, que tiene que tener el convencimiento que con el
plan se puede llevar adelante el proyecto. Si es preciso se debe cambiar al
director del proyecto y al equipo o parte de l. Este punto es aconsejable en
la mayora de los casos, por la implicacin personal que tiene.
Decidir cul de las cuatro estrategias de recuperacin va a ser la elegida
ya que condicionar el desarrollo del plan. Ser muy realista y actuar con
transparencia y con una aproximacin tica.
A continuacin se procede a desarrollar las categoras principales de la
recuperacin. El plan debe de estructurarse en tres categoras, y que tengan
en cuenta a todos los actores:
t 1FSTPOBM
t 1SPDFTPTZIFSSBNJFOUBT
t 1SPEVDUP
Los actores a considerar sern al menos la direccin que patrocina o encarga el proyecto, el cliente y/o usuario y el jefe del proyecto, el equipo del
proyecto y de las direcciones funcionales que realizan la ejecucin.
Acciones que el plan debe contener para cada categora:
Personal
Esta categora es vital para el xito de la recuperacin, ya que un equipo
adecuado, cohesionado, convencido y adecuadamente liderado es una de
las claves ms importantes del xito.
En la mayora de los casos se comienzan las actuaciones enfocndolas
a solucionar los problemas de personal. La recuperacin de la moral del
equipo es un paso fundamental y se comenzar decidiendo si su composicin actual es la adecuada. Para ello habr que decidir si es idneo
continuar con el director del proyecto y el equipo o cambiarlos y sopesar si hay que incorporar nuevas personas. La posterior restauracin del
liderazgo se basara en dar el adecuado apoyo y poder al director y a su
equipo. Una vez establecido el nuevo equipo se comunicar el plan y
objetivos a abordar.
359
Adems habr que acometer acciones para un funcionamiento eficaz

del equipo mediante la claridad de roles y responsabilidad, crear una estructura para administrar el tiempo para el mximo rendimiento (reuniones,
informes, etc.), asegurar la correcta comunicacin interna y revisar la formacin del equipo y establecer un plan de formacin, si fuera preciso, en
temas puntuales. Por ltimo, dejar que los distintos miembros se ajusten a
la nueva situacin. Una vez en funcionamiento es muy til consultar con el
equipo para obtener ideas adicionales.
Procesos y herramientas
Se tendr en cuenta que hay que corregir la fuente de los problemas.
Corregir los procesos que no funcionan correctamente tanto de gestin,
seguimiento y control del proyecto.
En primer lugar, abordaremos la planificacin: preparar una nueva planificacin con hitos a corto plazo y definir la nueva lnea base del proyecto
que lleve al fin acordado. Ahondando, se definir la cadena crtica de la
planificacin para un seguimiento ms eficaz. Una vez preparada la nueva
planificacin se procede a la restructuracin del presupuesto que es probable que sea necesario, o al menos una revisin al haber reformado la planificacin, en concreto si se retrasa el proyecto. Por ltimo se comprueba
la adecuacin de recursos procediendo a una nueva previsin (incremento
o disminucin). Se comprobar el plan de compras y subcontratacin, revisndolo y adecundolo.
Con referencia a los procesos hay que identificar y corregir los errores
de procesos. Proceder a la reingeniera de los que no se cumplen. Es aconsejable crear acontecimientos en miniatura para buscar pequeos xitos a
corto plazo, para que ayuden en la confianza del plan.
Teniendo en cuenta que se trata de una intervencin, se definir e implementar un plan de riesgos con contramedidas y su seguimiento estricto.
En caso de haber detectado problemas de comunicacin o de confianza
ser necesario tambin un plan de comunicacin. Un elemento importante
es definir un proceso de seguimiento completo, fiable y constante del proyecto, que permita detectar y corregir nuevos errores.
Producto
Para los aspectos relacionados con el producto, hay que abordar la
clarificacin o en su caso la reforma de los requisitos, por lo que hay que
asegurar primero el entendimiento de los requisitos con el cliente y segundo documentarlo. Es crtico el establecer los requisitos mnimos y claves,
al igual que asegurar la estabilidad y congelacin de requerimientos del
cliente.
360
Se proceder a rehacer los trabajos o entregables mal realizados,

para corregir los defectos de calidad. Tambin es necesario un plan de
contingencia de calidad para la mejora de los procesos que generan
defectos.
f) Ejecutar el plan
Para ejecutar el plan, lo ms importante es que la direccin, el cliente, el
equipo y los posibles grupos de inters estn convencidos de que es el plan
adecuado a realizar y contar con su apoyo. En segundo lugar, es importante
que el momento sea el adecuado, ni tarde ni pronto. Un plan precipitado
y poco slido provocara efectos adversos y una tardanza injustificada pondra en duda nuestra solvencia para este trabajo. Hay que tener presente
que hay una serie de elementos que son claves o elementos crticos para
tener xito en el empeo:
Con respecto a los actores involucrados en general, hay que asegurarse que todos tienen un entendimiento de la situacin real del proyecto,
comparten la solucin y adquieren un compromiso de llevarlo a cabo. Un
elemento adicional es la gestin eficaz de la comunicacin.
Con respecto al equipo, dotarse del equipo que es necesario e investirle
de autoridad y responsabilidad. Dotarse de las habilidades y las capacidades
que el proyecto requiere y mantener un liderazgo firme, tico y continuado.
En el enfoque al desarrollo del proyecto hay que centrarse en los problemas
o amenazas principales, en primer lugar de manera intensa. Por supuesto la
revisin constante del estado del proyecto, comprobar resultados y corregir
las actuaciones si fuera necesario.
En ocasiones y dependiendo de la situacin especfica del tipo de problemas, en la etapa de recuperacin se recurre a un equipo especifico de
gestores y/o tcnicos de gran solvencia, que actan sobre problemas especficos para resolverlos sin que afecte o paralice el avance completo del
proyecto.
Frecuentemente en la ejecucin del plan se encuentran sorpresas adicionales a las previstas inicialmente, que pueden obligar a nuevos ajustes y
se realizarn a la luz de la estrategia definida. Por tanto, el seguimiento del
plan es tan importante como su ejecucin. El plan requerir un seguimiento
muy estricto y la evaluacin continua comprobando como sigue el plan
previsto y tomar acciones correctivas cuando sean necesarias. Se aconseja
adoptar una aproximacin del crculo de calidad; planeamiento, ejecucin,
comprobacin y acciones correctivas, mediante un proceso contino en
todo el desarrollo.
361
g) Revisar el plan a posteriori

Una vez terminado el proyecto con xito, es muy til la revisin y documentacin de las lecciones aprendidas. No slo por una reflexin personal,
sino para poder dejar constancia a la compaa, como detectar a tiempo
los problemas y cules han sido las claves de la recuperacin, qu funcion bien (procesos, herramientas y elementos personales) y qu no lo hizo
razonadamente.
No hay que olvidar la felicitacin a los que contribuyeron decididamente
a recuperar al proyecto.
4. RECUPERACIN DE PROYECTOS IMPOSIBLES

Como anteriormente se explic, los proyectos imposibles son aquellos
que superan con creces las dificultades normales para una feliz conclusin.
Las razones por las que uno, se ve o quiere verse, involucrado son muy
variadas y pueden responder a razones muy personales o de compaa. El
xito en este tipo de proyectos es siempre dudoso. No hay recetas milagro
que sean capaces de conseguir lo imposible. Adicionalmente a la gestin
ordinaria, una aproximacin extra nos ayudar a limitar los daos que
finalmente puedan ocurrir. Es aconsejable un primer anlisis:
Quin es quin: la identificacin de los diferentes actores es el primer
paso e incluir la identificacin de los principales roles: el promotor, el
cliente, el director, el equipo, el ejecutor y si existen otros externos como
los consultores y qu papel juegan.
Identificar el nivel de compromiso de los participantes. Es importante
entender cules son los compromisos personales y profesionales de los
miembros del equipo, para averiguar la naturaleza del proyecto, binomio
recompensa-probabilidad de xito.
En cuanto a la gestin, decidir utilizar las herramientas de gestin de
proyecto ms idneas para el tipo concreto de proyecto al que nos enfrentamos y una gestin del personal activa que evite un efecto defensivo y nos
lleve al fracaso.
Este anlisis que podemos denominar un anlisis poltico es de gran
ayuda para entender el punto de partida de los que estn alrededor del proyecto y nos permitir conseguir un mejor nivel de motivacin y alinear los
esfuerzos del equipo en favor de un mejor resultado. Los siguientes pasos
estn encaminados a conseguir una negociacin de condiciones tolerables, de lo posible y alcanzable que haga factible terminar el proyecto con
xito. Es en un proyecto de estas caractersticas, donde es muy posible que
no se puedan alcanzar los objetivos fijados, ser preciso poder negociar un
362
conjunto de condiciones que puedan ser alcanzables y a su vez sean tolerables para las autoridades implicadas. Para ello hay que conocer tanto
como sea posible el contenido real del proyecto, por lo que se utilizarn
aquellas herramientas que nos faciliten estimaciones objetivas del trabajo
a realizar. Para las estimaciones es aconsejable establecer un intervalo de
confianza (optimista, ms probable y pesimista).
Se ha de conocer las implicaciones y lmites del cliente. Un retraso o
fracaso y qu efecto le producira. Es muy frecuente que se tenga que enfocar, como en la regla del 80/20, en un grupo principal de caractersticas.
Conocer los objetivos realmente importantes y prioritarios asegura su cumplimento con el cliente.
En la negociacin se debe contar con el apoyo de la compaa (patrocinador y ejecutores) y se ha de conseguir del cliente, que pueda compartir
un cierto grado de incertidumbre en la duracin, ligado a la propia incertidumbre de la definicin que deber despejarse con el tiempo. La relacin
basada en una buena comunicacin con el cliente ser vital para un desarrollo acordado.
El ltimo paso sera el relacionado con los elementos de la gestin de
proyecto: una gestin del personal activa que evite un efecto defensivo y
nos lleve al fracaso. Un proyecto de este tipo lleva a direcciones de tipo
defensivo, con una burocracia para defenderse, el equipo fragmentado y en
conflicto, etc. Por eso, la gestin del equipo basado no slo en sus capacidades tcnicas, sino en un gran conocimiento de su situacin y motivacin
personal, ser una parte esencial para mantener el espritu de equipo y
conseguir una eficaz gestin.
Para la gestin de los requisitos utilizar una aproximacin basada en las
tcnicas del Triage. La tcnica del Triage es la utilizada en los hospitales
para dirigir a los posibles pacientes que llegan a urgencias, en funcin del
anlisis de entrada para una clasificacin que permite la ms rpida y adecuada atencin.
La tcnica del Triage se utiliza para distinguir y clasificar los requisitos
o caractersticas del proyecto: los que deben satisfacerse; los que deberan
satisfacerse y los que podran satisfacerse. Esta clasificacin permitir establecer la prioridad de los requisitos y as centrar por un lado, los recursos
y esfuerzos en ellos, y conseguir ms fcilmente una negociacin con el
cliente.
Utilizar las herramientas de gestin de proyecto ms idneas para el tipo
concreto de proyecto al que nos enfrentamos. Segn la dificultad y la naturaleza del proyecto hemos de aplicar unas u otras herramientas de gestin.
Es aconsejable utilizar una planificacin en niveles, detallada basada en
estimaciones fsicas y paramtricas y un seguimiento muy frecuente, sistema
de cadena critica CPM, sistemas de valor ganado. Adicionalmente aplicar
363
una gestin de costes detallada, una gestin de recursos, la creacin de un

Plan de Gestin de Riesgos y por ltimo un Plan de Calidad.
En definitiva, prepararse desde el inicio y controlar el proyecto en todo
momento, con el apoyo de todos los stakeholders posibles. Esto no garantiza el xito a priori, pero si saber en todo momento cual es la situacin para
la toma de las decisiones ms adecuadas.
5. CASOS REALES
Con objeto de ilustrar los procesos descritos, a continuacin se describen
dos casos reales de recuperacin de proyectos, que muestran la necesidad
del reconocimiento de la situacin de crisis de un proyecto y la necesidad
de una estructuracin del proceso de recuperacin.
5.1. Programa A400M de AIRBUS

En mayo de 2003 la compaa AIRBUS (EADS) firm con OCCAR, que es
una organizacin internacional para la gestin de programas militares formada por varios pases europeos, un contrato para suministrar 180 aviones
de transporte militar de nuevo diseo, denominados A400M.
A finales de 2008, EADS anunci un aplazamiento indefinido del primer
vuelo del A400M por los problemas aparecidos que declaraba: el sistema de
propulsin (nuevas turbinas) no estaba listo y los requerimientos tcnicos
eran tan desafiantes que estaban ocasionando muchos retrasos. La importancia del proyecto para la compaa era tal, que podra poner en riesgo
la supervivencia de sta y an ms, daar irreparablemente el proceso de
xito de la construccin aeronutica europea, en la que tanto empeo y
esfuerzo se haban puesto. La compaa, despus de un anlisis de la situacin, que llevaba dando sntomas de estar fuera de control ya un tiempo,
fue consciente de la gravedad y decidi poner todos los medios a su alcance para reconducirla.
La situacin era ms compleja y los sntomas detectados no slo eran los
declarados: el equipo de proyecto no era capaz de gestionar el programa a
la vista de la complejidad que haba adquirido, existan graves problemas
de coordinacin entre reas y el equipo estaba desanimado. El producto
presentaba fallos porque los requerimientos de los diferentes clientes eran
muy diversos y acumulativos, la obligacin de cumplir los requerimientos
de la aviacin civil era ms exigente de la esperada y los proveedores de
sistemas no eran capaces de resolver todos los problemas de cumplimiento
e integracin de los mismos. A esta situacin se aada que la turbina de
nuevo diseo, realizada por un consorcio europeo, presentaba problemas
364
y no estaba lista. Por ltimo, los clientes, que a pesar de ser institucionales,
presentaban serias dudas sobre el xito del mismo y ya haban mostrado su
preocupacin y malestar por la marcha del proyecto, cuyos problemas eran
un secreto a voces dentro y fuera de la compaa.
Ante esta situacin, la direccin de AIRBUS tom la decisin de poner
en marcha un programa de actuaciones para recuperar el proyecto, que
denomin el A400M Booster Plan. Para ello, la primera fase fue pactar
con los clientes un plan viable y creble. La estrategia elegida seria de combinacin: se basara en renegociar los contratos con los clientes, converger
algunas de las especificaciones tcnicas, incrementar la productividad para
resolver los problemas y atrasar el plan a una fecha viable. Para ello se
cambi el equipo que lideraba el Proyecto y cont con un apoyo directo y
continuo de la direccin al ms alto nivel.
Para alcanzar los objetivos de requerimientos, plazo, coste y calidad, el
plan se dirigi a seis lneas principales: a) restaurar la eficacia en los procesos del programa (procesos); b) mejorar los sistemas y prcticas de la
gestin del proyecto (procesos); c) acelerar el proceso de la convergencia
tcnica entre las especificaciones de requerimientos (producto); d) preparar
el lanzamiento industrial del programa (proceso); e) fomentar el trabajo
colaborativo (personal) y f) reconstruir la confianza de los clientes y otros
grupos de inters.
El resultado fue el esperado y se realiz el vuelo del prototipo segn lo
planeado y el programa est en la primera fase de produccin y entrega de
las primeras unidades, habindose recuperado el proyecto. Hoy se puede
decir que el proyecto es un xito aunque haya tenido importantes retrasos
y los clientes hayan tenido que soportar un precio mayor por las unidades
y soportar econmicamente a la compaa.
5.2. Buque Ferry de pasajeros y camiones para las Islas Feroe

(Dinamarca) de IZAR
A mediados del ao 2002 la compaa IZAR, resultante de la unin en
el ao 2000 de las empresas espaolas de Construccin Naval mercante
y militar, firm un contrato para la construccin de un buque Ferry con
el Gobierno de las Islas Feroe (Dinamarca) en uno de sus astilleros del
Sur de Espaa, habitualmente dedicado a la construccin militar. Este buque sustituira a los viejos buques de los aos cincuenta, que permitan el
trasporte de personas y mercancas entre islas, vitales para el desarrollo
de stas. La crisis desatada en el sector constructor por la apertura de un
expediente de la Comisin Europea en Bruselas sobre las ayudas pblicas
en el 2004, haba desembocado en la formacin de una nueva compaa
ms reducida NAVANTIA, y la necesidad de un duro plan de ajuste. Una de
365
las consecuencias es que se haba paralizado, por las huelgas habidas en

el proceso, la construccin del buque durante casi cuatro meses y adems
haba enmascarado una situacin ms grave en cuanto a la situacin del
proyecto en s.
La direccin de la nueva compaa NAVANTIA en 2004, mantuvo una
reunin con los responsables del proyecto donde manifestaron: su inexperiencia en este proyecto, que era un buque ms complejo de lo inicialmente
previsto; las exigencias de calidad del cliente; las dudas sobre la fecha de
entrega, que estaba muy cercana; los problemas tcnicos no resueltos y las
reclamaciones de las empresas contratistas, que no haban podido trabajar
en meses y amenazaban con abandonar. Ante esta situacin la direccin
tom la determinacin de intervenir el proyecto.
En primer lugar, la direccin encarg a un grupo de ingenieros, de gran
experiencia en este tipo de buques de otros astilleros del grupo, realizar un
informe que contuviera un anlisis de situacin, una evaluacin fsica del
trabajo a realizar que identificara los problemas y las posibles soluciones y
por ltimo la preparacin de un plan de recuperacin en un plazo de un
mes. En el informe el grupo manifest que al barco le quedaba la mitad del
trabajo por realizar, por lo que el tiempo necesario para acabar el proyecto
sera de varios meses ms de los previstos, lo que llevara a la cancelacin
del contrato y que sera preciso contar con nuevas empresas y expertos
concretos en varias reas.
Ante tal situacin la direccin opt por poner en marcha un plan, con
una estrategia basada en: a) negociar con el cliente unas nuevas condiciones contractuales de fecha de entrega y de evitar la cancelacin en base
al nuevo plan; b) negociar con los sindicatos su apoyo; c) poner al frente
un nuevo equipo de otro Astillero con poderes para ejecutar el proyecto,
con un coste razonable y sin modificar los requerimientos del producto;
d) todo el plan estara controlado de cerca por la direccin y tendra su
apoyo.
Una vez negociado se puso en marcha, y en los aspectos de gestin
se concret en: a) poner al frente un nuevo Director de Proyecto que era
el jefe del grupo que efectu la evaluacin con un grupo de expertos de
soporte (Personal); b) se form un grupo de apoyo con expertos de otros
astilleros con mucha experiencia en reas concretas crticas, desde ingenieros a operarios altamente cualificados (Personal); c) se implant una nueva
planificacin y un sistema de hitos a corto plazo, realizado por expertos de
planificacin y control de costes en este tipo de buques (Procesos); d) se
renegociaron los contratos con los suministradores principales (Procesos);
e) se implant una nueva sistemtica de seguimiento del proyecto semanal
y una mensual con la direccin, que haba encargado el programa (Procesos) y f) se establecieron una serie de reuniones con los representantes del
366
cliente y con la autoridad del pas de destino, para aclarar y negociar todos
los puntos de dificultad en los requerimientos del proyecto, de las normas
a aplicar y congelar posibles nuevos cambios (producto).
Una vez trascurrido la mitad del tiempo restante, los resultados presentaban algunas deficiencias y no estaba en lnea con las expectativas previstas,
haban aparecido problemas tcnicos no esperados debidos a errores anteriores, por lo que la direccin tom la decisin de cambiar la direccin del
Astillero con objeto de acelerar el plan que conoca desde su implantacin.
Una vez se hubo hecho cargo, procedi a ajustar algunas de las acciones
para mejorar el rendimiento: i) se dio plenos poderes al director del proyecto y se asignaron recursos estables al proyecto para asegurar su disponibilidad, cambiando su organizacin para ser ms dinmica (personal);
ii) se realizaron varias reuniones con el equipo del proyecto ya ampliado
para obtener sugerencias sobre las actuaciones y reforzar y mejorar la moral
del equipo (personal); iii) se implant un sistema de unidades fsicas para
evaluar cada una de las actividades de planificacin y su avance real y a
la planificacin se le aadi el sistema de cadena crtica (proceso); iv) se
increment el presupuesto disponible (procesos) y v) se rehicieron algunos
de los sistemas del buque para que cumplieran con las especificaciones
acordadas con el cliente (producto).
Finalmente, se termin el proyecto en el plazo acordado con el cliente
y con los estndares pactados, aunque el coste del plan fue superior a lo
inicialmente previsto.
6. REFERENCIAS
FESTINGER, L., Theory of Cognitive Dissonance, Stanford University Press (June,
1957).
SAUSER, B. J., REILLY, R. R. & SHENHAR, A. J., Why projects fail How contingency
theory can provide new insights-A comparative analysis of NASAs Mars Climate
Orbiter loss, International Journal of Project Management, vol. 27, 7, 2009, pp.
665-679.
367
CAPTULO 15
PROYECTOS INTERNACIONALES
Alejandro Molns de la Fuente
1. INTRODUCCIN
En este captulo se introduce lo que significa, en la gestin de un proyecto, lo internacional, es decir su realizacin/gestin en un entorno geogrfico distinto del habitual de una empresa. El captulo va a estudiar en primer
lugar el importante valor de las diferencias existentes cuando se trabaja en
otros mercados, referencias a las diferencias culturales, polticas, religiosas,
legales, etc. En segundo lugar, se van a describir aspectos especficos de la
negociacin en el marco internacional. Lgicamente, esto tiene una relacin
directa con la adaptacin del proceso negociador al mercado concreto en el
que se va a trabajar y al anlisis que se haga de las diferencias existentes. En
tercer lugar, se trabajar sobre las caractersticas especficas de los contratos
en el entorno internacional. En cuarto lugar, se van a analizar los posibles
riesgos que en un proyecto internacional se pueden encontrar, bien sean de
naturaleza poltica, econmica o comercial, y las alternativas que se pueden
utilizar para minimizar o evadir dichos riesgos. En ltimo lugar, pero no
menos importante, se hablar de RR.HH. en los proyectos internacionales,
referencias a la utilizacin de personal local o expatriado, condiciones de
contratacin, etc.
Por tanto, en este captulo de proyectos internacionales se van a buscar
aquellos aspectos que les diferencian, entendiendo que es un proyecto que
se desarrolla fuera de las fronteras del pas de la empresa, que supone la
aparicin de un marco jurdico, aduanero, econmico y cultural diferente.
369
Se tendrn, por tanto, que analizar cuidadosamente estos aspectos diferenciales y realizar las oportunas adaptaciones al entorno concreto.
2. ELEMENTOS CLAVE EN LA INTERNACIONALIZACIN

El objetivo es reflexionar acerca de uno de los elementos clave en la
internacionalizacin de la empresa. En funcin del pas en el que se trabaje
hay que descubrir y analizar aquellos aspectos (culturales, legales, econmicos, etc.) que son diferentes y a los que, por tanto, hay que adaptarse,
como se ve en la figura 15.1. Lgicamente, como la internacionalizacin es
una de las estrategias de crecimiento que las empresas acometen, la respuesta a la pregunta anterior implicar estrategias de accin, para evitar que
esas diferencias sean una barrera de entrada al nuevo mercado. El diseo
de la oferta deber ajustarse a las necesidades y expectativas de los clientes
locales.
Figura 15.1. Diferencias en los mercados.
Hay que aclarar que el trabajo en los mercados exteriores no se basa,

por tanto, en reglas de aplicacin homogneas para todos los casos, sino
que la decisin debe ser considerada dentro de cada empresa en particular,
de forma que su orientacin estratgica acte como un elemento determinante del peso de cada factor. En cualquier caso este abanico de opciones
est frecuentemente fundado en el conocimiento adquirido a lo largo de
los aos, en la experiencia acumulada y en la informacin disponible en
370
ese momento, todos ellos ingredientes bsicos de una decisin racional y

prudente para determinar los riesgos y dificultades de acceso a los mercados internacionales, que se agrupan bajo el epgrafe barreras de acceso.
Se incluyen las siguientes variables.
2.1. Entorno poltico
Los cambios polticos pueden ser factores determinantes (favorables o
desfavorables) de los intercambios a nivel internacional. Hay pases que
ofrecen oportunidades importantes (acuerdos comerciales, tratamiento favorable a las empresas extranjeras), por eso se tiene que conocer la situacin de cada pas (o por lo menos de una importante cantidad de ellos), a
travs de los informes que se publican regularmente por entidades pblicas
y privadas. Lo relevante para las empresas y el responsable del proyecto es
conocer las condiciones polticas (que pueden ser absolutamente distintas a
las del pas de la empresa) en las que va a trabajar para que sus actividades
tengan en cuenta el entorno y eviten problemas con las autoridades locales
y su ordenamiento legal. En muchos pases se da una integracin no solo
de elementos polticos, sino tambin religiosos y culturales. La empresa y
los responsables del proyecto deben monitorizar permanentemente estos
aspectos, ya que cualquier descuido puede ser devastador. Tambin conviene conocer la posible animadversin o favorable actitud ante el pas de
la compaa del proyecto que traer consigo una mejor o peor percepcin
de la empresa, sus productos o servicios.
2.2. Entorno cultural
Es uno de los aspectos diferenciales ms relevantes en la prctica y
que sin embargo no suele despertar excesiva atencin en las empresas. La
distancia cultural puede definirse como la diferencia percibida por los
exportadores entre el mercado de origen y el de destino, basndose en el
lenguaje, los hbitos de negocio, el entorno poltico, legal, las prcticas para
la comercializacin y el marketing de sus productos y servicios. En las fases
iniciales de la internacionalizacin, las empresas demuestran una fuerte
preferencia por culturas prximas y comparables, con una distancia cultural
menor, para ir disminuyendo esta tendencia paulatinamente debido a la
experiencia y conocimiento adquiridos. A veces las diferencias culturales
de los mercados no justifican que se deban adoptar estrategias que adapten
la empresa a cada mercado particular. En otras ocasiones se adoptan estrategias de tipo global, considerando las caractersticas culturales similares
y obviando las que son distintas. Hay autores que indican que un elevado
371
porcentaje de errores en las operaciones u operaciones fallidas se deben a

estas diferencias culturales [Cervio, 2006; Fanjul, 2013].
La cultura tiene variables tan importantes como: hbitos, comportamientos, gustos, actitudes, valores, esttica, etc. Y muchas veces nos olvidamos de la transcendencia de estas variables, intentando introducir polticas
que se han seguido con xito en un mercado, trasladndolas a otros. Parece
evidente que no sera una buena idea organizar el comedor de una obra en
un pas musulmn donde se sirvieran comidas (cerdo) o bebidas (alcohol)
a los empleados locales, independientemente de que fuera una prctica
habitual en la matriz. Los responsables de los proyectos debern tener en
cuenta todos estos aspectos a la hora de poner en marcha el trabajo. Especial atencin merecern elementos como vestimenta (importante en algunos pases, en referencia a la mujer), cdigo de lenguaje (uso de trminos
malsonantes), etc.
La empresa y los responsables de los proyectos internacionales tienen
que ser conscientes de los desafos impuestos por un contexto globalizado
e interconectado. La exposicin a culturas de distintos pases obliga a prepararse, no solo al responsable del proyecto, sino a toda la organizacin.
Hay que desarrollar empresas culturalmente abiertas, inteligentes y adaptables a distintos entornos.
La empresa debe ver en la diversidad cultural una oportunidad estratgica y se debe reflejar internamente en aspectos como la seleccin
interna de personas que puedan comunicarse de forma adecuada con
otras culturas, la formacin interna con expertos interculturales, es decir,
creando una organizacin que integre en todas sus reas capacidad para
trabajar en entornos culturalmente diferentes. Desde el punto de vista
prctico el responsable del proyecto debe buscar atraer y seleccionar profesionales culturalmente inteligentes y facilitar a los mismos capacitacin
y formacin para incrementar sus posibilidades de entendimiento cultural
en los pases en donde se vaya a desarrollar el proyecto. No solo se trata
de idiomas y formacin curricular, hay que buscar tambin actitudes que
faciliten esa adaptacin.
a) Idioma
La lengua es la diferencia ms obvia entre las diferentes culturas. En el
mundo hay aproximadamente 200 pases, donde se hablan 3.000 lenguas
con 10.000 dialectos. Normalmente en los proyectos se utilizar una lengua
franca, en muchos de los casos el ingls, pero para evitar susceptibilidades las empresas deben utilizar, en lo posible, el idioma local, teniendo
en cuenta los giros, expresiones, argots, signos y mmicas, habitualmente
utilizados en el pas.
372
Hay que tener en cuenta que en ciertas culturas hay diferencias importantes entre lo que se dice y su significado real, como es el concepto del
tiempo (ahorita mismo), en otras las formas de saludo (nuestra costumbre inveterada del tuteo universal), el lenguaje corporal, la costumbre de
los regalos (no hablamos de corrupcin), que obligan a entender los usos
correctos desde el punto de vista local. Por ltimo, los aspectos que se
pueden o no hablar, si uno es extranjero, con las personas locales (humor,
bromas, poltica, religin, etc.).
Los responsables de los proyectos deben instruir al personal que vaya a
trabajar en un pas en concreto sobre usos correctos o incorrectos e incluso
facilitar una gua sobre los mismos. En muchos pases el uso de una frase en
el idioma local en un momento adecuado (comidas, cenas, negociaciones)
puede ser un factor decisivo. Y, por ltimo, hay que entender que usar el
mismo idioma local no garantiza un perfecto entendimiento. El castellano, el
francs, el ingls, nos ofrecen abundantes muestras de ello (ver tabla 15.1).
b) Educacin, actitudes, valores y esttica
En todos los pases el nivel de educacin condiciona al comprador y habitualmente suele coincidir con nivel de desarrollo econmico. Hay modelos de educacin ms abiertos a productos extranjeros y ms exigentes con
la compra o valoracin del servicio. Los valores y actitudes determinan lo
que se considera correcto o apropiado, lo que es importante y lo que es deseable. Los gustos, apreciacin de los colores, formas, msica, diseo, etc.,
varan segn las culturas. Estas diferenciaciones afectan a las decisiones de
compra de productos de consumo, no as a los productos industriales.
La empresa debe cubrir necesidades, pero adems en condiciones aceptables para el tipo de sociedad al que se dirige. Los responsables de un
proyecto han de valorar aquellos aspectos que puedan suponer susceptibilidad o choque con los valores considerados como aceptables en el pas
del proyecto. Sociedades como la coreana o la japonesa consideran sus
niveles de calidad como los ptimos, por tanto, en un proyecto en el que
se trabaje con o para empresas de estos pases habr que vigilar un estricto
cumplimiento de las normas, plazos y estndares de calidad. Tambin hay
que evitar valoraciones o expresiones que puedan herir a los responsables
locales (referencias a la tecnologa, avances industriales, formacin).
El responsable del proyecto tendr en cuenta, especialmente, estas actitudes y valores cuando contrate y trabaje con personal local. En algunas
culturas los retrasos, la impuntualidad, el rendimiento, la calidad, no son
necesariamente valores negativos. El responsable, cuando planifique el proyecto, debe tener en cuenta estos aspectos para evitar complicaciones en la
ejecucin (falta de horas de trabajo, revisiones de calidad, etc.).
373
Tabla 15.1. Blog de Juan Carlos Andreu (www.juancarlosandreu.com).
374
2.3. Entorno legal y geogrfico

El comercio y las inversiones internacionales estn regulados de distinta
forma por los gobiernos. La empresa debe informarse de las distintas legislaciones sobre las formas de entrada y trabajo en los mercados. En todos
los pases existen una serie de barreras arancelarias y no arancelarias que
pueden afectar al proyecto, como son:
Restricciones legales, para que las empresas extranjeras operen en
determinados sectores.
La necesidad de disponer de autorizacin administrativa para el desarrollo de ciertas actividades.
Otras barreras tcnicas, como homologaciones y certificaciones.
Otras barreras de naturaleza fiscal.
Es aconsejable recurrir a expertos legales locales para aclarar los posibles riesgos a los que nos enfrentamos. Las distintas legislaciones suponen
barreras a la internacionalizacin de las empresas, puestas para preservar
(proteger) las industrias nacionales, como por ejemplo: licencias de importacin, aranceles (provocan incremento de precios) e impuestos especiales
(alcohol, tabaco, artculos de lujo, etc.). Hay que conocer la normativa sobre el convenio de doble imposicin, proteccin recproca de inversiones y
repatriacin de beneficios y dividendos. Estos problemas afectan tanto a las
empresas como a sus empleados expatriados. El responsable del proyecto
tendr en cuenta aquellos aspectos derivados de las diferencias geogrficas
especialmente los referidos a la accesibilidad, el lugar del proyecto, capacidad de abastecimiento y transporte, temperatura, etc. La planificacin del
proyecto incluir todos los aspectos de la cadena de suministros (ver figura
15.2). En resumen, desde el punto de vista interno de la empresa que realiza el proyecto internacional es importante aprovechar de la mejor forma
posible sus puntos fuertes (fortalezas) y mejorar sus puntos dbiles (debilidades), en relacin a la mejor adaptacin a las condiciones y diferencias de
los mercados donde va a operar.
Fortalezas tpicas para el xito internacional:
t %JTQPOFSEFVOOJWFMUFDOPMHJDPZEFDBMJEBERVFQFSNJUBBDPNFUFS
con xito mercados exteriores.
t 5FOFSMBGMFYJCJMJEBEOFDFTBSJBQBSBBEBQUBSFMTFSWJDJPQSPEVDUPBMBT
necesidades de los nuevos mercados.
Debilidades tpicas ms comunes a las empresas exportadoras:
t /PEJTQPOFSEFSFDVSTPTIVNBOPTBQSPQJBEPTFODVBOUPBFYQFSJFOcia, conocimientos de comercio exterior y de idiomas para los nuevos
proyectos.
375
t %FTDPOPDJNJFOUP DVMUVSBM EFM JEJPNB QPMUJDP SFMJHJPTP DPTUVNbres, etc.) del pas del proyecto.
t %FTDPOPDJNJFOUP EFM NBSDP MFHBM Z GJTDBM FTQFDGJDP EFM QBT EFM
proyecto.
Figura 15.2. Proyectos internacionales.
3. LA NEGOCIACIN INTERNACIONAL
En este captulo se trata uno de los aspectos esenciales de un proyecto
internacional, la negociacin. En el captulo 9 se ha hablado de las tcnicas
de negociacin y de los aspectos generales de la misma. En este captulo
se ven las diferencias fundamentales cuando se trate de una negociacin
internacional.
376
3.1. Elementos culturales en la negociacin internacional

Cada vez se realizan ms negocios internacionales, por lo que es necesario tratar de evitar problemas con los posibles clientes debido a las
diferencias interculturales. Muchos negocios se han malogrado por culpa
de la falta de entendimiento entre personas de diferentes pases que no han
sabido entender esas diferencias culturales o no han sabido acomodarse a
los hbitos y prcticas de la otra parte. Las negociaciones interculturales se
dan entre personas de distintas nacionalidades, entre culturas corporativas
o entre agrupaciones dentro de las compaas. No se puede esperar que
todos piensen como uno mismo. Algunas de las diferencias ms habituales
en el mbito internacional tienen que ver con aspectos como la jerarqua
de los negociadores (conviene que los niveles jerrquicos sean similares),
autonoma en la toma de decisiones (en algunos pases se perder el respeto al negociador que tenga que estar llamando a sus superiores continuamente), pagos y cobros ilcitos (el responsable del proyecto tiene que tener
una clara poltica de empresa respecto a estos temas, que pueden suponer
un serio problema tico y legal para la empresa y para los negociadores e
incluso de tipo penal, modelo de negociacin (prolongado o rpido), estilo
de negociacin (colegial o en equipo frente a negociaciones individuales).
Esto significa que cualquier negociacin internacional debe ser preparada
y planificada hasta en sus ms mnimos detalles y con suficiente antelacin
atendiendo al pas en concreto, a la informacin sobre los negociadores y
a la empresa, y a los entornos fsicos de la negociacin. Cada negociacin
exigir un perfil especfico de negociador y de plan de negociacin.
En el mundo de los proyectos internacionales pueden surgir conflictos
culturales para los que se debe estar preparados, en la medida de lo posible, conociendo los usos y costumbres que imperan en la zona donde se
pretende llevar a cabo el proyecto. El conocimiento de la cultura del pas de
nuestro cliente nos permitir establecer vnculos ms estrechos y duraderos.
En las operaciones internacionales la relacin personal vale mucho, ya que
las dos partes tendern a buscar alguien con el que se sientan cmodos y
seguros. Conseguir el primer proyecto puede resultar complicado, pero el
reto es mantener la relacin a largo plazo.
Un error muy frecuente es pensar que el manejo de la lengua de la
otra parte va a ser suficiente para tener una negociacin con xito. Pero la
experiencia demuestra que en la negociacin y comunicacin intercultural
pueden darse con bastante facilidad situaciones conflictivas antes, durante
y despus de una negociacin, que van ms all del uso correcto de una
lengua extranjera o una lengua franca; que van ms all de lo que se podra
denominar la competencia lingstica. El nivel de conocimientos, la comprensin adquirida y el nivel de aceptacin de las diferencias culturales, es
377
decir, lo que se puede denominar competencia intercultural, son necesarios

para mejorar las condiciones con las que se afronta una negociacin internacional.
En un entorno de negociacin multicultural es importante no limitar las
expectativas a estereotipos, como por ejemplo: los latinos regatean, puesto que el proceso de globalizacin que est experimentando el mundo y
la gran movilidad de las personas hace que los posibles negociadores no
sean ejemplos puros de lo que se espera de las personas en funcin de
su nacionalidad.
Muchos negociadores dan por hecho que un contrato es un contrato,
mientras que en ciertas culturas, donde gobiernan otras normas culturales,
un contrato es simplemente un marco sobre el que se basarn las futuras
relaciones. Por ello, es necesario encontrar formas de corroborar que la
otra parte va cumplir sus promesas y que el acuerdo se va a cumplir en el
largo plazo.
3.2. Factores de xito en la negociacin internacional
Como ya se ha dicho, para mejorar las posibilidades en las negociaciones internacionales va a ser necesario desarrollar lo que se ha denominado
competencia intercultural. Para ello, hay que estudiar los siguientes aspectos que dan idea de las posibles maneras de actuar de la otra parte durante
la negociacin:
Forma de trabajar: orientacin hacia el trabajo o interaccin social.

Tiempo y espacio (puntualidad, lugares de la negociacin).
Idioma y pensamiento: contexto.
Relacin grupo-individuo.
Rituales y prcticas sociales (comidas de trabajo, actividades deportivas o sociales con los clientes).
Importancia de la clase social y estatus.
Valores.
En algunas culturas, especialmente en Oriente, se considera de mala
educacin decir no cuando una persona pide algo en particular o cuando
se est alcanzando un acuerdo. Las reglas de cortesa en esas culturas van
en contra de poner a una persona en una situacin en la que quede malparada si una parte da una respuesta negativa (prdida de cara).
En muchas sociedades y en algunas empresas es frecuente prolongar las
negociaciones. Por ejemplo, cuando en un zoco un comprador no acepta el
primer precio de un mercader, saliendo a menudo de la tienda despus de
haber dejado al mercader con la sensacin de que est realmente interesado
en comprar el artculo. Ese proceso suele alargarse durante varias horas y
378
suele acabar con un acuerdo acompaado de un t de menta y una conversacin. Hay que reconocer que el regateo en el mundo empresarial, aunque
puede parecer la forma ms rudimentaria de negociacin, fortalece las relaciones humanas y puede dar lugar a una sensacin mutua de xito tanto
por parte del comprador como del vendedor. Ambas partes intercambian
nuevas ofertas hasta que se alcancen mejores compromisos. En realidad en
algunas culturas (por ejemplo, la japonesa), alcanzar un compromiso no
es tan importante como desarrollar una relacin a largo plazo. Como consecuencia, los negociadores japoneses esperan revisar frecuentemente el
compromiso; lo que no es tan normal en pases occidentales donde es ms
importante alcanzar y respetar un acuerdo formal. Como resumen se puede
decir que el responsable del proyecto cuanto ms conozca a la otra parte,
en todos los sentidos (cultural, profesional, etc.) ms posibilidades de xito
tendr en la negociacin.
4. CONTRATO INTERNACIONAL
Como definicin general, se puede decir que un contrato internacional
es un acuerdo de voluntades pactado entre dos o ms partes que tienen sus
domicilios o residencias en estados distintos. Otro aspecto fundamental a
tener en cuenta en los proyectos internacionales es el referido a la contratacin. La contratacin internacional est caracterizada por el hecho de afectar a dos o ms ordenamientos jurdicos. Esto es debido a que los elementos del contrato (las partes, el objeto del contrato, el lugar de conclusin,
lugar de ejecucin, etc.) se encuentran situados en distintos pases. Aparece
como dificultad decidir cul va a ser el derecho que va a regir una operacin comercial internacional. La existencia de distintas leyes aplicables es
un factor de complicacin e incertidumbre que dificulta la conclusin del
contrato. Esto se agrava ms an, ya que las soluciones propuestas por
las disposiciones internas de los ordenamientos jurdicos resultan muchas
veces inadecuadas para regular este tipo de operaciones. Estas disposiciones estn pensadas para situaciones internas, muy diferentes de las que
tienen lugar en la operativa internacional. A pesar de la fecunda actividad
legisladora desarrollada por las organizaciones internacionales en esta rea
durante la segunda mitad del siglo XX, las dificultades mencionadas anteriormente siguen presentes [Arteaga, 2013]. Existen ciertas caractersticas
especiales derivadas del medio jurdico internacional:
t .VMUJQMJDJEBE EF FTUSVDUVSBT KVSEJDBT FO QSFTFODJB UBOUBT DVBOUPT
pases haya en el contrato).
t 7BSJFEBEEFVTPTZDPTUVNCSFTBQMJDBCMFTBMDPOUSBUP
379
t 1MVSBMJEBEEFKVSJTEJDDJPOFTDBQBDFTEFJOUFSWFOJSFOFMDPOUSBUPJOUFSnacional.
Todos estos elementos deben ser tenidos en cuenta a la hora de realizar un contrato internacional pues las consecuencias jurdicas e incluso
comerciales que se derivan del mismo son muy diferentes. Las normativas
pueden divergir en aspectos como: la formacin del contrato, la entrega de
la mercanca, el medio de pago, el transporte, el seguro de mercancas, etc.
Adems, se deben cumplir las normas administrativas que rigen en el comercio exterior, como las de importacin, exportacin, aduanas, control de
cambios, etc. Estas grandes diferencias empezaron a unificarse con el uso
generalizado a nivel mundial de los INCOTERMS, que definen los derechos
y obligaciones de las partes en las relaciones de compraventa internacional.
La funcin del contrato internacional consiste en fijar los derechos y obligaciones que corresponden a cada una de las partes a las que se refiere.
Este actuar como mtodo de previsin y cobertura de riesgos, evitando as
posteriores complicaciones que puedan hacer peligrar la debida ejecucin
de la relacin comercial.
4.1. La importancia del contrato en el mbito internacional
El contrato, tanto nacional como internacional, define el contenido y
alcance de las obligaciones y derechos que corresponden a las partes. Es
el instrumento de gestin del acuerdo entre las partes que define las prestaciones que debern realizar los obligados por ella y los derechos de que
se podrn prevaler. Esta importancia aumenta en el mbito internacional ya
que los puntos que no estn regulados sern regidos por leyes que sern
extraas a una de las partes y que pueden presentar soluciones diferentes a
las de su propio derecho. Esto puede producir sorpresas a la hora de ejecutar el contrato, de ah la necesidad de prever sus consecuencias.
4.2.
Los principales riesgos jurdicos derivados de un proyecto

internacional
Los principales riesgos jurdicos son los siguientes:

La indeterminacin de la ley que va a regir el contrato puede generar
graves problemas debido a la multiplicidad de puntos de contacto
(y en consecuencia, de leyes) que presentan estas relaciones. As,
cuando dicha ley no haya sido previamente definida por las partes,
corresponder al Juez o al Tribunal Arbitral la determinacin de la
misma.
380
La indeterminacin del modo de solucionar los problemas que se

puedan derivar de la relacin jurdica, es decir, si ser la justicia estatal o la justicia arbitral la que intervendr para solucionar los conflictos. En el caso de que se elija la primera, habr que concretar cul es
el pas del tribunal.
Adems de estos riesgos jurdicos existen tambin riesgos tecnolgicos, comerciales, econmico-financieros o polticos que habr que
tener en cuenta.
En contratos internacionales de cierta envergadura es asimismo comn
firmar documentos que reflejen el entendimiento inicial entre el futuro comprador y vendedor. A dichos documentos se les suele denominar MOU
(memorandum of understanding) o LOI (letter of intent).
4.3. El arbitraje internacional
Al no existir una jurisdiccin internacional de derecho privado, las partes
suelen recurrir a alguna institucin que, con carcter internacional, arbitre
las posibles divergencias con respecto al contrato que les une. Ello se hace
porque si se sometieran al Tribunal Nacional de una de las partes, la otra
posiblemente se vera en una situacin de desventaja al no conocerla tanto
como la primera, por hablar posiblemente otro idioma, lejana fsica del
Tribunal, encarecimiento de los gastos, etc.
Podra darse tambin la posibilidad de someterse a un juez de un tercer
pas neutral entre las partes, pero esta solucin plantea tambin gran cantidad de problemas. Dado que el sometimiento a un Tribunal Judicial no
parece ser una buena salida para las partes del contrato, han ido surgiendo
nuevas formas de solucionar los conflictos, como es el Arbitraje Comercial
Internacional. El rbitro ofrecer, en la gran mayora de los casos, una solucin rpida, tcnica y confidencial. La relacin con las partes se basar simplemente en la voluntad de stas de someterse a su veredicto, y se apoyar
en el propio convenio arbitral.
El arbitraje internacional puede resolver temas como:
Decidir sobre la resolucin del contrato y fijar la fecha de la resolucin.
Incumplimiento de las partes en la ejecucin del contrato.
Responsabilidad de las partes en la ejecucin del contrato.
Cantidades debidas por una parte a la otra, y por qu concepto.
Excepciones alegadas.
Derecho de retencin sobre cantidades en poder de una parte.
Derecho de compensacin.
Indemnizacin por daos y perjuicios.
381
Costes del procedimiento arbitral y su distribucin entre las partes.

La intervencin de cualquier tribunal de arbitraje tiene una serie de ventajas con respecto a una solucin jurisdiccional:
Para las partes es muy difcil encontrar un tribunal que pueda hacerse
cargo de todos los aspectos del contrato, ya que posiblemente ste se
habr redactado segn la conjuncin de las leyes de los pases de las
compaas.
Las partes tienen entre ellas una relacin supranacional, y es por ello
que tambin prefieren que los conflictos se resuelvan en un contexto
adecuado como el del Arbitraje Internacional
La jurisdiccin nacional suele ser lenta, y ms en el caso de tener
que resolver un conflicto internacional, lo que implicara viajes de al
menos una de las partes del conflicto, imprevisibilidad de los costes
del procedimiento judicial, etc.
Los rbitros internacionales son personas que conocen a fondo el
mundo de los negocios internacionales y sus usos habituales, etc.
En un litigio jurisdiccional, ste es objeto de publicidad para llamar a quienes puedan estar interesados en el procedimiento. Es
muy probable que esta publicidad moleste a las partes intervinientes, que pueden estar tratando algn secreto comercial mediante su
contrato.
5. ANLISIS DE LOS RIESGOS EN LOS PROYECTOS INTERNACIONALES

En el captulo 3 se ha hablado de los riesgos del proyecto. En este captulo se vern las diferencias fundamentales cuando se trate de un proyecto
internacional. El concepto de riesgo implica incertidumbre, pero esto no
significa que necesariamente vaya a ocurrir una prdida, sino simplemente
la posibilidad de que pueda ocurrir, junto con la incertidumbre de si va a
ocurrir o no. Por tanto, cuando se dice que el proyecto internacional supone mayores riesgos para una empresa, lo que realmente se quiere decir es
que la empresa tiene una mayor incertidumbre respecto a una operacin
local. La gestin del riesgo internacional consiste en determinar, en cada
caso, cul es la mejor alternativa, entre minimizar y asumir el riesgo, trasladrselo a un tercero mediante un contrato o cubrirlo con un seguro [Nez
de Dios, 2010].
Los riesgos ms habituales en proyectos internacionales se pueden dividir en tres categoras:
382
a) Cobertura del riesgo comercial

Los riesgos comerciales son los riesgos relacionados con el posible impago de nuestra venta internacional por parte del importador que la ha
comprado o de su avalista. Este posible impago puede tener diferentes
causas dependiendo de si es un cliente privado o pblico.
t 4JFMDMJFOUFFTQSJWBEP FMSJFTHPDPNFSDJBMJODMVZFFYDMVTJWBNFOUF
las razones propias del comprador, como son insolvencia (quiebra o
suspensin de pagos), morosidad prolongada o falta de transferencia.
Cuando las razones del impago se deben a otro tipo de causas ajenas
al cliente privado, entraramos en los llamados riesgos polticos y
riesgos extraordinarios, que veremos ms adelante.
t 4JFMDMJFOUFFTQCMJDPMBTSB[POFTEFTVJNQBHPTVFMFOTFSQPMUJDBT
Cuando una empresa pblica no paga, se suele deber a problemas
de divisas o de transferencia de las mismas, por lo que su impago no
entra dentro del riesgo comercial propiamente dicho, sino del riesgo
poltico.
El seguro de crdito a la exportacin (SCE) se refiere a todos aquellos
seguros relacionados con la actividad exportadora de la empresa, que se
ocupan de reas especficas de la misma. Por ejemplo, algunas de las plizas que ofrecen las compaas aseguradoras, dentro de este concepto de
SCE, son las siguientes:
t 1MJ[BEFDPCFSUVSBEFFYQPSUBDJPOFTSFHVMBSFTEFMBTFNQSFTBT
t 1MJ[BEFDPCFSUVSBEFPCSBTZUSBCBKPTFOFMFYUSBOKFSP
t 1MJ[BEFDPCFSUVSBEFFKFDVDJOEFGJBO[BT EFBOUJDJQPPEFDVNplimiento).
t 1MJ[BEFDPCFSUVSBEFDSEJUPDPNQSBEPSTVNJOJTUSBEPS
t 1MJ[BEFDPCFSUVSBEFDSEJUPTEPDVNFOUBSJPT
t 1MJ[BEFDPCFSUVSBEFHBSBOUBTCBODBSJBT
b) Cobertura del riesgo poltico y extraordinario
El riesgo pas es el derivado de las condiciones de estabilidad poltica y financiera (riesgo poltico) y del desarrollo econmico e institucional
de un pas (riesgo econmico y soberano). Por ello, podemos considerar
como riesgo pas el derivado de las siguientes medidas adoptadas por un
gobierno extranjero que impiden al importador pagar o cumplir el contrato:
no permitir la transferencia de la suma adeudada por empresas privadas
residentes del pas, transferir en moneda diferente a la convenida, falta de
pago durante seis meses (a partir del vencimiento estipulado, por moratoria
establecida en el pas destino) insolvencia del propio Estado, de sus insti-
383
tuciones o empresas pblicas. En el caso de proyectos internacionales el

riesgo poltico y extraordinario se puede cubrir por el seguro de crdito a
la exportacin por cuenta del estado.
c) Cobertura del riesgo de cambio
El riesgo de cambio es la posible prdida que se puede tener en el cobro de ventas internacionales en divisas, como consecuencia de variaciones
no esperadas, desde la fecha de la firma del contrato del proyecto hasta la
fecha de cobro, en el valor de la divisa respecto a nuestra moneda local.
Debemos resaltar que el riesgo hace referencia a la posible prdida. Por
tanto, y teniendo claro que el objeto de una empresa no es especular con
las divisas que obtendr por su venta, es importante que antes de cubrir un
riesgo de cambio, la empresa haya analizado la probabilidad, la tendencia
y el impacto que puede tener la variacin de la divisa respecto a nuestra
moneda local, en el resultado de la operacin. A la hora de analizar estos
riesgos sera importante ver lo indicado en los captulos 6 y 7, especialmente en lo referido a la financiacin de proyectos.
La cobertura del riesgo de cambio se puede realizar mediante determinados instrumentos financieros, llamados derivados, o mediante una
pliza de seguro. La decisin de cubrir un riesgo de cambio no slo
depender de las expectativas que tenga la empresa respecto a su evolucin, sino de la propensin al riesgo de los gestores de la empresa o
de la filosofa de la misma respecto al riesgo. Una vez que la empresa ha
decidido cubrir el riesgo, debe analizar y determinar cul es el instrumento
financiero ms adecuado. Un criterio podra ser el siguiente:
t 1BSBDPCSPTFOEJWJTBTBDPSUPQMB[P TPOBEFDVBEPTFMGPSXBSE, los
futuros y las opciones sobre divisas.
t 1BSBDPCSPTFOEJWJTBTBMBSHPQMB[PDPOWBSJBTDPCFSUVSBTEFDPSUP
plazo, son adecuados los tres instrumentos ya mencionados.
t 1BSBDPCSPTFOEJWJTBTBMBSHPQMB[PDPOVOBDPCFSUVSBEFMBSHPQMBzo, el mejor instrumento es el swap de divisas.
6. LOS RECURSOS HUMANOS EN LA INTERNACIONALIZACIN

En el mbito internacional el papel desempeado por las personas y
la gestin de este recurso se vuelve crucial si tenemos en cuenta, no slo
la mayor complejidad organizativa, sino tambin el hecho de trabajar en
entornos lejanos y diferentes. En las empresas internacionalizadas se distingue entre personal local y expatriados. Los primeros pertenecen al pas
384
del proyecto, los segundos vienen desplazados de la casa matriz o de un

tercer pas.
a) Ventajas que puede aportar el empleo de personal local
Normalmente la contratacin de personal local viene determinada por
dos factores fundamentales, la disminucin de costes salariales y las exigencias legales y contractuales del pas del proyecto. Lgicamente el uso de
personal local tambin est relacionado con las polticas de responsabilidad
social corporativa y la mejora de la imagen de las compaas en los pases
de los proyectos. Otras razones a considerar son las siguientes:
t /PUJFOFOCBSSFSBTDVMUVSBMFT
t 1FSNJUFOMBDPOUJOVJEBEFOMBHFTUJOEFMBGJMJBMBMFWJUBSDPOUJOVBT
sustituciones de expatriados.
t 0QPSUVOJEBEFTEFDBSSFSBFOFMQFSTPOBMMPDBM
t .FKPSBDFQUBDJOEFMBFNQSFTBFOFMQBTEFEFTUJOPQPSQBSUFEFMPT
clientes.
t -PTEJSFDUJWPTMPDBMFTBQPSUBOVOBWJTJODPNQMFNFOUBSJBFOMPTQSPcesos de toma de decisiones de la central.
t .FKPSFTSFMBDJPOFTDPOMBBENJOJTUSBDJOEFMQBTFODPODSFUP
b) Ventajas del uso de expatriados
El empleo de personal expatriado genera mayores costes que el de persona local y garantizan a la matriz una mayor seguridad, por lo que la mayora de las empresas multinacionales suelen utilizar expatriados nicamente en los puestos clave (directivos, especialistas tcnicos y profesionales de
alto nivel). Otras razones que fomentan el uso de personal expatriado son
las siguientes:
t -BOPEJTQPOJCJMJEBEEFQFSTPOBMDVBMJGJDBEPEJTQPOJCMFFOFMQBTEF
destino.
t &YJTUFODJBEFJNQPSUBOUFTEJGFSFODJBTDVMUVSBMFTFOUSFFMQBTEFPSJgen y el pas de destino que tienden a aumentar las asimetras de informacin y potenciar el oportunismo, por ello, las empresas buscan
un directivo de confianza.
t /FDFTJEBE EF USBOTGFSFODJB DPOPDJNJFOUP UDJUP (SBO QBSUF EFM DPnocimiento que se transmite a las distintas unidades de una empresa
internacional es tcito, no pude codificarse y transmitirse mediante manuales, informes, etc. Para su transmisin se hace imprescindible, por
tanto, desplazar al personal que lo posee. De la misma forma, la em-
385
presa puede aprender de los entornos internacionales en los que opera

y transmitir dicho conocimiento a otras partes de la organizacin.
t -BFNQSFTBSFDVSSFBFYQBUSJBEPTRVFDPOPDFOMBGPSNBEFPQFSBS
de la organizacin en su conjunto, que han establecido contactos
y vnculos entre distintas unidades y conocen el impacto que la decisin adoptada por una filial puede tener sobre el resto de la
organizacin. Estos directivos actan como un mecanismo de
coordinacin, conociendo tanto los condicionantes locales como el
inters corporativo.
t -PTFYQBUSJBEPTWJHJMBOMBFKFDVDJOEFMBTPQFSBDJPOFTMPDBMFTFJOcrementan los canales de comunicacin entre la filial y la sede central
por lo que son importantes como mecanismo de control.
No obstante, el empleo de personal expatriado puede generar una serie de problemas como la falta de adaptacin, mayores costes salariales o
un efecto desmotivador en los directivos locales, por lo que la mayora de
las empresas multinacionales suelen utilizar expatriados nicamente en los
puestos clave. Un aspecto esencial en la gestin de los recursos humanos
expatriados es la seleccin y compensacin de estos directivos. En relacin a la seleccin, los criterios utilizados deben contemplar tres aspectos
fundamentales: cualificacin profesional o tcnica, habilidades directivas y
liderazgo y sensibilidad hacia la cultura del pas de destino. En lo que se
refiere al segundo aspecto se ha de tener en cuenta que la expatriacin
supone un cambio importante en la vida de estos empleados que ha de
verse suficientemente compensado. Suelen utilizarse una serie de paquetes
retributivos adicionales a la remuneracin normal que permiten mantener el
nivel de vida llevado en el pas de origen, cubrir costes de desplazamiento y
proporcionar primas y ayudas familiares. En la eleccin del responsable del
proyecto se debe contemplar junto con los requisitos anteriores, que tenga
una importante capacidad personal para coordinar equipos de trabajo y
de proveedores, que habitualmente son multinacionales y multiculturales;
y de forma muy especial se tiene que cuidar la relacin tanto con el cliente
como con las autoridades del pas.
7. REFERENCIAS
ARTEAGA, J., Manual de internacionalizacin, ICEX, 2013.
CERVIO, J., Marketing Internacional, Ediciones Pirmide, 2006.
FANJUL, E., Negociacin intercultural, Iberglobal, 2013.
LLAMAZARES, O., Cmo negociar con xito en 50 pases, Global Marketing, 2003.
NEZ DE DIOS, F., Gestin de riesgos en la empresa internacional, Global Marketing, 2010.
386
CAPTULO 16
PROYECTOS MULTINACIONALES
Aurora del Castillo Pinela
1. INTRODUCCIN
La globalizacin de los mercados, las nuevas tecnologas, que facilitan
enormemente la comunicacin, la necesidad de nuevos enfoques de negocio en las empresas, que les permitan mantener su ventaja competitiva
y aseguren su negocio a medio y largo plazo, entre otras razones, han
hecho que, en los ltimos aos, los fundamentos de la gestin de programas hayan cambiado de un enfoque mucho ms local, a la necesidad de
gestionar programas y equipos globales/virtuales deslocalizados geogrficamente.
En este captulo intentaremos dar una visin global de lo que supone la
gestin de programas multinacionales, no solo por la complejidad aadida
en la gestin de equipos multinacionales y multiculturales, o la intervencin de empresas y/o gobiernos de mltiples pases, sino desde el punto de
vista de las peculiaridades que supone la contratacin y la posterior gestin
de estos programas, entendidos en su amplio sentido, incluyendo en ellos
uno o varios proyectos, la gestin de los consorcios y/o contratistas, las distintas participaciones industriales y la financiacin de los mismos, as como
el entorno que ha llevado a que se acometan cada vez con mas frecuencia
proyectos multinacionales.
387
2. PROGRAMAS DE DESARROLLO MULTINACIONAL

Durante las ltimas dcadas, cada vez ms, se vienen desarrollando
programas multinacionales. Son mltiples las razones que llevan a la
puesta en marcha de estos programas y sus proyectos. Entre otras, se podran destacar, la globalizacin de mercados y clientes, la nueva situacin
econmica, que hace que algunas empresas tiendan a invertir en pases
en fase de crecimiento econmico por ejemplo Brasil, Rusia, India y China
(los llamados pases (BRIC), o la situacin poltica y acuerdos de programas de desarrollo entre pases.
En Europa, la actual situacin econmica hace que haya cada vez ms
una necesidad de compartir recursos en las empresas, no solo para acometer proyectos que resulten ms competitivos en los mercados, sino para
afrontar nuevos proyectos tecnolgicos que sera casi imposible llevar a
cabo por una sola empresa, debido a sus altos costes de investigacin y
desarrollo, y su largo plazo de puesta en el mercado.
Frecuentemente, los programas de desarrollo multinacional, que suponen una gran inversin en Investigacin y Desarrollo, son financiados por
los Gobiernos de los pases participantes, que se valen de estos programas
para el desarrollo tecnolgico de las industrias nacionales, convirtindose
as los propios Gobiernos en clientes lanzadores del producto. Un ejemplo de este tipo de programas son los financiados por los Ministerios de
Defensa o Infraestructuras, entre otros, en Europa y EE.UU.
Las claves para el desarrollo de programas Multinacionales se resumiran
en los siguientes aspectos:
a) Estrategia industrial
t (MPCBMJ[BDJOEFNFSDBEPTZQSPEVDUPT
t (MPCBMJ[BDJOEFDMJFOUFTMPDBMJ[BEPTFONMUJQMFTQBTFTSFTQVFTta global.
t /FDFTJEBEEFBDDFTPBOVFWPTNFSDBEPT
t #TRVFEBEF$POTPSDJPTUFDOPMHJDPT
t "DDFTPBOVFWBTUFDOPMPHBTEFJOOPWBDJO
t /FDFTJEBEEFDPNQBSUJSJOWFSTJPOFTFOOVFWPTEFTBSSPMMPT
b) Tipo de programa/proyecto
t 1SPZFDUPTEFBMUBUFDOPMPHBRVFSFRVJFSFOFMVTPEFi,OPXIPXw
residente en varias empresas.
t 1SPZFDUPTEFBMUPDPTUFEFEFTBSSPMMP
t 1SPZFDUPTDPOQPUFODJBMJNQMBOUBDJOFONMUJQMFTQBTFT
t 1SPZFDUPTEFBMUPSJFTHPFDPONJDPUDOJDP
388
c) Clientes lanzadores
t
t
t
t
/FDFTJEBEEFDPNQBSUJSDPTUFTEFEJTFPZEFTBSSPMMP
/FDFTJEBEEFDPNQBSUJSDPTUFTFOJOWFSTJPOFT
$PNQSPNJTPDPOFMEFTBSSPMMPEFMBJOEVTUSJBOBDJPOBM
3B[POFTQPMUJDBTPFTUSBUHJDBT
3. MODELOS DE ORGANIZACIN DE PROGRAMAS MULTINACIONALES

Tanto las empresas multinacionales, como las mas locales, tienen actualmente, por las razones ya expuestas en el prrafo anterior, la necesidad de
expandir sus negocios a nuevos mercados y clientes, por lo que las empresas han de organizarse para ser capaces de afrontar la complejidad de la
gestin de los programas multinacionales, y poner en marcha su estrategia
de expansin y ventas, teniendo en cuenta la localizacin de sus clientes
actuales y futuros.
Se describirn en esta seccin las distintas formas de organizacin de
programas multinacionales y sus peculiaridades de gestin, tanto en las
empresas multinacionales como en los consorcios empresariales. Se pretender, tambin dar una esquemtica visin de algn aspecto clave en
la gestin de programas multinacionales como puede ser el modelo de
subcontratacin que, cada vez ms, es usada por las empresas buscando la
optimizacin de costes y el acceso a ciertas tecnologas no claves existentes
en los potenciales suministradores.
Otro tipo de programas, como los que surgen como consecuencia de
compensaciones industriales tambin llamados offset, debidas a acuerdos
por adquisiciones entre dos Gobiernos, sern tambin descritos en esta
apartado.
3.1. Empresas multinacionales
El modelo de empresa multinacional sera el de una empresa localizada
en varios pases, con tareas y competencias distribuidas entre los distintos
centros productivos. Dentro de este modelo de organizacin multinacional,
se pueden tener distintos enfoques dependiendo del tipo de productos o
servicios, del tipo de cliente o del estilo ms localizado o global de la empresa. Los distintos modelos se detallan a continuacin.
389
a) Modelo Multinacional Global

Este tipo de modelo organizativo, cuyo esquema se muestra en la figura
16. 1, suele ser aplicable en empresas cuyos productos, a veces de alto nivel
tecnolgico, estn dirigidos a un cliente global, sin necesidad de particularizar o clientizar el producto de acuerdo a las necesidades del cliente local.
Un ejemplo de este tipo de organizaciones o proyectos multinacionales
globales pueden ser las empresas aeroespaciales (Airbus o Boeing), o de
automocin (Audi, Mercedes), etc.
Tanto la estrategia de productos y clientes de la empresa como la gestin de los programas, es centralizada. La gestin de los proyectos se lleva
a cabo en una nica oficina de programa, que coordina los distintos proyectos, los cuales se desarrollan habitualmente en los distintos centros de
competencia que s suelen estar geogrficamente deslocalizados.
La gestin de estos programas exige un alto nivel de coordinacin de
las oficinas de proyectos, los centros productivos y los subcontratistas, as
como de los clientes, que normalmente son globales y estn distribuidos a
lo largo del mudo.
La oficina de programa, centralizada, ha de garantizar una gestin integrada del programa, en todas sus fases: conceptual, desarrollo, produccin,
venta y apoyo del ciclo de vida, y asegurar que el producto final cumple
estrictamente con la especificacin tcnica, y se entrega en plazo, calidad y
coste a los clientes operadores.
Esta gestin integrada, ha de llevarse a cabo en las distintas fases del
proyecto, asegurando la integracin de todos los elementos gestin: Work
Breackdown Structure (WBS), planificacin master, gestin de riesgos,
control de costes y mrgenes de beneficio, control de configuracin del
producto, gestin de suministradores y subcontratistas etc, tal como se ha
descrito en detalle en los captulos 3 y 6 anteriores.
Un ejemplo de empresa multinacional global, sera la compaa aeronutica europea Airbus, en ella los proyectos son desarrollados de acuerdo
a las competencias tecnolgicas de cada centro operativo (Madrid, Toulouse, Hamburgo etc.), con equipos de trabajo multidisciplinares, localizados
internacionalmente en cada centro de competencia, pero los programas
son gestionados de forma centralizada por una oficina de programa que
coordina e integra los proyectos de los centros de competencia, y gestiona
la respuesta a los clientes.
390
Figura 16.1. Esquema Organizativo Multinacional Global.
391
b) Modelo Multinacional Insourcing/Transnacional

Este tipo de modelo organizativo, cuyo esquema se muestra en la figura 16.2, sera el que desarrollaran las organizaciones multinacionales
que, estando localizadas globalmente en mltiples pases, no orientan
sus productos al cliente global, sino que adaptan sus desarrollos a los
requisitos de los clientes locales, por lo que estas organizaciones, requieren una gestin de los programas descentralizada, y ms localizada
en sus centros delegados.
Esta alternativa se centra mas en particularizar clientizar los desarrollos de la empresa, para ofrecer un producto que se adecue al cliente local.
Es el caso de desarrollos de productos tecnolgicos, como pueden ser equipos de comunicaciones, radares o sistemas de seguridad, con desarrollos
en ocasiones complejos y de alto coste, pero que han de adaptarse a los
requerimientos peculiares de cada cliente/pas.
La necesidad de un enfoque organizativo ms geogrficamente deslocalizado de la empresa, implica que la gestin y la estrategia del programa sean, a su vez, ms autnomas en cada delegacin, y mas enfocada al cliente local. La coordinacin multinacional es, por consiguiente,
menor y principalmente se centra a alto nivel o de estrategia global de
empresa. Es, sin embargo, fundamental la adaptacin de la empresa a
la cultura, normas, regulaciones y leyes laborales locales lo que desemboca en organizaciones de gestin independiente y casi replicada en las
distintas zonas geogrficas.
Los equipos locales han de ser entrenados para entender y conocer cul
es la idiosincrasia del pas y del cliente al que va dirigido el producto. La
prctica ms habitual es que los equipos de trabajo cuenten con personal
local en la mayora de las reas del programa. Un ejemplo de este tipo de
empresas, que se organizan de una forma transnacional, seran aquellas
que desarrollan y producen, por ejemplo, sistemas de radares para seguridad de fronteras o telecomunicaciones. Es muy importante, el hecho de
un enfoque mas adaptativo a las necesidades locales, lo que posibilita la
amortizacin de los costes de desarrollo, al adaptar el producto bsico para
mltiples clientes y poder expandir la distribucin del producto internacionalmente.
392
Figura 16.2. Esquema organizativo multinacional transnacional.
393
3.2. Consorcios multinacionales

Un consorcio multinacional es una unin o acuerdo entre empresas a
largo plazo, que adquiere carcter de nueva entidad legal y, por lo tanto, un
carcter de empresa en s mismo y que ha de acogerse a las regulaciones
legales existentes en el pas donde est registrado, aplicables a cualquier
otra empresa. El consorcio empresarial, como modelo de cooperacin industrial, se crea a partir de la asociacin de varias empresas existentes, para
el desarrollo de programas multinacionales especficos, normalmente de
alta complejidad tcnica, largo plazo de desarrollo y muy altos costes de
inversin. Muchos de estos consorcios se han establecido para responder al
desarrollo de programas financiados por Gobiernos en reas de Defensa e
Infraestructuras principalmente.
En Europa, por ejemplo, se cre el Consorcio PANAVIA a finales de
los aos 70, formado por las empresas British Aerospace de Reino Unido,
Alenia de Italia y MBB de Alemania, para el desarrollo y produccin del
avin Tornado. Posteriormente, estas mismas empresas, junto con CASA
(en la actualidad EADS-CASA), formaron en los ochenta, como veremos en
detalle mas adelante, el Consorcio Eurofighter Gmbh, para el desarrollo del
avin EF2000 Typhoon. Lo que viene a demostrar que los consorcios son la
opcin que, para programas de desarrollo en el mbito de la Defensa, esta
opcin resulta optima.
El consorcio multinacional ha de tener su propia estructura organizativa
y de gestin, que cubra todas las reas tcnica, comercial, financiera, Recursos Humanos, etc., y una entidad legal individual, que adems le permita
tener un vnculo contractual con las empresas que conforman el consorcio,
que frecuentemente es de contratista a subcontratado.
a) Modelo organizativo consorcio empresarial
El consorcio se establece con las empresas que participarn en el
desarrollo de el, o los proyectos que se van a llevar a cabo, una vez establecido el acuerdo de requisitos de el o los programas a desarrollar. La
distribucin de las responsabilidades entre los distintos participantes en el
diseo, desarrollo y produccin son acordadas, dependiendo de las inversiones que cada una de las empresas, o los Gobiernos de sus pases, aporten a cada uno de los proyectos.
Las compaas que conforman estos consorcios, no pierden su identidad
individual ni legal, sus propios desarrollos, ni sus mercados, en los que
hasta pueden, ser competidoras entre s. En el modelo organizativo Consorcio Empresarial, cuyo esquema se muestra en la figura 16.3. El consorcio,
adquiere la responsabilidad de contratista principal/prime contractor, por
394
lo tanto adquiere plena responsabilidad tcnica y legal frente al cliente durante todo el ciclo de vida del programa.
Las regulaciones legales del consorcio, son las del pas donde ste se
encuentre localizado legalmente y, por lo tanto tambin lo son las que
regulan las relaciones contractuales de la entidad legal del consorcio con
las empresas que lo componen as como con los subcontratistas y suministradores. La responsabilidad de la gestin de subcontratistas es, as
mismo, del contratista principal, aunque se delegue en las empresas del
consorcio.
Esquema organizativo de gestin en consorcios empresariales
Cliente B
Cliente A
Empresa A
Cliente C
Empresa B
Cliente D
Empresa C
Figura 16.3. Modelo organizativo consorcio.
3.3. Responsabilidades del consorcio empresarial

El consorcio, como empresa contratista principal, es responsable, frente
al o los clientes principalmente de:
t 3FTQPOTBCMFEFMPTBTQFDUPTMFHBMFTFOUSFFMDPOTPSDJPFNQSFTBSJBMZ
los clientes.
t (FTUJOEFMPTQSPHSBNBTRVFTFEFTBSSPMMFOCBKPSFTQPOTBCJMJEBEEFM
consorcio.
t &KFSDFSFMFOMBDFOJDPDPOMPTDMJFOUFTFOUPEBTMBTGBTFTEFMDJDMPEF
vida del programa
395
t 3FTQPOTBCMFEFMBJOUFHSBDJOZDPPSEJOBDJOEFMBTDPNQBBTEFM
consorcio en las actividades tcnicas y contractuales de los proyectos
bajo su responsabilidad.
t 1SFQBSBDJOOFHPDJBDJO ZHFTUJOEFMPTDPOUSBUPTDPOMPTDMJFOUFT
en todas las fases del programa.
t $POUSBUBDJOEFMBTDPNQBBTEFDPOTPSDJP
t 3FTQPOTBCMF EF MPT DPOUSBUPT DPO MPT TVNJOJTUSBEPSFT Z TVCDPOUSBtistas, aunque normalmente esta responsabilidad se delegue en las
compaas componentes del consorcio.
t 3FTQPOTBCMFGJOBODJFSPZEFDPOUSPMEFDPTUFTEFMQSPHSBNBBOUFFM
cliente y las compaas del consorcio.
t 3FTQPOTBCMFEFMBFOUSFHBBMPMPTDMJFOUFTEFMPTQSPEVDUPT TJTUFNBT
o servicios contratados, en plazo calidad y coste.
t 3FTQPOTBCMFEFMDPOUSPMEFMBDPOGJHVSBDJOZNFKPSBEFMQSPEVDUP
durante su ciclo de vida.
t 3FTQPOTBCMFEFMBTHBSBOUBTDPOUSBDUVBMFTEFMQSPEVDUPGJOBM
a) El concepto de distribucin de trabajos: WORKSHARE
En los programas desarrollados dentro de un consorcio empresarial, es
necesario que se distribuya la responsabilidad de los distintos proyectos
entre las compaas que componen el consorcio. Este reparto de responsabilidad suele estar basado en las especialidades o nichos de tecnologa
de cada empresa participante. Sin embargo, en programas de desarrollo
financiados por gobiernos, se tienen adems en cuenta, a la hora de distribuir el trabajo de desarrollo, factores como la inversin que cada gobierno
realice en el proyecto, o la tecnologa especfica que ese gobierno quiera
desarrollar en su pas.
Al concepto de reparto de trabajo entre empresas componentes de un
programa se le denomina workshare, y suele ser medido por el porcentaje de participacin de cada empresa. El porcentaje de participacin en el
desarrollo o workshare, no solo tiene en cuenta capacidades tcnicas, de
las empresas participantes, sino que se ajusta al porcentaje de participacin
econmica en el programa de cada pas participante.
Ejemplo de programas de desarrollo multinacional basado en el concepto workshare, son los programas de defensa desarrollados en Europa
desde los aos 80, tales como el avin de combate Eurofighter/Typhoon,
Programas Espaciales de la Agencia Espacial Europea, como el programa
Galileo o satlites de comunicaciones, etc.
La figura 16.4, muestra el workshare de participacin de los pases europeos, en el programa del avin de combate EF2000, comercialmente denominado Typhoon, desarrollado por el consorcio EUROFIGHTER Gmbh,
con la participacin de EADS-CASA con un workshare de un 13%; BAE
396
Systems con un 37,5%, EADS-GE con un 30% y Alenia con un 19,5%. Este
programa fue contratado por una Agencia de la OTAN, creada por los Ministerios de Defensa de los cuatro pases que financiaron el desarrollo, Espaa, Reino Unido, Alemania e Italia, que mencionaremos m;as adelante.
Figura 16.4. Esquema Workshare del Programa Europeo Eurofighter 2000.
b) Participacin del cliente: agencias de contratacin

Como hemos mencionado anteriormente, en numerosas ocasiones los
programas multinacionales de alta tecnologa son financiados por los gobiernos, al ser estos programas de muy alto coste de desarrollo.
Para permitir la mejor gestin de los proyectos, as como la integracin
de los mismos, es habitual que el cliente contratista sea un reflejo organizativo del consorcio industrial, lo que se realiza a travs de la creacin de
agencias de contratacin.
397
Las agencias de contratacin, estn participadas y financiadas por los gobiernos que participan en el o los programas para los que han sido creadas.
En los programas de defensa europeos, por ejemplo, las agencias de
contratacin que se han creado para gestionar programas multinacionales,
dependen de la Organizacin del Tratado del Atlntico Norte (OTAN), que
es responsable de la gestin global de las mismas. Podemos poner como
ejemplo, la Agencia de Organizacin Conjunta para la Cooperacin en
Material de Armamento (OCCAR), que es la responsable de la gestin el
programa de avin de transporte militar A 400M, o la agencia NATO Eurofighter and Tornado Management Agency (NETMA), que se responsabiliza
de la gestin del programa del avin de combate europeo Eurofighter/
Typhoon.
c) Responsabilidades de las agencias de contratacin
Cuando el programa de desarrollo est gestionado por una agencia de
contratacin, que ejerce las funciones de cliente nico financiador del
programa, esta agencia, que, como hemos dicho aglutina a los clientes/gobiernos de los pases que participan, adquiere mltiples responsabilidades,
no solo frente a los gobiernos a los que representa, sino frente al consorcio
empresarial que ejerce de contratista principal de las empresas participantes en el programa de desarrollo. Las principales responsabilidades de la
agencia de contratacin seran:
t
t
t
t
t
*OUFHSBSMPTSFRVJTJUPTEFMPTDMJFOUFTHPCJFSOPTQBSUJDJQBOUFT
)BDFSEF*OUFSGBDFOJDBDPOFMDPOTPSDJPDPOUSBUJTUB DPNPDMJFOUF
$POUSPMEFMBQMBOJGJDBDJOEFIJUPTZFOUSFHBT
$POUSPMGJOBODJFSPQSFTVQVFTUPT DPTUFTZQMBOEFQBHPT
3FTQPOTBCMFEFMPTBTQFDUPTMFHBMFTFOUSFMBBHFODJBDPOUSBUJTUBZFM
consorcio empresarial.
t /FHPDJBDJO Z GJSNB EF MPT DPOUSBUPT DPO FM DPOTPSDJP FNQSFTBSJBM
como prime contractor del consorcio.
t "DFQUBDJO DPOUSBDUVBM EFMPT QSPEVDUPT GJOBMFT FOUSFHBEPT QPS FM
consorcio empresarial.
d) Las ventajas de los programas de cooperacin industrial

Desde el punto de vista de los intereses industriales, la cooperacin
entre empresas, ya sea con el modelo de consorcio empresarial, el modelo
de unin de empresas Joint Venture, o cualquier otro tipo de modelo
cooperativo, aporta a las industrias participantes una serie de ventajas tanto
tecnolgicas como competitivas (costes, inversiones) o de acceso a mercados muy importantes. Entre otras podramos enumerar:
398
t "DDFTPBMEFTBSSPMMPEFOVFWBTUFDOPMPHBTPNFKPSBEFMBTQSPQJBT
t $PNQMFNFOUBSJFEBEEFMDPOPDJNJFOUPUDOJDPi,OPX)PXwFOUSFMBT
empresas participantes, lo que resulta en proyectos mucho mas ambiciosos tcnicamente.
t 0QUJNJ[BDJOEFSFDVSTPT UBOUPIVNBOPTDPNPNBUFSJBMFT
t 3FQBSUPEFDPTUFTZPQUJNJ[BDJOEFMQSFDJPEFMQSPEVDUPSFTVMUBOUF
t 3FQBSUPEFMBTJOWFSTJPOFTSFRVFSJEBTFOFMQSPHSBNB
t "DDFTPBOVFWPTNFSDBEPTOBDJPOBMFTFJOUFSOBDJPOBMFT
El objetivo final, es aumentar la ventaja competitiva de las industrias, de
modo que permita mantener o incrementar su cuenta de resultados y asegurar su futuro a medio y largo plazo que garantice, no solo su presencia
en el mercado sino un claro incremento de negocio.
3.4. Subcontratacin/outsourcing
Sea cual sea el modelo organizativo empresarial, de los descritos en los
prrafos anteriores, o el tipo de programa y sus diferentes proyectos, que
se estn llevando a cabo, en la mayora de casos se requiere que parte de
los desarrollos sean subcontratados a empresas externas. Esto hace, que la
subcontratacin sea el origen de mltiples proyectos multinacionales, que
requieren gestin intrafronteriza.
La decisin estratgica de la subcontratacin o el comprar o fabricar
make or buy, depende de muchos factores, entre los que podramos destacar, la estrategia tecnolgica y de produccin de la empresa, el tipo de
programa, en cuanto a sus proyectos mas innovadores o aquellos en los
que las tecnologas no sean fundamentales y estratgicas para la empresa
(no transferencia de Know-How), el acceso a ciertas tecnologas ya existentes en el mercado, desarrolladas en otras empresas especializadas y no
existente en la Empresa, el coste de desarrollo, o el ciclo desarrollo del
sistema o el producto subcontratado.
Una gestin eficiente de la subcontratacin, puede ser muy ventajosa
para ambas partes, contratista y subcontratado, ya que la estrategia en grandes empresas multinacionales es centrarse en la innovacin y el desarrollo
tecnolgico, y en aumentar su competitividad, y externalizando cada vez
mas, no solo paquetes de produccin sino desarrollos de productos completos, y en algunos casos involucrando al Subcontratista como un aliado
a largo plazo.
a) Factores positivos y riesgos en la subcontratacin
Se puede considerar como factor positivo de la subcontratacin, a la
bsqueda de ventajas competitivas, mediante el ahorro de costes laborales
399
e infraestructuras, y por lo tanto la utilizacin optima de los recursos existentes en la empresa, para los desarrollos de competencias que realmente
son de inters para la misma.
Otro factor positivo en la subcontratacin, es la disminucin de riesgos,
ya que al subcontratar tecnologas no existentes o no estratgicas, a empresas externas, los riesgos asociados a nuevos desarrollos y sus costes, se
minimizan.
La subcontratacin tiene, sin embargo, desventajas y riesgos para la
empresa, como pueden ser, la prdida a largo plazo de las tecnologas
que se subcontratan, o la capacidad de produccin que se decide subcontratar, lo que convertira a la empresa en un cliente cautivo del
subcontratista.
Otro factor de riesgo es el hecho de que la empresa subcontratista pase
de ser un aliado a ser un competidor en el mercado, en ciertas tecnologas
adquiras gracias a su acceso a las tecnologas de la empresa contratista, o
que el subcontratista no evolucione tecnolgicamente o que no invierta en
innovacin, supone asimismo un riesgo para la subcontratacin. Se espera
del subcontratista que invierta en innovacin, siendo esto una clara ventaja
para contratista y subcontratado. La tabla 16.1 muestra un resumen de las
ventajas y riesgos de la subcontratacin.
r
r
r
r
r
RAZONES
MAKE OR BUY
Estrategia
tecnolgica.
Competencias
existentes en la
empresa.
Acceso a tecnologas
ya desarrolladas.
Costes de desarrollo
y Produccin.
Tiempo/ciclo de
produccin.
VENTAJAS
RIESGOS
r Ahorro de costes:
Laborales
Infraestructuras
r Disminucin de
inversiones.
r Optimizacin de recursos.
r Acceso a tecnologas
externas.
r Focalizacin en
tecnologas core.
r Disminucin de riesgos.
r Prdida de capacidades
a largo plazo.
r Incremento de costes a
largo plazo.
r Transformarse en
cliente cautivo del
subcontratista.
r Subcontratista pasa a
ser competidor.
r Estancamiento
tecnolgico del
subcontratista.
Tabla 16.1. Ventajas y riesgos en la subcontratacin.
b) La gestin de subcontratistas
En el desarrollo de programas complejos, como pueden ser los aeroespaciales, las grandes compaas han de subcontratar desarrollos de pro-
400
ductos o paquetes de trabajo, a mltiples empresas en todo el mundo. La

seleccin del subcontratista, y el tipo de proyecto a subcontratar, se realiza
segn criterios de especialidades tecnolgicas de la empresa subcontratada,
costes u otros factores como pueden ser las necesarias certificaciones de calidad y no su localizacin geogrfica, por lo que el grado de complejidad en
la gestin y la coordinacin es alto, teniendo en cuenta y adems el factor
de la necesidad de una gestin transfronteriza.
La gestin de la subcontratacin es una parte importante de la gestin
del programa. Algunas consideraciones sobre cmo llevar a cabo una seleccin y gestin de subcontratistas son las siguientes:
Categorizacin de los subcontratistas: se categorizaran segn sus competencias y tipo de certificaciones de calidad, de tal forma que se tiene una
lista de subcontratistas preferentes para cada tipo de tecnologa. La lista de
subcontratistas se revisa peridicamente y se le aaden o quitan empresas
de acuerdo a su respuesta o cumplimiento contractual, o al resultado de las
auditoras que el contratista lleve a cabo.
Delegacin de competencias: dependiendo de la categora asignada
a cada subcontratista, se pueden delegar ciertas competencias, como por
ejemplo la gestin de la calidad del producto final, lo que supone un ahorro
en recursos de gestin por parte del contratista.
Ubicacin fsica: fomentar que los subcontratistas ubiquen una delegacin cercana a las cadenas de produccin de la empresa, lo que facilita la
gestin, la comunicacin y el control. En empresas como, por ejemplo, las
aeronuticas en las que los programas de produccin son de muy largo
plazo (ms de 30 aos) y, por lo tanto, los contratos con los subcontratistas lo son tambin, esto es un modelo ya implantado desde hace tiempo.
Acuerdos a largo plazo: en proyectos de alta complejidad, puede ser
ventajoso para ambas partes, que la vinculacin con el subcontratista sea
muy extensa en el tiempo, por lo que los acuerdos de colaboracin a largo
plazo pueden servir para obtener unas mejoras considerables, por ejemplo,
en costes.
Transferencia de tecnologa: la evolucin rpida de las tecnologas,
hace que, en proyectos de largo desarrollo, las tecnologas que en un principio eran core pasen a ser transferidas para la empresa a los subcontratistas, siendo para ellos, en cambio un avance tecnolgico, que desemboca
finalmente en una ventaja competitiva tanto para subcontratista como para
el contratista.
401
3.5. Programas de compensaciones industriales (OFFSET)

Finalmente, mencionaremos en lneas generales los fundamentos de los
programas offset. Los llamados programas de compensaciones industriales
(offset) se generan como consecuencia de grandes adquisiciones tecnolgicas a terceros pases por parte, normalmente, de los gobiernos. El gobierno que realiza la adquisicin busca el retorno de las inversiones realizadas
en forma de transferencias de tecnologas, Know-how, o paquetes de
trabajo a las empresas locales, que permitan la capacitacin tecnolgica y
el desarrollo de dichas empresas para programas futuros. En pases como
Estados Unidos, cuyo Gobierno y empresas han sido histricamente las
proveedoras de material de defensa para los pases occidentales, tanto los
programas de ventas de material de defensa a terceros pases mediante
contratos FMS (Foreign Military Sales) como los offsets asociados, estn
totalmente regulados.
a) Tipo de programas de OFFSET
Existen varios tipos de offset, dependiendo de si la transferencia de tecnologa o paquetes de trabajo estn directamente relacionado, o no, con el
programa de adquisicin. Los programas ms comunes de offset son:
t 0GGTFUT EJSFDUPT QSPHSBNBT EJSFDUBNFOUF SFMBDJPOBEPT DPO FM QSPducto o sistema adquirido. Por ejemplo: parte de la produccin del
sistema que se ha comprado se realiza, no por el fabricante original,
sino por una empresa local. Para que la empresa local pueda llevar
a cabo la fabricacin, el fabricante original ha de ceder la licencia de
produccin y transferir, no solo el conocimiento, documentacin y
especificaciones tcnicas, sino los recursos materiales y equipamiento
necesarios.
t 0GGTFUT JOEJSFDUPT QSPHSBNBT OP EJSFDUBNFOUF SFMBDJPOBEPT DPO FM
sistema adquirido. Por ejemplo: la empresa fabricante original, transfiere a una empresa local paquetes de trabajo que no tienen que ver
con el sistema adquirido, pero que pueden ser considerados de inters tecnolgico por el Gobierno que ha hecho la adquisicin.
Un ejemplo prctico, consideramos una empresa americana que vende
aviones militares a un pas europeo. El gobierno del pas que hace la adquisicin, acuerda un programa de offset, que incluye:
t 0GGTFUTEJSFDUPTMBQSPEVDDJOEFQBSUFEFMPTBWJPOFTBERVJSJEPT TF
realizar en una empresa local del pas que ha adquirido los aviones,
lo que traer consigo la instalacin de una cadena de produccin en
402
la empresa seleccionada y la transferencia del conocimiento, documentacin y recursos materiales asociados a la produccin.
t 0GGTFUTJOEJSFDUPTMBFNQSFTBBNFSJDBOBWFOEFEPSB USBOTGJFSFVOPP
varios proyectos de diseo y desarrollo de sistemas a una empresa
del pas que adquiere los aviones, para un futuro programa conjunto
de desarrollo, no relacionado con el avin adquirido. Los desarrollos
transferidos han de ser de reas tecnolgicas inexistentes en el pas
comprador, lo que asegurara una transferencia tecnolgica de valor
aadido para la empresa que recibe el contrato.
b) La gestin de los programas OFFSET
La gestin de los programas de offset tiene que tener en consideracin
los siguientes elementos:
t -PTNMUJQMFTJOUFSWJOJFOUFTFOMBEFGJOJDJOZFMBDVFSEPEFMPTPGGTFU
los gobiernos que intervienen tanto en la compra como en la venta
del sistema, la empresa fabricante original del sistema adquirido y las
empresas a las que irn dirigidas los contratos consecuencia de los
acuerdos de offset.
t -PT DSJUFSJPT EF WBMPSBDJO EF MPT QSPHSBNBT EF PGGTFU FM HPCJFSOP
comprador y la empresa fabricante original, del sistema que se adquiere, deben acordar un valor (o un criterio de valoracin) para
la transferencia del conocimiento y de las tecnologas cedidas a las
empresas locales del pas que adquiere el producto, y que sern las
beneficiarias de los acuerdos de offset. Normalmente, estas valoraciones son superiores al coste real de los paquetes de trabajo que se
transfieren ya que hay que valorar el inmaterial que supone el coste
de cesin del conocimiento.
t -BEVSBDJOEFMPTQSPHSBNBT: los programas de offset suelen ser de
larga duracin ya que, por lo general, se mantienen activos al menos
mientras dure el contrato de adquisicin.
t $POUSPMEFMQSPHSBNB: del cumplimiento de los compromisos contractuales por parte de la empresa vendedora.
En el caso de Espaa, uno de los programas de compensaciones ms
importantes se desarroll como consecuencia de la adquisicin, en los aos
80, de los aviones F-18 por parte del Ministerio de Defensa espaol. Las
compensaciones acordadas por Espaa por la compra de estos aviones,
supuso un retorno industrial que permiti que empresas como las actuales
EADS-CASA o INDRA, desarrollasen tecnologas que las capacitaron tecnolgicamente para que pudiesen hacer ms tarde sus propios desarrollos y
participar en programas multinacionales de alta tecnologa como el EF2000
Typhoon.
403
4. LA GESTIN DE EQUIPOS MULTINACIONALES

La puesta en marcha de proyectos multinacionales, requiere una gestin global/transfronteriza, de equipos multinacionales, que tiene grandes
ventajas, en cuanto al valor aadido que suponen elementos como la multiculturalidad, la utilizacin y reparto de las distintas especializaciones y
tecnologas, el acceso a diferentes mercados internacionales, los ahorros de
coste o infraestructuras, o el incremento de innovacin entre otros.
Pero tambin existen dificultades y retos en la gestin de equipos, tales
como la deslocalizacin (distancia fsica); el uso de un idioma (normalmente el ingls) no comn y no nativo para algunos de los participantes;
las distintas metodologas y procesos de gestin y trabajo usados por las
diferentes empresas, subcontratistas y suministradores; las distintas leyes
y regulaciones laborales en las diferentes reas geogrficas, y los distintos
entornos polticos econmicos y sociales, adems, y muy importante, de las
diferencias culturales, religiosas etc.
4.1. Los equipos globales
En los proyectos multinacionales, la organizacin clsica piramidal, localizada fsicamente en una sola ubicacin, donde los componentes de los
equipos de proyecto tienen una relacin diaria, pasa a ser una organizacin
horizontal, en la que los distintos equipos de proyecto multidisciplinares
estn localizados en diferentes zonas geogrficas, y la propia estructura del
programa requiere de herramientas de gestin y comunicacin que permitan una gestin global de todos los equipos del proyecto.
El trabajo en equipo, o la construccin de un sentido de equipo, pasa
por conseguir que ste, sea cual sea su distribucin o localizacin fsica,
tenga unos claros objetivos y un sentido individual de contribucin y valor
aadido para la consecucin de esos objetivos. La organizacin ha de implantar claros procesos de gestin y ejecucin de trabajo y una estrategia de
comunicacin que permita el flujo de informacin adecuado entre las reas
organizativas. Los principales aspectos que garantizan la creacin y gestin
de equipos multinacionales eficientes son: definicin e implementacin de
procesos consistentes claros y comunes, aceptacin de las diferencias culturales, clara estructura de equipos, implementacin de mecanismos de
transferencia de conocimiento y best practices, implementacin de una
eficaz estrategia de comunicacin.
404
a) La gestin de los equipos globales

La gestin de los equipos multinacionales, requiere habilidades y principios de liderazgo y gestin que aseguren la coordinacin de equipos
globales as como la de suministradores, subcontratistas y de clientes, ver
figura 16.6.
Figura 16.6. Competencias de gestin de equipos.
Aunque los conceptos bsicos de gestin y organizacin de un proyecto

no dependan de cuan global sea su desarrollo, todos los aspectos citados
en el apartado anterior, incrementan significativamente la complejidad en la
gestin de equipos y proyectos, ya que las organizaciones multinacionales
y sus equipos, requieren un alto grado de coordinacin, comunicacin, claras interfaces, procesos de trabajo claros y comunes o compatibles entre
405
las distintas organizaciones locales y un gran esfuerzo de integracin de

equipos y organizaciones.
La gestin global y a larga distancia, implica que el gestor, normalmente, tiene limitadas posibilidades de controlar la organizacin y el trabajo de
una forma personal y directa, lo que trae como consecuencia que haya que
establecer una gestin enfocada a resultados y una estructura de mando
clara como referencia para los miembros del equipo. El gestor de equipos globales multinacionales, ha de tener tanto competencias de liderazgo
como de gestin tales como las que a continuacin describimos.
b) Las competencias de liderazgo
Las competencias de liderazgo y comunicacin tal como, en detalle se
han escrito en el captulo 11, son fundamentales cuando se trata de equipos
multinacionales. Especficamente, el gestor de equipos multinacionales ha
de tener competencias para:
t &TUBCMFDFSZNBOUFOFSSFMBDJPOFTBMBSHBEJTUBODJBDPOFMMPTFRVJQPT
delegar responsabilidades, sin perder el control del programa. Apoyar
la independencia de los equipos, bajo su responsabilidad. Utilizar los
medios disponibles tales como videoconferencias, teleconferencias u
otros para mantener la comunicacin cuando esto no sea posible de
forma directa.
t *OWFSUJSFOFTUBCMFDFSSFMBDJPOFTDPOMPTFNQMFBEPTJOGPSNBS JOWPMVcrar en las decisiones a los empleados, comunicar conclusiones, dar
soporte y confianza.
t 4FSDPOWJODFOUFJODMVTPBMBSHBEJTUBODJBTFSDBQB[ VTBOEPMPTNFdios disponibles, de transmitir decisiones con argumentos convincentes, as como conciliar los diferentes puntos de vista de los miembros
del equipo.
t 5FOFSIBCJMJEBEQBSBHFTUJPOBSDPOGMJDUPTFOMPTFRVJQPTNVMUJOBDJPnales, por sus caractersticas ya comentadas, los conflictos son algo
inevitable. Es importante identificar el potencial problema y gestionarlo, antes de que el conflicto tenga consecuencias que impacten en
los resultados del proyecto.
t &TUBSEJTQVFTUPBDBNCJBSFMTUBUVRVP: revisar regularmente el estado
del programa y su organizacin y las mejoras aplicables en la organizacin y los procesos. Cooperar, comunicar y coordinar de forma
continua.
406
c) Las competencias de gestin

Son clave, para el xito de la gestin de programas globales, entre otros,
los siguientes aspectos con respecto a las competencias de gestin:
t %FMFHBDJO EF SFTQPOTBCJMJEBE la gestin de equipos globales, requiere que los jefes de proyectos locales, tengan clara delegacin
de responsabilidad, reconocida por el equipo, que les permita la
transmisin de directivas y el control de los resultados del equipo, as
como ser el punto de contacto e interlocucin nico.
t (FTUJOQPSPCKFUJWPT adems de conocer los objetivos generales de
la empresa, del programa y del proyecto dentro del programa, los
miembros del equipo han de tener objetivos individuales conocidos,
claros y evaluables. Esta evaluacin de objetivos ha de hacerse conjuntamente con los responsables directos del equipo y del programa,
al menos anualmente.
t 1SPDFTPTDMBSPTZEFGJOJEPTMPTQSPDFTPTEFHFTUJOIBOEFTFSDPNVnes a lo largo de los distintos equipos que participan en el proyecto;
deben de estar claramente definidos; deben de ser comunicados en
las directivas del programa a todos los equipos y sus miembros y,
por ltimo, han de ser revisados, peridicamente, para introducir
posibles mejoras o adaptarse a las diferentes fases del programa.
t 3FVOJPOFTFTUBCMFDJEBTZQFSJEJDBTDPOFMFRVJQPZTVTNJFNCSPT:
los avances en la comunicacin tales como videoconferencias o teleconferencias, facilitan enormemente el contacto con el equipo y han
de ser usadas siempre que sea necesario. Sin embargo la comunicacin directa, hace que el equipo se sienta ms vinculado con el lder,
y por lo tanto con el proyecto. Las reuniones peridicas son muy
importantes para la gestin y una ocasin de comunicacin directa,
no solo para revisin del programa, sino para el contacto individual
con los miembros del equipo.
t 1PUFODJBSMBDPNVOJDBDJOFGJDJFOUF adems de las reuniones peridicas, donde se revisa el estado completo del programa, sus riesgos
y sus aspectos financieros, la comunicacin, en todas las direcciones
(horizontal y vertical), es fundamental y una de la claves de xito de
la gestin de equipos globales, el establecimiento de canales adecuados que la potencien es muy importante (reuniones Ad-hoc, video
conferencias, intercambiaos culturales, actividades comunes, etc.), ya
que ayuda a la relacin de los distintos equipos entre si, adems de
con los responsables jerrquicos.
t %PUBSBMPTFRVJQPTEFMPTSFDVSTPTBEFDVBEPT el xito en la consecucin de un proyecto, no solo depende las herramientas de gestin,
sino de la capacidad del lder de dotar a los equipos de los recursos
407
de personal, en cuanto a capacidad y experiencia de sus miembros,

as como de los recursos materiales necesarios.
t .PUJWBDJOQFSTPOBMJOEJWJEVBMVOPEFMPTFMFNFOUPTNBTJNQPSUBOtes en el xito de la gestin de equipos, y ms si estos son globales/
virtuales y deslocalizados, es que cada miembro del equipo se sienta
motivado, no solo con los objetivos comunes, sino con los suyos
propios, es decir, futuro profesional, capacidad de crecimiento en la
empresa, formacin continua, acceso a documentacin y, en definitiva, crecimiento personal.
408
CAPTULO 17
CIERRE Y EVALUACIN DE PROYECTOS

Miguel ngel Hernndez Lpez,
Isabel Fernndez Fernndez
1. INTRODUCCIN
Al llegar a este captulo se ha aprendido a desarrollar un proyecto y se
ha visto que el mismo comprende un conjunto de actividades entre las que,
a ttulo de ejemplo, se pueden citar la planificacin y el seguimiento del
proyecto (vistas en los captulos 3 y 8 respectivamente), la asignacin de
recursos humanos y materiales, las relaciones con otros participantes, etc.
Todo lo anterior habr permitido obtener una configuracin o un producto
final (captulo 13) que, de acuerdo con los requisitos establecidos y buscados desde el inicio, permitirn satisfacer las necesidades de uno o varios
clientes. Sin embargo, el proyecto no ha terminado an, ya que llegados a
este punto se plantean una serie de cuestiones que es preciso resolver antes
de dar por finalizado el trabajo.
En primer lugar, de cara al exterior, es decir, ante los clientes y los organismos reguladores, habr que comprobar que el proyecto cumple con
todos los requisitos legales y que el cliente ha quedado conforme con su
realizacin. Es decir, hay que efectuar un cierre ordenado del proyecto
comprobando, entre otros aspectos, que:
Se ha cumplido con toda la normativa aplicable.
El proyecto est completo y tiene toda la documentacin exigible.
409
Se han resuelto todos los comentarios dados por el cliente o por los
Colegios Profesionales, en caso de que hubiera sido necesario obtener un visado del proyecto.
El cliente est satisfecho con el trabajo desarrollado. Este punto es
de importancia fundamental, ya que servir, como referencia para la
realizacin de trabajos posteriores, con el mismo cliente o con otros
diferentes.
Por otra parte, ante la propia empresa se deber comprobar el xito o el
fracaso obtenido en la realizacin del proyecto y, en cualquier caso, habr
que utilizar las lecciones aprendidas en futuros trabajos. Es decir, habr que
efectuar una evaluacin adecuada del proyecto, comprobando entre otros
aspectos, lo siguiente:
Si se han alcanzado los objetivos de rendimiento propuestos.

Si se ha cumplido con los plazos fijados.
Si se ha cumplido con las limitaciones presupuestarias.
Si la documentacin de cierre est debidamente ordenada y almacenada.
Qu lecciones se han aprendido del desarrollo del proyecto.
De todo lo anterior se puede deducir que el proceso de cierre y evaluacin de proyectos no es un asunto menor y que necesita ser tratado con
toda consideracin por las personas encargadas de su gestin.
2. CIERRE Y EVALUACIN DEL PROYECTO

Todo proyecto debe ser concluido y su cierre implica, en general, una
serie de aspectos comunes a todos ellos, con independencia de los que
sean especficos a cada tipo de proyecto (obra civil, consultora, I+D, etc.).
Un proyecto no termina porque se haya agotado el presupuesto establecido, o porque se hayan agotado los plazos previstos. Slo puede considerarse finalizado un proyecto cuando el cliente, interno o externo, se declare
satisfecho al ver que sus requisitos han sido satisfechos. La ambigedad en
la definicin de los objetivos, en la especificacin de los requisitos y/o en
sus mtodos de verificacin se traducir en dificultad para determinar si se
puede considerar el proyecto finalizado. La consecucin de los objetivos de
naturaleza tcnica no tienen por qu implicar que el proyecto haya acabado
en plazo y/o en presupuesto, que sern aspectos adicionales que habr que
analizar y que podrn tener implicaciones diversas, como penalizaciones
por incumplimiento de plazos, etc.
Por un lado, el cierre significa la aceptacin por parte del cliente del sistema o servicio contratado o encargado, lo que requiere generar evidencia
objetiva de que los requisitos especificados han sido satisfechos. Por otro
410
lado, el cierre conlleva una transferencia de propiedad y el comienzo del

perodo de garanta. Existen tambin implicaciones econmicas, desde la
facturacin de las cantidades pendientes al anlisis final de la rentabilidad
del proyecto. Y por ltimo, estn los aspectos relacionados con el personal,
las lecciones aprendidas y el conocimiento. Las siguientes subsecciones
abordan estos aspectos.
2.1. Pruebas de aceptacin y acta de recepcin
Al comienzo del proyecto deben estar definidas de manera inequvoca y
objetiva las pruebas que se realizarn al sistema con objeto de comprobar si
se han cumplido los requisitos especificados. Es esencial que el jefe de proyecto no comience a planificar las tareas ni mucho menos los trabajos sin
tener plena visibilidad de las pruebas de aceptacin que sern requeridas.
La realizacin de esas pruebas de aceptacin tendr implicaciones tanto de
personal requerido (incluyendo su necesaria capacitacin), instalaciones
necesarias, tiempo necesitado y coste asociado. Entre las tareas que integren la descomposicin estructurada de tareas del proyecto (mencionada
en el captulo 2) debern incluirse todas las relacionadas con la realizacin
y documentacin de las pruebas de aceptacin, para que sean incluidas
en la planificacin del proyecto (tema tratado en el captulo 3). Uno de
los principales riesgos en cualquier proyecto es la falta de aceptacin por
parte del cliente, y ese riesgo se minimiza con un entendimiento claro de
las pruebas que debern pasarse para tener esa evidencia objetiva del cumplimiento de los requisitos establecidos.
En ocasiones los clientes solicitan auditoras externas para esas pruebas
de aceptacin, ya sea por falta de medios y/o conocimientos propios para
realizarlas, o porque se quiera tener incluso mayor seguridad de que los
requisitos se han cumplido. Es cierto que, en los grandes proyectos, se habrn ido entregando informes de progreso para que el cliente vaya dando
sus comentarios, pero es en el momento del cierre del proyecto cuando los
comentarios suelen ser ms duros y crticos y pueden tener mayores implicaciones, llegando incluso a rechazarse la entrega del sistema.
No se debe olvidar que el origen de los comentarios muchas veces se
encuentra en el propio cliente, que no especific correctamente el resultado
esperado, pero incluso en este caso cabe preguntarse de quin es la responsabilidad, si del cliente por no especificar de forma correcta y completa o
del autor del proyecto por no aclarar a tiempo estas indefiniciones. Lo deseable habra sido no comenzar a realizar los trabajos hasta haber aclarado
cualquier indefinicin, pero esto no siempre es posible, como consecuencia
de problemas desconocidos en la fase de inicio o que no haya sido posible
aclarar hasta que el proyecto se encuentra en fase de realizacin. Asumir la
411
responsabilidad de la gestin de un proyecto implica conocer, entre otros,

los objetivos y alcance del proyecto, los requisitos detallados y las pruebas
de aceptacin requeridas; de no ser as el jefe de proyecto debe, antes
que nada, solicitar las aclaraciones o informacin adicional que necesite.
Comenzar a trabajar en un proyecto sin ese conocimiento es un riesgo inasumible y una prctica muy poco profesional.
Una vez cumplido con los trmites anteriores se presentar al cliente la
correspondiente acta de recepcin, solicitando su firma en la misma, como
confirmacin de la aceptacin y aprobacin final del proyecto. Debe tenerse en cuenta que esta aceptacin por parte del cliente es una condicin
imprescindible para poder dar por finalizado y cerrado el proyecto y, por lo
tanto, para poder efectuar la facturacin indicada en el apartado siguiente.
El formato del acta de recepcin puede adoptar diversas formas, pero lo
fundamental de la misma es que en ella figure, de forma expresa, la identificacin del proyecto junto con referencia a los documentos contractuales
(pliegos de concurso, oferta realizada, contrato firmado, etc.), la fecha de la
entrega, los documentos o productos entregados y la aceptacin de los mismos. Esta acta deber ser firmada, tanto por la persona responsable en el
cliente como por la persona responsable de la empresa que ha realizado el
proyecto, que normalmente ser el jefe del proyecto. Conviene sealar que,
a veces, especialmente en proyectos menores, o en el caso de estudios previos, trabajos de auditora, etc., el acta de recepcin se puede sustituir por
una simple carta de transmisin de la documentacin o producto asociado
al proyecto. En esta carta se har constar la aceptacin de los trabajos por
parte del cliente, el cual deber devolver una copia firmada de la misma.
2.2. Facturacin final del proyecto
Cuando se habla de gestin de proyectos, es habitual centrarse en todos
los trabajos y procesos de ejecucin, dejando al margen la tareas puramente
administrativas que tambin suelen ser realizadas por los jefes de proyecto.
Una de stas es, al inicio del proyecto, el diseo y acuerdo con el cliente de
un plan de facturacin que asegure los fondos necesarios para que el desfase entre los costes incurridos y los ingresos obtenidos sea el menor posible
y se minimice, de esta forma, el coste financiero del proyecto.
La facturacin final va a depender, por tanto, de los planes de facturacin acordados que habitualmente se establecen: por hitos, vinculndose la
factura al cumplimiento de objetivos; lineal que es habitual en los proyectos
de larga duracin y que normalmente utiliza el concepto de horas estndar
imputadas para la justificacin de la factura; por costes incurridos, que es
una mezcla de las dos anteriores y que, para no caer en una discusin con
el cliente, precisa de una definicin muy clara de las horas necesarias para
412
la realizacin de los trabajos, ya que se facturan horas realmente trabajadas

y materiales realmente consumidos.
En cualquier caso siempre existe, al final del proyecto, una factura final
ligada al acta de recepcin o, en su caso, a la carta de transmisin de la
documentacin al cliente. Esta factura ser la que complete, deducidas las
facturas anteriormente emitidas, el precio final del proyecto facturado al
cliente. Salvo que se trate de proyectos auditables en costes por el cliente
(slo habitual en proyectos pblicos o de gran envergadura donde se pacta
un beneficio sobre el coste incurrido) la factura final no suele ir acompaada de ningn informe econmico adicional para el cliente.
En determinados proyectos (como en los de construccin) el cliente
puede exigir una retencin sobre el monto total de la factura, para cubrir un
periodo de garanta o vicios ocultos durante un plazo previamente acordado. Esto no implica que la factura no recoja el monto total para finalizar el
proyecto, sino que el cobro de la misma ser parcial para que, en su caso,
el cliente pueda hacer frente a posibles daos, errores o problemas que
puedan surgir con posterioridad a la recepcin del proyecto. No obstante lo
anterior, la frmula habitual para cubrir esos posibles problemas suele ser
la solicitud de un aval a favor del cliente, que ser liberado una vez haya
trascurrido el periodo de garanta pactado.
Las actividades indicadas en los dos apartados anteriores constituyen el
denominado cierre ordenado del proyecto, un esquema del cual se incluye
en la figura 17.1.
Figura 17.1. El cierre ordenado del proyecto.
413
2.3. Anlisis de rentabilidad final del proyecto

Habitualmente, el concepto de rentabilidad est ligado al beneficio econmico obtenido una vez que el proyecto ha finalizado y se ha procedido al
cierre del mismo, con la aceptacin por parte del cliente, o de la direccin
de la empresa en el caso de proyectos internos. Sin embargo, el concepto de
rentabilidad es ms amplio ya que, en funcin del tipo de proyecto, puede
abarcar aspectos ms cualitativos o intangibles como pueden ser el incremento de capacidades, la obtencin de mejoras operativas o los beneficios
sociales que proporcionan, por ejemplo, los proyectos llevados a cabo por
una ONG. En cualquier caso, lo importante es haber definido claramente,
en el momento de la planificacin, cul es el objetivo de rentabilidad del
proyecto para poder realizar, en el cierre, un correcto y completo anlisis
de evaluacin econmica y/o social del mismo.
Para analizar la rentabilidad en los proyectos de servicios y en los que
tienen como objetivo un bien social, es muy frecuente que se definan indicadores cualitativos que, desde el punto de vista econmico, nos permita
determinar, sino el rendimiento, al menos el incremento de valor o la utilidad final del proyecto. Entre otros se pueden citar:
t *ODSFNFOUPEFMWBMPSEFMBDDJPOJTUB
Es evidente que si el proyecto ha generado beneficios, stos coadyuvan
a incrementar el valor de la empresa y, como consecuencia, el valor del
accionista. Sin embargo, no slo son los beneficios econmicos los que hay
que registrar en este concepto ya que, si el proyecto ha salido bien y el
cliente est contento, habra que poder contabilizar factores como: fidelizacin de clientes (posibles pedidos futuros); incremento en la capacitacin
del personal del proyecto (mayor facilidad para poder acometer nuevos
proyectos) y mejora de la imagen de la empresa. Es difcil valorar estos conceptos intangibles pero sin duda habr que buscar las mtricas adecuadas a
cada tipo de proyecto para incluirlos en el informe final de cierre.
t 3FMBDJODPTUFQSFWJTUPTPCSFDPTUFSFBM
En la mayora de los proyectos pblicos cuyo objetivo es un bien social, como la construccin de hospitales o escuelas, la manera de medir
la rentabilidad final del proyecto es a travs de la relacin entre el coste
inicialmente presupuestado para llevar a cabo la obra y el ahorro en costes
obtenido a la finalizacin del proyecto, siempre que ello se haya realizado
sin menoscabo de la calidad final de la obra.
No obstante lo anterior, y tal y como se vio en el captulo 6, no hay
duda de que el objetivo fundamental de la mayora de los proyectos es la
414
obtencin de una rentabilidad econmica que permita a la empresa recuperar el capital invertido y generar fondos para acometer futuros proyectos.
La frmula habitual para medir la rentabilidad final de un proyecto es la
siguiente:
t 3FOUBCJMJEBEFDPONJDBTPCSFGBDUVSBDJOEFMQSPZFDUP
La frmula utilizada R= 1-(Ct/It), donde R es la rentabilidad en %; Ct es el
coste total incurrido en el proyecto (incluyendo el de garanta si lo hubiera)
e It es el volumen total de ingresos (facturacin sin IVA del proyecto).
t 3FOUBCJMJEBEFDPONJDBTPCSFMBJOWFSTJO
El tradicional ROI (Return of Investment) nos da, expresado en %, la rentabilidad final que ha representado, para el inversor, el proyecto ejecutado.
Lo calculamos mediante la aplicacin de la frmula ROI = 1- [(Ct-Bt)/Ct],
donde Bt es el beneficio neto obtenido en el proyecto (una vez deducidos
los impuestos que sobre l tuvieran lugar); Ct es el coste total incurrido en
el proyecto, incluso el de garanta.
Si por ejemplo, se tiene un proyecto cuya facturacin final ha sido de
60.000, los costes totales incurridos hasta su finalizacin y aceptacin son
de 50.000 y el impuesto sobre beneficios empresariales es del 30%, tendramos una rentabilidad del R=16,6% calculando, 1- (50.000/60.000) y un
ROI del 14%, calculando, 1-[(50.000-7.000)/50.000)= 14%, donde el beneficio neto ha sido de Bt= 10.000x(1-0,30)=7.000
2.4. Informacin econmica de cierre
Como se ha dicho en el punto anterior, la factura final no suele ir acompaada de informacin econmica adicional. No obstante, cuando el cliente
haya exigido en el plan de facturacin la inclusin de determinados anexos
en la factura final, como por ejemplo: relacin de nmero de horas facturadas; materiales y otras compras que se facturan; gastos suplidos, etc. se
debe anexar el resumen agregado de todos los desgloses parciales que han
acompaado a las anteriores facturas emitidas, de tal forma que se tenga el
resultado agregado de las horas, materiales y gastos totales facturados en
el proyecto.
A diferencia de la informacin a la que se refiere el prrafo anterior, la
informacin econmica del cierre del proyecto, a efectos internos (y a la
que el cliente no tendr acceso excepto que se trate de proyectos, como
los de investigacin, con facturacin de costes incurridos con un margen
contractual negociado) ser de gran importancia, no slo para el proyecto
que se cierra sino como base histrica para el clculo de costes de futuras
415
propuestas econmicas. La documentacin habitual que debe acompaar al

cierre interno del proyecto es la siguiente:
t Tabla de relacin de costes reales incurridos en el proyecto respecto
a los inicialmente presupuestados. Esta relacin se deber realizar de
manera detallada segn el desglose CBS (Cost Breakdown Structure)
o los paquetes de trabajo WBS (Work Breakdown Structure) que se
hayan utilizado para los clculos del presupuesto que dio lugar a la
oferta econmica del proyecto, y que incluir el desglose de horas,
materiales y otros costes del mismo.
t Informe de anlisis de las principales desviaciones mostradas en la
tabla anterior, con explicacin detallada de las causas y, en su caso,
de las medidas correctivas que se utilizaron para mitigarlas.
t Informe de compras, incluyendo la relacin de materiales y los precios de los contratos cerrados con cada proveedor (como se ver en
el tema 18, stos contratos han podido incluir los precios de suministros negociados para posibles contratos de apoyo al ciclo de vida).
En el caso de no existir contrato de adquisicin se incluir la factura
de compra.
t Informe financiero sobre el origen y aplicacin de los fondos del
proyecto, con detalle sobre los fondos propios y la amortizacin de
los fondos ajenos solicitados para el proyecto.
t Estudio de costes de operacin y mantenimiento, si fuera el caso.
Adems de la informacin anterior, la empresa deber analizar en profundidad los resultados del proyecto a travs de una serie de indicadores
que, aunque en su mayora, se habrn ido calculando durante la etapa
de control y seguimiento del proyecto, para obtener la informacin actualizada y detectar posibles problemas, es en el cierre cuando cobran
especial relevancia y muestran la situacin real del proyecto, al no existir
desfases entre trabajos ejecutados, tiempo empleado y costes e ingresos
contabilizados. Estos indicadores se muestras en la siguiente subseccin.
Un esquema de lo indicado en los dos apartados anteriores puede verse
en la figura 17.2.
416
Figura 17.2. La evaluacin del proyecto.
2.5. Indicadores de la evaluacin del proyecto

A la hora de analizar los resultados de un proyecto, parece conveniente definir un conjunto de indicadores que nos ayuden en esta tarea y que
nos permitan establecer criterios comparativos con otros casos similares
desarrollados por la misma empresa o con los mismos clientes. Un resumen de estos indicadores se presenta en la figura 17.3 al final de esta Subseccin. Entre estos indicadores, se pueden considerar los mencionados
a continuacin.
417
a) Indicadores econmicos
Se obtienen del cierre contable del proyecto y entre ellos pueden mencionarse los siguientes, que se aplicarn todos o alguno de ellos en funcin
del tipo de proyecto de que se trate:
t 'BDUVSBDJOEFMQSPZFDUP.VFTUSBFMWPMVNFOUPUBMGBDUVSBEPQPSMB
realizacin de los trabajos y servir para evaluar otros indicadores,
como, por ejemplo, el margen o el beneficio del proyecto.
t .BSHFOEFMQSPZFDUP.VFTUSBMBEJGFSFODJBFOUSFMPTJOHSFTPTZMPT
costes asociados a la realizacin del proyecto.
t #FOFGJDJPBDUVBMJ[BEPBMBGFDIBEFDJFSSFEFMQSPZFDUP&TUFJOEJDBdor es similar al anterior, pero en l se tienen en cuenta los costes
actualizados de los recursos humanos y materiales utilizados para el
desarrollo de los trabajos.
t $PTUFQPSIPSBUSBCBKBEB.VFTUSBFMDPTUFRVFIBTVQVFTUPDBEBIPSB
de trabajo propio dedicada al desarrollo del proyecto. Se obtiene dividiendo los costes del proyecto, una vez descontadas las cantidades
correspondientes a los trabajos subcontratados y los gastos utilizados
en suministros, entre las horas propias utilizadas.
t 1SFDJPEFWFOUBEFMBIPSBUSBCBKBEB.VFTUSBFMQSFDJPBMRVFIBbra que vender la hora trabajada para obtener beneficios iguales
a los del proyecto analizado. Se obtiene dividiendo la facturacin
del proyecto, una vez descontado el importe destinado a subcontrataciones y suministros, entre el nmero de horas propias utilizadas.
b) Indicadores financieros
Muestran el origen de los fondos utilizados para poder desarrollar el
proyecto, y su proyeccin en el tiempo. Entre ellos se pueden mencionar
los siguientes:
t 1PSDFOUBKFEFFOEFVEBNJFOUPFYUFSOP Si una empresa factura por
la realizacin de sus trabajos de forma similar a la indicada en el
apartado anterior de Facturacin final del proyecto y, adems, una
vez efectuada esta facturacin, tarda en cobrar otro perodo, ms o
menos largo de tiempo, es evidente que durante un elevado nmero de meses ha de financiar, con fondos propios, la mano de obra,
las subcontrataciones, los suministros, etc. Todo esto, ms el riesgo
de no cobrar por los trabajos realizados, en el mejor de los casos,
supone unos costes financieros. El valor de este riesgo, que la empresa deber abonar a terceros, en caso de impagos, como deudas
418
contradas con ellos, constituye el porcentaje de endeudamiento

externo.
t 1PSDFOUBKFEFFOEFVEBNJFOUPQSPQJP Este indicador muestra el porcentaje de endeudamiento interno (con la propia empresa) y se calcula como el valor complementario del porcentaje de endeudamiento
externo.
t 7BMPSBDUVBMOFUPEFMQSPZFDUP&TUFJOEJDBEPSUJFOFFODVFOUBMPT
valores monetarios referidos al instante en que los mismos se producen, y calcula su valor actualizado en el momento del cierre del
proyecto.
t 3FOEJNJFOUPEFMQSPZFDUP. Este indicador tiene en cuenta el tiempo y
el dinero necesarios para obtener el margen comercial del proyecto.
En otras palabras, se calcula dividiendo el margen del proyecto entre
el tiempo necesario para obtenerlo.
c) Indicadores de ocupacin laboral
Las empresas obtienen sus beneficios mediante el trabajo de sus
empleados, por lo que, mantenerlos ocupados es de una importancia
enorme y es aqu donde los indicadores de ocupacin laboral nos
proporcionan una idea de cuntas personas han hecho falta para la
realizacin del trabajo. Entre estos indicadores se pueden mencionar
los siguientes:
t -BDBSHBEFUSBCBKP Representa el nmero de horas de trabajo de
cada categora, necesarias para realizar completamente un trabajo.
t &MOEJDFEFPDVQBDJO Viene dado por el resultado de dividir la
carga de trabajo en un perodo entre el nmero de horas de trabajo hbiles en dicho perodo.
d) Indicadores de gestin
t -PTJOEJDBEPSFTEFHFTUJOTPOMPTRVFNJEFOMBTEFTWJBDJPOFTFOUSF
los valores previstos al inicio del proyecto y los valores finalmente
obtenidos tras el cierre del mismo.Entre estos indicadores, podemos
citar el cumplimiento del plazo de realizacin del proyecto.
Un esquema de lo indicado en este apartado puede verse en la figura
17.3.
419
Figura 17.3. Diferentes tipos de indicadores de evaluacin del proyecto.
420
2.6. Personal, lecciones aprendidas y gestin del conocimiento

Cada proyecto supone una extraordinaria oportunidad de aprendizaje
para cualquier empresa o institucin. Al comienzo del proyecto se realizan
muchas estimaciones que despus podrn ser contrastadas, a medida que
se desarrolla el proyecto. Es esencial que entre las tareas del proyecto se
incluyan las relacionadas con la generacin de lecciones aprendidas y con
la difusin interna del conocimiento generado, pues de lo contrario no se
dedicarn los recursos adecuados y se perder la oportunidad de recopilar
las lecciones aprendidas. Esta actividad no es slo realizable en el momento
del cierre del proyecto, sino que debe ser constante durante toda su ejecucin. Capitalizar las lecciones aprendidas y ser una organizacin abierta
al aprendizaje [Senge, 1992; Edmondson, 2012] aporta a cualquier empresa
o institucin un extraordinario valor aadido. Las lecciones aprendidas y
el conocimiento generado podrn reflejarse en procedimientos, informes,
listas de comprobacin, instrucciones tcnicas, etc. La documentacin generada deber ser conservada y difundida entre los empleados de la empresa
o institucin que la puedan necesitar, para que sea utilizada en el desarrollo
de otros proyectos, evitando as la realizacin del mismo trabajo en diferentes ocasiones. Sin embargo, deber establecerse un sistema de acceso
controlado a la misma, evitando que pueda ser mal utilizada o, incluso,
en ciertos casos, que pueda caer en manos de competidores. Mucho ms
importante que la recopilacin de las lecciones aprendidas es su difusin
junto con la del conocimiento generado, para que puedan ser asimilados
y puestos en prctica por otras personas de la empresa o institucin. Ello
permitir, entre otras cosas, realizar con mayor fiabilidad las estimaciones
necesarias de tiempos, esfuerzos y costes en futuros proyectos, minimizando adems sus riesgos.
Todos los integrantes del equipo del proyecto pueden realizar valiosas
aportaciones en ste mbito, con independencia de su edad, formacin o
nivel de responsabilidad en el proyecto. Lo importante es que el jefe de
proyecto cree una cultura en la que el conocimiento se valore, de manera
que los miembros del equipo sientan el estmulo de aportar sus reflexiones
personales. La identificacin de lecciones aprendidas y de oportunidades
de mejora depende en gran medida de la motivacin de la gente, que a su
vez depende de la cultura y espritu de equipo que haya logrado crear el
jefe de proyecto, as como de su propia actitud. Predicar con el ejemplo es
la mejor manera de liderar y estimular, por lo que el jefe de proyecto deber ser el primero en reconocer de manera explcita aquellas decisiones o
acciones personales que pudieran haber resultado ms efectivas o eficaces
de haberse realizado de otra manera, para que los miembros del equipo
se sientan estimulados a seguir su ejemplo. Tambin es posible establecer
421
sistemas de recompensas ligadas a la identificacin de lecciones aprendidas

y de oportunidades de mejora; esas recompensas pueden ser econmicas o
tomar forma de reconocimiento o promocin; no obstante, hay que evitar
que las recompensas establecidas desvirten la necesaria profesionalidad
con la que todos los miembros del equipo deben comportarse, empezando
por el propio jefe de proyecto.
Una forma interesante de documentar las lecciones aprendidas es en
forma de historias que sinteticen las vivencias del proyecto [Kleiner et
al., 97]. Las historias son fciles de recordar y permiten recoger aquellos
aspectos que las siguientes generaciones deben recordar. Documentar en
forma de historias las lecciones aprendidas tiene importantes ventajas,
como el transmitir a todos los miembros del equipo que sus opiniones
son tenidas en cuenta y son consideradas valiosas, y permiten recoger las
experiencias de personas que no siempre se sienten cmodas expresndolas abiertamente en pblico. Aprendemos a nivel individual aunque
trabajamos en grupo y el aprendizaje de la persona no lo garantiza a nivel
institucional; es necesario articular el sistema que permita recoger ese
conocimiento generado y lo ponga a disposicin del resto de personas de
la empresa o institucin. Cuando esas otras personas lo hayan interiorizado y puesto en prctica, entonces podr decirse que la organizacin est
realmente abierta al aprendizaje.
El conocimiento puede y debe ser protegido, por lo que una opcin a
tener siempre en cuenta es la solicitud de registros y patentes de aquellos
desarrollos nuevos que se realicen en el proyecto, de manera que la empresa o institucin obtenga de ello el correspondiente rendimiento. Por ltimo,
es necesario tener en cuenta qu conocimientos ser necesario mantener
disponibles en la empresa o institucin para dar a los clientes el adecuado
apoyo tras el cierre formal del proyecto. Con frecuencia se deshacen los
equipos de los proyectos a su terminacin, sin tener en cuenta el apoyo que
ser necesario dar tanto durante el perodo de garanta como despus. Una
adecuada gestin del conocimiento por parte del jefe de proyecto ayudar
a que el no dejar residente los recursos y competencias necesarias sea una
leccin dolorosamente aprendida.
La finalizacin de un proyecto supone la liberacin de los recursos a l
asignados, que pasarn a estar disponibles en la empresa o institucin para
su reasignacin a otras actividades. Eso es especialmente importante en lo
referente a los miembros del equipo. No todas las tareas se finalizarn al
concluir el proyecto; muchas irn finalizando antes, por lo que la liberacin de recursos humanos en el proyecto suele ser gradual. Sin embargo,
es necesario mantener la visin global en todo momento ya que para la
realizacin de las pruebas de aceptacin es posible que se requiera el concurso de personal que estuvo ligado a determinadas tareas y que ha sido
422
ya reasignado a otros proyectos. Por ello el jefe de proyecto debe tener

plena visibilidad de quines debern participar en qu momento en qu
tareas o actividades, de forma que la liberacin y reasignacin de recursos
humanos no presente un problema para el proyecto, ni porque suponga
una cierta descapitalizacin tecnolgica si antes de su reasignacin no se
han recopilado las oportunas lecciones aprendidas, ni porque se tengan
carencias de apoyo en algn hito del proyecto o en las pruebas finales de
aceptacin. Un esquema de lo indicado en este apartado puede verse en
la figura 17.4.
Personal, lecciones y gestin del conocimiento
Objetivos
Consecuencias
t3FDPQJMBDJO
de lecciones
aprendidas
t&TUJNBDJPOFT
ajustadas para
futuros proyectos
t%JGVTJOEF
lecciones
aprendidas y
conocimiento
generado
Precauciones
t1BUFOUFT OVFWPT
desarrollos)
t$POUSPMBDDFTPBMB
documentacin
t*OGPSNBDJOEF
apoyo a clientes
t/PEJTPMWFS
equipos de trabajo
antes de tiempo
(pruebas)
Figura 17.4. La gestin del conocimiento generado en el desarrollo del proyecto.
3. REFERENCIAS
DOMINGO AJENJO, A., Direccin y Gestin de Proyectos. Un enfoque prctico. RAMA, 2005.
EDMONDSON, A. C., Teaming; how organizations learn, innovate and compete in the
knowledge economy. Harvard Business School, 2012.
KLEINER, A. y ROTH, G., How to Make Experience your Companys Best Teacher.
Harvard Business Review, September-October 1997, pp. 172-177.
SENGE, P., La quinta disciplina. Granica, 1992.
423
CAPTULO 18
APOYO AL CICLO DE VIDA

Javier Romero Yacobi
1. INTRODUCCIN
Uno de los pensadores ms influyentes en la gestin empresarial del
siglo XX, Peter Drucker, deca que lo que el cliente quiere comprar y considera valioso nunca es el producto. Es la utilidad, es decir, aquello que le
aporta el producto [Drucker, 1999]. Todo proyecto termina (ver captulo
17) pero ese cierre no significa la satisfaccin permanente y garantizada del
cliente; sus nuevas necesidades de apoyo son la oportunidad del contratista
y ah nacen los proyectos de Apoyo al Ciclo de Vida.
Como ya se ha explicado a lo largo del libro todo proyecto persigue un
fin, la satisfaccin de las necesidades identificadas por el cliente y demandadas al mercado. Una vez entregado el producto se abre la ventana de una
nueva necesidad, el soporte al producto, de unos (cliente) y de oportunidad
para otros (el contratista). Las actividades de soporte o de Apoyo al Ciclo de
Vida (a partir de ahora se nombraran por sus siglas ACV) tienen como objetivo que la utilidad del producto se mantenga constante o mejore durante
toda la vida del producto.
El Apoyo al Ciclo de Vida es un concepto muy amplio que comprende
el conjunto de actividades y procesos de gestin, logsticos y de ingeniera,
necesarios para el sostenimiento de los sistemas o productos de forma que
se garantice la correcta operacin de los mismos cuando y donde sean requeridos, as como el mantenimiento y la actualizacin de sus capacidades
a lo largo de su ciclo de vida.
425
Los objetivos fundamentales de este captulo son en primer lugar mostrar la importancia de los proyectos de ACV, las ventajas estratgicas para
la empresa que los suministra y cmo el cliente mejora su satisfaccin por
el mejor uso de su activo. Tambin se definen las caractersticas especficas de este tipo de proyectos y las actividades que se incluyen. Se termina
realizando una sntesis de los diferentes tipos de modelo de negocio para
proveer servicios de ACV.
2. IMPORTANCIA Y VENTAJAS ESTRATEGICAS DE LOS PROYECTOS DE
ACV
Desde principios de los 90 las empresas empezaron a centrarse en el

valor que los consumidores obtienen al utilizar los productos en vez de en
la propia venta del producto. Este giro vino motivado por una disminucin
de la demanda, una alta competencia y una cada de los mrgenes de beneficio. La venta de repuestos y servicios de postventa como por ejemplo
ejecutar reparaciones, llevar a cabo mejoras en los productos, renovar los
equipos, encargarse de las inspecciones y del mantenimiento planificado,
ofrecer soporte tcnico, formacin, etc., tambin podan ser una abundante fuente de ingresos y beneficios. La empresa de investigacin Aberdeen
Group fija la venta de repuestos y servicios postventa en EE.UU. en un 8%
del PIB anual [Cohen et al., 2006]. Si se estudian los datos en el sector de
defensa, en el ao 2010 entre las 100 primeras empresas en facturacin hay
20 empresas que son suministradoras especializadas en servicios de ACV.
Dichas empresas han aumentado su facturacin en un 147% desde 2002
a 2010. Para otras compaas no especializadas en servicios, la cuota de
facturacin procedente de esta actividad sigue aumentando; por ejemplo
BAE Systems indic que el 48% de su facturacin proviene de la venta de
servicios. Siendo la facturacin media en actividades de ACV un 38%. Cambiando de sector se puede citar el ejemplo de RENFE que tiene externalizado el apoyo logstico de sus trenes regionales con las propias compaas
fabricantes, normalmente en contratos de apoyo logstico de 14 aos de
duracin. Las ventajas para el cliente son fundamentalmente el ahorro en
costes, mejora de la disponibilidad y operatividad de su activo y dedicar sus
recursos al uso del bien (ver la seccin 4).
El uso generalizado de herramientas que mejoran los procesos productivo como el Seis Sigma, la Gestin de la Calidad Total que prepara
los procesos para producir el producto correctamente la primera vez y
analizar los defectos encontrados con minuciosidad para evitar su repeticin; la Gestin Integral de la Cadena de Suministro que busca compartir
informacin entre proveedores y clientes con el fin de coordinar los pedidos y los stocks de repuestos; la Gestin de Relacin con los Clientes
426
que reduce los costes de venta y propicia un mejor entendimiento del

cliente, han generado productos de mayor calidad y procesos ms eficientes [Chesbrough, 2011]. Pero todas estas metodologas han sido implementadas por la mayora de las empresas haciendo necesario un mayor
esfuerzo (inversiones en I+D+i por ejemplo) para conseguir la diferenciacin por producto. Parece claro que una propuesta de valor centrada en
la utilizacin del activo brinda una oportunidad adicional para mejorar la
competitividad de la empresa.
En los proyectos de ACV el cliente se centra en la utilidad del bien lo
que a su vez da una oportunidad al contratista. En el punto 4 se estudiaran
las propuestas de valor para el cliente, en esta seccin se citan las principales ventajas estratgicas que estos servicios pueden suministrar a la empresa
que los proporciona:
t &MOFHPDJPEFM"$7FTVOBGVFOUFQPUFODJBMEFJOHSFTPTEVSBOUFMB
fase de servicio. Cada vez ms los clientes se estn centrando en
utilizar sus recursos propios en operar sus activos y externalizan el
soporte.
t -PT QSPZFDUPT EF "$7 TPO EF MBSHB EVSBDJO DPO VOB GBDUVSBDJO
anual estable. Por ejemplo los fabricantes de aviones pueden seguir
facturando despus de la entrega del avin durante 20 o 25 aos segn la duracin de la vida operativa.
t -BTBDUJWJEBEFTEF"$7QFSNJUFOVOBQPMUJDBEFBDUVBDJOBDUJWBDFOtrada en el cliente, creando una propuesta de relacin a largo plazo
(fidelizacin). Por ejemplo segn algunos estudios del mundo del automvil existe una correlacin muy bien definida entre la calidad de
los servicios de ACV prestados por la marca y la intencin del cliente
de volver a comprar un coche de la misma casa.
t -PTTFSWJDJPTEF"$7TPOVOBQPTJCMFWBEFNBSDBSMBTEJGFSFODJBT
con la competencia. Por ejemplo las empresas de construccin naval, que tradicionalmente basaban su negocio en la construccin
de buques y se olvidaban de la vida operativa, han incluido en su
portfolio los servicios de ACV completando de esta manera su participacin en toda la vida de los buques, pasando de facturar slo
en la fase de diseo y produccin a vender servicios en la fase de
operacin del buque e incluso en el desguace de la unidad.
t %VSBOUFMBFKFDVDJOEFMPTTFSWJDJPTEF"$7TFUSBCBKBDPOKVOUBNFOte con el cliente lo que permite a la empresa obtener informacin
de tecnologas, procesos y planes de los clientes mejorando as la
posicin competitiva de la compaa de cara a nuevos contratos. Esta
idea se engloba en la actualidad en el concepto conocido como inteligencia competitiva.
427
3. ELEMENTOS DE UN PROYECTO DE ACV

Cuando se habla de un proyecto de ACV bajo el prisma integral del
ciclo de vida de un producto/sistema se refiere a un proyecto que se
desarrolla en la fase de utilizacin del mismo, sin embargo los trabajos
relacionados con esta fase comienzan desde el inicio. Durante las fases
de viabilidad y definicin se analizan las necesidades del cliente desde
el punto de vista operativo a nivel global y se establecen unos requisitos
que sern la base para definir el sistema. En esta fase es fundamental
identificar las necesidades futuras de apoyo al producto para una operacin acorde con los objetivos, de forma que el diseo se oriente a la
consecucin de estos objetivos y se optimice la relacin coste-eficacia del
mantenimiento. En las fases de ingeniera y construccin el objetivo es
disear para que se cumplan los objetivos de soportabilidad del sistema y
se identifiquen los elementos de apoyo logstico necesarios para asegurar
la operatividad del sistema a lo largo de su vida en servicio. Por ltimo,
en la fase de servicio el objetivo es sostener el diseo de tal forma que
el sistema siga manteniendo durante toda su vida, en trminos relativos,
las mismas prestaciones que tena cuando entr en servicio. La figura 18.1
identifica los objetivos de cada fase del ciclo de vida de un sistema desde
el punto de vista de la soportabilidad.
Como ya se ha dicho, el ncleo de este captulo son los proyectos de
ACV en la fase de servicio. Con esta premisa los aspectos ms especficos
de un proyecto de ACV se muestran en la figura 18.2. Cada uno de estos
aspectos relacionados con la empresa en su vertiente interna es desarrollado en las siguientes subsecciones mientras que la parte vinculada con el
cliente, es decir la repuesta a las preguntas qu necesidad se satisface del
cliente? y cmo se obtiene el beneficio? se tratan en la seccin 4.
Figura 18.1. Objetivos del ACV en el Ciclo de Vida de un sistema.
428
Figura 18.2. Elementos claves a considerar en un proyecto ACV.
429
3.1. Aspectos clave en los servicios/actividades de ACV

En esta subseccin se describen los aspectos claves de los servicios
suministrados, que sirven para sostener el diseo del sistema o activo
durante la fase de servicio. Una visin general de estos se muestra en la
figura 18.3.
Figura 18.3. Mapa de actividades de ACV.
A continuacin se exponen brevemente los principales elementos y aspectos de las actividades de ACV:
a) Gestin
i. Los servicios relacionados con el control de la configuracin en la
fase de utilizacin del sistema se realizan durante la fase de uso del
sistema lo que implica que las tareas principales sean: gestionar el
proceso de modificaciones, registrar y monitorizar toda la documentacin y datos tcnicos asociados, la gestin de cambios a la configuracin, informes de estado y auditorias de la configuracin.
430
ii. La cadena de suministro es el proceso de planificacin, implementacin y control de la distribucin de los materiales a lo largo de las
operaciones de la cadena, de la forma ms eficiente posible, desde el
origen del material hasta el usuario (ver el captulo 5). En este caso
los servicios proporcionados son:
t 3FQVFTUPT
t &RVJQPTEFBQPZPZQSVFCB QBSUJDVMBSFTZHFOFSBMFT
QFSUSFDIPT
adquisicin y gestin.
t 3FQBSBDJOEFSFQVFTUPTSFQBSBCMFTSFQBSBDJOEFMPTSFQVFTUPTZ
gestin de los reparables con el fabricante original de los equipos
(Original Equipment Manufacturer - OEM por sus siglas en ingls).
t &OWBTF FNCBMBKF BMNBDFOBNJFOUPZUSBOTQPSUF
t 4UPDLZHFTUJOEFBMNBDFOFT
iii. La gestin de obsolescencias consiste en el conjunto de actividades y
tareas necesarias para minimizar el impacto de la falta de suministro o
apoyo causados por la obsolescencia del material. Esta gestin se realiza mediante la identificacin, cuantificacin y resolucin de las
obsolescencias con una relacin coste-eficacia ptima. La gestin
de obsolescencias se centra en una amplia aplicacin sistmica de
la gestin de riesgos y es aplicable a todo el ciclo de vida del sistema,
siendo parte integral de las fases de diseo, desarrollo, produccin y
operacin.
iv. El refresco de tecnologa se define como el reemplazo continuo de
elementos de un sistema, en especial los COTS, para asegurar una
eficaz y eficiente sostenibilidad del sistema durante su vida operativa.
La figura 18.4 refleja los diferentes tipos de refresco de tecnologa
considerados.
v. El objetivo de las actividades de clculo de coste de vida del sistema
es refinar y actualizar su estimacin mediante la utilizacin de costes
histricos con objeto de proporcionar una estimacin ms fiable de
los futuros gastos asociados a la operacin y apoyo as como estimar
los costes de la retirada del servicio sistema. Adicionalmente permitir valorar los costes de las actividades a efectuar como resultado
de una modificacin o de cambios planificados en las actividades de
apoyo al sistema.
431
Figura 18.4. Tipos de refresco de tecnologa.
b) Ingeniera
i. La autoridad de diseo del sistema es la responsable de garantizar
la integridad tcnica del diseo del producto o sistema mediante la
validacin de los cambios a la configuracin, el mantenimiento y la
documentacin. La autoridad de diseo proporciona consejo tcnico,
investigaciones de ingeniera, evaluacin tcnica de la necesidad de
los cambios, gestin de la lnea base del diseo, certificacin y apoyo a la gestin de la seguridad. Una de sus principales tareas es la
gestin del cambio que comprende el conjunto de actividades que
comienza con la evaluacin tcnica de la necesidad de un cambio
(cualquier peticin de estudio de un cambio, para asegurar que est
alineada y es consistente con el diseo del sistema) y contina con
las tareas de ingeniera asociadas al cambio.
ii. Otra de las tareas importantes es el anlisis de fallos y las acciones correctoras correspondientes. Para llevar a cabo esta actividad
se necesita el establecimiento de una metodologa sistematizada de
recoleccin de datos de uso y fallo, gestin de los mismos, anlisis e
implementacin de acciones correctivas.
432
iii. Las actividades relacionadas con la seguridad consisten en el mantenimiento del safety case del sistema durante su vida operativa,
incorporando todos los elementos relevantes para la seguridad del
mismo como consecuencia de los cambios introducidos en la operacin y/o configuracin del sistema. La gestin de la certificacin
consiste en el mantenimiento de las bases de certificacin y en la
gestin del proceso de verificacin de la certificacin que asegure
que se mantiene la integridad tcnica del sistema.
c) Modernizaciones
Las modernizaciones comprenden las acciones a que se somete el material (normalmente a mediados de su vida operativa) para mejorar su rendimiento operativo, su fiabilidad y su mantenibilidad. Esta mejora incluye
la implementacin de cambios que consiste en la incorporacin al sistema
de aquellas modificaciones que han sido aprobadas por un comit que
controla los cambios, la actualizacin de la configuracin, la verificacin de
su correcto funcionamiento y la actualizacin del estado de certificacin y
seguridad del sistema.
d) Mantenimiento
Existen diferentes tipos de mantenimiento que van desde inmovilizaciones de gran duracin, en las que se realizan acciones de mantenimiento
de todos los tipos, cuya entidad y magnitud requieren una gran necesidad
de recursos, hasta reparaciones incidentales, mtodo que nicamente incluye el mantenimiento correctivo de sistemas vitales para la seguridad y
para establecer el rendimiento operativo por encima del grado de eficacia
operativo. A continuacin se explican algunos tipos de mantenimiento ms
especficos:
i. Rehabilitacin progresiva: consiste en el reemplazo programado de
equipos y componentes cuyo desgaste se pueda detectar antes de
que llegue a producirse la avera, procediendo a su rehabilitacin.
ii. Mantenimiento en uso: es el mantenimiento bsico de un equipo
realizado por los usuarios del mismo. Consiste en una serie de tareas elementales (tomas de datos, inspecciones visuales, limpieza,
lubricacin, reapriete de tornillos) para las que no es necesario una
gran formacin, sino tan solo un entrenamiento breve. Este tipo de
mantenimiento es la base del Mantenimiento Productivo Total (TPM
por sus siglas en ingls).
iii. Asistencia in situ: los grupos mviles de apoyo son grupos de expertos asignados para la investigacin y/o resolucin de problemas
433
tcnicos detectados por el usuario del activo/sistema. Estos expertos

se desplazan puntualmente al lugar en el que se encuentra el sistema
para proporcionar su asistencia tcnica in situ al cliente.
iv. Mantenimiento por sntomas: La ejecucin de este mtodo se basa en
la observacin de los parmetros fundamentales de funcionamiento
de los sistemas y equipos. Aqu el mantenimiento se realiza cuando
se detecta una alteracin fuera de lo establecido de una de las variables monitorizadas. Para realizar este tipo de mantenimiento se necesita la instalacin de un sistema de supervisin y diagnostico de estas
variables fsicas indicativas de su estado o condicin. Este proceso
tiene como objetivo final la reduccin de los costes de mantenimiento mediante tres vas complementarias:
t 1SPQPSDJPOBOEP BTJTUFODJB UDOJDB SFNPUB B MPT VTVBSJPT TF FMJmina la necesidad de disponer de expertos cualificados in situ,
concentrndolos en un nico centro que dar soporte a diferentes
productos.
t &MJNJOBOEPBWFSBTDBUBTUSGJDBTRVFTPOBMUBNFOUFDPTUPTBTUBOto en costes materiales como los derivados de inmovilizaciones
largas no deseadas de los productos. Esto se consigue mediante
la adecuada supervisin del estado de salud de los equipos y
sistemas.
t 0QUJNJ[BOEPFMQMBOEFNBOUFOJNJFOUP-PTQSPEVDUPTPTJTUFNBT
se utilizan en la vida real con perfiles de operacin que difieren de
los tericos utilizados en el desarrollo del plan de mantenimiento.
Por ello, mediante la monitorizacin del uso y estado de los equipos, el sistema podr adecuar la periodicidad y conveniencia de
efectuar tareas de mantenimiento de forma que se optimicen los
recursos de mantenimiento sin afectar a la disponibilidad y operatividad de los productos o sistemas.
e) Adiestramiento
El adiestramiento es la adquisicin de conocimiento, capacidades y habilidades prcticas y tcnicas de forma que se asegure la operacin y el
mantenimiento del producto o sistema. Los servicios proporcionados son:
t 'PSNBDJO USBEJDJPOBM FO DMBTF
MFDDJPOFT EF BEJFTUSBNJFOUP QPS
profesores en las instalaciones del fabricante o cliente.
t "EJFTUSBNJFOUPFOFMQVFTUPEFUSBCBKP 0O5IF+PC5SBJOJOH0+5
por sus siglas en ingls): formacin que tiene lugar durante la jornada
de trabajo usando equipos reales.
434
t "EJFTUSBNJFOUPCBTBEPFOPSEFOBEPS $PNQVUFS#BTFE5SBJOJOH$#5
por sus siglas en ingls): cursos de formacin interactivos y multimedia.
t 4JNVMBEPSFTDVSTPTEFGPSNBDJODPOTJNVMBEPSFTFODBTUSBEPTFOMPT
sistemas tcticos o con simuladores dedicados.
3.2. Recursos
Los recursos son los activos necesarios para proporcionar las actividades o
servicios de ACV. En este caso consisten en personas con sus conocimientos,
habilidades, experiencia; en tecnolgicos como la propiedad intelectual y la
capacidad tcnica; y en activos fsicos materiales, herramientas e instalaciones.
Los recursos por si mismos no generan ventaja competitiva deben unirse
y organizarse para crear la capacidad de dar un servicio o un producto. La
organizacin que es clave en estos proyectos necesita ser flexible y adaptable para satisfacer las caractersticas inherentes de imprevisibilidad y rapidez
requerida de algunos de los servicios de ACV.
Uno de los rasgos diferenciadores de estos proyectos es la fuerte vinculacin con el cliente lo que implica que la gestin de las diferentes culturas
tanto sociales como de empresa sea un factor clave en la consecucin de los
objetivos.
La gestin de la cadena de suministro de los recursos en un proyecto de
ACV tiene dos elementos esenciales que la hacen diferente de la de un proyecto industrial convencional: el repuesto y el personal que realiza el trabajo.
En la tabla 18.1 [Cohen et al., 2006] se muestran las principales diferencias:
Demanda
Cadena de suministro
industrial
Previsible
Recursos gestionados
Equipos, piezas
Tiempo de respuesta
Programado
Unidades en stock
Limitadas
Objetivo de la gestin del

inventario
Maximizar la agilidad de
los recursos.
Logstica Inversa
No aplica
Mtrica
Tasa de suministro
Parmetro
Cadena de suministro
de servicios de ACV
Imprevisible
Personal, equipos,
herramientas,
Urgente
Indefinida, se analiza
estadsticamente
Ubicar los recursos con
antelacin.
Se encarga de devolver,
reparar, y deshacerse de
piezas
Disponibilidad del producto
Tabla 18.1. Diferencias cadena de suministro industrial

y cadena de suministro de servicios de ACV.
435
3.3. Cooperaciones con socios

Las cooperaciones son un vehculo para que las empresas puedan mantener y mejorar su competitividad. Desde el punto de vista de los servicios
de ACV las colaboraciones con la industria local del lugar donde es usado
el activo y las cooperaciones estratgicas para ofrecer soluciones integrales
son claves para competir. La figura 18.5 muestra el proceso para la puesta
en marcha de una cooperacin.
Figura 18.5. Proceso de seleccin de una cooperacin

[Schann, Tanganelly, 2012]
a) Las motivaciones estratgicas son dos: la primera consiste en aumentar las capacidades y recursos para suministrar una solucin integral
que responda a las necesidades del cliente y la segunda se centra en
reducir costes.
b) La eleccin del socio es crtica; hay que intentar que se complementen las fortalezas y disminuyan las debilidades. Hay que buscar la
adaptabilidad de las culturas sobre todo cuando las empresas son de
diferentes pases. Es tambin crtico sin menoscabo de la confianza
realizar una investigacin previa del socio potencial.
c) Una vez seleccionado el socio se tiene que analizar que forma organizativa se quiere darle a la cooperacin. Normalmente en proyectos
de ACV la empresa quiere conservar su identidad, su independencia
jurdica y su autonoma estratgica aunque con una prdida de poder
derivado de la coordinacin de las actividades conjuntas. En el captulo 5 se habla de los tipos de asociaciones o alianzas.
d) Las claves para la formalizacin del acuerdo son dos: la confianza y el
concepto t ganas-yo gano. El resultado del proceso de negociacin es
la formalizacin del acuerdo de cooperacin y supone la solucin negociada para la puesta en marcha de la cooperacin. Los puntos a considerar en este tipo de acuerdo son: los intereses de los socios, los objetivos
y duracin de la colaboracin; la contribucin o alcance de trabajo de
cada socio y el reparto de resultados ya sean ganancias o prdidas.
e) Para garantizar el xito de la cooperacin debe realizarse una adecuada ejecucin, es decir, deben de marcarse los objetivos estratgicos,
definir bien los trabajos a realizar, llevar la cuenta (indicadores) y esta-
436
blecer una rendicin de cuentas regular. Cuando se tengan problemas,

ser transparentes y francos entre las partes y reevaluar si la cooperacin sigue siendo estratgica es clave para la resolucin del conflicto.
4. TIPOS DE CONTRATACIN
Los proyectos de ACV pueden funcionar bajo varios modelos: en funcin de lo que el cliente quiera, del producto y del ciclo de vida del producto. Hay clientes que quieren pagar por cada vez que utilicen un servicio
y otros que ponen en mano del contratista el producto para olvidarse del
mantenimiento y ellos centrarse en la operacin. Incluso hay clientes que
quieren slo la utilidad del activo pero que ni siquiera quieren ser los propietarios de dicho activo perteneciendo este al contratista. En la tabla 18.2
se muestran diferentes modelos de negocio para los servicios de ACV.
Contrato
Tipo de
ingreso
Nivel de
externalizacin
Caracterstica
Dueo del
activo
Ejemplo
A Necesidad Variable segn

tarifas
Muy Bajo
Se contrata soporte
tcnico y repuestos
por separado y segn
necesidad.
Cliente
Servicio
postventa de
electrodomsticos
Basado en
costes
De precio a
tanto alzado.
precio fijo
Bajo
La industria es
Cliente
responsable de
reparar el producto o
sistema incluyendo los
repuestos necesarios.
Mto. de vehculos
Basado en
coste
Coste + un
margen fijo
Bajo
La industria es
Cliente
responsable de
Ver punto 4.1
Basado en
coste
Precio mximo
con incentivos.
Coste +
beneficio + un
incentivo
Bajo
La industria es
Cliente
responsable de
Ver punto 4.1
Basado en
resultados
Precio basado
en resultados
Muy alto
La Industria es la
responsable de que
el producto o servicio
este listo para su uso.
Cliente
Ver punto 4.2
Suministro
de
capacidades
Alquiler
Total
La industria es la
responsable de
la operacin del
sistema o producto.
Incluso el propietario
es la empresa que
suministra el activo.
Suministrador Ver punto 4.3

del servicio
Tabla 18.2. Modelos de negocio de ACV.
437
Tal y como hemos comentado la eleccin del modelo de negocio depender de la naturaleza del producto y del ciclo de vida del producto por
ejemplo, cuando el activo es un sistema complejo y es complicado conocer
los fallos del sistema, las empresas no quieren arriesgarse a un contrato
basado en prestaciones si no que prefieren uno a coste fijo ms incentivos en funcin del rendimiento. Cuando ya se tienen los suficientes datos
sobre los costes de mantenimiento se puede elegir un contrato basado en
resultados.
La figura 18.7 muestra la evolucin actual de contratacin de los servicios de ACV desde la contratacin basada en recursos a la propuesta de que
el propio contratista es el dueo del bien.
4.1. Basado en costes
En estos tipos de contratacin la industria es responsable de reparar el
producto o sistema incluyendo los repuestos necesarios. Tenemos bsicamente tres tipo de contratacin:
t %FQSFDJPBUBOUPBM[BEPFOFTUFTJTUFNBMBEJSFDDJOEFQSPZFDUPT
corresponder al rgano de contratacin y la responsabilidad tcnica
y de ejecucin a la empresa. Son aplicables cuando el proyecto esta
suficientemente definido y valorado.
t $PTUF VO NBSHFO GJKP FO FTUF TJTUFNB MB EJSFDDJO EF QSPZFDUPT
corresponder al rgano de contratacin y la responsabilidad tcnica y de ejecucin a la empresa. El rgano de contratacin asume la
totalidad de los costes incurridos admisibles. Este sistema necesita
un control muy exhaustivo de los gastos por parte de la empresa
que deber pasar auditorias de costes peridicamente. Este sistema
es aplicable cuando el proyecto no esta ni suficientemente definido
ni valorado. Es un sistema no muy habitual pues el cliente necesita
muchos recursos para auditar el proyecto.
t 1SFDJPNYJNPDPOJODFOUJWPTFOFTUFTJTUFNBFMQSPZFDUP TVEFTBrrollo y la responsabilidad tcnica y de ejecucin es exclusiva de la
empresa. Se establecer un precio mximo y el importe que recibir
el contratista estar constituido por los costes incurridos admisibles
ms los beneficios e incentivos que se acuerden. El precio mximo
estar limitado al acordado. Para este caso la definicin del proyecto
estar suficientemente definido.
438
Figura 18.7. Evolucin de la forma de contratacin de ACV.
439
4.2. Contratar resultados

El objetivo de los Contratos Basados en Prestaciones (Performance Based
Logistic, PBL por sus siglas en ingls) es mejorar la relacin eficacia/coste
y que el cliente concentre sus esfuerzos en la utilizacin de los sistemas. El
cliente traspasa al contratista la responsabilidad de mantener operativos los
sistemas. La retribucin a los contratistas se realizara segn los resultados
obtenidos y no por los recursos dedicados. Los contratos PBL requieren por
un lado un conocimiento detallado del estado de los sistemas, que no siempre se tiene, y por otro requieren de suficiente confianza por ambas partes
ante un modelo radicalmente diferente de externalizar el apoyo.
Los inicios de este modelo de contratacin PBL surgen en los aos 90
cuando la International Society of Logistics (SOLE) estableci las bases de la
sostenibilidad basada en la utilidad (Performance Based Supportability, PBS).
Se denomin as al considerarse a la sostenibilidad un elemento crtico en
las prestaciones de los sistemas. El objetivo era organizar las mejores prcticas de la industria de forma sistemtica y eficaz para facilitar su aplicacin
a programas y productos militares y civiles. Las razones que llevaron a ese
cambio de paradigma en la externalizacin del apoyo logstico fueron fundamentalmente la complejidad de los sistemas y el descontento con la relacin
efectividad/coste. La externalizacin del apoyo logstico segn la filosofa PBL
[Sols, Nowick, Verma, 2007] puede realizarse en tres distintas dimensiones: la
dimensin sistema (la externalizacin puede abarcar al sistema completo, a
algn subsistema, o a algn componente relevante); la dimensin elementos
de apoyo logstico (segn incluya uno, varios o todos los elementos de apoyo); y la dimensin responsabilidad (segn el nivel de responsabilidad en la
toma de decisiones transferido del usuario al contratista).
A pesar de las ventajas de la estrategia de externalizacin PBL tanto para
usuarios como para contratistas, recogidas por numerosas fuentes, la adopcin de PBL como filosofa preferida de externalizacin del apoyo logstico
presenta importantes barreras. Ser consciente de qu tipo de dificultades se
presentarn a la hora de adoptar la filosofa PBL para externalizar el apoyo
logstico a un sistema ayudar a afrontarlas de manera proactiva, minimizando el riesgo de que tengan un impacto negativo en el desarrollo de la
externalizacin.
PBL es el concepto de soporte basado en resultados que planifica y suministra un paquete de prestaciones integrado y asequible diseado para
optimizar el alistamiento de los sistemas y cumplir los objetivos de dichas
prestaciones a travs de acuerdos a largo plazo con unas lneas claras de
autoridad y responsabilidad. El paso de contratar recursos a contratar resultados no puede ni debe hacerse de manera inmediata. Se recomienda
que se establezcan contratos de transicin con los que se puede llegar a
440
objetivar el estado real del sistema al tiempo que se pueda poner en marcha
un sistema de medicin de las prestaciones, que permitan tanto al usuario
como al contratista adquirir visibilidad de las condiciones reales de operatividad del sistema y confianza en la nueva manera de trabajar. La experiencia demuestra que esos contratos de transicin, en los que normalmente la
parte a riesgo se mide desde el principio pero a efectos de determinacin
de la retribucin se va aplicando gradualmente durante la duracin del
contrato hasta llegar a la totalidad, son muy tiles adems de para reducir
la incertidumbre, para identificar y sortear las barreras que se presentan en
la implementacin de contratos PBL.
Todo cliente busca que su producto en su fase de utilizacin tenga unos
adecuados niveles de disponibilidad y fiabilidad operativa, minimizando la
huella logstica y el tiempo de respuesta, y al menor coste de ciclo de vida
posible. En las adquisiciones de productos complejos y de largos periodos de adquisicin una de las soluciones que se estn llevando a cabo es
externalizar el apoyo logstico con retribuciones ligadas a las prestaciones
alcanzadas por los sistemas. Para ello el cliente, para facilitar la gestin del
soporte al producto durante su ciclo de vida intenta unir las comunidades
que gestionan la adquisicin y el sostenimiento. Se asigna al jefe de proyecto el rol de Gestor del Ciclo de Vida Total del Producto (TLCSM por sus
siglas en ingls) con responsabilidades no solo durante la adquisicin sino
tambin en la planificacin, implementacin y gestin del sostenimiento
de los sistemas durante su ciclo de vida (from the concept to disposal).
Este cambio consiste en establecer la gestin total del ciclo de vida de los
sistemas de manera que se amplen las responsabilidades de los jefes de
programa hacia la fase de soporte o bien se establezca un periodo y unos
procedimientos de transferencia de informacin y conocimientos a los responsables de esta fase. Asimismo, justo antes del comienzo de la fase de
entrada en servicio del sistema, se creara una Revisin de los Requisitos de
Sostenimiento (RRS) como transicin entre la adquisicin y el sostenimiento. Esta revisin debe abordar los temas siguientes:
t &WBMVBSMBTQSFTUBDJPOFTEFMTJTUFNBDPOGSPOUOEPMBTDPOMPTSFRVJsitos operativos y de sostenimiento, particularmente los relativos a
parmetros de prestaciones clave del sostenimiento y atributos claves
del sistema.
t &TUBCMFDFSMPTSFRVJTJUPTEFMPTBDVFSEPTCBTBEPTFOQSFTUBDJPOFT
t 3FDPNFOEBSNFKPSBTFOFMTJTUFNBRVFJODSFNFOUFOMBTDBQBDJEBEFT
mejoras en las mtricas de sostenimiento, etc.
t 1MBOJGJDBSMBFWPMVDJOEFMBTFTUSBUFHJBTEFMTPTUFOJNJFOUP
Este cambio propuesto en la gestin de los programas viene resumido
en la figura 18.8.
441
Figura 18.8. Gestin Total del Ciclo de Vida.
442
El responsable de ACV es el encargado de asegurar que los requisitos de ACV son tenidos en consideracin desde las primeras etapas del
diseo, influir en el diseo del producto para mejorar la sostenibilidad
del mismo, disear el sistema de apoyo del activo y preparar junto con
el jefe de proyecto la Revisin de Requisitos de Sostenimiento (RSS). El
Responsable de ACV pasa a ser el jefe de proyecto de ACV durante la fase
de servicio.
4.3. Contratar capacidades
Si se piensa en una formulacin clsica de un negocio con una cadena
de actividades que aaden valor al producto [Porter, 1986], el servicio solo
aparece al final del proceso justo antes de llegar al cliente (instalacin,
pruebas y garanta), y si vamos un poco ms all se incluye el mantenimiento del producto para que funcione correctamente. Pero est claro que el
foco de la cadena de valor es el producto. Este modelo de negocio se fija en
el efecto que el producto genera. Ted Levitt uno de los gurs del marketing
pone un ejemplo muy sencillo: lo que los clientes no quieren es comprar un
taladro en s; lo que quieren es el agujero que pueden hacer con el taladro
[Chesbrough, 2011]. Este enfoque del negocio basado en la utilidad del producto nos conduce a una tipo de prestacin de servicios de ACV totalmente
nuevo, el cliente contrata capacidades, contrata la utilidad del bien.
La propuesta de valor de este modelo es que cliente convierte un
activo fijo en un gasto variable ms pequeo. Por ejemplo, el clsico
negocio de alquiler de coche el activo fijo, el coche, se convierte en un
gasto variable por un servicio de transporte. La propuesta de valor para
el cliente es evidente: flexibilidad y reducir su inversin inicial de capital,
para el contratista o suministrador de servicio el retorno de la inversin
vendr dada por una mejor utilizacin del activo, buscarle nuevos usos al
activo bien en nuevos mercados bien rediseando el producto para ofrecer ms servicios. Un ejemplo tpico de la cadena de valor de Porter es
la fabricacin de un automvil con su logstica de entrada, su proceso de
produccin, su logstica de salida y su distribucin y marketing. El cliente
adquiere el auto en el concesionario y una vez el coche esta en propiedad
del cliente este le lleva al taller cuanto tiene una avera o peridicamente
si le toca un mantenimiento programado. El ncleo del negocio es el coche y la ventaja competitiva viene de un mejor coche o de un coche ms
barato. Si se pone el foco en la utilidad del coche el cliente usa el servicio
de transporte y el contratista cobra un precio fijo por un tiempo de utilizacin del activo siendo este ltimo el encargado del mantenimiento del
coche. Para el cliente el coche pasa de un activo fijo a un gasto variable
en funcin de su uso.
443
En este modelo de negocio se produce lo que Mikel Cusumano ha llamado servitizacin [Hopkins, 2011] que tiene lugar cuando las cosas que
solamos llamar productos se transforman en servicios y est relacionada
con los diferentes modelos que se crean para ofrecer servicios y monetizarlos. Un ejemplo de este concepto es el modelo de negocio de General
Electric (GE) [Chesbrough, 2011] y sus motores de aviacin. GE paso de
vender las turbinas a las compaas reas a arrendarlas por horas de vuelo
durante toda la vida del avin con el compromiso de enviar a los tcnicos
y reparar la maquina en menos de 24 horas en el mismo lugar, sin trasladar
la aeronave al hangar, pues esto representaba una prdida de ingresos tanto
para GE como para sus clientes, este es el punto en donde los intereses de
ambos convergen. Bsicamente GE transit de un modelo de negocios basado en producto a uno basado en servicio, lo que result ms estable, 30
aos garantizados de ingresos, es una forma distinta de pensar.
5. REFERENCIAS
COHEN, M., AGRAWAL, N., AGRAWAL, V., Ganar en el mercado postventa, Harward
Deusto Business Review, junio, 2006.
CHESBROUGH, H., Innovacin de servicios abiertos, Plataforma, 2011.
DRUCKER, P., Management: Tasks, Responabilities, Practices, Butterworth-Heinemann,
1999.
HOPKINS, M. S., Entrevista a M. A. Cusumano, Los directivos deben preguntarse
cules son las potenciales mega tendencias que podran alterar su negocio en el
futuro, Harward Deusto Business Review, octubre, 2011.
KAPLETIA, D., PROBERT, D. Migrating from products to solutions: An exploration of
system support in the UK, Industrial Marketing Management, 2009.
SCHAAN, J., KELLY, M., TANGANELLI, D., Gestin de alianzas estratgicas, Pirmide, 2012.
SOLS, A., NOWICK, D., VERMA, D., Defining the fundamental framework of an effective Performance Based Logistics (PBL) Contract, Engineering Management
Journal, June, 2007.
444
BIBLIOGRAFA
ADIZES, I., Corporate Lifecycles: How and Why Corporations Grow and Die and
What To Do About It. Englewood Cliffs, NJ: Prentice Hall, 361 pp. (1988).
AMENDOLA, L., Gestin de proyectos de activos industriales, Universidad Politcnica
de Valencia, 2003.
AMUNDSEN, R. and CHATER, A. G., The South Pole: 1910-1912, Digireads (Kindle
Edition), 2004.
AJENJO, A. D., Direccin y Gestin de Proyectos. Un enfoque prctico.
ALEXANDER, I. and STEVENS, R., Writing better requirements.
AZUA, S., Dinmicas de gestin orientadas a las personas. Inmobasque, 2012.
BAEYER, H. C., The Fermi Solution, Dover Publications Inc., 1993.
BLANCHARD, B., System Engineering Management, John Wiley & Sons, 1991.
BLANCHARD, B., Supply chain management best practices, John Wiley & Son, 2010.
BLANCO, A., Formulacin y evaluacin de proyectos, Edisofer S. L., 2011.
BURT, D.; DOBLER, D. and STAERLING, S., World class supply management. The key
to supply chain management. McGraw-Hill, 2003.
CAGLE, R., Blueprint for Project Recovery, AMACON.
CHESBROUGH, H., Innovacin de servicios abiertos, Ed. Plataforma, 2011.
CHINCHILLA, N. y MORAGAS, N., Dueos de nuestro destino. Cmo conciliar la vida
profesional, familiar y personal. Ariel, 2007.
CHOPRA, S. and MEINDL, P., Supply chain management: strategy, planning and operation, Prentice Hall, Upper Saddle River, NJ, 2001.
CLARK, W., The Gantt Chart, a Working Tool of Management, The Ronald Press
Company, 1922.
COSTA, M.; GALEOTE, M. P. y SEGURA, M., Negociar para con-vencer, McGraw-Hill,
Madrid, 2004.
COHEN, M.; AGRAWAL, N.; AGRAWAL, V., Ganar en el mercado postventa, Harward
Deusto Business Review, junio, 2006.
445
COYLE, J.; BARDI, E. and LANGLEY, C. J., The management of business logistics: a
supply chain perspective, 7th Eddition, Thomson South-Western, 2003.
CLEVELAND, D. and GAREIS, R., Global Project Managemen Handbook; Planning,
Organizing and Controlling International Projects, Ed. McGraw-Hill.
CUSUMANO, M. A., Enterprise 2: the dawn of emergent collabotation, MIT Sloan Management.
DE MANUEL, J. y MARTNEZ-VILANOVA, R., Tcnicas de negociacin, ESIC Editorial,
Madrid, 2009.
DE URBINA, J. A., El gran libro del protocolo, Temas de Hoy, S. A., Madrid, 2001.
DOW, W. and TAYLOR, B., Project management communication bible. Indianapolis,
Indianapolis, EE.UU.: Wiley Publishing, Inc., 2008.
DRUCKER, P., The Essential Drucker, Harper Business, 2001.
DVIR, D.; LIPOVETSKY, S.; SHENHAR, A. and TISHLER, A., In search of project classification - a non-universal approach to project success factors. Research Policy
27 (1998), pp. 915-935.
ESCOLA, R. y MURILLO, J. I., tica para ingenieros, Ediciones Universidad de Navarra,
S. A., 2004.
FABOZZ, F. and NAHLIK, C., Project Financing, Ed. Euromoney.
FAIRLEY, R. E. and WILLSHIRE, M. J., Why the Vasa Sank, IEEE Software, ISSN 07407459, 2003, Volume 20, Issue 2.
FESTINGER, L., Theory of Cognitive Dissonance, Stanford University Press, June, 1957.
FONTRODONA, J., GUILLN, M. y RODRGUEZ, A., La tica que necesita la empresa,
Unin Editorial, Madrid, 1998.
FORRESTER, J., Industrial Dynamics, MIT Press, 1961.
GARCA, B. R. y GALLARDO, K., El outsourcing como ventaja competitiva: el impacto
de la subcontratacin en la flexibilidad y los costos, Editorial Acadmica Espaola, 2011.
GATTORNA, J. L. and WALTERS, D. W. Managing the supply chain: a strategic perspective, Basingstocke, McMillan, 2001.
GOI, J. L., tica empresarial y cdigos de conducta. La Ley - Actualidad, 2011.
GOLEMAN, D., Inteligencia emocional, Ed. Kairs.
GOODPASTURE, J., Quantitative Methods in Project Management, J. Ross Publishing
2004.
HASS, A. M. J., Configuration Management Principles and Practice, Editorial Addison-Wesley, 2003.
HANS-HENRICH, A., Commercial Aircraft Projects: Managing the development of
highly complex products, Ed. Ashgate.
HAUGAN, G., Project Planning and Scheduling, Management Concepts Inc., 2002.
HARVARD BUSINESS SCHOOL PUBLISHING CORPORATION, Managing up. Pocket Mentor
Series, Boston, Massachusetts, EE.UU.: Harvard Business School Press, 2008.
HEERKENS, G. R., Gestin de proyectos, Ed. McGraw-Hill.
HIRSH, E., HIRSH, K. W. and HIRSH, S. K., Introduction to Type and Teams. 2nd Edition, Mountain View, California, EE.UU.: CPP, Inc., 2003.
KAPLETIA, D. and PROBERT, D., Migrating from products to solutions: An exploration
of system support in the UK, Industrial Marketing Management, 2009.
446
BIBLIOGRAFA
KERZNER, H., Project management: A systems approach to planning scheduling and

controlling.
KLASTORIN, T., Project Management: Tools and Trade-Offs, Profit Editorial I, 2010.
KLIERN, R. L., Effective communications for project management, Boca Raton, Florida, EE.UU.: Auerbach Publications, Taylor & Francis Group LLC, 2007.
LOWNEY, C., El liderazgo al estilo de los Jesuitas, Ediciones Granica, Barcelona, 2005.
LUKAS, J. A., Earned Value Analysis-Why it Doesnt Work, PECCE, 2008.
MAXWELL, J. C., The 21 irrefutable laws of leadership. Workbook, Nashville, Tennesse, EE.UU.: Thomas Nelson, Inc., 2007.
MEREDITH, J. y MANTEL, S., Project Management: A Managerial Approach, John Wiley & Sons, 2009.
MIRANDA, J. J., El desafo de la gerencia de proyectos, MM Editores, 2004.
NAVARRO, F., ResponsabilidaD SOCIAL CORPOrativa. Teora y prctica, ESIC Editorial, 2012.
NEUMANN, J. y MORGENSTERN, O., Theory of Games and Economic Behavior, Princeton University Press, 1944.
NIERENBERG & ROSS, Women and the Art of Negotiating, Barnes & Noble, Inc., United States of America, 1985.
OWEN, J., How to lead. 2nd edition. Harlow, Reino Unido: Pearson Education Limited, 2009.
PREZ, J. L., Polticas orientadas a la direccin de las personas, Universidad de
Deusto, 2009.
PREZ DE HERRASTI y DE GOYENECHE, I., Project Finance: inversin en proyectos
autofinanciados, Ed. Ediciones, 2010.
PREZ DE LOS COBOS, F., Contratacin temporal, empresas de trabajo temporal y subcontratacin en la negociacin colectiva, Ministerio de Asuntos Sociales, 2010.
QUINTS ALONSO, G., El discurso del mtodo de Descartes, Alianza Editorial, 1999.
SAGE, A. P. y WILLIAM, B. R. (eds.), Handbook of Systems Enginering and Management, John Wiley & Sons, 2009.
SAUSER, B. J., REILLY, R. R. & SHENHAR, A. J., Why projects fail How contingency
theory can provide new insights-A comparative analysis of NASAs Mars Climate
Orbiter loss, International Journal of Project Management, vol. 27, n. 7, pp.
665-679.
SCHAAN, J., KELLY, M. y TANGANELLI, D., Gestin de alianzas estratgicas, Ed. Pirmide, 2012.
SHANNON, C. y WEAVER, W. Mathematical Theory of Communication, Illinois University Press, 1949.
SHARON, A., DE WECK, O. L. y DVIR, D., Project Management vs. Systems Engineering Management: A Practitioners View on Integrating the Project and Product
Domains, Systems Engineering, Vol. 14, No. 4, 2011, pp. 427-440.
SHENHAR, A.; DVIR, D.; LEVY, O. y MALTZ, A. C., Project success - a multidimensional strategic concept, Long Range Planning 34 (2001), pp. 699-725.
SHENHAR, A. y DVIR, D., Reinventing Project Management: the Diamond Approach
to Successful Growth and Innovation, Harvard Business School Press, 2007.
SOMMERVILLE, I. and SAWYER, P., Requirements Engineering: a good practice guide.
447
SOLS, A.; NOWICK, D.; VERMA, D., Defining the fundamental framework of an effective Performance Based Logistics (PBL) Contract, Engineering Management
Journal, June, 2007.
SOLS, A., Fiabilidad, Mantenibilidad, Efectividad. Un enfoque sistmico, Editorial
Universidad Pontificia de Comillas, 2000.
TAYLOR, F. W., The Principles of Scientific Management, 1911.
TINSLEY, R., Advanced Project Financing: Structuring Risks, Ed. Euromoney.
VELASCO A. y SAN EPIFANIO, J. A., Jugar en equipo, Ed. Martnez Roca.
VERZUH, E., The Fast Forward MBA in Project Management, John Wiley & Sons, 2005.
WATTS, F. B., Engineering Documentation Control Handbook. Third Edition, Editorial William Andrew, 2008.
WISNER J. D., KEONG, G. and TAN, K.-C., Principles of supply chain management: a
balance approach, Thomson South-Western, 2005.
448
NDICE TEMTICO
Acta de recepcin, 411

Agencias de contratacin, 397, 398
Alcance del proyecto, 39-59
Alianzas, 120-122, 232
Apoyo al Ciclo de Vida, 37, 317, 425-444
Arbitraje internacional, 381
Arbitraje, (conflicto), 234, 238
Auditoras de la configuracin, 317, 325, 332, 336
Auditoras externas, 411
Banco Agente, 192
Barreras tcnicas, 375
Cadena de suministro, 112, 114-124, 303, 375, 426, 431, 435
Camino crtico, 69
Cash Flow o Flujo de Caja, 141, 162, 166, 191, 193
Ciclo de vida, 28, 39, 50, 135, 137-140, 199, 315-327
Ciclo de vida del proyecto, 41, 198, 135, 138
CMI, Cuadro de Mando Integral, 195, 197, 200-225, 256
Confianza, 119, 254, 261, 268, 274-277
Comunicacin diagonal, 280
Comunicacin formal, 281, 284
Comunicacin horizontal, 280
Comunicacin informa, 280
Comunicacin vertical, 280
Conciliacin de horarios, 96, 100
Conciliacin (conflicto), 238
Conflicto, 221, 233-239, 245, 268, 341, 356, 363, 377
Consorcio empresarial, 394, 398
449
Contrato EPC, 168

Control de la configuracin, 315, 318, 390
Cooperacin industrial, 394, 398
Coste de capital, 150-158
COTS: Commercial Off-The-Shelf., 431
Delegar, 254, 256, 258, 264, 401
Deslocalizado, 15, 387, 390, 401
Descomposicin Estructurada de Costes (CBS, -Cost Breakdow Structure) 136, 416
Descomposicin Estructurada de Tareas (WBS, -Work Breakdow Structure) 40, 43,
52-57, 140, 145, 416
Diagramas CPM, 77
Diagramas de Gantt, 66, 74
Diagramas PERT, 67, 72, 75, 77
Diferencias culturales, 369, 377, 404
Distributiva (negociacin), 223
Due Diligence, 167, 172, 181, 192
Efecto bullwhip, 117
Elemento de la configuracin, 319, 331
Enfoque sistmico, 27
Entorno legal, 375
Entorno poltico, 371
Estilo (negociacin), 217, 222
Estrategia, 87, 198-228, 349-365, 370, 388, 400, 440
tica, 91-108
Factores de xito, 378
Fidelizacin de clientes, 414
Fuentes de financiacin, 136, 159-162
Fuerza mayor, 172, 174
Funcionalidades, 296, 300, 315, 340
Garantas, 186,
Gestin de la configuracin, 57, 313
Gestin del tiempo, 255
Identificacin de la configuracin, 316, 327
Imagen de la empresa, 98, 414
Implicaciones de la clasificacin del proyecto, 292
Imputar, 139
Indicador de Tipos Myers-Briggs (MBTI), 261, 271
Indicador estratgico, 205, 212
Influencia, 102, 263, 275
Informes de gestin, 53, 411
Ingeniera de ACV, 425
Ingeniera de sistemas, 27
Insourcing, 392
Integradora (negociacin), 223
KPI: Key Performance Indicator, 89, 200, 205, 212, 255
450
NDICE TEMTICO
Lecciones aprendidas, 35, 41, 410, 420

Leyes del liderazgo, 263
Lnea-base, 318
Lnea-base funcional, 319
Lnea-base asignada, 322
Lnea-base de diseo, 321
Lnea-base de producto, 322
Mantenimiento, 425, 426, 433
Margen, 136, 140, 172
Mtricas, 81, 345, 441
Moral, 91
Motivacin, 102, 246, 254
Negociacin, 221-238
Ocupacin laboral, 106, 419
Oferta econmica, 137
Pirmide de Maslow, 251, 269
Plan de facturacin, 412
Plan de Gestin del proyecto, 325
Plan de la Gestin de la configuracin del proyecto, 325
Planificacin de la configuracin, 325
Presupuesto de costes, 137
Programa, 24, 305, 387
Project Finance, 161, 165
Pruebas de aceptacin, 411
Ratio de cobertura del servicio de la deuda (RCSD), 187
Recuperacin, 339
Recursos humanos, 353, 384
Refresco de Tecnologa, 431, 432
Registro de la configuracin, 317, 334
Rentabilidad, 136, 151, 171, 414
Requisitos, 47
Responsabilidad Social Corporativa, 103
Riesgo, 15, 77, 168, 340, 399
Riesgos de tipo de cambio, 79, 172
Riesgos jurdicos, 380, 382
Riesgos polticos, 179, 383
Severidad del riesgo, 84
Sntomas, 342
Sistemas de clasificacin de proyectos, 289
SPV, Special Purpose Vehicle, 167, 172-174, 181, 193
Stakeholders, 45
Subcontratacin, 111, 124-132
Tctica, 253
Tcnica (negociacin), 227-229
Term Sheet, 190
451
TIR- Tasa Interna de Retorno, 154

VAN-Valor Actual Neto, 153
Valor futuro, 143
Valor Ganado, 144
Valor presente, 143
Verificacin de la configuracin, 336
Visin, 93, 263, 273
Visin de conjunto, 31
Workshare, 396
452

La Gestiã N Integral de Proyectos

Transféré par

Informations du document

Titre original

Copyright

Formats disponibles

Partager ce document

Partager ou intégrer le document

Options de partage

Avez-vous trouvé ce document utile ?

Ce contenu est-il inapproprié ?

Droits d'auteur :

Formats disponibles

La Gestiã N Integral de Proyectos

Transféré par

Droits d'auteur :

Formats disponibles

LA GESTIN INTEGRAL

ALBERTO SOLS RODRGUEZ-CANDELA,

Servicio de Biblioteca. Universidad Pontificia Comillas de Madrid

Esta editorial es miembro de la Unin de Editoriales Universitarias Espaolas (UNE), lo que

2013 De todos los autores

Reservados todos los derechos. Queda totalmente prohibida la reproduccin total o

PRESENTACIN, Manuel Moreu Munaiz ..........................................................

PRLOGO, Alberto Sols, Isabel Fernndez y Javier Romero ..........................

CAPTULO 1. INTRODUCCIN A LA GESTIN INTEGRAL DE PROYECTOS,

CAPTULO 2. EL ALCANCE DEL PROYECTO, Juan Jos Burgaz Fernndez ............

8. Verificacin del alcance del proyecto ...........................................................

CAPTULO 3. TCNICAS DE PLANIFICACIN DE PROYECTOS, Alberto Sols

CAPTULO 4. TICA PROFESIONAL, Miguel Yaguez Prez .....................................

1. Marco terico ..................................................................................................

CAPTULO 5. RELACIN CON LOS PROVEEDORES Y GESTIN DE

2.1. Qu es la cadena de suministro? De la mejora de los flujos a la

CAPTULO 6. GESTIN FINANCIERA, Isabel Fernndez Fernndez y Alberto

7.2. Fuentes de financiacin de capital .........................................................

CAPTULO 8. SEGUIMIENTO DE PROYECTOS Y CUADRO DE MANDO INTEGRAL,

CAPTULO 9. TCNICAS DE NEGOCIACIN, Vernica Blanco-Traba HernndezCaizares ..............................................................................................................

CAPTULO 10. DIRECCIN Y GESTIN DE EQUIPOS DE TRABAJO, scar Gonzlez

CAPTULO 11. LIDERAZGO Y COMUNICACIN, Alejandro Salado Dez .................

CAPTULO 12. SISTEMAS DE CLASIFICACIN DE PROYECTOS, Alberto Sols

CAPTULO 13. GESTIN DE CAMBIOS Y CONTROL DE LA CONFIGURACIN,

5.4. Registro de la configuracin ...................................................................

CAPTULO 14. RECUPERACIN DE PROYECTOS, Enrique Rodrguez Segura..........

CAPTULO 15. PROYECTOS INTERNACIONALES, Alejandro Molns de la Fuente ...

CAPTULO 16. PROYECTOS MULTINACIONALES, Aurora del Castillo Pinela ...........

CAPTULO 17. CIERRE Y EVALUACIN DE PROYECTOS, Miguel ngel Hernndez

CAPTULO 18. APOYO AL CICLO DE VIDA, Javier Romero Yacobi.........................

NDICE TEMTICO .............................................................................................

Presentar este libro de gestin integral de proyectos es un gran placer

LA GESTIN INTEGRAL DE PROYECTOS

fin, una pltora de conceptos que no es fcil de conocer y administrar. Este

Lo mejor en cualquier aventura, iniciativa o viaje son los compaeros

LA GESTIN INTEGRAL DE PROYECTOS

a los captulos, combinando el mximo rigor acadmico con la necesaria

INTRODUCCIN A LA GESTIN INTEGRAL

LA GESTIN INTEGRAL DE PROYECTOS

El entorno actual es especialmente complejo y demandante, tal y como

Figura 1.1. El entorno actual.

Pocos proyectos comienzan con unos requisitos claros y bien definidos,

INTRODUCCIN A LA GESTIN INTEGRAL DE PROYECTOS

los requisitos a ser alcanzados, la manera de verificar su cumplimiento, y

LA GESTIN INTEGRAL DE PROYECTOS

considerarse un programa, que podra dividirse en los siguientes proyectos:

INTRODUCCIN A LA GESTIN INTEGRAL DE PROYECTOS

Tabla 1.1. Diferencias de gestin de proyectos, programas

La relacin entre los diversos proyectos en los que se descomponga un

LA GESTIN INTEGRAL DE PROYECTOS

Figura 1.2. Programas, proyectos y portfolios o carteras.

2. LA EVOLUCIN DE LA GESTIN DE PROYECTOS

INTRODUCCIN A LA GESTIN INTEGRAL DE PROYECTOS

complementados con los de Frank Gilbreth, ms orientados a la reduccin

3. LA GESTIN INTEGRAL DE PROYECTOS

Figura 1.3. Ingeniera de sistemas.

La ciencia moderna se caracteriza por un nivel de especializacin cada

LA GESTIN INTEGRAL DE PROYECTOS

promotores de la denominada Sociedad para la Investigacin General de

Figura 1.4. Las caractersticas del enfoque sistmico.

a) Capacidad de generar conocimiento. El enfoque sistmico no slo

INTRODUCCIN A LA GESTIN INTEGRAL DE PROYECTOS

LA GESTIN INTEGRAL DE PROYECTOS