00 A Direccion y Gestion de Proyectos II PDF

Dirección y Gestión de Proyectos
Un enfoque práctico
2a Edición
Alberto Domingo Ajenjo Doctor

Ingeniero de Telecomunicación
ÍNDICE
SOBRE EL AUTOR .................................................................................................. XVII
PRÓLOGO ................................................................................................................. XIX
PREFACIO A LA SEGUNDA EDICIÓN .............................................................. XXI
INTRODUCCIÓN ..................................................................................................... XXIII
CAPÍTULO 1. INTRODUCCIÓN A LA DIRECCIÓN Y GESTIÓN DE

PROYECTOS ..................................................................................................... 1
1. I NTRODUCCIÓN ..................................................................................................... 1
1.1 Tipos de proyectos ..................................................................................... 3
1.2 La dimensión técnica, económica, comercial y estratégica de un proyecto.. 6
1.3 Costes, gastos, ingresos, margen y beneficio ........................................... 7
L ECTURA . MAXIMIZACIÓN DE BENEFICIOS EN LA EMPRESA ......................... 9
1.4 El factor riesgo y las contingencias .......................................................... 10
2. LAS FASES DE UN PROYECTO ...........................'..................................................... 11
2.1 Detección de oportunidades ..................................................................... 12
2.2 Preparación de la oferta ........................................................................... 13
2.3 Presentación (o no) y adjudicación (o no) ................................................ 14
2.4 Ejecución de los trabajos .......................................................................... 15
2.5 Cierre (y vuelta a empezar) ....................................................................... 16
3. EL PROYECTO EN LA EMPRESA............................................................................. 17
3.1 Concepto de empresa ................................................................................ 17
3.2 Organización déla empresa ..................................................................... 18
3.3 Vinculación proyecto-empresa ................................................................. 20
VIH DIRECCIÓN Y GESTIÓN DE PROYECTOS
4. GESTIÓN Y DIRECCIÓN .................................................................................. 22

4.1 Dirección, gestión, administración y participación............................... 24
4.2 Gestión estratégica, administrativa y operativa .................................... 26
4.3 El encanto de la gestión ....................................................................... 27
5. CAOS CONSULTING S.A., UNA EMPRESA MODELO ........................................ 29
5.1 Características generales de la empresa .............................................. 29
5.2 Costes laborales ................................................................................... 30
5.3 Costes generales .................................................................................. 32
5.4 Otros costes......................................................................................... 33
5.5 Margen comercial de Caos Consulting ................................................ 33
5.6 Facturación de Caos Consulting .......................................................... 34
LECTURA. EL ARTE DE NEGOCIAR...... '. ............. 34
CAPÍTULO 2. DETECCIÓN DE OPORTUNIDADES ................................... 39
1. INTRODUCCIÓN ................................................................................................................. 39
2. CLIENTE, MERCADO Y PRODUCTO.................................................................. 40
LECTURA, BARRERAS DE ENTRADA Y BARRERAS DE SALIDA ...................... 41
3. PLAN DE NEGOCIO......................................................................................... 42
3.1 Objetivos del plan de negocio............................................................... 43
3.2 Formato de un plan de negocio............................................................ 44
4. OPORTUNIDADES COMERCIALES ................................................................... 46
4.1 Oportunidades "perseguidas".............................................................. 46
4.1.1 El concurso ............................................................................... 47
4.1.2 Información acerca de las necesidades del Cliente..................... 47
4.1.3 Creación de necesidad en el Cliente .......................................... 48
4.1.4 Divulgación y publicidad .......................................................... 48
4.1.5 Ampliación del alcance de un proyecto o trabajo....................... 49
4.1.6 Continuación de trabajos anteriores ........................................... 49
4.2 Oportunidades "noperseguidas"......................................................... 50
5. CONCURSOS .................................................................................................. 50
5.1 Objetivos de un concurso ..................................................................... 53
5.2 Publicidad del concurso ...................................................................... 53
5.3 El Pliego .............................................................................................. 56
5.4 Ventajas y desventajas.......................................................................... 60
5.5 Los concursos y la Administración ....................................................... 61
5.6 Peticiones de información .................................................................... 62
LECTURA. INFLACIÓN YESCALACIÓNDE PRECIOS ........................................... 63
CAPÍTULO 3. EVALUACIÓN DEL PROYECTO.......................................... 71
1. INTRODUCCIÓN ............................................................................................. 71
2. EVALUACIÓN Y DECISIÓN PRELIMINAR ......................................................... 72
ÍNDICE IX
3. ESTIMACIÓN DEL COSTE Y EL PRECIO DEL PROYECTO ..................................... 74

3.1 Análisis del trabajo a realizar .............................................................. 75
3.1.1 Estructura de paquetes de trabajo.............................................. 76
3.1.2 Descripción de los paquetes de trabajo ....................................... 77
3.2 Esfuerzo requerido ............................................................................... 79
LECTURA. RELACIONES DE SUSTITUCIÓN DE PERSONAL .......................... 82
3.3 Otros costes y gastos ............................................................................ 84
3.3.1 Subcon trataciones ..................................................................... 85
3.3.2 Costes varios ............................................................................ 87
LECTURA. ESTRATEGIAS CON PROVEEDORES .......................................... 88
3.4 Presupuesto y precio de venta del proyecto ......................................... 90
LECTURA. EL NÚMERO DE PERSONAS QUE PARTICIPAN EN UN PROYECTO 94
4. PLANIFICACIÓN TEMPORAL DEL PROYECTO .................................................. 96
4.1 Técnicas de planificación .................................................................... 97
4.2 Técnicas PERT. ................................................................................... '. 100
LECTURA. "Am DIOS MÍO " YSUPROGRAMA DE OPTIMIZACIÓN DE VUELOS ... 105
5. PLAN FINANCIERO DEL PROYECTO ................................................................ 109
6. UN EJEMPLO: EL PROYECTO DE FLORES DEL SUR ........................................... 112
6.1 Antecedentes ........................................................................................ 113
6.2 Análisis de los antecedentes ................................................................. 114
6.3 Identificación de las tareas a realizar .................................................. 116
6.4 Estimación de horas y gastos ................................................................ 121
6.5 Planificación temporal y recursos ........................................................ 128
6.6 Plan financiero del proyecto ................................................................. 130
6.7 Recomendación del responsable de la oferta........................................ 132
LECTURA. LAS DIFERENTES FORMAS DE DAR UNPRECIO ......................... 132
CAPÍTULO 4. PREPARACIÓN DE LA OFERTA ......................................... 135
1. INTRODUCCIÓN ............................................................................................. 135

2. OFERTAR, o NO OFERTAR.............................................................................. 136
3. PREPARACIÓN DE LA OFERTA ........................................................................ 138
3.1 Oferta técnica ...................................................................................... 140
3.2 Oferta de gestión .................................................................................. 142
3.3 Oferta económica ................................................................................. 143
4. CURRICULA VITAE Y REFERENCIAS DE LA EMPRESA ........................................ 144
4.1 Curriculum personal, versión larga ..................................................... 145
4.2 Curriculum personal, versión corta ...................................................... 147
4.3 Presentación y referencias de la empresa ............................................ 148
5. PRESENTACIÓN (Y SEGUIMIENTO) DE LA OFERTA .......................................... 150
6. ADJUDICACIÓN (o NO) DEL TRABAJO ............................................................. 153
LECTURA. ESTILO DE COMUNICACIÓN .................................................... 154
X DIRECCIÓN Y GESTIÓN DE PROYECTOS © RA-MA
CAPITULO 5. SEGUIMIENTO DEL PROYECTO ........................................... 159
1. I
NTRODUCCIÓN ..................................................................................................... 159
2. ANTES DE EMPEZAR A TRABAJAR ......................................................................... 159
2.1 Revisión de la oferta y del contrato ......................................................... 160
2.2 Organización y acopio de recursos .......................................................... 161
2.3 Intercambio de información en el proyecto .............................................. 162
3. R EUNIONES .......................................................................................................... 167
3.1 Convocatoria de reunión ........................................................................... 168
3.2 Desarrollo de la reunión ........................................................................... 171
LECTURA, CÓDIGOS DE CONDUCTA ............................................................. 173
3.3 Actas de reunión ........................................................................................ 174
3.4 Resumen de reunión .................................................................................. 177
4. EL DÍA A DÍA DE LA GESTIÓN DEL PROYECTO ..................................................... 179
4.1 Estado de las acciones .............................................................................. 181
4.2 Avance técnico y económico ..................................................................... 183
LECTURA, MÉTODOS DE ANÁLISIS DEL VALOR AÑADIDO ........................... 190
4.3 Informe de situación del proyecto .............................................................. 194
5. CONTROL DE CONFIGURACIÓN ............................................................................. 195
5.1 Gestión de la documentación .................................................................... 196
5.2 Gestión de los productos generados .......................................................... 201
6. CAMBIOS AL ALCANCE DEL PROYECTO ................................................................ 201
6.1 Propuesta motivada .................................................................................. 203
6.2 Análisis y evaluación ................................................................................. 205
6.3 Autorización o rechazo .............................................................................. 205
6.4 Implantación y seguimiento ....................................................................... 206
6.5 Registro de estado de los cambios ............................................................ 207
7. OTRAS ACTIVIDADES ............................................................................................ 208
7.1 Conflictos interpersonales en el proyecto ................................................. 208
7.2 Interfaces del proyecto ............................................................................... 209
7.2.1 Interfaz con el Cliente .................................................................... 210
7.2.2 Interfaz con el equipo de trabajo ................................................... 211
7.2.3 Interfaz con el responsable de la gestión del proyecto .................. 212
7.2.4 Interfaz con la empresa .................................................................. 212
7.3 Decisiones, decisiones, decisiones ............................................................ 213
LECTURA. ASPECTOS LEGALES Y VALOR CONTRACTUAL DE LA
DOCUMENTACIÓN DEL PROYECTO .......................................................... 215
CAPÍTULO 6. CIERRE DEL PROYECTO.......................................................... 219
1. INTRODUCCIÓN .................................................................................................... 219

2. ACEPTACIÓN ........................................................................................................ 220
ÍNDICE XI
3. INFORME DE CIERRE DE PROYECTO ............................................................... 222

3.1 Balance de ingresos y gastos ............................................................... 223
3.2 Resumen de cierre de proyecto ............................................................. 225
3.2.1 Informe económico ................................................................... 225
3.2.2 Informe de situación final ......................................................... 226
3.3 Tratamiento de la documentación generada ......................................... 228
4. INDICADORES OBJETIVOS DEL RESULTADO DEL PROYECTO ............................ 230
4.1 Indicadores económicos de primer orden ............................................. 230
4.2 Indicadores financieros ....................................................................... 232
4.3 Indicadores de ocupación laboral........................................................ 234
4.4 Indicadores de gestión ......................................................................... 236
EPÍLOGO. LA GESTIÓN EN EL TERCER MILENIO ................................. 239
APÉNDICE A. EJEMPLOS DE EVALUACIÓN ECONÓMICA DE

PROYECTOS ............................................................................................. 247
1. INTRODUCCIÓN ............................................................................................ 247

2. UN TRABAJILLO ESTIVAL PARA UNA ESTUDIANTE DE DERECHO..................... 248
2.1 Introducción y antecedentes ................................................................ 248
2.2 Evaluación del trabajo ......................................................................... 248
2.3 Planificación ....................................................................................... 249
2.4 Costes y gastos..................................................................................... 250
2.5 Decisión .............................................................................................. 253
LECTURA. EL EFECTO FISCAL....................................................................... 254
3. PROYECTO DE DESARROLLO Y FABRICACIÓN EN SERIE DE UN NUEVO
PRODUCTO : T HERMO PC ........................................................................................ 255
3.1 Introducción y antecedentes ....................................................................... 255
3.2 El Pliego ....................................................................................................... 255
3.3 Análisis de los antecedentes ........................................................................ 263
3.4 Evaluación del proyecto .............................................................................. 264
3.4.1 Identificación de las tareas a realizar ............................................. 265
3.4.2 Estimación de horas y gastos (I): fase de diseño y desarrollo .... 268
3.4.2 Estimación de horas y gastos (II): fase de fabricación ................. 271
3.5 Decisión ....................................................................................................... 278
4. ANÁLISIS Y EVALUACIÓN DE UN PROYECTO EN CURSO ........................................ 279
4.1 Introducción y antecedentes ....................................................................... 279
4.2 Visión general del proceso de análisis y evaluación ................................ 280
4.3 Obtención de información ........................................................................... 280
4.4 Evaluación del avance y diagnóstico ......................................................... 284
4.5 Conclusiones ................................................................................................ 287
XII DIRECCIÓN Y GKSTION DE PROYECTOS
APÉNDICE B. GESTIÓN DE PROYECTOS DE DESARROLLO DE

SOFTWARE ............................................................................................... 289
1. INTRODUCCIÓN ............................................................................................. 289

2. CICLO DE VIDA DE UN PROYECTO DE DESARROLLO DE SOFTWARE ................ 290
2.1 Fases del ciclo de vida ......................................................................... 291
2.1.1 Fase de análisis y planificación ................................................. 291
LECTURA. ESPECIFICACIÓN DE REQUISITOS DE USUARIO .............................. 296
2.1.2 Fase de desarrollo ..................................................................... 300
2.1.3 Fase de operación y mantenimiento .......................................... 303
2.2 Tipos de ciclo de vida ........................................................................... 304
2.2.1 Modelo en cascada .................................................................... 304
2.2.2 Modelo incrementa! .................................................................. 305
2.2.3 Modelo evolutivo ...................................................................... 307
3. EVALUACIÓN ECONÓMICA ............................................................................ 308
3.1 Participación del equipo de trabajo en cada fase ................................. 310
3.2 Modelos de costes de desarrollo software ............................................ 311
3.3 Coste de los cambios ............................................................................ 314
3.4 Coste de mantenimiento........................................................................ 315
4. CONTROL DE CONFIGURACIÓN ...................................................................... 317
5. RECOMENDACIONES FINALES ....................................................................... 321
APÉNDICE C. CONTENIDO DEL CD-ROM ................................................. 323
1. INTRODUCCIÓN ............................................................................................. 323

2. ESTRUCTURA Y CONTENIDO DEL DISCO ......................................................... 323
ÍNDICE ALFABÉTICO .................................................................................... 327

ÍNDICE DE FIGURAS
CAPITULO 1
FIGURA 1.1 EL PROCESO PROYECTUAL ........................................................................... 3

FIGURA 1.2 PROCESO DE ELABORACIÓN DE UN PROYECTO ........................................ 11
FIGURA 1.3 EJEMPLO DE ORGANIGRAMA ....................................................................... 19
FIGURA 1.4 ORGANIZACIÓN FUNCIONAL....................................................................... 20
FIGURA 1.5 ORGANIZACIÓN PROYECTUAL..................................................................... 21
FIGURA 1.6 ORGANIZACIÓN MATRiciAL ........................................................................ 22
FIGURA 1.7 LA LABOR DEL DIRECTOR DE PROYECTO ................................................. 25
FIGURA 1.8 PIRÁMIDE DE DECISIÓN EN LA EMPRESA ................................................... 27
FIÜURA 1.9 RAZONES PARA DAR EL SALTO A ACTIVIDADES DE DIRECCIÓN Y
GESTIÓN ......................................................................................... 28
FIGURA 1.10 RAZONES PARA NO DAR EL SALTO A ACTIVIDADES DE DIRECCIÓN Y
GESTIÓN............................................................................................................. 28
FIGURA 1.11 ORGANIGRAMA SIMPLIFICADO DE CAOS CONSULTING ........................ .'. 30
CAPÍTULO 2
FIGURA 2.1 PROCEDIMIENTO GENERAL PARA CONVOCAR UN CONCURSO .............. 51
ANUNCIOS DE CONCURSOS PÚBLICOS CONVOCADOS EN
FIGURA 2.2 EL BOLETÍN OFICIAL DEL ESTADO (BOE), A LA
IZQUIERDA, Y EN UN DIARIO DE ÁMBITO NACIONAL,
A LA DERECHA ................................................................................................ 55
FIGURA 2.3 CRITERIOS DE VALORACIÓN Y ADJUDICACIÓN DE UN
CONCURSO PÚBLICO PARA PRESTACIÓN DE ASISTENCIA
TÉCNICA A LA ADMINISTRACIÓN. FUENTE, PLIEGO
FIGURA 2.4 ADMINISTRATIVO .......................................................................................... 57
FUNCIÓN DE ASIGNACIÓN DE PUNTOS A LAS OFERTAS
ECONÓMICAS RECIBIDAS .............................................................................. 59
FIGURA 2.5 EVOLUCIÓN DEL IPC (ÍNDICE GENERAL, MEDIA NACIONAL)
ESPAÑOL, DURANTE LOS
ÚLTIMOS 30 AÑOS (FUENTE, INSTITUTO NACIONAL DE
ESTADÍSTICA).................................................................................................. 64
FIGURA 2.6 FACTORES QUE INTERVIENEN EN EL CÁLCULO DEL IPC ........................ 66
EVOLUCIÓN DEL VALOR REAL (PODER ADQUISITIVO) DE UNA
FIGURA 2.7 PESETA, DURANTE LOS
ÚLTIMOS 35 AÑOS (FUENTE, INSTITUTO NACIONAL DE
ESTADÍSTICA) ................................................................................................. 67
CAPITULO 3
PROCESO DE PREPARACIÓN DE UNA OFERTA ........................................... 73
FIGURA 3.1
FIGURA 3.2 ESTIMACIÓN DEL COSTE Y EL PRECIO DB UN PROYECTO........................ 74
FIGURA 3.3 DESCRIPCIÓN DE UN PAQUETE DE TRABAJO ............................................. 78
XIV DIRECCIÓN Y GESTIÓN DE PROYECTOS _____________________________________________ @RA-
MA
FIGURA 3.4 E STIMACIÓN DEL ESFUERZO NECESARIO PARA LLEVAR A CABO UN PROYECTO .............. 81
FIGURA 3.5 M ODELO DEL ICEBERG , DE COSTES OCULTOS ................................................................... 87
FIGURA 3.6 FORMATO DE PRESUPUESTO DE UN PROYECTO ................................................................. 93
FIGURA 3.7 PLANIFICACIÓN INICIAL DEL PROYECTO DE INSTALACIÓN DE UN PORTÓN ..................... 98
FIGURA 3.8 PLANIFICACIÓN MODIFICADA DEL PROYECTO DE INSTALACIÓN DE UN PORTÓN ............. 99
FIGURA 3.9 E JEMPLO DE GRAFO DE PROYECTO .................................................................................... 101
FIGURA 3.10 C ÁLCULO DE LOS VALORES MIC DE LOS SUCESOS DEL PROYECTO................................. 102
FIGURA 3.11 C ÁLCULO DE LOS VALORES MAC DE LOS SUCESOS DEL PROYECTO ................................ 103
FIGURA 3.12 C AMINO Y ACTIVIDADES CRÍTICAS DEL GRAFO PERT DEL PROYECTO ........................... 103
FIGURA 3.13 C AMINO Y ACTIVIDADES CRÍTICAS DEL GRAFO PERT DEL PROYECTO ............................ 107
FIGURA 3.14 SECUENCIA DE ACTIVIDADES DEL PROCESO DE PREPARACIÓN DEL AVIÓN ...................... 108
FIGURA 3.15 FORMATO DE PLAN FINANCIERO DEL PROYECTO .............................................................. 111
FIGURA 3.16 FLUJO DE ACTIVIDADES DEL PROYECTO F LORES DEL SUR ............................................... 117
FIGURA 3.17 E STRUCTURA DE PAQUETES DE TRABAJO PARA EL PROYECTO F LORES DEL S UR ............. 118
FIGURA 3.18 C ONTENIDO DEL P AQUETE DE TRABAJO "PT.0, GESTIÓN" ............................................. 119
FIGURA 3.19 C ONTENIDO DEL PAQUETE DE TRABAJO "PT. 310, P REPARACIÓN DEL CURSO ".............. 120
FIGURA 3.20 E STIMACIÓN DEL ESFUERZO ASOCIADO AL PROYECTO DE F LORES DEL S UR ................... 122
FIGURA 3.21 E SFUERZO, SEGÚN CATEGORÍAS, EN EL PROYECTO DE F LORES DEL S UR ......................... 123
FIGURA 3.22 E SFUERZO, SEGÚN ÁREAS FUNCIONALES, EN EL PROYECTO DE F LORES DEL SUR ........... 124
FIGURA 3.23 PRESUPUESTO ESTIMADO PARA EL PROYECTO F LORES DEL SUR ..................................... 127
FIGURA 3.24 PLANIFICACIÓN TEMPORAL PREVISTA PARA EL PROYECTO ............................................. 128
FIGURA 3.25 PLAN FINANCIERO DEL PROYECTO FLORES DEL SUR ........................................................ 131
FIGURA 3.26 E VOLUCIÓN DE INGRESOS Y GASTOS (E UROS) DEL PROYECTO F LORES DEL S UR............ 131
CAPÍTULO 5
FIGURA 5.1 FORMATO DE FAX ............................................................................................................... 165

FIGURA 5.2 FORMATO DE COMUNICACIÓN INTERNA ........................................................................... 166
FIGURA 5.3 FORMATO DE CONVOCATORIA DE REUNIÓN ...................................................................... 169
FIGURA 5.4 Lo QUE SE DEBE Y NO SE DEBE HACER AL CONVOCAR UNA REUNIÓN .............................. 171
FIGURA 5.5 FORMATO DE ACTAS DE REUNIÓN ..................................................................................... 175
FIGURA 5.6 Lo QUE SE DEBE Y NO SE DEBE HACER AL REDACTARLAS ACTAS DE UNA REUNIÓN ... 176
FIGURA 5.7 FORMATO DE RESUMEN DE REUNIÓN ................................................................................. 178
FIGURA 5.8 Lo QUE SE DEBE Y NO SE DEBE HACER AL REDACTAR EL RESUMEN DE UNA REUNIÓN. 179
FIGURA 5.9 FORMATO DE ESTADO DE LAS ACCIONES PASADAS Y PENDIENTES ................................... 182
FIGURA 5.10 Lo QVP. SE DEBE Y NO SE DEBE HACER AL REDACTAR EL ESTADO DE LAS ACCIONES .. 183
FIGURA 5.11 RECTA DE AVANCE TÍPICA DE LOS TRABAJOS DE UN PROYECTO ....................................... 184
FIGURA 5.12 FORMATO DE AVANCE ECONÓMICO DEL PROYECTO ......................................................... 186
FIGURA 5.13 R ECURSOS CONSUMIDOS FRENTE A LOS REMANENTES DEL PROYECTO .......................... 187
FIGURA 5.14 R EPRESENTACIÓN GRÁFICA DE LAS HORAS, SEGÚN CATEGORÍAS, CONSUMIDAS ........... 187
FIGURA 5.15 REPRESENTACIÓN GRÁFICA DE LA EVOLUCIÓN DE INGRESOS Y GASTOS .......................... 188
FIGURA 5.16 FORMATO DE EVOLUCIÓN ECONÓMICA DEL PROYECTO ................................................... 189
FIGURA 5.17 E VOLUCIÓN DEL CONSUMO DE HORAS DE TRABAJO DEL PROYECTO ............................... 190
FIGURA 5.18 EVOLUCIÓN DE LOS INGRESOS Y GASTOS DEL PROYECTO ................................................. 190
FIGURA 5.19 INFORME DE SITUACIÓN DE PROYECTO O PAQUETE DE TRABAJO ...................................... 196
FIGURA 5.20 FORMATO DE GESTIÓN DE LA DOCUMENTACIÓN DEL PROYECTO .................................... 200
FIGURA 5.21 FORMATO DE PROPUESTA DE CAMBIO ............................................................................... 204
FIGURA 5.22 FORMATO PE REGISTRO DE CAMBIOS ............................................................................... 207
FIGURA 5.23 R EPRESENTACIÓN GRÁFICA DE LOS INTERFACES EN UN PROYECTO ................................ 210
CAPÍTULO 6
FIGURA 6.1 FORMATO DE ACEPTACIÓN PARCIAL / FINAL DE LOS TRABAJOS ........................................ 221
FIGURA 6.2 BALANCE DE INGRESOS Y GASTOS PARA EL CIERRE DEL PROYECTO ................................ 224
FIGURA 6.3 FORMATO DE INFORME ECONÓMICO DEL CIERRE DE UN PROYECTO ................................ 226
ÍNDICE DE FIGURAS XV
FIGURA 6.4 FORMATO DE INFORME DE SITUACIÓN FINAL ............................................................... 227

FIGURA 6.5 INDICADORES ECONÓMICOS DEL PROYECTO ................................................................ 237
EPÍLOGO
FIGURA E.l CONVERGENCIA DE FACTORES HACIA EL DESARROLLO DEL TELETRABAJO..................... 243
APÉNDICE A
FIGURA A. 1 PLANIFICACIÓN TEMPORAL DEL ESTUDIO JURÍDICO ..................................................... 250

FIGURA A.2 PRESUPUESTO DEL ESTUDIO JURÍDICO ........................................................................ 252
FIGURA A.3 FLUJO DE ACTIVIDADES ASOCIADAS AL CONTRATO THERMOPC .................................... 265
FIGURA A .4 PLANIFICACIÓN DEL PROYECTO THERMOPC, FASE DE DISEÑO Y DESARROLLO ................ 266
FIGURA A.5 PLANIFICACIÓN DEL PROYECTO THERMOPC, FASE DE FABRICACIÓN .............................. 268
FIGURA A.6 ESTIMACIÓN DEL ESFUERZO ASOCIADO AL DISEÑO Y DESARROLLO DEL
PROTOTIPO DE THERMOPC ...................................................................................... 269
FIGURA A.7 PRESUPUESTO DEL PROYECTO THERMOPC, FASE DE DISEÑO ......................................... 271
FIGURA A.8 ESTIMACIÓN DEL ESFUERZO ASOCIADO A LA FABRICACIÓN EN SERIE DE THERMOPC 273
FIGURA A.9 PRESUPUESTO DEL PROYECTO THERMOPC, FABRICACIÓN ........................................... 274
FIGURA A. 10 PRESUPUESTO DEL PROYECTO THERMOPC, FASE DE FABRICACIÓN, VALORES
MODIFICADOS ................................................................................................................................... 277
FIGURA A.11 PROCEDIMIENTO DE AUDITORÍA Y DIAGNÓSTICO DEL PROYECTO ................................... 280
FIGURA A.12 INFORME DE EVOLUCIÓN DEL PROYECTO DE FLORES DEL SUR, MES 3 ............................. 281
FIGURA A.13 INFORME DE SITUACIÓN ECONÓMICA DEL PROYECTO ................................................... 283
FIGURA A.l 4 RECURSOS CONSUMIDOS Y REMANENTES EN EL PROYECTO: HORAS (ARRIBA) E
INGRESOS/COSTES (ABAJO)...................................................................................... 285
FIGURA A.l 5 ESTIMACIÓN MODIFICADA PARA EL PROYECTO FLORES DEL SUR ................................... 286
APÉNDICE B
FIGURA B. 1 INTERRELACIÓN DE LOS AGENTES QUE CONFIGURAN EL PROCESO DE DESARROLLO

DE SOFTWARE................................................................................................................................... 291
FIGURA B.2 FASE DE ANÁLISIS Y PLANIFICACIÓN .......................................................................... 295
FIGURA B.3 NO ES CONVENIENTE COMENZAR EL DESARROLLO MIENTRAS NO SE HAYAN
APROBADO FORMALMENTE LOS REQUISITOS DE USUARIO Y DEL SOFTWARE ................... 296
FIGURA B.4 EVOLUCIÓN DE UN PROYECTO Y ACTUACIONES DE VALIDACIÓN Y VERIFICACIÓN ............. 298
FIGURA B.5 FASE DE DESARROLLO .............................................................................................. 303
FIGURA B.6 FASE DE OPERACIÓN Y MANTENIMIENTO ..................................................................... 304
FIGURA B.7 CICLO DB VIDA EN CASCADA (WATEBFALL)................................................................... 305
FIGURA B.8 CICLO DE VIDA INCREMENTAL ................................................................................... 306
FIGURA B.9 CICLO DE VIDA EVOLUTIVO ....................................................................................... 308
FIGURA B. 10 VOLUMEN RELATIVO DE PARTICIPACIÓN SEGÚN CATEGORÍA Y FASE DEL PROYECTO . 311
FIGURA B. 11 MODELO DE COSTES PARA PEQUEÑOS DESARROLLOS DE SOFTWARE ............................... 312
FIGURA B. 12 ESTRUCTURA GENÉRICA DE UN MODELO DE COSTES ..................................................... 312
FIGURA B. 13 IMPACTO ECONÓMICO DE LOS CAMBIOS A LOS REQUISITOS ............................................ 314
FIGURA B. 14 PORCENTAJE MEDIO DE ESFUERZO DEDICADO A CADA TIPO DE MANTENIMIENTO DEL
SOFTWARE ........................................................................................................................................ 317
FIGURA B. 15 FORMATO DE NOTIFICACIÓN DE DISCONFORMIDAD ...................................................... 318
FIGURA B. 16 FORMATO DE INFORME DE MODIFICACIÓN DEL SOFTWARE............................................. 319
FIGURA B.17 FORMATO DE HOJA DE ESTADO DEL DOCUMENTO ......................................................... 320
APÉNDICE C
FIGURA C.l ESTRUCTURA Y CONTENIDO DEL DISCO ....................................................................... 324

PRÓLOGO
El ser humano lleva muchos siglos acometiendo cada vez empresas más arduas y complejas.
Entre ellas encontramos desde siempre la realización de obras civiles, edificios,
construcciones militares, etc. Y en los dos últimos siglos se suman la producción de
artefactos industriales complejos, la organización de fábricas, etc. Este tipo de actividad
humana, que requiere fundamentalmente realizar "algo" en un tiempo determinado y con
unos recursos concretos y limitados, originariamente se limitaba a los casos que he mencionado
anteriormente y alguno más, pero ha ido extendiéndose cada vez más, a medida que la
complejidad de las "cosas" a realizar se acrecentaba.
Básicamente en la última mitad de este siglo (especialmente de a partir de la segunda guerra

mundial y durante la guerra fría) comienzan a utilizarse técnicas organizativas, es decir,
coordinación de recursos con un fin u objetivo común (habitualmente relacionado con el
cumplimiento de plazos). Nadie duda de que la carrera espacial protagonizada por rusos y
americanos significó un notable avance en el desarrollo de técnicas especiales de
organización, adaptadas a las peculiaridades de "ese tipo concreto de organizaciones"
efímeras en el tiempo y que necesitaban de una gran eficiencia en el control de plazos,
calidades y recursos. Aparecen las técnicas de gestión de proyectos.
En la actualidad encontramos una enorme cantidad de actividades humanas que presentan la

necesidad de controlar con el mismo rigor el tiempo, la calidad y la eficiencia en el empleo de
los recursos. Por ello necesitamos contar con instrumentos que nos ayuden a conocer mejor
cómo enfrentarnos a la gestión de este tipo de problemas.
Este libro que estamos prologando es un buen ejemplo de satisfacción de las necesidades
que comentamos. Su autor, además de haber sido en el pasado alumno mío, lo cual no es
relevante para mi juicio sobre su obra, es un gran profesional de la docencia y la ingeniería,
que ha tenido la ocasión de conocer en la práctica muchos de los problemas a los que se
enfrenta la gestión de un proyecto y, además, ha tenido la valentía y ha desarrollado el
esfuerzo notable de poner en un buen libro esos conocimientos.
XX DIRECCIÓN Y GESTIÓN DF. PROYECTOS
Normalmente muchos libros acerca de la gestión de los proyectos nos relatan un conjunto
de técnicas muy interesantes, que con su estudio nos permiten ser expertos en las mismas. Sin
embargo, pocos libros trasmiten con tanta claridad como el presente la idea de proyecto en el
ámbito de la ingeniería. El conocimiento de las diferentes fases de la vida de un proyecto,
resaltando los aspectos claves y más relevantes de las mismas para la correcta gestión de
un proyecto, a mi juicio es una de las aportaciones más importantes de este libro.
Quiero por todo ello felicitar al lector por poder tener la oportunidad de compartir, como
la tuve yo, los conocimientos y experiencias plasmadas en este buen libro de gestión de
proyectos.
Alejandro Orero Giménez Catedrático, Universidad

Politécnica de Madrid
PREFACIO A LA SEGUNDA EDICIÓN
Hace ya más de cuatro años, cuando la peseta aún no había dado paso al euro, comencé
a escribir la primera edición de este libro. Desde entonces, las tecnologías de la información
han cambiado radicalmente la manera en la que nos comunicamos, y esto ha ayudado a que
la economía se globalice hasta extremos anteriormente insospechados. Y no siempre en
favor de todos. El mundo ha vivido horrorizado la transformación de un sistema de equilibrio
de poderes basado en dos superpotencias, que ha sido reemplazado por una sociedad que
lucha contra la proliferación mundial del terrorismo. Hemos vivido varias guerras, dos de
ellas aún en marcha. La unión europea se ha ampliado hacia el este y se debate entre, por un
lado, la necesidad de competir social y económicamente con los Estados Unidos y, por otro,
respetar los intereses individuales de sus miembros por mantener sus identidades y cuotas de
poder nacionales.
Mientras, Oriente Medio promete seguir siendo un centro de atención que dictará, sin duda,
las políticas exteriores de los países más desarrollados, pero que también podría constituirse
en un espejo en el que muchos países africanos podrían mirarse. Muchas naciones de la
América del Sur y del Centro, en tanto, luchan por lograr definitivamente tasas de
crecimiento que les permitan lograr la estabilidad económica y social que necesitan para
abandonar, definitivamente, la lista de países en eterno desarrollo.
Desde el punto de vista personal, también el autor ha vivido algunos cambios: un país nuevo,
un trabajo nuevo, amigos nuevos y nuevas perspectivas de futuro (siempre incierto). Y, por
supuesto, una nueva (y más crítica) forma de pensar.
Así que, cuando mi Editor me recordó la necesidad de revisar y actualizar el libro, pensé
que tal vez sería mejor empezar de nuevo, desde cero.
XXII DIRECCIÓN Y GESTIÓN DE PROYECTOS
Y no. Tras pensarlo detenidamente decidí que no. Aunque tantas cosas han cambiado
en el mundo, la forma de organizar y conducir proyectos es esencialmente la misma.
Algunos hábitos se han modificado, e Internet ayuda a que algunas empresas se
organicen de manera diferente, publiciten, vendan y atiendan a sus Clientes a través de
La Red. Pero en esencia, cómo gestionar y dirigir un proyecto, no ha cambiado
demasiado.
Así que, en esta Segunda Edición, el lector encontrará una nueva moneda, nuevos
ejemplos, algo de información adicional, y muchas erratas corregidas (que habrán
dado lugar, sin duda, a otras tantas). Pero me tranquiliza saber que, en esencia, lo que
he enseñado a mis alumnos estos últimos años y he intentado transmitir a los lectores
es, a día de hoy, todavía válido.
Y por último, no quisiera dejar de agradecer una vez más a mi familia, mis amigos,
mis alumnos, mis compañeros de trabajo y mis Clientes las lecciones que cada día me
dan sobre dirección y gestión de proyectos, tal vez menos técnicas, pero seguro que
más humanas. Y, por supuesto, a los lectores, que con suma paciencia y benevolencia
recibieron desde el primer día la primera edición de esta obra, y han hecho de ella uno
de los títulos de más éxito en su categoría.
Alberto Domingo Ajenjo
La Haya, Octubre de 2004

INTRODUCCIÓN
Reconozcámoslo. Nos guste o no, todos somos gestores. De pequeños gestionamos nuestra
asignación semanal como mejor podemos. Más tarde, nuestras horas de estudio y de diversión.
Y también gestionamos nuestro sueldo cuando empezamos a trabajar, los bocadillos cuando vamos
de acampada o el presupuesto disponible para las vacaciones. En todos los casos, lo que
pretendemos es hacer el mejor uso posible de los recursos disponibles (dinero, bienes, tiempo,
etc.) para satisfacer de manera óptima los objetivos perseguidos (diversión, bienes que podemos
adquirir, calidad de vida, etc.).
Evidentemente, gestionar y dirigir supone gozar de una visibilidad más amplia sobre los recursos
y los objetivos, y difícilmente estaremos dispuestos a renunciar a la gestión de nuestros propios
recursos aunque, en muchos casos, implique cierta responsabilidad adicional y, por qué no decirlo,
algún que otro quebradero de cabeza.
Asumido lo anterior, ¿por qué los jóvenes profesionales son tan reacios a dirigir y a gestionar los
proyectos en los que participan? Es evidente que al optar por una carrera profesional no vinculada
con la gestión, el individuo se decanta por actividades técnicas, pero eso no ha de significar
renunciar a la "perspectiva" y al "poder" que supone participar en las tareas de dirección y
gestión de los proyectos en los que trabaje.
Participar en la gestión de un proyecto supone conocer los recursos y objetivos del mismo, así
como las limitaciones a tener en cuenta, y este conocimiento nos permite optimizar nuestro trabajo
y adaptarlo a los requisitos más específicos o más relevantes del proyecto. La gestión pasa de ser
una tarea aislada a constituirse en una herramienta para mejorar el desarrollo de las actividades
técnicas.
Y no olvidemos que, trabajemos para una empresa o por cuenta propia, el objetivo de todo acto
mercantil es lograr y maximizar el beneficio, es decir, ganar "más" (ya sea
XXIV DIRECCIÓN Y GESTIÓN DE PROYECTOS
dinero, prestigio, satisfacción personal u otro tipo de recompensa). Parece lógico

pensar, pues, que nuestro jefe preferirá un empleado que se involucre en la gestión
global del proyecto y ayude a obtener el resultado convenido con el mínimo esfuerzo,
frente a otro subalterno que, en busca de la excelencia técnica, haga peligrar el
beneficio esperado, al consumir excesivos recursos.
El objetivo final de este libro es muy ambicioso: lograr que el lector perciba las
actividades de dirección y gestión como tareas adicionales al propio trabajo técnico (al
igual que lo son la adquisición de materiales, la documentación o el servicio post-
venta, por ejemplo), y que comprenda cuáles son los mecanismos y herramientas
necesarios para ello. Probablemente este objetivo no pueda verse cumplido hasta
después de un par de años de inmersión en el mercado laboral (unos pocos ni siquiera
lo habrán conseguido al final de su vida laboral) pero, no en vano, aquellos que antes
lo logren tendrán una ventaja estratégica sobre los demás, aumentando sus
responsabilidades en la empresa, sus posibilidades reales de promoción y, por qué no,
su compensación económica.
Y para los que rotundamente se nieguen a abrir sus mentes a los aspectos mercantiles
asociados a la técnica, pues que al menos el esfuerzo les sirva para adaptarse lo mejor
posible (o lo menos traumáticamente posible) del aula, del laboratorio o del entorno
puramente técnico al mundo real.
A QUIEN VA DIRIGIDO ESTE LIBRO
Este libro es un manual de dirección y gestión de proyectos, sea cual sea el tipo de
contenido de los mismos. En general, es un libro para profesionales de otras
disciplinas que, por voluntad propia o por necesidad, han de coordinar, dirigir o
gestionar proyectos.
En la obra el lector encontrará un análisis estructurado de las actividades de dirección

y gestión, y una metodología, razonablemente completa', para gestionar un proyecto,
junto con numerosas herramientas de ayuda y ejemplos.
Teniendo esto en cuenta, la mayor utilidad del libro será para aquellos que, debiendo
abordar tareas de dirección y gestión, carezcan de gran experiencia en la materia. A
nuestro modo de ver, dos son los grandes grupos de lectores que podrán obtener
mayor provecho de la lectura de este texto:
Profesionales de la gestión, sin experiencia o con escasa práctica en la materia,

que necesiten una "guía práctica" para aplicar los conocimientos teóricos, y
que valoren disponer de un conjunto de herramientas para ello.
' Ya que las actividades de dirección y gestión, en muchos casos, tienen más de "arte" que de
técnica.
INTRODUCCIÓN XXV
"" Profesionales de otras disciplinas (técnicas o humanísticas), que hayan de

abordar aspectos de dirección y gestión.
De entre los profesionales de otras disciplinas pueden extraerse, a su vez, otros dos
grandes sub-grupos:
[S=
Profesionales con experiencia que, conociendo el entorno técnico de los
proyectos en los que trabajan, tienen que asumir (por voluntad propia, o no),
llegado el momento, responsabilidades de dirección y gestión de dichos
proyectos. Este grupo de lectores encontrará en el texto un conjunto de
orientaciones metodológicas para evaluar, organizar, supervisar y controlar el
desarrollo de los proyectos que tan bien conocen, así como un conjunto de
herramientas para ello, que le facilitarán las tareas de gestión y minimizarán el
tiempo y él esfuerzo necesarios.
* Profesionales sin demasiada experiencia que, por la tipología o tamaño de la

empresa en la que se integran (tal vez se trate del caso de profesionales
liberales, autónomos, en los que la "empresa" son ellos mismos), deben
asumir desde el primer momento todas las facetas del proyecto, incluyendo las
de dirección y gestión. Para estos lectores, el libro, además, servirá como
primera aproximación a la actividad proyectual, tratando de facilitar la
transición desde el mundo académico al profesional.
ESTRUCTURA DEL LIBRO
El texto se ha dividido en seis capítulos. El primero de ellos es una introducción al

proceso proyectual. Se define el concepto de proyecto y el de empresa, así como la
vinculación entre el uno y la otra. Se describe el propósito y el alcance de las
actividades de dirección, gestión y administración de proyectos. Por último, se
propone la organización de Caos Consulting, una empresa (ficticia) que servirá de
modelo para los sucesivos ejemplos que el lector encontrará en el libro.
Los siguientes cinco capítulos abordan el alcance, la metodología y las herramientas

propuestas para abordar cada una de las fases típicas en las que se ha dividido un
proyecto cualquiera. Así, el segundo capítulo trata de la fase de detección de
oportunidades comerciales. Los capítulos tercero y cuarto se ocupan, respectivamente,
de la evaluación del proyecto y (en su caso) de la preparación de la oferta.
El capítulo cinco se dedica al seguimiento del proyecto, es decir, a la fase de ejecución

de los trabajos, propiamente dicha. Por último, el sexto capítulo se ocupa del proceso
de cierre del proyecto, y de la evaluación de los resultados del mismo. Para facilitar el
seguimiento de los ejemplos, así como para que sirvan de herramienta base para la
XXVI DIRECCIÓN Y GESTIÓN DE PROYECTOS
gestión de otros proyectos, se ha optado por incluir todos los formatos de los
documentos mostrados en este libro en un disco para PC.
El libro incluye, además, varios apéndices. El primero de ellos ilustra con ejemplos
prácticos de proyectos (más o menos reales) de diferente contenido y tamaño las
técnicas y procedimientos propuestos en los capítulos de la obra. En esta parte se ha
hecho especial énfasis en incluir aspectos prácticos que, resultado de la experiencia,
constituyen las anécdotas en la gestión, habituales en prácticamente todos los
proyectos. El apéndice B, por su parte, es una breve introducción a las peculiaridades
que implica la dirección y gestión de un proyecto de desarrollo de software, tan
habitual en nuestros días y que, por la intangible naturaleza del resultado (una
aplicación software), puede ser tan distinto de manejar.
Además, el lector encontrará a lo largo de la obra numerosas lecturas complementarias

que versan sobre temas asociados a la gestión y que, sobre todo a los profesionales
más jóvenes, servirán como introducción a los temas que tratan (tan diversos y
variados como la preparación de un curriculum vitae, el estilo a utilizar al redactar un
documento, estrategias de negociación o el efecto de la inflación sobre la economía de
un proyecto). En principio, estas lecturas estuvieron todas ellas agrupadas en forma de
apéndices, pero, finalmente, con la intención no sólo de colocarlas allí donde pudieran
ser más útiles, sino con el interés adicional de romper la monotonía del resto del texto,
se ha optado por distribuirlas a lo largo de los capítulos del libro.
Junto con el texto del libro, el autor ha preparado un disco en el que se incluyen las
herramientas y los formatos incluidos en la obra, así como los ejemplos resueltos
utilizados a modo ilustrativo (fundamentalmente a lo largo de los capítulos 3, 5, 6 y el
apéndice A). También encontrará el lector en el disco el texto de las Leyes y
Reglamentos jurídicos mencionados en el libro, junto con otros textos de referencia. A
nuestro modo de ver, la principal ventaja de este material complementario es doble.
Por un lado permite de inmediato utilizar las herramientas propuestas para gestionar
proyectos en curso o a punto de comenzar. Por otro, al proporcionarse como ficheros
fuente de aplicaciones muy extendidas (Microsoft Word y Microsoft Excel), son
fácilmente modificables para que cada lector pueda adaptarlos a las peculiaridades y
necesidades concretas de sus proyectos o de la organización. El contenido y la
organización detallada del disco se describe en el apéndice C.
Por último, no resta sino rogar benevolencia a los lectores por las múltiples erratas y
errores que, sin duda, han encontrado confortable abrigo en esta ya segunda edición
del texto. De todos ellos pedimos y agradecemos cuantos comentarios y críticas
(constructivas, preferiblemente) estimen oportuno, que podrán remitir, a nombre del
autor, a la dirección de correo electrónico de la editorial.
INTRODUCCIÓN XXVII
AGRADECIMIENTOS
Como es bien sabido, un libro rara vez es el resultado del trabajo de una sola persona.
Una buena parte del conocimiento contenido en el presente texto se la debo a muchos
de mis compañeros y colegas, a mis alumnos, al paciente auditorio de mis seminarios,
así como a aquellas organizaciones para las que tengo y he tenido la oportunidad de
dirigir o gestionar proyectos.
También quiero agradecer a Jorge Deza sus siempre interesantes sugerencias para la
obra, así como las aportaciones que, con su característico sentido del humor, realizó al
primer borrador de este libro.
Alberto Domingo Ajenjo

CAPITULO 1
INTRODUCCIÓN A LA DIRECCIÓN Y
GESTIÓN DE PROYECTOS
1. INTRODUCCIÓN
Existen prácticamente tantas definiciones de proyecto como autores y obras al

respecto en la literatura. Aunque todos tenemos claro el concepto asociado al término,
resulta, sin embargo, complejo formular una definición completa y consistente, que no
olvide ninguna característica de lo que es un proyecto^, y que no* restrinja ni limite las
actividades que puedan encuadrarse dentro de dicha definición.
Pero éste no es un libro de carácter teórico, sino más bien eminentemente práctico. Por
esta razón, bastará para los propósitos del mismo una definición informal que, sin
competir con las formalizaciones de obras más precisas, abstraiga las características
fundamentales del proceso proyectual.
A poco que se analice la anterior definición se observa un conjunto de características

que deben cumplirse para que una serie de actividades pueda considerarse como un
proyecto. Las más relevantes se citan a continuación:
> Persecución de uno o varios objetivos. Las actividades aisladas no

constituyen, por sí solas, un proyecto. Para que exista un proyecto, debe
existir una coordinación de actos orientados a la consecución de uno o
varios objetivos, integrados entre sí y estructurados, tanto de índole
técnica como económica. En general, el objetivo principal de un proyecto
2 DIRECCIÓN Y GESTIÓN DE PROYECTOS
es satisfacer un conjunto de requisitos técnicos, a un coste dado, en las

condiciones más eficientes.
> Actividades planificadas, ejecutadas y supervisadas. La coordinación
de actividades anteriormente mencionada es condición sine-qua-non para
que a las mismas se las pueda calificar de proyecto. Actividades aisladas,
independientes, carentes de interrelación entre ellas, no constituyen un
proyecto. Un proyecto, por el contrario, exige que exista vinculación
entre las actividades, puesto que persiguen un objetivo común, dicha
vinculación debe plasmarse en forma de planificación (técnica, temporal
y económica), cuya correcta ejecución, supervisada, es clave para el éxito
o el fracaso del mismo.
> Disponibilidad limitada de recursos. El proceso proyectual implica la
búsqueda de la eficiencia en el uso de los recursos para obtener el
resultado perseguido. Si los recursos son ilimitados, desaparece el
concepto de eficiencia, y con él la naturaleza proyectual de las
actividades.
> Limitado en el tiempo. Un proyecto debe estar acotado en términos de
principio y fin del mismo. El final de un proyecto se alcanza cuando se
cumplen los objetivos prefijados, o cuando se hace evidente que dichos
objetivos no pueden alcanzarse (fracaso del proyecto). Si un conjunto de
actividades carece de fin es porque no existe un objetivo alcanzable y, por
tanto, no constituyen un proyecto. Sin embargo, la fínitud temporal no
implica períodos cortos de tiempo. Hay proyectos que duran años, o que
sobrepasan a la generación de gentes que los empezó (por ejemplo, ia
construcción de algunas de las catedrales más conocidas). Por otro lado,
aunque el proyecto tenga que estar acotado en el tiempo, no sucede lo
mismo con sus resultados, que pueden perdurar con carácter indefinido
(por ejemplo, la catedral).
> Con resultado único. Retomar un trabajo finalizado y repetir sus
resultados no es un proyecto. Un proyecto exige hacer algo nuevo o único
en su género, y no reproducir resultados de otras actividades.
Algo que se desprende de inmediato de las consideraciones anteriores, es que el

proyecto no es un bien o servicio de la empresa. No forma, pues, parte de la lista de
precios, y no puede venderse "tal cual". Un proyecto es un conjunto de actividades
orientadas a un fin mercantil, pero no el fin en sí mismo.
Algunos autores restringen1 algo más la definición de proyecto, imponiendo que

requiera el trabajo en equipo. Si bien es cierto que, en general, casi todos los proyectos
requieren la participación de varias personas, bien con vistas a la realización de las
actividades técnicas, bien colaborando o prestando apoyo en tareas auxiliares
(administrativas, jurídicas, etc.), no nos parece adecuado dejar de lado los proyectos
de pequeño tamaño, realizados por una sola persona, pero que siguen las mismas
©RA-MA ______________ CAPÍTULO 1: INTRODUCCIÓN A LA DIRECCIÓN Y GESTIÓN DE PROYECTOS 3
pautas y fases que cualquier proyecto de mayor dimensión, y que pueden gestionarse
mediante las mismas técnicas descritas en este libro.
La figura 1.1 muestra otra forma de ver un proceso proyectual. El objeto de un

proyecto, por lo general, es obtener un resultado, en forma de bien o servicio, para un
destinatario, usuario o cliente. Este destinatario impone un conjunto de
especificaciones (técnicas, de prestaciones, de calidad, etc.) que deben cumplirse para
considerar que el resultado del proyecto es válido. Para obtener dicho resultado, se
hace uso de un conjunto de recursos, materiales y/o humanos, sometidos a un cierto
número de restricciones, de índole económica o temporal. La dirección del proyecto
persigue la correcta planificación, ejecución y supervisión de las actividades del
mismo, que permiten alcanzar los resultados perseguidos con los recursos disponibles
y con las limitaciones existentes.
Figura 1.1 El proceso proyectual
1.1 Tipos de proyectos
Una vez más, cada autor opta por una clasificación de los proyectos atendiendo a
algún parámetro concreto, con lo que resultan múltiples clasificaciones posibles de los
mismos, en función de su tamaño, duración, objeto, modelo de gestión, etc. A
4 DIRECCIÓN Y GESTIÓN DE PROYECTOS © RA-MA
continuación se incluye una posible clasificación básica de proyectos comunes,

informal, basada en una conjunción del alcance y el objeto de los mismos:
Proyecto clásico. Este tipo de proyectos aborda la realización de una serie de

documentos que definen la obra o el trabajo a realizar, para su ejecución en un
futuro. El alcance comprende la identificación, evaluación, organización y
valoración de las actividades que haría falta emprender para culminar el
resultado perseguido, pero en su alcance no está comprendida la realización de
las mismas. El resultado de los trabajos es, pues, una memoria, unos planos,
un pliego de condiciones y un presupuesto y, a lo sumo, un prototipo o
maqueta del objeto en cuestión. Si el alcance del proyecto es amplio o muy
ambicioso, a menudo es conveniente abordarlo en dos fases, estando la
primera de ellas orientada a definir las directrices generales del trabajo a
realizar. Esta primera fase recibe el nombre de anteproyecto.
Proyecto de investigación. Los proyectos de investigación tienen como

objeto aportar, a su conclusión, un conjunto de conocimientos nuevos en una
disciplina y materia concreta, a menudo desconocidos al comienzo de los
trabajos, para que otros puedan beneficiarse posteriormente de los mismos, en
entornos industriales o académicos. El resultado de este tipo de proyectos es
una memoria de investigación donde, aparte del planteamiento del problema a
resolver, y la descripción del estado del arte, se reseñan los trabajos realizados,
los resultados de los mismos y las conclusiones pertinentes, junto con las
futuras lineas de investigación propuestas en esa disciplina concreta.
Estudios y análisis. En ocasiones el alcance de un trabajo concreto se limita a

analizar o estudiar la información disponible acerca de los aspectos técnicos,
económicos o sociales de un determinado problema. En este caso, el proyecto
recibe el nombre de estudio (comprensión o entendimiento del problema) o
análisis (examen del problema para comprender los principios del mismo).
Estudios de viabilidad. A veces la complejidad del problema que se aborda

pone en entredicho la posibilidad de éxito de un proyecto concreto. En tales
casos, es práctica común realizar un conjunto de actividades que pongan de
relieve los aspectos considerados (técnicos, económicos, jurídicos, etc.) antes
de abordar el proyecto definitivo. Este conjunto de actividades, junto con su
resultado, recibe el nombre de estudio de viabilidad.
Proyecto industrial. Éste es, en principio, el tipo de proyectos a los que va

dirigido este libro. A diferencia de los proyectos clásicos, los proyectos
industriales comienzan y terminan en sí mismos, dando lugar a un producto o
servicio terminado (sin que ello sea obstáculo para que otros proyectos partan,
posteriormente, de los resultados del primero). Como cualquier proyecto,
involucra una planificación en la ejecución de actividades orientadas a un fin
SRA-MA _________ CAPITULO 1: INTRODUCCIÓN A LA DIRECCIÓN Y GESTIÓN DE PROYECTOS 5
concreto (el bien o servicio) por lo que, una vez finalizado el mismo, la
replicación de los resultados no constituiría un proyecto en sí mismo2.
Otra clasificación interesante para los proyectos es aquella que los diferencia teniendo
en cuenta quién es el Cliente o el destinatario de los trabajos:
•" Los proyectos externos a la organización son aquellos en los que el Cliente es
ajeno a la empresa (o las personas) que hace los trabajos. Éste es el tipo más
común de proyecto, y su funcionamiento teórico es sencillo y predecible, pues
se rige fundamentalmente por criterios de mercado, incluyendo competitividad
y eficacia.
*" Los proyectos internos a la organización, por su parte, son aquellos en los
que el Cliente es la misma empresa que desarrolla los trabajos. Por ejemplo,
son proyectos internos el desarrollo de una nueva aplicación de gestión de
nóminas por el departamento de informática de una empresa, el diseño un
nuevo modelo de vehículo por una marca de automóviles o un proyecto de
investigación y desarrollo que una empresa aborda para mejorar su posición
competitiva y estratégica.
Si bien en principio no debería haber diferencia práctica entre el desarrollo de

proyectos internos y externos, lo cierto es que al "tener al cliente en casa" se
desvirtúa el modelo de competencia perfecta, y se corre el riesgo de caer en
prácticas que disminuyan la eficiencia real de los trabajos, y el nivel de
exigencia ante los resultados.
En un plano superior al de los proyectos se encuadra el concepto de programa. Un

programa es un conjunto ordenado de proyectos independientes que, de manera global,
persiguen o acercan un objetivo común. Cuando, por ejemplo, el ministerio de defensa
de una nación necesita renovar su tecnología militar, pone en marcha un programa de
modernización. Dicho programa abarca objetivos, plazos y presupuestos mucho
mayores de los que sería razonable encomendar a un solo proyecto. La actividad
principal del programa es, pues, coordinar la planificación general, la asignación
presupuestaria, la contratación y el seguimiento de los diferentes proyectos que, en
conjunto, persiguen los objetivos del programa.
' A la repetición de los resultados obtenidos en un proyecto se le suele denominar "unidades

recurrentes". Por ejemplo, diseñar y fabricar un satélite es un proyecto. Fabricar el segundo
(sin cambios), no lo sería, desde un punto de vista estrictamente teórico. Pero podría serlo si
para las subsiguientes unidades se incorporan mejoras o modificaciones sustanciales que
revitalicen la actividad proyectual, o si no es el propio producto, sino la fabricación en serie, lo
que se considera como proyecto.
1.2 La dimensión técnica, económica, comercial y estratégica

de un proyecto
A la hora de abordar un proyecto, no hay que olvidar que en el mismo se involucran

aspectos de diferente índole, que surgen de la convergencia de los objetivos del
destinatario, de los recursos disponibles, de las restricciones y del entorno (empresa,
organización, etc.) donde se lleve a cabo.
La dimensión técnica del proyecto hace referencia a la adecuación del resultado del
mismo a los objetivos del destinatario, vigilando que se cumplan sus requisitos o,
dicho de otra manera, que satisfaga las necesidades por las que el proyecto fue
encargado.
La dimensión económica del proyecto involucra los aspectos de costes e ingresos de

los trabajos realizados que, por un lado, permiten que el resultado del proyecto sea
económicamente razonable y, por otra parte, logren que el coste de los recursos
utilizados por el equipo de proyecto no supere los ingresos obtenidos.
Pero todo proyecto presenta una dimensión comercial para la empresa o equipo de
trabajo que lo desarrolla, que le proporciona una imagen frente a sus potenciales
clientes, y facilita la reutilización para otros proyectos de la experiencia obtenida en el
actual.
Por último, no hay que olvidar que si el ejecutor del proyecto es una empresa llamada
a perdurar en el tiempo, el objeto del trabajo no es sólo obtener un beneficio
económico puntual, sino además adquirir tecnologías, experiencia y saber que le
permita seguir compitiendo en ese mercado, en las mejores condiciones, durante el
mayor tiempo posible. El proyecto adquiere, así, una dimensión estratégica.
A título de ejemplo, imaginemos un proyecto consistente en diseñar y fabricar un

prototipo para un nuevo vehículo de transporte. La dimensión técnica del proyecto
determinará la necesidad de que el vehículo diseñado cumpla con los requisitos (peso,
consumo, capacidad de carga, aceleración, etc.) requeridos por el cliente, mientras que
la dimensión económica requerirá, en la dualidad reseñada anteriormente que, por un
lado, el coste del vehículo sea competitivo y, por otro sea posible diseñarlo y
construirlo con los recursos limitados de que dispongamos. La dimensión estratégica
tendrá como objetivo, por su parte, comercializar proyectos similares para
reaprovechar la experiencia y, por otro lado, introducir o afianzar la posición de
nuestro grupo de trabajo en el mercado o sector de los vehículos de transporte.
0 RA-MA__________________ ( A P Í I U L O I: INTRODUCCIÓN A I . A DIRECCIÓN Y GESTIÓN DE PROYECTOS 7
1.3 Costes, gastos, ingresos, margen y beneficio
A nadie se le escapa que la principal razón por la que una empresa, individuo o grupo
de individuos aborda un proyecto es la consecución de unos beneficios. Aunque la
cultura social actual tiende a minusvalorar y a denostar el concepto de beneficio^, toda
actividad humana está orientada, por lo general, a la consecución del mismo.
Lo que ocurre es que no siempre el beneficio de una actividad es de tipo económico.

Existen ganancias o provechos (en general, lucro) que no son de tipo monetario, ni
siquiera económico. Hay muchas actividades cuyo resultado no es un excedente
monetario, sino un incremento de nuestro prestigio, un mayor bienestar moral o social,
o un beneficio a terceros. Cuando publicamos un artículo de forma gratuita buscamos
el reconocimiento social, y cuando participamos en una labor humanitaria
perseguimos un beneficio económico a terceros. Cuando una empresa ejecuta trabajos
a beneficio económico nulo es porque pretende acceder o fidelizar a un cliente, abrirse
mercado u obtener una experiencia concreta. En este sentido, el dinero es sólo una
forma de beneficio y, por tanto, no es ni mejor ni peor que las demás.
Para obtener el beneficio asociado a una actividad es necesario incurrir en una serie de
costes. El coste es el valor de los factores de producción que se ponen en juego y se
consumen para realizar una actividad. Son costes típicos los de personal del equipo de
trabajo que participa en las actividades, los de la materia prima consumida y, en
general, los asociados a la destrucción o inutilización (en el sentido positivo del
término) de recursos.
Conviene no confundir el concepto de coste con el de gasto. El gasto es el intercambio

de un factor de producción por otro, lo que sucede cuando, por ejemplo, se adquiere
materia prima. El factor dinero se intercambia por el factor (por ejemplo) madera, con
lo que se incurre en un gasto. Sin embargo, hasta que no se consuma dicha materia
prima en el proceso productivo, no podremos hablar de coste.
Por supuesto, cuando se incurre en costes asociados a los recursos propios, se espera a
cambio obtener unos ingresos. Como ya se ha dicho, los ingresos esperados pueden
ser en forma de retribución monetaria, bienes materiales, o de maneras más intangibles,
como prestigio, cuota de mercado, etc.
El concepto de beneficio sería mucho más popular si nos esforzáramos en comprender la

enorme utilidad social del mismo. El beneficio, aparte de recompensa para el empresario, es la
clave para el mantenimiento y el crecimiento de la actividad mercantil, tan necesaria en
cualquier sociedad. De esto ya nos dimos cuenta hace miles de años. El origen etimológico de
la palabra beneficio se sitúa en el latín beneficium, originado a su vez por la composición de
bene y faceré (bien hacer). Incluso equivalente sajón profit deriva del latín proficere (hacia el
progreso).
La diferencia entre los ingresos obtenidos y los costes en los que se incurre para
obtener los mismos conforma el concepto de margen. Un margen positivo supone que
nuestro proceso productivo ha consumido menos de lo que ha recuperado vía ingresos,
mientras que un margen negativo supone que los ingresos no han sido suficientes para
compensar los costes.
Para terminar, la diferencia entre margen y beneficio se explica mediante el concepto

de coste de oportunidad. El coste de oportunidad se define como el beneficio que se
hubiera podido obtener utilizando los recursos disponibles en una actividad distinta.
Imaginemos que un empresario obtiene 300.000 euros (€) por la realización de unos
trabajos, que le han supuesto incurrir, durante un ano, en costes de personal y equipos
de 240.000 €. El margen (que recibe también el nombre de incremento patrimonial)
del proyecto será, pues, de:
Margen = ingresos - costes = 300.000 - 240.000 = 60.000 €
SÍ el empresario hubiera colocado la cantidad inicial de 300.000 € en un depósito

financiero, al 5%, habría obtenido 15.000 € de intereses al final del ejercicio. El
beneficio de la actividad empresarial se reduce, pues, a:
Beneficio - margen - costes oportunidad - 60.000 - 15.000 = 45.000 €
En definitiva, y volviendo al principio del apartado, parece difícil imaginar que ningún
empresario o individuo decida voluntariamente afrontar una inversión de recursos
propios si no espera obtener a cambio un beneficio.
En resumen, la optimización del beneficio es la razón de ser de cualquier actividad

mercantil, aunque sujeta a dos consideraciones:
** El beneficio no siempre ha de ser de tipo económico-monetario.
•" A veces puede condicionarse la maximización de los beneficios a criterios de

otro tipo, tales como la limitación del riesgo, o de la inversión necesaria. Así,
©RA-MA CAPÍTULO 1: INTRODUCCIÓN A LA DIRECCIÓN Y GESTIÓN DE PROYECTOS 9
en el ejemplo mencionado, el empresario podría haber optado por colocar el

capital en el depósito financiero (u otra opción "segura") y conformarse con
un rendimiento inferior, a cambio de no incurrir en riesgos empresariales. Este
tipo de comportamientos es típico cuando, por ejemplo, se atraviesa un
período de inestabilidad o flaqueza del mercado.
LECTURA. MAXIMIZACIÓN DE BENEFICIOS EN LA EMPRESA
La realidad económica empresarial es tan compleja que su estudio directo es

prácticamente inabordable. En ella intervienen múltiples factores técnicos,
sociales, jurídicos, politices y estratégicos que cambian continuamente y que se
interrelacionan entre sí. Ante la incapacidad para describir de manera objetiva
comportamiento economice de las empresas se recurre a los modelos.
Un modelo es una representación simplificada de la realidad que, dejando de

lado los factores que menos afectan al resultado, trata de abstraer lo esencial del
sistema al que modela, y predice el comportamiento del mismo ante un conjunto
de hipótesis de partida concretas.
En el mundo empresarial, la optimización de beneficios es un modelo simplista

de los objetivos de la empresa. Un modelo así planteado no tiene en cuenta los
múltiples factores sociales, la cultura individual de los trabajadores, ni la
sensibilidad de sus clientes. No considera las fricciones entre propietarios,
directivos, empleados y consumidores. Tampoco aborda la naturaleza de los
propios beneficios, que no sólo pueden ser de índole económica, sino también
en forma de prestigio, labor social, etc.
Sin embargo, incluso en las organizaciones con menos ánimo de lucro se

utilizan indicadores del beneficio como medida del éxito de la organización, ya
que el modelo de optimización de beneficios, si no del todo realista, permite
contrastar, en líneas generales, cuan buena ha sido la actuación (y, en concreto,
la gestión) de la organización.
Supongamos una organización humanitaria sin ánimo de lucro cuyo objetivo

principal es ayudar a la integración de personas socialmente marginadas. ¿Qué
indicador de la "calidad" de su trabajo pueden utilizar? Cualquier valor
absoluto (número de actuaciones, número de personas integradas, número de
cartas de agradecimiento recibidas) no describe la eficiencia de la organización,
y no permite comparar los resultados con tos de otra organización, o con los
obtenidos en otros ejercicios. Al final, siempre es conveniente referir los
resultados a indicadores económicos claros (monetarios o no), tales como el
coste por persona integrada o el número de personas ¡integradas por cada
voluntario de la organización. Éstos, también son indicadores del beneficio de la
empresa.
1.4 El factor riesgo y las contingencias
Lamentablemente, no toda actividad proyectual ha de conducir necesariamente al éxito

técnico, económico, comercial y estratégico del proyecto. El concepto de riesgo hace
referencia a los efectos imprevistos y a las contingencias que ponen en peligro la
consecución de los objetivos perseguidos. Todo proyecto conlleva riesgos de que algo
salga mal, que pueden ser de tipo técnico, temporal, econórnico, etc.
En la práctica, casi todos los proyectos sufren alteraciones. Un empleado que se pone
enfermo, una huelga, una materia prima en mal estado o la rotura de una herramienta
suponen contingencias para el proyecto, que ve cómo se incrementan los costes sin
aumentar los ingresos. En muchos casos, el incremento del coste se compensa en otras
actividades o se encaja en el margen del proyecto, y se asume sin mayores
consecuencias. En algunos casos, más de los que muchos quisieran, la aparición de
contingencias hace que el margen de un proyecto se torne negativo, bien porque los
costes exceden a los ingresos, bien porque, al no ser capaces de finalizar el proyecto,
no se consiguen ingresos.
Gestionar un proyecto supone tener en cuenta estas posibles alteraciones. Preverlas (en
la medida de lo humanamente posible), cuantificarlas, detectarlas cuanto antes y
corregir sus efectos ayuda a mantener controlado el alcance, coste y plazo del proyecto
y, por tanto, a minimizar el peligro de que el mismo se vea abocado (técnica o
económicamente) al fracaso^.
Llegados a este punto es conveniente distinguir entre el concepto de riesgo y el de

incertidumbre. Mientras que el riesgo supone conocer las probabilidades de que algo
suceda, la incertidumbre asume un desconocimiento total de dichas probabilidades^
Los riesgos, pues, se pueden evaluar, para adoptar medidas al respecto. Las
incertidumbres no son calculables (lo que no quiere decir que no pueda reservarse un
margen para atenuar el efecto de las mismas).
A modo de ejemplo, toda empresa dispone de información acerca de las jornadas

laborales perdidas a causa de bajas por enfermedad de su personal. Al organizar la
planificación temporal de un proyecto, la empresa puede calcular el riesgo de que
una
4
Cuando el riesgo previsible de un proyecto es superior al razonable, debe planificarse en
consecuencia. Supongamos un proyecto de muy alto riesgo técnico como, por ejemp lo, la
síntesis de un fármaco efectivo contra el cáncer. Plantear este proyecto como un proyecto
industrial clásico (necesidad de obtener beneficios mediante un resultado positivo, en plazo y a
coste limitados) aboca, necesariamente, al fracaso. Pero eso no quiere decir que no tenga
sentido. Es posible organizar un proyecto con un alcance más reducido, con ingresos inferiores
a los gastos (o nulos), o de investigación, que pueda desarrollarse adecuadamente.
5
Así, la rotura de un equipo informático o la enfermedad de un empleado concreto podrían
considerarse riesgos, mientras que el éxito comercial de un producto o una huelga general
podrían encuadrarse en la categoría de incertidumbres.
© RA-MA _______________ CAPÍTULO 1: INTRODUCCIÓN A LA DIRECCIÓN Y GESTIÓN DE PROYECTOS 11
actividad crítica se retrase por culpa de un empleado que se pone enfermo. Sin
embargo, no es posible valorar fácilmente la probabilidad de ocurrencia de una
contingencia que ni siquiera ha sido prevista, como por ejemplo, la quiebra de un
suministrador, que deja la producción detenida por falta de materia prima.
2. LAS FASES DE UN PROYECTO
Casi todos los proyectos industriales siguen las mismas pautas o fases en su ciclo de
vida. La figura 1.2 muestra la secuencia típica de actividades que tienen lugar a la hora
de realizar un determinado proyecto, desde la búsqueda del mismo hasta el cierre
contable, pasando por la preparación de la oferta y la ejecución de los trabajos.
Figura 1.2 Proceso de elaboración de un proyecto
En la figura 1.2 no se hace referencia alguna a la duración relativa de cada fase. En

general, la fase identificada como "realizar trabajos" suele ser la más extensa, en
tiempo o en esfuerzo, y es la que la gente identifica realmente como "proyecto".
En los siguientes apartados se describe el objeto de cada una de las fases referidas.
2.1 Detección de oportunidades
La fase de detección de oportunidades es, probablemente, la más comercial de todo

el proyecto. Consiste en detectar un hipotético futuro contrato investigando las
posibilidades a partir de anuncios o convocatorias (públicas o restringidas),
aprovechando la relación formal con el Cliente potencial o contactos informales, o
incluso, tratando de crear necesidades en el Cliente (convencerle de que se puede
realizar para él un trabajo que realmente necesita/.
La detección de oportunidades puede realizarse de muy diferentes maneras: contactos

comerciales, publicidad y autopromoción, convocatorias y concursos públicos y
privados o, incluso, la creación de una necesidad en el potencial Cliente.
La actividad comercial de búsqueda de oportunidades y preparación de ofertas debe

ser un proceso constante y recurrente en toda empresa. Tanto si la empresa es una
consultora en temas de ingeniería, como si se trata de una peluquería de caballeros, la
búsqueda de potencíales Clientes y las actividades comerciales (publicidad) han de ser
permanentes. Algunos grupos de trabajo, en especial los de pequeño tamaño,
interrumpen las actividades comerciales durante la ejecución de los proyectos que le
son adjudicados. Al terminar un proyecto, se reanudan de nuevo los contactos, pero el
equipo de trabajo permanece desocupado hasta que aparece un nuevo contrato.
Durante este período, de ingresos nulos, se siguen generando costes de personal e
infraestructuras, que perjudican el margen global de la empresa.
Pero no sólo basta con detectar que existe una oportunidad de negocio concreta. A
continuación es necesario evaluar si dicha actividad es viable con respecto a los
recursos del Cliente (su presupuesto), y compatible con nuestra experiencia previa en
ese campo y con la competencia en el sector. Esta evaluación, que culmina en una
decisión preliminar, no está basada aún en cifras numéricas de costes e ingresos, sino
más bien en factores generales y estratégicos tales como la afinidad del tema con los
intereses y la experiencia de la empresa, el orden de magnitud del precio del contrato,
etc.
Si la evaluación preliminar así lo aconseja, se procede a continuación a evaluar

detalladamente el coste de realización los trabajos, el precio de venta, el margen y el
beneficio esperado, la disponibilidad de recursos y los plazos temporales. Sobre esta
evaluación, ya sólidamente fundamentada, se toma la decisión final acerca de la
conveniencia o no de preparar una oferta. La preparación de la oferta exige tiempo y
6
Tampoco es raro que se creen nuevas empresas cuando se detecta una oportunidad de negocio
que lo justifique. La adjudicación de licencias administrativas para prestar un servicio o
explotar un recurso, la aparición de un Cliente con gran poder de compra o la identificación de
una necesidad (aún no satisfecha) común a varios Clientes son motivos suficientes para
plantearse la posibilidad de crear una nueva empresa.
recursos, y el coste es demasiado elevado como para presentar ofertas a contratos que
no se aspira a ganar.
Pero incluso aunque un proyecto en ciernes pueda resultar económicamente poco

interesante (desde el punto de vista del beneficio esperado), puede que aún se trate de
un proyecto de interés estratégico. Para evaluar el interés estratégico del potencial
contrato, es preciso analizar la conveniencia de ofertar (y arriesgarnos a ganar el
contrato) por el simple hecho de darnos a conocer al Cliente, o para adquirir (a
beneficio nulo o negativo) experiencia en el sector.
2.2 Preparación de la oferta
Una vez identificada una oportunidad de negocio, y evaluadas las posibilidades de la

empresa, es necesario mostrar al Cliente nuestro interés y capacidad para la correcta
ejecución de los trabajos. Para ello es necesario abordar la fase de oferta, en la cual se
prepara la documentación que le permite al Cliente juzgar la idoneidad del ofertante
para la realización de los trabajos, así como fijar el precio de los mismos.
Toda oferta incluye una parte técnica, una parte de gestión y una oferta económica. En
la parte técnica se describe el trabajo a realizar, tratando de justificar la capacidad para
hacerlo de manera correcta. En la parte de gestión se describen los recursos que se
utilizarán para ejecutar los trabajos involucrados, junto con la planificación temporal
de los mismos. Por último, en la oferta económica se indica el precio que el ofertante
pide por la ejecución del proyecto, y las demás condiciones (forma de pago, revisión
anual, etc.) que pudieran ser aplicables.
La oferta para un proyecto puede ser desde una mera conversación verbal, si el grado
de intimidad con el cliente es elevado, hasta (en contratos multimillonarios) un
documento de miles de páginas que describa, paso a paso, el trabajo que se espera
hacer7. Conviene evaluar correctamente el esfuerzo dedicado a la preparación de la
oferta, pues un esfuerzo excesivo provoca ineficiencias (excesos de costes), mientras
que un esfuerzo insuficiente pone en peligro la adjudicación del contrato.
En casi todas las ofertas, probablemente la oferta económica sea la de mayor

trascendencia. Esto no se debe a que el esfuerzo técnico o de gestión sea menos
importante, sino que, por lo general, la empresa conoce bien el entorno técnico en el
que se mueve, mientras que los resultados por los que se mide son claramente
económicos.
7
En la Historia persisten y persistirán gloriosas excepciones a este principio. Por ejemplo, no
es que el mecánico de mi coche tenga mucha intimidad conmigo, pero creo que nunca me hará
una oferta por escrito. Y creo que tampoco las mafias organizadas presentan ofertas de miles de
páginas, aunque el "contrato" sea de tipo millonario.
El aspecto más significativo de la oferta económica es el precio. Para calcular el

precio de venta es necesario calcular el coste del proyecto. Para ello es necesario
realizar la mejor estimación de los costes de personal (propio o subcontratado) y los
dedicados a material, equipo, viajes, etc. Cuanto mejor sea esta estimación, menor es
el riesgo de perder el contrato por exceso de precio, o de perder dinero al subestimar el
mismo.
El precio de venta se calcula añadiendo al coste del proyecto el beneficio

empresarial deseado. En general, dicho beneficio será tan alto como las
condiciones de mercado permitan, pudiendo llegar ú ser nulo o, incluso, negativo,
se considerase da tí
2.3 Presentación (o no) y adjudicación (o no)
Una vez realizada la oferta, corresponde ejercitar una nueva evaluación crítica de la
misma, donde se vuelva a analizar si dicha actividad es viable con respecto a los
recursos del Cliente (su presupuesto), y compatible con nuestra experiencia previa en
ese campo, y la competencia en el sector.
Tras dicho análisis, cuyo resultado es decisivo, llega el momento de tomar la tercera (y
última) decisión acerca de la conveniencia o no de presentar la oferta. Esta decisión se
toma en función de criterios tan dispares como el beneficio bruto esperado, el esfuerzo
técnico y humano que suponga la realización del proyecto, la compatibilidad con otros
proyectos en curso, la disponibilidad del personal y el equipo necesarios, el coste de
oportunidad de dedicar nuestros recursos a ese (y no otro) proyecto, etc. Aunque
pueda parecer que esta decisión se basa en los mismos criterios que se utilizaron para
tomar la decisión de preparar la oferta, lo cierto es que en el período que media entre
la decisión de prepararla y la de presentarla suelen ocurrir muchas cosas: se establecen
alianzas corporativas, se identifican problemas técnicos o económicos y, en definitiva,
se logra un conocimiento del trabajo a realizar del que no se disponía tras la
evaluación inicial, y que puede hacernos reconsiderar nuestra idea original.
Pero llegados a este punto ya se han invertido suficientes recursos y esfuerzos como
para tirarlo todo por la borda y no presentar la oferta, y rara vez se llega a ejecutar una
opción tan radical. Sin embargo, sí puede ser prudente ''retocar" los compromisos y las
contraprestaciones del documento a la luz de los resultados de esta evaluación crítica.
Sí, finalmente, se decide presentarle al Cliente la oferta elaborada, comienza de

inmediato la fase de seguimiento de la misma, poniendo a los responsables técnicos y
de gestión del equipo de trabajo a disposición del Cliente para cuantas dudas y
comentarios pudieran surgirle de la lectura de la propuesta.
© RA-MA _____________ CAPÍTULO I: INTRODUCCIÓN A LA DIRECCIÓN Y GESTIÓN DE PROYF.CTOS 15
A menudo, y especialmente si el contrato es de suficiente importancia, el Cliente

querrá mantener ciertas reuniones de negociación con los potenciales contratistas para
perfilar detalles de sus respectivas ofertas, o para tratar de completar lo mejor de una
oferta con aspectos positivos de las otras. Incluso, si existen varias propuestas de
calidad, cada una con aspectos positivos en un área o tema concreto, el Cliente puede
llegar a proponer "repartir" el trabajo entre varías empresas, obligando a la que sea
adjudicataria del contrato a subcontratar a una o varias de las empresas restantes para
que realicen las actividades concretas en las que sus ofertas eran superiores*.
La evaluación de la oferta por parte del Cliente puede dar lugar a tres tipos de
respuestas:
 Adjudicación del contrato. La adjudicación puede ser directa o puede

que requiera de un proceso de negociación entre el ofertante y el
Cliente para revisar detalles del alcance, el precio, el plazo u otras
condiciones.
 No adjudicación del contrato. La no adjudicación es, evidentemente,

el peor de los escenarios, ya que el esfuerzo y coste de preparación de
la oferta no conlleva, por lo general, restitución alguna.
 Revisión de la oferta, se solicita a los ofertantes que cambien

determinados aspectos de la misma e, incluso, se abre un nuevo
período para la presentación de nuevas propuestas o propuestas
corregidas.
2.4 Ejecución de los trabajos
Hay quien dice que lo peor de una oferta es ganarla. A menudo, en el documento de la
propuesta se enfatiza el espíritu constructivo y se maximiza el trabajo a realizar (o se
minimizan los costes), debido a la ilusión del equipo por ganar el contrato.
Cuando se gana el contrato, sin embargo, es el momento de dejar de "prometer" para

empezar a "hacer". Es en este punto cuando, a veces, se advierte un exceso de
voluntarismo, a veces temeridad, al preparar la oferta. Una planificación temporal
excesivamente apretada, un alcance demasiado extenso de los trabajos, o una
estimación voluntarista de los costes son algunos de los errores típicos que, cometidos
en la premura de la fase de oferta, salen a la luz tan pronto se ponen en marcha los
trabajos.
s
Esta opción, aunque permite que varias empresas (y no una sola) participen en el contrato,
rara vez gusta a los contratistas, que sienten cómo se ha sacado "lo mejor" de su oferta,
obligándoles a relacionarse y organizarse con otras empresas en un contexto proyectual muy
diferente al que inicialmente habían previsto (y considerado en su oferta).
Antes de ponerse, en cualquier caso, a ejecutar tareas, es conveniente repasar

cuidadosamente los objetivos, el contenido, la planificación y los recursos para
realizar los trabajos, y verificar que las condiciones en las que se preparó y presentó la
oferta se mantienen. Cualquier posible desviación (como por ejemplo, algún empleado
clave que ha abandonado la empresa, un acortamiento forzado de los plazos, una
ampliación del alcance, etc.) debe ser identificada y corregida (en la medida de lo
posible), antes de poner en marcha los trabajos.
Y desde el punto de vista de la gestión del proyecto, a partir de este momento

comienza la fase de ejecución propiamente dicha. Durante esta fase, las actividades
del responsable del proyecto se centrarán en tres puntos:
> Supervisar y analizar el desarrollo y el avance de los trabajos y corregir

las posibles desviaciones.
> Supervisar y analizar la evolución económica del proyecto y corregir las
posibles desviaciones.
> Actuar como punto intermedio entre el Cliente, el equipo de trabajo y la
Dirección de la empresa, facilitando la comunicación y optimizando los
flujos de información.
2.5 Cierre (y vuelta a empezar)
Cuando finalizan las actividades que forman parte del alcance de un proyecto, dicho
proyecto termina, llega a su fin. En ese momento se actualiza la información
intermedia del mismo, técnica y administrativa, y se procede al cierre contable del
proyecto.
Para poder cerrar un proyecto, es necesario que realmente se haya finalizado el mismo,
es decir:
Desde el punto de vista técnico, es preciso que todas las actividades se hayan
finalizado por completo. No es posible cerrar (correctamente) un proyecto si,
por ejemplo, queda pendiente un período de garantía, o el Cliente no ha
confirmado que es de su agrado y por tanto puede solicitar modificaciones.
Desde el punto de vista administrativo, es preciso asegurarse de que no se va

a incurrir en costes adicionales (facturas pendientes, material a reponer, etc.),
© RA-MA CAPITULO 1: INTRODUCCIÓN A LA DIRECCIÓN Y GESTIÓN DE PROYECTOS 17
y de que se han facturado todas las cantidades pertinentes al Cliente (aunque, desde el
punto de vista contable, no se hayan cobrado todavía).
Por supuesto, el cierre de un proyecto es el mejor momento para evaluar la adecuación

del equipo de trabajo para dichas actividades, proyectando el conocimiento y la
experiencia adquirida sobre las acciones comerciales encaminadas a obtener nuevos
proyectos.
3. EL PROYECTO EN LA EMPRESA
Y, a la vista de lo anterior, ¿cómo encaja la empresa dentro del proceso proyectual

descrito?
La empresa es, básicamente, el marco donde se ejecutan los proyectos. Como ya se ha

dicho, los proyectos son conjuntos de actividades concretas, de duración limitada. La
empresa es el repositorio donde están los recursos (materiales, humanos, financieros,
etc.) de los que los proyectos se nutren en su comienzo, y que devuelven a su fin.
3.1 Concepto de empresa
Aunque existen múltiples definiciones de empresa en la bibliografía, desde un punto

de vista simplista puede considerarse que:
Por sí solas, las empresas carecen de sentido, salvo que existan individuos que
consuman los resultados de la producción. Por tanto, las empresas producen, y los
individuos (clientes) consumen. De ahí la necesidad de que las empresas incurran en
importantes esfuerzos comerciales que les faciliten la obtención de una cuota de
mercado que garantice el consumo de lo que producen.
Tal y como funciona, en términos generales, el mercado, la empresa especializa

recursos que, de otro modo, no estarían disponibles para el proyecto. La empresa
anticipa el personal, los equipos y los recursos financieros para ejecutar el proyecto.
Dirige y organiza las operaciones, los procesos productivos y la estrategia global.
Mejora dichos procesos para incrementar su competitividad mediante la investigación y
el desarrollo. Pero, sobre todo, la empresa asume el riesgo inherente al proceso
productivo, ante evoluciones desfavorables de los negocios, tratando de compensar los
resultados desfavorables con otros más benignos, perpetuando la unidad de
] 8 DIRECCIÓN Y GKSTION DE PROYECTOS © RA-MA
producción. Las empresas, ante todo, tienen proyección indefinida en el tiempo,

mientras que los proyectos no.
Es muy frecuente que los individuos traten de asumir, en algún momento de su vida
profesional, el papel de empresa (y obtener para sí sus rendimientos económicos). Este
propósito, que es perfectamente loable y lícito, sólo es viable si el propio individuo es
capaz, también, de absorber las necesidades comunes del proceso productivo. Así, un
profesional independiente puede asumir perfectamente (por sí sólo, o en colaboración
con otros) la realización de un diseño técnico o artístico, la elaboración de un
programa informático, y mil proyectos diferentes más. En este caso, el incipiente
empresario así constituido tiene que absorber, además del trabajo técnico propiamente
dicho, las labores de dirección y planificación, las tareas administrativas y fiscales, la
obtención de la financiación necesaria, la provisión del espacio físico y las
herramientas (ordenador, teléfono, fax, etc.) que le sean precisas, la organización y
mantenimiento de las instalaciones, etc.
El problema de este tipo de organizaciones "embrionarias" es doble. Por un lado, el

profesional ha de desdoblar su actividad en tareas para las que está muy capacitado
(las técnicas, propiamente dichas), y en otras que, siendo necesarias, no son su
especialidad, y para las que en principio será menos eficiente. Por otro lado, es dudoso
que un Cliente decida contratar trabajos de gran volumen o duración a profesionales
individuales, prefiere contratarlos a empresas capaces de asumir un mayor riesgo,
económico y temporal (¿alguien se imagina a un profesional independiente asumiendo
la responsabilidad de diseñar y construir un prototipo de avión de transporte y, sobre
todo, adelantando y aportando los recursos materiales para ello?).
Se asiste, por lo general, a una lenta transformación del profesional individual en

empresa, que se origina cuando recaba ayuda para las tareas más administrativas (por
lo general, contabilidad y fiscalidad), y termina contratando un equipo de personas que
le asista en tareas, tanto administrativas como técnicas.
3.2 Organización de la empresa
Una empresa es algo más que un conjunto de bienes y recursos. De la definición

informal de empresa del apartado anterior se desprende una característica que aporta
valor añadido a la mera agrupación de recursos materiales y humanos: la organización.
La organización de empresas busca la ordenación (funcional y operativa, temporal y

económica) de los recursos humanos y materiales que optimiza la consecución de los
objetivos perseguidos, bien sean de tipo tangible (beneficios), o de tipo intangible
(prestigio, mercado, etc.).
PRA-MA ________ CAPITULO i: INTRODUCCIÓN A LA DIRECCIÓN Y OHSTION DE PROYECTOS 19
En una empresa, la organización define las relaciones entre los elementos que la
componen y, en consecuencia, la utilidad de los mismos para los fines productivos. La
organización diferencia la competitividad de unas empresas frente a otras. Dos
empresas en competencia pueden disponer de recursos materiales y humanos
similares, y una de ellas puede ser mucho más competitiva (y lograr mejores
resultados) gracias a una organización más adecuada de los recursos.
Todas las empresas, desde las artesanales hasta las más burocráticas, siguen un
determinado modelo de organización. La representación gráfica de las relaciones que
dicho modelo implica recibe el nombre de organigrama. La figura 1.3 muestra un
ejemplo de organigrama.
Figura 1.3 Ejemplo de organigrama
En el organigrama, cada caja representa un área funcional (en términos coloquiales, un

puesto de trabajo o una responsabilidad concreta). Las líneas verticales implican una
relación jerárquica, mientras que las horizontales representan una relación de
asesoramiento o colaboración al mismo nivel. Por último, las líneas punteadas
muestran una relación de dependencia, que coexiste con la jerarquía básica de la
organización (por ejemplo, un ingeniero puede depender del jefe de ingeniería, desde
el punto de vista funcional, pero estar subordinado al director de proyecto, en las
actividades que afecten a dicho proyecto).
20 D1RRCCION Y GESTIÓN DE PROYECTOS
3.3 Vinculación proyecto-empresa
La importancia del organigrama va mucho más allá de la identificación de las

responsabilidades en la empresa. La organización empresarial, por lo general, define
una cultura corporativa, y condiciona en gran medida la ejecución de los proyectos,
hasta el punto de que, a partir de un simple vistazo al organigrama de la empresa, es
casi posible identificar el tipo de proyectos que realiza.
Las empresas cuya actividad está menos orientada a proyectos presentan, por lo
general, organigramas típicamente funcionales, como el que se muestra en la figura
1.4. Este tipo de organizaciones son claramente jerárquicas, y cada empleado tiene un
superior o una cadena de mando perfectamente identificada.
Figura 1.4 Organización funcional
En los organigramas funcionales los empleados se agrupan teniendo en cuenta su

especialidad (administración, marketing, ingeniería, producción, etc.). Cuando el área
funcional es demasiado amplia como para que dependa de un mismo responsable, se
divide, a su vez, en sub-áreas más especializadas.
Las organizaciones funcionales también pueden ejecutar proyectos, pero la

organización de los mismos se complica en gran medida, salvo que la totalidad del
proyecto pueda ejecutarse dentro de la misma área o sub-área funcional.
El extremo opuesto a una organización funcional es la organización proyectual

(representada en la figura 1.5) que, como su propio nombre indica, está claramente
CAPITULO 1: INTRODUCCIÓN A LA DIRECCIÓN Y GESTIÓN DE PROYECTOS 21
orientada a la ejecución de proyectos como actividad principal de la empresa. En la organización

proyectual, la responsabilidad de mayor nivel recae sobre los directores de proyecto, a los que se
asigna el personal necesario para la realización de los trabajos pertinentes.
Figura 1.5 Organización proyectual
Sin embargo, la organización proyectual no carece de inconvenientes. Si los proyectos durasen

indefinidamente, y cada trabajador sólo participase en un único proyecto a la vez, la organización
por proyectos cumpliría correctamente con su papel. Sin embargo, la temporalidad de los
proyectos es una definición inherente a los mismos. Los proyectos comienzan y se terminan, las
personas pasan de unos proyectos a otros, y hay temporadas en las que participan en más de un
proyecto a la vez, o que no trabajan en ninguno, creándose asignaciones múltiples, o "bolsas" de
empleados no asignados.
Para corregir estas deficiencias, por lo general las empresas organizan sus recursos mediante
modelos intermedios, de tipo matricial. Las organizaciones matriciales se representan en dos (o
más) dimensiones. Tal y como se muestra en la figura 1.6, una de las dimensiones agrupa (como
en la estructura funcional) a los empleados de acuerdo con su especialidad. La otra dimensión, de
carácter proyectual, incluye a los directores de proyecto.
Figura 1.6 Organización matricial
Cuando la empresa inicia un nuevo proyecto, designa un director responsable del

mismo, y se selecciona un conjunto de empleados que participarán en los trabajos, y
que pueden pertenecer a varias áreas funcionales. Cuando el proyecto termina, dichos
empleados "se devuelven" a sus áreas, y quedan disponibles para un nuevo proyecto.
Por supuesto, un mismo director de proyecto puede responsabilizarse de más de un
proyecto a la vez, al igual que un empleado puede participar en más de un proyecto de
manera simultánea.
4. GESTIÓN Y DIRECCIÓN
Llegados a este punto, parece el momento de definir, con mayor rigor, lo que se
entiende por gestión de un proyecto.
M gestión de proyectos es el conjunto de actividades encaminadas a ordenar,

íisponer y organizar los recursos y (as necesidades" para completar con éxito un
En la definición anterior, el término "éxito" alude al cumplimiento, principalmente, de

los objetivos técnicos, económicos, de planificación y de calidad del proyecto y sus
resultados.
'ORA-MA _____________ CAPITULO 1: INTRODUCCIÓN A LA DIRECCIÓN Y GESTIOT-J DE PROYbCI OS 23
Como no podría ser de otra manera, las actividades de gestión abarcan todos los
ámbitos del proyecto, desde las actuaciones puramente técnicas, hasta las más
comerciales, incluyendo también las tareas administrativas, contables o, incluso,
financieras. En particular, la gestión de un proyecto completo puede dividirse en la
gestión de sub-áreas, en términos de:
•" Gestión del alcance y contenido. Abarca las actividades orientadas a

garantizar que se satisfagan todas las tareas necesarias, y sólo las necesarias, para
completar el proyecto, incluyendo la identificación del alcance completo, la
verificación de su cumplimiento, y la gestión de los cambios que puedan producirse
durante los trabajos.
^ Gestión técnica. Incluye las actividades necesarias para garantizar que el

resultado del proyecto satisfaga los requisitos y necesidades planteadas por el
Cliente, y las organiza y resuelve de manera adecuada y eficiente.
®° Gestión de recursos temporales (planificación). Comprende las actividades

necesarias para asegurar que el proyecto se ejecuta en el plazo previsto y los
resultados están a disposición del cliente en la fecha comprometida. Se
incluyen en este apartado la identificación de las actividades proyectuales, la
estimación de su duración, su secuenciamiento, la supervisión de la ejecución en
tiempo, y la corrección de las desviaciones.
T Gestión de costes. Trata de los procesos orientados a asegurar que los trabajos se
llevan a cabo dentro de los límites económicos impuestos al proyecto, e incluye
las actividades de planificación de recursos, estimación de costes y control de
costes y gastos.
*" Gestión de la calidad. La gestión de la calidad comprende las actividades

orientadas a asegurar que el proyecto satisface los requisitos bajo los que se
contrató, e incluye la elaboración de un plan de calidad, su aplicación y
seguimiento.
*" Gestión de los recursos humanos. Incluye las actividades orientadas a hacer un
uso lo más eficiente posible de las personas que participan en el proyecto,
incluyendo la organización jerárquica y funcional del mismo, la selección del
equipo de trabajo, la asignación de responsabilidades y la supervisión del grupo.
A diferencia de la actividad de dirección, la gestión de recursos humanos no
comprende las actividades propias del "liderazgo", tales como la motivación, la
¡nterrelación, etc.
*" Gestión de la comunicación. Este concepto, a menudo minusvalorado en las

organizaciones, tiene como objeto garantizar que la información del proyecto,
formal e informal, se genera, recopila, almacena, disemina y utiliza de forma
adecuada en volumen y tiempo.
**" Gestión de riesgos. La gestión de riesgos identifica, analiza y cuantifíca los

riesgos propios de un proyecto (véase el apartado J.4), y anticipa mecanismos
de corrección de los potenciales efectos negativos asociados a los mismos.
IS
~ Gestión de compras, adquisiciones y subcontratos. En proyectos de cierto
tamaño, se hace necesario un conjunto de procesos orientados a la correcta
definición y obtención de bienes y servicios procedentes de fuera de la
empresa. La gestión de compras, adquisiciones y subcontratos se encarga,
pues, de las actividades orientadas a la planificación de compras, la
especificación de los bienes o servicios a adquirir, la solicitud y la selección
de ofertas, la compra (propiamente dicha) y el seguimiento administrativo de
las mismas.
Por supuesto, en proyectos simples, o de pequeño tamaño, a menudo la gestión se

realiza como un todo, sin diferenciar entre las áreas anteriormente identificadas. Por el
contrario, en los proyectos de gran tamaño, o donde la complejidad y diversidad así lo
recomiendan, es frecuente organizar los mismos con un director de proyecto, del que
dependen diferentes responsables de gestión de actividades, de costes, de compras, etc.
4.1 Dirección, gestión, administración y participación
A menudo se confunden los términos gestión y dirección de proyectos, tal vez por la
costumbre de traducir en ambos sentidos el término anglosajón project management.
En general, el concepto "dirección de proyectos" es más ambicioso que el de gestión.

La dirección de un proyecto implica actividades de mayor responsabilidad, que
requieren más experiencia y capacitación, tales como la selección y motivación de
equipos de trabajo, el liderazgo, la toma de decisiones estratégicas, y, en general, otras
actividades de índole más humana y cultural que la mera gestión de recursos. Así,
dentro de la dirección de un proyecto pueden considerarse incluidas las actividades
orientadas a:
Perseguir un gran fin que mejore la posición competitiva de la empresa.

Establecer relaciones, internas y externas que favorezcan que la
empresa sobreviva en el tiempo al proyecto (consiguiendo nuevos
proyectos).
Dirigir a las personas reforzando su sentido de la responsabilidad
y satisfaciendo sus necesidades y ambiciones individuales.
Dirigir a los grupos de trabajo reforzando el sentimiento de cohesión y el
> sentido "de grupo".
Fomentar la imaginación, la creatividad y la originalidad, a la par que la
sensación de utilidad, a la hora de plantear soluciones y asumir riesgos.
ORA-MA _____________ CAPÍTULO 1: INTRODUCCIÓN A LA DIRECCIÓN Y GESTIÓN DK PROYECTOS 25
> Crear y mantener un flujo de información, formal e informal, que

favorezca su intercambio y la sensación de participación en el grupo.
> Desarrollar esquemas de poder personal y de delegación de
responsabilidad.
Por otra parte, la administración de proyectos se limita a la aplicación de técnicas y

herramientas numéricas para planificar y organizar la utilización y consumo de
recursos en un proyecto. Es la actividad más puramente "contable" de las descritas y,
por lo general, está bastante alejada del contenido técnico de los trabajos.
Sin embargo, no todas las organizaciones y empresas comprenden suficientemente

bien las diferencias entre administración, gestión y dirección, y los buenos gestores de
proyectos se transforman, antes o después, en directores de proyectos (buenos o
malos), tal vez sin la necesaria "cancha" humana para ello. Por último, el peor error es
transformar a un buen administrador en director de proyectos, pues su lejanía de los
aspectos técnicos del trabajo difícilmente le permitirá controlar adecuadamente la
evolución (y los problemas) del proyecto.
Figura 1.7 La labor del Director de Proyecto
Así pues, ¿cuál es la razón de la confusión, casi general, entre los términos de
dirección, gestión y administración de proyectos? Probablemente, el origen deba
asociarse al hecho de que en la mayoría de las empresas las funciones de dirección, las
de gestión y las de administración recaen (para cada proyecto) sobre una misma
persona: el director de proyecto (ver figura 1.7). Por lo general, sólo en las empresas
especializadas en dirección y gestión de proyectos (que disponen de "cuerpos" de
personal específico para cada función) o en proyectos de gran volumen suele
distinguirse entre las tres figuras mencionadas.
Este libro, tal y como se desprende del título, es un manual de dirección y gestión de
proyecto pues en él se muestran técnicas y herramientas que ayudan a dirigir, a
organizar y a gestionar las actividades proyectuales. La razón de un enfoque tan
amplio reside en la imposibilidad real de abordar la gestión integral^ de proyectos, que
incorpora aspectos técnicos (alcance), temporales (planificación) y económicos
(costes), sin introducir conceptos y tácticas más propias de la responsabilidad de un
director de proyecto que de un mero gestor. Sin embargo, también es cierto que la
faceta específica asociada a la labor de dirección requiere una cierta dosis de
experiencia que no se logra mediante la lectura de textos, más o menos afortunados.
4.2 Gestión estratégica, administrativa y operativa
Desde el punto de vista del alcance y la trascendencia de los actos y decisiones que se
tomen dentro del ámbito de un proyecto, cabe destacar los siguientes niveles de
importancia:
<*" La gestión operativa es el nivel más bajo de importancia en relación a la

trascendencia del acto o decisión. Su alcance temporal es a muy corto plazo, y
est¿ muy cercana al ámbito técnico (más práctico) del proyecto. Es la que
permite ejecutar el trabajo día a día. Cualquier miembro del equipo de trabajo
puede adoptar decisiones operativas.
Son ejemplos de actos o decisiones operativas la elección de materiales o

componentes de entre los habituales, la convocatoria de reuniones internas
informales, o el intercambio de información técnica.
«" La gestión táctica (o administrativa) involucra los actos o decisiones de

trascendencia a corto y medio plazo que pactan a la planificación de recursos
y a la corrección de las desviaciones detectadas. Estas decisiones las toma el
director de proyecto, quien puede delegarlas en los responsables adecuados
(incluido el gestor del proyecto).
La convocatoria de reuniones con el Cliente, internas o de carácter formal, la

reasignación de tareas a los miembros del equipo de trabajo o las decisiones
trascendentes acerca del modo de realizar los trabajos son ejemplos de actos o
decisiones de tipo táctico.
y
Con el término "gestión integral" se describe el conjunto de sub-áreas de gestión enunciadas
en el apartado 4. Sin embargo, la literatura especializada está haciendo uso de este término
(incorrecto, ajuicio del autor) para denotar las actividades de gestión de programas o, dicho de
otra manera, la "gestión de la gestión" de varios proyectos a la vez.
ORA-MA CAPÍTULO 1: INTRODUCCIÓN A LA DIRECCIÓN Y GESTIÓN DE PROYECTOS 27
*" La gestión estratégica, por último, implica actos o decisiones que afectan a la
supervivencia del proyecto y de los proyectos que de él dependan. Son las más
complejas, pues suelen requerir información externa al propio proyecto, y
desencadenan un cúmulo de acciones tácticas y operativas. Estas actuaciones,
que tienen implicaciones a largo plazo, las toma únicamente el director de
proyecto.
Como ejemplos de actuaciones de tipo estratégico pueden citarse la elección

del tipo de cliente o área tecnológica, la negociación del precio o el alcance
del proyecto, la suspensión de los trabajos, o el no cumplimiento de algunos
de los requisitos del proyecto.
La figura 1.8 muestra una representación gráfica de la ordenación descrita para los
niveles de decisión y responsabilidad en una empresa típica.
Figura 1.8 Pirámide de decisión en la empresa
4.3 El encanto de la gestión
A la vista de lo anterior, puede extraerse la conclusión de que la correcta dirección y

gestión de un proyecto es una tarea compleja, no siempre formalizada, que tiene tanto
de arte como de técnica. Tal vez por esta razón, la gestión no siempre resulta atractiva
para los profesionales más técnicos (en campos ajenos a la misma), especialmente si
son jóvenes y no tienen muchos años de experiencia.
Lo más habitual es que la vida de un profesional cualificado comience (si el mercado

laboral lo permite) con actividades técnicas o comerciales, y sólo con el tiempo se
aborda la administración, la gestión y la dirección de los proyectos en los que se
participa. Gloriosa excepción a lo anterior la constituyen los profesionales autónomos,
que se ven obligados a gestionar sus propios recursos por sí mismos. Incluso en estos
casos las actividades de gestión sufren un cierto "rechazo", que desaparece con el
tiempo, la experiencia, la saturación técnica y las ganas de hacer "cosas nuevas".
Si se pregunta a profesionales involucrados en actividades de gestión, las razones
esgrimidas con mayor frecuencia pueden ser similares a las mostradas en la figura 1.9".
Por apetencia
personal
14 %
Figura 1.9 Razones para dar el salto a actividades de dirección y

gestión
Si, por el contrario, se pregunta a aquellos que, teniendo oportunidad de dirigir y

gestionar trabajos, mantienen su dedicación a las labores técnicas o comerciales,
pueden obtenerse" razones del tipo de las mostradas en la figura 1.10.
Figura 1.10 Razones para no dar el salto a actividades de dirección y

gestión
!
" Hace algún tiempo me dediqué a encuestar, informalmente, a directores y gestores de
proyectos (más o menos profesionales) de una empresa de ingeniería, las razones por las que se
dedicaban a dichas tareas, y no a otras de tipo más técnico. Tras un filtro destinado a eliminar o
matizar respuestas del tipo "soy un elegido'" o "alguien tiene que hacerlo", se obtuvieron estos
resultados.
Y se obtuvieron.
5. CAOS CONSULTING S.A., UNA EMPRESA MODELO
Indiscutiblemente, la empresa determina en gran medida la viabilidad y el desarrollo

de un proyecto. El tipo de proyectos atractivos para un grupo de profesionales
liberales no es el preferido por una multinacional de gran tamaño.
La organización de la empresa, su tamaño, su idiosincrasia y, en general, el carácter de

sus gentes, define qué tipo de mercados son más atractivos para la organización, y que
proyectos son más adecuados para la misma.
A lo largo de este libro vamos a utilizar un modelo de empresa ficticia, Caos

Consulting S.A., cuya dimensión, organización y características se utilizan para
aplicar y evaluar los diferentes conceptos y razonamientos enunciados en el texto.
5.1 Características generales de la empresa
La empresa CAOS Consulting S.A., con domicilio social en Colmenar Viejo

(Madrid), se dedica a labores de ingeniería informática y de telecomunicaciones, e
incluye soporte de consultoría, estudios y proyectos.
La cartera de clientes de CAOS Consulting está conformada, en su mayoría, por otras

pequeñas y medianas empresas de diversos sectores, así como por diferentes órganos
de las Administraciones locales, autonómicas y central.
CAOS Consulting cuenta con 58 empleados, todos ellos ubicados en sus oficinas
situadas en el kilómetro 32 de la carretera de Colmenar Viejo. La estructura
simplificada de la empresa es la que se muestra en la figura 1.11.
El Director General de la empresa es el Sr. Jaime Lonar, de quien depende

directamente la Jefa de la Sección de Ingeniería, Sra. Sandra Mática. En la sección de
ingeniería hay, aparte de la Sra. Mática, 43 personas, asignadas a 4 sub-secciones
distintas (hardware, software, telecomunicaciones y fabricación).
Cada vez que Caos Consulting obtiene un contrato, se organiza un nuevo proyecto. En
función del tipo de proyecto, su responsabilidad recae en una de las cuatro sub-
secciones de ingeniería. El responsable de la sub-sección correspondiente elige un
Director de Proyecto que, durante la vida de dicho proyecto, se responsabiliza técnica
y económicamente del mismo. El Director de Proyecto designado, a su vez, elige los
participantes en el mismo de entre el personal (que esté disponible) de cualquiera de
las secciones de la empresa.
Figura 1.11 Organigrama simplificado de Caos Consulting
5.2 Costes laborales
Para estimar y asignar costes, Caos Consulting divide a sus empleados en seis
categorías distintas:
Directivos (DI): son, aparte del Director General, el responsable de Recursos

Humanos y los Jefes de las Secciones de Ingeniería y Administración. El
sueldo medio anual de un Directivo de Caos es de 105.000 € brutos.
Consultores (CO): son profesionales de reconocido prestigio y probada

experiencia en cada una de sus disciplinas que hacen de expertos para los
proyectos en los que participan. Caos cuenta con cuatro consultores, tres de
ellos asignados a la sección de ingeniería y uno en Servicios Auxiliares. El
sueldo medio anual de los consultores es de 65.000 €.
Ingenieros Sénior (IS): se encuadran en esta categoría todos los responsables

de una sub-sección, así como el personal con más de cinco años de experiencia
laboral. Su sueldo medio anual es, en Caos Consulting, de 46.000 €. Por lo
general, todos los Directores de Proyecto son ingenieros sénior.
cRA-MA _____________ CAPITULO I: INTRODUCCIÓN A LA DIRECCIÓN Y GESTIÓN DE PROYECIOS 31
*" Ingenieros Júnior (IJ): son los titulados superiores cuya experiencia es
inferior a los cinco años. Su sueldo medio es de 28.000 € al año.
^ Técnicos (TE): corresponde esta categoría a los ingenieros técnicos,

delineantes, estudiantes y becarios en prácticas. Su sueldo medio es de 23.000 €
anuales.
*" Personal auxiliar (PA): esta categoría está formada por secretarias,
administrativos, ordenanzas, etc. Su sueldo medio anual es de 14.000 €.
Cada empleado le supone a Caos un determinado coste laboral, que es el coste en el

que incurre la empresa por la utilización del factor trabajo. Los costes laborales
agrupan seis conceptos:
 Los sueldos y salarios, que incluyen nóminas, retribuciones en especie y

aportaciones a planes de pensiones.
 Las cotizaciones obligatorias a los sistemas de Seguridad Social.
 Las cotizaciones voluntarias, tales como seguros de enfermedad,

de asistencia médica, etc.
 Las prestaciones sociales directas, que incluyen incapacidad

temporal, desempleo o jubilación.
 Las indemnizaciones por despido.
 Otros gastos (sociales, transporte, comedores, formación, etc.).
De los costes laborales, variando mucho en función de la empresa y del nivel y escala
retributiva del trabajador, dice el Instituto Nacional de Estadística'2 que en torno a un
75% se corresponde con el sueldo bruto del empleado, y aproximadamente el 25% con
las cargas sociales y otros costes.
En el caso de Caos Consulting, la empresa calcula el coste asociado a cada empleado

sumando a los sueldos medios de la categoría a la que pertenece un 33,3% (resultado
de dividir el 25% de las cargas entre el 75% del sueldo bruto), correspondiente a las
cargas sociales anteriormente mencionadas (Seguridad Social, desempleo, formación,
12
Fuente, Boletín Mensual de Estadística del INE. Datos correspondientes al último trimestre
de 2003.
etc.)/J, y dividiendo entre el número de horas de trabajo anuales7'' (en torno a 1.750).
Se obtiene así el coste laboral medio por hora facturable, que queda reflejado para
cada categoría en la siguiente tabla:
COSTES MEDIOS POR HORA TRABAJADA Y CATEGORÍA

(en Euros)
CATEGORÍA SUELDO BRUTO COSTES COSTE POR
• - -ANUAL . - ; • ..: "SOCIALES . HORA
DI (4 personas) 105.000 34.965 79,98
CO (4 personas) 65.000 21.645 49,51
IS (11 personas) 46.000 15.318 35,04
IJ (19 personas) 28.000 9.324 21,33
TE (14 personas) 23.000 7.659 17,52
PA (6 personas) 14.000 4.662 10,66
La nómina global de Caos Consulting {incluyendo cargas sociales) asciende, pues, a

2.831.292 € anuales.
5.3 Costes generales
De los 58 empleados de Caos sólo el personal de la sección de ingeniería participa

directamente en los proyectos (y factura a los clientes). Las 14 personas restantes, de
Dirección General, Recursos Humanos, Administración, Comercial y Servicios
Auxiliares, se consideran costes generales. Los costes laborales de estas personas (3
directivos, 1 consultor, 4 ingenieros sénior, 4 júnior y dos empleados auxiliares)
ascienden a 938.432 € anuales.
Los costes de alquiler de inmueble, luz, agua, teléfono, tasas y otros varios (correos,
costes financieros, formación del personal, etc.) suponen un desembolso de otros
360.000 € al año.
La suma de todos los costes generales, 1.298.432 € anuales, representa algo menos del
69 % de los costes del personal de ingeniería (el que se "factura" al cliente), por lo que
antes de vender una hora de trabajo, los costes horarios expresados en la tabla anterior
deben multiplicarse por el coeficiente de gastos generales, o sea, por 1,69.
13
En realidad, este porcentaje no es aplicable a todos los niveles salariales. Por ejemplo, las
cotizaciones a los sistemas de Seguridad Social tienen topes máximos, asociados a la máxima
cobertura (pensión) que se puede percibir del Estado, con independencia del sueldo percibido.
Así, los costes sociales de un directivo serían mayores en valor absoluto que los de un técnico,
pero inferiores en valor porcentual. No obstante, en este ejercicio se han considerado que todos
ellos se calculan como el 33,3% del sueldo bruto, para compensar el desequilibrio entre
prestaciones de la empresa (sociedades médicas privadas, seguros o planes de pensiones),
complementarias al sueldo bruto, que son también distintas para cada categoría profesional.
u
Fuente, Encuesta sobre el Tiempo de Trabajo en España 2000, último estudio al respecto
publicado por el INE.
©RA-MA _____________ CAIMTULO 1: INTRODUCCIÓN A LA DIRECCIÓN Y GESTIÓN DE PROYECTOS 33
5.4 Otros costes
Además de lo anterior, cada vez que Caos Consulting factura una hora de trabajo de su
personal, ha de imputar otros costes asociados a dos partidas adicionales: el sistema
informático de la empresa y los consumibles.
Los costes informáticos incluyen la adquisición, instalación y mantenimiento de la

red de área local, ordenadores y periféricos de la empresa, así como las herramientas y
aplicaciones informáticas utilizadas con carácter general'5. Se estima que el coste total
por año oscila en torno a 180.000 €, que, repartidos entre las horas de trabajo de los
empleados de ingeniería, implican añadir a cada hora facturada un coste adicional de
2,34 €.
Los costes de consumibles incluyen la adquisición y alquiler de elementos de

consumo habitual en la empresa, además de material de oficina, discos y cintas de
ordenador, recargas de tinta para impresoras y gastos de reprografia (impresión,
reproducción y encuademación de planos, memoria, trabajos, etc.), y se estiman en
torno a 0,75 € por hora facturable. Este valor, sin embargo, depende en gran medida
del tipo de proyecto, de la cantidad y clase de consumibles utilizados, y del número y
complejidad de documentos, planos, etc. a realizar, por lo que el valor de 0,75 €/hora
se utiliza para estimar el coste, pero a posteriori se imputa al proyecto solamente los
costes en los que realmente se incurre.
Por último, a la hora de estimar el coste de un proyecto, se incluyen también otros

gastos adicionales que se prevean necesarios (tales como suministros de materiales y
equipos, dietas, viajes, compra de herramientas o útiles, etc.).
5.5 Margen comercial de Caos Consulting
Caos Consulting no es una organización no gubernamental (ONG), ni una institución

benéfica. Sus propietarios (pequeños accionistas, entre los que cabe incluir a alguno de
los trabajadores de mayor categoría, que poseen un pequeño porcentaje de las
acciones) pretenden obtener un beneficio (como recompensa por la inversión
económica) de la empresa. Al precio por hora resultante de multiplicar el valor del
coste por hora por el coeficiente 1.69, al que se suman los costes de equipos
informáticos, de consumibles y otros varios, se le añade un porcentaje de beneficio
que justifique el riesgo y el esfuerzo de los accionistas. En general, el Consejo de
Administración de Caos Consulting pretende obtener un margen''5 medio (para todos
los proyectos de un año) que ronde el 20%.
15
Las herramientas y aplicaciones que se adquieren específicamente para un proyecto se
imputan contablemente al mismo, y no se repercuten sobre los costes generales.
Recuérdese que, tal y como se ha expuesto en el Capítulo 1, el beneficio del proyecto se
calculará restando al margen obtenido el coste de oportunidad en ese momento. No es de
5.6 Facturación de Caos Consulting
El pasado año la empresa facturó alrededor de 12,4 millones de Euros, antes de

impuestos, de los cuales 6,2 millones se gastaron en suministros (material y equipos),
subcontratos, viajes y estancias. También se gastaron 2,83 millones en nóminas, y
360.000 € más en costes generales. Por último, se gastaron 180.000 € en equipos
informáticos y su mantenimiento, y casi otros 58.000 en consumibles. El margen
global puede calcularse como la diferencia entre ingresos y gastos, referida al total de
facturación, como sigue (todos los valores expresados en miles de Euros, o sea, K€):
12.400-6.200-2.831-360-180-58
= 0,223
12.400
O, lo que es equivalente, aproximadamente un 22,3 % de la facturación global de la

empresa.
Con tipos de interés de mercado inferiores al 4%, la Dirección de Caos entiende que el
beneficio obtenido es razonable, si bien pretenden incrementarlo a medio plazo.
El sutil encanto de la negociación esta presente,- día a día y a cada instante, en

nuestras vidas. Tenemos que negociar la hora de vuelta a casa con nuestros
padres cuando somos pequeños. Negociamos qué película vemos o al sitio al
que vamos con los amigos,, las condiciones de nuestro préstamo hipotecario con
el banco o el sueldo con nuestra jefe. Negociamos lambién el destino en
vacaciones con la familia o, si somos eí presidente de una multinacional, el
futuro de miles de puestos de trabajo con los sindicatos.
extrañar, pues, que las empresas revisen periódicamente los márgenes a aplicar en función del
estado general de la economía.
17
La idea de escribir este texto me vino a la cabeza durante un larguísimo viaje París-Madrid, a
las tantas de la noche y después de pasar muchas horas en el aeropuerto, leyendo el libro
Getting to Yes. Negotiating agreement without giving in, de R. Fisher, W. Uri y B. Patton
(Penguin Book). Había sido un día de frustrantes intentos de negociar aspectos técnicos de un
proyecto espacial multinacional, y sin resultado aparente. Aunque el libro (y este apéndice) no
presenten "recetas mágicas", "ideas felices" ni "soluciones universales", a veces uno siente que
material de este tipo debería repartirse (gratuitamente, claro, y con "dibujitos") antes de dichas
reuniones, entre los participantes. Mi agradecimiento a los autores por hacerme sonreír al final
de esa tediosa jornada.
CAPÍTULO I: INTRODUCCIÓN A LA DIRECCIÓN Y GESTIÓN DH PROYECTOS 35
Como profesionales, a menudo nos vemos obligados a negociar dentro del

entorno de nuestro trabajo. Negociamos aspectos "técnicos tales como
especificaciones, interfaces, etc. Negociamos costes de materiales y recursos
para ejecutar el trabajo y, por qué no, aspectos contractuales, condiciones de
ejecución (plazos, lugares), salarios y pluses, etc.
Y sí la negociación está implícita en casi todas las actividades cotidianas, ¿no

parece razonable enfrentarse a elía con ideas claras y estructuradas, y actitudes
abiertas y positivas?
Con independencia de la importancia de la decisión a tomar o de su

trascendencia, en toda negociación se utilizan tácticas similares. Todas ellas van
encaminadas a la consecución del mayor número posible de objetivos, aun
cuando se parta a veces* .<fo situaciones de manifiesta debilidad, con
interlocutores irritables, prepotentes, ofuscados o agresivos, de diferentes países
y culturas, o con intereses ocultos e, incluso, ilegítimos.
El buen negociador es aquel que obtiene, lo que quiere, pero sin "arrasar" con
todo, es decir, sirt quemar al interlocutor de forma que se eliminen futuras
posibles negociaciones.
Culturas de negociación
Básicamente, hay dos culturas de negociación:
■ La táctica amigable propugna una buena relación humana.

■ La táctica agresiva promueve la competitividad y un constante estado de
tensión.
■ La táctica amigable fomenta un clima de negociación agradable,
generalmente a costa de transigir y ceder en más puntos de tos
estrictamente necesarios, y está especialmente indicada cuando la
negociación actual no es lo más trascendente de la relación (por ejemplo,
existen vínculos de amistad o familiaridad), o cuando se persigue mejorar
nuestra postura para futuras ocasiones. La segunda táctica (agresiva) suele
obtener mejores resultados" a corto plazo, pero genera tensiones
innecesarias que suelen provocar rupturas y eliminar oportunidades
futuras.
Los expertos coinciden en que k> mejor es un punto medio entre ambas
posturas, localizado en función del interlocutor y de la importancia deJ motivo
de negociadón /íf. También recomiendan olvidar ios aspectos personales y
La literatura negra se ha servido de una combinación de ambas posturas de negociación,

consistente en que dos personas del mismo equipo se reparten los papeles de negociador
amigable y negociador agresivo, formándose el conocido equipo "poli bueno, poli malo", que
obtiene sorprendentes resultados en algunas ocasiones.
concentrarse en el problema, así como negociar en grupos reducidos

[idealmente de dos personas), donde las posturas puedan quedar claras y ni
asta el peligro de dispersarse en exceso.
Negociación basada en objetivos
A menudo es frecuente que los interlocutores se concentren en

puntuales, de poca importancia, tratando de llevar al contrario a su terreí
"ganar" esa parcela de la. negaciación, y perdiendo el punto de vista global
misma. Esta actitud suele conducir a posturas intransigentes, donde existe
pocas "piezas a intercambiar", que acaban en acuerdos poco satisfactorios p¿
todos. . - . . -
Al igual que en una partida de ajédíez, eñ general es preferible concento los

objetivos globales de la negociación (jaque mate), asumiendo que se ce< y
ganará terreno en los distintos aspectos concretos (peones, alfiles, etc.)- Así,
estamos negociando con nuestros padres la hora de vuelta a casa tras una fíest
probablemente sea mala idea Insistir indefinidamente en volver más tarde de 1(
permitido. Es mejor proponer una estrategia global más amplia (como p(
ejemplo, llamar por teléfono al llegar y volvet en taja, un poco más tarde) done
«Jas las paites tengan algo que ganar.
Principios de negociación
A la hora de preparar una reunión en la que se hayan de negociar punt(

concretos, merece la pena revisare! siguiente decálogo de aspectos a tener
cuenta:
1. Marcar siempre, y de antemano, unas condiciones mínimas para Uegí

acuerdo. Con ello se evita acceder a posiciones insostenibles al decií
rapidez y bajo presión. --- ~-
Separar a las personas, del problema concreto. Dejarnos influir por ni

simpatía o antipatía por el interlocutor vicia la negociación y entorp<
visión del problema concreto.
Análogamente, tratar de reaccionar de forma rto emocional, considerando

negociación como un proceso profesional y no personal (poco a poco,
actitud calará, incluso al negociar los aspectos más privados y perseas-
Concentrarse en los objetivos globales, y no en liedlos concreU

aconsejable ceder en aspectos, puntuales si con ello se alcanzan posturi
más favorables a nivel global. Dicho de otro modo, no hay que dejar que los
tapen el bosque.
CAPITULO 1: INTRODUCCIÓN A LA DIRECCIÓN Y GESTIÓN DE PROYECTOS 37
orar todas las opciones antes de tomar partido por una de el

menudo, la opción más atractiva no es necesariamente la mejor, en términos
globales.
Canalizar la negociación hacia objetivos que puedan medirse de forma

concreta. No negociar aspectos vagos, tales como "nivel de
responsabilidad" o "consideración en el trabajo", sino aspectos objetivos,
del tipo "'número y categoría de personas a mi cargo" o "despacho y plaza
de aparcamiento".
Conceder ai interlocutor cierto margen de maniobra para que sus

concesiones no aparezcan como simples derrotas.
Tratar de separar la negociación présente cíe otras pasadas, salvo que

estas últimas hiciésemos concesiones concretas a nuestro interlocutor.
Asegurar la existencia de un canal abierto de comunicación. Escuchar a

nuestro interlocutor. Pedir que nos repitan lo que no entendamos. Asentir de
vez en cuando los aspectos fundamentales. Análogamente, hablar claro y
repetir lo importante, enfatizando los puntos clave. No olvidar los aspectos
culturales, religiosos, ideológicos, etc. Son campos donde se abona la
intransigencia necesaria para quebrar una negociación en cursa
Analizar el impacto de la negociación (los resultados obtenidos) dentro

la propia empresa. Qué opinarán los jefes y compañeros, cómo influirá en
nuestro prestigio personal, si sentará algún tipo de precedente, si servirá
para facilitar Muras negociaciones o si ios resultados son consistentes con
lo inicialmente pretendido. _. ...
Y si todo falla, hagamos como los gobiernos: busquemos un medíac

imparcial;, aséptico y objetivo que ayude a encauzar la negociación con
propuestas coherentes y equilibradas (moraleja: el partido se ve mejor desde el
banquillo que desde la cancha).
CAPITULO 2
DETECCIÓN DE OPORTUNIDADES
1. INTRODUCCIÓN
No es necesario ningún diploma en administración de empresas para darse cuenta de
que sin contratos no hay proyectos. Y sin proyectos no hay empresa (ni beneficios, ni
sueldos, ni nada). Ser un gran gestor, dirigir un importante y cualificado grupo de
trabajo, y disponer de unas preciosas oficinas en la gran arteria financiera de la ciudad
sirve de muy poco si no tenemos clientes para quien trabajar y, sobre todo, a quien
facturar.
La fase de detección de oportunidades consiste en, precisamente, localizar posibles

clientes. Es la parte más comercial del proyecto y, casi siempre, la menos técnica del
mismo. La mayor parte de las empresas, salvo las más pequeñas, disponen de un
departamento comercial que, conociendo las habilidades y capacidades de la empresa,
se ocupa de detectar oportunidades de negocio y convertirlas en contratos.
Pero no nos engañemos. Como responsables del futuro proyecto, somos los más
cualificados para saber qué podemos hacer, cuánto tardaremos, y cuánto costará
hacerlo (éstos son los tres pilares básicos de la gestión). Participando, directa o
indirectamente en las actuaciones comerciales, nos aseguramos de que se contratan
proyectos que luego podremos realizar adecuadamente.
Además, participar en este tipo de tareas es algo muy didáctico para el responsable del
proyecto, que aprende a conocer el mercado en el que se mueve, y á los clientes a los
que, posteriormente, tendrá que presentar su oferta y, tras ganar el contrato, rendir
cuentas.
Para terminar, más intensa es aún la actividad comercial de los responsables de

proyecto en pequeñas empresas, donde no existe un departamento comercial ad-hoc, y
la tarea de detección de oportunidades se alterna con la dirección, gestión y, a menudo,
la propia ejecución de los proyectos.
2. CLIENTE, MERCADO Y PRODUCTO
A lo largo de la vida profesional surgen múltiples oportunidades de negocio, de

carácter inesperado, pero, sin embargo, no es lo habitual. Lo más normal es que la
consecución de trabajos responda a una actividad comercial, que será tanto más
fructífera cuanto mejor encaminada esté.
Para que las actuaciones comerciales sean eficientes, tienen que responder a las
necesidades reales del entorno en que nos movamos y, en concreto, tienen que tratar
de adaptarse a las peculiaridades del mercado, e! consumidor (o cliente), nuestra
empresa y el producto o servicio en venta.
Para conocer y caracterizar al cliente al que nos dirijamos es preciso tratar de dar
respuesta a, al menos, las siguientes cuestiones:
> Qué problemas, carencias o necesidades tienen.

> Qué otras necesidades se les pueden crear (o "despertar").
> Cuál es su potencial de negocio (cuánto están dispuestos a gastar).
> En qué plazo de tiempo estarían dispuestos a consumir los bienes o
servicios.
> Qué necesitarán después.
> Qué nivel de fidelidad en la compra presentan.
> Qué otras peculiaridades culturales, ideológicas o de cualquier otro tipo
les caracterizan.
En cuanto al mercado, será necesario conocer:
> Cuál es la tasa de crecimiento experimentada en los últimos tiempos, y si

se espera que se sostenga.
> Cuál es el nivel de competitividad.
> Sí existen barreras de entrada.
> Si existen barreras de salida.
> Si existen nichos de mercado.
> Cuáles son los principales riesgos.
> Si es fácil fidelizar a los clientes.
CAPITULO2: DETF.CC10N DE OPORTUNlDADES 41
> Cuál es el nivel actual de satisfacción de los clientes.

> Cómo reaccionan los clientes ante nuevos entrantes.
Por último, habrá que caracterizar nuestro producto o servicio, en términos de:
> Cuál es el tipo de producto o servicio.

> Si es un producto (o servicio) único, o forma parte de una familia.
> Si será capaz de evolucionar en el tiempo, o quedará obsoleto.
> Si es posible atender a un mercado de gran volumen, o es de tipo
selectivo.
> Cuáles son sus diferencias con productos o servicios similares de la
competencia.
Una vez respondidas estas cuestiones, estaremos en condiciones de abordar la

realización de un plan de negocio.
LECTURA. BARRERAS DE ENTRAD Y BARRERAS DE SALIDA
mundo sabe lo que san las barreras de entrada. San impedimentos

que hacen difícil o imposible la entrada de una nueva empresa en un sector
concreto. La necesidad de patentes, la economía de escala, la imagen de marca o
la necesidad de licencias gubernamentales son algunos ejemplos de barreras
clásicas de entrada. Así, uno puede crear una nueva marca de flotadores para la
playa, pero se lo pensará dos veces antes de crear una nueva marca de tabaco, al
tener que competir con grandes multinacionales que invierten miles de milk en
publicidad.
Lo que ya no es tan conocido es la existencia de barreras de salida, que son

factores económicos, estratégicos o emocionales que mantienen a una empresa
compitiendo en el mercado, aunque consiga márgenes'1' muy reducidos o,
incluso, negativos. Un jubilado podría seguir vendiendo sellos en un parque,
aunque no gane dinero con ello. Un empresario puede decidir mantener su
negocio, no rentable, autes que asumir el coste de despido de sus empleados.
Una marca de automóviles de lujo podría arrojar pérdidas, si con ello mejora la
posición competitiva de su filial de segmento medio. O un operador ds
telecomunicaciones podría mantenerse en régimen de pérdidas económicas, coi
tal de que no se le ejecuten los avales que depositó al solicitar la licencia.
/y
Nótese que hablamos de márgenes, y no de beneficios. La diferencia conceptual entre ambos
términos se expuso en el apartado 1.3.
il punto ideal del mercado perfecto sería aquel en que las barreras de entrada y
de salida fuesen prácticamente nulas. Las empresas podrían acceder fácilmente
al mercado, sin costes prohibitivos^ y aquellas menos eficientes podrían
abandonarlo sin grandes problemas. Este mercado se regiría básicamente por la
oferta y la demanda. Es lo que sucede, por ejemplo, con las panaderías o con el
ercado de accesorios para automóvil, esde el punto de vista de la rentabilidad de
un empresario ya establecido en u sector, la mejor situación vendría dada por
altas barreras de entrada, y bají barreras de salida. En este caso se dificulta la
entrada de nuevos competidores,
Aquellos que fracasen podrán abandonar rápidamente el negocio. Un ejemplo de
te situación se da en los quioscos de prensa (hace falta una concesiói
administrativa) o en los laboratorios lannacéuticos, a causa de la necesidad
lisponer de las preceptivas patentes.
ú peor caso se da cuando las barreras de entrada son bajas, y las de salida son
altas. La afluencia de rruevos actores es alta, pero no pueden abandonar el
mercado cuando las cosas van mal, y permanecen en él, dificultando la
competencia. Esto es lo que sucede cuando, por ejemplo, se recurre a
financiación ajena para la entrada en el negocio, que hay que devolver en caso
abandono.
ir último, cuando tanto las barreras de entrada como las de salida son altas,
íneñcios potenciales son elevados, pero se corre el riesgo de que los
competidores que fracasan permanezcan largo tiempo compitiendo con pérdidas
incluso hundan los precios, antes que abandonar el mercado. Es lo que
cede, por ejemplo, en la industria de los automóviles de lujo, que requiere una
tuerte inversión para su puesta ,eji marcha, que no se amortiza hasta pasad<
muchos años.
3. PLAN DE NEGOCIO
Cuando uno va de viaje es lógico que antes consulte un mapa, acuda a una agencia de
viajes a contratar un vuelo y un hotel, y se informe de las peculiaridades (moneda,
clima, necesidad de visado, etc.) del lugar al que se dirige.
Emprender una actividad empresarial, bien como profesional liberal, bien como
empresa, es como organizar un gran viaje que, incluso, puede durar el resto de nuestra
vida profesional.
CAPITULO 2: DETECCIÓN DE OPORTUNIDADES 43
Aunque en un viaje pueda resultar atractiva una cierta dosis de incertidumbre, riesgo y
aventura, rara vez el deseo de experiencias fuertes se traslada a la vida empresarial,
donde lo que nos jugamos es un capital y, por ende, nuestra viabilidad de llegar a fin
de mes sin que el banco ejecute la hipoteca de nuestra casa.
Un plan de negocio es la información básica necesaria para planificar una mueva

actividad empresarial, un nuevo producto o un nuevo servicio. Antes de lanzarnos a
un nuevo negocio, es conveniente meditarlo de manera organizada, y el plan d>
negocio constituye una herramienta adecuada para ello
3.1 Objetivos del plan de negocio
Son múltiples los objetivos del plan de negocio (sea éste para una nueva empresa o,
más modesto, para un nuevo producto o servicio) pero, en términos generales, pueden
resumirse en tres:
•" Aclarar nuestras ideas, y plasmar y consolidar en un papel los locos devaneos
que a uno se le ocurren en el atasco de turno o en el fragor de una reunión de
vecinos.
*" Cuantificar estimaciones de costes e ingresos esperados que puedan

constituirse en objetivos de referencia para evaluar la viabilidad del tema.
** Transmitir lo anterior, de manera razonada, a nuestros superiores o a las

posibles fuentes de financiación.
En concreto, un plan de negocio deberá:
> Acotar las áreas de interés, el sector y el mercado al que nos dirigiremos.
> Caracterizar el producto o servicio a ofrecer.
> Caracterizar el entorno, incluyendo barreras de entrada y salida.
> Identificar a los clientes o consumidores potenciales.
> Identificar las ventajas y desventajas competitivas de nuestro producto o
servicio.
> Determinar cómo se va a gestionar el proceso y quién o quiénes serán los
responsables.
> Estimar los costes implicados, los ingresos esperados, el margen y el
beneficio, y el tiempo.
3.2 Formato de un plan de negocio
Si el plan de negocio refleja las cuestiones planteadas en el apartado anterior, junto

con las peculiaridades específicas que se consideren oportunas, el formato del mismo
es un aspecto secundario. De hecho, existen tantos formatos como tipos de productos
o servicios, y cada autor tiene y hace uso de sus propias preferencias.
Cualquier formato de plan de negocio es válido en tanto y en cuanto sea capaz de

transmitir, de la manera más clara y objetiva, los razonamientos que se esconden
detrás de la comercialización del nuevo producto o servicio. El objetivo último del
plan es que el responsable (seamos nosotros, nuestros superiores, los accionistas o un
banco) lo apruebe y dé luz verde al comienzo de las actividades. Para ello, aparte de
presentar una idea novedosa y atractiva, deberá estar redactado de forma clara, amena
y, por qué no, atractiva a la vista.
A continuación, se incluye un formato de índice de plan de negocio que puede servir

de base para que cada cual genere el plan que más le satisfaga, personalizándolo no
sólo a su gusto, sino también a las necesidades específicas del negocio o el producto:
0.- Sumario ejecutivo. Constituye un breve resumen (en torno a un 5% de

la extensión del plan completo), escrito en lenguaje llano y fácil de
comprender, del contenido del plan. Como su propio nombre indica,
está destinado al nivel de responsabilidad ejecutiva de la organización,
que puede dedicar poco tiempo a la lectura del plan, y que no
necesariamente dispone de los conocimientos técnicos necesarios para
comprender la totalidad del mismo. En el sumario ejecutivo deberán
describirse, sucintamente, los objetivos, los condicionamientos, el
mercado, el equipo de trabajo, el producto o servicio, la estrategia de
mercado y los datos económicos y financieros correspondientes.
1- Descripción del entorno y la competencia. En este capítulo se

reseñarán los razonamientos que inducen a pensar que existe una
oportunidad de negocio, y sobre qué hechos se fundamenta. En
concreto, se describirá:
a) La situación actual del mercado.

b) El número e importancia (cuota de mercado) de los competidores.
c) Las barreras de entrada y de salida.
d) Las características del Cliente (sus necesidades e inquietudes, su
capacidad de compra, su fidelidad a las marcas existentes, su
reacción potencial ante un nuevo proveedor o producto, etc.).
©RA-MA CAPITULO 2: DRTECC1ON DE OPORTUNIDADES 45
2.- Descripción del producto o servicio. En este capítulo se describe el

negocio, producto o servicio que se pretende crear y comercializar,
incluyendo:
a) Características generales.
b) Diferencias con productos o servicios comparables de la
competencia.
c) Capacidad de evolucionar con el tiempo o capacidad para dar
lugar a una familia de productos o servicios.
d) Factores que pueden sumar o restar atractivo al producto.
e) Sinergia con otras empresas, productos o servicios propios.
3.- Estrategia de mercado. Se trata de describir la estrategia de mercado

propuesta para dar salida al negocio, producto o servicio, incluyendo:
a) Estrategia de búsqueda de oportunidades.

b) Canales de distribución.
c) Forma de comercialización.
d) Promoción y publicidad.
4.- Planes operativos y de gestión. En este capítulo se reseña la

información de interés acerca del modelo de gestión a utilizar para
poner en marcha la actividad, o desarrollar el producto o servicio,
incluyendo:
a) Recursos humanos necesarios, y cualifícación de los mismos.

b) Recursos materiales necesarios.
c) Actividades a subcontratar y subproductos a adquirir.
d) Política de gestión.
5.- Estimaciones económicas y financieras. Se incluye en este capítulo

toda la información de interés para evaluar la inversión necesaria, los
costes previstos, los ingresos esperados, el margen resultante y el
beneficio consecuente, indicando claramente cuál es el plazo temporal
para todo ello. También es necesario incluir información acerca de la
forma de financiación propuesta, especialmente en el caso de una nueva
actividad empresarial. En concreto, se contemplará:
a) Hipótesis de trabajo utilizadas para las estimaciones económicas.

b) Coste de poner en marcha la actividad.
c) Coste del primer producto o servicio.
d) Coste de productos o servicios adicionales (recurrentes).
e) Coste de operación.
f) Ingresos esperados.
g) Para los siguientes años, flujos de caja, margen y beneficio

previsto, h) Plan de financiación, incluyendo
amortización.
6.- Estrategia de salida. Por si algo sale mal, es cada vez más frecuente
que en los planes de negocio se incluya un apartado que describa una
estrategia de salida del mercado razonable. Esta estrategia no sólo sirve
para casos de desastre, sino que también puede apuntar actuaciones
orientadas al momento en el que la empresa, bien o servicio ya está listo
para ser comercializado, y puede ser un buen momento para vender el
negocio a una empresa de mayor volumen, transferir los derechos de
explotación, etc.
7.- Síntesis y conclusiones. Para terminar, se reseñarán las características

que justifican abordar el riesgo de la nueva empresa, producto o
servicio, abundando en las razones de por qué la nueva actividad es
única, o tiene mejores oportunidades que las de la competencia.
8.- Apéndices. Se incluirá aquí toda la información adicional que pueda ser
de interés, tal y como planos o fotos del producto, recortes de prensa,
informes realizados, información relativa a la competencia, referencias
de potenciales clientes, etc.
4. OPORTUNIDADES COMERCIALES
Tan pronto se dispone de una idea clara acerca de cuál es el producto o servicio a
comercializar, cuál es el mercado natural para nuestra actividad, y a qué tipo de
clientes nos vamos a dirigir, llega el momento de pasar a la acción: a buscar contratos.
La búsqueda de oportunidades comerciales es muy similar a la búsqueda de empleo,

tanto en concepto como en la forma. En los siguientes apartados se van a reseñar las
maneras más habituales de detectar y acceder a oportunidades de negocio {o, por qué
no, a un nuevo empleo).
4.1 Oportunidades "perseguidas'
Prácticamente la totalidad de las oportunidades de negocio con las que tendremos que
enfrentarnos en nuestra vida profesional serán "perseguidas", en el sentido de que
habremos de ser nosotros mismos los que, mediante una búsqueda activa, tratemos de
detectarlas e identificarlas.
CAPÍTULO 2; DETECCIÓN DE OPORTUNIDADES 47
4.1.1 EL CONCURSO
Cuando un individuo o empresa determinada identifica una necesidad concreta, que no

puede satisfacer con sus propios recursos, recurre a la contratación de bienes o
servicios que otro le proporciona. Por lo general, en un mercado en competencia existe
más de un posible proveedor del bien o servicio en juego, y el futuro Cliente puede
"permitirse el lujo" de seleccionar a aquel que mejor precio o condiciones le ofrezca.
Esto es lo que sucede, por ejemplo, cuando compramos un automóvil. Buscamos en

diferentes concesionarios para ver cuál nos ofrece no sólo el mejor precio, sino la
mejor garantía, plazo de entrega, etc.
Si el poder de negociación del Cliente es grande, porque el presupuesto es importante

o porque realiza frecuentes adquisiciones, lo lógico es que promueva un concurso.
Para ello, genera unas especificaciones o requisitos mínimos a cumplir por el bien o
servicio a adquirir. Dichas especificaciones las pone en manos de diferentes
proveedores potenciales, quienes responden con su mejor oferta. Finalmente, el
Cliente elige aquélla de las ofertas recibidas que más le satisfaga.
Para una empresa, es vital estar al tanto de todos los Concursos que se convoquen,
oficial o extraoficialmente, en el área de negocio de su interés. Los concursos pueden
ser públicos o privados. Darse a conocer (con publicidad) o no. Pueden ser abiertos a
todo el mundo, o restringidos a un selecto grupo de potenciales proveedores. Como
cada empresa o individuo tiene la libertad de seleccionar a sus proveedores de la
forma que más le satisfaga, puede convocar el concurso de selección como le parezca
oportuno. Claro que, si el poder de compra es insuficiente, corre el riesgo de no recibir
ofertas interesantes (por ejemplo, ¿cuántas ofertas podría recibir nuestro sagaz Cliente
si convocase un concurso para adquirir, digamos, un reloj de pulsera de 100 €? No
muchas, ¿verdad?).
Es tan grande la importancia de esta modalidad de adjudicación de contratos que se le

ha dedicado el apartado 5 de este capítulo, en exclusiva.
En general, todas las oportunidades de negocio son, en realidad, concursos. Los

siguientes apartados describen procedimientos de contratación que son
particularizadones o casos específicos de los concursos, por lo que se describen por
separado (pero son, en definitiva, concursos).
4.1.2 INFORMACIÓN ACERCA DE LAS NECESIDADES DEL CLIENTE
Otra forma de abordar a un potencial Cliente es estar lo suficientemente cerca de él

(conceptualmente hablando, claro) como para detectar una necesidad concreta y, antes
48 DIRECCIÓN Y GESTIÓN IW. PROYECTOS
de que tenga tiempo de pensar en comparar posibles proveedores, remitirle una oferta
para la resolución de dicho problema.
Si nuestro Cliente tiene la suficiente confianza en nosotros, los precios y condiciones

son aceptables, y su necesidad es real, tal vez nuestra diligencia sea recompensada con
una contratación directa.
4.1.3 CREACIÓN DE NECESIDAD EN EL CLIENTE
Un refinamiento maquiavélico del procedimiento anterior es no esperar a que el

Cliente tenga una necesidad, sino intentar adelantársela en el tiempo. Imaginemos, por
ejemplo, un farmacéutico que aún lleva su gestión de pedidos, ventas y stock a mano,
sin ayuda de ordenador. Podemos esperar a que se dé cuenta de lo útil que es una de
esas nuevas maquinitas, pero tal vez en ese momento decida encargar el proyecto (de
compra e instalación del equipo y el software) a otro proveedor, que simplemente haya
sido más diligente que nosotros.
Pero también podemos iniciar una estrategia de acercamiento basada en mostrarle

cuánto mejoraría su eficiencia si dispusiera de un sistema informático, dándole a
conocer las características y ventajas del que nosotros le ofrecemos. Si el producto y el
servicio es bueno, las condiciones aceptables, nuestra propuesta creíble y, claro, el
farmacéutico accede, podremos obtener un contrato donde, simplemente, antes no lo
había.
Esta técnica de creación de necesidades ha sido tremendamente explotada a lo largo

del tiempo, muchas veces con límites éticos mucho menos perfilados que en el
ejemplo anterior. La creación de necesidades irreales es una técnica habitual de los
mercados de productos y servicios de lujo. En realidad, nadie "necesita" un automóvil
de lujo, ni unas zapatillas de marca, ni, probablemente, un diamante en el anillo"". La
publicidad y la promoción actúan, aquí, como vehículos para la creación de
necesidades que, en muchos casos, son simplemente falsas.
4.1.4 DIVULGACIÓN Y PUBLICIDAD
Por lo general no podremos estar siempre al lado de todos los posibles clientes, con
vistas a detectar sus necesidades. Además, si el producto o servicio es de tipo
genérico, y/o de bajo coste (por ejemplo, una lavadora), los márgenes comerciales no
nos permitirán iniciar actividades comerciales individualizadas para cada cliente en
potencia.
20
De hecho, cuestiono la necesidad, incluso, del propio anillo.
CAPÍTULO 2: DETECCIÓN DE OPORTUNIDADES 49
En este caso, la forma de acceder a estas oportunidades de negocio es dar a conocer

nuestra actividad, nuestros productos, o nuestros servicios, como manera de tratar de
estar presentes en la mente de cada posible Cliente cuando se decida a ejecutar su
acción de contratación (o compra).
El problema de la publicidad es que dejamos la pelota en el tejado del Cliente, que es

quien debe responder a la misma, solicitando nuestros servicios. Es como llamar por
teléfono a un Ministro, y dejarle recado para que nos devuelva la llamada. Tal vez esa
llamada no llegue nunca, y seguramente hubiera sido más inteligente por nuestra parte
seguir insistiendo.
4.1.5 AMPLIACIÓN DEL ALCANCE DE UN PROYECTO O TRABAJO
Pero probablemente las mejores oportunidades surgen cuando ya estamos trabajando

para un Cliente, a quien \e surge \a necesidad de ampliar el alcance del contrato en
curso. En tal caso, salvo que técnica, económica o administrativamente no estemos
haciéndolo nada bien, el Cliente preferirá adjudicarnos, directamente, la ampliación
del contrato, antes que buscar a otras empresas, convocar un concurso y adjudicárselo
a la más eficiente. Ese incremento de eficiencia, en la mayor parte de los casos, se verá
anulado por la necesidad de que el nuevo contratista aprenda lo que se lleva hecho
hasta el momento, así como la complejidad que supone para el Cliente un cambio de
empresa adjudicataria.
Sin embargo, hay honrosas excepciones a esta regla general. Si nuestro trabajo actual
no es satisfactorio, o nuestras relaciones con el Cliente son deficientes, probablemente
estará encantado de seleccionar una nueva empresa, adjudicarle un contrato en forma
de ampliación de alcance de los trabajos, y librarse de nosotros.
4.1.6 CONTINUACIÓN DE TRABAJOS ANTERIORES
Esta oportunidad es, prácticamente, una particularización de la basada en divulgación

y publicidad, reseñada en el apartado 4.1.4. En este caso, la publicidad que sirve de
vehículo para la obtención del nuevo contrato es la satisfacción del Cliente por el
resultado de algún trabajo (nuestro) anterior. Así, pasado el tiempo, cuando al Cliente
le surja una nueva necesidad, podrá recurrir directamente a nosotros, movido y
animado por buenas experiencias anteriores.
SO DIRECCIÓN Y GESTIÓN DB PROYECTOS
4.2 Oportunidades "no perseguidas"
Y llegamos al segundo gran tipo de oportunidades comerciales, las no perseguidas,

que son aquellas que, en teoría, encontramos sin buscarlas. Es como ir por la calle y
que alguien que te para en una esquina te ofrezca un empleo.
Este tipo de oportunidades son escasas y poco frecuentes. Aunque muchos se

esfuercen en convencernos de lo contrario, recibir una buena propuesta de negocio
"por las buenas" es poco probable. Lo que ocurre es que se confunden las
"oportunidades inesperadas" con las "oportunidades no perseguidas".
Veamos qué significa lo anterior: cuando estamos sumergidos en un tipo de actividad

profesional (desde la práctica de la abogacía hasta el diseño de microprocesadores de
silicio), continuamente nuestro trabajo es nuestra mejor tarjeta de visita o, dicho de
otra manera, nuestra mejor publicidad. A veces, alguien al tanto de nuestro trabajo, de
manera directa o a través de terceros, puede recurrir a nosotros para resolver una
necesidad. El hecho de que no esperemos esa oportunidad no significa que no la
hayamos buscado anteriormente.
5. CONCURSOS
Ya dijimos anteriormente que el concurso es una de las formas preferidas de

contratación de trabajos (y tal vez, al menos en teoría, la más justa), válida siempre y
cuando concurran varias circunstancias:
 El volumen del contrato sea suficiente como para encajar el esfuerzo de

preparar un concurso, y el coste de convocarlo.
 Existan suficientes proveedores potenciales.
 El objeto del contrato y las condiciones del mismo (plazo, precio, condiciones
para ofertar, etc.) sean razonablemente atractivos para que exista interés por
concurrir al concurso.
 El Cliente sea conocido y solvente, para que los potenciales concursantes se

sientan atraídos por la convocatoria.
Las razones anteriores pueden sintetizarse en una sola: que podamos asegurar
(razonablemente) que la convocatoria del concurso va a ser un éxito, en términos de la
cantidad de ofertas que se reciban como respuesta al Pliego, y de la variedad y calidad
de las mismas.
CAPITULO 2: DETECCIÓN DH OPORTUNIDADES 51
En cuanto al procedimiento para convocar un concurso, puede ser tan variado como
distintos pueden ser los convocantes, el alcance, el volumen del contrato, etc., pero
todos ellos siguen un patrón más o menos establecido, reflejado en la figura 2.1,
EVALUACIÓN DE
PROPUESTAS
NEGOCIACIÓN Y
ADJUDICACIÓN DEL CONTRATO
diferenciándose luego en la forma de llevar a cabo cada fase.
Figura 2.1 Procedimiento general para convocar un concurso
Un concurso comienza cuando, tras detectar una necesidad cuya resolución conviene
subcontratar a otros, se decida hacerlo en forma de concurso y, no menos importante,
se disponga ya de una partida presupuestaria para el futuro contrato.
El primer paso es preparar un Pliego de prescripciones, que indica qué tendrá que
hacer (objeto del contrato) el ftituro contratista y cómo tendrá que hacerlo, así como
qué tipo de propuesta habrá de presentarnos, y cómo la valoraremos (criterios de
valoración). En este Pliego se tendrán en cuenta consideraciones de tipo:
Técnico. Qué habrá que hacer. Qué soluciones se buscan, con qué tecnologías,
etc.
 Administrativo: Qué tipo de empresa ofertante se busca, qué documentación se

habrá de presentar, qué requisitos contractuales se exigen, etc.
 Económico: Cuánto se espera que cueste el contrato, y cómo serán las

condiciones de pago.
Una vez redactado el Pliego (de cuyo contenido y forma se ocupa el apartado 5.3), es
el momento de darlo a conocer a los posibles interesados, es decir, hacerlo público.
Hay diferentes maneras de publicar un Pliego, en función del tipo de contratista al que
vaya dirigido. Estas maneras se analizan en el apartado 5.2.
Al publicarse el Pliego, comienza el plazo para que los posibles interesados lo

estudien, analicen, preparen una oferta y la presenten. Cuando dicho plazo (que suele
ser siempre reducido) concluye, la parte contratante (el potencial cliente) procede a
evaluar las ofertas recibidas como respuesta al Pliego, para seleccionar la mejor de
ellas y, eventualmente, adjudicar el contrato al autor de la misma.
Si no se recibe ninguna oferta, o ninguna de las ofertas recibidas cumple los requisitos
mínimos (no sólo técnicos, sino también de credibilidad o de solvencia del ofertante)
exigidos por el Pliego, se dice que el concurso queda desierto. Hay pocas cosas peores
que un concurso desierto. Excepciones aparte, este tipo de situaciones responde
frecuentemente a un Pliego mal redactado, un momento de convocatoria inoportuno, o
a unas condiciones poco atractivas para los potenciales proveedores, y la consecuencia
es clara: se ha desperdiciado el tiempo, el esfuerzo y el coste de preparar el Pliego y
convocar el concurso.
Por último, a veces el Cliente da un último "apretón de tuerca", e introduce una cierta
negociación con el potencial contratista, antes de adjudicarle el contrato. Esta
negociación, por lo general, suele ir destinada a rebajar algo el precio ofertado, a
ampliar ligeramente el alcance o, en muchas ocasiones, a introducir en la oferta
"ganadora" aspectos atractivos de las otras ofertas2'. También puede ir destinada a
evaluar la solidez técnica de la propuesta y del equipo de trabajo, como es el caso
siguiente, que corresponde a un párrafo extraído de un Pliego de prescripciones para
un concurso convocado por la Administración Central:
"Si se considera oportuno, se podrá celebrar una segunda vuelta con las
ofertas más ventajosas, invitando a los licitadores a efectuar una defensa de la
solución técnica propuesta y una entrevista al equipo propuesto. Esta segunda
vuelta afectará únicamente a la evaluación de la solución técnica y del equipo
de trabajo propuestos, no pudiendo modificar la valoración de la oferta
económica ni de las prestaciones adicionales ofertadas".
Incluso, en muchos casos, el Cliente negocia con el autor de la mejor oferta global para que
éste se responsabilice del contrato completo, pero subcontratando partes del mismo a otras
empresas que hayan presentado ofertas mejores en puntos concretos.
5.1 Objetivos de un concurso
Los objetivos del concurso, que a estas alturas son ya bastante evidentes, pueden
sintetizarse en tres grupos:
*" Objetivos técnicos:

K Lograr un suficiente número de propuestas que den respuesta a nuestros
requisitos concretos, plasmados en el Pliego.
> Obtener información técnica de diferentes fuentes.
> Poder comparar entre las diferentes propuestas, seleccionando los
aspectos técnicos más atractivos, incluso aunque no hubiésemos pensado
en ellos al redactar el Pliego.
•" Objetivos económicos:

> Asegurar que los precios a recibir no superan la partida presupuestaria de
la que se dispone.
> Establecer una competencia que fuerce a ofertar a la baja, para lograr el
mejor precio.
> Comparar entre las propuestas y obtener información acerca de los
diferentes precios que permita negociar en mejores condiciones.
*■ Otros objetivos:
> Obtener información acerca de las empresas disponibles (y dispuestas)
para realizar este tipo de trabajos.
5.2 Publicidad del concurso
El concurso sólo cumplirá con sus objetivos si su contenido y condiciones llegan a

manos de todos los contratistas cuyas ofertas puedan ser de interés. Si la difusión
del Pliego es pequeña, y sólo llega a manos de unos cuantos interesados, se corre el
riesgo de no recibir las mejores ofertas que, tal vez, se hubieran presentado de haber
dado mayor publicidad al Concurso.
Así pues, lo primero que hay que considerar es a quién se desea que llegue el Pliego o,
dicho de otra manera, con cuántos ofertantes deseamos tratar. Si bien es bueno
disponer de una oferta amplia y variada, evaluar dichas ofertas supone un coste y un
esfuerzo, y carece de sentido animar a presentar propuestas a contratistas que no
forman parte del tipo de empresas buscadas. A modo de ejemplo, la Administración
española22 diferencia entre tres tipos de concursos, en función del procedimiento

seguido, que son:
** El procedimiento abierto, al que cualquier contratista que satisfaga las

cláusulas generales y particulares puede concurrir.
"»" El procedimiento restringido, al que sólo pueden responder los contratistas

que hayan sido expresamente invitados a presentar oferta.
■»" El procedimiento negociado, mezcla de los dos anteriores, en el que se invita

a concurrir a un número reducido de empresas, con las que se negocian las
condiciones del contrato.
El perfil medio del contratista buscado y el número de potenciales ofertantes

determina, en gran medida, cómo seleccionar el tipo de publicidad que hay que dar al
Pliego. Un concurso abierto, con gran número de potenciales interesados en concurrir
al mismo, suele hacerse público vía anuncios en prensa o, en el caso de que el
convocante sea la Administración, en el Boletín Oficial correspondientes (de las
Comunidades Europeas, del Estado, de la Comunidad Autónoma, etc.). En dicho
anuncio se relacionan las características más relevantes del Pliego, tales como:
> Datos de la entidad o empresa contratante.

> Propósito y objeto (general) del concurso.
> Duración del contrato y presupuesto del mismo.
> Plazo para la presentación de propuestas.
> Lugar de obtención de la documentación completa (el Pliego).
A la vista de la información anterior, cada posible ofertante decidirá si el contrato es

de su interés y, en caso afirmativo, procederá a obtener el Pliego completo, para
realizar la oferta.
La figura 2.2 muestra dos concursos convocados, uno a través del diario oficial y otro
en la prensa diaria.
22
Según Real Decreto Legislativo 2/2000, de 16 de junio, que aprueba el texto refundido de la
Ley de Contratos de las Administraciones Públicas (LCAP), y Real Decreto 1098/2001, de 12
de octubre, que aprueba el Reglamento correspondiente.
CONSEJO GENERAL DEL

PODER JUDICIAL
Acuerdo de la Secretaria General del Consejo
General del Poder Judicial por el que se
CONCURSOS PÚBLICOS
anuncia concurso para la contratación de ¡a
asistencia técnica para la elaboración de un Mejora y acondicionamiento edificio Acc Canarias
estudio sobre la seguridad en las coma- (CAN 142/99)..
nicaciones informáticas de los órganos judi- Por un importe de 31.223.833.- PTA (187.659 Euros).
ciales en España. Suministro sistema de cargas artificiales transportables
para prueba grupos electrógenos y sistemas eléctricos
1. Entidad adjudicadora; Consejo Región Canana (CAN 144/99). Por un importe de
Genera] del 10.397.750.- PTA (62.491,74 Euros).
Poder Judicial. calleMarqutsdela Ensenada, núme
ro 8, 28071 Madrid, teléfono 91 700 61 00, tciefáx Estudio, análisis y verificación sistemas contraincendios
700 63 51. D.R.N.A. Canaria (CAN 145/99).
2. Objeto: Asistencia técnica para la elaboración Por un importe de 5.747.500.- PTA (34.543,17 Euros).
de un estucho sobre la seguridad en las cwniuni Ampliación sistemas iluminación Centro Emisores-
cationes informáticas de los órganos judiciales en Receptores del Pico de ta Gorra y Centro de Control (CAN
España. 152/99). Por un importe de 21.943.480- PTA (131.883
3. Tramitación, procedimiento y forma de adju Euros).
dicación: Concurso abierto de tramitación ordinaria.
4. Presupuesto base de licitación: 4.009.000 de Asistencia Técnica para el estudio de una red de
comunicaciones por microondas para N.A. en la Región
péselas. Canaria (CAN 153/99), Por un importe de 11.973.272.-PTA
5. Garantía provisional: 2 por 100 del presu (71.960,8 Euros).
puesto de licitación.
6. Qbtrncion de documentación: Consejo Gene Remodelación Antiguo Edificio Administrativo (CAN 154/99).
ral del Poder Judicial. Véase punto 1, y Centro Por un importe de 156.709.905 ■ PTA (941.845 Euros).
de Documentación Judicial, calle Manterola. 13, 2.*,
20007 Donostia-San Sebastián, telefono Disponibilidad de documentación: Información en el D"
Económico Administrativo de la Dirección Regional de
943 44 52 23, hasta el 31 de agosto de 1999. Navegación Aérea. Ojo; de Garza, s/n. Telde, Gran Canaria.
7. Condiciones mínimas: Según pliegos. Teléfono: 928 57 70 20 y 928 57 70 21
8. Presentación de las ofertas o solicitudes de Presentación de ofertas: Hasta las 13.30 horas del día
participación: Registro General del Consejo General 03/09/99, en el Departamento antes citado.
del Poder Judicial, calle Marques de te Ensenada, Comunicación de empresas presentadas: A partir del día
número 8. planta baja, 28071 Madrid (horario de 07/09/99 en el tablón de anuncios de la Oficina de
registro: líe lunes a viernes, de nueve a catorce Contratación.
Apertura de ofertas: Se comunicará oportunamente
y de dieciséis treinta a dieciocho horas. Sábados
de nueve a trece horas. Durante el mes de agosto
no funcionará registro durante las tardes ni sábados), PUBLICIDAD
hasta el día 31 de agosto de 1999.
El importe de este anuncio será por cuenta de los
9. Apertura de proposiciones económicas: Ten adjudicatarios.
drá lugar, en acto publico, el día 24 de septiembre
de 1999, a las diez horas, en el salón de actos
del Consejo General del Poder Judicial, planta baja
10. Gastos 4e anuncio: El abono de tos gastos
de publicidad del presente concurso correrá a cargo
del adjudicatario de éste.
Madrid, 30 de Jubo de 1999.—Rl Secretario gene
ral.-33.388.
Figura 2.2 Anuncios de concursos públicos convocados en el

Boletín Oficial del Estado (BOE), a la izquierda, y en un diario de
ámbito nacional, a la derecha
En los casos en que se haya preseleccionado un grupo de posibles contratistas, o que el

número de los candidatos potenciales sea reducido (y estén identificados), no interesa
incurrir en el coste de un anuncio de gran divulgación, sino que es más eficiente enviar
el Pliego, junto con la invitación para ofertar, a la lista de empresas identificadas. Esto
mismo ocurre en el caso de los contratos de la Administración por procedimiento
Restringido o Negociado.
Por último, en las contrataciones directas la publicidad carece de sentido, pues el

Pliego de condiciones (si es que se elabora), se entrega directamente al contratista
seleccionado, con el que a continuación se negocian las condiciones específicas del
contrato.
5.3 El Pliego
La información del anuncio de convocatoria o de la carta de invitación (directamente

recibida) sirve para evaluar, grosso modo, el interés del contrato, pero aporta escasa
información adicional. El resto de los datos necesarios para tomar una decisión firme
sobre si ofertar o no, de la forma en la que hay que preparar la oferta y de la
descripción detallada de los trabajos a realizar se encontrará en el correspondiente
Pliego (o se debería encontrar, salvo que la redacción del Pliego no tenga la calidad
necesaria).
Un Pliego para la contratación de trabajos suele estar compuesto por dos partes
independientes: las condiciones administrativas aplicables al contrato (Pliego
Administrativo), y las prescripciones técnicas (Pliego Técnico) del trabajo a realizar.
Cada parte, a su vez, incluye información adicional, que suele estructurarse, más o
menos (dependiendo del tipo de contrato, y de la entidad contratante), en los siguientes
apartados:
®° PARTE I: Condiciones administrativas (Pliego Administrativo)

> Objeto del contrato: qué se pretende del contrato a adjudicar.
> Régimen jurídico: quién contrata, y bajo qué fórmula administrativa.
> Presupuesto: cantidad máxima por la que se pueden presentar ofertas, y
condiciones asociadas (forma de pago, anualidades, incrementos por
escalación, etc.)
> Procedimiento y forma de adjudicación: concurso, subasta, etc., y normas
por las que se rige.
> Requisitos a cumplir por las empresas ofertantes: tipo de actividad,
calificación en registros de capacidad industrial, solvencia económica o
certificados de calidad, experiencia previa, etc.
> Requisitos a cumplir por las ofertas presentadas: documentación técnica y
administrativa a presentar, forma, lugar y plazo.
> Criterios de adjudicación: normas con las que se valorarán las ofertas
presentadas.
> Formalización del contrato: forma de adjudicar el contrato, fecha de la
firma, fianzas y avales a depositar, cesión y subcontratación de
actividades, y extinción del contrato.
> Otras condiciones que se estimen oportunas.
■*" PARTE II: Prescripciones técnicas (Pliego Técnico)

> Objeto del contrato.
> Descripción del contenido de los trabajos.
ERA-MA ______________________________________ C A P ÍT U L O 2 : D E T E C C IÓ N D E O P O R T U N ID A D E S 5 7
> Requisitos de planificación y organización del equipo de trabajo.

> Otras condiciones técnicas.
Los criterios de valoración (o de adjudicación) merecen una atención especial. Desde

el punto de vista de la empresa o entidad contratante, suponen determinar a qué
aspectos se le va a dar más importancia a la hora de evaluar las ofertas recibidas.
Desde la óptica de los contratistas, constituyen una valiosa información acerca de qué
aspectos son los que más preocupan al Cliente, cómo hay que orientar la oferta a
presentar, y cómo incidirá en el coste del trabajo a realizar. La figura 2.3 muestra los
criterios de valoración extraídos de un Concurso Público convocado por un órgano de
la Administración, en relación a unos trabajos en el área de consultoría y asistencia
técnica en materia de telecomunicaciones.
CRITERIOS DE ADJUDICACIÓN CONTRATO DE

ASISTENCIA TÉCNICA, Exptc. XX
CRITERIOS DE VALORACIÓN PUNTUACIÓN
7 PUNTOS 1.- CRITERIOS TÉCNICOS

1.1- GRADO DE RESPUESTA GENERAL DE LA PROPUESTA A LOS 1,8 REQUISITOS
DEL PLIESO 1.2- VIABILIDAD GENERAL DE LA PROPUESTA, EN CUANTO AL 0,5
ALCANCE V CONDICIONES DE REALIZACIÓN 1.3.- GRADO DE CUMPLIMIENTO EN CUANTO A
FUNCIONALIDAD DEL 0,5 PRODUCTO OFERTADO.
1,0 1.4.- NIVEL ESTÉTICO DEL PRODUCTO OFERTADO 1.5.- EFICIENCIA TÉCNICA DEL PRODUCTO
OFERTADO, (PLATAFORMA NECESARIA, VELOCIDAD DE PROCESO, REQUISITOS DEL
0,5 SISTEMA, HERRAMIENTAS DE DESARROLLO EMPLEADAS) 1.6- CALIDAD GENERAL DEL EQUIPO
DE TRABAJO PROPUESTO, Y 0,5 ADECUACIÓN DE LOS PERFILES PROFESIONALES
0,5 1.7- EXPERIENCIA DEL EQUIPO EN TRABAJOS SIMILARES 1.8- ADECUACIÓN DE LOS PLAZOS
PROPUESTOS CON LOS 0,25 REQUISITOS DEL PLIEGO. 1.9- CALIDAD
TÉCNICA Y DETALLE DE LA DOCUMENTACIÓN A 0,75 APORTAR POR EL
CONTRATISTA. 1.10.-APORTACIONES ADICIONALES QUE, SIN ESTAR SOLICITADAS EN EL PLIEGO,
PUEDAN MEJORAR EL RESULTADO DE LOS 1,0 TRABAJOS A REALIZAR.
2.- CRITERIOS ECONÓMICOS 3

PUNTOS 2.1.- REBAJAS AL PRESUPUESTO MÁXIMO 3,0
Figura 2.3 Criterios de valoración y adjudicación de un concurso

público para prestación de asistencia técnica a la Administración.
Fuente, Pliego Administrativo
A la vista de los criterios de la figura 2.3, un posible candidato al contrato podría, por
ejemplo, decidir volcarse en la oferta técnica y, en concreto, en ofertar mejoras
adicionales (que puntúan sobre 10 puntos), en lugar de ofertar una rebaja en el precio
que, aunque puede suponer hasta 2,5 puntos, podría comprometer la calidad del
trabajo ofertado. También podría decidir subcontratar, para dicho expediente, un
experto internacional en el tema de que se trate, con el fin de acceder al punto
adicional de los criterios de valoración.
Los criterios de valoración pueden desvirtuar la naturaleza del concurso. Tomemos, a

modo de ejemplo, la importancia relativa entre oferta técnica y oferta económica. Si la
oferta económica puntúa muy bajo, se está desincentivando a los ofertantes a incluir
rebajas considerables en el precio, ya que los precios bajos influirán poco en la
valoración de la oferta. Por el contrario, valorar muy alto el precio ofertado es casi
equivalente a convertir el concurso en una subasta, ya que un ofertante con una
propuesta de excelente calidad técnica se ve numéricamente, en puntuación, superado
por una oferta de calidad mediocre, pero con un presupuesto muy bajo.
Los Clientes saben que las ofertas económicas muy bajas rara vez se corresponden
únicamente a intereses por abrirse mercado y ser competitivos, y en la mayor parte de
las ocasiones esconden equipos de trabajo, cualificaciones técnicas y capacidades
inferiores a la media. Además, un precio muy bajo puede obedecer a condiciones de
precariedad, inestabilidad del ofertante o, simplemente, un análisis del alcance y el
esfuerzo incorrectos que, a menudo, terminan con empresas incapaces de cumplir con
el trabajo, y proyectos abandonados a la mitad.
Para evitar la situación anterior, que se conoce familiarmente como "precios o bajas
temerarias", pueden fijarse fórmulas de valoración de las bajas económicas que
premian rebajas sensatas, considerando como "sensato" el valor medio de las
propuestas presentadas. Así, se penaliza tanto a los ofertantes que licitan por un precio
elevado, como a los que proponen rebajas desproporcionadas, poco prudentes.
La figura 2.4 muestra una posible forma de valoración de las propuestas económicas,
para un contrato de, por ejemplo, 10 millones de euros. Si las proposiciones
económicas se valoran entre 0 y 3 puntos, se asignarían cero puntos a las propuestas
cuyo precio de licitación se corresponda con el presupuesto máximo de licitación (10
millones de euros). Toda proposición cuyo precio supere el precio máximo sería
automáticamente descartada. De entre las proposiciones restantes, se asignará hasta 3
puntos a aquélla o aquéllas cuyo precio coincida con la media aritmética de todas las
propuestas económicas presentadas. Las demás propuestas recibirán la puntuación
correspondiente a interpolar mediante sendas rectas, entre 0 y 3 puntos, y entre dicho
valor medio y, respectivamente, el precio máximo de licitación y el precio mínimo
ofertado.
Figura 2.4 Función de asignación de puntos a las ofertas

económicas recibidas
Veamos el resultado de aplicar el caso anterior a un ejemplo, en el que seis licitadores

presentan, a un concurso de precio máximo 10 millones de euros, precios de 10.5, 10,
9, 8, 7 y 4 millones, respectivamente.
Obviamente, el licitante que ofertó 10.5 millones queda automáticamente

descalificado. Los demás licitadores superan esta prueba, y sus ofertas económicas se
utilizan para calcular el precio medio de licitación, que en este caso es de:
10+9+8+7+4
L* . . ^^ = — ------------------- = /.o
Si un licitante hubiera ofertado exactamente 7,6 millones, habría obtenido una

puntuación de 3 puntos, para su oferta económica. Por su parte, tanto los licitadores
que ofertaron el precio máximo permitido como el menor precio obtienen 0 puntos.
Los demás ofertantes obtienen una puntuación que se calcula interpolando las rectas
de la figura 2.4, utilizando PMIN=4 y PMAX~10, y que responden a la expresión
siguiente:
Siendo/? el precio ofertado (en millones), y V(p) la puntuación obtenida.

Haciendo uso de la expresión anterior, la lista de puntos obtenidos por cada licitante
queda como sigue:
Licitante Precio ofertado'' Puntuación

1 10,5 Descalificado
2 10 0
3 9 1,25
4 8 2,5
5 7 2,5
6 4 0
(*) En millones de euros
Nótese que, desde el punto de vista de los posibles lidiadores, esta forma de valorar
económicamente las propuestas, aunque más lógica, es más compleja de manejar, ya
que se trata no sólo de realizar una baja, sino de estimar cuál puede ser el valor medio
de la baja de todos los licitadores, para no excederse en un precio por debajo de la
media aritmética previsible.
5.4 Ventajas y desventajas
El concurso es sólo una de las posibles formas de contratación, que se justifica cuando
el volumen de contratación es grande, la reputación del convocante buena, y amplia la
oferta disponible (y, por tanto, el número de potenciales ofertantes).
Un concurso bien planteado y bien conducido obtiene muy buenos resultados, en

términos de la calidad de las ofertas recibidas y de la información en ellas presente.
También permite conseguir un equipo de trabajo a priori ideal, en condiciones
económicas razonables, al permitir comparar las ofertas de diferentes candidatos.
Sin embargo, todo lo anterior sólo se cumple cuando el Pliego y el concurso se

plantean de manera sensata, razonable y adecuada. Un Pliego donde el alcance del
trabajo a realizar no esté correctamente definido, aboca a ofertas oscuras, con altos
niveles de ambigüedad, al no quedar claro el detalle del propósito del contratante.
Igualmente, un concurso convocado en condiciones leoninas, de precio, tiempo o
alcance, suele conducir a recibir pocas ofertas (a veces ninguna), posiblemente de
mala calidad. Tampoco es conveniente que una empresa de escaso prestigio o reducido
volumen de contratación convoque concursos, al menos mientras su capacidad de
compra sea reducida (o, dicho de otra manera, mientras no sea percibida por los
suministradores como un buen Cliente).
Pero preparar un Pliego y convocar un concurso no es tarea tan sencilla como podría
parecer a primera vista. Redactar un buen Pliego; en especial la parte técnica, requiere
CAPITULO 2: DETECCIÓN DF OPORTUNIDADES 61
conocer perfectamente el problema a resolver, y la manera en que queremos

resolverlo. También exige evaluar el tiempo y el coste asociado a desarrollar el
trabajo. Por último, es preciso definir de antemano los criterios bajo los que se van a
evaluar las ofertas recibidas. Todo lo anterior se traduce en un fuerte esfuerzo que,
cómo no, lleva asociado un importante coste.
Además, el concurso no finaliza con el Pliego. Hay que convocarlo, para lo que se
requiere incurrir en costes de difusión (en prensa, o de manera directa), y a posteríori
recibir y evaluar las ofertas, de acuerdo con los criterios de valoración inicialmente
definidos, algo que, para hacerse bien, requiere un fuerte conocimiento técnico y un
importante esfuerzo.
5.5 Los concursos y la Administración
Ya que los concursos son, en teoría, la manera más eficiente y transparente de

adjudicar contratos, parece lógico que la mayor parte de los órganos de la
Administración, así como gran parte de las empresas públicas, utilicen habitualmente
esta fórmula para sus expedientes de contratación.
La transparencia es, a todos los efectos, una necesidad vital para una administración
que, por lo general, contrata miles de expedientes al año, por valor de muchos
millones de euros. La existencia de un procedimiento público, reglado y con criterios
de valoración fijados de antemano, aunque no impide por completo el fraude, sí
complica en gran medida las adjudicaciones basadas en criterios aleatorios, subjetivos
o corruptos.
En el caso español, la contratación de trabajos y suministros por parte de la

Administración está regulada por la Ley de Contratos de las Administraciones
Públicas (Real decreto Legislativo 2/2000, de 16 de junio), y por el Reglamento
General de la Contratación del Estado (Real Decreto 1098/2001, de 12 de octubre).
La Ley vigente en España cataloga a cada expediente de contratación a convocar

según cuatro parámetros:
Tipo de contrato. La legislación vigente diferencia entre:

> Contrato de obras.
> Contrato de gestión de servicios públicos.
> Contrato de suministros.
> Contrato de consultoría y asistencia, y de los servicios.
> Contrato de concesión de obras públicas.
^ Tipo de tramitación. Puede ser:

> Ordinaria.
> Urgente (necesidad inaplazable, o cuya adjudicación sea preciso acelerar
por razones de interés público).
> Excepcional (para acontecimientos catastróficos, de situaciones que
supongan grave peligro o de necesidades que afecten a la defensa
nacional).
^ Procedimiento de adjudicación. Distingue entre:

> Abierto. Cualquier licitante puede presentar una propuesta.
> Restringido. Sólo los licitantes "invitados" por la Administración pueden
presentar propuestas.
> Negociado. Se adjudica el contrato a la empresa justificadamente elegida
por la Administración, previa consulta y negociación de los términos del
contrato con uno o varios empresarios.
^ Forma de adjudicación. Puede ser mediante2J:

>* Subasta. El contrato se adjudica al licitador que, cumpliendo los
requisitos establecidos en el Pliego, oferte el precio más bajo.
> Concurso. El contrato se adjudica al licitante que, cumpliendo los
requisitos establecidos en el Pliego y en su conjunto, haga la proposición
más ventajosa, teniendo en cuenta los criterios establecidos en los Pliegos
(que generalmente son tanto técnicos como económicos).
5.6 Peticiones de información
Muchas veces, cuando el contrato es muy importante y el objeto del mismo es

complejo, el potencial Cliente publica el concurso en dos fases.
En la primera fase, conocida como solicitud de información'4, el contratante declara

su intención de celebrar el concurso, dando una idea del orden de magnitud de los
precios, del alcance preliminar de los trabajos y, en general, de cualquier otro aspecto
23
En la normativa anterior existía también la adjudicación mediante contratación directa,
cuando el número de posibles licitantes era muy reducido, el objeto del contrato muy
específico, o se veían involucrados aspectos relacionados con la Seguridad del Estado. Esta
forma de adjudicación, tradicionalmente limitada a contratos de escaso volumen económico,
está actualmente restringida al ámbito de las corporaciones locales.
24
También conocida como RFI, del inglés Request For Information.
de interés, y solicita a los potenciales ofertantes respuestas a su solicitud. Dichas respuestas son
ofertas en el sentido estricto de la palabra. Contienen una descripción técnica de cómo se harían
los trabajos, una propuesta de gestión y una valoración económica.
Estas respuestas le sirven al contratante para hacerse una idea sobre cuánto le pueden costar los
trabajos, cuáles son las dificultades técnicas más evidentes, cómo la resolvería cada ofertante o,
simplemente, cuántas empresas hay dispuestas a "competir" por el contrato.
Tras la solicitud de información, el potencial Cliente redacta una solicitud de oferta" clásica. Pero
esta solicitud suele ser mucho más elaborada que una petición de oferta simple, pues el redactor ha
obtenido mucha información de la fase anterior, y es capaz de abordar temas de especial
complejidad, solicitar un diseño concreto, proponer organizaciones industriales, o modificar los
precios (al alza o a la baja) en función de las indicaciones obtenidas. Es posible, incluso, que sólo
se invite a ofertar a los dos o tres interesados que mejor respuesta hayan dado a la solicitud de
información.
Las solicitudes de información demuestran lo competitivo que puede llegar a ser el mercado. Es
necesario invertir tiempo y esfuerzo en preparar dos respuestas (aunque en general, el esfuerzo de
preparar la propuesta es mucho menor que el de responder a la solicitud de información, donde ya
se hizo casi todo el trabajo), antes de llegar a saber si seremos "agraciados" o no con el contrato.
Por supuesto, este tipo de concursos sólo pueden plantearlos Clientes con un gran poder de compra
(por ejemplo, la Administración), y en contratos de elevado precio.
LECTURA. INFLACIÓN Y ESCALACION DE PRECIOS
En Jas economías capitalistas actuales, los pequeños desajustes entre la oferta y

la demanda, las variaciones puntuales del consumo y, en general, los errores en
las previsiones económicas provocan subktas generalizadas de precios en los
artículos y en los servicios. Estas subidas se miden mediante varios índices, de
los cuales el más conocido es el tristemente famoso "índice de Precios de
Lógicamente, acto seguido los trabajadores (y sus representantes sindicales)

reclaman subidas salariales, para compensar la pérdida de poder adquisitivo de
sus sueldos, debida ai efecto del 1PC.
Figura 2.5 Evolución del IPC (índice general, media nacional)

español, durante los últimos 30 años (Fuente, Instituto Nacional de
Estadística)
La subida de salarios vuelve a poner en manos de los consumidores una liquidez

que, a su vez, anula el efecto del incremento inicial de precios, por lo que éstos
deben aumentar de nuevo para equilibrar el consumo (demanda) con la oferta.
Aunque las políticas económicas de los Estados y sus gobiernos persiguen

IPC's natos, rara vez se logra alcanzar y sostener el incremento cero. El
resultado de este fenómeno es la llamada inflación, según la cual, la escalada
continua de precios y de salarlos hace que la moneda vaya perdiendo valor con
el tiempo, y que una unidad monetaria, hoy, sirva para adquirir menos bienes o
servicios que hace algunos años. ¿Quién no recuerda a nuestros padres o
abuelos, contándonos lo que se podía comprar hace 30 años con una peseta2"?
Pero, ¿cómo calculan los Gobiernos el IPC? En España, se encarga de ello el

Instituto Nacional de Estadística (fNE), ponderando la subida de los precios de
partidas de consumo que supongan una fracción sustancial del gasto de la cesta
de la compra nacional,.aplicable a ios bienes y servicios que consume toda la
© RA-MA CAPITULO 2: DETECCIÓN DE OPORTUNIDADES 65
población residente en viviendas fomÜiares. Así, se ponderan doce grandes

grupos, que a principios de 2004 quedan como sigue'7:
Alimentación y bebidas no alcohólicas

Bebidas alcohólicas y tabaco •3,n%
Vestido y calzado : 9,73 %
Vivienda 10,69 %
Menaje 6,41 %
Medicinas 2,68 %
Transporte 14,4%
Comunicaciones . 2,99 %
Ocio y cultura 6,76 %
Enseñanza 1,67%
Hoteles, restaurantes y cafeterías 11,23%
Otros 7,39 %
La figura 2.6 muestra de manera gráfica la ponderación de cada uno <fc estos
grupos en el cálculo del IPC general.
La inflación no sólo tiene efecto sobre la economía doméstica y sobre la nómina

de los empleados. También incide fuertemente sobre ios resultados económicos
de las empresas, en especial sobre aquellas que realizan grandes proyectos, a
largo plazo, donde entre gastos e ingresos pueden mediar muchos meses o
varios años.
Supongamos que, en una economía con una tasa de inflación en torno al 3%

anual (o 0,25% mensual), ingresamos 1 € a día dé hoy. Evidentemente,
podremos adquirir a cambio de esa cantidad bienes o servicios por dicho valor.
Pero pasado un número n de años, la inflación anual acumulada hará que con
dicho euro se puedan adquirir menos bienes o servicios. En concreta, su valor
actualizado (VA) transcurridos n años, sería de:
27
Los Gobiernos tienen la potestad para "retocar" los diferentes grupos de bienes y servicios y
modificar el peso especifico de cada uno de ellos en el IPC global, en función de las
variaciones percibidas en los bienes que la población adquiere en cada momento. Este
mecanismo, técnicamente razonable, se transforma en un poderosísimo instrumento electoral
en épocas de elecciones, cuando interesa presentar a los votantes valores de inflación
reducidos.
Figura 2.6 Factores que intervienen en el cálculo del IPC
Así, 1 € de hoy valdría 0,971 € (actualizados) transcurrido un año, 0,942 €

(actualizados) tran&amrkios dos, etc. Si volvemos a la figura 2.5, que muestra la
evolución del IPC en España durante los últimos 35 años, y aplicamos los
valores anuales para actualizar; según la fórmula anterior, 1 € hipotético de
1968, obtendríamos la gráfica de la figura 2.7, donde se muestra cómo su valor
real (por aquel entonces, 166,386 pesetas) ha disminuido progresivamente cada
año, tanto más cuanto mayor fuera el 1PC de dicho ejercicio, hasta llegar a "ser
capaz de adquirir" bienes correspondientes a sólo 57 céntimos de euro hoy en
día. Es decir, un 5,7% de to que habría podido adquirirse, con el mismo euro,
35añosatrás.
CAPITUL
O 2:
DETECCI
ÓN DE
OPORTU
NIDADES
67
Figura 2.7 Evolución del valor real (poder adquisitivo) de un

euro, durante los últimos 35 años (Fuente, Instituto Nacional de
Estadística)
xmgamos, ahora, un proyecto encargado a la empresa modelo Cae

Consulting, cuya duración es de, pongamos, 2 años naturales, por el que se
facturan 300.000 €, con un margen á& 20%. En teoría, el margen sería de
60.000 €. Sin embargo, veamos por qué el negocio no es tan bueno como a
lera vista pueda parecer.
'aos paga cada mes la nómina de sus empleados, los costes generales de la
empresa, y anticipa los costes de los materiales y suministros utilizados para el
proyecto. Supongamos que, de los 240.000 € de coste, 60.000 son de
suministros, que se adquieren al comienzo del proyecto, y los 18G.OQ0 €
restantes son sueldos y gastos generales, que se sufragan cada mes, a razón de
7.500 €. Supongamos también que la tasa anual de inflación es del 3%, y que el
proyecto se factura en un único pago, al finalizar el mismo. Ahora en concepto
de valor actual neto (VAN) no se aplica a una cantidad concreta, sino a un flujo
monetario determinado, con cada cantidad ingresada o egresada referida al
momento exacto en que se contabiliza su entrada o salida de caja. La siguiente
tabla muestra el flujo económico resultante, junto con el valor actual neto del
ijoglobal:
Mes 0. " 1-.000 ' ■ 1,000 67.500 67.500 0 0

Mes! 1,003 0,998, • 7.500 7,431 0 0
Mes 2■-; ims 0,995 - 7.5,00 7.463,. 0 0
Mesa1,008 O;993 . ' -7-500 • . 7.444 0
0
Mes 4 ','., 1,010 0,990 ' 7t5G0 • 7.425 0 0
Mes -5" 1,013 0,988 7S0Í3 7,407 0 0
Mesé 1,015 = 9,985 7.600 , , . 7,388 0 0
Mes 7 . t,018 "* 0,983 ' 7.5SO- 7,370 *~ 0 0
Mes 8 - ■ 1,020 . 0,980 7.500' ' s 7.352 ' 0 0
Mes 9 1,023 - ; "0,978 . f,SOO"" - 7.333 - 0 0
Mes 10 - 1,025 " \ OiWS 7.500 . 7.315 0 0
Mes 11tflm m . : 0,973. • ;_ 7300 7.297 0 0
Mes 12 1.03Q* - 0,970' 7.50Q 7.279 0 0
Ifes Í3:1.033 0,968 ^ " . 7.SQ0- ^ . - 7.260 0
0
Mes 14 1,036 0,966 7.500 ' 7J242 ' 0 0
Mes 15 1,038 «963 7.500. '7.224 . 0 0
Mes 16 1,041 "0,961 7,500 ■ 7.206 . 0 0
,Mes 171,043 0,958 ' 7.500 7.Í88 0 0
Mes 18 . 1J346 0,95ó 7.5ÓÓ" 7.170, 0 0
Mes 191,049 „ .0,954 \ „ . 7.S00 " „« X163 0 0
:
Mes 20 1,05! %M JJXtí 7-135 0 0
Mes 21 1,054 0.-949 7.500 7.117 0 0
Mes 22 1,056 0,947 7.500 7.099 0 0
Mes 231,05? ,0,944 . , . 7.5007.081 , 300.000 283.257
TOTAL (Euroá 240.000234.931 300.000 283.257
VALORACTUAL DEL MAfÊN (Euros) 48.326
De la tabla anterior se desprendé que el efecto de la inflación ha sido disminuir

los beneficios reales, actualizados, de 60.000 € a 48.326, esto es, se ha pasado
de un margen del 20%, a otro sensiblemente inferior, de poco más del 16%.
Por supuesto, existen diferentes mecanismos piara compensar en parte el efecto

negativo de la inflación. El trias evidente es escalar el precio de venta,
incrementando el mísnio paráûe, al calcular su valor actual, se compense la
pérdida de poder adquisitivo.
Pero además, la tabla anterior debe servir para extraer conclusiones acerca de
cómo gestionar los flujos de ingresos y gastos, de cara a maxirnizar el margen
actualizado. Supongamos que el Cliente de este proyecto no admite
escalacionés al precio. Aun así podemos mejorar ía situación, fijando una fonna
de pago consistente eti un 23% al comenzar tos trabajas, un 50% a la mitad del
proyecto, j el resto (25%) al finalizar. Supongamos también que podemos
adquirir Ía mitad de los suministros at principio del proyecto, y retrasar el resto
de adquisiciones hasta la mitad del proyecto. El nuevo flujo sería:
FLUJOS MONETARIOS ACTUALIZADOS, r-3% anual (0,257o mensual)
Gastos (Eur) VA_Sastos H Ingresos (Eur) VA_Ingresos
1,000 1,000 37.500 37.500

Mesl 0,99$ 7.500 7.481
Mes 2 1,005 0,995 7.500 7.463
Mes 3 1,008 0,993 7.500 7 444
Mes 4 1,010 0,990 7JO0 7.425
Mes 5 1,013 0,988 7.500 7.407
Mes 6 1,015 0,985 7.500 7-388
Mes 7 1,018 0,983 7.500 7.370
Mes 8 1.020 0,980 7.500 7J32
Mes 9 1,023 #,978 7.500 7.333
Mes 10 1$25 0,975 7300 7.315
Mes 11 1,028 0,fT3 7.500 7.297
Mes 12 1,030 0,970 37.500 36,39
Mes 13 1,033 0,968 7.500 3
Mes 14 Í.036 • ©,966 7.500 7.260
Mes 15 1,038 0,963 7.500 7.242
Mes 16 1,041 0,961 7.800 7.224
Mes 17 1,043 Q,95S 7.500 7.206
Mes 18 1,046 0,956 7.500 7,188
Mes 19 1,049 0,954 7.500 7,170
Mes 20 1,051 0,951 7.500 7.153
Mes 21 1,054 ff,949 7.500 7.135
Mes 22 1,056 0,947 7.M0 7.117
Mes 23 1,059 0,944 7.500 7.099
7.081
TOTAL (Euros) 240.000 300.000
234,046
VALOR ACTUAL DEL MARGEN (Euros)
Corno puede observarse, esta modificación «A la forma de pago ha hecht

mejorar el margen a un 19,1%, bastante mejor que el anterior 16,1%.
El efecto inflacionista es especialmente severo, como ya se ha apuntado, en

proyectos muy largos, pero también miando los tipos de interés son muy
elevados. En épocas en que la inflación ka rozado el 20%, el efecto sobre el
proyecto anterior habría sido nefasto. En concreto, aun en la hipótesis de pagos
adelantados y adquisición diferida de suministros, el margen del proyecto, con
una inflación del 20%, habría sido sólo del 14,9%.
CAPITULO 3
EVALUACIÓN DEL PROYECTO
1. INTRODUCCIÓN
Tras detectar una oportunidad de negocio hay que determinar hasta qué punto nos
resulta interesante ese trabajo. Puede que el futuro proyecto no encaje adecuadamente
en el tipo de actividad que desempeña la empresa, o puede que las condiciones de
alcance, plazo o precio del mismo no se adecúen lo suficiente a nosotros.
Además, cada empresa es un mundo aparte: tiene un tamaño concreto, un tipo de

personal determinado, una estructura de costes específica, y un sinfín de detalles y
peculiaridades que la diferencian de las demás empresas de su sector de actividad. Por
esta razón, un proyecto adecuado para una empresa puede no serlo para otra muy
similar, y donde una prevé beneficios sustanciales, la otra puede estar abocada a
pérdidas económicas.
La fase de evaluación de oportunidades consiste en analizar la viabilidad de que la

empresa compita por un proyecto concreto. Se evalúa el tipo de trabajo a realizar, el
coste que supondrá realizarlo y el tiempo que se precisará para ello. Y de ahí se extrae
el potencial precio de venta y, por tanto, el margen comercial resultante.
A partir de dichos datos es posible tomar una decisión (razonada) acerca de la

conveniencia o no de presentar una oferta al Cliente y, por tanto, de competir por el
contrato.
2. EVALUACIÓN Y DECISIÓN PRELIMINAR
Antes de ponernos a preparar una oferta para el Cliente hay que tener en cuenta que:
Y no es sólo el coste laboral y material de asignar recursos al preparar una propuesta.

También hay que tener en cuenta el coste de oportunidad de las personas y los medios
que, de no estar preparando esa oferta, posiblemente estarían trabajando en algún otro
proyecto, sí remunerado.
Por eso, antes de lanzarnos en picado a responder a una petición de oferta hay que
considerar, grosso modo, si realmente nos interesa y tenemos posibilidades de
conseguir el trabajo. Probablemente, en sólo unos minutos o, a lo más, con un pequeño
análisis podremos responder a un número de preguntas que tal vez nos hagan desistir
de preparar la propuesta, si detectamos de antemano que no es lo suficientemente
interesante. Así, habría que considerar, al menos, los siguientes factores:
> ¿Disponemos de los conocimientos necesarios para realizar los trabajos

en cuestión y, en caso negativo, podemos obtenerlos a tiempo y a coste
razonable?
> ¿Disponemos de los recursos materiales y humanos necesarios para
realizar los trabajos, o podemos adquirirlos o subcontratados a un coste
razonable?
> ¿Somos competitivos en el mercado, y podemos ofrecer al menos lo
mismo, o más, que otros posibles ofertantes?
> ¿Tiene el Cliente algún proveedor favorito, candidato principal a
adjudicarse el contrato? En caso afirmativo, ¿tenemos alguna posibilidad
de batirle, en precio o condiciones (técnicas, financieras, temporales,
etc.), y que el proyecto siga siendo rentable?
> ¿El contrato, en el precio y las condiciones previstas, es consistente en
precio y económicamente rentable?, es decir, si en dichas condiciones
es posible obtener un beneficio de su realización.
> Concurrir a la oferta y obtener el contrato, ¿qué coste de oportunidad
tiene?, ¿puede impedirnos atender a otros Clientes o a otros proyectos,
más interesantes para nuestra empresa?
Por último, aunque alguna de las preguntas anteriores nos pudiera hacer desistir de
ofertar, hay que considerar también si:
> Obtener el contrato en cuestión, ¿dotaría a nuestra empresa de una

mejora competitiva, en términos de adquisición de nuevos
CAPITULO 3: EVALUACIÓN DEL PROYECTO 73
conocimientos, nuevas tecnologías, o mejora de la reputación que luego

pueda facilitar acceder a nuevos contratos?
Si, tras el análisis anterior, el resultado es que merece la pena ofertar, habrá que seguir
un procedimiento (mostrado en la figura 3.1) que nos permita:
> Analizar exactamente el trabajo a realizar.

> Evaluar el coste de llevarlo a cabo.
> Fijar un precio de venta (o verificar que el precio fijado por el Cliente es
suficiente para compensar los costes, dejando un beneficio razonable).
> Preparar un documento, llamado "documento de oferta" o "propuesta",
donde se le transmita al Cliente la información que, como resultado del
proceso anterior, le permita juzgar y evaluar nuestra capacitación para
llevar a cabo los trabajos.
Figura 3.1 Proceso de preparación de una oferta

3. ESTIMACIÓN DEL COSTE Y EL PRECIO DEL

PROYECTO
Tomemos el primero de los procesos mostrados en la figura 3.1. Lleva por nombre
"Estimar costes y gastos". Difícilmente podremos calcular el beneficio de un proyecto,
salvo que conozcamos cuánto nos va a costar llevarlo a cabo.
Evidentemente, nadie (o, más bien, nadie en sus cabales) querría vender un bien o
servicio por menos de lo que cuesta2*. Si preguntamos a un albañil cuánto nos cobrará
por levantar una pared de dos metros por uno, hará un rápido cálculo sobre cuánto le
cuesta un ladrillo, cuántos ladrillos necesita, cuánto gastará en cemento, arena y agua,
lo que tardará en hacer la pared, y lo que quiere ganar por ello. Sólo después nos dirá
el precio, que calculará como el coste anterior, probablemente añadiendo un pequeño
margen para imprevistos.
i
i En general, el precio de todo proyecto debería calcularse de igual manera que en el

ejemplo anterior, es decir, siguiendo la secuencia que se indica en la figura 3.2.
Figura 3.2 Estimación del coste y el precio de un proyecto
28
Salvo que de lo que se trate sea de una campaña de marketing puntual, o de incrementar la
cuota de mercado mediante una política de precios agresivos (bajo la esperanza de que al
vender más, el coste unitario disminuya y compense las pérdidas). Aparte de estos casos
puntuales, no vamos a tener en cuenta aquí motivaciones "extrañas" que nos puedan llevar a
vender algo por debajo de su coste. Este libro describe sólo técnicas básicas, y deja factores
distintos, por lo general al margen de la ley, para otro tipo de lecturas.
En la figura anterior se contemplan dos factores que intervienen en el coste del

proyecto: las horas de trabajo del personal, y los costes y gastos adicionales. Una vez
conocido el coste total del proyecto, el precio de venta se calcula añadiendo al mismo
el beneficio esperado que se pretende obtener de la realización del trabajo.
Evidentemente, dicho beneficio sólo se realiza si somos capaces de llevar a cabo el
trabajo estrictamente con los recursos humanos y materiales previstos.
3.1 Análisis del trabajo a realizar
El albañil del ejemplo anterior lo tiene bastante fácil para identificar las tareas
necesarias para levantar la pared. Aun así, corre el riesgo de olvidar alguna de ellas,
que pueda suponerle un tiempo y un esfuerzo no contemplado, y que dé al traste con
su intención de obtener beneficio del trabajo realizado.
Por ejemplo, nuestro hombre podría olvidarse de que tiene que ir al almacén de
material a por los ladrillos, cemento y arena, y de que para ello necesita un vehículo
apropiado. También podría olvidar que tiene que desmontar la valla actual y retirar el
material viejo, o que ha de hacer una pequeña cimentación, debajo del nuevo muro.
Cualquiera de estas tareas requerirá tiempo, esfuerzo y, a veces, material o equipo
adicional. Y no tener en cuenta dicho esfuerzo o sobrecoste, le puede suponer minorar
los beneficios esperados.
En proyectos más complejos, en especial donde lo que se venden son servicios,

identificar "de cabeza" las actividades y tareas necesarias es aún más complicado, y
requiere un tipo de análisis más estructurado y formal, menos proclive a olvidar tareas
que el método "mental". La manera más habitual de realizar dicho análisis es
descomponer el proyecto en actividades independientes o paquetes de trabajo,
compuestos por tareas y, si es preciso, sub-tareas. Esta descomposición permite:
> Analizar detallada y organizadamente el trabajo a realizar.

> Pre-asignar recursos de personal, materiales y temporales a la ejecución
de cada tarea.
> Formalizar los requisitos previos y los resultados a obtener de cada
tarea (incluyendo documentación, tareas interrelacionadas, medios
materiales, etc.).
> Asignar un responsable a cada tarea.
El primer paso para realizar este análisis es dibujar un árbol de tareas que describa
(de forma general, para refinarlo más tarde) la estructura de las actividades,
conceptualmente distintas, a abordar dentro del proyecto a realizar. Este árbol o
estructura de tareas es el equivalente conceptual de un organigrama en una empresa:
76 DIRECCIÓN Y GESTIÓN DH PROYECTOS
refleja las áreas de actividad que hay, cuál es su dependencia funcional, y quién es el
responsable de cada una de ellas.
3.1.1 ESTRUCTURA DE PAQUETES DE TRABAJO
Para convertir el flujo de actividades en un árbol o estructura de paquetes de trabajo,

se agrupan las actividades en grandes bloques, separando aquéllas conceptualmente
distintas, e independientes entre sí.
La generación .de flujos y árboles de tareas es una cuestión muy personal, y muy
influida por la experiencia de cada uno. Difícilmente, salvo que el proyecto sea muy
sencillo, dos personas distintas llegarán por separado a estructuras idénticas (de ahí
que algunas organizaciones, tales como la Agencia Espacial Europea, ESA, o el
Departamento de Defensa norteamericano, DoD, hayan propuesto modelos o super-
estructuras para normalizar los árboles de tareas, que luego cada proyecto adapta a sus
necesidades).
Es buena práctica que todo proyecto incluya un paquete de gestión del que dependan
los demás paquetes del proyecto. En el paquete de gestión se llevan a cabo y
(previsiblemente) resuelven todas las actividades propias tanto de la dirección como
de la gestión propiamente dicha, tal y como se describieron en el apartado 4 del
capítulo 1. Típicamente, la gestión de un proyecto suele consumir (dependiendo del
proyecto) entre un 5% y un 15% del presupuesto global del mismo, por lo que no es
conveniente despreciar estas actividades.
Al igual que sucede con el organigrama de una empresa, el árbol de paquetes de

trabajo debe ser lo suficientemente sencillo como para simplificar al máximo la
gestión y minimizar las interfaces entre los miembros del equipo de trabajo. Sin
embargo, debe ser lo suficientemente elaborado y completo como para describir todas
y cada una de las tareas del proyecto (al nivel correspondiente), segregando en
paquetes distintos actividades conceptualmente diferentes. En cuanto a las tareas
individuales, puede enumerarse un conjunto de condiciones que debe cumplir un
conjunto de actividades para que pueda considerarse un paquete de trabajo:
> Deben ser lo suficientemente sencillas como para permitir y facilitar la

gestión (planificación, monitorización y control) de las mismas. Si la
descomposición es excesivamente detallada, la fragmentación resultante
desperdicia recursos utilizándolos de forma poco eficiente (y, en
concreto, complica y encarece las labores de gestión y dirección del
proyecto).
> Deben ser lo suficientemente completas como para permitir que dicha
gestión se pueda realizar de manera autónoma. Si la descomposición no
es lo suficientemente detallada se diluyen los flujos de trabajo y se corre
CAPÍTULO 3: EVALUACIÓN DEL PROYECTO 77
el riesgo de no dimensionar correctamente el esfuerzo o de no asignar

claramente las responsabilidades.
> Deben estar asignadas a un responsable único (pero dicha persona puede
ser, a la vez, responsable de varios paquetes de trabajo).
> Deben tener entradas y salidas (documentos, productos, etc.)
identificadas y concretas.
3.1.2 DESCRIPCIÓN DE LOS PAQUETES DE TRABAJO
Tras identificar los paquetes de trabajo en que se va a estructurar el proyecto, conviene

abordar un segundo nivel de detalle, consistente en describir, a grandes rasgos, el
alcance, contenido y particularidades de cada uno de ellos.
La descripción de los paquetes de trabajo no sólo sirve para analizar el alcance del
trabajo a realizar. Sirve, sobre todo, para estructurar el análisis de! trabajo a llevar a
cabo, y para detectar si hay alguna inconsistencia (falta o sobra algún paquete) en el
árbol de paquetes propuesto. Además, sirve también para valorar el esfuerzo y
estimar el coste.
La descripción de cada paquete de trabajo incluye, como si de un sub-proyecto se

tratase, toda la información necesaria sobre el mismo que, dejada en manos del
responsable del paquete, le permitirá hacerse una idea clara de los objetivos del
paquete, de las interfaces con otros paquetes de trabajo, y la planificación concreta de
sus actividades. Sirve, pues, para dotar a cada miembro del equipo de trabajo de una
visión general de la parte del proyecto que le afecta.
En la descripción de un paquete de trabajo debe aparecer, al menos, la siguiente

información básica:
> Proyecto al que pertenece (es conveniente adjuntar la estructura de

paquetes del proyecto completo).
> Número y título del paquete de trabajo.
> Responsable.
> Descripción general del alcance y objetivos del paquete de trabajo.
> Fecha de comienzo y de final del paquete de trabajo.
> Entradas al paquete de trabajo (elementos con los que se debe contar
antes de comenzar los trabajos, del tipo especificaciones de usuario,
materiales y equipos, productos, documentación concreta, etc.).
> Salidas del paquete de trabajo (elementos que se obtienen como resultado
de la ejecución de las actividades del paquete de trabajo, incluyendo
documentos generados, planos, equipos, etc.).
>• Tareas a ejecutar (conjunto de actividades que componen el paquete de

trabajo, pero que están excesivamente interrelacionadas entre sí como
para constituir un paquete de trabajo en sí mismas. En paquetes de trabajo
de nivel jerárquico superior, las tareas son, a su vez, los sub-paquetes de
trabajo que de él cuelgan).
> Restricciones, requisitos, regulación aplicable y, en general, cualquier
condicionante que pueda ser de interés.
> Actividades excluidas, que en principio parecería razonable considerar
dentro del alcance del trabajo pero que por razones contractuales, o de
cualquier otra índole, no formen parte del mismo.
Cualquier otra información al respecto (esfuerzo previsto, dependencia de otros

paquetes, relaciones con terceros, etc.) puede ser, también, de gran utilidad.
La figura 3.3 muestra un posible formato de descripción de un paquete de trabajo, de

acuerdo con las consideraciones anteriores.
NOMBRE DEL PROYECTO
Referencia : Edición : Fecha :
PAQUETE DE TRABAJO
RESPONSABLE: ESFUERZO:
COMIENZO : FINAL :
ENTRADAS:
Figura 3.3 Descripción de un paquete de trabajo

© RA-MA CAPITULO 3: EVALUACIÓN DEL PROYECTO 79
Al reunir la descripción de todos los paquetes de trabajo de un proyecto concreto,

pueden surgir inconsistencias debidas a la incorrecta definición de la estructura del
proyecto, proporcionando una muy valiosa ayuda para detectar y corregir tales errores.
3.2 Esfuerzo requerido
La descripción de los paquetes de trabajo reseñada en el apartado anterior permite

identificar, si la descomposición y descripción están correctamente realizadas, todas
las actividades involucradas en el proyecto.
A continuación, ya se está en condiciones de valorar el esfuerzo asociado a la

realización de dichas tareas o, dicho de otra manera, las personas, y el tiempo que tales
personas necesitarán, previsiblemente, para completar el trabajo que les corresponde.
La estimación de horas permite conocer cuál será una de las partidas del coste de la
realización del trabajo ofertado. Permite consolidar la información de esfuerzo
derivada de la descripción de los paquetes de trabajo que, junto con los demás gastos
de proyecto conforma el coste total del mismo (y, por tanto, el precio de venta ideal al
Cliente).
A la hora de dimensionar el esfuerzo, es conveniente clasificar el mismo según las

distintas categorías profesionales del mismo, pues el coste real es muy distinto para
cada una de ellas (una hora de secretaria le cuesta a nuestra empresa modelo, Caos
Consulting, 10,66 €, mientras que una hora de un ingeniero sénior cuesta 35,04 €, más
del triple. Además, algún consultor experto en un tema concreto puede sobrepasar
fácilmente los 200 € por hora de trabajo)29.
También es muy conveniente valorar el esfuerzo teniendo en cuenta las

heterogeneidades del equipo de trabajo (no todas las personas rinden igual), y los
posibles problemas que puedan surgir, y que hagan que el coste se incremente. Un
error común a la hora de determinar el esfuerzo necesario para un proyecto es pensar
que todos los miembros del equipo de trabajo se van a ilusionar por igual con el
proyecto, y van a rendir como lo haríamos nosotros en su situación. Con el tiempo, el
responsable se da cuenta de que de cada persona rinde de una manera y a un ritmo
determinado, y se ve afectado por factores externos (sociales, laborales, familiares,
29
Como siempre, ante el vicio de pedir está la virtud de no dar. Un reconocido consultor
empresarial norteamericano pedía 5.000 dólares sólo por ponerse al teléfono. Sus tarifas
horarias son también de escándalo, pero se supone que sus análisis y consejos ahorran a las
empresas que le solicitan ayuda varias veces el coste de sus servicios. Evidentemente, no todo
el mundo necesita (ni puede) pagar cifras tan elevadas.
DIRECCIÓN Y GESTIÓN DE PROYECTOS
etc.) que pueden incrementar notablemente el esfuerzo requerido

30
previsto en principio
Sin embargo, también es peligroso dimensionar el esfuerzo en exceso, puesto que se

traduce en un incremento del precio de oferta, lo que puede llevar a dejar de ser
competitivos, y ocasionar la pérdida del contrato.
No hay que olvidar que se debe tener en cuenta no sólo el esfuerzo dedicado a ejecutar
el proyecto en sí, sino también las tareas adicionales asociadas, tales como reuniones,
cursos de formación al Cliente, tiempo invertido en viajes o períodos de garantía
(especialmente en proyectos de desarrollo de software). Estas tareas adicionales son
fáciles de olvidar, pero muy costosas en cuanto a dedicación de recursos (en especial
humanos), por lo que pueden abocar directamente al fracaso económico.
La figura 3.4 muestra un formato útil para estimar el esfuerzo (en horas de trabajo)
asociado a cada actividad o paquete de trabajo. Así se facilita estimar por separado y
reducir el error global (basándose en el principio de que es más fácil estimar lo que se
tarda en levantar un metro cuadrado de pared que el tiempo necesario para construir el
edificio completo). Además, con ello se facilita simultáneamente el control del avance
de las diferentes tareas y la detección de sobre-esfuerzos en cualquiera de ellas, tan
pronto se produzcan.
La estimación anterior, además, permite realizar alguna comprobación adicional sobre

las hipótesis manejadas, que puedan proporcionar una indicación de que alguno de los
pasos realizados no fue correcto. Así por ejemplo:
> El número total de horas resultante tiene que ser consistente con el
equipo de trabajo previsto y con la duración del proyecto. Como regla
general, el esfuerzo total tiene que ser comparable o ligeramente inferior
al producto del número de horas de trabajo disponibles en el período de
ejecución del contrato, multiplicado por el número de personas que
componen el equipo de trabajo. De esta manera se garantiza que el
personal no se verá excesivamente sobrecargado de trabajo, y que no
habrá un exceso considerable de tiempos muertos, que suelen perjudicar
notablemente el resultado económico del proyecto.
i0
Es buena práctica (aunque contraria al espíritu del concepto de categorías profesionales)
poner "nombre y apellidos" a las horas de esfuerzo previstas en un proyecto. La experiencia
demuestra que una misma tarea puede requerir el doble de horas de trabajo si la realiza una
persona que, incluso teniendo la misma capacitación y experiencia, está menos motivada o es
menos eficiente que otra.
1
2
3
4
5
6
7
8
9
III
II
12
13
14
15
16
17
11
19
20
Figura 3.4 Estimación del esfuerzo necesario para llevar a cabo un

proyecto
La distribución de la carga de trabajo entre categorías tiene que ser

consistente con el tipo y alcance del proyecto. En un proyecto de
desarrollo software, la mayor parte del trabajo puede y debe hacerla
personal de categoría IJ (ingeniero júnior) o inferior, mientras que en un
contrato con gran parte de trabajo de instalación, fabricación y montaje,
el mayor porcentaje de trabajo debería hacerse por parte de personal
técnico (TE). En un proyecto de consultaría, lo normal es que la mayor
parte de las tareas las realicen ingenieros sénior, con ayuda de ingenieros
júnior, y así sucesivamente. En general, al igual que la composición de
personal de una empresa debe ser de tipo piramidal (pocos directivos,
más ejecutivos, mucho personal laboral), el equipo de trabajo de un
proyecto debe reflejar un cierto equilibrio entre la dedicación requerida
para el personal de cada categoría, con poco esfuerzo del personal más
cualificado, y más esfuerzo del personal "de base", pues parece lógico
pensar que en la distribución de esfuerzo según categorías debe primar la
participación de personal lo más "económico" posible.
> Por último, aunque algo mucho más complejo y sutil de determinar, está
la proporción de esfuerzo entre paquetes de trabajo o, más
concretamente, entre áreas funcionales del proyecto. Supongamos un
proyecto cualquiera para el diseño y desarrollo de un nuevo producto de
material plástico. Los paquetes de trabajo podrían ser, por ejemplo,
gestión, especificación, diseño y desarrollo. Típicamente, la mayor parte
del esfuerzo se destinaría al desarrollo del producto, seguido por el diseño
y, tal vez, la especificación. La gestión no debería ocupar más allá del 5
al 15% del total. Valores muy apartados de esta "regla general" vendrían
a indicar una estimación (tal vez) incorrecta del trabajo.
LECTURA. RELACIONES DE SUSTITUCIÓN DE PERSONAL
Los eosíes de personal son diferentes en función de la categoría del mismo, que
generalmente va ligada a la formación y a la experiencia. La norma general es
emplear en un proyecto al personal de menor eualificadón posible, con el fin de
minimizar los costes del mismo.
Así, por ejemplo, el coste horario (sueldo más cargas sociales) más los gastos
generales de un ingeniero sénior de Caos Consulting es de 59,2 €/hora, mientras
que el coste de un ingeniero júnior es de sólo 36,0 €/hora. Supongamos que un
cliente contrata a Caos un trabajo que exige 100 horas de esfuerzo. El coste de
ejecutarlo con cada categoría de ingeniero sería:
i 00 horas x 59,2 — 5.920 €, con un ingeniero sénior, y

100 horas X36,0 == 3.600 6, con un ingeniero júnior
TÍO, parece razonable utilizar a un ingeniero júnior para el trabajo, y iones al

ingeniero sénior. O, mejor aún, ejecutar todos los trabajos con igenieros
júnior, y despedir a ios más veteranos. Incluso, prescindir de ingenieros y
utilizar personal técnico o auxiliar.
Evidentemente., la situación anterior no es realista. Las empresas contratan y

mantienen a personal de categorías superiores porque disponen de la
experiencia y la práctica que los más jóvenes no han adquirido, o que los de
menor cualíftcación no están en condiciones de adquirir, En concreto, los
empleados de categorías superiores son (en teoría) capaces de resolver
problemas que los demás no serían capaces de abordar correctamente, o que
©RA-MA CAPÍTULO 3: EVALUACIÓN DEL PROYECTO 83
tardarían más tiempo en resolver. Esto nos lleva al problen

sustitución de empleados de diferentes categorías:
Supongamos que el ingeniero sénior de Caos, por su experiencia y habilidad,

capaz de ejecutar en k horas eí mismo trabajo que el ingeniero júnior tarda ui
hora en terminar (la lógica nos dice que k habrá de ser menor <|ue 1). El valor k
que iguala los costes se denomina relación de sustitución y, en nuestro case
viene dado por la ecuación:
k x59 ,2 = 1x3 6, 0 ' 2T
= ü.6l
Es decir, si un ingeniero sénior tarda 0,66 horas <unos 3? rnrrrutos) en termina

el trabajo en el que un júnior ocupa una hora, da igual asignar a uno u otro a
dicha tarea. Si el valor de k es menor que 0,61, convendrá asignar ai ingeniero
sénior a dicha tarea, y si es mayor será más rentable ocupar al ingeniero júnior
en la misma.
Lo anterior, llevado al extremo, se produce cuando el ingeniero júnior no

capaz de ejecutar el trabajo del ingeniero sénior y, simplemente, ta relación de
sustitución deja de tener sentido (el valor de k tiende a cero).
¿Y cómo se conjuga lo anterior en un proyecto típico? Es de suponer que todo

proyecto involucra actividades de mayor y de menor nivel. En las actividades de
mayor nivel, que requieren mayor capacitación y experiencia, un empleado de
mayor categoría será mucho más eficiente que otro de menor coste, por lo que
parece razonable utilizar empleados experimentados para ejecutar las mismas.
Sin embargo, gran parte de todo proyecto consiste en labores que requieren
menos especialización, y en las que la eficiencia de un sénior no es mucho
mayor que la de un empleado de menor categoría (llevado al extremo, no es
muy probable que un abogado experto haga muchas más fotocopias por hora
que un abogado pasante). Es en estas labores donde debe concentrarse el
personal de menor categoría, para reducir el coste global del proyecto.
Con el paso del tiempo, y según adquiere experiencia, el ingeniero júnior ve

decrecer el valor de su k respecto a personal recién contratado (sin experiencia),
frente a los que comienza a ser más eficiente. En este momento, podrá
comenzar a encargarse, paulatinamente, de tareas de mayor complejidad y
responsabilidad.
3.3 Otros costes y gastos
El siguiente capítulo de costes de un proyecto atañe a las partidas presupuestarias que

no van destinadas a los costes directos de personal de la empresa, y que incluye tanto
los materiales y bienes a adquirir a terceros como los gastos por viajes y
desplazamientos, comidas, gastos financieros, uso y mantenimiento de ordenadores,
etc. Cada empresa estructura de manera diferente estos costes, por lo general en
función del tipo de proyectos que realiza, definiendo con más nivel de detalle aquellos
tipos de costes más importantes o más significativos dentro de sus actividades.
A título de ejemplo, clasificaremos los costes en tres partidas diferentes:
Subcontrataciones: Son costes de personal, ajeno a la empresa, pero que

interviene, bajo nuestra responsabilidad ante el Cliente, en el proyecto. Son
consultores externos o personal de otras empresas a los que se subcontrata
actividades concretas. Por lo general, se utilizan dos modalidades de
subcontratación: un volumen de trabajo determinado a un precio fijo (sin tener
en cuenta el esfuerzo real que finalmente dediquen), o un trabajo concreto a un
determinado precio por hora. En cualquier caso, al personal subcontratado no
le son aplicables los gastos generales de la empresa.
Costes internos: Al presentar a la empresa modelo Caos Consulting, en la

lectura del capítulo 1, se hizo mención a los costes de consumibles, servicios
informáticos, etc., que son proporcionales al esfuerzo real que se dedique y al
consumo de recursos concretos.
Otros costes: En esta partida se incluyen todos los demás costes y gastos que
no tenían cabida en los dos tipos anteriores. Dentro de ella, cada empresa hará
las clasificaciones que estime oportuno, como por ejemplo:
> Material y equipo: son los elementos físicos necesarios para completar
el proyecto. Pueden ser para uso propio, o suministros que, por lo
general, se le entregan al Cliente al terminar el proyecto. Por ejemplo,
serían suministros los ordenadores y equipos, cableado, y programas
software que se adquieren para instalarlos en las oficinas del Cliente.
Serían de uso interno (y no hay que entregarlos al Cliente al terminar el
trabajo) los libros adquiridos para uso de los programadores de Caos, las
carpetas para archivar la documentación, etc.
>■ Viajes y estancias: son costes en los que incurre el personal para realizar
el trabajo, incluyendo los desplazamientos a la oficina del Cliente o a
cualquier otro sitio que sea necesario, las dietas correspondientes, etc.
> Otros gastos: se incluye aquí, por último, los gastos adicionales que no
tenían cabida en los apartados anteriores, tales como adquisición de
documentación, las comidas u obsequios de empresa (gastos de
representación), etc.
3.3.1 SUBCONTRATACIONES
Como ya se ha dicho, en el capítulo de gastos directos es preciso tener en cuenta el

coste de las subcontrataciones de personal/trabajo externos a la propia empresa. En
general, parece deseable mantener para nuestro personal el máximo posible de trabajo
a realizar, y evitar subcontratado a otros, que serían los principales beneficiarios del
margen económico del proyecto. Sin embargo, existen diferentes razones por las que
puede ser aconsejable subcontratar actividades concretas del proyecto a realizar:
^ Para aportar y utilizar los conocimientos de profesionales de reconocido

prestigio (consultores) en el campo técnico del trabajo a realizar.
^ Para completar el área de conocimiento de nuestra empresa.
*" Para incorporar infraestructura material o humana que sólo se requiere durante
la vida del proyecto, y no merece la pena adquirir o contratar.
=** Para abaratar costes, ya que cuando nuestro campo de especialización no

incluye una actividad concreta, lo más lógico es que una empresa
especializada sea capaz de ejecutar ese trabajo a menor coste del que nos
supondría hacerlo a nosotros mismos (véase la lectura sobre relación de
sustitución de personal, en este capítulo).
No obstante, no hay que olvidar que las subcontrataciones, en general, suponen

compartir el beneficio con terceros ajenos a la empresa, bien en su carácter
corporativo o personal, y que, por ende, el criterio de optimización de beneficios
conduce a restringir las subcontrataciones a aquellos casos en los que sea
estrictamente necesario.
Lo anterior es evidente a nivel de empresa, pero no siempre lo es desde la perspectiva

de un proyecto cualquiera. En este último caso, el Director de Proyecto puede observar
cómo, al no estar afectado por el coeficiente de costes generales, a veces es más barato
subcontratar a un tercero el trabajo que podría realizar el personal contratado por la
empresa, que tal vez ni siquiera esté suficientemente especializado. Podría incluso
surgir la tentación de subcontratar todo (o la mayor parte de) el alcance del proyecto.
Sin embargo, desde el punto de vista más general, este planteamiento puede dar lugar
a varios inconvenientes, entre ellos:
> Desde la perspectiva de la empresa, la visión "estrecha" del Director de

Proyecto ocasiona que el personal contratado esté inactivo, sin generar
ingresos pero incurriendo en costes y, además, sin adquirir experiencia
real.
> Desde el punto de vista del proyecto, el personal ajeno es difícil d e

manejar, especialmente en situaciones de crisis. Su falta de identificación
con la organización, la ausencia de una jerarquía y autoridad claras y,
sobre todo, la carencia de mecanismos coercitivos, pueden acabar
convirtiendo en inmanejable el proyecto.
> Además, el personal ajeno trabajando en un proyecto propio es una
magnífica válvula de escape para los conocimientos, contactos, e incluso
datos sensibles de la empresa. Y un buen comportamiento del personal
ajeno, incluso, puede ocasionar que sean adjudicatarios directos de
futuros contratos que, de otra manera, podrían haber seguido vinculados a
nuestra organización.
Otro aspecto a tener en cuenta es que, cuando subcontratamos tareas, estamos

transfiriendo trabajo a terceros, pero no por ello dejamos de ser responsables del
mismo ante el Cliente. Somos, pues, responsables del cumplimiento de las
obligaciones de nuestro subcontratista, al que habrá que especificar adecuadamente el
trabajo a realizar y controlar su correcta evolución.
En este sentido, al subcontratar trabajo nos convertimos en Clientes del subcontratista,

y es necesario tener en cuenta todos los factores que nuestro Cliente tuvo en
consideración al contratarnos (a nosotros) el trabajo, incluyendo la especificación del
alcance de la parte a subcontratar, la solicitud de ofertas, la evaluación de las mismas y
la negociación del contrato. Las reglas más básicas a la hora de subcontratar trabajos
incluyen:
Definir exhaustivamente el alcance de los trabajos a subcontratar.
Identificar claramente las responsabilidades del subcontratista, incorporando

incluso cláusulas contractuales de incumplimiento y responsabilidad.
Prever alguna válvula de escape para que un incumplimiento por parte de

nuestro subcontratista no provoque la quiebra técnica o económica de nuestro
proyecto ante el Cliente (aunque esto no siempre es posible), reservando algún
presupuesto y algún plazo de tiempo para, nada más detectar un problema,
poder activar medidas de contingencia (subcontratistas alternativos, dedicar
personal propio, etc.).
Prever y valorar los costes de interfaz con nuestro subcontratista. Estos costes
suelen ser a menudo infravalorados, al no tener en cuenta el tiempo que "se
pierde" transfiriendo información al subcontratrista, revisando sus
contribuciones, etc. En general, dependiendo del tipo de proyecto y relación
existente, no es mala práctica asumir un 10% del coste del subcontrato como
costes de interfaz.
CAPITULO 3; EVALUACIÓN DEL PROYECTO 87
3.3.2 COSTES VARIOS
La partida de costes y gastos varios es, probablemente, la más difícil de estimar, no

sólo porque el importe del coste rara vez se conoce de antemano, sino porque es muy
fácil no considerar (por olvido o por imposibilidad de anticiparlo) algún concepto
aislado.
Los costes varios son, a modo de analogía, la parte sumergida del iceberg de costes.
Tal y como muestra la figura 3.5, al evaluar el coste de un proyecto rápidamente
aparecen los conceptos "fáciles": los asociados a personal, subcontrataciones y
suministros. No obstante, por debajo de ellos es fácil que haya toda una miríada de
costes de diferente naturaleza y entidad, que pueden (salvo que se estimen
adecuadamente) dar al traste con el balance económico del proyecto.
Figura 3.5 Modelo del iceberg, de costes ocultos
Los diferentes costes y gastos deben ser cuidadosamente valorados, asumiendo valores
reales típicos y, en cierto modo, el escenario de peor caso. Por ejemplo, sí el proyecto
supone viajar un cierto número de veces a otra ciudad, es conveniente estimar el
precio tarifa completa en avión, y no partir de la base de que podamos aprovechar
tarifas reducidas de tipo turístico, mal ajustables a los horarios, necesidades y prisas de
un profesional. Tampoco es mala idea prever algún desplazamiento adicional a los
estrictamente necesarios, pues suele ser frecuente tener que organizar reuniones
DIRECCIÓN Y GESTIÓN DE PROYECTOS
extraordinarias o presentaciones no previstas (especialmente, cuando surgen

problemas durante la ejecución del proyecto).
También habrá que ser algo tolerante en cuanto a los gastos del personal desplazado, y
no pretender ahorrar obligándole a pernoctar en fondas o desplazarse en autobús
(bastante tienen ellos con estar fuera de casa donde, seguramente, estarían mucho
mejor)3'. Además, es típico tener alguna atención, de vez en cuando con el Cliente,
para allanar el camino hacia la aceptación del proyecto o la consecución de otros
futuros, así como con el personal involucrado de nuestra empresa, cada vez que se
cumpla un hito importante de manera satisfactoria.
Por último, hay costes ocultos que, a primera vista, son difíciles de detectar, salvo a
través de la experiencia. Si, por ejemplo, refiriéndonos a la figura 2.2, de anuncios de
convocatoria de concursos, observamos en el de la izquierda que "El abono de los
gastos de publicidad del presente concurso correrá a cargo del adjudicatario de éste".
Esta pequeña frase significa que el adjudicatario habrá de satisfacer el coste del
anuncio en el BOE (y, tal vez, en otros boletines en los que se haya publicado
simultáneamente), incrementando los costes del proyecto en unos 450 i2 €, que
suponen un nada desdeñable 1,8% del presupuesto del contrato (sin IVA).
Es habitual que un significativo porcentaje de tos costes de un proyecto esté

destinado a la adquisición de bienes, equipos y servicios, materiales y
suministros en general, necesarios para el proyecto y que nuestra empresa debe
adquirir de diferentes proveedores.
Negociar correctamente cori los proveedores forma parte de la gestión cotidiana

del proyecto, y su importancia en la cuenta de resultados es similar a la del
cómputo del esfuerzo humano. Al fin y al cabo, sí, por ejemplo, el 30% del
presupuesto del proyecto se emplea en adquirir bienes a terceros, y logramos,
mediante una correcta gestión de compras, un 10% medio de rebaja en los
31
En general, las dietas o gastos pagados en los desplazamientos deben cubrir holgadamente
las necesidades del trabajador que se deriven de su ausencia del domicilio familiar,
manteniendo al menos su calidad de vida habitual. Pero tampoco hay que pasarse. Un antiguo
compañero de viajes reclamaba, por ejemplo, cargar a la empresa los gastos en tabaco,
alegando que sólo fumaba cuando estaba de viaje, ya que en casa su mujer no se lo permitía.
32
El coste de insertar un anuncio en el BOE depende de la extensión del mismo, y a la fecha de
preparación de esta obra puede calcularse de manera aproximada como el número de líneas que
ocupa multiplicada por 12,5 € por línea, más impuestos (fuente: Boletín Oficial del Estado,
2004).
supuesto del proyecto, que puede destinarse a horas de trabajo, a incrementar

las actividades comerciales, corno xeservas aníe contingencias, o simplemente
como un pequeño beneficio extra I -■ - ,,;,
Otra manera de mejorar !a marcha económica del proyecto es negociar una

forma de pago adecuada con los suministradores. Diferir al máximo posible los
pagos supone, tal y como se vio en la lectura "'Inflación y escaktcián de
precios", del capítulo 2, retrasar al máximo la salida de flujos económicos del
proyecto,, minimizando las necesidades de efectivo o, dicho de otra manera,
financiando parcialmente el proyecto con cargo a los proveedores.
ichas empresas disponen de un departamento de compras específico

negociar con los proveedores, peco a menudo, las empresas de tamaño pequeño
o medio carecen de dicha ayuda, y es el propio responsable del proyecto el que
se encarga de seleccionar a los proveedores y de negociar el precio y las
condiciones. Esto también sucede cuando los bienes a adquirir son demasiado
específicos como para encargarlos al personal administrativo, y el personal
técnico del proyecto debe colaborar en la selección del proveedor e, incluso, en
la negociación.
Si tenemos que participar en la gestión <fc compras del proyecto, lo lógico es

buscar proveedores que:
" Sean competitivos, oneciendo productos o servicios de calidad aeeptabl

precios razonables, y con buenas condiciones de suministro y pag©.
■ Sean estables, permaneciendo en el mercado para proporcionar nuevos
productos, repuestos, mantener los períodos de garantía, etc.
■ Añadan valor al producto, siendo algo más que meros mtermediarios en la
cadena comercial., lo que añade costes innecesarios al producto o servicio.
A continuación se trata de que, como-parte de-te estrategia con los proveedores,

se intente ejercer sobre ellos Ja máxima influencia posible, que refuerce nuestra
capacidad de negociación y, por tentó, mejore los precios y las condiciones en
los que podemos adquirir losTbienes. Para ello, es conveniente:
■ Concentrar las compras de nuestros Clientes, para comprar '"mucho de una

vez", en lugar de "poco y muchas, veces 1 '. Esto abarata los costes del
proveedor y, al igual que en una primitiva economía de escala, tos precios
que nos ofrezca.
■ Distribuir las compras entre varios proveedores. Aunque esta técnica
contrarresta la eficacia de la anterior, evita que dependamos de un
proveedor único que, en ocasiones de urgencia o necesidad, pueda abusar de
su posición privilegiada. Ademas* ayuda a comparar condiciones y precios,
y proporciona mejor información de cara a las negociaciones.
■ Crear una amenaza de "integración hacia atrás", es decir, estar dispuestos a
asumir el trabajo del proveedor, si los precios o condiciones empeoran en
emplo, si nuestro proyecto exige utilizar un consultor en física

nuclear, y los precios de los consultores habituales de la empresa comienzan
a subir irracionarmente, podemos contemplar la posibilidad de integrar en
nómina un físico nuclear, sí esto logra abaratar costes. O, si para desarrollar
sistemas electrónicos militares adquirirnos circuitos impresos, podremos
negociar mejor si contemplamos la posibitidad de dotarnos de la tecnología
necesaria para su fabricación, en caso de que el proveedor habitual no los
proporcione a un coste razonable.
Colaborar con la entrada en el sector de nuevos proveedores, por ejemplo,
comenzando a adquirir bienes o servicios de una empresa recién creada, con
Q\ otêtivo de que, anaeclip plazo, sé incremente el número de proveedores,
crezca la competencia y caigan los precios.
Buscar un producto sustitutivo, de otro(s) proveedores), para que. en el
caso de una subida no razonable de precios o empeoramiento de las
condiciones del proveedor habitual, se pueda ejercer un cambio del mismo.
A comienzos de la década de los 90 se creó una especie de oligopolio en el

mercado de las memorias para ordenador personal que permitió que el precio de
esos pequeños componentes triplicara y cuadruplicara su precio normal. Esto, a
su vez, hizo encarecer el precio de los ordenadores en los que se instalaban
dichos circuitos. La lógica reacción de los compradores de circuitos de
memoria, encabezados por las grandes marcas de ordenadores, fue tratar de
romper la hegemonía de los proveedores de memorias, incentivando
económicamente, y con pedidos fabulosos, a otros fabricantes de circuitos de
otro tipo para que se introdujesen en ©1 mercado de tas memorias. El efecto a
medio plazo (uno o dos años) fue el abaratamiento de las memorias, el
incremento de la competencia en dicho sector y,, por tanto, el fin de la "tiranía"
de los fabricantes tradicionales.
3.4 Presupuesto y precio de venta del proyecto
El presupuesto fija el precio final de venta o suministro al Cliente, desglosado por

conceptos. Para ello calcula el coste de personal en función del número de horas de
trabajo estimadas anteriormente (esfuerzo necesario), así como los gastos previstos,
añadiendo el correspondiente margen de beneficio.
A la hora de estimar los costes de personal es preciso tener en cuenta:
El coste horario del personal, clasificado según categorías. Para asignar un

coste horario a cada categoría profesional suele tomarse como referencia el
coste medio de todos los empleados de la empresa que pertenezcan a esa
categoría. Dicho coste incluye el sueldo y las cargas sociales, por lo que no es
extraño encontrarse con costes horarios medios de más de 20 €/hora para

profesionales sin experiencia (aunque, desde luego, su nómina no sea de
3.200 6 brutos al mes).
** Los coeficientes de costes de personal, correspondientes a los costes

generales, tales como infraestructura del local, teléfono, personal auxiliar,
gastos administrativos, etc. Estos coeficientes varían tremendamente entre
empresas y, dentro de una misma empresa, entre departamentos y secciones.
Además suelen actualizarse con cierta frecuencia, para reflejar la eficiencia de
la empresa, departamento o sección durante el último ejercicio (como norma
general, bajos coeficientes suelen indicar niveles de eficiencia altos).
^ Las contingencias sobre gastos, que incluyen reservas para partidas no

previstas inicialmente (reuniones canceladas, cargos financieros, retrasos en
suministros, etc.), pero que suelen aparecer en todo proyecto. Estas
contingencias suelen rondar (por lo general), entre el 4% y el 10% para los
costes de personal, y el 3% para otros gastos imputables (siempre, claro, en
función del tipo de empresa, el tipo de proyecto y el riesgo del mismo). La
parte de las contingencias que, al final del proyecto, no se hayan consumido
(en parte gracias a la buena gestión del proyecto) se incorporan al beneficio
del mismo.
A los costes de personal referidos se añaden, a continuación, los demás costes y

gastos, tal y como se calcularon en el apartado anterior, teniendo en cuenta que dichas
partidas no suelen ir afectadas por los coeficientes de gastos generales, pero sí, a
menudo, por un factor que prevea las posibles contingencias.
Finalmente, se le añade al coste global del proyecto el margen proyectado para el

mismo. Este margen suele calcularse de una de las dos maneras siguientes:
^ Como un porcentaje sobre el propio coste, ofertando el precio de venta

resultante. Este método se utiliza cuando el contrato no tiene un precio fijo, y
cuando no se conoce apriori el precio que el Cliente está dispuesto a pagar.
<*■ Como la cantidad restante para alcanzar el precio de venta buscado, bien sea el
precio fijado por el Cliente para el contrato, o cualquier otro que se estime
como oportuno, en función de la información contextual de que se disponga.
La figura 3.6 muestra un posible formato para evaluar el presupuesto de un proyecto.

Este formato debe personalizarse para cada empresa, sección, etc., incorporando los
datos que suelen ser comunes a todos los proyectos de la organización, tales como:
> Categorías profesionales, y coste horario de cada categoría.

> Coeficientes de gastos generales.
> Coste horario de equipos informáticos (ordenadores) y estimación por
hora para consumibles.
En la figura 3.6 se han introducido los valores asociados a la empresa modelo Caos
Consulting (ver capítulo 1). Después, para cada proyecto se introducirán (aparte de los
datos básicos de título, Cliente, referencia, responsable, etc.) los datos específicos del
mismo, en las casillas recuadradas y sombreadas, incluyendo:
> La estimación de horas de trabajo por categoría.

> El coste estimado de las subcontrataciones.
> Otros costes horarios ligados al número de horas de trabajo del proyecto
(por ejemplo, alquiler de maquinaria específica, alquiler de salas o
instalaciones, etc.).
> Los gastos estimados para material y equipos, viajes y estancias y gastos
varios.
> El porcentaje que se considere adecuado para prever los riesgos y
contingencias del proyecto, para cada partida de costes (personal,
subcontrataciones, y costes y gastos varios).
Como puede apreciarse en la figura 3.6, el coste del proyecto se estima como la suma
de los costes de personal y subcontrataciones, más los costes y gastos varios, cada uno
afectado por un porcentaje para contingencias y riesgos. A partir de los datos
introducidos, el formato calcula el valor de las diferentes partidas de costes y gastos,
así como el precio de venta (sin IVA) resultante de aplicar los márgenes indicados
sobre cada partida. El margen puede ser distinto para cada partida de costes, aunque
también es posible ignorar dichos porcentajes, y utilizar un margen global fijo (20%
en la figura) que permita obtener un precio de venta "estratégicamente adecuado".
J
Que el lector puede encontrar en el fichero \formatos\plantillas\datos_economicos.xls del
disco incluido en el libro.
Figura 3.6 Formato de presupuesto de un proyecto

94 DIRECCIÓN Y GKSTION DE PROYECTOS
Finalmente, la zona sombreada a la derecha de los datos básicos del proyecto muestra
los valores resumen más significativos del proyecto: precio de venta, horas de trabajo
y porcentaje de margen resultante estimado.
En cuanto al precio de venta, hay que tener en cuenta una posible diferencia entre el
valor resultante del cálculo anterior y el precio que finalmente se le pida al Cliente. En
teoría, ambos valores habrían de ser idénticos pero, en la práctica, se dan diferencias
muy notables, debido a, entre otros:
<*" Que se fije un precio de venta por encima del calculado, aumentando el
beneficio, al estimar que dicho precio es inferior al de la competencia, o que
estamos en mejores condiciones que ellos para lograr la adjudicación del
contrato.
^ Que se fije un precio de venta por encima del calculado, con el fin de rebajar
el mismo durante la negociación y dar al Cliente la sensación de haber logrado
"un buen trato".
^ Que se fije un precio de venta por debajo del calculado (e, incluso, por debajo
del de coste), provocando pérdidas para nuestro negocio, al estimar que el
proyecto es estratégico de cara a lograr futuros contratos o adquirir
experiencia en un campo concreto, o como forma de darse a conocer a un
determinado Cliente.
LECTURA. El NUMERO DE PERSONAS QUE PARTICIPAN EN

UN PROYECTO
Suele ser normal que, cuando un proyecto cae en manos de un principiante,

exista el impulso de conformar un equipo de trabajo de tamaño superior ai
necesario. Un proyecto normalmente engloba diferentes disciplinas, y puede
parecer que hace faifa ai meaos una persona para cada una de ellas. Además,
existe la falsa sensación de que un número elevado de partícipes en el proyecto
confiere al mismo mayor probabilidad de éxito, y el responsable del mismo se
siente más respaldado.
Sin embargo, lo anterior no es siempre cierto. Desde el punto de vista técnico,

fragmentar demasiado el problema hace que las personas sean menos
conscientes éeí objetivo global, que se difurninen las responsabilidades de cada
uno, y que se concentren en exeeso en sus parcelas particulares, o que invadan
las parcelas de los demás, añadiendo complejidad a la interfaz entre los
miembros del equipo de trabajo.
A su vez, desde la perspectiva económica, cada una de las personas que

participen en el proyecto tendrá que conocer un mínimo del mismo (es decir,
estudiarse el proyecto), antes de realizar cualquier trabajo productivo. Cuantas
más personas participen, más gente tendrá que "ponerse al día", y más horas de
esfuerzo se invertirán en una tarea de formación que, objetivamente, no es
rentable al proyecto.
En principio, dos deben ser los criterios a seguir a la hora de determinar

número de personas que deben participar en un proyecto:
■ El esfuerzo global, en número de personas, necesario para realizar el

trabajo. Este valor teórico se calcula dividiendo tas horas de trabajo del
proyecto entre la duración del mismo, y entre la duración (en horas) de la
jornada laboral típica.
■ El número de disciplinas involucradas en el proyecto y, en concreto, ei
número de ellas que requieran un nivel de especializaeión tal que exijan la
presencia de personas específicas.
Pongamos un ejemplo. Sea un proyecto consistente en medir un terreno y

levantar un mapa cartográfico del mismo, evaluado en 350 horas de trabajo, y
que debe completarse en 5 semanas (unas 200 horas de tiempo "corrido"). Al
calcular el cociente 350/200, se obtiene el valor 1,75» Como las personas no son
(afortunadamente) fragmentares, el proyecto requeriría la participación de, al
menos, dos personas.
Sin embargo, hay varias consideraciones adicionales.
La medición es una tarea mucho menos especializada que el trazado del

mapa. Por tanto, no parece adecuado que la persona que levanta el mapa
participe en las tareas de medición. Será conveniente utilizar una persona
distinta para cada actividad.
" La labor de medición requiere dos personas, como mínimo, una para sujetar
la referencia, y otra para manejar el teodolito. Junto con el delineante del
mapa, ya so» tres las personas involucradas.
■ Alguien tendrá que gestionar el proyecto. En este caso parece factible
encargar la dirección del mismo al partícipe de mayor categoría o
experiencia, pero en otros casos el proyecto exigirá nombrar un director
proyecto "profesional".
En el caso ejemplo, al final, con tres personas parece haber suficiente para
desempeñar el trabajo. Cada una de ellas dedicará, en media, 117 horas de
esfuerzo, lo que supone en torno a 24 horas semanales. O sea, cada una de ellas*
dedica, aproximadamente, el 58% de su jornada laboral a este proyecto.
Esta dedicación parcial es otro de los problemas a tener en cuenta a la hora

asignar personas a proyectos: en general la eficiencia decrece,
96 DIRECCIÓN Y GESTIÓN DE PROYECTOS ©RA-MA
prohombre perderá granarte de, su tiempo cambiando de una tarea a otra,

estará obligado a conocer los entresijos de ocho problemas distintos, y será más
propenso a olvidar "detalles 1", ,1o que puede perjudicar seriamente a su
rendimiento efectivo.
4. PLANIFICACIÓN TEMPORAL DEL PROYECTO
Tan importante como la evaluación del alcance y la estimación económica del

proyecto es la planificación y programación temporal del mismo, tarea a la que,
lamentablemente, a veces se presta menos atención de la necesaria.
A lo largo del capítulo hemos visto cómo la descomposición de un proyecto en

actividades y sub-actividades constituye una herramienta fundamenta] para estimar el
alcance y el coste del mismo. Pero una vez definidas y descritas las actividades, es
preciso analizar cuánto va a durar la ejecución de cada una de ellas, y sobre todo, en
qué orden se van a abordar.
La duración de cada actividad del proyecto vendrá dada por múltiples factores, entre,
ellos la complejidad, el esfuerzo requerido, las personas disponibles y, por qué no, el
tiempo del que dispongamos. El orden de ejecución de las diferentes actividades, sin
embargo, habrá de tener en cuenta otro tipo de factores más restrictivos, tales como:
Que algunas actividades necesiten, para ser realizadas, resultados de otras

actividades que deberán comenzar antes. En particular, en muchos casos una
actividad no podrá dar comienzo hasta que otra (u otras) finalicen. Así, por
ejemplo, en el caso de nuestro albañil del apartado 3, difícilmente nuestro
hombre (¡o mujer!) pensará en comenzar a levantar la pared antes de
desmontar la valla primitiva, o antes de disponer del material necesario.
Que para ejecutar algunas actividades se precisen recursos que hayan de ser
compartidos con otras actividades (incluso, de otros proyectos). Imaginemos
que nuestro hombre tiene que levantar dos paredes, y decide utilizar, para
acelerar, un ayudante que levante la otra pared. Difícilmente podrá levantar
ambas paredes a un tiempo, si sólo dispone de un andamio^7.
4
Sin embargo, como a nuestro hombre no le falta experiencia, probablemente lo que hará es
contratar de todos modos a su ayudante, para trabajar los dos juntos en una misma pared,
acortar "el período de construcción de cada una, y reducir el tiempo total necesario para la obra.
Además, trabajar en compañía es siempre mucho más gratificante.
^ Que para abaratar costes sea recomendable ejecutar unas actividades después
de otras. Supongamos que debemos ir a buscar a los escolares de un colegio
de tres pueblos en torno al mismo. Podemos utilizar tres autocares distintos o,
para reducir costes, utilizar uno sólo, que tarde más tiempo.
Las técnicas de planificación se ocupan de estructurar las tareas a realizar dentro del
proyecto, definiendo la duración y el orden de ejecución de las mismas, mientras que
las técnicas de programación se encargan de la transformación del plan del proyecto
en un calendario real, que tenga en cuenta aspectos de recursos, costes, carga de
trabajo, etc.
Hasta finales de la década de los años cincuenta, la planificación y la programación de

proyectos eran una actividad única, y hoy en día lo sigue siendo, salvo para proyectos
de gran tamaño o complejidad.
4.1 Técnicas de planificación
Aunque, como siempre, existen múltiples opciones, la herramienta clásica, sin duda
más popular para la programación de proyectos, es la gráfica de Gantt.
Una gráfica de Gantt es un diagrama bi-dimensional en el que se representan las

diferentes actividades o tareas del proyecto (eje vertical) frente al eje de tiempos
necesarios para realizar las mismas (eje horizontal).
Cada una de las actividades del proyecto se muestra en la gráfica de Gantt mediante
una barra horizontal, cuyo extremo izquierdo representa la fecha de comienzo de dicha
actividad, viniendo la duración de la misma indicada por su longitud. A veces también
es posible que sobre cada barra de actividad se coloque información acerca de los
recursos materiales o humanos necesarios para realizar dicha actividad.
Volvamos a nuestro albañil-constructor, al que ahora (como nos hizo muy bien la
pared) encargamos que nos abra un portón en la valla de nuestra casa, para meter un
coche y aparcarlo en el jardín. Nuestro avezado hombre identifica las siguientes
actividades por realizar, junto con la duración aproximada de ellas:
> Solicitar al Ayuntamiento el correspondiente permiso de obra (6 días, de

los cuales 2 horas son para solicitar la licencia, y el resto es la espera,
hasta que se tramite).
> Encargar un contenedor para los escombros (0 días. Es sólo una llamada
telefónica).
> Derribar la parte correspondiente de valla (1 día).
> Colocar y recibir el portón metálico (2 días).
> Reconstruir los extremos de la valla donde se colocó el portón (1 día).

> Rebajar el realce de la acera (1 día).
> Levantar el césped y cimentar dos rodaduras de cemento, donde apoyarán
las ruedas del vehículo, y levantar dos muros de protección a los lados (2
días).
> Encargar que se retire el contenedor de escombros (0 días. Es sólo una
llamada telefónica).
Por supuesto, no se le ha ocurrido tener en cuenta el esfuerzo necesario para "gestionar

y dirigir" el proyecto, aunque debería hacerlo, ya que invierte una considerable
cantidad de tiempo en negociar con los Clientes, en acotar e¡ alcance de sus tareas,
etcJí. También sabe nuestro hombre que hay ciertas restricciones a la hora de ordenar
la secuencia de tareas:
> No puede comenzarse ninguna actividad hasta que no se disponga de la

licencia del Ayuntamiento.
> No es posible colocar el portón sin antes derribar el fragmento de valla.
> No es posible reconstruir los extremos de la valla hasta que no se haya
colocado el portón.
> El contenedor debe estar disponible el día que se derribe la valla.
Con la información anterior, Esteban, que así se llama nuestro hombre, confecciona el
diagrama de Gantt de la figura 3.7, donde se aprecia que, según la planificación
inicial, el proyecto dura 17 días, contando sábados y domingos (en los que no se
trabaja), si se empieza a trabajar un lunes.
Figura 3.7 Planificación inicial del proyecto de instalación de un

portón
33
Una de las actividades complementarias más habituales es la gestión de "poyaques". Frases
tales como "Poyaque está vd. aquí, pínteme el recibidor" o "Poyaque estamos, levante la pared
metro y medio más" son bastante habituales, en el día a día del trabajo.
Pero en la planificación anterior Esteban detecta un conjunto de hechos que no son de

su total agrado:
~> Por un lado, el proyecto dura casi tres semanas, contando el plazo de
espera por la licencia. Sería mejor hacer el trabajo en una semana, aunque
requiera pagarle unos jornales a Ramón, uno de sus ayudantes, que puede
hacer algunas tareas mientras Esteban hace otras.
> También sería preferible solicitar la licencia un viernes, para poder
empezar a trabajar, de verdad, un lunes.
> El contenedor se paga por días, por lo que no sería mala idea devolverlo
tan pronto como se termine de derribar la valla, y se termine de rebajar la
acera, únicas actividades donde se genera escombro.
Con la información anterior, Esteban rehace la planificación del proyecto, que queda
como se muestra en la figura 3.8.
Figura 3.8 Planificación modificada del proyecto de instalación

de un portón
Con estos cambios, Esteban ha reducido la duración del proyecto (sin contar la espera
por la licencia de obras) a 4 días de trabajo, a cambio de pagar 3 jornales a Ramón.
También ha reducido de 9 a 1 los días de pago por alquiler del contenedor de
escombros. En general, un diagrama de Gantt es útil para:
> Calcular los plazos de ejecución y, por tanto, de entrega de los trabajos.
> Ayudar a detectar y reducir los tiempos de espera y los tiempos muertos,
de personas y máquinas.
> Equilibrar la carga de trabajo entre personas.
4.2 Técnicas PERT
Desde el punto de vista cuantitativo, la gráfica de Gantt no proporciona información

sobre la secuencia más óptima de las actividades (que debe seleccionarse
manualmente), ni sobre el plazo mínimo de ejecución de un proyecto concreto.
Tampoco facilita la labor de identificar cuál es el efecto de un retraso en la
finalización de las diferentes actividades sobre la fecha de finalización del proyecto
completo.
A mediados de los años cincuenta, la empresa Du Pont inició un estudio sobre técnicas
de aplicación de ordenadores a la planificación y programación de proyectos, que
recibió el nombre de Critical Path Method36 (CPM). Fue el nacimiento de las técnicas
PERT, Project Evaluation Review Techniqué", cuyo objetivo general es ayudar a
programar un proyecto individual a coste y duración mínimos. Los objetivos
particulares son:
> Determinar qué actividades son necesarias, y cuándo lo son.

> Buscar el plazo mínimo de ejecución del proyecto.
> Buscar las ligaduras temporales entre actividades del proyecto.
> Identificar las actividades críticas, es decir, aquéllas cuyo retraso en la
ejecución supone el retraso del proyecto completo.
> Identificar el camino crítico, que es aquél formado por la secuencia de
actividades críticas del proyecto.
y Detectar y cuantificar las holguras de las actividades no críticas, es decir,
el tiempo que pueden retrasarse (en su comienzo o finalización) sin que el
proyecto se vea retrasado por ello.
Las técnicas PERT suelen hacer uso de grafos para representar las actividades
involucradas en un proyecto y las dependencias temporales entre ellas. Cada flecha del
grafo representa una determinada actividad, identificada por su nombre y duración, y
cada nodo entre dos o más flechas representa un suceso o hito temporal (el comienzo o
el final de una actividad, una reunión, la recepción de una notificación, etc.). En un
grafo sólo puede haber un suceso inicial y un suceso final. Por último, todas las
actividades que concurren en un suceso preceden en el tiempo a las que parten de él.
36
Que puede traducirse como "método de! camino crítico".
37
Que puede traducirse como "técnica de evaluación y revisión del proyecto".
Supongamos un proyecto que involucra seis actividades, A, B, C, D, E y F, de

duraciones típicas respectivas 2, 1, 4, 8, 5 y 3 unidades de tiempo (horas, días, años,
etc.), con las siguientes restricciones temporales:
> La tarea A se ha de ejecutar antes que las tareas B y D (lo que se expresa
como A<B, D).
> La tarea B se ha de ejecutar antes que la tarea C (lo que se expresa como
B<C).
> La tarea C se ha de ejecutar antes que la tarea E (lo que se expresa como
C<E).
> La tarea D se ha de ejecutar antes que las tareas E y F (lo que se expresa
como D<E, F).
El grafo de este proyecto se muestra en la figura 3.9. Las dos actividades virtuales,
representadas por sendas flechas discontinuas entre las actividades D y E, y F y el
suceso final, muestran ligaduras en el tiempo, pero sin que exista una actividad
intermedia entre ambas.
Figura 3.9 Ejemplo de grafo de proyecto
Conocido el grafo del proyecto, el siguiente paso es calcular la fecha mínima de

comienzo de las diferentes actividades. La fecha mínima de comienzo de una
actividad, denominada MIC, coincide con la fecha mínima de comienzo del suceso
del que parte. Para calcular el MIC de un suceso se procede como sigue:
> El suceso inicial comienza al inicio del proyecto (momento en el que el

"reloj del proyectó" se pone en marcha). Su MIC es, por tanto, cero.
> Los MIC de los sucesos contiguos se calculan como la duración de las
actividades que van desde el suceso inicial hasta dichos sucesos
contiguos.
> En general, el MIC de un suceso se calcula como el valor máximo de la

suma de la duración de cada actividad que llega al mismo, más el MIC
del suceso del que procede.
La figura 3.10 muestra el gráfico anterior, donde se han incorporado los valores MIC
de cada suceso. Observando el MIC del suceso final, se llega a la conclusión de que el
tiempo mínimo de ejecución del proyecto ejemplo es de 15 unidades temporales.
Figura 3.10 Cálculo de los valores MIC de los sucesos del proyecto
A continuación, se calcula el valor MAC, o fecha máxima de comienzo de actividad,

para cada suceso del grafo. Ésta es la fecha máxima en la que podrían cumplirse los
sucesos del proyecto, sin que supusieran un retraso en la finalización del mismo, más
allá del valor fijado por el MIC del suceso final.
Para calcular los valores de MAC se procede en sentido inverso, esto es, de derecha a
izquierda, desde el suceso final hasta el suceso inicial, y se procede como sigue:
> El MAC del último suceso se hace coincidir con el MIC del mismo, para
no retrasar el final del proyecto.
> Para cada nodo (suceso) situado a la izquierda, incluido el nodo inicial:
> Se toman todas las actividades que tienen su origen en ese nodo.
> Para cada una de las actividades anteriores, se calcula el valor
diferencia entre el MAC del suceso al que conduce la actividad,
menos la duración de dicha actividad.
> El MAC del suceso se calcula como el valor mínimo de las
diferencias obtenidas en el paso anterior.
CAPITU1,0 3: EVALUACIÓN DEL- PROYECTO 103
Si los valores están correctamente calculados, el MAC del suceso inicial debe
coincidir con el MIC de dicho suceso, y valer cero. La figura 3,11 muestra el grafo del
proyecto de ejemplo con los valores MIC y MAC ya calculados.
Figura 3.11 Cálculo de los valores MAC de los sucesos del proyecto
A partir del grafo asi calculado es inmediato identificar el camino crítico que, como
ya se ha dicho, es el formado por las actividades críticas que, a su vez, son aquellas
que no admiten retrasos en su ejecución, sin que el proyecto, en conjunto, sufra un
retraso similar. Para identificar las actividades y el camino crítico en un grafo, basta
con extraer la secuencia de actividades que enlazan nodos cuyo MIC es igual a su
MAC. La figura 3.12 muestra el camino crítico del grafo de ejemplo, formado por las
actividades (críticas) A, D, V] y E (nótese que nada impide que una actividad virtual
forme parte del camino critico).
Figura 3.12 Camino y actividades críticas del grafo PERT del

proyecto
Si estas tres actividades (dejando aparte la actividad virtual) se ejecutan sin retrasos, es
posible completar el proyecto en 15 unidades de tiempo, según marcan los valores
MIC y MAC del suceso final. Cualquier retraso en alguna de estas actividades, supone
un retraso en la finalización del proyecto. El valor del retraso sufrido por el proyecto
depende de si la actividad que provoca el retraso, al ver incrementada su duración,
continúa o no siendo crítica. En caso afirmativo, el retardo global del proyecto es
equivalente al retardo experimentado por la tarea. En caso negativo, la magnitud del
retardo del proyecto es un valor intermedio entre cero y el retardo de la tarea.
Las restantes actividades (no críticas), B, C, D y F, admiten, en mayor o menor

medida, un cierto retraso sin que ello implique, necesariamente, el retraso del proyecto
completo. Dicho margen de maniobra temporal, que puede añadirse a la duración de
una (o varías) actividades sin que el proyecto sufra retraso recibe el nombre de
holgura.
Veamos cómo se calcula la holgura asociada a la actividad K(ij), que transcurre entre
los sucesos I y J. Después de calcular los valores MIC y MAC de cada suceso del
grafo, la holgura H(K(i j)) de la actividad mencionada se calcula de acuerdo con la
expresión siguiente:
H(K(ij)) = MACj- MIC, - DuraciónK(iJ¡
Aplicado a los valores del ejemplo anterior, las holguras de las actividades no críticas
B, C y F, se calcularían como sigue:
H(C) -10-3-4-3 unidades de tiempo

H(B) = 6-2-1 =3 unidades de tiempo
H(F) = 15 - 10 - 3 = 2 unidades de tiempo
Es decir, podría retrasarse en su comienzo, o incrementarse su duración en tres o en

dos unidades de tiempo, sin que se altere la duración del proyecto (o, lo que es lo
mismo, sin alterar el MíC de ninguna actividad crítica).
Evidentemente, para una actividad crítica, la holgura es siempre cero.
En el caso de la actividad C el cálculo de la holgura es trivial, como también lo es el

resultado del mismo, que coincide con la diferencia entre el MIC y el MAC del suceso
del que parte la actividad. Esta obviedad se desdibuja en el caso de actividades
compuestas, o de ramas de actividades, donde existe una "holgura conjunta" que
puede distribuirse, como mejor convenga, entre las diferentes actividades que
compongan la rama. Así, en el ejemplo anterior, al calcular la holgura conjunta de las
actividades B y C, se obtiene:
H(B, C)= 10~2~(l + 4)=3 unidades de tiempo

Como puede verse, se dispone de 3 unidades de tiempo para "repartir" entre las
actividades B y C, como mejor convenga.
Por último, el concepto de holgura también es aplicable a un suceso individual, Si,

calculándose como sigue:
H(S¡) = MACSÍ - MICSI
LECTURA. «AIR DIOS MIÓ" Y SU PROGRAMA DE

OPTIMIZAC1ÓN DE VUELOS
el gran magnate japonés lo Voló Baji Tó adquirió un significativo

porcentaje de la empresa de transporte: aéreo Air Dios Mío, especializada en
vuelos chárter de bajo coste, se propuso reflotarla rjara que los mafíosos que la
utilizaban como tapadera para el blanqueo de su dinero (procedente de
actividades poco lícitas) perdieran interés por ella y abandonaran el capital ée la
compafiía.
Hasta ese momento, una ele las causas de los malos resultados ecpnómk
sistemático desbarajuste en el aeropuerto: las tripulaciones pasaban h(
vagando por la terminal* o esperando en la cabina del avían. Los pasajeros
esperaban en el avión a que terminaran de cargar el equipaje o,: peor aun, se
quedaban en.la escalerilla hasta que concluía la limpieza dej aparato. Y ios
operarios técnicos se veían estorbados por los mozos que cargaban maletas, o
por los que cargaban el combustible de la aeronave.
Las consecuencias de tal desorganización eran previsibles: no sé sabía cuánto

tiempo, en realidad, era necesario para preparar ÜJ avión y dejarlo listo para el
despegue, aunque la media real estaba en torno a 250 minutos. Además, se
perdía mucho tiempo en resolver pequeños conflictos, por falta de organización
y, peor aún, los pasajeros se disgustaban y reclamaban a fa compañía. Por
último, estos innecesarios retrasos hacían perder él shf de despegue del avión
(coloquialmente, su tumo de despegue), cOñ el consiguiente malestar
autoridades aeroportuarias.
Para resolver la situación, Voló Sam acometió de inmediato un progratra

análisis de las operaciones de la empresa, "que detectara (y permitiera corregir)
los derectos de planificación de actividades que/según sus consejeros, eran la
causa de que los aviones de la compañía sufrieran retrasos, permanecieran
demasiado tiempo en tierra y, en definitiva, no obtuviesen los ingresos
necesarios para hacer rentable el negocio.
106 DIRECCIÓN Y GESTIÓN DH PROYECTOS
meargaüo üe analizar y resolver el problema, loso Cálcu Lator, mano derecha

de Voló Sam, identificó las siguientes actividades típicas (y su duración), en las
operaciones de un avión efe la compañía;
Cada avión, antes de cada vuelo, se somete a un chequeo técnico, que dura
unos 35 minutos (tarea A).
La limpieza del aparato ocupa unos 40 minutos (tarea B).
La carga del combustible necesario para el vuelo tarda unos 15 minutos
(tarea C).
El encendido de motores y chenqueo pre-vuelo, realizado por el comandante
supone unos 4 minutos (tarea D).
La torre tarda unos 6 minutos en conceder el permiso de rodadura
despegue (tarea E). *
En tierra, la facturación de las maletas permanece abierta durante 90
minutos (tarea F).
El transporte y carga de las maletas en la bodega del avión lleva cerca de 2
jninutos (tarea G).
Una vez el pasaje ha facturada su equipaje, el embarque tarda 30 minutos
(tarea H).
Ei embarque de fa tripulación, por su parte, tarda 12 minutos (tarea I).
A la tripulación se la lleva en un minibús, siendo el recorrido típico de unos
60 minutos (tarea j).
Cuando la tripulación llega al aeropuerto, pasa por operaciones y toma el
plan de vuelo, en lo que se tarda unos 10 minutos (tarea K).
Las comidas tardan en cargarse en d avión en tomo a 8 minutos (tarea L)
La rodadura desde el aparcamiento hasta la cabecera de pista lleva unos 4
minutos (tarea M). - t - - ; . - ..--.--_"-"--_--- " - .
Tras un pequeño análisis que llevó a cabo entrevistándose con diferentes
responsables del mantenimiento y operación de aviones y aeropuertos, Calcu
Lator identificó las siguientes restricciones temporales entre Jas tareas
anteriores:
La facturación debe terminar antes de comenzar el embarque de los

pasajeros, que debe estar concluido (puertas cerradas) antes de encender los
motores del avión. Así pues, F < H < D. -"--.-
Con respecto a la carga del equipaje, el traslado de maletas y carga de
mismas en el avión no debe comenzar hasta que no se cierre la facturaciói
de pasaje, y debe estar terminada antes de encender los motores y hacer
chequeo pre-vuelo. F < G < D.
Por motivos de seguridad, el personal de limpieza debería habí
abandonado el avión antes de comenzar la carga de combustible. B < C. La
carga de las comidas no debe comenzar hasta que no se haya íerminad( de
limpiar la aeronave, y tendrá que haber terminado para cuando
primeros pasajeros lleguen al avión. B < L < H.
■ Es conveniente realizar el chequeo técnico antes de cargar ei combustible, y

la carga deí mismo debe terminar antes ¿le encender los motores. A < C < D.
■ En cuanto a ía tripulaci6ns iras ser reunidos han de pasar por operaciones,
donde toman su plan de vuelo. Tras ello, embarcan en el avión, pero
siempre antes que los pasaieros. J < K < I <H~, « -~ :„„.... - . Z
■ Una vez terminado el chequeo pre-vnelo, con los motores ya encendidos,
hay que pedir permiso a la torre. Hasta que no se dispone del permiso, no se
puede abandonar el aparcamiento y comenzar la rodadura hasta la cabecera
de pista. D < E < M.
Teniendo en cuenta lo anterior, Calcu Sam dibujó el grafo PERT de actividades

de la figura 3.13T sobre el que calculó los correspondientes valores MIC y MAC
de cada suceso. ;!
Figura 3.13 Camino y actividades críticas del grafo PERT del

proyecto
Según el grafo de la figura, el MIC del proyecto es de 134 minutos, que es

tiempo mínimo necesario para dejar el avión listo para despegue (en cabecera de
Dista), desde que comienzan las operaciones de preparación para el vuelto
siempre y cuando se organicen correctamente.
\demás, según el grafo anterior, las actividades críticas del proceso son las
siguientes:
■ Encendido de motores y chequeo pre-vueto (D).

■ Solicitud y ofcíendón de permiso de rodadura (E).
■ Rodadura hasta la Cabecera de pista (M). ..
Además, la figura,3.14 muestra una. posible planificación temporal de las

actividades (ai existir holguras, hay otras organizaciones posibles), que permite
anticipar cuándo ifeben cursarse las solicitudes correspondí entes, para que cada
tarea comience a su debido tiempo. ;
Figura 3.Í4 Secuencia de actividades del proceso de preparación

del avión
A la vista de i cu Lutor transmitió a Voló Baji Té las siguí
• El tiempo necesario para preparar un avión (incIuyeiKio tripulación y

pasaje) para un vuefé es de 134 minutos (muy inferior al que se consigue en
la actualidad, de 250 minutos),
■ Las operaciones que tienen que ver con el pasaje (facturación y embarque)
constituyen el cámara crítico,
* Puede aliorrárs&l Ó minutos acortando el tiempo de embarque á 20 minutos.
Esto suele ser posible cuando se entra aí avión a través de pasarela ífmger),
pm>no cuando se -utilizan autobuses desde la terminal hasta el avión.
■ Si 'le anterior no; «s.posiWe, "puede ahorrarse esos Í0 minutos solapando
facturación y embarque, y permitiendo que haya pasajeras facturando
mientras otros se dirigen a fa puerta de eníbar<jue 3 y mientas algunas
'eras ya se están subiendo al avión;
■ En el caso anterior, la reunión de la tripulación p;> ar, junto con la

preparación del pian de vuelo y ñ embarque de la tripulación, el camino
critico (junto can el embarque del pasaje, y ks operaciones de encenctído,
permiso y rodadura). Como la holgura de esa "rama es de 8 minutos, el
tiempo mínimo de preparación pasaríi, a ser de 126 mimftosr_ salvo que
alguna de, las toes actividades-pudiera reducirse eif 2 o más .minutas, en cuyo
caso el camino critico pasaría a ser de 124 minutos.
Resultados
lo Voló Baji Tó quedó gratamente impresionada por el trabajo ée CaícuXator,
por lo que, tras premiarle dejándoleque besara sunmano, se apresuró a dictar
instrucciones para poner en marcha la nueva metodología de -preparación del
avión.
Tres meses más tarde, la reorganización de actividades había logrado reducir a

un 2% las pérdidas económicas de la compañía, que atonas, había mejorado su
imagen ante los pasajeros y usuarios, y ante las autoridades aeroportuarias.
Sin embargo, esto no gustó nada a Mario Cossanostpa, líder indiscutible de la

facción italiana del accionariado de Air Dios Ivlío. Ün#s día$rrnjis tarde, en un
restaurante de la zona, alguien contundió ls botella 4e aguarrás con el vino de
mesa, y ácido sulfúrico con el aderezo de-las ensaladas. El eqiipo completo de
lo Voló Sam, que casualmente ese d!a celebraba en dicho restaurante la mejoría
de la situación, obtuvo la baja laboral pwr incapacidad permanente por la vía
rápida. Todo volvió a ser lo mismo...
5. PLAN FINANCIERO DEL PROYECTO
De los datos básicos del proyecto (costes, gastos e ingresos esperados) se obtiene, tal y
como se reseñó en el apartado 3.4, el presupuesto del proyecto que, al compararlo con
el precio de venta oportuno, permite obtener el margen económico del proyecto.
Pero, tal y como se explicó en la lectura "Inflación y escalación de precios" del

capítulo 2:
] 10 DIRHCCION Y GESTIÓN DE PROYECTOS © RA-MA
En general, una empresa que va a realizar unos trabajos tiende a arriesgar capital y
esfuerzo, ya que rara vez se cobra el precio de venta al comenzar a trabajar. Así, el
"flujo de caja", el diferencial entre los ingresos y la suma de costes y gastos, suele ser
negativo, a veces durante toda la vida del proyecto y hasta el final del mismo.
Los flujos de caja negativos hacen que la empresa financie, en todo o en parte, el
trabajo a realizar. Esta situación es bastante habitual, y sus efectos, correctamente
tenidos en cuenta, minoran sólo ligeramente el margen económico del proyecto.
Sin embargo, en determinadas circunstancias los costes financieros pueden reducir

sustancialmente el margen del proyecto. Por ejemplo, cuando la duración del proyecto
es muy larga {varios años), cuando hay que adelantar dinero para suministros, pagos a
proveedores o a subcontratistas, o cuando el 100% del precio se percibe al final del
trabajo e, incluso, con cierto retraso con respecto al mismo (por ejemplo, pagos a 90
días de la fecha de factura) el margen del proyecto puede verse fuertemente afectado
por dichos costes financieros.
El plan financiero se ocupa del análisis de ingresos y gastos asociados a cada proyecto,
desde el punto de vista del instante temporal en que se producen. Su misión
fundamental es detectar las situaciones financieramente inadecuadas.
A estas alturas de la evaluación del proyecto, cuando ya se ha realizado una

planificación temporal del mismo, se debe disponer ya de una idea clara (o, al menos,
suficientemente aproximada) de cuál es la previsión temporal de los costes y gastos
del proyecto, así como de los ingresos esperados.
La figura 3.15 muestra un posible formato para confeccionar el plan financiero del
proyecto^. En él se incluyen de manera automática los datos globales de ingresos y
gastos del proyecto (que se obtienen del presupuesto). El usuario debe proyectar los
valores globales sobre el período asociado a la duración del proyecto. En el formato de
ejemplo se considera un plan financiero de hasta 12 meses, aunque fácilmente puede
adaptarse a duraciones distintas.
Para obtener el plan financiero deben rellenarse las casillas recuadradas y sombreadas,
tanto para los conceptos de costes y gastos como para los de ingresos. Nótese que
ambos conceptos pueden extenderse más allá de la duración de los trabajos cuando,
por ejemplo, se cobra meses después de la finalización del trabajo, o se hace lo propio
con las facturas de los proveedores o subcontratistas.
Este formato está disponible en el fichero \formatos\plantillas\datos_economicos.xls.

Para estimar financieramente el resultado del proyecto, es necesario contar con un dato
básico: el tipo de interés aplicable, que es la referencia básica para calcular el valor
actual neto (VAN) de un flujo monetario^.
Figura 3.15 Formato de plan financiero del proyecto
Obtenido el margen del proyecto, es interesante calcular la tasa de rendimiento

interno (TIR) del proyecto, valor que representa el margen comercial referido al
tiempo necesario para obtener el mismo, y que se calcula según la expresión siguiente:
_ ingresos - Costes Margen

I\K— ------------- — -------- = -----------
Costes • Tiempo Tiempo
Obviamente, el margen y el valor TIR sólo coinciden cuando el período de cálculo es

igual a un año completo.
s
'' E\ mecanismo de cálculo del valor actual neto de un flujo monetario se describió en la
lectura "/nflación y escalación de precios", del capítulo 2.
Finalmente, otro dato de especial interés es el beneficio del proyecto. Como ya se dijo
en el capítulo 1, el beneficio se calcula como el margen económico menos los costes
de oportunidad, que son los márgenes que hubieran podido obtenerse de haber
dedicado el capital y el esfuerzo a otras actividades. En el formato propuesto en la
figura 3.15 el beneficio se calcula detrayendo el coste de oportunidad (referido al
período de tiempo correspondiente) de la tasa de rendimiento interno (TIR) del
proyecto.
Pero el plan financiero tiene otras aplicaciones, aparte de evaluar el rendimiento del
proyecto en el tiempo. Sirve, por ejemplo, para:
•" Determinar la carga de trabajo, que es el número de horas de esfuerzo o,

dicho de otra manera, las personas que hacen falta, mes a mes, para realizar
los trabajos necesarios.
*** Determinar los flujos de caja y prever la liquidez necesaria para hacer frente a
los pagos comprometidos.
•■ Evaluar estrategias de pago que mejoren el rendimiento financiero (por

ejemplo, negociar y modificar las condiciones de pago a proveedores, o
negociar pagos intermedios por parte del Cliente).
** Comparar la evolución del proyecto, una vez en marcha, con la prevista

inicialmente, según se indica en el capítulo 5 (seguimiento del proyecto).
6. UN EJEMPLO: EL PROYECTO DE FLORES DEL SUR
Para ilustrar el contenido de este capítulo vamos a resolver a continuación un ejemplo

de pequeño proyecto multidisciplinar, donde la empresa modelo Caos Consulting tiene
que ejercitar todo el proceso proyectual, desde la identificación de oportunidades,
hasta la presentación del documento de oferta.
En este apartado se presentan algunos de los criterios y mecanismos para organizar la

gestión del proyecto propuesto. Evidentemente, dichos criterios varían en función del
tipo de empresa, la persona que redacte la oferta, la cultura de gestión o la solución
técnica elegida como óptima. Diferentes soluciones no han de ser necesariamente
peores, sino que revelarán, más bien, la "cultura" de gestión del autor.
6.1 Antecedentes
Uno de los clientes de Caos Consulting S.A. es la empresa Flores del Sur, S.A., con
sede en Sevilla. En el pasado se les realizó el proyecto de instalación de su oficina
central, así como diversos trabajos de consultoría para la instalación y puesta en
marcha de su departamento de informática, con el que, básicamente, realizan sólo las
labores de gestión administrativa. Quedaron razonablemente satisfechos con el trabajo
realizado.
Hace pocos días el Sr. Jaime Lonar, Director General de Caos, estuvo jugando al golf
con el Sr. Warren González, Consejero Delegado de Flores del Sur, quien le
manifestó su interés por ensamblar una red de área local como experiencia piloto para
la futura integración de gestión de pedidos, envíos y stock en una plataforma
informática centralizada.
El Sr. González no sabía exactamente cómo será el sistema, pero sí sabía que quieren
una base de datos que mantenga el stock diario de cada tipo de flor en cada uno de los
12 almacenes de la compañía, así como los pedidos diarios según cada tipo de flor, de
cada uno de los 135 puntos de venta autorizados. Esta información, en la actualidad, se
recibe sin compilar, vía fax, desde cada almacén, cada día laborable y en torno a las
20:00 horas.
Además, reconoció que no tienen los requisitos del todo claros, pero un sistema
basado en la base de datos Oracle les suena familiar. Tampoco desean entrar en
detalles técnicos complejos, pero indicó que el sistema piloto:
> Habrá de ser ampliable a la futura plataforma de gestión de pedidos,

envíos y stock.
> Habrá de incluir una red de área local para conectar el puesto
administrativo ya existente con un puesto para la gestión de la base de
datos, otro para el despacho del jefe de logística y otro para la secretaría
(quien se encarga de los mailings a los puntos de venta autorizados).
> Habrá de ser complementado con un curso de formación para el
informático de la empresa, el jefe de logística y la secretaria, pudiendo
incluso recibirlo el mismo Sr. González.
Ante las sibilinas propuestas del Sr. Lonar, el Sr. González sugirió la posibilidad de
que Caos Consulting presentase una oferta "no solicitada1" para la definición,
especificación, adquisición e integración de dicho sistema, así como para la provisión
de un pequeño curso de formación. Manifestó también su interés por tener dicho
sistema en marcha antes de la festividad de la Patrona del Tanganillo, época de gran
demanda de adornos florales, para la que aún faltan cinco meses, y dijo disponer de en
torno a 60.000 € (equipo e IVA incluidos) para ello.
Aunque no lo confirmó, no negó tampoco la posibilidad de pedir oferta,

simultáneamente, a otras empresas (o de que ya hubiesen sido solicitadas y/o
presentadas anteriormente).
El Sr. Lonar, a continuación y tras dejarse ganar al golf, se apresuró a telefonear a

Sandra Mática, Directora de ingeniería de Caos, instruyéndola para que pusiese en
marcha la maquinaria de ofertas de la empresa.
La Sra. Mática designó, entonces, a Armando Bronca, Director de Proyecto de la sub-

sección de telecomunicaciones, como director/gestor de la oferta, comentando el
hecho de que, en el ejercicio anterior, el beneficio medio de la Sección de Ingeniería
rondó el 20%. No obstante, y habida cuenta de las buenas relaciones con el Cliente, y
del carácter de la oferta, se admitiría recortar ligeramente dicho beneficio.
6.2 Análisis de los antecedentes
El objetivo de este primer análisis es recopilar los antecedentes que rodean la potencial
presentación de la oferta. Estos antecedentes conforman un panorama subjetivo, que
proporcionará una idea aproximada de la esperanza de obtener la adjudicación del
contrato, tal y como se reseñó en el apartado 2 del presente capítulo.
A raíz del enunciado de la detección de oportunidad descrita, se extraen los siguientes

aspectos clave del proyecto:
> El Cliente es una empresa mediana-pequeña, no técnica (su negocio son

las flores, y no la informática). Es preciso adoptar un lenguaje claro y
comprensible. No es conveniente complicar el diseño propuesto, sino
simplificar al máximo el sistema y minimizar los requisitos de
mantenimiento. Resultará difícil proponer soluciones tecnológicamente
muy avanzadas.
> Ya se ha trabajado para ellos. Son conscientes de la capacidad y
responsabilidad de la empresa. Conocen las debilidades, y habrá que
demostrar en la oferta (caso de presentarla) que han sido subsanadas.
También habrá que resaltar los aspectos en los que quedaron satisfechos.
Sin embargo, Caos puede estar en desventaja ante empresas radicadas en
Sevilla, que al no incurrir en costes importantes de desplazamiento,
pueden abaratar el precio y, además, estar en contacto más cercano con el
Cliente.
> Quedaron razonablemente satisfechos. Este hecho predispone la selección
de la oferta de Caos frente a otras, siempre y cuando no sea
excesivamente débil desde el punto de vista técnico, o muy cara desde el
económico.
> El alcance del trabajo está mal definido. Planteará problemas a la hora de
definir el contenido exacto y los requisitos del proyecto. Será difícil
acotar las tareas a realizar. Será conveniente dejar un margen económico
para amortiguar las posibles lagunas en las especificaciones.
> Posibilidad de futuras ampliaciones del alcance. La oferta puede ser de
carácter estratégico, sirviendo como "cebo" para conseguir futuros
contratos, de mayor envergadura. Tal vez sea conveniente afinar el
precio, con el fin de lograr este contrato, disminuyendo el margen de
beneficios.
> Han solicitado o solicitarán otras ofertas. Previsiblemente contactarán
con otras empresas para solicitar ofertas similares, lo que les permitirá
comparar precios y calidades técnicas.
> Sugieren utilizar un producto específico, Oracle, para la base de datos del
sistema; Han recibido comentarios al respecto, o existen motivaciones a
favor de este producto. La oferta deberá proponer Oracle, salvo que se
puedan justificar adecuadamente los inconvenientes técnicos, la
complejidad adicional o un coste excesivo. Caso de proponer un producto
distinto, tal vez sea buena idea dejar Oracle como alternativa.
> El plazo de entrega (cinco meses, menos el período de oferta y
adjudicación del contrato) no parece un problema, salvo por el hecho de
que las especificaciones del producto no están muy claras, y al final
pueden aparecer pequeños problemas que requieran "ajustar" el resultado
a los deseos del Cliente.
> El presupuesto (según indican) se sitúa en torno a 60.000 €. Puede ser un
tiento a la baja, siendo el presupuesto disponible mayor. En cualquier
caso, habrá que tratar de ajustar costes al orden de magnitud propuesto,
para evitar que otro ofertante (que sí respete ese umbral) se adjudique,
por dicha razón, el contrato.
> La competencia puede ser alta, ya que no existen grandes barreras de
entrada para este tipo de proyectos.
Realizando el análisis descrito en el apartado 2, el Director de Proyecto Armando

Bronca describió, en una comunicación interna dirigida a sus superiores de Caos, el
siguiente panorama general:
"El proyecto es del tipo técnico que Caos Consulting puede ejecutar, pues está
dentro del área de conocimiento de la empresa. Supuestamente, pues, Caos
debe disponer de recursos para afrontar el proyecto, y los costes medios por
empleado se sitúan en torno a la media del mercado. No parece que haya un
proveedor seleccionado de antemano, aunque se supone va a haber
competencia. Estimar el coste, el margen y el beneficio del proyecto es
complejo (puesto que el alcance está mal definido), pero a priori, la cantidad
manejada parece suficiente para un proyecto de esta envergadura. Además,
116 DIRECCIÓN Y GESTIÓN DE PROYECTOS & RA-MA
obtener este contrato puede significar que las futuras ampliaciones a la red de
Flores del Sur sean adjudicadas directamente a Caos. Se recomienda, pues,
proceder a evaluar el coste previsto del proyecto."
A la vista de lo anterior, la Sra. Mática dispuso que se procediese a realizar la

estimación económica del proyecto, incluyendo la identificación del alcance del
trabajo, el análisis de costes, la planificación y la fijación de un precio de venta para el
proyecto.
6.3 Identificación de las tareas a realizar
La siguiente etapa del proceso de decisión de presentación o no de la oferta es la

identificación y segregación de las tareas y actividades a llevar a cabo, lo que
permitirá evaluar el coste interno de la realización del proyecto y, de ahí, derivar el
precio de venta al Cliente.
De la información transmitida acerca de la conversación entre el Sr. Lonar y el Sr.

González se desprende el siguiente alcance del trabajo a realizar:
*" Especificación y diseño (HW/SW) de un sistema en red.
■ Especificación, diseño e implantación de una aplicación de gestión y consulta de

bases de datos.
^ Adquisición de materiales:
> Equipos.
> Red de comunicaciones.
> Software (Sistema Operativo, Base de Datos, etc.).
*" Instalación y prueba del sistema completo (HW/SW).
*" Curso de formación sobre sistema operativo, base de datos, etc.
Para extraer los diferentes paquetes de trabajo, es conveniente representar

gráficamente el flujo de trabajo, donde se identificarán las dependencias temporales
entre las tareas. Tras un pequeño análisis, podríamos llegar a la conclusión de que la
secuencia (flujo) de actividades debe comenzar analizando las necesidades de la
empresa, y realizando un diseño del sistema que las satisfaga. A continuación, si el
Cliente está conforme con dicho diseño, pueden dar comienzo dos actividades
distintas, casi en paralelo, orientadas a especificar el programa software del sistema, y
a especificar y adquirir los ordenadores y las redes de área local. Una vez se disponga
tanto del hardware (equipos) como del software (programa de aplicación), pueden
CAPITULO 3: EVALUACIÓN DEL PROYFXTO 117
comenzar, a la vez, las tareas de instalación e integración, con la preparación de un

curso de formación para el Cliente que, una vez impartido, dará por terminado (previa
aceptación) el proyecto. Este flujo de trabajo queda representado en la figura 3.16:
Figura 3.16 Flujo de actividades del proyecto Flores del Sur
El flujo de trabajo anterior permite descomponer el proyecto en paquetes de trabajo.

La descomposición se hará atendiendo a los siguientes requisitos:
> Agrupar actividades relacionadas dentro de un mismo paquete de trabajo.

> Escindir la responsabilidad entre los diferentes componentes del equipo
de trabajo.
> Minimizar las interfaces entre los distintos paquetes de trabajo.
Existen muchas otras organizaciones posibles para este proyecto, que generalmente
sólo difieren en detalles, y suelen responder más bien a la cultura proyectual del
contratante (Cliente) o del contratado, y no a diferencias importantes en la forma de
abordar el trabajo. Así, por ejemplo, nuestro Cliente podría preferir insertar una
actividad intermedia de análisis de los sistemas utilizados por otras cadenas de la
competencia, o desarrollar un sistema intermedio de prueba para verificar que
realmente es lo que necesita. Por nuestra parte, podríamos decidir preparar el curso de
formación nada más finalizar el diseño del sistema, para liberar a la gente que lo
prepare lo antes posible, para otros trabajos.
Para convertir el flujo de actividades anterior en un árbol o estructura de paquetes de

trabajo, se agrupan las actividades en grandes bloques, separando aquéllas
conceptualmente distintas, e independientes entre sí, y según los criterios enunciados
en el apartado 3.1, La figura 3.17 muestra un posible árbol para el ejemplo anterior.
Figura 3.17 Estructura de paquetes de trabajo para el proyecto

Flores del Sur
En las figuras 3.18 y 3.19 se muestran, a modo de ejemplo, posibles descripciones

textuales de un paquete de trabajo de gestión (paquete 0) y de otro de tipo técnico
(paquete 110, preparación del curso).
Referencia : P.032-99 Edición Fecha: 01.12.04
PAQUETE DE TRABAJO : PT.O GESTIÓN
RESPONSABLE: Armando Bronca ESFUERZO: 60 horas
COMIENZO : 01.01.05 FINAL: 20.04.05
ENTRADAS:
Documento de oferta
Contrato
Datos económicos de la apertura del proyect
SALIDAS :
Informes de situación de las actividades del proye

Informe final
Informe de cierre de proyecto
TAREAS:
• Dirigir la ejecución del proyecto

• Definir directrices básicas y pautas de realizad
• Supervisar la correcta ejecución de las tareas
• Gestionar y coordinar los recursos materiales y humanos
• Canalizar las relaciones con el Cliente
• Organizar y conducir las reuniones
■ Editar y aprobar la documentación generada
• Supervisar la aceptación final de los trabajos
RESULTADOS:
OTROS COMENTARIOS :
• Objetivo adicional del proyecto: ayudar a Flores de Sur, durante el proyecto, a definir
y especificar la futura plataforma de gestión de stocks, como mecanismo para facilitar
la obtención (por parte de Caos) del futuro contrato.
• Objetivo adicional: extender el alcance del proyecto al desarrollo de aplicaciones para
la consulta remota de stocks, desde los puntos de venta, a través de línea telefónica y
modem.
12(1 DIRECCIÓN Y GESTIÓN DE PROYECTOS © RA-MA
Descripción de los paquetes de trabajo

Pág. 10 de//
RED DE FLORES DEL SUR, S.A.
Referencia: P.032-99 Edición : Fecha: 01.12.04
PAQUETE DE TRABAJO: PT.31Ü PREPARACIÓN DFX CURSO
RESPONSABLE: Javier Nés ESFUERZO: 64 horas
COMIENZO: 09.04.05 FINAL : 13.04.05
ENTRADAS:
» Documento de Oferta y Contrato (PT.0)

* Documento de requisitos del sistema (PT. 110)
. Documento de diseño HW/SW del sistema(PT.120)
» Manual de usuario de la aplicación SW(PT.210)
» Manuales de usuario de los dispositivos HW (PT.220)
SALIDAS:
• Transparencias del curso "Red de llores del Sur"

• Manual de introducción ai sistema.
TAREAS:
• Recopilar información sobre requisitos de usuario, y diseño y uso del HW/SW del sistema
• Proponer índice del curso para aceptación
• Elaborar transparencias del curso
• Elaborar manual "rápido" de uso de! sistema
RESULTADOS :
OTROS COMENTARIOS:
• Formato de las transparencias: PowerPoint. Diseñar, aprovechando el PT, un formato de curso para
futuras ocasiones.
Figura 3.19 Contenido del Paquete de Trabajo "PT.310,

Preparación del curso"
Como ya se dijo anteriormente, la descripción de los paquetes de trabajo debe servir,

además, para detectar inconsistencias en el reparto de actividades. Supongamos, por
ejemplo, que al configurar la estructura del proyecto de Flores del Sur, hubiésemos
olvidado incluir el paquete PT.120, "Diseño HW /SW". Al describir el paquete
PT.210, "Desarrollo de la aplicación SW", hubiésemos tenido que incluir como
entrada las especificaciones de diseño SW, que no son la salida de ninguno de los
paquetes restantes. Esta inconsistencia nos habría facilitado detectar que, entre el
análisis de requisitos y el desarrollo, falta una tarea intermedia (el diseño).
6.4 Estimación de horas y gastos
Ésta es, sin lugar a dudas, la parte más compleja de la preparación de la oferta. La
estimación de costes al alza supondrá ofertar a un precio poco competitivo, con la
posible pérdida del contrato, mientras que la estimación a la baja podrá ocasionar que
el proyecto termine con pérdidas.
La estimación es tanto más compleja cuanto:
> Peor definido esté el alcance del trabajo.

> Menor sea nuestra experiencia real en proyectos similares.
> Mayor sea el número de actividades a realizar.
> Mayor sea la envergadura global del proyecto.
En el caso que nos ocupa, los parámetros a estimar son los siguientes:
> Coste de las horas de personal.

> Coste de los servicios informáticos y de consumibles.
> Coste de los desplazamientos del personal (viajes y estancias).
> Costes del suministro de equipos y software al Cliente.
La figura 3.20 muestra una posible estimación de las horas de trabajo, según
categorías, asociadas a la realización de cada paquete de trabajo.
A la hora de realizar la estimación anterior, Armando ha seguido escrupulosamente los

requisitos del Cliente (hasta donde la falta de definición concreta permite), con el fin
de reducir al máximo posible el coste del proyecto. Sin embargo, y con el fin de
despertar el interés de Flores del Sur, ha evaluado e incluido en la estimación una
mejora al alcance mínimo del proyecto. Dicha mejora consiste en la provisión de un
módem telefónico y una extensión a la aplicación a desarrollar, que permitirá que los
puntos de venta de Flores del Sur consulten el estado del stock a través de la línea
122 DTRBCCION Y GESTIÓN DE PROYECTOS © RA-MA
telefónica40. Además, es el embrión de la futura ampliación del sistema (que Armando

espera se le contrate igualmente a Caos) para permitir realizar pedidos de manera
automática, también a través de módem.
1 GESTIÓN (1 60 60
2
3 DISEÑO DEL SISTEMA 100
4 Análisis del sistema 110 8 60 16 84
5 Diseño HWSW 120 8 40 48
6
7 DFSAIÍROM,O DE1. SISTEMA 200
8 Desarrollo de la aplicación 210 300 16 316
9 Adquisición e instalación HW 22(1 80 80
10 Integración HW / SW 230 40 40 80
II
12 FORMACIÓN 300
13 Preparación del curso 310 24 24 16 64
14 Impartición del curso 320 8 24 16 48
15
II.
17
18
19
20
Figura 3.20 Estimación del esfuerzo asociado al proyecto de Flores

del Sur
40
Armando evaluó la posibilidad de implantar esta opción a través de Internet, pero el alto
coste de desarrollo, sumado al hecho de que muchos puntos de venta no disponen de conexión
a Internet le hizo decantarse por la opción más segura, aunque menos glamurosa.
Una forma de verificar la consistencia de la estimación realizada es observar el

porcentaje de horas totales según categoría. En un proyecto típico de ingeniería, los
"mandos" no intervienen más que al principio y al final de la negociación (en nuestro
caso, un 2% del total), mientras que el grueso del trabajo es realizado por ingenieros
júnior y personal técnico y de soporte (en el proyecto descrito, el 83%). Los ingenieros
sénior, que dirigen la evolución del proyecto (pero no lo ejecutan), intervienen en
torno a un 8,7%.
Un desbalance excesivo en los valores descritos puede revelar que la empresa no es

eficiente en costes (parte del trabajo lo hace gente de categoría superior a la
requerida), o que asume excesivo riesgo al dejar tareas de responsabilidad en
trabajadores con poca experiencia.
La figura 3.21 muestra la distribución de la carga de trabajo según categorías, donde

se observa que la mayor parte del trabajo (63%) la realizan ingenieros júnior y
personal técnico (20%), y sólo el 11% de las horas las consumen ingenieros sénior.
Como el proyecto de Flores del Sur, además, es técnicamente sencillo, no ha sido
necesario prever horas de consultoría.
Figura 3.21 Esfuerzo, según categorías, en el proyecto de Flores del

Sur
Otro dato relevante es la proporción de esfuerzo según áreas funcionales del trabajo a
desarrollar, que se muestra en la figura 3.22. Según esta figura, el desarrollo ocupa
aproximadamente el 61% del esfuerzo total, cifra que es consistente con el tipo de
proyecto a ejecutar.
Figura 3.22 Esfuerzo, según áreas funcionales, en el proyecto de

Flores del Sur
A continuación procederemos a estimar los costes de viajes y estancias requeridos.

En nuestro caso distinguiremos entre desplazamientos a Madrid (por ejemplo, para
adquirir material), viajes a Sevilla de un día de duración (ida y vuelta en el día, sin
pernocta) o de dos días de duración. El coste estimado para cada tipo de
desplazamiento o viaje es;
Desplazamientos a
Madrid:
15€ 25 € 40 Euros
> 70 km. ida y vuelta /desplazamiento
> Varios
> TOTAL
Viajes a Sevilla, de 1 día de duración:

> Desplazamiento 350 € 100 € 450
> Gastos Euros /viaje
> TOTAL
Viajes a Sevilla, de 2 días de duración:

> Desplazamiento 350 €
> Hotel 150€
> Gastos 150 €
> TOTAL 650 Euros/viaje
La previsión de los desplazamientos y viajes necesarios para cada tarea del proyecto se
muestra a continuación:
*" Análisis de requisitos:

> 1 viaje de 2 días a Sevilla
> 1 viaje de 1 día a Sevilla
*" Instalación e integración:

> 2 viajes de 2 días a Sevilla
> 1 viaje de 1 día a Sevilla
^ Curso (impartición):
> 2 viajes de 2 días a Sevilla
** Varios (gestión, reuniones, etc.):

> 4 viajes de 1 día a Sevilla
> 10 desplazamientos a Madrid
A continuación hay que calcular el coste de los suministros hardware y software.

Para ello se ha elegido una configuración basada en PC's estándar, tipo Pentium 4, y
Microsoft Access como sistema gestor de base de datos (elección que habrá que
justificar técnica y económicamente al Cliente, como parte del documento de oferta,
ya que mostró su preferencia por Oracle^')- Armando Bronca ha previsto una mejora
al alcance que, como ya se ha dicho, consiste en la posibilidad de que los puntos de
venta consulten el estado del stock a través de módem, por lo que también se ha
cotizado un dispositivo de este tipo en el presupuesto. Los suministros y sus precios
(obtenidos a través de una oferta solicitada al proveedor de equipos informáticos
BitPC Factory) serían, pues, los reseñados en la siguiente lista:
3 x Ordenador Pentium 5.400 €

> 4 1 x Modem 200 €
41
No obstante, y pese a ello, se ha optado por otro paquete de base de datos a raíz del informe
del personal técnico de Caos, que indica que optar por Oracle impondría un tuerte sobrecoste
asociado al aprendizaje del manejo de una nueva herramienta.
] 26 DIRECCIÓN Y GESTIÓN DE PROYECTOS
> 4 x Adaptador de red 200 €

> 4 x Segmentos de red 50 €
> 3 x Licencias Windows 550 €
> 3 x Licencias Access 800 €
> TOTAL 7.200 €
A los precios anteriores habría que añadir el coste de transporte de Madrid a Sevilla,
que supone 260 € en concepto del porte, y 216 € más (un 3% del valor asegurado) para
la cobertura mediante un seguro.
Por último, se estima que será necesario adquirir herramientas de desarrollo en Access
para los programadores de Caos, que faciliten la ejecución del trabajo y cuyo coste se
estima ronde los 750 €.
En la figura 3.23 se incluye el formato relleno correspondiente a la estimación

económica del mencionado ejemplo, donde se observa que:
■*" Se han valorado las contingencias de personal en torno al 5% de las horas

estimadas, con el fin de mitigar posibles sobre-esfuerzos derivados de la mala
definición del alcance de los trabajos.
*" El coste de realizar el proyecto se estima en 47.285 €, de los que 29.535 son
costes de personal, y 17.750 € son costes de suministros y varios.
"" Para un margen del 20%, el precio de venta sería de 65.821 € (IVA incluido),
algo superior al máximo mencionado por el Sr. González, de 60.000 €.
"■ Para entrar en el umbral de precio de Flores del Sur, el beneficio máximo sería
de un 9,39%, o sea, de 4.439 €.
HOJA DE ESTIMACIÓN ECONÓMICA DE PROYECTO
Red de Sre local y BD de stock REFERENCIA : P 032-99

More 3 ÜBÍ Sur, S.A. DIRECTOR : Arm ndo Bronca ;gi¡ra
S
FECHA INICIO ene-05 mav-05
PRECIO VENTA (SIN

IVA): ESFUERZO:
MARGEN:
1.A COSTES DE PERSONAL
CAT 1 (DI) 79.98 1,69 2,00% C

ÂT 2 (CO) 49.51 1,69 3,00% C
CAT 3(IS) B4 35.04 1,69 4,00% 5.173
;AT 4 (IJ| 488 21,33 1,69 5,00% 18.471
CAT 5 (TE) 160 17,52 1,69 5,00% 4.974
CAT 6 (PA| 48 10,66 1,69 6,00% 917
SUBTOTAL 1.B
SUBCONTRATACIONES
SU8CJ SUBC_2
SUBTOTAL 1.C COSTES VARIOS
ORDENADOR: CONSUMIBLES : 780 2,34 1,00 5,00%

OTROS 780 0,75 1,00 5,00%
780 1,00 5.00%
-, ----
3.09 :
SUBTOTAL 1.D OTROS GASTOS
----- 1
MATERIAL/EQUIPO
VIAJES / ESTANCIAS
VARIOS :
TOTAL COSTES Y GASTOS
Z, PRECIO DE VENTA .
2.A MARGEN
PERSONAL 29.535
SUBCONTRATACIONES 0
COSTES VARIOS 12,00% 2 531
OTROS GASTOS 12,00% 15.219
TOTAL 47 285
2.B PRECIO DE VENTA
PRECIO DE VENTA, Euros, SIN ESCALACION INTERANUAL
PRECIO DE VENTA, Euros, CON IVA al... [ 16.00%|
Figura 3.23 Presupuesto estimado para el proyecto Flores del Sur

6.5 Planificación temporal y recursos
A partir de las actividades involucradas y del número de horas de esfuerzo estimadas

para cada una de ellas, es posible confeccionar una planificación temporal del
proyecto. La mayor o menor duración del proyecto es un compromiso entre el tiempo
disponible (normalmente fijado por el Cliente), y los recursos a emplear en cada
actividad.
En general, cuanta más gente participe en una actividad, más rápidamente se

finalizará, y a la inversa. No obstante, hay que tener en cuenta que fragmentar
demasiado el trabajo supone que varias personas deben involucrarse en la actividad,
ponerse al tanto de los requisitos del proyecto, del plan de desarrollo, de la tecnología
involucrada, de la documentación existente, etc., y esto puede encarecer en exceso el
coste. Además, no siempre añadir una persona más al equipo de trabajo acorta el
tiempo de ejecución del mismo. Es, pues, un ejercicio de estimar el número de
personas por actividad que supondrá un tiempo mínimo para su ejecución.
La figura 3.24 muestra la planificación temporal que se estima adecuada para ejecutar
el proyecto de Flores del Sur, y que satisface plenamente el margen máximo de que se
dispone e, incluso, acorta en un mes el plazo disponible:
Figura 3.24 Planificación temporal prevista para el proyecto

Para ello, Armando Bronca identifica los siguientes recursos necesarios, que negocia y
conviene con la responsable de la sección de ingeniería, Sra. Mática:
> El propio Armando Bronca, como Director del proyecto y responsable de

la supervisión del diseño del sistema, del desarrollo de la aplicación y de
la impartición del curso de formación. Su carga de trabajo media
(aproximada) será de 84 horas en cuatro meses, lo que equivale a unas 21
horas al mes (un 13% de su tiempo disponible).
> Un ingeniero júnior, que realizará el diseño del sistema, la mayor parte
del desarrollo de la aplicación, y colaborará en la preparación del curso
de formación, que también impartirá. Dedicará unas 488 horas, lo que
supone una dedicación aproximada del 76% de su jornada laboral.
> Un ingeniero técnico, que se encargará de la adquisición de los
suministros, la instalación e integración del sistema, y otras labores de
soporte, incluyendo el curso de formación. Dedicará 160 horas en dos
meses, al 50% de su tiempo.
> Una secretaria, para labores auxiliares. Dedicará 48 horas, durante la
totalidad de la duración del proyecto.
De la estimación de horas por actividad y tarea, así como de la planificación temporal

del proyecto, se deduce la distribución temporal de esfuerzo (carga de trabajo) por
categorías, que es la reflejada en la tabla siguiente:
CARCA DE TRABAJO PREVISTA, POR CATEGORÍA Y MES

CATEGORÍA MES1 MES 2 MES 3 MES 4 TOTAL
DI
CO
IS 29 17 15 23 84
IJ 90 150 160 SS 488
TE 80 80 160
PA 16 8 8 16 48
TOTAL 135 175 263 207 780
Hay que tener en cuenta que las previsiones anteriores son sólo eso: previsiones.
Resulta muy complejo determinar la dedicación de las personas cuando ésta es inferior
al 100%. Si una persona, pongamos por ejemplo, debe dedicar 6 horas diarias a un
proyecto, es muy difícil encontrar otro proyecto al que pueda destinar las 2 horas
diarias restantes''2. Además, los días o semanas anteriores a una entrega o reunión
suele ser necesario volcar todo el esfuerzo posible en el proyecto en curso, y ese tipo
de variaciones y cambios de ritmo suelen convertirse en el peor quebradero de cabeza
42
Y, peor aún, como se instaure la jornada laboral de 35 horas, en cuyo caso sólo quedaría una
hora diaria disponible.
del empleado en cuestión, el Director del proyecto y, también, del responsable de la

sección (en este caso, la Sra. Mática).
6.6 Plan financiero del proyecto
Con los datos anteriores Armando Bronca prepara el plan financiero del proyecto. Para
ello, hace varias hipótesis acerca de los flujos monetarios asociados a los trabajos a
realizar, que incluyen las siguientes:
> El Cliente abona el 50% de la facturación total al comienzo de los

trabajos, y el otro 50% a la finalización y aceptación de los mismos.
Conociendo al Chente, abonará las facturas a 90 días de la fecha de
emisión de las mismas, por lo que los pagos no se harán efectivos hasta
los meses 3 y 7, respectivamente.
> Los suministros (equipos) se adquirirán durante el segundo mes, pero se
abonarán 90 días después de la fecha de factura, esto es, durante el mes 5.
> Los demás costes se distribuyen entre los cuatro meses de duración de los
trabajos.
> El tipo de interés de mercado vigente se sitúa en torno al 3%, y el coste
de oportunidad de otros proyectos de Caos se considera del 15% (algo
inferior al 20% de margen medio deseable para los proyectos de la
empresa).
El plan financiero del proyecto queda tal y como se muestra en la figura 3.25.
A partir del plan financiero anterior resulta sencillo valorar los resultados previstos
para este proyecto. Así, aunque el margen bruto del proyecto es del 9,39%, al
proyectarlo sobre la duración real del mismo (siete meses, que es el momento del
último flujo de caja) supone un 16,1% de rendimiento (TIR) efectivo"", que es un valor
bastante bueno en comparación a la media de otros proyectos de la empresa. Incluso
con un coste de oportunidad del 15%, el proyecto alcanza un beneficio real del 7,3%.
Además, como se muestra en la figura 3.26, que compara ingresos, gastos y margen a
lo largo del tiempo, desde el punto de vista de la financiación el proyecto representa
un endeudamiento máximo para la empresa de 25.423 €, durante los meses 5 y 6, que
es una cantidad bastante acorde con las posibilidades de Caos.
43
El concepto de la Tasa de Rendimiento (TIR) se introdujo en la sección 5 de este mismo
capítulo, y se formalizará (junto con otros indicadores financieros de un proyecto)
posteriormente en el capítulo 6.
6.7 Recomendación del responsable de la oferta
A la vista de lo anterior, Armando Bronca, Director de la oferta, escribe una

comunicación interna a la Sra. Mática, con copia al Director General, donde adjunta
una descripción del alcance del trabajo, los paquetes de trabajo, la planificación
temporal, la estimación económica y el plan financiero del proyecto.
Además, en dicha comunicación interna, el Sr. Bronca, considerando el 9,39% de

margen a obtener (16,1% TIR) si se satisface el precio máximo de venta dictado por
Flores del Sur, recomienda presentar la oferta e, incluso, habida cuenta de la relación
existente con el Cliente, y la posibilidad de obtener futuros contratos de ampliación
del sistema, rebajar ligeramente el margen y el precio de venta.
LECTURA. LAS DIFERENTES FORMAS DE DAR UN PRECIO
A lo largo del capitulo anterior se ha mostrado una metodología para calcular el

precio asociado a llevar a, cabo un proyecto, conjugando el coste del personal,
de las materias primas, de los diferentes gastos adicionales y el margen deseado.
También se ha incluido una partida de contingencias para proteger a la empresa
contra pequeñas (del orden det $%) desviaciones respecto al plan elaborado.
El precio'así resultante se denomina precio firme y fijo. El contratista se

compromete a realizar ios trabajos comprometidos por ese precio,, asumiendo
cualquier nesgó que pueda suceHer.
Si el proyecto es de larga duración (digamos de más de un año), la tasa de

inflación es muy alta o s é tiene incertidumbre, Sobre cuándo comenzará
realmente d proyecto conviene que el contratista se proteja proponiendo un
precio fijo con escalaeiótt, que equivale a decir que el precio firme y fijo se
incrementará de acuerdo con algún indicador financiero que refleje la subida de
tes desde la presentación de la oferta hasta la realización de los trabaj
rasiones también es deseable protegerse contra la incertidumbre en cuanto

sftierzo/tierripo necesario para^desempenar los trabajos. Un precie variable por
unidad &e esfuerzft/tiempo Indica que el "coste final de los trabajos
dependerá del esfuerzo real o del tiempo que sea realmente necesario para
acabar el proyecto. Este tipo de precios elimina el riesgo para pl contratista, que
Ib transfiere en su totalidad a ÍK parte contrataote, quien, a su vez, tratará de
protegerle solicitando una estimación del coste final y una garantía de que el
precio final (variable) no se desviará en más de un porcentaje con respecto al
indicativo.
proyecto y aplicarse a altérenles partidas. No es extraño que un proveedor fíie el

precio como una partida firme y fija (su "mano de obra"), más una componente
variable para, por ejemplo, cubrir el coste de los materiales.
A cualquiera de los precios anteriormente citados {firme y fijo, fijo con

escalación y variable) se le pueden añadir incentivos. Los incentivos son
gratificaciones que se añaden al; precio acordado si se cumplen determinadas
circunstancias (acabar el trabajo a tiempo o ante$ de tiempo, alcanzar un
objetivo comercial, etc.)- Lo contrario de un incentivo es, pues, una
penalización* que disminuye el precio acordado si se incumplen las condiciones
del contrato (plazo de entrega, nivel de calidad, etc.).
¿Cuándo se aplica cada tipo de precio?
En general el comprador siempre prefiere aprecios firmes y fijos que le

garanticen el coste total y dejen en manos del vendedor (el contratista) el riesgo
de desviaciones con respecto al presupuestó», Además, los precios variables
suelen exigir que el comprador supervise los trabajos del contratista para
asegurarse de que no se invierten más, ünktades.de esfuerzo o de tiempo de las
realmente necesarias. '
Por el contrario, el contratista tenderá a preferir precios váríabl£s»\qüe le

protegen de malas estimaciones p de incertidumbres en el esfuerzo necesario.
Esto es especialmente cierto en trabajos de; investigación o de consultoría.
donde predecir a priori d esfuerzo necesario es muy arriesgado.
Así que, una vez más, eHipo* de preciosurael acordad© éntrelas partes en "cada
proyecto, salvo que una de las partes, además de una buena razón para ello,
tenga una situación competitiva que le permita imponer -él-tipo de precio a la
otra. Es lo que ocurre, por-ejemplo, con la mayoría íl© los contratos de la
Administración, que tiene el suficiente "poder de compra" como para obligar a
los ofertantes a fijar un precio, eji general, firme y fijo. .
CAPITULO 4
PREPARACIÓN DE LA OFERTA
1. INTRODUCCIÓN
Detectar una buena oportunidad de negocio es como que un posible comprador entre
en una tienda: no basta. Al igual que el potencial comprador tiene que ver lo que
necesita, a un precio y en unas condiciones razonables, el potencial Cliente de un
proyecto necesita saber que tiene ante sí un equipo de trabajo capaz de realizar
correctamente el trabajo, en precio y condiciones adecuadas.
Para eso sirve la fase de oferta. Durante este trabajo preliminar, se le dice al potencial
Cliente qué se va a hacer, cómo, en cuánto tiempo y a qué precio, en caso de que se
nos adjudique el contrato. La oferta permite que el Cliente determine:
> Si lo que se puede hacer por él es lo que realmente necesita.

> Si tiene ante sí a un equipo de profesionales capaces y solventes o, por el
contrario, a un grupo de aficionados o a un equipo sin solvencia técnica,
empresarial o financiera.
> Si se le va a hacer el trabajo en el tiempo y condiciones que desea.
> Si, mediante comparación con otras ofertas, ésta es la que más le
conviene.
Una fase de oferta, al igual que el tiempo y esfuerzo que se le dedica al posible
comprador en la tienda, puede variar mucho en alcance y esfuerzo. Hay ofertas que se
transmiten verbalmente, en cuestión de segundos o minutos, tan pronto se detecta una
oportunidad de contrato y se habla con el Cliente. Otras, como por ejemplo las que
conducen a ganar el diseño de un nuevo modelo de avión, pueden llevar meses,
incluso años, e involucrar a decenas de personas y miles de horas de trabajo, con miles
de hojas de documentación. Todo depende del valor del contrato a ganar, de la
136 DIRECCIÓN V GESTIÓN DE PROYECTOS
competencia que exista, de la relación con el Cliente y de nuestro interés por conseguir
el trabajo.
En el capítulo anterior vimos cómo evaluar el alcance y coste de un proyecto, para ver
si está en consonancia con:
Lo que la empresa es capaz de hacer, con los conocimientos, instalaciones y

recursos humanos de que dispone.
•* El tiempo disponible para ello.
*" El precio que el Cliente está dispuesto a pagar o, en su defecto, el precio que
las condiciones de mercado marcan como "competitivo".
En caso de que Ja evaluación del proyecto haya sido satisfactoria, el siguiente paso es
preparar una oferta, donde se ponga de manifiesto el resultado del análisis anterior, y
se muestre al potencial Cliente nuestra capacidad para ejecutar correctamente los
trabajos que son objeto del contrato. El propósito de este capítulo es identificar y
describir los pasos para confeccionar dicho documento de oferta.
2. OFERTAR, O NO OFERTAR
Llegados a este punto, disponiendo ya del análisis del trabajo a realizar, su duración y
el presupuesto global del proyecto, disponemos de toda la información objetiva
necesaria para tomar una decisión sobre la conveniencia o no de presentar una oferta.
Como suele suceder, no existe una norma general en términos de cuándo se debe
ofertar y cuándo se debe renunciar a presentar una oferta. Las ofertas "perdedoras",
aquellas que tienen pocas posibilidades de terminar en contrato (por precio, afinidad
con el Cliente, experiencia previa, mucha competencia, etc.), obligan a realizar un
esfuerzo que no revierte en beneficio alguno. Por otro lado, a veces se ganan de forma
inesperada contratos, al no presentarse otros potenciales contratistas, o al ser evaluada
nuestra oferta de manera más favorable por cualquier razón.
Además, para tomar una decisión habrá que tener en cuenta, también, la información
subjetiva contextúa! de que se disponga, y que incluya no sólo el coste del proyecto y
el alcance del mismo, sino aspectos más "sutiles" sobre las relaciones con el Cliente,
el interés del proyecto para la empresa, etc.
En concreto, habrá que considerar, al menos, los siguientes factores básicos (la
mayoría de los cuales ya se tuvieron en cuenta durante la evaluación preliminar, según
se reseñó en el capítulo 3):
©RA-MA CAPÍTULO 4: PREPARACIÓN DE LA OFERTA 137
> Si tenemos experiencia práctica y conocimientos técnicos suficientes

sobre las actividades del trabajo a realizar y, en caso contrario, si seremos
capaces de adquirirlas a tiempo, y a coste razonable.
> Si, a la luz de la planificación temporal prevista, somos capaces de
realizar el trabajo en el plazo disponible para ello.
> Cómo son las relaciones formales e informales con el Cliente.
> Si se han presentado anteriormente otras ofertas al mismo Cliente y, en
caso afirmativo, qué resultados se obtuvieron.
> Si el Cliente nos adjudicó otros contratos en el pasado, cómo
terminaron, y cuál fue el grado de satisfacción del Cliente y de nuestra
empresa.
> Qué reputación tiene el Cliente, en cuanto a su facilidad para quedar
satisfecho con los trabajos que contrata.
> Cuál es la solvencia económica del Cliente, y si será capaz de pagar en
tiempo y forma los trabajos que va a contratar.
> Si existen factores políticos a tener en cuenta, que modifican (al alza o a
la baja) nuestras posibilidades reales de obtener el contrato.
> Cuál es el orden de magnitud del precio que, previsiblemente, ofertará la
competencia por el mismo trabajo y, en especial, si puede ser claramente
inferior.
> Cuál es el coste de oportunidad de dedicar recursos a este trabajo (caso
de obtener el contrato) y, en particular, cuál sería el beneficio potencial si
dedicásemos los recursos a otro proyecto o a otro cliente.
► Si existe posibilidad (técnica, legal y económica) de, posteriormente,
revender el trabajo realizado o la experiencia adquirida a otros clientes.
> Si disponemos de recursos para preparar, en el momento actual, una
oferta adecuada para el Cliente.
> Cuál será el coste de preparar dicha oferta y, en concreto, si será un
porcentaje significativo de los beneficios del proyecto.
> Si disponemos de recursos para afrontar las actividades del contrato y,
en caso negativo, si seremos capaces de obtenerlos, a coste razonable,
para el mismo.
No obstante, incluso si la respuesta a una o varias de las cuestiones anteriores es poco

optimista, aún puede haber razones estratégicas que nos animen a afrontar la
preparación de la oferta y, en caso favorable, la ejecución del contrato:
5* Que acceder a este contrato sea llave para ampliar la cartera de clientes
potenciales.
> Que acceder a este contrato sea llave para adquirir nuevos
conocimientos o nuevas tecnologías.
138' DIRECCIÓN Y GESTIÓN DE PROYECTOS ©RAMA
> Que acceder a este contrato mejore la reputación de la empresa.

> Que acceder a este contrato facilite el acceso a otros mercados, u otras
zonas geográficas.
> Que acceder a este contrato ayude a eliminar la competencia.
> Que presentar la oferta, aun sin esperanzas para ganar el contrato, sirva
para hacer acto de presencia ante el Cliente, y evitar que nos olvide en
futuras licitaciones (es decir, la oferta tiene un carácter principalmente
promocional).
Por último, cabe decir que la decisión de presentar oferta, o no, trasciende más allá del
ámbito del propio proyecto y que, por tanto, la decisión última (al menos en grandes
proyectos) debe tomarla la dirección de la empresa, a quien habrá que proporcionar:
^ Los datos sobre contenido, esfuerzo y estimación del presupuesto.
■ Un breve informe, justificado, donde se aconseje o desaconseje la

presentación de la oferta, en función de las razones que motivan la
recomendación.
3. PREPARACIÓN DE LA OFERTA
Si hemos llegado hasta aquí, es que hemos decidido presentar la oferta al Cliente y, de
esta manera, optar a la adjudicación del contrato.
El documento de oferta es aquel que se remite al potencial Cliente ofreciéndole un

bien o servicio a cambio de una cierta contraprestación económica. Por lo general
responde a una solicitud del propio Cliente (mediante petición directa, concurso
público o restringido, etc.), aunque también puede ser una oferta no-solicitada (si se
detecta que el Cliente tiene una necesidad no cubierta, y estamos en condiciones de
satisfacerla. En este caso es interesante evaluar la capacidad real de contratación que
tenga el Cliente antes de preparar la oferta).
Llegado el momento de compilar el documento de oferta, de lo que se trata es de

mostrar al potencial Cliente que somos el equipo más idóneo para realizar el proyecto,
es decir:
Que estamos suficientemente cualificados, desde el punto de vista técnico, y

que sabemos cómo ejecutar las tareas necesarias, y cómo resolver los posibles
problemas que puedan aparecer durante el trabajo. Ésta es la oferta técnica.
CAPÍTULO 4: PREPARACIÓN DE LA OFERTA 139
Que seremos capaces de terminar el trabajo en el período de tiempo adecuado,

organizando las reuniones intermedias oportunas y gestionando los recursos
(humanos y materiales) de la manera correcta. Ésta es la oferta de gestión.
Que todo lo anterior lo haremos por un precio adecuado. Esta es la oferta

económica.
Además de mostrar a nuestro futuro Cliente que sabemos lo que hay que hacer, y que
somos capaces de hacerlo, la oferta también sirve como referencia contractual. Todo
lo que se dice en el documento de oferta que se va a hacer, incluido en el precio
propuesto, después hay que hacerlo.
El documento de oferta debe adecuarse en estructura a lo solicitado (verbalmente o

mediante escrito de petición de oferta) por el Cliente pero, en general, es de esperar
que contenga, al menos:
■*" Una introducción.
*" Los antecedentes y propósito del trabajo ofertado.
*■ El alcance práctico del mismo (indicando claramente qué no forma parte del
alcance).
cr
La oferta técnica (descripción de lo ofertado, indicando de forma somera
cómo se va a realizar el trabajo, con qué medios, qué soluciones se proponen y
qué problemas se anticipan), que mostrará al Cliente la capacidad técnica del
ofertante.
*" La oferta de gestión, incluyendo planificación temporal de la ejecución del

trabajo, esfuerzo a utilizar y personal clave.
^ La oferta económica, indicando claramente cuál es el precio final para el

contratante (incluyendo impuestos, coeficientes de actualización, etc.), los
demás gastos que pudieran derivarse, así como el momento y la forma de pago
del proyecto.
Adicional mente, y si se considera oportuno, puede incluirse:
 Referencias de la empresa en proyectos similares.
 Cualificaciones (técnicas, de calidad, seguridad, etc.) de la empresa

y/o el personal.
 Curricula vitae del personal clave.
 Cualesquiera otros datos de interés para el Cliente.

A la hora de preparar la oferta, si existe un Pliego de Prescripciones Técnicas o

Administrativas (véase el apartado 5 del capítulo 2, referido a los concursos), es
especialmente útil tener en cuenta los criterios de valoración reseñados en el mismo,
tratando de adaptar la oferta a dichos criterios e, incluso, dedicando un apartado o un
párrafo de la introducción a describir cómo y en qué medida se satisfacen los mismos.
En cuanto a la extensión del documento de oferta, varía enormemente en función del

tipo de Cliente, la relación mantenida con él en el pasado y, sobre todo, el tipo y
volumen del contrato. A modo de ejemplo, una oferta para la instalación de una red de
área local puede ocupar un par de hojas (con los datos clave) si el Cliente ya tiene
referencias nuestras, o más de cien si la oferta es de carácter estratégico y pretende
aseverar la solvencia técnica del ofertante. La oferta para la contratación de un sistema
complejo, por otra parte, puede llegar a ocupar varios cientos (y, a veces, miles) de
páginas.
En general, es conveniente no dedicar a la preparación de la oferta un esfuerzo

excesivo (pues significa coste de oportunidad para otros proyectos). Una regla general
puede ser no dedicar más del 5% del volumen del contrato, aunque el carácter
estratégico, el interés o las relaciones con el Cliente pueden modificar
significativamente al alza dicho umbral.
Las ofertas, pues, han de prepararse buscando no sólo una corrección técnica y un
buen precio, sino también que agraden al destinatario de la misma. Una estética
atrayente, un estilo cuidado, evitar incorrecciones gramaticales u ortográficas, y la
utilización de figuras, tablas y esquemas facilitará que el Cliente lea su contenido con
mayor atención y, en definitiva, propiciará un juicio favorable hacia la misma.
3.1 Oferta técnica
Como ya se ha dicho, la oferta técnica describe el problema a resolver, cómo

pensamos resolverlo, qué riesgos se anticipan, y cómo se abordarán llegado el caso.
El propósito de esta parte del documento de oferta es múltiple:
> Mostrar al potencial Cliente que hemos entendido su problema, sus

necesidades y sus requisitos específicos.
CAPITULO 4: PREPARACIÓN DK LA OFERTA 141
> Anticiparle una potencial solución (sin llegar a resolver el problema, eso
se hará durante el contrato), para mostrarle nuestra capacidad técnica.
> Identificar los puntos conflictivos del trabajo a realizar, y anticipar
posibles soluciones.
> Justificar el tiempo y el dinero que consideramos necesario para
ejecutar el proyecto.
El nivel con el que se tratan en la oferta los aspectos anteriores es muy dependiente del
volumen económico del contrato, del tipo de relación con el Cliente y, sobre todo, del
riesgo técnico del trabajo. En general, más vale excederse ligeramente en extensión y
detalle que quedarse corto y dar la sensación de descuido o incapacidad técnica. No
obstante, el exceso también es malo, y puede abrumar al Cliente con detalles de muy
bajo nivel, que luego pueden no corresponderse con los reales, que surgen durante la
ejecución del proyecto, etc.
También el índice de la oferta técnica varía enormemente de un proyecto a otro, pero

en casi todos los casos es necesario incluir:
> Una introducción, donde se sintetice nuestra comprensión del problema.

> Un alcance general, donde se describa, a grandes rasgos, en qué
consistirá el trabajo.
> Una descripción de las actividades previstas, incluyendo el diagrama
árbol de actividades.
> Una descripción de los materiales, herramientas y sistemas que se
utilizarán para la ejecución del trabajo, incluyendo una lista de los que, a
la finalización del proyecto, quedarán en propiedad del Cliente.
> Una lista de entregables, incluyendo documentos, productos, y cualquier
otro elemento que el Cliente vaya a recibir como resultado del trabajo.
> Una identificación de los riesgos potenciales, especialmente si se trata
de un proyecto de investigación y desarrollo, o donde haya una
dependencia fuerte de factores externos que pueda comprometer el éxito
del resultado.
> Una síntesis final de, en el escenario descrito, cuáles de los requisitos
iniciales del Cliente se verán satisfechos, y cuáles no (también llamada
matriz de cumplimiento).
También puede ser conveniente describir cómo se da cumplimiento a los criterios de

valoración (si los hubiere) del Pliego del Cliente, para darle a entender que se han
comprendido, e intentado satisfacer, las necesidades y deseos del contratante.
3.2 Oferta de gestión
La oferta de gestión, una vez más, complementa a la oferta técnica describiendo la

organización, la metodología y los procedimientos que se seguirán para llevar a cabo
el proyecto, caso de que nos sea adjudicado. Es un error común que a esta parte de la
oferta se le dé menos importancia que a la oferta técnica, al entender que esta
información es un "complemento" al contenido técnico del trabajo. Y sin embargo son
numerosas las ofertas que, siendo técnicamente buenas, se descartan por no ofrecer
garantías razonables de la solvencia o capacidad del equipo de trabajo propuesto.
El contenido de la oferta de gestión varía enormemente de una oferta a otra, en

función de los requisitos del Pliego (si lo hay), del tipo de proyecto, y de nuestra
relación con el Cliente. Pero siempre debe incluir, en cualquier caso, la información
que sea necesaria para justificar la solvencia organizativa y de gestión de nuestra
propuesta, con vistas a desarrollar adecuadamente los trabajos objeto del contrato. En
general, contendrá:
^ Documentación específica para el proyecto:

> Descripción de los paquetes de trabajo, y responsable de cada uno de
ellos.
> Lista de resultados entregables del proyecto.
> Planificación temporal propuesta: diagramas Gantt y/o PERT.
> Plan de reuniones.
> Equipo de trabajo. Perfil profesional y/o curricula del personal con mayor
responsabilidad en el proyecto.
> Referencias de la empresa en proyectos similares.
^ Documentación complementaria:
> Procedimientos propuestos para la gestión: plan de gestión, plan de
calidad, plan de compras, plan de verificación y ensayos, etc.
Como complemento a la documentación de gestión, es frecuente que en contratos con

la Administración, o cuando el volumen o importancia del contrato así lo justifiquen,
el contratante solicite, además, documentación administrativa que determine y
garantice la capacidad del ofertante para presentar la propuesta. Esta documentación
puede incluir, entre otros:
> Datos para la identificación y validación del licitante, incluyendo

documentos probatorios de su identidad, certificados de inscripción en el
Registro Mercantil, escrituras de constitución, poderes notariales, etc.
CAPITULO 4: PREPARACIÓN DE LA OFERTA 143
> Certificación de no estar incurso en prohibiciones para contratar con la

Administración (o con el contratante de que se trate).
> Certificación de estar al día en el cumplimiento de las obligaciones
tributarias, o con la Seguridad Social.
> Justificación de la solvencia económica y financiera de la empresa.
> Justificación de la solvencia técnica o profesional del empresario y los
directivos.
> Fianzas o avales.
En cuanto a los criterios de valoración de las ofertas, por lo general la oferta de

gestión suele valorarse en términos de la solvencia técnica del equipo de trabajo
propuesto, la experiencia de la empresa en trabajos similares y el plazo de ejecución
de los trabajos, entre otros factores. Por el contrario, la documentación administrativa
suele ser condición para la admisión de la oferta, pero no puntúa sobre la valoración
final de fa misma.
3.3 Oferta económica
La oferta económica es a una oferta lo que una etiqueta de precio es al escaparate de

un comercio: el centro de atención. Muchas ofertas se desechan directamente, sin
llegar a mirar el documento técnico ni de gestión, porque el precio no se considera
adecuado.
La oferta económica es el compendio de todas las condiciones de venta del proyecto,

entre las que cabe citar:
 El precio de venta del proyecto básico.
 El precio de las mejoras adicionales al proyecto básico.
 La forma de pago, incluyendo:
 Distribución: el 100% del contrato al final, una parte al principio y otra al
final, según hitos temporales intermedios, etc.

 Medio: cheque, transferencia, etc.
 Financiación: al contado, a 90 días, etc.
 Validez de la oferta (puede ser válida indefinidamente o, lo más

normal, durante un período de tiempo limitado).
 Inclusión o no de determinados impuestos, entre ellos el IVA.

*" Precio al que se facturarán, si ha lugar, los recursos adicionales que el Cliente
pueda solicitar, como complemento a los necesarios para la realización del
proyecto.
^ Cualesquiera otras, de interés.
Finalmente, una cuestión importante para el éxito de la propuesta, pero a veces

(incomprensiblemente) ignorada: si el contrato conlleva un presupuesto máximo de
licitación (fijado en el Pliego del concurso, o comunicado formal o informalmente por
el contratante), dicho precio no debe ser superado, salvo que existan fundadas razones
que induzcan a pensar que nadie puede ofrecer los trabajos en cuestión por debajo del
precio fijado''''.
Si, tras la evaluación económica del proyecto, su coste efectivo es superior al precio
máximo de licitación, deben buscarse fórmulas alternativas para reducir el precio, tales
como:
> Emplear personal de inferior categoría (y coste económico).

> Limitar el alcance de los trabajos a realizar, a los mínimos
imprescindibles.
> Disminuir el número, las prestaciones o la calidad de los suministros.
> Subcontratar actividades a terceros que, al ser más eficientes, o al tener
costes horarios menores, puedan ejecutarlas a menor precio.
4. CURRICULA VITAE45 Y REFERENCIAS DE LA EMPRESA
Para convencer al Cliente de nuestra idoneidad para ejecutar el tr abajo, es conveniente

darle a conocer el perfil profesional de las personas que compondrán el equipo de
trabajo, así como las referencias de la empresa en proyectos de similar naturaleza.
Existen multitud de formas de preparar un curriculum vitae: para solicitar un puesto de

trabajo, para un concurso de méritos, para un tríptico de una conferencia o para ser
presentados en una reunión de socios de un club literario.
4
Existen excepciones. El autor tiene experiencia con un Cliente que, sistemáticamente,
solicita trabajo por debajo de su coste real, tal vez con la vana esperanza de forzar a los
licitadores a bajar su precio. Sistemáticamente, también, se le remiten ofertas con precios
superiores que, a menudo, acaba aceptando.
4
El plural del latinajo "curriculum vitae" es, según el diccionario, "curricula vitae". Sin
embargo, cuando se escribe sólo, también se admite el plural castellanizado "currículos".
Las normas generales dicen que el curriculum debe prepararse específicamente para la
aplicación concreta a la que vaya destinado, resaltando los aspectos relacionados con
dicha aplicación, y minimizando (o, simplemente, eliminando) los menos interesantes
a tal efecto.
Incluso a la hora de solicitar un puesto de trabajo hay quien prefiere enfocar el

curriculum para la empresa a quien se dirige: si es para un puesto de ingeniería
telemática resaltará sus cursos de programación y manejo de ordenadores, mientras
que si es para un departamento de marketing enfatizará sus cualidades como
comunicador (aparte, claro está, de sus conocimientos técnicos).
No es de extrañar, pues, que cada persona disponga de dos o tres modelos de

curriculum, listos para diferentes aplicaciones (hay quien, incluso, los personaliza
cada vez que hace uso de ellos). Además, cada curriculum podrá estar redactado en
varios idiomas, en función del destino del mismo.
Con los curricula de la empresa (las referencias) sucede otro tanto. Se seleccionarán
aquellas referencias anteriores y características de la empresa más significativas con
vistas al nuevo proyecto a contratar, existiendo, además, versiones de diferente
extensión (básicamente, una corta y una larga), y en distintos idiomas.
Aunque, como ya se ha dicho, "para gustos, los colores", en los siguientes apartados
se incluyen tres ejemplos tipo de curriculum redactados para ofertas: dos de un
integrante del equipo de trabajo (versión corta y versión larga), y una descriptiva de la
empresa que presenta la oferta.
4.1 Curriculum personal, versión larga
Aunque el estilo de presentación de los curricula puede ser muy variado, las empresas
suelen utilizar un formato normalizado para los CV del personal que propone para
realizar un trabajo concreto, donde lo importante es resaltar la adecuación del
individuo al mismo.
A diferencia de un curriculum personal (el que utilizamos, por ejemplo, para solicitar
un puesto de trabajo), en el corporativo no se indican datos de localización del
individuo (dirección ni número de teléfono personal), ni peculiaridades ajenas al
trabajo (tales como aficiones o carné de conducir, salvo que específicamente así se
requiera).
En cuanto a los datos del individuo, se reseñarán aquellos que describan

razonablemente su formación y experiencia: año de nacimiento (y nunca la edad, pues
se obligaría a actualizar todos los curricula de la empresa en los cumpleaños de sus
empleados), titulación, tiio de función que ejerce en la compañía, etc. Por supuesto, se
omitirán calificaciones académicas, cursillos (salvo los muy específicos, y

relacionados con el proyecto), idiomas no aplicables al proyecto o a la documentación
a manejar, estado civil o número de hijos, etc.
En lo que se refiere a las publicaciones, se describirán aquéllas de aplicación al

trabajo, y se reseñarán brevemente las demás.
Si bien no existe una norma estricta, es recomendable que el formato incluya, al

menos, los siguientes apartados:
> Datos personales.

> Perfil profesional.
> Experiencia laboral.
> Otros (publicaciones, patentes y méritos adicionales).
Tampoco existe una norma consensuada en cuanto a la longitud total, pero salvo
excepciones que lo justifiquen, a efectos de una oferta, el CV no debería tener una
extensión superior a una o dos páginas por persona, y sólo se incluirán los del personal
de cierta relevancia o responsabilidad en la estructura del equipo de trabajo.
A continuación se incluye, a título orientativo, un curriculum vitae ficticio para su

inclusión en un documento de oferta.
CURRICULUM VITAE
DATOS PERSONALES
NOMBRE : Armando Bronca Segura
FECHA NACIMIENTO : 1964
TITULACIÓN Doctor Ingeniero de Telecomunicación (UAL, 1993)

Ingeniero de Telecomunicación (UPM, 1988)
Diplomado en Gestión de Proyectos (UCtA, 1994)
PERFIL PROFESIONAL
Armando Bronca Segura es Director de Proyecto de la Sección de Ingeniería de Caos

Consulting, 5.A., donde presta sus servicios desde 1994. Con doce años de experiencia, tres
de ellos como profesor en la Universidad de Alpedrete, ha realizado labores de ingenier ía
de I+D, consultorio, ingeniería de sistemas y dirección de proyectos de ingeniería
telemática. En la actualidad, dirige un grupo de 12 personas, 8 de ellas titulados superiores
y medios.
EXPERIENCIA PROFESIONAL
1994 - Caos Consulting S.A., Sección de Ingeniería.

Funciones: dirección de proyectos, ingeniería de sistemas, consultorio.
Proyectos: redes de área local. Redes de telecomunicaciones RbSI, X.25, y
SDH. Interconexión de redes. Configuración de sistemas en red.
1991 - 1994 Universidad de Alpedrete, Departamento de Informática de Sistemas.

Funciones: Profesor Ayudante y Profesor Asociado, tiempo completo.
Asignaturas: Telemática, Redes de ordenadores.
1989 - 1990 Telepoiht, S.L.

Funciones: Becario para \a gestión de documentación de instalaciones de
puntos de acceso a redes de radio analógicas.
1989 - 1992 Colaborador habitual de la revista "LocoBit".
OTROS
> Autor del libro Transmisión de datos en redes híbridas, Edt. Paraguaya, 1997.
> Coautor del libro Aprenda Windows aunque sea un manazos, Edt. Chupete,
1996.
> Autor de más de diez publicaciones técnicas en temas de informática y
telemática.
> Titular de la patente "Mecanismo de inserción transparente de caracteres de
control en tramas SDH".
> Miembro del grupo de evaluadores del V Programa Marco para proyectos
telemáticos de alta tecnología de la Unión Europea.
> Miembro de número del IEEE y de la ACfA.
4.2 Curriculum personal, versión corta
La versión corta del curriculum suele utilizarse para describir brevemente a los
integrantes del equipo de trabajo propuesto, dentro de la parte de gestión del
documento de oferta. Es el mismo tipo de reseña bibliográfica que aparecería en un
tríptico de una conferencia o congreso, o en la contraportada de un libro.
Con una extensión de sólo unas pocas líneas, su contenido básico es el equivalente al
del perfil profesional de un curriculum largo, al que se añaden algunos datos
significativos adicionales, o algún aspecto o dato peculiar.
A modo de ejemplo, el CV resumido correspondiente al curriculum del apartado

anterior podría ser el siguiente:
Armando Bronca Segura es Doctor Ingeniero de Telecomunicación y

diplomado en Gestión de Proyectos. En la actualidad, ejerce de Director de
Proyecto de la Sección de Ingeniería de Caos Consulting, 5.A., donde
presta sus servicios desde 1994. Con doce anos de experiencia, tres de
ellos como profesor en la Universidad de Alpedrete, ha realizado labores
de ingeniería de 1+0, consultorio, ingeniería de sistemas y dirección de
proyectos de ingeniería telemática. Dirige un grupo de 12 personas, 8 de
ellas titulados superiores y medios. Es autor y co-autor de dos libros,
diferentes artículos técnicos y una patente. Fue miembro del comité
evaluador del V Programa Marco de la Unión Europea.
4.3 Presentación y referencias de la empresa
La presentación de la empresa es a la propia empresa lo que el curriculum es al

individuo. Su finalidad es lograr que, de un vistazo, el lector sea capaz de evaluar el
tipo de empresa, la actividad a la que se dedica y sus características más
fundamentales, tales como tamaño, facturación, organización interna, experiencia en el
sector, clientes para los que ha trabajado y proyectos realizados.
Este tipo de información se conoce como "resumen corporativo". Este resumen, que es
de carácter público, no debe contener información confidencial (potenciales clientes o
perspectivas) que puedan ser de utilidad para la competencia.
A continuación se incluye un ejemplo de resumen corporativo de la empresa modelo

Caos Consulting, S.A., válido para su integración en la oferta de gestión de un
proyecto:
RESUMEN CORPORATIVO
Caos Consulting, S.A., es una empresa dedicada a servicios de ingeniería básica y

consultorio en temas de telecomunicaciones e informática. Su domicilio social, situado en el
término municipal de Colmenar Viejo, a escasos 35 kilómetros de Madrid, dispone de más
de 3.000 metros cuadrados destinados a oficinas, centros de diseño, talleres, laboratorios,
almacén de equipos y sala blanca.
Caos Consulting cuenta con una plantilla de 58 personas, 32 de las cuales son doctores o
titulados superiores, y 16 técnicos de grado medio. La experiencia profesional media del
personal cualificado es de 9 años. La estructura corporativa de la empresa se muestra en la
siguiente figura:
durante el pasado ejercicio fiscal, la empresa facturó más de 12,5 millones de euros en
proyectos de ingeniería, abarcando desde actividades de consultorio y soporte técnico
hasta proyectos de detalle y llave en mano. Las áreas principales de actividad abarcan:
> Ingeniería telemática.

> Proyectos informáticos.
> Desarrollo de software.
> Hardware de comunicaciones (incluyendo microelectronica).
> Especificación, adquisición, integración y validación de equipos.
Los objetivos prioritarios de la empresa son la optimización de las relaciones precio/calidad

y coste/eficiencia, para lo cual cuenta con la certificación ISO-9001. Caos es contratista
principal del Ministerio de Fomento. A continuación se detallan algunos de los proyectos
más relevantes realizados en el pasado:
EXPERIENCIA CORPORATIVA
Proyecto : Plan de informatización de Cliente : MINISTERIO DE

obras FOMENTO
Comienzo : Feb-1995 Final : Ene-1996
Descripción = Informatización de la base de datos de proyectos contratados por el
Ministerio. Especificación, diseño, creación e implantación de la red de
ordenadores y h Base de Datos de gestión de proyectos.
Proyecto : MON6ONET Cliente : Agencia Espacial Euroasiática

(ESA)
Comienzo : Nov-1996 Final : Mar-1999
Descripción ; Implantación de una red de comunicaciones SDH para difusión de datos de
telemetría de satélite entre Siberia y Mongolia.
Proyecto ; Abono-Bus Cliente : Ayuntamiento de Parrandilla

la Viera (Lugo)
Comienzo : Jun-1998 Final : Dic-2000
Descripción : Diseño e implantación de un sistema de monedero electrónico y abono
transportes para la red de autobuses de Parrandilla la Viera.
Proyecto : Red de área local de Flores Cliente : Flores del Sur (Sevilla)
del Sur
Comienzo : Ene-2005 Final : May-2005
Descripción : Implantación de una red de área local con equipamiento
hardware/software para la gestión integrada de pedidos, envíos y stocks.
Proyecto ¡ 05-NET (Operational Cliente : Unión Europea (Programa

Synchonous NETwork) ESPRINT)
Comienzo : Ene-2001 Final : En curso
Descripción : Diseño detallado de los centros de conmutación de datos multimedia para
redes corporativas de banda ancha.
5. PRESENTACIÓN (Y SEGUIMIENTO) DE LA OFERTA
Concluido el documento de oferta técnica, de gestión y económica, llega el momento

de presentársela al Cliente. Son muchas las ofertas que, tras todo el esfuerzo realizado,
hacen fracasar la obtención del contrato. Las razones pueden ser muy diversas, pero
las más comunes son:
La oferta no se termina a tiempo. La noche anterior a la fecha límite de

entrega el responsable de la oferta y su equipo de trabajo se empeñan en
finalizar un trabajo que, generalmente a causa de la mala planificación, ha
agotado el plazo disponible y aún no está terminado. Los nervios se disparan.
Comienzan a aflorar "pequeños detalles" que aún faltan por concluir. No da

tiempo a hacer las copias necesarias, ni hay quien las encuaderne. Al final, la
oferta no se entrega, o se entrega carente de la calidad y nivel de terminación
que, de haber planificado correctamente el trabajo, podría haber tenido.
Falta "elpapel". Los directores de oferta y equipo de trabajo están a menudo

muy vinculados al trabajo técnico, y no es infrecuente que presten menos
atención a la documentación administrativa. Es muy habitual que muchas
propuestas queden descalificadas por la falta de un trámite, generalmente
administrativo, que puede ir desde una relación del personal clave de la
empresa, hasta un aval bancario o un certificado del Impuesto de Actividades
Económicas. Conseguir esos papeles requiere, a veces, algunos (no muchos)
días. Aunque a última hora se detecte la falta de ese trámite, a veces ya no da
tiempo, simplemente, a conseguirlo.
Los costes no encajan. La información necesaria para realizar y finalizar la

oferta suele aparecer, de golpe, al final de período disponible para la misma.
Proveedores que se toman su tiempo para dar precios de los equipos o
elementos a suministrar, consultores externos que proporcionan su
contribución a la oferta a última hora, o también consideraciones sobre el
alcance que surgen en el último momento, al revisar paquetes de trabajo y
costes, pueden hacer que, en el último momento, los costes "no cuadren" con
el precio de venta fijado. En ese momento, el equipo de oferta puede optar por
tratar de disminuir esos costes o, simplemente, renunciar a presentar la
propuesta (también pueden presentarla de todos modos, aun a riesgo de ser
directamente descalificados, pero esto no suele sentar bien al Cliente).
La oferta no cumple. También hay muchas ofertas que, durante una lectura
cuidadosa por parte del Cliente, son directamente descalificadas. La oferta
presentada, buena y correcta en su conjunto, ha olvidado algún punto
específico del pliego del concurso, o ha omitido algún compromiso clave para
obtener el contrato. Estas omisiones pueden ser voluntarias (para reducir
costes que de otra manera no encajarían en el presupuesto), o involuntaria,
fruto de las prisas de última hora, que impiden una cuidadosa relectura del
Pliego y de la propuesta, para verificar que es 100% consistente con los
requisitos del Cliente.
El "soplo" de última hora. También es habitual que, cuando ya todo está

preparado, encuadernado y listo para entregar, llegue una orden directa de
arriba para que la oferta no se entregue. La Dirección de la empresa puede
haber recibido información acerca de la insolvencia financiera del Cliente, de
las escasas posibilidades de obtener el contrato, de la necesidad de utilizar los
recursos para otros proyectos comprometidos, o mil otras razones de peso para
abortar el proceso de oferta. También es típico que el Cliente "recomiende",
tal vez a última hora, que dos o más competidores se pongan de acuerdo entre
sí y presenten una oferta conjunta.
í 52 DIRECCIÓN Y GESTIÓN DE PROYECTOS
Aunque la propuesta se entregue correctamente finalizada y a tiempo, sigue sin

terminar el trabajo del Director o responsable de la oferta, y el de su equipo de trabajo,
pues comienza la fase de seguimiento de la oferta.
En esta fase, dependiendo del volumen y tipo de contrato, de la relación particular con
el Cliente, y del nivel de competencia, puede ser conveniente o necesario mantenerse
en contacto con el Cliente, y ponerse a su disposición para presentar, comentar o
completar aspectos puntuales de la documentación entregada.
Si es posible, suele ser muy conveniente organizar una reunión de presentación para
describir, en persona, el contenido de la oferta. Una buenas transparencias en color, y
una sesión abierta y amigable, resultará mucho más atractiva para el Cliente que
leerse, "en frío", las muchas hojas de papel del documento de oferta, y le puede
predisponer a prestar más atención a nuestro trabajo. Lamentablemente, en muchas
ocasiones el propio Cliente rechaza esta opción, bien porque haya muchos ofertantes,
bien porque prefiera un análisis más personal de la documentación presentada.
Pero otras veces es el propio Cliente el que demanda una reunión (o varias) de este
tipo. En estas reuniones, si la iniciativa parte del Cliente, no suele ser extraño que,
aparte de que se le presente la oferta y el equipo de trabajo, pretenda negociar otros
aspectos, tales como:
> Cambios o ampliaciones al alcance.

> Cambios en la organización propuesta para el trabajo.
> Reducciones de precio, o formas alternativas de pago.
> Borrador del futuro contrato.
La imagen transmitida por el potencial adjudicatario durante este tipo de reuniones, ya

sean convocadas por él mismo o a instancias del Cliente, es a menudo determinante
para las posibilidades de obtener el contrato. Si el Cliente percibe un equipo de trabajo
solvente, competente y amigable, tenderá a pensar que dicha "imagen" puede
mantenerse durante todo el proyecto. Sin embargo, si la imagen transmitida es
inadecuada (escasos conocimientos, mala organización, trato tenso, etc.), rara vez va a
arriesgarse a dejar "su proyecto" en manos de gentes que, desde el principio, le
inspiran poca confianza o poca simpatía.
También es conveniente, si es posible, hablar de vez en cuando con el Cliente para

interesarse por la evaluación de las ofertas, y sobre cuándo se estima se tome la
decisión sobre la empresa adjudicataria. Esta necesidad responde no sólo al interés por
conocer nuestras posibilidades de ganar el contrato, sino también de la conveniencia
de disponer de información real sobre nuestras posibilidades, que es muy útil a la hora
dé planificar el uso de nuestros recursos e, incluso, preparar otras ofertas.
6. ADJUDICACIÓN (O NO) DEL TRABAJO
Y llegó el gran día. O, según como se mire, la fecha nefasta. El Cliente da a conocer
su decisión sobre quién será el encargado de realizar el proyecto. Salvo que nuestra
oferta estuviera basada en hipótesis técnicas o económicas desafortunadas, lo más
lógico es que estemos esperando ansiosamente ser los elegidos.
Pero es muy probable que no haya sido así, y que nuestra oferta no haya sido la
elegida. Tras los minutos iniciales de decepción e insatisfacción, llega el momento de
aprovechar al máximo posible el trabajo realizado, sobre todo extrayendo las
experiencias útiles obtenidas durante la preparación de la oferta y el seguimiento del
expediente. Será conveniente, pues, tratar de responder a, al menos, las siguientes
cuestiones:
¿Por qué no nos ha sido adjudicado el contrato?, ¿qué podríamos haber hecho
para mejorar nuestra posición? En concreto:
> ¿Era nuestra oferta consistente con los requisitos del Pliego?
> ¿Ofertamos a un precio muy por encima o muy por debajo de la
competencia?
> ¿Nuestra solución técnica era adecuada?
> ¿El equipo de trabajo propuesto reunía las condiciones necesarias para
dicho trabajo?
> ¿Hemos atendido correctamente al Cliente, y escuchado y tenido en
cuenta sus sugerencias?
> ¿Es nuestra empresa la adecuada para ejecutar este tipo de contrato?
¿Cómo se puede reaprovechar el trabajo realizado durante la preparación de

la propuesta?
> ¿Puede presentarse esta propuesta, modificada convenientemente, a otros
Clientes o a otros concursos?
> ¿Del trabajo realizado, se puede capitalizar algún conocimiento o alguna
información obtenida? (sin violar, claro está, acuerdos de
confidencialidad ni propiedad intelectual o industrial alguna).
> ¿Se puede utilizar ante el Cliente el hecho de haber presentado la
propuesta y no haber obtenido el contrato, como un mérito para mejorar
la posición competitiva en fiituras licitaciones?
¿Qué conclusiones se pueden obtener del resultado de la adjudicación?

> ¿Hay que estructurar de manera distinta algún recurso de nuestra
empresa?
> ¿Hace falta revisar nuestra estructura de costes?
> ¿Hay que modificar nuestra política de atención al Cliente?
> ¿Hace falta contratar a algún tipo de profesional del que ahora no
dispongamos?
> ¿Es necesario adquirir o desarrollar nuevos conocimientos o tecnologías,
en alguna de las áreas afectadas?
¿Quedan, tras la adjudicación, tareas pendientes?

> ¿Hay que recuperar fianzas o avales depositados para la presentación al
concurso?
> ¿Se ha transmitido adecuadamente la información sobre la propuesta, así
como las conclusiones sobre el proceso, a nuestros superiores, equipo de
trabajo y proveedores involucrados?
> ¿Hay que abonar o cobrar facturas correspondientes al esfuerzo realizado
o subcontratado para la propuesta?
> ¿Nos comprometimos con alguien a realizar algún tipo de actividad tras
la presentación de la propuesta (tales como mantener conversaciones o
negociaciones futuras)?
LECTURA. ESTILO DE COMUNICACIÓN
A lo largo de la vida cotidiana nos vamos dando cuenta de que lo importante no

es sólo et contenido (el chocolate), sino también el continente (el envoltorio).
Importa el envasado casi tanto amo la calidad del producto, el aspecto para
prejuzgar al individuo y el celofán tanto o más que las flores que recubre.
Lamentablemente, en el ámbito profesional y en la vorágine de la apresurada

actividad cotidiana, a menudo se pierde de viste este planteamiento, y nos
centramos mucho más en los aspectos técnicos del problema que en el estilo de
comunicación empleatfo
Y muchos jamás llegan a comprender cuánto se valora "desde fuera" la presentación,

incluyendo limpieza, orden, claridad, estilo y ortografía.
CAPITULO 4: PREPARACIÓN DK LA OFERTA 155
Aunque en un proyecto técnico el objetivo primordial es la excelencia técnica

con los recursos disponibles, no debe olvidarse que ello no es incompatible con
un estilo de comunicación claro, pfeciso, ordenado y, si es menester, atractivo
para el Cliente y otros potenciales destinatarios..
Al igual que un profesor valora ^presentación a la hora de corregir un examen

o una práctica, el Cliente valora subjetivamente el aspecto y la presentación un
documento de proyecto. Este aspecto genera}, si es positivo, reforzará
impresión de solidez técnica e, incluso en raras ocasiones, ayudará a disknulí
las "lagunas" del documento presentado.,
Cada empresa y cada persona tiene su propio estilo de comunicación (y

digamos su concepto de estética). Todos son válidas y aceptables (en tanto y
cuanto se ajusten al buen gusto general), pero es necesario observar una serie
reglas y preceptos que confieren _a la documentación (ÍHefuyer
comunicaciones internas y faxes, presentaciones o documentos propiamení
dichos) un aspecto serio, disciplinado y profesional, de entre las cuales cabt
citar, al menos, las siguientes
Evitar tutear al Cliente, aunque se mantenga una relación distendida con

en especial en documentos formales.
Evitar el uso de términos familiares, jergas, vulgarismos y modismos.
■ Evitar la primera persona, tanto en singular (he realizado, ofrezco) como
plural (hemos realizado, ofrecemos), en favor de construcciones
impersonales del tipo (se ha realizado, se ofrece). Cuando resulte necesarit
hacer explícito el sujeto de la acción se recurrirá a construcciones del tij
"se ha realizado, dentro del ámbito del proyecto", o "el equipo de trabajo
realizado".
Evitar, donde exista un equivalente en castellano, el uso de anglicismos
en general, extranjerismos (por ejemplo, utilizar ^draff* en lugar
"borrador", "portable" en vez de "portátil", "featuré" por "característica'
"momé" por "ratón", etc.).
Evitar la autopublicídad evidente y descarada, en especial si se acompat
de juicios de valor que descalifiquen a la competencia.
Evitar imbuir emociónalidad en el documento, procurando lograr el may
nivel de "asepsia emotiva" posible.
Tratar correctamente al Cliente (o lector), sin evidenciar la diferencia
conocimiento sobre el asunto qne, eventualíñente, pudiera haber4h.
Redactar los documentos de manera clara, sintética y ordenada, evitando un
lenguaje ampuloso o excesivamente técnico, pero sin disminuir el rigor o la
complejidad necesarios.
17
Por supuesto, hay cabida para todo tipo de opiniones, pudiendo alguna de ellas resultar
discutible. Valga aquello de que "cada maestrillo...".
48
No olvidemos que, en definitiva, el Cliente, quien nos da de comer, no tiene por qué conocer
técnicamente el tema en el que estamos trabajando. En caso contrario, ¿por qué habría de
querer contratarnos?
156 DI RECCIÓN Y GESTIÓN DE PROYECTOS © RA-MA
■ Procurar utilizar un lenguaje ameno > agradable de leer (siempre sin caer en
, as íannliandadeso deslices humorísticos). .
■ Escribir lo justo y necesario, evitando el texto de relleno, innecesario y
molesto para el lector. -
■ Incluir cuantas explicaciones, tablas.. índices,, pies de página, gráficos o
imágenes pudieran. Ser útiles para la comprensión del documento.
Ert cuanto a las presentaciones, na hay que olvidar que sirven para un propósito
concreto, que generalmente es:~
■ "Convencer" al interlocutor de algo -(nuestro punto de vista o la adecuación

dt nuestro producto o senecios a sus necesidades).
■ Resumir brevemente Jos objetivos alcanzados, el contenido de un
documento o el balance de una acción, a menudo a personas poco técnicas o
con conocimientos limitados acerca del contenido específico.
En ambos casos es oprtvemeíite adoptar una serte de medidas que faciliten el

cumpfimiento de- los objetivos de fa presentación, esto es, que el auditorio
permanezca atenta y asimile" (y, deseablemente, comparta), nuestro punto de .>
la información preáentada. Para e\t&, es Conveniente:
izar el auditorio antes de preparar la presentación. ¿Cuánta gente

abrá?,, ¿qué tipo de formación tiene?, ¿cuánto tiempo podrán dedicar a la
presentación?, ¿qué tipo de información les interesa en particular? No es lo
mismo presentar un producto concreto a un grupo dé ingenieros que a un
grupo de potencíales compradores, (sin formación, técnica), ni los resultados
técnicos del proyecto ai Cliente, en un ríar de horas, que a nuestro Jefe, en
diez minutos. .
Identificar la información importante, que nuestro auditorio está dispuesto a
escuchar, y descartar tos detalíes irrelevantes que sólo servirán para aburrir.
Resaltar'lO6\aapéct0s positivos, y,"pisar de puntillas'1 por los negativos,
aunque sin obviar su importancia (pues sólo sirve para restar credibilidad).
Confeccionar un guión de/los plintos a tratar, que tenga en cuenta el tiempo
disponible para cada uno de ellos 5así como las posibles preguntas (y las
respuestas adecuadas) o comentarios a los que puedan dar lugar. A la hora de
preparar la presentación, dedicar una transparencia, ai menos, a cada tema o
punto a tratar, intercalando índices para guiar al auditorio a través del
avance de ía presentación (los oyentes deben tener una idea clara de qué
temas se, van a tratar, cuántos quedan pendientes y,
aproximadamente, cuánto tiempo resta <|e presentación)! Evito aglomerar ideas
en una misma transparencia. Diseñar transparencias "ligeras", con pocos
puntos, o ideas, apoyadas, cuando sea factible, con gráficos e imágenes.
Dedicar a cada transparencia, y salvo excepciones, no menos de medio
Inmuto (para evitar "marear" al auditorio con el cambio continuo de
transparencia}^ no másHe tres o cuatro minutos (para evitar que, tras
■ Utilizar la tecnología al alcance del auditorio para atraer su atención. Mejor

transparencias impresas que; a mano, mejor en color que en blanca y negra,
mejor con gráficos e imágenes que sin ellos y mejor con movimiento y
sonido que sin él49.
■ Sin embargo, ten peligroso es el exceso comedí defecto. Hay que evitar
utilizar combinaciones de colores excesivamente chillonas, efectos visuales
agresivos -y, en definitiva, todo aquello que pudiera restar importancia al
mensaje que se quiere ' fransúiitir.. \, , .-; ..;; • '- •
■ Tratar de despertare! interés del auditorio desde el principio, presentando el
tema deforma amena y cuidadosa. Despertar el interesal final, sintetizando
las conclusiones, así como cuando algún punto a tratar sea suficientemente
importante. Para,despertar el interés existen múítiplesiécnídas, tales cojrio
¡nbiat el tono de voz, insertar una anécdota o un comentario distendido;
una transparencia visualmente atractiva 5<?, "dirigir una,precinta al auditorio*
Comenzar: la presentación pon un breve resumen del contenido de la misma,

í como una idea aproximada de la duración. Si el auditorio es reducido, es
posible intercalar preguntas y comentarios durante la presentación, pero si
es muy amplio o el tema "muy complejo, quizás sea preferible-anunciar que
las preguntas se responderán al final.
■ Adaptarse dinámicamente a la evolución de la presentación. Si el auditorio
se muestra impaciente,; acelerar el ritmo de la- presentación. SÍ se (nuestra
desorientado, abundar en explicaciones sobre los conceptos; básicos y.
generales. Sí demuestra interés, abundar en los detalles,
■ Si el auditorio es heterogéneo, adaptarse a la media del mismo, enfatizando
los puntos principales para los .oyentes más avanzados (que, a continuación,
probablemente se "desconectarán"), y permitiendo que los más rezagados
hagan,preguntas cuando comiencen á perder el hilo de la presentación.
tilizar un formato de presentación claro, atractivo, pero sin que sea
excesivamente recargado ni con combinaciones de colores agresivas.
Identificar claramente la sección de la presentación a la que pertenece la
transparencia, el título y subtituló dé la misma, el número de transparencia y
(caso lie ser factible) el número total de transparencias. A=sí el auditorio
sabrá encada momento en qué punto de la presentación está,, y. cuánto
queda para el final de la misma.
49
Al final, al ritmo que vamos y con los avances de los programas de presentación, será difícil
distinguir entre una presentación convencional y un vídeo tipo documental. Los programas de
presentación ya permiten incluir clips de vídeo con su banda sonora asociada. En breve, será
hasta prescindible nuestra intervención, salvo para responder a las preguntas que puedan surgir.
i0
Últimamente, y cuando la ocasión lo permite, intercalo una foto de mi perro Trasto entre dos
transparencias. El efecto es inmediato y, en general, nadie se siente agredido. La calificación
estética de este método queda ajuicio de los lectores.
CAPITULO 5
SEGUIMIENTO DEL PROYECTO
1. INTRODUCCIÓN
Este capítulo trata específicamente de la gestión del proyecto, una vez que pasa a
formar parte, ya, del trabajo asignado a la empresa, y hasta su finalización.
Para algunos responsables de proyecto, éste será el primer contacto que tengan con el
nuevo trabajo, si el departamento comercial de su organización asumió, por completo,
las tareas de detección de oportunidades y presentación de la oferta. Para otros, sin
embargo, sólo será la continuación, ahora "cobrando" por ello al Cliente, del esfuerzo
realizado y mantenido durante las fases de evaluación, preparación de la oferta y
seguimiento del expediente.
2. ANTES DE EMPEZAR A TRABAJAR
No es extraño que entre la presentación de una oferta y el comienzo de los trabajos

medien días, semanas o, incluso, meses. Aunque normalmente durante ese tiempo (sea
breve o extenso) es habitual que el Director de la Oferta permanezca en contacto con
el potencial Cliente, a menudo se producen cambios en la organización de la empresa,
en la organización del Cliente, o incluso cambios en el entorno que obligan a revisar el
alcance comprometido en la propuesta original.
Llegado el momento de comenzar los trabajos, es la oportunidad ideal para revisar la

oferta inicial y los posibles cambios o alteraciones a la misma. Entre las razones para
revisar el alcance y contenido de la propuesta, cabe citar:
:S=
Que alguna de las personas previstas para el equipo de trabajo haya
abandonado la empresa, haya asumido competencias distintas, o haya sido
asignada a otros proyectos que impidan su participación en el que está a punto
de comenzar.
*" Que se haya incorporado nuevo personal a la empresa, susceptible de

participar en el proyecto.
*" Que con posterioridad a la presentación de la propuesta se haya negociado,

directamente con el Cliente, alguna modificación al alcance o al precio que
suponga una alteración a los costes del proyecto.
tr
Que, desde la presentación de la propuesta, la empresa haya adquirido (o
prescindido de) nuevas tecnologías o recursos que modifiquen el coste del
proyecto.
Pero, aparte de la modificación de las condiciones bajo las que se ofertó, lo más
habitual es tener que revisar, ahora bajo la perspectiva de un trabajo que sí hay que
realizar, la oferta presentada. No hay que olvidar que muchas propuestas se preparan
en cortos períodos de tiempo, bajo cierta presión, y compaginándolas con la ejecución
de otros proyectos, por lo que no es del todo imposible que en la oferta se haya colado
algún "gazapo"57, en forma de compromiso (técnico, económico o de planificación)
excesivamente voluntarista. Ésta es la última oportunidad para detectar y corregir esos
deslices que, una vez que comience el trabajo, formarán parte del mismo.
2.1 Revisión de la oferta y del contrato
Así pues, la primera actividad del responsable del proyecto, una vez le sea notificada
la adjudicación del contrato, es recopilar toda la información de la propuesta y el
borrador de contrato, y proceder a un minucioso análisis de los mismos con el fin de:
*" Detectar fallos o inconsistencias en el documento de oferta que puedan afectar

significativamente al coste o al precio del proyecto.
*" Verificar que el contrato a firmar responde a los compromisos adquiridos en el

documento de oferta y que no existen elementos nuevos que puedan alterar
dichos compromisos.
51
Gazapo es, según el Diccionario de la Lengua Española, el "yerro que, por inadvertencia deja
escapar el que escribe o el que habla".
CAPITULO 5: SEGUIMIENTO DEL PROYECTO 161
Asegurar que la organización mantiene y dispone de los recursos necesarios

para realizar los trabajos en las condiciones comprometidas en la oferta (y el
contrato).
2.2 Organización y acopio de recursos
El siguiente paso es hacer el acopio de los recursos necesarios para el proyecto, y que
en su momento se comprometieron en el documento de oferta. Entre dichos recursos,
cabe mencionar:
 Los recursos humanos (personas), en número y cualifícación (categoría

profesional, formación o experiencia) precisos para ejecutar el proyecto.
 Los recursos materiales, correspondientes a las instalaciones, utillajes,

herramientas y otros elementos necesarios para la realización de los trabajos.
^ Los recursos financieros requeridos para hacer frente al proyecto, incluyendo

no sólo los destinados a sufragar los costes internos (personal e instalaciones),
sino los derivados del propio trabajo, tales como la adquisición de suministros,
la realización de viajes, avales y garantías, etc.
En general, asumiendo la solvencia económica de la empresa, el problema más

habitual es la disponibilidad de las personas necesarias para la realización del
proyecto, y que en su momento se incluyeron dentro del personal clave para la
ejecución del mismo. Bien porque hayan surgido, entre medias, nuevos proyectos,
bien porque hayan abandonado la empresa, o porque hayan sido reasignados a otras
labores o actividades, suele ser habitual que ciertas personas, simplemente, ya no estén
disponibles, o no lo estén en el período de ejecución del proyecto. En tal caso, el
responsable del mismo tiene que sustituir dicho personal "descolgado" con otras
personas capaces de realizar adecuadamente el trabajo. Y esto muchas veces no es
fácil, sobre todo en el caso de empresas de reducido tamaño, o de trabajos que
impliquen un cierto grado de especializacíón.
Algo parecido suele ocurrir con ciertas instalaciones o herramientas específicas.

Imaginemos una empresa constructora que dispone de dos grúas de obra, que en los
últimos meses ha presentado varias ofertas para el alzamiento de edificaciones. Y
supongamos también que dicha empresa ha resultado adjudicataria de cuatro contratos
] 62 DIRECCIÓN Y OKSTION DE PROYECTOS
distintos. Como la empresa sólo dispone de dos grúas, tiene que tomar alguna de las
medidas siguientes:
•" Rechazar dos de los contratos, por falta de recursos propios (por razones
evidentes, rara vez la empresa optará por esta solución).
tr
Retrasar en el tiempo dos de los proyectos contratados (con la connivencia del
Cliente) para que la necesidad de la grúa en cada uno de los cuatro proyectos
no sea coincidente en el tiempo (sin embargo, rara vez el Cliente aceptará una
demora importante por razones de este tipo).
^ Modificar la planificación de los proyectos para que, estando en marcha todos

a la vez, se puedan compartir las dos grúas entre los cuatro proyectos (esta
solución, sin duda la óptima, no siempre es técnicamente posible. En el
ejemplo, puede esgrimirse en contra, tal vez, el alto coste del traslado de las
grúas, o la necesidad de disponer de ellas durante toda la duración de cada
obra).
■*" Conseguir grúas adicionales, mediante compra, alquiler, etc., y satisfacer, así,
las necesidades de los cuatro proyectos (esta opción, sin duda elegante y muy
razonable, debe contrastarse con la viabilidad real de conseguir las dos grúas
adicionales a tiempo para los proyectos, así como con el sobrecoste asociado a
la consecución de las mismas, y su consiguiente repercusión sobre el margen
de los proyectos).
2.3 Intercambio de información en el proyecto
Tan importante como los documentos formales de gestión del proyecto son las
comunicaciones formales o informales entre los integrantes del equipo de trabajo,
entre ellos, o con terceros (incluyendo al Cliente).
Dichas comunicaciones definen en general la marcha y avance del proyecto, y suelen

suponer compromisos menores a respetar posteriormente. Aunque se realicen de
manera informal (por teléfono, correo electrónico, etc.), es conveniente que toda
decisión de relevancia o de interés quede plasmada por escrito, y (si es menester)
firmada.
La información transmitida dentro del ámbito de un proyecto, sea de alcance interno o

externo al equipo de trabajo, tiene lugar en forma de mensajes. Un mensaje es un
conjunto de símbolos, señales o signos que constituyen el objeto de la comunicación.
Según el alcance del mensaje, cabe distinguir entre:
lS=
Mensajes de ámbito externo: circulan entre personas de la organización y
personas ajenas a la misma.
*" Ámbito interno: exclusivamente reducido a los integrantes del equipo de

trabajo o, incluso, a los integrantes del equipo de trabajo de la organización.
Esta restricción a la difusión se debe, por lo general, a dos posibles razones:
> Interés: la información transmitida es de utilidad sólo para las personas
que forman parte del universo de distribución, y no aportan nada útil a
personas ajenas a dicho ámbito.
> Confidencialidad: la información transmitida contiene datos sensibles,
desde el punto de vista comercial, y no conviene que sea puesta a
disposición de personas ajenas al equipo de trabajo.
Según el medio de transmisión utilizado para la difusión del mensaje cabe citar, entre
otros:
*" Correo (carta o mensajería).
** Fax (transmisión facsímil).
*" Correo electrónico (e-mail).
■=»" Comunicación interna.

cS=
Otros (voz, telefonía, etc.).
Por supuesto, cada medio de transmisión goza de sus ventajas e inconvenientes, tales
como la rapidez, el coste, la posibilidad de verificar la recepción, la posibilidad de
verificar la autenticidad del remitente o del contenido, etc., por lo que todos los
medios reseñados (y muchos más) se utilizan habitualmente, en diferentes ámbitos y
aplicaciones, en función de las necesidades concretas.
Dos de los medios de transmisión de información clásicos en comunicación dentro de

un proyecto son el fax y la comunicación interna.
El fax (transmisión facsímil), que siempre debe ir firmado, permite notificar cualquier
información, evento o hecho por escrito a cualquier integrante del equipo de trabajo,
con carácter formal, y suele adjuntarse a la documentación de gestión del proyecto. En
él debe consignarse, además de la información contenida, la referencia del proyecto,
del fax, la fecha, el remitente y la lista completa de destinatarios, el asunto y el número
total de páginas de que consta la transmisión.
Existen ciertas dudas acerca de la validez legal de una firma transmitida por fax,
aunque en la práctica se asume la equivalencia legal con el correo ordinario. Es
conveniente archivar todos los faxes enviados y recibidos, junto con la hoja de
confirmación de transmisión (en el caso de los enviados). La lectura "Aspectos legales
y valor contractual de la documentación del proyecto", al final del capítulo, incide
sobre esta cuestión.
La comunicación interna es el equivalente al fax, pero con un ámbito (interno)

limitado al equipo de trabajo (y tal vez a los superiores de la empresa). No se transmite
por medios electrónicos, sino directamente en papel (el correo electrónico y otras
tecnologías recientes están alterando esta premisa). Su principal valor es el de dejar
constancia escrita de la evolución de las relaciones y acuerdos tomados en el seno del
equipo de trabajo.
Si los hechos comunicados son de trascendental importancia o interés, es conveniente

enviar copia del fax o comunicación interna al responsable inmediatamente superior,
con el fin de utilizarlo como autoridad certificadora de la comunicación.
Las figuras 5.1 y 5.2 muestran, respectivamente, formatos de fax y de comunicación

interna.
CAPITULO 5: SEGUIMIENTO DHL PROYECTO 167
3. REUNIONES
En cualquier proyecto de cualquier empresa:
las reuniones son una parte fundamental del trabajo cotidiano, y de referencia
prioritario para el flujo e intercambio formal de información.
En una reunión bien organizada se exponen en común los problemas y dificultades del
proyecto, y se articulan las soluciones apropiadas, según el sentir común de los
presentes. Se negocian los aspectos que suponen un compromiso entre grupos de
trabajo (sean o no de la misma empresa), y se refuerzan los objetivos comunes a lograr
por todos los participantes en el proyecto.
Y, sin embargo, las reuniones están generalmente desprestigiadas. Se consideran

males necesarios, donde para decidir y concretar cuatro ideas se pierden horas y horas
en divagaciones, en exposiciones personales de logros que a pocos interesan, y en
discusiones inútiles cuya única consecuencia es reforzar las posiciones particulares de
cada cual.
El responsable del proyecto tiene la obligación de organizar adecuadamente las

reuniones de trabajo, para conseguir los objetivos de la misma (intercambio de
información, resolución conjunta de las dificultades y refuerzo del objetivo común)
evitando la pérdida de tiempo y la sensación de ineficacia.
La reunión de comienzo es normalmente la primera que se organiza tras la

adjudicación del contrato, y no es una excepción al planteamiento anterior. Además,
probablemente sea la primera reunión conjunta para algunos de los integrantes del
equipo de trabajo, cliente y subcontratistas, por lo que merece la pena prepararla
adecuadamente. Aunque parezca increíble, del mayor o menor éxito (o fracaso) de la
reunión de comienzo (y de la imagen que del responsable se hagan el resto de
partícipes) puede depender el curso de las relaciones durante el resto del proyecto.
Esta primera reunión suele dividirse, si el volumen o complejidad del proyecto lo

justifica, en tres:
> Una primera reunión interna, del Director del proyecto con el equipo de
trabajo. En ella:
> Se hace partícipe al equipo de trabajo de los objetivos del proyecto.
> Se presenta un calendario de fechas e hitos, y se repasa la planificación
inicialmente propuesta.
> Se asignan responsabilidades.
> Se recopilan comentarios o propuestas para mejorar la organización del

proyecto.
> Se prepara la reunión con el Cliente.
En la reunión con el Cliente se tratan todos los aspectos, contractuales,
técnicos y operativos, que se estimen de interés, se revisa el alcance y
objetivos iniciales, se recopilan comentarios o propuestas y se aceptan o
rechazan modificaciones al contenido, plazo o precio de los trabajos.
Finalmente, y si es necesario, puede mantenerse otra reunión interna (más

breve esta vez) con el equipo de trabajo para introducir los posibles cambios
acordados en la reunión con el Cliente.
3.1 Convocatoria de reunión
En buena práctica, toda reunión debe ser convocada por el responsable del proyecto.
Convocar una reunión supone establecer una agenda, donde se indique la fecha, hora
y lugar de celebración, la duración prevista, así como la lista de los agentes
potencialmente interesados en participar en la misma. También es necesario indicar el
propósito de la reunión, y el posible desarrollo de los temas a tratar en la misma
(aunque, en la mayor parte de los casos, suele verse modificado de manera dinámica).
La agenda de la reunión permite que los asistentes planifiquen sus desplazamientos

(sobre todo, si han de viajar) o acudan sólo los días/horas que les resulte de interés.
También facilita que los partícipes preparen convenientemente los temas a tratar, y
que preparen sus contribuciones a los mismos.
No obstante lo anterior, tampoco es aconsejable excederse en profundidad ni detalle a

la hora de confeccionar la agenda, pues sabido es que las reuniones suelen ser bastante
dinámicas, los temas que se tratan flexibles, y muy frecuentemente se introducen o
eliminan, sobre la marcha, puntos concretos, impidiendo precisar de antemano la
evolución de las mismas. La agenda debe dar una idea general del contenido y la
duración, pero nada más.
En cuanto a la duración, puede parecer (y es) algo difícil de estimar, pero es necesario
hacerlo. Hay que planificar el tiempo necesario para discutir todos y cada uno de los
puntos de la agenda, con calma, pero a sabiendas de que, salvo que haya una hora de
finalización, las discusiones tienden a agotar todo el tiempo disponible.
La convocatoria de la reunión se distribuye a la lista de convocados (y a los demás

agentes que deban conocer su celebración, aunque no esté prevista su asistencia), por
to general vía fax, o por correo electrónico (normalmente la premura de tiempo impide
distribuirla por correo postal ordinario). A la hora de "invitar" a los asistentes a la

reunión, es buena práctica ser estricto. Más asistentes de los realmente necesarios
supone que la reunión pierde su eficacia, y que algunas personas estarán,
lamentablemente, perdiendo su tiempo y, probablemente, haciéndonos perder el
nuestro.
La figura 5.3 muestra un posible formato para la convocatoria de una reunión.
PROVECTO: REFERENCIA :
REUNIÓN :
LUGAR :
FECHA : HORA:
CONVOCADOS " • • fttf 11

NOMBRE Sv HJKÍ: IMPRESA
AGENDA:
Ht HhHO : AGENDA.DÍK Página I
Figura 5.3 Formato de convocatoria de reunión

Se considera de buen gusto confirmar la asistencia (por escrito o, simplemente, por

correo electrónico o por teléfono) a las reuniones para las que se es convocado
(aunque en la práctica se asume la asistencia salvo notificación en contra). No hay que
olvidar que, normalmente, quien convoca una reunión es responsable de habilitar la
sala para la misma, los medios materiales y humanos, comidas, etc., cuya organización
depende en gran medida del número de asistentes. También es conveniente que los
asistentes a la reunión, a la vista de la agenda de temas propuesta por el organizador,
contribuyan con nuevos puntos que, siendo de interés, no aparezcan en la lista
propuesta. A continuación se muestra una pequeña nota (que puede enviarse por fax o
correo electrónico) para confirmar la asistencia a una reunión:
Estimado Sr. Bronca,
En referencia a la convocatoria de reunión de seguimiento del proyecto "Red de

área local de Flores del Sur", según su fax de referencia FX-FDS-OO3.99, adjunto
le incluyo la relación de personas de nuestra organización que tienen prevista su
asistencia:
Sr. Mikono Mato (días 1 y 2).

SrQ. Marta Pujos (día 2, solamente).
Adicionalmente, le ruego tenga en cuenta nuestro interés por tratar, en dicha

reunión, las implicaciones económicas de la nueva redacción del proyecto técnico.
Atentamente,
Mikono Mato.
La figura 5.4 resume los aspectos más importantes a la hora de convocar una reunión y
fijar la agenda de la misma.
3.2 Desarrollo de la reunión
Mucha gente tiene la sensación de que las reuniones son "menos trabajo" porque
parece que nadie tiene que asumir un papel demasiado activo durante la totalidad de
las mismas. Sin embargo, es un gran error. Una reunión tiene éxito si (entre otros) el
responsable de la misma se ha encargado de preparar todos los detalles para que
"parezca" que la reunión avanza por sí sola.
Preparar estos detalles comienza por el principio: organizar los medios. No hay nada
que frustre más que llegar a una reunión y encontrar que el responsable no esté
presente, que nadie sepa dónde es, que la puerta de la sala esté cerrada (y haya diez
personas, con cara de frustración, apoyadas en la pared del pasillo), o que el proyector
de transparencias tenga la bombilla impida.
Si la puntualidad de los convocados es similar a la del responsable, a la hora señalada

estarán todos sentados a la mesa y listos para comenzar. Si no, es de buen gusto, al
igual que haríamos en una cena con los amigos, dar unos minutos "de cortesía" para
los más retrasados, pero no muchos (no hay que olvidar que, en definitiva, el retraso
de algunos no puede significar la pérdida de tiempo de trabajo de todos).
Al comenzar la reunión es conveniente que el responsable de la misma resuma el

contenido de la agenda, junto con las modificaciones a la misma, resultado de las
sugerencias hechas por los partícipes. Así ayudará a que los asistentes enfoquen su
atención sobre los temas a tratar, y recuerden el objetivo fundamental del evento. En
concreto, es conveniente repasar, en voz alta:
> De qué reunión se trata: proyecto, grupo de trabajo (técnico, económico,

directivo, etc.), y número de orden. Por ejemplo, "quinta reunión del
grupo de trabajo sobre aspectos económicos de la nueva ley de
consignas".
> Objetivo de la reunión. Siguiendo con el ejemplo anterior, "el objeto
principal es tratar de definir y consensuar los criterios de reparto de
comisiones e incentivos".
> Asuntos a tratar (y quién presentará cada uno de ellos). Por ejemplo,
"Para comenzar, Fulano expondrá el estado actual..., y después, Mengano
propondrá las alternativas identificadas...".
> Hora prevista de finalización. Por ejemplo, "La reunión deberá finalizar
antes de las 14:00 horas, puesto que algunos de los asistentes deben
regresar a sus puntos de origen".
A partir de ahí, se deberían tratar los puntos de la agenda, uno por uno, y a ser posible
en el orden reflejado en la misma. Probablemente, alguien desee introducir algún
punto adicional. La decisión de incluirlo o no es muy subjetiva, pero en principio hay
que tener en cuenta que:
> Es posible que a la reunión convocada no hayan asistido las personas

adecuadas para tratar dicho punto, o que no lo hayan preparado
adecuadamente, por no estar en la agenda. Ante esta eventualidad, el
tema en cuestión debería posponerse hasta la siguiente reunión.
> Tal vez la inclusión de dicho punto no sea consistente con la hora de
finalización de la reunión. Además, si dicha hora no puede retrasarse (por
ejemplo, porque alguno de los asistentes haya de tomar un avión), incluir
el nuevo punto puede significar que uno de los temas previstos se quede
sin tocar por falta de tiempo. Ante esta posibilidad, parece razonable
dejar el nuevo punto para el final (y sólo si hay tiempo).
> También puede suceder que, por una falta de previsión, hayamos
olvidado incluir un tema importante en la agenda, que puede ser clave
para discutir otros que sí estén en ella. En tal caso, especialmente si la
discusión se anticipa breve, no habrá más remedio que aceptar la
CAPÍTULO 5: SEGUIMIENTO DEL PROYECTO 173
inclusión del nuevo punto, y tratar de compaginarlo con el resto de la

agenda.
Durante la reunión, lo más normal es que alguien asuma de forma natural el control de
la misma. Lo mejor que puede suceder es que el control se reparta entre todos los
asistentes, saltando de uno en otro a medida que cada uno expone sus puntos de vista y
suscita el debate. Si dicho control no se ejerce naturalmente, será el responsable el que
deba hacerlo.
También es tarea del responsable reconducir la discusión cuando ésta se desvíe por
caminos inadecuados: cuando el debate se centre, innecesariamente o durante
demasiado tiempo, en aspectos muy puntuales, o cuando se comience a divagar sobre
temas intrascendentes. Para evitar y corregir estas situaciones, el responsable puede:
> Clarificar de vez en cuando el propósito de la reunión, resaltando los

objetivos y los temas a tratar. Puede utilizarse, por ejemplo, expresiones
del tipo "un debate interesante, pero no hay que olvidar que el objetivo
actual es...".
> Resumir los avances logrados, evaluando los mismos y dando por
zanjado ese punto de la reunión. Pueden emplearse fórmulas del tipo "en
resumen, las posturas con respecto al asunto tratado son las siguientes ..."
y, "por tanto, la conclusión al respecto es que...".
> Apuntar e introducir el siguiente tema a tocar, avanzando los objetivos
perseguidos, con expresiones del tipo "a continuación deberíamos pasar
al asunto de..., con el fin de ver si es posible definir...".
Cuando a una reunión asisten personalidades de gran relevancia, cuando está

presente un número elevado de personas, o cuando el tema a tratar es muy
polémico, con posturas encontradas, es habitual fijar un código de conducta
para la reunión.
■
El responsable de la reunión es el encaiga$o s además de presentar a los

asistentes y dar lectura a la agenda, de exponer el código de conducta.
En dicho código se estipulan las normas éticas a seguir para asegurar que la
reunión discurra sin sobresaltos, y dentro de .uilas pautas de comportamiento
razonables. En cierto modo, puede decirse que ta« agenda es un código de
conducta muy simplificado.
El código de conducto resuelve de antemano aquello que puede ser origen de

conflicto o tensión. Por ejemplp, define cuándo intervendrá cada parte, cómo
serán las iníexenciones, corno se proeede a pedir Ja palabra, qué valor tiene la
opinión de cada asistente, cómo se realizarán las votaciones y, en general,
cuantas normas se estimen oportunas pata mantener el orden y permitir que la
reunión discurra adecuadamente.
definen códigos de conducta (normas de obligado cumplimiento, en muchos

easos) en casi todas las instituciones públicas (Congreso de los Diputados,
Senado, Ayuntamientos, etc.), en los consejos de administración de las grandes
empresas y en los debates públicos. Si bien en una reunión de trabajo normal no
parece tener mucho sentido, si puede ser razonable, por ejemplo, regular de
antemano cómo serán las intervenciones de los asistentes y cómo se regulará el
uso de Ja palabra. En definitiva, todo lo que pueda ayudar a hacer más eficaz el
trabajo, pero sin restringir la libertad ní la flexibilidad de acción de los
asistentes a la reunión.
3.3 Actas de reunión
Durante cada una de las reuniones del proyecto el responsable del mismo (o persona
delegada) debe confeccionar las actas de la reunión (también conocidas como
"minutas"). En ellas, aparte de la referencia, fecha, hora y lugar de la reunión, así
como la lista de asistentes a la misma, deben consignarse brevemente los temas
tratados, las decisiones tomadas y, en especial, las acciones a realizar por cada agente
como consecuencia de las mismas (junto con la fecha tope para que dichas acciones
sean consumadas). La figura 5.5 muestra un posible formato para la redacción de
actas.
El objeto fundamental de las actas de reunión, como puede inferirse, es perpetuar y

recordar los acuerdos y decisiones tomadas en el seno de los proyectos y, en concreto,
durante las reuniones mantenidas, viniendo a ser algo así como la "memoria histórica"
de los acuerdos del proyecto.
Es difícil tomar buenas actas. En muchos casos se peca, bien por exceso, bien por
defecto. Unas actas redactadas por exceso normalmente contienen mucha información
transcrita que no resulta sustancial para el proyecto, es mero adorno. La lectura de las
actas se vuelve tediosa, y no es fácil extraer la información relevante, de más interés
(además, quien toma las minutas actúa, en tal caso, como mero escribano, y resulta,
por lo demás, de escasa utilidad como asistente a la reunión).
I K I I I ' K<): Formulo Actas
Figura 5,5 Formato de actas de reunión
Por el contrario, unas actas "por defecto" resultan crípticas, y leídas días después de la
reunión no aportan la información necesaria para saber qué temas eran importantes y,
sobre todo, por qué.
Tal vez lo más sustancial de unas actas sea el reflejo de las acciones, compromisos y
acuerdos tomados durante la reunión (esa memoria histórica de carácter colectivo a la
que se hacía referencia al principio de esta sección). Se deberá notar de cada acción
comprometida, anotando el responsable de la misma y la fecha en la que debe haberse
cumplido con el compromiso adquirido.
Las actas deben firmarse por todos los presentes (o, al menos, por un representante
de cada empresa) y distribuirse al final de la reunión, aunque a veces se mecanografían
tras la reunión y se distribuyen, posteriormente, por fax. En este último caso, se envían
firmadas por el responsable del proyecto, y se supone aceptadas por todos los demás
salvo que se notifique lo contrario, antes de un plazo de tiempo prudencial.
Todas estas formalidades se deben a que las actas de reunión se consideran

documentos vinculantes, esto es, de obligado cumplimiento (véase la lectura sobre
aspectos legales de la documentación de un proyecto, al final del presente capítulo).
Pueden implicar alteraciones al alcance o las condiciones del contrato y, por tanto,
suponen modificaciones potenciales a los beneficios esperados. Es, pues, fundamental,
redactar las actas con suma claridad, con lenguaje sencillo y sin ambigüedades, y sin
introducir en ellas matizaciones ni interpretaciones personales.
La figura 5.6 reseña algunos aspectos a tener en cuenta a la hora de redactar las actas
de reunión.
Figura 5.6 Lo que se debe y no se debe hacer al redactar las actas de

una reunión
©EíA-MA CAPITULO 5: SEGUIMIENTO DEL PROYECTO 177
3.4 Resumen de reunión
El resumen de reunión constituye un documento paralelo a las actas, cuyo carácter es

más informativo y menos de gestión. Su contenido es menos formal, más descriptivo,
y hace hincapié en la información derivada de la reunión, y no en los aspectos de
interés para la gestión del mismo.
Es el tipo de documento que se suele generar para terceras partes (tal vez los
responsables de la empresa, a quienes no les interesan los detalles técnicos ni tal vez
los de gestión) o a raíz de reuniones informativas. Nótese, por otra parte, que la
preparación del resumen no exime de la generación de las correspondientes actas.
En los resúmenes de reunión se incorporan todos los temas tratados junto con la
información extraída, sea o no directamente de interés para el proyecto.
Por ejemplo, si en una reunión con un proveedor de equipos informáticos se acuerda

fijar el plazo de entrega en dos meses, ésta será la única información a consignar en
actas. En el resumen de reunión, además, se puede consignar para qué clientes ha
trabajado el proveedor en el pasado o, incluso, cuáles son sus puntos de vista con
respecto a las subidas de precio de los equipos.
Es especialmente importante ser, al igual que con las actas, escrupulosamente aséptico
a la hora de redactar los resúmenes de reunión, evitando comentarios triunfalistas o
derrotistas. Lo importante es la información contenida, que no debe verse enmascarada
por la redacción.
Los resúmenes de reunión no se firman, no se consideran documentos vinculantes

(pues no están sujetos a la revisión ni aprobación por las partes), y sólo se distribuyen
a las personas directamente interesadas (o se adjuntan como documentación final del
proyecto). La figura 5.7 muestra un posible formato para el resumen de las reuniones.
178 DIRECCIÓN Y GHSTIÓN DE PROYECTOS
REUNIÓN MANTENIDA CON :
OBJETO :
PROYECTO: REFERENCIA :
FECHA: HORA:
LUGAR:
NOMBRE EMPRESA CARGO
FICHERO : Form:iH> Resumen Rennioii.díic III III 2IMI4
Figura 5.7 Formato de resumen de reunión

Por su parte, la figura 5.8 muestra algunos aspectos a considerar al redactar el resumen
de la reunión1.
Figura 5.8 Lo que se debe y no se debe hacer al redactar el

resumen de una reunión
4. EL DÍA A DÍA DE LA GESTIÓN DEL PROYECTO
La labor del responsable del proyecto no termina en las reuniones. Más al contrario,
las reuniones son hitos temporales donde se evalúa el trabajo realizado, y se identifica
y organiza el que resta por hacer.
Para gestionar día a día el proyecto, el responsable-gestor del mismo tiene que
realizar, básicamente, tres actividades distintas:
** Organizar y planificar.
*• Supervisar.
*" Controlar y corregir.

Debiendo aplicarlas a:
■*" Los recursos materiales y humanos disponibles. ^
El tiempo disponible. •■ El coste comprometido.
La organización y planificación (de recursos, temporal y de costes) se efectúa, por lo

general, durante la primera fase del proyecto, e incluso durante la preparación de la
oferta del mismo.
Durante el resto del proyecto, suele ser escasa la actividad de planificación, ya que se
limita a los cambios que se introducen después de comenzado el trabajo.
La gestión día a día es, más bien, una tarea de supervisión y control, y de corrección
de desviaciones. Es necesario identificar cuanto antes consumos superiores o
inferiores de recursos y las causas, así como establecer los mecanismos correctores
que permitan retomar el avance previsto para el proyecto. En concreto, es necesario:
> Medir y evaluar el progreso de los trabajos.

> Identificar las desviaciones sobre el plan previsto.
> Evaluar el impacto de dichas desviaciones sobre los objetivos básicos del
proyecto, tanto en alcance y plazo, como en costes.
> Proponer actuaciones correctivas que solventen o atenúen las
desviaciones identificadas.
> Corregir la planificación del resto del proyecto, para acomodar las
desviaciones y las actuaciones correctivas.
La gestión cotidiana es, pues, el arte de mantener la organización de las actividades

del proyecto. Y al igual que no existe un método único para organizar, por ejemplo, un
archivo, tampoco existe un modelo único para gestionar proyectos. Más bien, existen
múltiples metodologías y herramientas que ayudan a realizar las labores de
supervisión y control, proporcionando la información más relevante en cada momento.
En esta sección describiremos algunas de ellas, tales como:
> El estado de las acciones. Proporciona información acerca de qué

compromisos puntuales se han adquirido durante el proyecto, y si se han
satisfecho o no.
CAPÍTUtQ 5; SEGUIMIENTO DEL PROYECTO 181
> El nivel de avance técnico y económico. Proporciona información acerca

del consumo de recursos hasta el momento, y su relación con las
previsiones.
> El informe de situación del proyecto. Proporciona información contable
del proyecto, según partidas, comparado con las estimaciones iniciales.
> El estado de la documentación y productos del proyecto. Proporciona
información acerca de los productos generados dentro del proyecto, su
estado, versión, localización, etc.
4.1 Estado de las acciones
Si un proyecto es de tamaño tal que supone un número elevado de reuniones, resulta

difícil seguir la evolución de las decisiones puntuales adoptadas en cada una de ellas.
Además, a estos acuerdos, compromisos o decisiones adoptadas durante las reuniones

hay que añadir las que surgen en conversaciones, formales o informales, y que se
comunican por medios distintos (fax, comunicación interna, teléfono, etc.).
Por ello, suele ser habitual confeccionar una lista del estado de las acciones pasadas y
pendientes, con carácter histórico (es decir, desde el comienzo del proyecto hasta el
momento actual).
En dicha lista se consignan las acciones acordadas (y que alguien se ha

comprometido a hacer, o que será necesario asignar a alguien) agrupadas según las
reuniones en las que se adoptaron dichas decisiones. Junto a cada acción se consigna
el responsable, así como el estado en el que se encuentra la acción (completada,
pendiente, en curso, a revisar, etc.), los motivos (si los hubiere) y la fecha de
cumplimiento previsto.
Estas listas se suelen distribuir junto con la convocatoria de cada reunión, y pueden
comentarse como primer punto de la agenda de la misma. Son un documento muy
práctico a la hora de sintetizar de golpe el estado de cumplimiento de las acciones de
cada uno de los agentes del proyecto (y, si es menester, iniciar procedimientos
correctivos para las acciones más críticas o "disciplinarios" para las partes que,
sistemáticamente, omitan el cumplimiento de sus acciones).
La figura 5.9 muestra un posible formato para el estado de las acciones de un

proyecto.
Figura 5.9 Formato de estado de las acciones pasadas y pendientes
La figura 5.10 muestra algunos aspectos a considerar al redactar el estado de las

acciones pasadas y pendientes del proyecto.
CAPITULO 5: SEGUIMIENTO DEL, PROYECTO 183
Figura 5.10 Lo que se debe y no se debe hacer al redactar el estado

de las acciones
4.2 Avance técnico y económico
No hay que olvidar que el propósito final del proyecto es, a través de la realización de
unos trabajos, conseguir que los ingresos superen a los costes para así obtener un
margen económico. Bajo la premisa anterior se esconden dos objetivos
complementarios:
*" Un objetivo más técnico, derivado de la correcta ejecución, a tiempo, de los

trabajos.
*" Un objetivo económico, derivado del control de costes y gastos y del ingreso
de las cantidades a percibir por dichos trabajos.
Resulta tremendamente complejo evaluar el grado de avance técnico de un proyecto

en curso, pues no es fácil saber, con rigor, qué porcentaje del mismo se ha concluido
hasta el momento.
Las técnicas basadas en comparar el número de horas trabajadas, el número de

paquetes de trabajo terminados, o el porcentaje de productos o documentos finalizados
rara vez dan una estimación aceptable del avance real, ya que no todas las horas de
trabajo rinden igual, no todas las tareas ni los paquetes de trabajo suponen el mismo
esfuerzo, ni se incorpora a dichas técnicas un factor que tenga en cuenta la
complejidad asociada a cada tarea y, por tanto, el riesgo de incurrir en demoras.
Además, es típico que en cada proyecto la curva de avance no sea (como cabría
esperar), una recta perfecta, sino que asuma una forma similar a la mostrada en la
figura 5.11.
Figura 5.11 Recta de avance típica de los trabajos de un proyecto
En la figura anterior pueden apreciarse varios efectos característicos en la curva de

avance de un proyecto, en comparación con el avance ideal (la recta inclinada,
punteada) que podría esperarse.
Al comienzo del proyecto, en la parte identificada como "Zona A", la curva de avance
se sitúa por debajo de la recta de avance ideal, es decir, el proyecto avanza con mayor
lentitud de la esperada. Este efecto se produce, por lo general, debido a la curva de
aprendizaje propia de cada proyecto, en la que los miembros del equipo de trabajo
deben absorber conocimientos acerca del proyecto, organizarse entre sí, aprender
nuevas técnicas y conceptos, etc.
En la madurez del proyecto, correspondiente a la "Zona B" de la figura, el equipo de

trabajo avanza más rápidamente que en la fase anterior, al estar ya familiarizados con
los trabajos, las herramientas, las técnicas y el propio equipo de trabajo. Es en esta
zona cuando se debe recuperar, lo más pronto posible, el retraso acumulado en la zona
A.
Por último, lamentablemente muchos proyectos sufren, al final, una fase de

"saturación", que se produce cuando los últimos "retoques" al trabajo están por hacer,
pero el nivel de avance se ralentiza. Es el típico caso de los contratistas de obra que
nunca llegan a terminar todos los detalles pendientes en la vivienda, los últimos
retoques a un documento técnico, o las últimas pruebas a un equipo electrónico o un
programa informático.
La fase C, en buena práctica, no debería existir. Es el resultado de una mala

planificación, de una falta de integración del equipo de trabajo, o de un Cliente que
modifica las especificaciones o induce ruidos en el proyecto. La fase C deja detalles
por resolver pero, peor aún, retrasa la finalización del trabajo. Este retraso supor.e
costes para la empresa, e insatisfacción para el Cliente. ¿Quién no se ha desesperado
cuando parece que la obra de nuestra casa jamás llegará a su fin, y al final hay que
terminar aceptando que alguna tablilla del suelo suene más de la cuenta, o que en la
pared quede algún desperfecto?
En cuanto al avance económico, es más sencillo dar un valor objetivo del mismo, a
base de comparar los recursos (horas de trabajo, costes y gastos) consumidos con los
correspondientes recursos contemplados al presupuestar el proyecto. Se trata, pues, de
revisar el presupuesto (según se describió en el apartado 3.4 del capítulo 3),
contrastándolo con los últimos datos contables del proyecto, tal y como se hace en el
formato mostrado en la figura 5.12.
En el formato de la figura se toman las horas y gastos del proyecto directamente del
formato del presupuesto del mismo y, mediante comparación con los datos de horas
consumidas y gastos en los que se ha incurrido (celdas recuadradas), se calcula el
porcentaje de recursos consumidos según cada categoría, así como el porcentaje de los.
mismos en remanente. Estos valores porcentuales deben compararse con el avance
técnico del proyecto, para comprobar que el desarrollo de los trabajos sea acorde con
los recursos consumidos hasta el momento (y, en caso contrario, adoptar las medidas
oportunas). No obstante, la validez de dicha evaluación es tanto más dudosa cuanto
más incertidumbre haya para estimar el avance técnico del trabajo.
186 DIRECCIÓN Y-GESTIÓN DE PROYECTOS
Figura 5.12 Formato de avance económico del proyecto
Sin embargo, desde el punto de vista objetivo el formato anterior proporciona

información muy valiosa acerca de la marcha del proyecto. A primera vista, permite
deducir qué parte de los recursos de esfuerzo humano ya han sido utilizados. La figura
5.13 muestra gráficamente la relación entre los valores "consumido" y "remanente"
para el concepto de "Total de costes y gastos", que da una idea general del porcentaje
de recursos consumidos.
Figura 5.13 Recursos consumidos frente a los remanentes del

proyecto
La verdadera utilidad del dato de "remanente" anterior se pone de manifiesto cuando

dicho valor se compara con el porcentaje de facturación pendiente, el tiempo restante
para la terminación de los trabajos, y otros indicativos del avance del proyecto, en su
conjunto.
Otro dato importante es el porcentaje de horas, según categoría, consumidas hasta el

momento, y que queda reflejado en la figura 5.14, como resultado de evaluar las
celdas correspondientes para cada categoría.
20% 40% 60% 80% 100%
CONSUMIDAS ■ REMANENTE
Figura 5.14 Representación gráfica de las horas, según categorías,

consumidas
La gráfica anterior permite identificar rápidamente desviaciones sobre la carga de

trabajo. En general, el porcentaje de horas consumidas habría de ser similar, en
cualquier momento del proyecto, para todas las categorías, salvo en el caso de que las
actividades del proyecto asociadas a una categoría concreta se deban concentrar en un
período específico de los trabajos. Así, por ejemplo, si el responsable de una Sección,
de categoría 1, sólo participa durante la fase inicial del proyecto, en reuniones de

presentación a Clientes y otros participantes, parece razonable que poco después del
comienzo, el porcentaje de horas consumidas por personal de categoría 1 sea cercano
al 100%, siendo el de las demás categorías cercano a cero.
Por último, también es conveniente representar de forma gráfica, tal y como se hace en
la figura 5.15, la evolución de los ingresos y gastos globales del proyecto. En la
gráfica de la figura se diferencian las partidas de horas (globales, para todas las
categorías) subcontratos, otros gastos, contingencias y facturación, y sirve para
detectar anomalías en el consumo de recursos, que no puedan explicarse
razonablemente mediante la planificación concreta del proyecto.
Figura 5.15 Representación grátlca de la evolución de ingresos y

gastos
Por último, en proyectos de cierta complejidad o larga duración, puede ser

conveniente ir acumulando, en un mismo informe, datos históricos de la evolución del
proyecto, y no sólo la información instantánea que recopila el informe de avance
económico de la figura 5.12. Para ello, basta con ir acumulando los resultados
contables parciales de, pongamos, cada mes, en un formato similar al mostrado en la
figura 5.16. En el formato mostrado, aparece la evolución de gastos e ingresos,
acumulados por mes, así como el remanente hasta el final del proyecto.
Figura 5.16 Formato de evolución económica del proyecto
Del informe de la figura 5.16 puede extraerse información muy útil para el análisis y
diagnóstico de la gestión del proyecto, como el consumo acumulado de horas de
trabajo, por mes y categoría (figura 5.17), o la evolución acumulada de ingresos y
gastos (figura 5.18). En esta última gráfica, por ejemplo, se observa cómo el pago
inicial del proyecto sirve para mantener un flujo de caja positivo durante los dos
primeros meses, mientras que a partir del tercer mes los costes superan a los ingresos
percibidos, y la empresa comienza a financiar parcialmente el proyecto.
Por último, la información reflejada en las figuras 5.17 y 5.18 permite comparar de
forma rápida y sencilla la evolución de los costes con el avance de los trabajos, lo que
ayuda a identificar, valorar y justificar desviaciones y retrasos potenciales, así como a
desarrollar las acciones necesarias para corregirlas.
Figura 5.17 Evolución del consumo de horas de trabajo del

proyecto
Figura 5.18 Evolución de los ingresos y gastos del proyecto
LECTURA. MÉTODOS DE ANÁLISIS DEL VALOR AÑADIDO
Existen muchas técnicas para evaluar la situación económica de un proyecto.

Cuando el objeto del trabajo es fácilmente cuantifíeable en términos de
unidades producidas, una de ias metodologías más utilizadas es ía del análisis
del valor añadido (también conocida como EVA, de sus siglas en inglés Earned
Valué Análisis).
Las técnicas EVA comparan, en un instante de tiempo determinado, el coste

inicialmente previsto para ese momento en particular (avance previsto), el coste
real invertido hasta ese momento (avance de gastos o avance contable), y la
estimación del porcentaje de trabajo total completado hasta ese instante {avance
real, o avance técnico). -*$
Veamos un ejemplo. La empresa Caos se ha adjudicado un contrato de

consultoría para efectuar unos trabajos para la Administración, con un precio
basado en una estimación de 4.672 horas, a realizar en un año natural.
La siguiente tabla muestra la síntesis de los informes de situación mensuales

durante los primeros nueve meses del proyecto, y reflejan las horas que
inicialmente se estimó que se consumiesen cada mes (horas previstas), el avance
porcentual correspondiente (avance previsto), las horas que realmente $$
dedicaron (horas reales), el coste de las mismas con respecto al total del
proyecto (avance de gastos) y un último valor indicativo del grado de avance
logrado al utilizar dichas horas (avance real), generalmente proporcionado p< el
equipo de trabajo.
BE FB IWR IWY JL JU SB OC rev DC Total

hfcras pristas 32D B
460 400 35 48 N
480 _32 160 >400 T490 493 320 4672
7% 17 28 2
33 0
43 0
5*% 61 64% 73 83 £G 100%
% % % % % % % %
Hcrasreeles 340 420 410 360 476 480 300 80 320 3186
7% 16 25 33 43 53 60 61% 63 eap/o
flUBFEB d9Q9StOG % % % % % % % 61%
5% 20 24 31 3£P/o 44 51 53% 61
AaxeneEÍ % % % % % %
Si se representan los valores anteriores de manera gráfica, se obtiene la figura

que se muestra a continuación, y que permite apreciar las diferencias entre al
avance previsto, el avance de los gastos (avance contable) y el avance real
(avance técnico).
ENE FEB MAR ABR MAY JUN JUL AGO SEP OCT NOV DIC
A partir de la gráfica y de la tabla anteriormente mostradas es posible calcular

un número de indicadores <tel estado del proyecto. Así, por ejemplo:
■ £1 retraso en la producción puede calcularse como la diferencia entre la

producción programada y la producción real en el instante de referencia,
que a finales de Septiembre es de 206 horas.
El sobreeaste puede calcularse como la diferencia entre el avance de los
gastos y el avance real del proyecto. En la figura, la diferencia entre ambos
valores es del 7% (se han consumido el 68% de los recursos, frente al 61%
de avance real).
■ Ei retraso en plazo puede calcularse como el momento en el tiempo en el
que el avance real en el instante de referencia deberían haberse realizado
según las previsiones. €n la figura anterior este retraso es de 1,75 meses, ya
que el 61% de avance realmente logrado a finales de Septiembre debería
haberse alcanzado en Julio. » "
A tenor de lo anterior,, el proyecto ejemplo, en el instante de referencia

(Septiembre) sufre un sobreeoste del 7% y un retraso del 15%.
Los indicadores anteriores pueden utilizarse para establecer un mecanismo de

alarmas que indique cuándo, a partir del sobreeoste y el retraso calculados, el
proyecto está en alguno de los siguientes estados:
©RA-MA CAPITULO 5: SEGUIMIENTO DEL PROYECTO 193
tajo control. No se requieren acciones de control.

■ Presenta desviaciones menores que conviene corregir,
■ Presenta desviaciones sustanciales que se deben notificar a la Dirección y
tomar medidas excepcionales para su corrección. .
■ Fuera de control. ^ I"
La siguiente figura muestra una roanera gráfica de representar fas desviaciones

en tiempo y plazo, márgenes para identificar las cuatro situaciones anteriores y
dónde se ubicaría (mediante una estrella) el proyecto ejemplo de la tabla
anterior. Los umbrales de las cuatro zonas de actuación se definen al comenzar
el proyecto, en función de la naturaleza del mismo, del nivel de coatrol deseado,
lo relevante que sea para la empresa, etc.
COSTE
ESTADO ACTUAL DEL PROVECTO
EL PROYECTO ESTA
BAJO CONTROL
SUPERVISAR V CORRE6IR
LAS DESVIACIONES
INFORMAR A LA DIRECCIÓN Y
TOMAR MEDIDAS EXCEPCIONALES
PROYECTO FUERA DE CONTROL
Otra de las utilidades de los análisis del valor realizado son ios mecí para
estimar el coste de terminación 4el proyecto. En? el ejemplo aíiteri horas
necesarias para terminar el proyecto' se calculan teniendo en cuenta horas
reales que han sido necesarias (3.186) para completar el avance realmei logrado
(el 61%). Las horas de trabajo necesarias para completar «i 100% proyecto
pueden calcularse extrapolando como sigue:
H - = 5.223- Horas
H TOTAL
Avance 0,61
Mientras que, al ritmo actual, el proyecto necesitaría, para terminarse
Lo anterior puede ÍJiterpretarse corno que, de no aplicar mecanismos de

corrección, el proyecto finalizaría con un sobrecoste de 551 horas (un 1 1,8%) y
un retraso de 2,75 meses {casi un 23%),
Pero, ¿son realmente válidas los métodos de análisis del valor añadido? La
respuesta es compleja. Los valores resultantes son indicativos del estado del
proyecto y, si se evalúan cuidadosamente, proporcionan información muy
valiosa para saber cuál es el estado del mismo. Pero como cualquier otro
método de análisis cuantitativo, los resultados son tan buenos como buenos sean
Jos datos utilizados. En conemo, es mvy difícil estimar con precisión cuál es el
avance real de un proyecto complejo.
El avance feat de un proyecto sólo puede medirse con precisión cuando el

resultado son unidades de producción de valor homogéneo (horas de trabajo no
vinculadas a resultados concretos, objetos fabricados, etc-). En los proyectos en
los que los productos son más complejos (documentos, prototipos, unidades
sueltas, etc.) evaluar el avance es muy complicado, y estimar el esfuerzo
necesario para completar cada uno de ellos es a menudo difícil y, además, a
menudo depende de la percepción subjetiva del equipo de trabajo. No es
extraño que preguntar a dos miembros distintos del equipo de trabajo, o al
mismo en días consecutivos dé cómo resultado distintos valores en la
estimación del avance real del proyecto.
4.3 Informe de situación del proyecto
Con el fin de que el Cliente pueda comprobar la evolución y avance del proyecto es
una buena práctica redactar, al final de cada paquete de trabajo, un informe de
situación del mismo, donde se consignen las tareas realizadas, las modificaciones al
alcance del trabajo, las diñeultades que se han encontrado para su realización, cómo
han sido las relaciones entre los integrantes del equipo de trabajo (entre empresas, no
entre grupos de la misma empresa) y con terceros, las acciones futuras previstas y, en
general, cualquier otro datos significativo a la hora de valorar el trabajo realizado. La
figura 5.19 muestra un posible formato para este tipo de informes.
Los informes de situación también pueden ser requeridos en reuniones de progreso

intermedias para todos los paquetes de trabajo en curso, aunque no hayan sido
completamente terminados, o para mantener informada a la dirección de la empresa.
También suelen confeccionarse, a modo de resumen, al terminar y cerrar el proyecto
(véase el capitulo 6).
Es conveniente confeccionar informes asépticos y poco emocionales. Los informes de

actividad trascienden a la propia vida del proyecto, y en ellos no es bueno volcar
percepciones personales que carezcan de sentido una vez finalizado el trabajo, si bien
sí goza de interés toda aquella información que justifique retrasos o incumplimientos
parciales o que pueda afectar a futuros trabajos.
5. CONTROL DE CONFIGURACIÓN
Al conjunto de actividades destinadas a documentos y los productos obtenidos

durante la vida de un proyecto se le conoce con el nombre de control de
configuración del proyecto,
Los objetivos y actividades principales del control de configuración se resumen en tres

puntos:
> Definir qué es configurable (debe gestionarse su generación y evolución)

dentro del proyecto.
> Asignar (a los elementos configurables) etiquetas de configuración
(códigos o referencias), según un patrón definido y conocido por los
miembros del equipo de trabajo y por el Cliente.
> Gestionar la evolución de los elementos configurables, según el
procedimiento descrito en el siguiente apartado.
Informe de situación [] Intermedio
NOMBRE DEL PROYECTO D Final
INFORME DE ACTIVIDAD / PROYECTO

PROYECTO/PT: CLIENTE :
TITULO :
RESPONSABLE :
FECHA COMIENZO: TERMINADO:
TRABAJO REALIZADO. ALTERACIONES AL ALCANCE PREVISTO
-
RESUMEN DEL ESTADO : - Sí i
No Descripción
Modificaciones al alcance
Retrasos
Incremento del riesgo
Sob recoste
Insatisfacción del Cliente
Ampliaciones al contrato
Carencia de recursos
Conflictos interpersonales
_
Falta de formación y/o experiencia
I l( III K< >: informe siluLición.<!<ic
Figura 5.19 Informe de situación de proyecto o paquete de trabajo
5.1 Gestión de la documentación
Durante el ciclo de vida típico de un proyecto, se genera abundante documentación

relativa al mismo, tanto de tipo técnico, como de gestión o documentación
complementaria. Algunos de los tipos de documentos más habituales se relacionan a
continuación:
&* Documentación técnica:

> Pliegos técnicos y especificaciones.
> Documentos de diseño.
> Notas técnicas.
> Planos, diagramas, etc.
> Listados de programas.
y Manuales técnicos, de instalación, de usuario, etc.
> Otros.
•■ Documentación de gestión:
> Presupuestos y ofertas.
> Minutas y acciones.
> Informes de situación.
> Balances de horas y gastos.
> Otros.
^ Documentos complementarios:
> Listas de documentos.
> Listas de productos.
> Presentaciones.
> Planes de calidad.
> Procedimientos.
> Faxes, comunicaciones internas, correos electrónicos, etc.
> Otros.
a documentación generada mismo, en especial en proyectos de cierta

complejidad, de larga duración o donde intervienen equipos numerosos -de
personas (o. distintas empresas). Su correcta gestión evita duplicar
innecesariamente los documentos generados, y permite conocer a los integrantes-
del equipo de trabajo qué documentación existe, cuál es la última versión, dónde se
encuentra Uxnúizada, etc.
Pero la documentación de un proyecto no sólo es importante para la vida del mismo.

Su utilidad trasciende más allá de la conclusión del proyecto que la generó, sirviendo
como referencia y base de conocimiento ante nuevos proyectos de similar naturaleza,
o cuando cambie alguno de los integrantes de] equipo de trabajo.
La gestión de la documentación de un proyecto comienza con el arranque del mismo,

y típicamente incluirá desde las primeras comunicaciones (tal vez informales) con el
potencial Cliente hasta el informe de cierre del proyecto, una vez terminado, y
pasando por los documentos de oferta, especificaciones, informes de situación, etc.
La gestión de la documentación, que en pequeños proyectos suele ser parte de la tarea

del gestor del proyecto, puede delegarse en otras personas en proyectos complejos, o
donde el volumen de la documentación generada así lo aconseje.
La lista de documentación de un proyecto incluirá cada documento o comunicación

generada o recibida dentro del mismo, clasificados según el tipo de documento. A
cada documento le será asignada una referencia unívoca, que permita deducir con
cierta facilidad datos tales como:
> El tipo o naturaleza del documento (nota técnica, informe de situación,

fax, etc.).
> El proyecto dentro del cual se genera.
5* El número de tarea o paquete de trabajo al que va asociado.
> El número ordinal.
> La empresa que lo ha generado.
> La versión.
Así, por ejemplo, el documento de referencia:
NT-FDS-200-012.2-CC
podría corresponder a la Nota Técnica número 12, versión 2, generada por Caos
Consulting dentro del paquete de trabajo 200 del proyecto para Flores del Sur,
mientras que el documento:
FX-FDS-200-019-FDS
podría corresponder al fax decimonoveno, enviado por Flores del Sur, y

correspondiente al mismo paquete de trabajo.
En los ejemplos anteriores, las dos primeras letras indican el tipo de documento de que
se trata. Una posible lista de códigos podría ser:
1 CÓDIGO Tipo documento CÓDIGO Tipo documento

FX Fax CI Comunicación
interna
MN Minutas RR Resumen de reunión
NT Nota técnica DD Documento de
diseño
SP Especificación IS Informe de situación
PL Plano
Sin embargo, cada empresa deberá decidir e implantar su propio mecanismo de

asignación de referencias a los documentos generados dentro de cada proyecto, de
acuerdo con las necesidades y. peculiaridades de su actividad. En proyectos
desarrollados entre varias empresas es conveniente decidir y acordar este mecanismo
de antemano, de manera unificada para todas ellas.
Es importante reflejar en el listado (o base de datos) de la documentación del proyecto

todas las versiones (y no sólo la última) de cada documento. Así se permite seguir la
evolución de un documento a lo largo de la vida del proyecto, y también recuperar
versiones anteriores de un documento concreto para, por ejemplo, identificar cambios
o modificaciones al mismo.
También es aconsejable clasificar los documentos en función de su disponibilidad o,

dicho de otra manera, a la capacidad de distribución del mismo, distinguiendo entre
documentos clasificados como52:
> Secreto / confidencial (para un grupo restringido de personas).

> Personal (sólo accesible a una persona).
> Interna (sólo accesible al personal de la empresa que lo genera).
> De proyecto (sólo accesible a los miembros del equipo de trabajo del
proyecto).
> De libre distribución.
Por último, ante la diversidad de soportes disponibles, conviene identificar también,

para cada documento, el tipo de soporte sobre el que está almacenado (fichero, papel,
etc.), así como su ubicación física (disco, cinta, carpeta, armario, etc.).
Una vez cerrado el proyecto, la documentación del mismo se clasificará en reutilizable

y no reutilizable. La documentación reutilizable se incorporará de inmediato al archivo
de documentación de la empresa, mientras que la no reutilizable puede ser destruida
En una película de espías los niveles de clasificación serían: no clasificado, restringido,

confidencial, secreto, alto secreto y sólo para sus ojos (del inglés eyes only).
una vez transcurrido un período prudencial de tiempo (que incluya garantías, servicios
posventa o períodos de posible contratación de una continuación del proyecto).
Así pues, y a modo de resumen, la gestión de la documentación de un proyecto

conlleva la realización de, al menos, las siguientes tareas:
> Redacción (o adaptación) de los procedimientos de gestión de

documentación y asignación de referencias a documentos.
> Asignación de referencias a los documentos, según sean generados.
> Inclusión de los nuevos documentos (o versiones de los mismos) en la
base de datos (listado) de documentación del proyecto.
> Difusión de la misma, para conocimiento general del equipo de trabajo.
> Incorporación de la base de datos del proyecto a la base de datos general
de la empresa, una vez cerrado el proyecto.
La figura 5.20 muestra un posible formato para reunir y controlar la documentación

generada o manejada dentro de un proyecto.
GESTIÓN DE DOCUMENTACIÓN DE PROYECTO
PROYECTO : REFERENCIA : CLIENTE :

RESPONSABLE : HOJA:
1 1 í*f1' ' " *■ ■ — — SOPORTE
Figura 5.20 Formato de gestión de la documentación del proyecto

5.2 Gestión de los productos generados
Además de los documentos del proyecto, es de vital importancia gestionar

adecuadamente la información correspondiente a los productos generados, tanto en
versiones intermedias como finales, incluyendo maquetas, prototipos, dispositivos
mecánicos, circuitos electrónicos, programas software, etc.
El procedimiento de gestión de productos es similar al descrito, para documentos, en

el apartado anterior, y sólo hay que tener en cuenta las peculiaridades propias de los
productos a la hora de configurar el formato definido en el apartado anterior.
6. Cambios Al Alcance Del Proyecto
Una de las cosas más divertidas de los proyectos es su "personalidad"w. Heredan las
características (buenas o malas) del Cliente, y se empapan de la profesionalidad y
rigor (o falta de él) del contratista, todo ello sin perder de vista los efectos y
perturbaciones del entorno en el que se desarrollan.
A lo largo del ciclo de vida de un proyecto, y con mayor probabilidad cuanto mayor es
su duración, se presentan múltiples ocasiones que incitan a cambios en el curso
previsto de los trabajos. Meditar sobre las necesidades y objetivos, la aparición de una
nueva técnica o herramienta, la modificación de las normas o la regulación aplicable, o
la aparición de productos sustitutivos o complementarios son algunas de las buenas
razones para verse tentado a modificar algo (alcance, precio o plazo) en la evolución
del proyecto.
Pero los cambios son costosos. Implican nuevo esfuerzo de planificación y gestión,
y tal vez desperdiciar parte del trabajo realizado para ortentarlo en otra dirección.
Son cambios de ritmo que minan la eficiencia del equipo de trabajo, y además
constituyen perturbaciones a través de las átales se filtran errores y "despistes".
Incluso aunque un cambio implique ventajas globales (en la calidad o funcionalidad

del producto, o en la eficiencia del proceso productivo), hay que pensárselo dos veces
antes de aplicarlo a un proyecto en marcha. Muchas veces, el coste del cambio supera
con creces al beneficio derivado del mismo, y aumenta los riesgos de que algo salga
mal.
En realidad, la personalidad es el conjunto de cualidades que distinguen a los individuos y,

por tanto, no es aplicable a los proyectos. Sin embargo, no es menos cierto que algunos
proyectos parecen estar dotados de vida propia.
El origen de un cambio puede ser interno o externo a la organización (o el equipo de

trabajo). Las propuestas de cambio de origen externo son ajenas al equipo de
trabajo. Suelen tener su origen en el Cliente, los usuarios, proveedores o sistemas de
auditoría externa a la empresa.
Por su parte, las propuestas de cambio de origen interno arrancan de la propia

organización, bien del equipo de trabajo, bien de /a dirección de la empresa, control de
calidad de la misma, etc.
Con respecto al alcance o propósito del cambio, cabe distinguir entre:
*" Adaptaciones. Son adecuaciones de los trabajos a nuevas características de

entorno de explotación. Así, por ejemplo, se adapta un programa de ordenador
a la aparición del euro, un vehículo a la nueva normativa de circulación, o un
texto educativo a los nuevos conocimientos y descubrimientos en el área
pedagógica que se trate.
■*■ Mejoras. Son ampliaciones de la funcionalidad o de las prestaciones del

producto o servicio adicional, y que no estaban contempladas en las
especificaciones iniciales del mismo. Son mejoras, por ejemplo, crear una
nueva interfaz de usuario (más vistosa, tal vez) para un programa de
ordenador, añadir un novedoso sistema de seguridad a un modelo de
automóvil, o cubrir un tema adicional en un libro de texto.
*" Correcciones. Son cambios al producto o servicio original que tienen como
objeto hacerle cumplir las especificaciones iniciales requeridas para el mismo,
y que por causa de algún error u omisión no se satisfacían. Así, son
correcciones los cambios a un programa para que calcule correctamente el
saldo de una operación, las modificaciones a un vehículo para que no muestre
tendencia al sobregiro en las curvas, o la eliminación de erratas o conceptos
incorrectos en un libro de texto.
En relación al propósito del cambio, cabe decir también que por lo general denota (por
sí solo) quién es el responsable del cambio, o quién sufragará el coste del mismo.
Parece lógico pensar que el contratista adjudicatario del contrato para la provisión de
un bien o servicio es el responsable de todos los cambios correctivos, mientras que
sólo vendrá obligado a realizar cambios adaptativos o mejoras cuando explícitamente
figure en el contrato, bien como parte de los compromisos adquiridos, bien como
ampliación en forma de mantenimiento o garantía.
Por último, todo cambio al alcance o contenido de un proyecto debe seguir un

procedimiento, concreto y conocido, que regule la manera de encarar una necesidad de
cambio y el proceso que se genera hasta que el cambio está implantado (o se rechaza).
Este mecanismo, conocido como gestión de cambios, tiene por objeto asegurar que no
se producen arbitrariedades a la hora de introducir cambios en un proyecto, y que la
CAPITULO 5: SEGUIMIENTO DR1, PROYECTO 203
planificación y utilización de recursos necesarios para la implantación del cambio es,

al menos, tan rigurosa como el procedimiento de gestión global del proyecto.
Así, las fases típicas (que se describen una por una en los apartados siguientes) de un
procedimiento de gestión de cambios, incluyen:
*" Propuesta motivada de cambio.
^ Análisis y evaluación del cambio.
*" Autorización o rechazo formal del cambio.
*" Implantación y seguimiento del cambio.
*" Registro del estado del cambio.
6.1 Propuesta motivada
En principio, todo cambio obedece a una necesidad, o a una motivación concreta, que
persigue mejorar el bien o servicio objeto del proyecto, o el procedimiento seguido
para obtener dicho bien o servicio.
Un cambio, como ya se ha dicho, supone costes. Costes para quien lo idea (pues ocupa
tiempo en ello), y aún más costes para quienes lo evalúan y (en su caso) implantan.
Por esta razón parece razonable que cualquier cambio propuesto esté razonablemente
motivado y haya sido suficientemente meditado.
En general, cualquiera puede proponer un cambio. Desde el Director General hasta el

último becario de la empresa. Aunque, en general, los cambios más interesantes
provienen de aquéllos más involucrados con el día a día del trabajo 54, las propuestas de
cambio deben estar abiertas a todos.
54
A finales de los ochenta, el Departamento de Defensa (DoD) norteamericano puso en marcha
un programa destinado a recopilar propuestas de cambio de todo el personal de las Fuerzas
Armadas, destinado a rebajar costes y optimizar procesos dentro de los ejércitos. El ahorro
obtenido a lo largo de los primeros años de implantación del cambio se convertía en "puntos",
que permitían al autor de la idea disfrutar de permisos vacacionales, programas de formación,
etc. Curiosamente, los cambios que más ahorro supusieron fueron propuestos por personal "de
base", que se peleaba con el día a día de la rutina. Así, un cabo de mantenimiento propuso
unificar las cabezas de los tornillos de las unidades auxiliares de potencia (y otros
dispositivos), lo que supuso un importante ahorro económico al reducir el número de
herramientas (y el peso a transportar) de dotación del aparato.
204 [DIRECCIÓN Y GESTIÓN DK PROYECTOS
La figura 5.21 muestra un posible formato para un propuesta de cambio. En él se

incluyen, aparte del autor y otros datos básicos, la descripción del cambio propuesto,
la motivación del mismo y la parte del proyecto a la que afecta.
KICHERO : Propuesta Cambio,doc
Figura 5.21 Formato de propuesta de cambio

6.2 Análisis y evaluación
Aunque una propuesta de cambio sea casi siempre una muestra de interés y de buena
voluntad por parte de quien la origina, de buenas intenciones está empedrado el
camino del cielo. Esto quiere decir que antes de aceptar un cambio es necesario
evaluar cuidadosamente su magnitud, el coste de llevarlo a cabo, y el impacto sobre
las actividades del proyecto (en especial, sobre las que tienen carácter contractual,
tales como alcance, plazo y coste).
A propuesta del Director de proyecto, se realizará un análisis y evaluación del cambio

sugerido. La evaluación, que puede llevar a cabo el propio responsable del proyecto o
persona por él designada, tiene por objeto:
^ Identificar él alcance práctico del cambio.

íS=
Identificar y evaluar el impacto sobre las necesidades de recursos (materiales y
humanos).
*" Evaluar los riesgos potenciales.
*" Analizar el impacto sobre la planificación temporal prevista.
»" Verificar la compatibilidad con otros proyectos o actuaciones de la empresa.
*" Analizar la trascendencia sobre otros proyectos, propios o ajenos, así como
sobre la empresa y el Cliente.
** Analizar el efecto sobre los aspectos contractuales del proyecto.
6.3 Autorización o rechazo
A la vista del análisis y evaluación anterior, el responsable del proyecto o persona

delegada (por ejemplo, el responsable técnico si el cambio propuesto sólo implica
aspectos técnicos del proyecto) tomará una decisión acerca de la pertinencia o no de
implantar el cambio propuesto. En ocasiones, cuando la trascendencia de dicho
cambio va más allá del propio proyecto, la decisión debe tomarse en instancias
superiores de la organización.
La decisión sobre un cambio puede ser de aceptación o rechazo. También puede

diferirse la implantación de un cambio cuando se estime que:
** El cambio trasciende al ámbito del proyecto, y debe ser evaluado por

instancias superiores.
■*" Es preciso profundizar más en el análisis realizado.
**" Obligue a modificar el contrato, y se entienda que no es conveniente proponer

dicha modificación o, simplemente, no es viable.
*" Aunque sea un cambio apropiado, no sea el momento oportuno.
Por último, es importante recordar que todo cambio que afecte al resultado del
proyecto ha de contar, en cualquier caso, con la aprobación del Cliente, en especial si
afecta a compromisos contractuales.
6.4 Implantación y seguimiento
Si se identifica que el cambio propuesto es, a la luz del análisis realizado, adecuado, y
si se ha optado por aceptar formalmente el mismo, es el momento de ponerlo en
marcha.
Obviamente, existen diferentes objetivos a perseguir a la hora de implantar un cambio

concreto (ya autorizado) dentro de las actividades de un proyecto, entre los que se
encuentran, al menos:
*" Perturbar al mínimo posible el desarrollo del proyecto, las actividades del
equipo de trabajo y las actuaciones previstas con terceros.
^ Mantener el coste (material y humano) del cambio dentro de los márgenes

previstos en la solicitud (y, tal vez, corregidos en la aceptación).
^ Dar cumplimiento a las necesidades concretas por las que se propuso el

cambio.
Por lo demás, implantar un cambio implica un proceso similar al de poner en marcha

un proyecto, ahora dentro del proyecto en curso y, por tanto, son de aplicación
similares consideraciones a las reseñadas en el apartado 2 de este capítulo.
6.5 Registro de estado de los cambios
El registro de estado de cambios es el "diario de a bordo" de las modificaciones al

proyecto, y forma parte del control de configuración del trabajo.
En las hojas de registro de cambios se consigna toda la información necesaria para

seguir y controlar las modificaciones ai proyecto, incluyendo la historia de propuesta
de cambio y el análisis y evaluación resultante. Además, se consigna la descripción de
la implantación, y los resultados de la misma.
La figura 5.22 muestra un posible formato para el registro de estado de los cambios de
un proyecto.
Figura 5.22 Formato de registro de cambios

7. OTRAS ACTIVIDADES
Hasta el momento se han abordado las técnicas y las herramientas más habituales para
supervisar el avance de un proyecto, así como para detectar las posibles desviaciones.
Pero, ¿qué ocurre cuando dichas desviaciones se producen?, ¿cuáles son los
mecanismos que han de ponerse en marcha para corregir los efectos indeseables de la
pérdida de rumbo?
Las desviaciones, en términos generales, pueden obedecer a múltiples causas. A

efectos del mecanismo de corrección a aplicar, sin embargo, sólo existen dos grandes
grupos de causas:
•" Las causas objetivas, puntuales, asociadas a hechos concretos. Por ejemplo,
una baja temporal por enfermedad, un cambio en el precio de algún
suministro, o un diseño defectuoso (que obliga a dedicar más tiempo, y más
dinero, al proyecto) son causas comunes de desviación temporal y económica
del proyecto. Sin embargo, estos motivos son relativamente fáciles de
detectar, y un poco de sentido común, junto con las facultades que debe tener
a su disposición todo director de proyecto, hace que las consecuencias puedan
preverse y corregirse con relativa facilidad (aunque no necesariamente, sin
coste apreciable).
^ Las causas subjetivas, asociadas a la idiosincrasia, la actitud y la aptitud de

las personas y de las organizaciones, que impiden detectar a tiempo las
situaciones anómalas y, mucho menos, organizar mecanismos correctivos
eficientes.
De los dos grupos anteriores, es sin duda el segundo el que más temen los directores
de proyecto experimentados. Allí donde las metodologías objetivas dejan de ser
suficientes, y donde lo que se requiere es más "engrasar la máquina" que técnicas
numéricas de probada eficacia, la dirección de proyectos deja de ser ciencia para
convertirse en arte.
7.1 Conflictos interpersonales en el proyecto
Un conflicto es, según el diccionario, un problema, una cuestión o materia de

discusión, o una situación desgraciada y de difícil salida. A lo largo de un proyecto se
producen múltiples conflictos interpersonales (que, como ya se dijo, son los más
complejos de resolver), ya sean internos (entre el equipo de trabajo, con lo superiores,
etc.) o externos (con el Cliente, o con terceros).
CAPITULO 5: SEGUIMIENTO DEL. PROYECTO 209
Un director de proyecto puede dedicar mucho tiempo a resolver conflictos. En

concreto, gran parte de su esfuerzo se destinará a detectar, analizar y (si tiene suerte)
solventar conflictos. Por eso, conviene dedicar unos párrafos a esta cuestión.
Las situaciones de conflicto interpersonal en un proyecto son complejas de resolver,

pues a menudo dependen no sólo del problema concreto, sino también del contexto en
el que se produce el mismo, incluyendo la actitud, la aptitud, los valores y las
prioridades, el nivel de vida, la percepción personal o los intereses personales de las
gentes y las organizaciones.
Los conflictos interpersonales suponen un coste para los proyectos mucho mayor de lo
que cabría imaginar, pues provocan, a corto plazo, ineflciencía en el equipo de trabajo,
flujos de información inadecuados (que dificultan la toma de decisiones correctas),
pérdida de iniciativa personal e, incluso, pérdida de miembros del equipo de trabajo.
Incluso, los conflictos interpersonales dan lugar a situaciones de insatisfacción que, en
más ocasiones de las que cabría esperar, acaban en pequeños actos de sabotaje".
Hay muchos textos especializados en las relaciones interpersonales dentro de los

equipos de trabajo, así como en la detección y resolución de conflictos, y no parece
éste el lugar más adecuado para ahondar en la cuestión. Sin embargo, sí puede ser
razonable resaltar la importancia que tiene "la mano izquierda" del responsable de un
proyecto con vistas a mantener el nivel de satisfacción y compromiso de las personas
involucradas en el proyecto, esto es, cuidar las interfaces del proyecto.
7.2 Interfaces del proyecto
La figura 5.23 muestra las interfaces más significativas de un proyecto típico. El

Director de Proyecto es el mediador, y el punto de contacto (y referencia) para los
diferentes agentes del sistema, ya sean internos (sus su periores en la empresa, el
equipo de trabajo, etc.) o externos (el Cliente, los proveedores, los subcontratistas,
etc.).
55
Voluntario o involuntario. Aunque parezca exagerado, un empleado insatisfecho pondrá
menos atención a la hora de cuidar o conservar los recursos materiales de la empresa, o un
directivo descontento será menos cauto a la hora de deslizar datos comerciales de la
organización en una fiesta de fin de semana, o en una entrevista con la competencia, para
cambiar de trabajo.
Figura 5.23 Representación gráfica (le los interfaces en un proyecto
Tales interfaces son consecuentes (o consecuencia) de los tres objetivos básicos

asociados a la figura del Director de proyecto:
> Conseguir que el equipo de trabajo funcione adecuadamente. Para ello,

tendrá que organizar, planificar, dirigir, coordinar y mediar, como
actividades principales.
> Conseguir que el Cliente (ante el cual el Director de Proyecto es el
máximo responsable) esté satisfecho (dentro, claro, de lo razonable).
> Obtener buenos resultados para la empresa.
7.2.1 INTERFAZ CON EL CLIENTE
El Director de Proyecto es el máximo responsable de la empresa ante el Cliente, y el

único punto válido para el contacto comercial o financiero, para la negociación o para
la transmisión de información de cierto alcance. Esto no impide, por otra parte, que el
director de proyecto pueda, eventualmente, delegar alguna responsabilidad en su
equipo de trabajo.
En general, las responsabilidades del responsable del proyecto con respecto al Cliente,
incluyen:
"" Canalizar las relaciones entre Cliente y empresa, incluyendo las de tipo
comercial y técnico.
*" Informar periódica y adecuadamente al Cliente acerca de los avances de los

trabajos, los resultados obtenidos, los problemas detectados y las posibles
soluciones a los mismos.
■»" Planificar, convocar, organizar y coordinar las reuniones, o proporcionar

soporte al Cliente en dichas actividades, si desea encargarse de ello él mismo.
"■ Responder de las faltas de cumplimiento, de los retrasos y de las posibles

quejas del Cliente referentes a trabajo realizado.
*" Negociar cambios al alcance o contenido, duración y coste de los trabajos.
7.2.2 INTERFAZ CON EL EQUIPO DE TRABAJO
El Director de Proyecto es el responsable de la correcta actuación del equipo de

trabajo del proyecto. A lo largo de la duración del mismo, el Director de proyecto es el
"jefe" operativo de los miembros del equipo de trabajo, y sus funciones incluyen:
^ Planificar, organizar, dirigir y coordinar a las personas y los medios utilizados,

incluyendo el cambio o sustitución de cualquiera de ellos.
*" Dirigir la ejecución de los trabajos, definiendo las directrices y pautas básicas
para ello.
**" Supervisar la correcta ejecución de los mismos.
"" Detectar y analizar las desviaciones sobre la planificación te mporal,

económica y técnica (de alcance), y elaborar planes para solucionar o corregir
las mismas.
*" Revisar y aprobar la documentación generada, así como los productos

resultantes, antes de su entrega al Cliente.
Para desempeñar correctamente las funciones anteriores es necesario establecer un

adecuado interfaz entre el equipo de trabajo y su responsable. A través de este interfaz:
•" Se intercambia la información vinculada al proyecto (salvo la de mayor detalle

técnico que, tal vez, pueda intercambiarse directamente entre los miembros del
equipo, sin pasar por el responsable del proyecto).
*" Se asignan, supervisan y corrigen las responsabilidades individuales y las

actuaciones derivadas de ellas.
Se analizan las desviaciones, las incidencias y los conflictos (de cualquier

clase), y se ponen en marcha los mecanismos de corrección oportunos.
Se coordinan los diferentes sub-grupos de trabajo del equipo, y los flujos de

información, responsabilidad y recursos entre ellos.
7.2.3 INTERFAZ CON EL RESPONSABLE DE LA GESTIÓN DEL PROYECTO
Si las funciones de dirección y gestión están separadas en diferentes personas, existe

una interfaz bidireccíonal entre ambas de suma importancia. La información de
gestión es vital para conducir adecuadamente un proyecto, y en especial para
coordinar correctamente al equipo de trabajo. Por otra parte, la información del
director del proyecto es sumamente necesaria para planificar adecuadamente el
proyecto en curso.
7.2.4 INTERFAZ CON LA EMPRESA
El último (pero no menos importante) interfaz a considerar es el que se establece entre

el Director de proyecto y la Empresa (en concreto, la Dirección de la misma). La
Empresa delega en el director de proyecto la responsabilidad de conducir
adecuadamente el mismo, y éste actúa por cuenta y en nombre de la empresa, desde el
punto de vista legal. La situación descrita obliga a establecer un flujo de información
de vital importancia entre el Director de Proyecto y la Dirección de la Empresa. Así:
^ El Director de Proyecto debe recibir frecuentemente consignas estratégicas

para la conducción de los proyectos y el trato con el Cliente. Un proyecto es
un elemento independiente, pero eso no quiere decir que no pueda haber otros
proyectos similares con otros Clientes, u otros proyectos distintos con el
mismo Cliente. La distribución de información táctica y estratégica entre los
Directores de proyecto de la empresa debe tender a incrementar la sinergia
positiva y a mejorar las posibilidades de contratación futura.
*• El Director de Proyecto debe mantener informada a la Dirección de la

Empresa, con toda la información útil acerca del proyecto. Esta información es
la que le sirve a la empresa para perfilar la estrategia comercial futura.
Pero no hay que olvidar que rara vez la Dirección de la Empresa desea involucrarse en
los detalles técnicos de los proyectos en curso. La información que se le pasa, pues,
acerca de los mismos, debe estar razonablemente filtrada para dejar de lado (como
©RA-MA CAPÍTULO 5: SEGUIMIENTO DEL PROYECTO 213
referencia) los aspectos más concretos del trabajo. En general, la información más
importante suele centrarse en los siguientes puntos:
> El proyecto, ¿va bien o va mal? (en el aspecto técnico, económico y de

plazos).
> Si va mal, ¿por qué?
> Las desviaciones detectadas, ¿tendrán un impacto final sobre el
resultado?, ¿de qué tipo, y de qué importancia?
> ¿Cómo pueden corregirse las desviaciones?
> ¿Qué otra información del proyecto puede ser útil para la Dirección de la
Empresa?
7.3 Decisiones, decisiones, decisiones
No podríamos dar por terminado este capítulo sin hacer referencia a una de las
actividades que ocupa gran parte de los recursos de un Director de Proyecto: la toma
de decisiones.
A lo largo del ciclo de vida del proyecto, surge la necesidad de decidir sobre múltiples
aspectos, que condicionan la marcha del proyecto y que, incluso, pueden tener mayor
trascendencia, sobre otros proyectos o sobre la propia empresa.
Desde el punto de vista de su importancia, y de la importancia de las consecuencias de

la misma, las decisiones pueden clasificarse en los mismos niveles en que se
agruparon los grados de responsabilidad en la empresa^6:
> Nivel operativo.

> Nivel táctico.
> Nivel estratégico.
Aunque existen muchos tratados que abordan diferentes teorías de la decisión, en

definitiva no existe una metodología clara que ayude, en todos los casos, a tomar
decisiones fundadas, salvo en aquellos casos en los que existan factores determinantes,
claramente cuantificables.
Es más, en muchos casos no existe una decisión correcta. Ni siquiera cuando el

problema se evalúa a posteriori. Lo que funciona en un caso no tiene garantías de
funcionar en otro parecido, y puede ser totalmente inadecuado para otras situaciones.
Véase el apartado 4.2 del capítulo 1.

También existen las llamadas decisiones por eliminación, que consisten en optar por
la alternativa que menos consecuencias negativas ocasiona.
Por último, en muchos casos la mejor decisión es, simplemente, no decidir, y dejar que
el problema se extinga por sí solo. Un corolario de esta forma de proceder sería aquél
de "si funciona, no lo toques".
Lo que sí es más abordable es la clasificación de las diferentes actitudes a la hora de

tomar decisiones, y que definen, entre otros factores, el estilo de dirección del
responsable del proyecto. Así, cabe distinguir (al menos) entre los siguientes estilos:
El estilo indeciso. La toma de decisiones apoyada en este estilo se caracteriza

por la abdicación de responsabilidades, así como por el desentendimiento de
las consecuencias. Generalmente, este impopular estilo está motivado por una
falta de conocimientos, falta de carácter o personalidad débil, o por el deseo
de evitar conflictos a toda costa. Se confunde frecuentemente con la
ineficiencia, y es poco recomendable, salvo en situaciones en las que existe un
superior muy dominante, al que le conviene la falta de iniciativa de su
subordinado.
El estilo progresivo. El responsable, tras optar por una decisión preliminar, la

hace pública y la somete a la aprobación y a los comentarios de los afectados.
Con la respuesta obtenida modula la decisión tomada, que puede incluso
cambiar radicalmente. Esta metodología de decisión consigue muy buenos
resultados, pues hace uso de las opiniones de todos los implicados, lo que
facilita la aceptación general. Sin embargo, tiene efectos negativos sobre el
líder, pues transmite una sensación de (aparente) inseguridad, que contribuye a
minar su imagen.
El estilo participativo. Consiste en analizar la situación y en tomar las

decisiones oportunas de manera colectiva, reseñando los aspectos clave del
problema y confiando en la participación del grupo, con cuyas aportaciones se
configuran las soluciones más adecuadas. Esta aproximación es
tremendamente eficiente, y consigue decisiones con un alto nivel de consenso
y aceptación, pero sólo si coinciden de manera simultánea varias
circunstancias: alto nivel de formación técnica y personal de todos los
integrantes del equipo de trabajo, estrecha relación entre sus miembros, y
buena motivación a nivel de grupo.
El estilo negociador. Este estilo consiste en dilatar controladamente la toma

de la decisión, hasta contar con la máxima información posible sobre el
problema, hasta haber recabado las opiniones de todos los interesados, o hasta
haber ideado y evaluado todas las posibles alternativas. Desde el punto de
vista teórico es una excelente manera de abordar el problema de la decisión,
salvo por el hecho de que rara vez se dispone del tiempo suficiente para ello.
CAPITULO 5; SEGUIMIENTO DEL PROYECTO 215
El estilo déspota-autoritario. El despotismo es una cualidad no siempre bien

entendida. Ejercida como mero abuso de autoridad, es un desafío a las normas
de convivencia y entendimiento en la sociedad actual. Sin embargo, entendida
como la necesaria capacitación de algunos para decidir en nombre de otros,
por su propio bien, es el concepto de la eficiencia llevado a cabo en el ámbito
social de la decisión. El estilo de decisión déspota conlleva decisiones firmes,
tajantes y claras, muchas veces ignorando las opiniones de los demás. Es ajeno
al concepto de popularidad, y se corresponde con caracteres fuertes y
agresivos (algunos sicólogos, sin embargo, hablan de caracteres débiles e
inseguros). Históricamente asociada a entornos poco evolucionados, funciona
bien sólo en casos muy específicos, en los que exista una fuerte jerarquía, un
gran poder fáctico, y un buen conocimiento del problema. Cuando, además,
existe una clara superioridad intelectual sobre el resto del equipo de trabajo, es
cuando el estilo déspota se convierte en populismo (o, llevado al extremo, en
fanatismo).
LECTURA. ASPECTOS LEGALES Y VALOR CONTRACTUAL DE

LA DOCUMENTACIÓN DEL PROYECTO
El diccionario de la Real Academia Española define un contrato como "el

pacto o conven!©, oral adscrita, entre partes que se obligan sobre materia o cosa
determinada, y a cuyo cumplimiento pueden ser compelidas".
De los contratos dice el Código Civil que las obligaciones (dar, hacer o no hac<
alguna cosa) que de él nacen tienen fuerza de ley entre las partes contratantes,
deben cumplirse al tenor de los mismos, y que son válidos siempre que hay*
consentimiento de los contratantes, que sean sobre objeto cierto, y causa de
obligación que se establezca.
También queda claro en el mismo código que no pueden ser objeto de contrate
las cosas o servicios imposibles.
Cualquier medio es válido para formalizar un contrato, y puede ser éste de tipt
lúblico o privado, sea cual sea el medí® tr\ el que se plasme, y desde
momento que es conocido por las partes contratantes.
Así pues, a la vista de lo anterior, cualquier documento de un proyecto en el qi

se adquieran compromisos por cualquiera de las partes, y que SOR conocido y
aceptado por ellas es, a todos los efectos, uff nuevo contrato que modifica o
complementa el documento-contrato inicial. Se dice que este tipo de
documentos son vinculantes, en el sentías de que, una vez conocidos y
aceptados por las partes, comprometen a su cumplimiento. Son documentos
vinculantes, según este criterio, las minutas de rewnió» aceptadas y firmadas, los
faxes y comunicaciones donde el remitente adquiera algún compromiso y, en

general, cualquier documento aceptado y firmado, sujeto -d las garantías
mínimas que la Ley establece para ellos.
El conflicto surge a la hora de considerar .el medio de transmisión del

documento. Un contrato del que cada parte conserva una copia, o las minutas de
una reunión, debidamente firmadas y distribuidas, no ofrecen ningún problema.
Pero, ¿qué ocurre cuando el meció de transmisión es menos tangible?, ¿qué
ocurre cuando no existe firma manuscrita, o cuando el documento se envía por
medios electrónicos, sin firma o con la firma eseaneada?, ¿y cuando no puede
garantizarse que el destinatario realmente lo na recibido, ni que el documento
recibido sea copia fiel del original? En concreto, ¿qué soporte jurídico tienen los
documentos, que en principio deberían ser vinculantes, pero que se transmiten
fax, por correo ekctfónico/ete.
in general, se reconoce la dificultad jurídica de satisfacer las condiciones de

validei o negociabilidad de un* documento transmitido de forma electrónica, o
dicho de otra manera, las características que debe cumplir el documento
respecto a su valor probatorio..
En el ámbito administrativo, con respecto a los medios de transmisión

electrónicos, informáticos o telemáticos, establece h Ley de Régimen Jurídico
de las Administraciones Públicas y del Procedimiento Administrativo Común
(LRJ-PAC, 3(3/1992)* en su artículo 45.5, que "gozarán de la validez y eficacia
de un documento original .siempre que quede garantizada su autenticidad,
integridad y conservación y, en su caso, la recepción por el interesado".
En "un ámbito más civil y más particular, la referencia tal vez más cercana se
encuentre eriêt artículo 51 dej Código de Comercio, que dispone que "la
correspondencia telegráfica sólo producirá obligación entre los contratantes que
hayan admitido este medio previamente y entxjntrato escrito, y siempre que los
telegramas reúnan las condiciones y signos convencionales que previamente
hayan establecido los contratantes* si asf lo hubiesen pactado". Esta disposición
es, a falta de referencias más concretas, ciertamente susceptible de trasponerse
al ámbito de las comunicaciones vía fax y, con restricciones'7, al del correo
electrónico.
57
En general, derivadas de la necesidad de garantizar, desde el extremo emisor del documento
hasta el receptor, la integridad del contenido (que no haya sido manipulado por el camino), la
no-repudiación (que el remitente pueda negar posteriormente su envío) y la probación (que se
pueda demostrar que el destinatario lo recibió).
Para terminar, visto lo anterior, pueden extraerse las siguientes conclusiones

acerca del carácter vinculante de la documentación del proyecto, así como de la
viabilidad de transferirla por medios electrónicos:
Cualquier documento del. proyecto» formal, conocido y firmado por las

partes, manuscrito o no, es tan vinculante Qomoej contrato original siempre
que presuponga un acuerdo o pacto entré las paites, y sea\ conocido por
éstas (o, al menos, por las que adquieren compromisos).
Desde el punto de vista jurídico, son válidos y aceptables todos los medios
de transmisión, siempre que se pueda demostrar la integridad, no-repudio y
probación de los mismos o, en su defecto, que exista acuerdo de aceptación,
previo y por escrito, de las partes,, de acuerdo con el principio, de autonomía
de las partes contratantes.
Mientras no exista acuerda de .aceptación formal por ambas pa:

conveniente enviar los documentos por correo, afinqúese adelanten
correo electrónico^ u otros medios de mayor eficiencia.
CAPITULO 6
CIERRE DEL PROYECTO
1. INTRODUCCIÓN
Una vez finalizado el proyecto, parece evidente la necesidad de analizar los resultados
y recapitular el curso de los hechos para hacerse una idea clara de los objetivos
cumplidos, de los que no se han alcanzado, y de la utilidad futura, en otros proyectos,
del trabajo realizado.
A grandes rasgos, el cierre de proyecto tiene como objeto principal:
"" Analizar desde la perspectiva económica el resultado del proyecto, es decir,

hacer balance de los recursos consumidos y los beneficios alcanzados.
^ Diagnosticar el funcionamiento de la empresa, identificando las desviaciones

entre el resultado y las previsiones iniciales, y encontrando las razones de
dichas desviaciones.
*■ Corregir, para futuros proyectos, las actuaciones inadecuadas, que dieron

lugar a las desviaciones anteriores.
Y como objetivos secundarios:

Consolidar como parte del "saber hacer"38 de la empresa los resultados

técnicos del proyecto, incluyendo los conocimientos adquiridos, la tecnologia
utilizada, la documentación y los productos desarrollados, etc.
Identificar las nuevas oportunidades comerciales nacidas de la ejecución del

proyecto recién terminado, y organizar las actividades comerciales precisas
para dar continuidad, mediante nuevos contratos, al proyecto anterior.
2. ACEPTACIÓN
Como es lógico, el proyecto no puede darse por terminado hasta que el Cliente revise
y acepte el resultado del mismo. Tanto si el resultado del proyecto es un documento,
un producto o, tal vez, algo tan intangible como una consultoría técnica, la aceptación
del Cliente es condición imprescindible para dar por concluido el trabajo.
Y esto nos lleva a la situación de conflicto típica de los proyectos mal especificados.
Cuando existe ambigüedad en la especificación del resultado de un proyecto, al final
resulta difícil determinar si la insatisfacción del Cliente se debe o no a una falta de
adecuación del producto a lo contractualmente establecido. Pongamos un ejemplo
trivial: cuando un individuo encarga una obra en su vivienda, es normal que
especifique claramente el tipo de pintura, lisa, papel, estuco, etc.) y color de
terminación de las paredes. Si al terminar la obra el acabado no es acorde con lo
inicialmente establecido, no se aceptará el trabajo y, previsiblemente, no se pagará
hasta que no se subsane el "error".
Pero pongamos, ahora, que el Cliente olvidó especificar, por ejemplo, el tipo de
pintura. El contratista puede dar por sentado que, al estar de moda, el acabado más
lógico es gotelet. Con su mejor intención puede terminar así las paredes, pintándolas
en el color elegido por el Cliente. Cuando éste ve el resultado de la obra puede sentirse
insatisfecho con el resultado. ¿De quién es la responsabilidad?, ¿del Cliente, por no
especificar, o del contratista, por no aclarar la ambigüedad?
fin de evitar ambigüedades que se propagan hasta el momento de la

•jeptación del trabajo, cada requisito individual del proyecto debe."quedar claro
de comenzar el proyectóla ser posible, plasmado en algún xk.
Supongamos que todos los requisitos del proyecto quedaron, en su momento,

definidos y redactados en una especificación de requisitos del trabajo. Aun así, el
Cliente tiene que revisar el resultado (es decir, verificar que está acorde con dichos
CAPÍTULO 6: C1KRRE DBL PROYECTO 221
requisitos) y aceptarlo formalmente, como paso previo a dar por terminado el proyecto
y proceder a emitir las facturas correspondientes.
La figura 6.1 muestra un posible formato de aceptación de los trabajos, que puede
redactarse y remitirse al Cliente al final del trabajo, o en hitos intermedios del
proyecto.
Por el Cliente: Por el Contratista:
Fdo. : Fdo. :
Fecha : Fecha :
I 1( I I I ito : Porra ato Acta de Ui-
Figura 6.1 Formato de aceptación parcial/final de los trabajos

Con la firma del documento de aceptación, en Cuente certifica que ha revisado los
trabajos presentados, y que está conforme con ellos.
En caso de que el Cliente rechace el producto o servicio resultado del proyecto, se le

deberá pedir que formalice por escrito sus objeciones, con el fin de documentar el
motivo de la disconformidad, y que pueda ser utilizado para las actuaciones
correctivas necesarias (o, en última instancia, para dirimir el conflicto en los
tribunales).
3. INFORME DE CIERRE DE PROYECTO
El informe de cierre es, en teoría, la última documentación del proyecto generada. Es

como una "foto de fin de curso", en la que se aprecia bien quién ha terminado y quién
no (además, por las caras de la gente uno puede llegar incluso a intuir si el curso fue
bueno órnalo).
El objetivo de un informe de cierre es evaluar el resultado de los trabajos, y resumir

todo lo sucedido durante el proyecto que pueda ser de cierta relevancia para
actividades futuras de la empresa. Contiene, básicamente, la información necesaria
para saber si el proyecto obtuvo los resultados previstos y, en caso contrario, las
razones de ello.
Pero los informes de cierre de proyecto tienen, además, otras utilidades no menos
importantes para la empresa, que trascienden más allá del proyecto recién acabado,
algunas de las cuales se reseñan a continuación:
> Detectar errores sistemáticos en los presupuestos de los proyectos y

ofertas.
> Analizar la tendencia histórica de los proyectos gestionados por cada
responsable.
> Analizar la tendencia fiistórica de los proyectos contratados con cada
Cliente.
> Establecer nuevas estrategias para abordar mercados clásicos o
emergentes.
El documento de cierre de proyecto siempre se hace tomando como referencia las

previsiones que, en su día, se realizaron durante la preparación de la oferta de gestión.
Se comparan los recursos invertidos con los previstos al comienzo, teniendo en cuenta
los posibles cambios admitidos durante la ejecución del proyecto. Lo mismo se hace
con la facturación, obteniéndose una imagen clara de las desviaciones entre valores
previstos y reales.
CAPITULO 6: CIERRE DEL PROYECTO 223
Un error habitual es gestionar los proyectos de manera tal que se persiga

prioritariamente mejorar los beneficios en un principio previstos. Así da la sensación
de que el Director del proyecto lo ha hecho mejor de lo esperado. Sin embargo, un
proyecto bien gestionado es aquel en el que las desviaciones con respecto a las
previsiones iniciales son mínimas. Incluso cuando dichas desviaciones son favorables
a la empresa (mayor beneficio del esperado) debe saltar la alarma pues, en general, el
beneficio extra no se suele lograr salvo que:
«* La estimación en el presupuesto inicial fuese excesivamente conservadora, lo

que podría haber ocasionado la pérdida del contrato en favor de la
competencia.
^ Se exijan sobre-esfuerzos al personal (horas extra no retribuidas ni

contabilizadas), que minan el rendimiento posterior o la satisfacción de las
personas.
^ Se ahorre en materiales y equipos o en la calidad (experiencia) del personal '

utilizado, poniendo en peligro la calidad del trabajo final y, por tanto, la
posibilidad de lograr futuros contratos con ése u otros Clientes.
La documentación de cierre, en general, se compondrá de
> El balance de ingresos y gastos.

> Los informes de situación finales.
> La lista de documentación generada.
> La lista de productos generados.
> Otros, en función de la empresa y del proyecto concreto.
3.1 Balance de ingresos y gastos
El balance de ingresos y gastos es, conceptualmente, muy similar al formato de avance

económico que se mostró en el capítulo 5 (seguimiento del proyecto).
La Figura 6.2 muestra un posible formato para el balance de ingresos y gastos del
proyecto.
59
Como siempre, dependiendo del volumen y del tipo de proyecto, la documentación de cierre
será más o menos formal (a veces un informe verbal basta) y más o menos detallada y
voluminosa.
Figura 6.2 Balance de ingresos y gastos para el cierre del proyecto
En el formato anterior, se rellenan los campos sombreados con los datos de cierre del
proyecto, (fundamentalmente horas, gastos e ingresos por facturación), y el propio
formato calcula (de manera automática) las desviaciones con respecto a la estimación
del presupuesto del proyecto. El signo de cada celda se interpreta como sigue:
> Los valores negativos indican (salvo en el capítulo de ingresos y margen,

por razones obvias) ahorro para el proyecto (incremento del beneficio).
> Los valores positivos indican gastos superiores a los previstos (reducción
del beneficio).
© RA-MA CAPITULO 6: CIERRE DEL PROYECTO 225
De los datos mostrados en la figura 6.1 pueden extraerse las siguientes conclusiones:
> El proyecto, sin modificar la facturación, ha requerido para su

realización, un mes más de lo previsto (y comenzó con un mes de retraso)
y ha utilizado 15 horas más de las inicialmente estimadas.
> Sin embargo, el ahorro de costes en otros conceptos ha reducido el coste
total del proyecto en 1.399 € (un 4,4%).
> Por tanto, a igualdad de ingresos, el margen bruto ha aumentado del
20,1% previsto a un 25,7%.
Conviene hacer una consideración que, por evidente, no es menos olvidada: al realizar
el balance anterior, hay que asegurarse de tener en cuenta todos los ingresos y los
gastos en los que se ha incurrido, incluso cuando aún no hayan sido contablemente
imputados. Así, por ejemplo, no hay que olvidar contabilizar:
■»" Las facturas libradas al Cliente, pero aún no cobradas.
&~ Los gastos en los que se haya incurrido, aún cuando todavía no nos hayan sido
facturados o cobrados (por ejemplo, al adquirir suministros, es frecuente que
la forma de pago sea a 90 días). Si el cierre se ha realizado entre ambas fechas,
de facturación y cobro, hay que asegurarse de imputar dichos gastos
pendientes.
3.2 Resumen de cierre de proyecto
La utilidad del balance de ingresos y gastos es evidente. Sin embargo, su nivel de

detalle es excesivo para un análisis externo, general, del resultado del proyecto.
Por esta razón, a menudo se extractan los resultados básicos del proyecto, que se
presentan, resumidos y explicados, a los superiores de la empresa.
El resumen contable del balance de ingresos y gastos suele recibir el nombre de

informe económico, mientras que a la explicación del mismo, junto con los factores
que han motivado el desenlace del proyecto, se le conoce como informe de situación
final.
3.2.1 INFORME ECONÓMICO
Como ya se ha dicho, el informe económico de cierre resume los datos contables más
significativos del proyecto, y permite a una persona ajena al mismo, de un vistazo,
hacerse una idea general del resultado (sin entrar en detalles de cada concepto
contable, e ignorando los aspectos asociados al alcance y a la planificación temporal).
Cumplimentar este tipo de informes no exime de la necesidad de elaborar, también, el
balance detallado de ingresos y gastos, que es el que contiene, realmente, toda la
información detallada del cierre.
La figura 6.3 muestra un posible formato para el informe económico de cierre.
3.2.2 INFORME DE SITUACIÓN FINAL
El informe de situación final es a la documentación de cierre lo que el resumen de

reunión6'' era a la propia reunión: una descripción general, en lenguaje no técnico, y
para todo tipo de lectores (ligados o no al proyecto) del ciclo de vida del proyecto,
desde la adjudicación del mismo hasta su cierre contable.
El informe de situación final debe contener, además de los datos básicos del proyecto
(nombre, responsable, duración, presupuesto, etc.), una descripción general de los
Véase el capítulo 5, Seguimiento del proyecto.

© RA-MA CAPITULO 6: CIERRE DEL PROYECTO 227
hechos más significativos del mismo: modificaciones al alcance de los trabajos,

dificultades encontradas, medidas adoptadas para resolverlas, relaciones con terceras
partes (clientes potenciales, proveedores, etc.), posibles acciones futuras (dentro o
fuera del proyecto) y, en general, cualquier otra información de interés sobre los
trabajos recientemente concluidos.
La figura 6.4 muestra un posible formato para la elaboración de informes de situación

final.
Informe de situación
NOMBRE DEL PROYECTO Intermedio
Final
PROYECTO/PT: CLIENTE :
TITULO :
RESPONSABLE :
FECHA COMIENZO: TERMINADO:
TRABAJO REALIZADO. ALTERACIONES AL ALCANCE PREVISTO
DIFICULTADES ENCONTRADAS
OTROS COMENTARIOS
RESUMEN DEL ESTADO :

Modificaciones al alcance Si No Descripción
Retrasos
Incremento del riesgo
Sobrecoste
Insatisfacción del Cliente
Ampliaciones al contrato
Carencia de recursos
Conflictos in te rpe rso n a les
Falta de formación/experiencia
I K l l i K l ) : Formulo Informo Sitiiiu-ion Himl.d.
Figura 6.4 Formato de informe de situación final

Al igual que sucedía con los resúmenes de reunión, es conveniente confeccionar

informes de situación asépticos y poco emocionales, ya que trascienden a la propia
vida del proyecto, y no es bueno volcar en ellos percepciones personales, muy ligadas
a la tarea cotidiana, que carecerán de sentido una vez terminado el trabajo.
Por último, cuando el proyecto tiene una duración muy dilatada en el tiempo, o cuando
su complejidad obliga a delegar responsabilidades de dirección y gestión entre varias
personas, es habitual redactar informes de situación intermedios, coincidiendo con
hitos temporales (reuniones de progreso, finalización de fases intermedias, etc.), para
cada parte o paquete de trabajo del proyecto en cuestión, aunque aún no se hayan
terminado por completo.
3.3 Tratamiento de la documentación generada
La documentación generada y obtenida durante el ciclo de vida de un proyecto es de

trascendental valor para la empresa, pues es la fuente de conocimiento y la experiencia
última adquirida para futuros proyectos relacionados con el anterior.
Una de las razones más poderosas que un Cliente puede tener para contratar a una
empresa determinada es la experiencia en trabajos similares. Sin embargo, puede que
en el momento de la nueva contratación las personas que llevaron a cabo aquellos
proyectos de parecido contenido se dediquen a otras actividades o, simplemente, ya no
figuren en la nómina de la empresa.
Sin embargo, la experiencia y el saber hacer (know-how) de la empresa debe

prevalecer sobre la dinámica de idas y venidas de las personas que en ella trabajan.
Este punto de vista es el que justifica una política interna rigurosa para el tratamiento
de la información y los productos generados dentro de un proyecto, como fuente de
experiencia para la empresa en general.
Veamos un ejemplo extremo: Caos Consulting (nuestra empresa modelo) consigue y

ejecuta el contrato para la implantación de la red de área local y de pedidos de Flores
del Sur (ver capítulo 3). Uno año después de finalizar el trabajo, Flores del Sur solicita
que se amplíe la aplicación para la gestión de stocks, u otra empresa pide una
aplicación similar a la desarrollada en su día para Flores del Sur. Supongamos que los
responsables del primer trabajo han sido promocionados a puestos de mayor
responsabilidad, o que han abandonado la empresa. La experiencia obtenida no se
habrá capitalizado (y no servirá para ser más competitivos en calidad, plazo o precio)
salvo que se hayan conservado, cuidadosamente documentados:
> Los diseños hardware y software del sistema.

> Los códigos fuente y ejecutable de la aplicación.
> Otra documentación específica del proyecto.
CAPÍTULO 6: CIERRE DEL PROYECTO 229
Los procedimientos de tratamiento de la información interna de la empresa deben estar

orientados a tres aspectos complementarios:
 Propiciar la conservación de la documentación generada u obtenida en los

proyectos, y difusión de su existencia entre los empleados para que pueda ser
utilizada y aprovechada en otros proyectos.
 Propiciar la conservación de los productos (diseños, prototipos, maquetas,

etc.) generados u obtenidos en los proyectos, y difusión de su existencia entre
los empleados para que puedan ser utilizados y aprovechados en otros
proyectos.
^ Asegurar su correcta custodia, de manera que su contenido no se filtre a

posibles competidores en el sector, pudiendo minorar o anular las posibles
ventajas competitivas de la empresa.
En principio, es necesario conservar y custodiar, con carácter indefinido:
> La documentación interna del proyecto (minutas, informes de reunión,

previsiones económicas, etc.).
> La documentación generada dentro del ámbito del proyecto.
> La documentación obtenida de terceros (Clientes, proveedores,
bibliografía, etc.).
> La descripción detallada de los productos generados, incluyendo, si es
menester, diseños, planos, descripción de cambios, manuales de usuario,
etc.
Por último, parece adecuado insistir en un aspecto al que no se le suele dar suficiente
importancia en algunas organizaciones: la conveniencia y necesidad de difundir la lista
de información y documentación disponible entre los empleados de la empresa a los
que pueda resultar de utilidad. Muy a menudo, dentro de los proyectos se desperdicia
una cantidad significativa de tiempo obteniendo información de la que ya se dispone
en la empresa. Los empleados, ignorantes de la existencia de la misma, proceden a
obtenerla por otros medios, invirtiendo esfuerzo y dinero, porque no existe un
procedimiento reglado y conocido para identificar la información de la que se dispone.
230 DIRECCIÓN Y GESTIÓN DE PROYECTOS S5 RA-MA
4. INDICADORES OBJETIVOS DEL RESULTADO

DEL PROYECTO
Lo más probable es que la documentación de cierre de un proyecto se curse, de oficio,

a los responsables de la empresa, quienes la analizarán para evaluar la marcha de los
proyectos, identificar patrones de consumo, futuras oportunidades de negocio y, por
qué no, para valorar los resultados de los responsables de los proyectos.
Incluso si el proyecto lo ejecuta una única persona, trabajando como profesional

liberal, es lógico pensar que él mismo querrá analizar dicha información, como mejor
forma de evaluar el trabajo realizado.
A la hora de analizar los resultados de un proyecto, la multitud de aspectos concretos

que se habrán producido dentro del ámbito del mismo (el alcance técnico, las
relaciones con terceros, los problemas surgidos, etc.) puede oscurecer los resultados
finales. Por esta razón, es conveniente definir un conjunto de parámetros objetivos que
sirvan para evaluar el proyecto en sí, así como para comparar dicho proyecto con otros
realizados por la empresa o, incluso, con otros similares efectuados por empresas de la
competencia (aunque rara vez se dispondrá de información real para este tipo de
comparaciones cruzadas).
A continuación se reseñan algunos de los indicadores objetivos más habitualmente

utilizados para evaluar proyectos.
4.1 Indicadores económicos de primer orden
Como su propio nombre indica, estos indicadores son los valores numéricos más
significativos que resultan al realizar el cierre contable del proyecto. Entre ellos se
incluyen los siguientes:
■*" Facturación del proyecto. Es un indicador del volumen del proyecto, cuya
principal utilidad es servir de referencia a la hora de evaluar otros parámetros
tales como el esfuerzo, los costes y gastos, el margen, etc.
*" Margen del proyecto. Tal y como se indicó en apartado 1.3 del capítulo 1, el
margen de un proyecto se define como la diferencia entre los ingresos y los
costes asociados a la realización del mismo, tanto en valor absoluto como en
porcentaje referido al precio de venta del proyecto.
*" Beneficio del proyecto. Como también se indicó en el capítulo 1, el beneficio

de un proyecto es el margen obtenido, una vez restados los costes de
oportunidad del capital material y humano utilizado para llevar a cabo los
trabajos. Como el coste de oportunidad es rara vez un factor absoluto y

objetivo, suele utilizarse como referencia (a falta de otra mejor) de coste de
oportunidad el valor del IPC (índice de Precios de Consumo), el precio oficial
del dinero, etc.
Coste por hora trabajada. Este indicador se calcula como la distribución de

los costes del proyecto entre las horas de esfuerzo dedicadas al mismo, una
vez detraídas las cantidades correspondientes al trabajo ajeno
(subcontrataciones) y a gastos en materiales y equipos (suministros), así como
el importe reservado para las contingencias de ambos apartados
(subcontrataciones y suministros). El valor resultante da una idea del coste
global que supone cada hora de trabajo dedicada al proyecto.
Tomemos, por ejemplo, el balance de ingresos y gastos del proyecto mostrado

en la figura 6.2. El valor del coste por hora trabajada, según los datos previstos
al comienzo del proyecto, sería de:
31.452 - 7.500 ■ (l + 0,08) - 7.500 ■ (1 + 0,03) ,„, „

Coste hora = ----------------- L - ----------------------------- = 69,1 Euros i hora
226
Mientras que, el valor anterior, referido ahora a los resultados reales del
proyecto, sería de:
30.054-7.800-(l+0,08)-6.870-(l+0,03) „A „
Coste hora =
---------- ——i—— ---- —— ----------------- = 60,4 Euros I hora
241
Precio de venta de la hora trabajada. Este indicador es conceptual mente

similar al de coste por hora trabajada, pero referido ahora a la facturación del
proyecto. Se calcula detrayendo de la facturación (sin impuestos) el valor de
las partidas de subcontrataciones y suministros, junto con sus respectivas
contingencias y beneficio medio. El valor resultante se divide entre el número
de horas de trabajo, y da una idea acerca del precio unitario al que debería
venderse la hora de trabajo, para obtenerse rentabilidades similares a las del
proyecto bajo análisis.
Así, por ejemplo, el precio de venta equivalente por hora del proyecto de la
figura 6.2 sería de 165,1 € en la estimación inicial, y de 149,7 € al final del
proyecto. Esto quiere decir que si se facturase directamente al Cliente por hora
trabajada en un proyecto de este tipo, se le tendría que cobrar 149,7 € por hora
para absorber los costes laborales, generales y gastos varios (informáticos,
consumibles, viajes y estancias, etc.), y así obtener el mismo margen que en la
facturación a precio fijo.
Componentes del coste del proyecto. Estos indicadores muestran la

importancia de cada partida de costes dentro del proyecto, y dan una idea
232 DIRECCIÓN Y GESTIÓN DE PROYECTOS €> RA-MA
acerca del tipo de proyecto y sus riesgos inherentes. A modo de ejemplo, se

utilizan con frecuencia los siguientes indicadores:
> Valor relativo del esfuerzo propio. Se calcula como el porcentaje del
coste total del proyecto que se destina a horas de esfuerzo del personal de
la empresa. Cuando este indicador es alto, el proyecto "vende",
fundamentalmente, horas de trabajo, que se supone implican un alto valor
añadido. En el proyecto de la figura 6.2, el esfuerzo propio representa el
29% del coste del proyecto, en la estimación, y el 32% en el momento del
cierre contable.
> Valor relativo de las subcon tratación es. Se calcula como el porcentaje
del coste total del proyecto que se destina a subcontrataciones
(incluyendo las contingencias para dicha partida). Un valor
excesivamente alto supone que la empresa es un mero intermediario (un
agente de contratación) entre el Cliente y terceros, y suele implicar un
cierto riesgo, al depender (la propia empresa) del trabajo de otros,
fundamentalmente, para cumplir con sus compromisos. En el proyecto de
la figura 6.2, el valor de las subcontrataciones asciende al 28% del coste
del proyecto (valor de cierre).
y Valor relativo de los suministros. Se calcula como el porcentaje del
coste total del proyecto que se destina a suministros (incluyendo las
contingencias para dicha partida). Un valor excesivamente alto convierte
a la empresa (en general) en un proveedor de bienes intermediario, lo que
(a diferencia del caso anterior) no siempre supone un excesivo riesgo. En
el proyecto de la figura 6.2, el valor de los suministros constituye al cierre
el 24% del coste del proyecto.
4.2 Indicadores financieros
Los indicadores financieros hacen referencia al origen de los fondos utilizados para
lograr los fines del proyecto, así como a la proyección en el tiempo de los mismos.
Estos aspectos atañen no sólo a la financiación del proyecto, síno directamente
también a la de la propia empresa, por lo que deben ser especialmente tenidos en
cuenta. A continuación se describen algunos de los indicadores financieros más
comunes:
Porcentaje de endeudamiento externo. Supongamos que la empresa no

percibe ningún ingreso hasta terminar el proyecto. En estas condiciones, la
empresa ha de financiar, con fondos propios, la mano de obra, equipos y
subcontrataciones necesarias para llevar a cabo ¡os trabajos. Esta financiación
no sólo supone un riesgo para la empresa (caso, por ejemplo, de no llegar a
cobrar por los trabajos realizados), sino que impone unos costes financieros,
cuya naturaleza ya quedó expuesta en la lectura del capítulo 2.
El porcentaje de endeudamiento externo (con ajenos) hace referencia al
montante de ese riesgo que, caso de impago, la empresa tendría que satisfacer
a otros, como deudas contraídas directamente por la empresa. Este valor se
calcula como el porcentaje de los gastos del proyecto destinados a
subcontrataciones, suministros (material y equipos), viajes y gastos varios.
Así, en el ejemplo de la figura 6.2, el valor de esta partida, referido al
presupuesto inicial del proyecto (valor estimado), sería de:
7.500 + 7.500 + 900 + 4.500

End externo = = 64,9%
31.452
Mientras que, referido a la conclusión de los trabajos (valor real), sería de:
7.800 + 6.870 + 486 + 4.163 .'

Lna externo = — ------------------------------- = 64,3%
30-054
Porcentaje de endeudamiento interno. El endeudamiento interno (o propio)

tiene en cuenta el porcentaje de los gastos que, en caso de impago, la empresa
habría de "satisfacerse a sí misma", y se calcula como el valor
complementario del porcentaje de financiación externo. En la figura 6.2, este
indicador toma el valor de 35,1% en el presupuesto inicial, y del 35,7% al
cierre del proyecto.
Valor actual neto del proyecto. Este indicador toma todos los flujos
monetarios referidos al instante en el que se producen, y calcula el valor
actualizado, al momento de cierre del proyecto, según la fórmula:
Donde F¡ es cada uno de los flujos monetarios (ingresos y gastos) del proyecto,
n es el número de años (o meses) transcurridos desde que se produjo el flujo
monetario, y r es la inflación anual (mensual), acumulada, desde entonces.
Tasa de rendimiento interno del proyecto. La tasa de rendimiento interno

del proyecto (o, simplemente, el rendimiento del proyecto) tiene en cuenta el
tiempo y el dinero que ha sido necesario invertir para obtener el margen
comercial del proyecto. Este indicador se calcula distribuyendo el margen del
proyecto entre el tiempo necesario para obtenerlo, según se indica a
continuación:
Ingresos - Costes _ Margen

r=
Costes ■ Tiempo Tiempo
Así, por ejemplo, un proyecto que con unos costes de 100 unidades monetarias
es capaz de obtener unos ingresos de 125 unidades, habrá obtenido un margen
del 25%. Sin embargo, el rendimiento del proyecto dependerá del tiempo
necesario para obtener dicho margen. Si el proyecto se llevó a cabo en seis
meses, el rendimiento r sería del 50% anual, mientras que si se invirtieron 5
años en completarlo, el valor de r disminuiría hasta un reducido 5% anual.
Nótese que el margen porcentual sólo coincide con el rendimiento cuando el
ciclo de producción completo es de un año.
El valor del rendimiento es muy útil a la hora de comparar el margen del

proyecto con el coste de oportunidad del capital invertido en el mismo. En
general, un proyecto será tanto más rentable cuanto mayor sea el valor de la
tasa de rendimiento del mismo y, en particular, cuanto mayor sea con respecto
al coste de oportunidad más accesible (un proyecto alternativo, una inversión
concreta o, en ausencia de otros valores, el tipo de interés del mercado de
capitales).
¿Y a qué se debe lo anterior? Veamos. Si en el mercado de capitales el tipo de

interés oscila en torno al 5%, el empresario puede obtener ese rendimiento sin
más que colocar su dinero en simples depósitos bancarios, sin asumir riesgos
ni dedicar esfuerzo a ello. Incluso, invirtiendo correctamente dicho capital
(por ejemplo, en Bolsa, o en el mercado inmobiliario), podrá obtener
rendimientos superiores. Salvo que el rendimiento medio de los proyectos sea
muy superior al tipo de interés, parece dudoso que el empresario decida
embarcarse en la complejidad y el riesgo que supone crear y gestionar una
empresa.
4.3 Indicadores de ocupación laboral
Las empresas que suman cierto valor añadido a los productos que venden (es decir,
todas, salvo los intermediarios que se limitan a revender tal cual los productos
comprados a otros productores basan su margen comercial en el trabajo de sus
empleados, que puede cuantifícarse mediante el esfuerzo (número de jornadas
laborales u horas de trabajo) que dedican a cada producto. Por esta razón, el principal
capital de este tipo de empresas es su propio personal.
En estas condiciones, mantener al personal de la empresa "ocupado" en proyectos es

vital para obtener beneficios. El personal inactivo no genera rendimientos y, peor aún,
ocasiona gastos.
CAPÍTULO 6: CIERRE DEL PROYECTO 235
Los indicadores de ocupación tienen como objeto dar una idea clara y objetiva de
cuántas personas hacen (o han hecho) falta para realizar el trabajo, y cuál será su
dedicación al mismo.
Los indicadores de ocupación tienen diferentes utilidades, entre las que cabe citar las
siguientes:
> Determinar el número de personas que hay (o que hubo) que "reservar"
para un proyecto.
> Determinar, en conjunto con los demás proyectos de la empresa, cuál es
el índice de ocupación del personal de la empresa (porcentaje de los
trabajadores que realmente están trabajando en proyectos).
> Ayudar a definir la política de personal de la empresa, cuantifícando el
número de trabajadores que, previsiblemente, faltan o sobran en la
plantilla.
El indicador de ocupación laboral más significativo es la carga de trabajo. Este valor

indica el número de horas de trabajo, de una determinada categoría, que harían falta
para completar un trabajo concreto.
Sumadas las cargas de trabajo de toda una categoría, a lo largo de un intervalo de

tiempo determinado, y dividido por el número de horas de trabajo hábiles en dicho
período, se obtiene el número de personas necesarias para el proyecto o para la
empresa.
Por último, dividiendo la carga de trabajo (individual o colectiva) de un período, por el

número de horas de trabajo hábiles del mismo, se obtiene el índice de ocupación.
Veamos un ejemplo: para un proyecto concreto, de 3 rneses de duración (480 horas

laborables disponibles), se identifican 4 tareas, que requieren, respectivamente, cargas
de trabajo de 180, 240, 420 y 700 horas.
Las cuatro actividades en conjunto requieren 1.540 horas de trabajo, por lo que, en
principio, harían falta un mínimo de 3,2 personas (valor resultante de dividir 1.540
entre 160 horas mensuales, y 3 meses de duración).
Supongamos ahora que la persona A se encarga, exclusivamente, de las tareas uno y

dos, para lo que necesita 420 horas (180 más 240). Su índice de ocupación individual
será del 87,5% (valor resultante de dividir las 420 horas entre las 480 que hay
disponibles en tres meses).
Análogamente, si los empleados B y C se ocupan de las tareas tres y cuatro, sus

índices de ocupación serían del 87,5%, y del 146%, respectivamente. En este último
caso, al ser el índice de ocupación superior al 100%, queda claro que el trabajador C
no puede, por sí solo, hacerse cargo de la actividad completa, y habrá de dejar parte de
la misma (el 46%, al menos), en manos de otra persona.
4.4 Indicadores de gestión
Para terminar el apartado dedicado a los indicadores objetivos, no pueden dejarse de

lado los valores que denotan, grosso modo, cómo de acertada ha sido la gestión de los
trabajos, y la respuesta del equipo de trabajo.
Evidentemente, la calidad del equipo de trabajo y el acierto del responsable del

proyecto se mide teniendo en cuenta múltiples factores objetivos y subjetivos (entre
ellos, el nivel de satisfacción del Cliente, el nivel de conflictividad del proyecto, etc.).
No obstante, conviene no perder de vista los valores objetivos que, al igual que el
resultado en goles de un partido de fútbol, es lo que, en definitiva, se puede medir con
mayor facilidad.
Entre tales factores objetivos cabe citar las desviaciones entre los valores previstos al
presupuestar el proyecto, y los valores finales, tras la terminación y cierre del mismo
y, en concreto, las desviaciones correspondientes a:
> Plazo de ejecución del contrato.

> Coste (global y por partidas).
> Margen.
> Contingencias.
Para terminar, la figura 6.5 muestra un compendio de indicadores del proyecto

ejemplo mostrado en la figura 6.2, obtenidos mediante el formato de cierre contable
del mismo.
Figura 6.5 Indicadores económicos del proyecto
Como puede apreciarse, en dicho compendio:
> No aparecen las desviaciones, que ya se calculan en el propio informe de

cierre contable (columna de la derecha del informe de la figura 6.2).
> En general, los indicadores financieros que requieren conocer el flujo
económico no aparecen reflejados, ya que requieren conocer el momento
preciso en el que se produjeron (información que no está disponible ni en
los formatos de presupuesto, ni en los de cierre). Dicha información sí
podría extraerse, sin embargo, de los informes de avance económico del
proyecto.
Del análisis del compendio anterior podrían extraerse varias conclusiones. Algunas de
ellas serían:
"> Se han visto reducidos, con respecto al valor inicialmente estimado, el

precio de venta y el margen por hora trabajada. La causa principal para
ello fue la necesidad de destinar 15 horas más de las inicialmente
previstas para realizar los trabajos, sin que la facturación se viese
incrementada.
> Gracias a la reducción de costes, se ha enjugado el coste adicional debido
al incremento de horas, y el balance final es positivo para el proyecto,
disminuyendo el coste por hora trabajada con respecto a la evaluación
inicial.
> El proyecto no implica una fuerte carga de trabajo para la empresa, ni una
dedicación constante de los miembros del equipo de trabajo. La larga
duración del proyecto (12 meses) comparada con el bajo número de horas
previstas (226) hace que la media de ocupación sea de 0,118 personas.
Este valor es poco realista, y sólo se entiende si, a lo largo de los 12
meses, hay mucho tiempo intermedio de inactividad.
Sólo el 35% de los recursos consumidos son internos de la empresa, lo
que indica un elevado componente (65%) de endeudamiento externo.
Esto es a la vez bueno y malo: las desviaciones en la carga de trabajo
(como, por ejemplo, las 15 horas adicionales) afectaron poco al resultado
del proyecto. Pero, por otro lado, el 65% de los recursos van destinados a
terceros, lo que deja poco valor añadido en la empresa, y aumenta el
riesgo de descubierto ante impagos del Cliente.
EPILOGO
LA GESTIÓN EN EL TERCER MILENIO
Compendiar el contenido de este texto, que con este capítulo llega a su fin (apéndices
aparte, claro está), no ha sido sólo una magnífica oportunidad para formalizar
conocimientos y herramientas de diferentes fuentes, propósitos y naturaleza, sino
también un aliciente para meditar acerca de cómo el ser humano ha sido capaz, a lo
largo del tiempo, de consolidar técnicas y procedimientos para hacer más efectivo y
más eficiente su esfuerzo.
Por otra parte, la primera edición de este libro vio la luz a las puertas del ya manido
tercer milenio6'', y si bien este hecho no influyó en absoluto sobre las técnicas de
gestión y dirección de proyectos, no es menos verdad que fue aliciente para infinitas
sesiones de meditación (y divagación) sobre los asuntos más dispares que cabría
imaginar. No ha sido esta obra ajena a tan saludable práctica.
Algunos antecedentes
Las técnicas de dirección y gestión son tan antiguas como el hombre. La aparición de
la inteligencia durante los primeros estadios de evolución de la raza humana dio lugar
a nuevas actividades, algunas derivadas de prácticas de supervivencia (la caza, o la
lucha), y otras nacidas de las nuevas inquietudes de una actividad intelectual incipiente
(la agricultura, la ganadería o la construcción de refugios, entre otros).
Nos dicen los antropólogos que las primeras formas de organización nacieron con
estas actividades. De forma gregaria o aislada, el hombre pronto aprendió que la
correcta administración de los recursos significaba mejorar los resultados con el
mismo esfuerzo y, en consecuencia, vivir mejor.
61
Discusiones aparte acerca de si dicho milenio comenzó un año antes o un año después.
Las primeras civilizaciones "históricas" impulsaron el avance de las técnicas de

administración de recursos, gracias a los procedimientos de aprendizaje que ya no se
basaban en la mera transmisión de padres a hijos, sino que contaban con el apoyo de la
escritura (herramienta básica, por otra parte, para el desarrollo de las técnicas
analíticas y cuantitativas más básicas). Además, el esplendor de alguna de estas
civilizaciones indujo a acometer obras y campañas militares de gran envergadura cuya
realización sólo fue posible gracias a la depuración de primitivas técnicas de gestión
(bueno, y también a la economía de medios que suponía contar con miles de obreros
esclavos, de "bajo consumo" y sin derechos sindicados).
Así, aparte de los rudimentarios sistemas de gestión del antiguo Egipto (el de los
faraones), una de las primeras reseñas formales de técnicas de gestión se encuentra en
Siracusa, durante el siglo III antes de nuestra era, cuando el buen Arquímedes
desarrolló métodos cuantitativos aplicados a la gestión de procesos, como casi siempre
orientados a las artes de la guerra. También los romanos desarrollaron algunas técnicas
de interés, aunque estos "chicos mediterráneos" jamás llegaron a mostrar en esta
disciplina la brillantez que en sus conquistas militares.
Como en casi todas las demás artes y ciencias, tampoco la Edad Media fue ejemplo a
seguir en cuanto al desarrollo de la materia, y hubo que esperar a la revolución
industrial, en pleno siglo XIX, para que los avances en las teorías matemáticas del
Renacimiento se trasladasen a unos entornos de producción radicalmente distintos a
los existentes hasta ese momento, donde la eficiencia comenzó a ser factor
determinante para la supervivencia de las organizaciones.
El siglo XX
Las guerras mundiales impulsaron, como casi todos los conflictos bélicos modernos,
las disciplinas relativas a la optimización de resultados con los mínimos recursos a
poner en juego (o sea, máximas bajas al enemigo con las mínimas pérdidas propias).
En concreto, la Segunda Guerra Mundial fue el motor de un gran avance en el
desarrollo de las técnicas de investigación operativa, de control y organización de
procesos y de decisión, que tan útiles son hoy en día para la gestión de procesos
productivos.
Más tarde, en plena guerra fría, comenzaron a acometerse proyectos ""faraónicos" para
la construcción de grandes plantas (de armamento, químicas y nucleares) y para el
desarrollo de programas de gran envergadura, como la carrera espacial, o el desarrollo
de misiles balísticos de largo alcance.
Rápidamente se mostró la necesidad de formalizar las técnicas existentes para la

planificación, gestión y control de los proyectos de mayor tamaño. Se desarrollaron así
técnicas formales de planificación y programación (tales como las metodologías CPM
o PERT), que con gran velocidad se trasladaron al ámbito civil, así com:> a proyectos
F.PILOGO: LA GESTIÓN EN EL TERCER MILENIO 241
de menor tamaño, incrementando la eficiencia y mejorando los resultados de aquellas

organizaciones que más se apresuraron a la hora de incorporar los nuevos
conocimientos.
La revolución informática
A la par que se consolidaron las técnicas "modernas" de planificación y gestión, el

mundo vivía una incipiente revolución tecnológica asociada al desarrollo y
generalización de los ordenadores. Al principio bienes inalcanzables salvo para los
gobiernos y las grandes empresas, pronto saltaron a las pequeñas organizaciones. La
introducción de la informática no supuso avances notables en las técnicas aplicadas,
pero sí en la facilidad y en la rapidez para implantar las ya existentes, así como en la
sencillez de simular a priori, en diferentes escenarios, el resultados de diferentes
opciones a la hora de gestionar los proyectos. En definitiva, se trataba de utilizar los
nuevos recursos computacionales para poder manejar y analizar más información, en
menos tiempo, y con menos recursos.
Este panorama coincidió (con toda probabilidad, de manera no casual) con corrientes
de pensamiento novedosas que, a principios de los años 70, fundamentalmente en
Estados Unidos, propugnaban la'utilidad de la información como un recurso
estratégico de la empresa, y fomentaban la dedicación de recursos en exclusiva para la
recopilación y el análisis de dicha información. Así comenzó a profesionalizarse la
carrera de gestión, lo que dio lugar a su vez a una proliferación masiva de las (hasta
entonces casi inexistentes) escuelas de negocios.
Esas técnicas encajaron perfectamente en una mentalidad que hoy en día persiste en la
cultura directiva en nuestras organizaciones. Y no sólo eso, sino que se ha filtrado
hasta niveles inferiores de la pirámide ejecutiva, y ya es práctica general gestionar los
trabajos utilizando herramientas informáticas que, sobre la marcha, permiten analizar
casi en tiempo real un gran número de los parámetros económicos y los recursos más
significativos de los proyectos (este libro, sin ir más lejos, proporciona algunas
herramientas para ello), modificando de inmediato la planificación, la programación o
el curso de las actividades. Y todo ello sin mencionar el incremento de eficiencia
propiciado por el avance y generalización de las telecomunicaciones.
Y ahora... ¿qué?
En este cambiante contexto resulta bien difícil predecir la evolución, siquiera a corto
plazo, del entorno en el que operan nuestras organizaciones. Si bien es cierto que las
corrientes culturales orientadas a la dirección de proyectos y las novedades en técnicas
de gestión avanzan a ritmo lento, la verdad es que la incesante renovación tecnológica
impone cambios de ritmo e insufla constantemente novedades en los procesos
242 DIRECCIÓN Y GESTÍÓN DB PROYECTOS
productivos, lo que sin duda supone un enorme efecto sobre las actividades básicas de
dirección y gestión.
Pese a la dificultad de realizar predicciones en este sentido, dos movimientos parecen

destinados a influir en la mecánica productiva de las organizaciones: el teletrabajo, y
la mejora de los servicios de telecomunicaciones, sustanciada en la aparición de
nuevas herramientas de trabajo basadas en internet y el comercio electrónico.
El impacto del teletrabajo en la gestión
En lo que respecta al teletrabajo, es evidente que cambiar una filosofía de producción

con varios miles de años de predominio no es tarea fácil ni exenta de complicaciones.
El teletrabajo ocasiona enormes cambios estructurales en las organizaciones y en los
procesos productivos, a los que las técnicas de dirección y gestión no son inmunes. La
ausencia de contacto personal, la carencia de horarios rígidos, y la desaparición de
restricciones geográficas no sólo implican un ahorro de costes y una mayor
especialización, sino también un previsible incremento de la inefíciencia de algunos
individuos, de los conflictos de interfaz entre el equipo de trabajo, y de los riesgos
asociados a la estimación de costes y plazos.
Tal y como muestra la figura E.l, la generalización del teletrabajo exige la

convergencia de diferentes factores que representan la evolución de los modelos de
productividad, no sólo a partir de desarrollos técnicos, sino también desde la
perspectiva de cambios en el comportamiento y los usos sociales e, incluso, en el
marco jurídico en el que se producen. Así, no puede olvidarse el impacto que las
tecnologías de la información han tenido sobre los modelos empresariales durante,
sobre todo, esta última década del siglo, ni tampoco las nuevas necesidades que han
surgido de la aparición de servicios proporcionados a través de las nuevas
infraestructuras. Esta revolución en los procedimientos va seguida de cambios en la
percepción y en el comportamiento social, más o menos espontáneos y (aunque a largo
plazo) de modificaciones a la regulación y legislación cuyo objeto no es otro que
validar jurídicamente comportamientos ya arraigados en la conducta social.
Dejando de lado las triunfalistas declaraciones de estrategas comerciales y políticos,

las experiencias reales de teletrabajo, hasta el momento, dejan un cierto sabor
agridulce. Estos experimentos han mostrado, sin duda, aspectos positivos y mejoras en
el rendimiento a corto plazo, pero no son extrapolables al conjunto de una sociedad.
En principio, los expertos coinciden al afirmar que son técnicas aplicables a un
limitado número de actividades, de creación, transformación y distribución de
información, en las que la sincronización temporal no es un factor determinante, y en
la que los medios de producción y resultados que se intercambian en el proceso son
claramente inmateriales (es decir, básicamente se maneja información).
EPILOGO: LA GESTIÓN EN EL TERCER MILENIO 243
Y desde el lado de las personas sucede lo mismo. El teletrabajo exige personal de alta
motivación y no menos responsabilidad. No es apto para todos, a menos que se
produzca una verdadera revolución social que identifique los objetivos del individuo
con los de su grupo de trabajo.
Figura E.l Convergencia de factores hacia el desarrollo del

teletrabajo
En cualquier caso, lo que sí es evidente es que en este tipo de procesos las técnicas de
dirección y gestión clásicas no son adecuadas. La falta de contacto personal, la
Íntangibilidad de los recursos manejados y la distancia psicológica de los elementos de
producción juegan un papel decisivo a la hora de multiplicar las in certidumbres y
reducir los elementos de control.
11
E-loquesea "
Una red de propósito militar, Arpanet, fue el origen de Internet, motor a su vez de un
verdadero polímero de cambios en el comportamiento social, en la percepción cultural
y en la dinámica económica de los países más desarrollados, al permitir acceder casi
en tiempo real a información y recursos distribuidos por todo el planeta. Pero de esta
revolución no sólo se han beneficiado los países más industrializados. También,
aunque a menor escala, se ha propiciado la universalización de la información y se ha
facilitado el acceso a ella para comunidades menos pudientes o favorecidas, con
independencia de su tamaño, ubicación y recursos (pues basta con un ordenador
personal, y una conexión a la red).
Las organizaciones, especialistas en sobrevivir en entornos cambiantes, han hecho uso

de su capacidad de respuesta ante estas novedades, con el fin de aumentar al máximo
su eficacia, y desde la primitiva utilización del correo electrónico (e-mail) avanzan,
lento pero incesante, hacia el intercambio y el comercio electrónicos (e-commercé).
Ya se habla incluso del tercer estadio evolutivo del mundo de las organizaciones en
Internet: el "negocio" electrónico (e-bussiness).
Por supuesto, todos estos cambios implican transformaciones radicales en los procesos
proyectuales y, por ende, en las técnicas de gestión aplicables. Cada vez más, las
empresas con capacidad para ello se transforman en productores de servicios con un
mercado potencialmente universal, al que se dirigen en masa. La búsqueda de
oportunidades es cada vez más genérica. Se aumenta la publicidad y se facilita el
acceso a la información comercial de la empresa, disminuyendo el contacto personal
con los potenciales clientes. Incluso la fase de estimación económica es más
impersonal. Algunas organizaciones ya disponen de páginas en Internet en las que los
Clientes consultan los productos existentes, indican sus necesidades especificas, y un
confígurador automático de ofertas realiza una estimación de los recursos precisos y,
por ende, del coste del producto final.
A modo de conclusión
Sin embargo, aquellos lectores que hayan seguido el contenido de este libro no deben
temer por su obsolescencia. Bien cierto es que las nuevas tecnologías y los nuevos
comportamientos obligarán a no pocos cambios a los procesos de dirección y gestión
clásicos. Pero también es verdad que, en una sociedad como la nuestra, cambios de tal
envergadura requieren mucho, mucho tiempo.
Y en definitiva, lo que se hace es refinar las técnicas clásicas de gestión para

adaptarlas mejor, con más eficiencia, a las nuevas corrientes, pero sin invalidar los
conceptos básicos anteriores.
Para aquellos lectores que hayan disfrutado con la lectura de la obra, no nos resta sino
tratar de dirigir su atención hacia otras áreas de esta disciplina, caso de que deseen
proseguir con el estudio de la misma.
Así, por ejemplo, puede ser sumamente interesante abordar los problemas
relacionados con la producción, incluyendo el estudio analítico del consumo de
recursos (factores de producción) y del volumen de producto generado, como paso
necesario para la organización eficiente de las empresas (y sus procesos productivos).
Las técnicas cuantitativas de gestión, el análisis econométrico, la teoría de la decisión
o la teoría de juegos son algunas de las materias en las que merece la pena incidir.
EPÍLOGO: LA GESTIÓN EN EL TERCER MILENIO 245
Otra posible materia sobre la cual los lectores pueden desear profundizar (aunque tal
vez para profesionales con una cierta experiencia adquirida) es la dirección de
proyectos, desde el punto de vista de las relaciones humanas involucradas. Es la parte
de "arte" que en este libro no ha tenido cabida. La motivación, el liderazgo, la
capacidad de comunicación, las técnicas de negociación, etc. son los aspectos que
diferencian a un simple responsable de proyecto de un verdadero Director.
Pero también puede haber quienes gusten de los conceptos relacionados con entidades
de mayor nivel que los proyectos: las propias organizaciones. Existen referencias
bibliográficas abundantes (muchas de ellas excelentes) acerca de la organización,
gestión y dirección de empresas, y también muchas escuelas de negocios, de
reconocido prestigio y sobrada eficiencia.
Si la lectura de este texto ha servido, aunque sólo sea, para motivar al lector a
proseguir con el estudio de alguna de estas disciplinas, el esfuerzo habrá merecido la
pena.
El autor,
La Haya, Octubre de 2004

APÉNDICE A
EJEMPLOS DE EVALUACIÓN
ECONÓMICA DE PROYECTOS
1. INTRODUCCIÓN
Como ya se ha visto a lo largo del presente libro, la mayor parte de los problemas de
un proyecto se derivan (imprevistos aparte) de una incorrecta evaluación (técnica o
económica) del mismo, cuyas consecuencias se arrastran durante el resto de los
trabajos (y, a veces, mucho más allá, al quedar nuestra imagen empobrecida por los
mediocres resultados obtenidos).
Estimar incorrectamente el coste, esfuerzo, plazo o suministros del proyecto, y dejar

que el contrato siga su curso, tal cual, supone abocar de antemano el proyecto a
problemas que, sumados a las contingencias naturales de cualquier trabajo, pueden
llevar el contrato al fracaso económico.
Por esta razón, se incluyen a continuación algunos ejemplos de estimaciones de

alcance, esfuerzo y coste de proyectos sencillos, con el fin de poner de manifiesto
algunas consideraciones prácticas típicas al evaluar proyectos de pequeño y mediano
tamaño. Entre tales ejemplos se incluye:
> Evaluación de un trabajo estival, para una estudiante universitaria.

> Evaluación de un proyecto para el desarrollo de un nuevo producto, y de
un proyecto para la fabricación en serie del mismo (ThermoPC).
> Análisis y evaluación de un proyecto en curso, como método para ilustrar
las dificultades que implica analizar y diagnosticar un proyecto en
marcha.
2. UN TRABAJILLO ESTIVAL PARA UNA ESTUDIANTE

DE DERECHO
2.1 Introducción y antecedentes
Belén Tilla es una estudiante de cuarto curso de licenciatura en Derecho. Cada verano
(meses de julio y agosto), desde hace algunos años, trabaja de 10:00 a 16:00 horas,
cinco días a la semana, como socorrista en la piscina de la urbanización donde pasa el
verano, por lo que viene recibiendo un sueldo bruto de 1.000 € mensuales.
En junio de este año, una revista de divulgación jurídica le ofreció la posibilidad de,
trabajando por libre, realizar un pequeño estudio sobre estadísticas de sentencias
jurídicas relacionadas con editoriales de prensa. Para ello, tendría que revisar y
extractar unos 450 expedientes judiciales, depositados en el archivo del juzgado
municipal, analizarlos y elaborar unas conclusiones a plasmar en un informe de unas
200 páginas.
Por dicho trabajo, la revista le pagaría 2.100 €, y otros 300 € más para gastos. La
revista abonará también el IVA correspondiente.
A primera vista, a Belén le parece un trato excelente. Cobrará 400 € más que en la
piscina, y trabajará en algo mucho más relacionado con sus estudios que rescatar al
mocoso del cuarto piso cada vez que se tira al agua con su triciclo.
Sin embargo, como nuestra avezada estudiante acaba de terminar de leer este libro, no
le basta con la decisión preliminar anterior, y decide poner en práctica sus flamantes
conocimientos de gestión, realizando un pequeño análisis del trabajo a realizar.
2.2 Evaluación del trabajo
Nuestra voluntariosa y trabajadora amiga comienza por analizar el alcance del

trabajo a realizar. A priori, parece bastante sencillo estructurarlo en tres tareas:
> Tarea 1: consultar, revisar y extractar los expedientes.

> Tarea 2: analizar la información recogida, y elaborar unas conclusiones.
> Tarea 3: plasmar el trabajo y las conclusiones en el documento-informe.
© RA-MA ______ APKNPIO. A: HJKMPLOS DE EVALUACIÓN ECONÓMICA DE PROYECTOS 249
A la vista de un par de expedientes tipo, y mediante un rápido cálculo, Belén estima

que puede tardar 20 minutos con cada uno de los expedientes, lo que supone un
máximo de 3 expedientes a la hora. Esto significa 150 horas en total para los 450
expedientes, a las que suma 15 más (un 10%) para pausas y descansos varios.
Una vez extractados los expedientes, Belén cree que necesitará en torno a 6 días de
trabajo para elaborar unos datos estadísticos y unas conclusiones, con las que redactar
el informe.
Para redactarlo puede utilizar (sólo durante el verano) un ordenador de la oficina de su

padre. Además, Teodoro Pesa (ese chico tan majo que viste siempre como un
enterrador, y que le hace constantemente la pelota a su padre) se ha ofrecido a
enseñarle a manejar el ordenador y el procesador de textos "en 2 ó 3 tardes". También
le dijo que podría tardar un par de semanas en representar los datos estadísticos y en
escribir e imprimir el informe.
2.3 Planificación
Los exámenes de Belén terminan a finales de junio, por lo que no podría comenzar los
trabajos hasta primeros de julio. Como el juzgado cierra en agosto, las 165 horas de
trabajo en el archivo tendrían que distribuirse entre los 22 días laborables (hay una
fiesta entre medias) del mes. Esto supone una jornada laboral de unas 7,5 horas
diarias^2. Para terminar a tiempo, el resto del trabajo tendría que hacerlo durante el
mes de agosto.
Los 6 días (48 horas de trabajo) que necesita para analizar los datos decide dividirlos
en 5 días completos, y dos mañanas sueltas. Así, las dos tardes libres podrá reservarlas
para el mini-curso de informática con Teodoro, y se deja un día libre adicional, por si
eso del ordenador es más difícil de lo que parece.
i
Por último, se reserva 2 semanas comr_! :ias (80 horas) para redactar y terminar el
informe, y una mañana adicional, ya a primeros de septiembre, para llevárselo y
enseñárselo al editor de la revista.
Con los datos anteriores, Belén confecciona la planificación temporal mostrada en la

figura A. 1.
6
Aquí, nuestra estudiante empieza a pensar que, después de todo, tal vez no sea un trabajo tan
maravilloso.
Figura A.l Planificación temporal del estudio jurídico
2.4 Costes y gastos
Belén no sabe cómo estimar el coste de su hora de trabajo, así que decide tomar como
referencia el coste de oportunidad, consecuencia directa de tener que dejar de trabajar
en la piscina.
Como socorrista, nuestra amiga obtendría unos ingresos de 1.000 €, en los 22 días del
mes, lo que supone (a seis horas de trabajo diarias) un ingreso bruto por hora de
7,58 €. Belén sabe que el estudio jurídico requiere mayor capacitación y, por tanto,
debería estar mejor pagado, a razón de, por ejemplo, un 20% más, por lo que decide
partir de un coste por hora de 9 €. En estas condiciones, el coste "de personal" del
proyecto sería:
COSTES DE PERSONAL, ESTUDIO JURÍDICO
Q23E¿2!3flflHS Mfyrrff
Revisión expedientes M
165 9,00 1.485
Elaboración conclusiones 48 9,00 432
Curso de PC 12 9,00 108
Elaboración informe 80 9,00 720
Presentación 4 9,00 36
A la vista de la tabla anterior, Belén empieza a percibir que tal vez el negocio no sea
tan redondo como pensaba en principio. Aun así, decide llegar hasta el final en su
análisis de costes, identificando las siguientes partidas:
Contingencias: Belén se reserva un 5% del presupuesto anterior (otras 15

horas, más o menos) para imprevistos, ante posibles problemas con el
ordenador, con la locahzación de expedientes, o por si olvida algún detalle que
__________ APÉNDICE A: EJEMPLOS DE EVALUACIÓN ECONÓMICA DE PROYECTOS 251
el Cliente, posteriormente, le reclame modificar. Esta reserva supone un coste

adicional de 139 €.
Viajes: para realizar el trabajo hay que ir 22 días al juzgado, lo que le supone,
a 0,8 € por trayecto, unos 35 €. A esto hay que añadir 22 comidas (el juzgado
está lejos de casa), que a precio de menú añaden 132 € más. Los días que va a
la oficina de su padre (12, contando 10 para el informe, y 2 más para el curso),
va y vuelve dos veces desde su casa (se acerca a comer, que le sale más
barato), haciendo en total 44 trayectos, por valor de otros 35 €.
Otros gastos: Belén reserva 20 € para invitar un día a cañas (pocas) a

Teodoro, en agradecimiento a "sus servicios", 60 € más para gastos de
fotocopias y encuademación del informe, y otros 60 € para imprevistos, lo que
suma un total de 140 €.
Los cálculos anteriores conducen a, sumando horas, contingencias y gastos, un coste

total del proyecto de 3.262 €, claramente superior a lo que la revista está dispuesta a
abonar.
La figura A.2 muestra el presupuesto inicial completo, que Belén calcula, ahora,
haciendo uso del formato propuesto en el capítulo 3 de este libro. Para ello, tiene que
tener en cuenta que está ignorando las cargas sociales y los gastos generales. Los
primeros, porque no considera la necesidad de darse de alta físcalmente, y cotizar a la
Seguridad Social (en la lectura de este apéndice se aborda esa cuestión). En cuanto a
los costes generales, Belén aprovecha la magnanimidad de su familia, que le permite
utilizar los recursos de su casa (luz, teléfono, espacio físico, etc.) y de la oficina para
la actividad mercantil.
Aun así, el saldo de la estimación económica del proyecto es claramente negativo, e

indica que el margen del mismo corresponde a unas pérdidas contables de más del
26%.
Sin embargo, Belén está dispuesta a que no haya excedente monetario en el proyecto,
y a que el margen sea nulo, así que decide "retocar" su sueldo horario, para ver qué
puede llegar a cobrar por hora, de manera que el margen se haga cero. Jugando con las
cifras del presupuesto anterior, Belén consigue un precio de venta de 2.400 €, con
margen nulo, si fija un coste horario de 6,34 € a la hora, cantidad inferior a los
7,58 €/hora que percibiría trabajando en la piscina.
© RA-MA ________________ APÉNDICE A: EJEMPLOS DE EVALUACIÓN ECONÓMICA DE PROYECTOS 253
2.5 Decisión
Desde el punto de vista económico, si Belén fuese una empresa, no tendría más
remedio que rechazar el proyecto. El margen negativo del 26% no le dejaría otra
opción. Además, una empresa tiene que asumir unos costes generales y unas cargas
sociales ineludibles, que Belén está, de una u otra manera, escondiendo
contablemente.
Desde el punto de vista del trabajo a realizar, nuestra amiga observa que, comparando
con su oportunidad de trabajo más directa, el cargo de socorrista en la piscina, el
nuevo trabajo tiene las siguientes ventajas:
> Le aporta experiencia profesional, que en la piscina no va a obtener.

> El dinero que ingresa, gastos aparte, será de 2.058 €, mientras que en la
piscina sólo obtendría 2.000 €.
> Este trabajo, si finaliza correctamente, le podrá conducir a otros trabajos
posteriores, durante el invierno e, incluso, al finalizar sus estudios.
Sin embargo, también tiene un cierto número de inconvenientes:
> Le supone rechazar el trabajo de la piscina, y tal vez la persona que la

sustituya se quede ya para veranos sucesivos.
> Le obliga a trabajar una media de 8 horas diarias, en comparación con las
6 horas de su jornada como socorrista.
> Los ingresos por hora de trabajo son un 20% menores que los que
obtendría en la piscina.
> Le exige a desembolsar, de su bolsillo, 342 € (los gastos del proyecto),
que sólo recuperará (si todo va bien) al final del proyecto. Además,
previsiblemente no cobrará el trabajo hasta un par de semanas después de
entregarlo, por lo que puede pasar casi tres meses hasta percibir el primer
euro.
> El trabajo es mucho más pesado e incómodo que el de socorrista.
> No conoce al Cliente, y existe un cierto riesgo de que, al final, no quede
satisfecho con el trabajo, y no pague la totalidad de lo convenido (o haya
que retocar gran parte del trabajo).
A modo de conclusión, nuestra amiga tiene bastante difícil elegir entre una u otra
opción. Puede elegir el trabajo como socorrista, y obtener un buen dinerito de forma
cómoda, o puede optar por el estudio jurídico, que le resultará mucho más complejo y
requerirá un gran esfuerzo, pero que le proporcionará experiencia profesional
relacionada con su formación académica. ¿Qué elegirá, finalmente, Belén?
LECTURA. EL EFECTO FISCAL
En el ejemplo anterior, Betón, ha olvidado (¿conscientemente, tal vez?) el efecto

de los impuestos sobre el margen y el beneficio de su peculiar proyecto.
Veamos:
Cuando Belén trabaja como socorrista en la piscina, te comunidad de vecinos se

encarga de cotizar por ella a la Seguridad Social, por cuotas de desempleo,
foimación, sanidad, ete. Al abanarle los t.000 € mensuales, sólo le retendrá una
pequefia cantidad, que depende de las condiciones personales, pero que podrá
estar por debajo del 2%, en concepto de impuestos y cargas sociales. Esto
supone descontar,, del nwgen, 40 £ durante los dos meses de verano.
Si acepta el trabajo de la- revista» Belén pasará a trabajar como autónomo (salvo
Jque la editorial decida hacerle un contrato temporal, algo poco probable),
teniendo que darse de alta como tal, solicitar una licencia fiscal y abonar el
impuesto de actividades económicas, así como adquirir los preceptivos libros de
cuentas. Este papeleo podría costarle unos 600 €. Además, pagando a terceros,
la editorial está obligada a retener el 15% de la cantidad total (480 €, de los que
probablemente algo recupere ai liquidar sus impuestos a final de año).
La picara Belén decide, sin embargo, obviar dicha obligación, y facturar a

través de la empresa de su padre03. Pero haciéndolo así, dicha cantidad se verá
gravada a final del ejercicio fiscal can un impuesto sobre beneficios a un tipo
impositivo mucho más alto que el que le correspondería a Belén.
Lo anterior, aparte de un ejercicio numérico de interés, es una clara crítica a los

sistemas fiscales \ que dificultan la realización de pequeños trabajos y
colaboraciones por libre, especialmente cuando el sujeto es un trabajador
ocasional. Muchos trabajos en este país (y en otros también) se rechazan por el
alto coste administrativo de estar en condiciones legales de emitir una factura.
Sin embargo, si aún así Belén decide seguir adelante y aceptar el trabajo, parece
xfue la mejor recomendación sería gastarse los 600 € (que, por cierto, ha de
adelantar de su bolsillo) y facturar en su propio nombre, aceptar la retención de
los 480 € y, al final del tómestre, al hacer su declaración fiscal, recuperar la
parte <pie 1© corresponda, „ pudiéndose así desgravar en concepto de los gastos
reales en los que haya incurrido.
63
El autor reprueba firmemente esta práctica, poco social, elegida por la protagonista del caso
de análisis. Sin embargo, tal deleznable opción sirve a los propósitos didácticos del texto.
o KA-MA ________________ APÉNDICE A: EJEMPLOS DE EVALUACIÓN ECONÓMICA ÜK PROYECTOS 255
3. PROYECTO DE DESARROLLO Y FABRICACIÓN

EN SERIE DE UN NUEVO PRODUCTO: THERMOPC
A comienzos de semana, Lorenzo Penco, comercial de Caos Consulting, recibió una

llamada de Esteban Quete, director comercial de la cadena de hipermercados
Alaplaya, para poner en su conocimiento la intención de la empresa de liberar un
Pliego para contratar el diseño y, posteriormente, la fabricación de un nuevo producto.
El Sr. Quete le comentó que, con vistas a la campaña de Navidad (para cuyo
comienzo, el 1 de diciembre, aún faltaban 6 meses), el hipermercado tenía pensado
regalar, junto con cada ordenador personal vendido, un dispositivo que permitiera
medir la temperatura ambiente a través del ordenador: el ThermoPC. Este dispositivo,
de bajo coste y complejidad, sería, según él, la mejor inversión publicitaria orientada a
incrementar las ventas navideñas del departamento de micro-informática.
Para seleccionar la empresa encargada de diseñar y fabricar el dispositivo, los

responsables técnicos de Alaplaya habían redactado un Pliego de Condiciones que,
distribuido a varias empresas del sector (entre ellas, Caos), permitiera a las mismas
presentar una oferta técnica, económica y de gestión.
De inmediato, Lorenzo Penco solicitó a Esteban Quete una copia del Pliego, que le fue
remitida por correo. Tras su recepción, Lorenzo cursó la misma a Sandra Mática,
quien cursó instrucciones precisas a Armando Bronca, Director de Proyecto de la
sección, para que la evaluara.
3.2 El Pliego
A continuación se extracta el contenido del Pliego de Alaplaya para la selección y

contratación de la empresa adjudicataria del diseño y fabricación del dispositivo
ThermoPC.
El apartado 5 del capítulo 1 contiene una descripción completa de la empresa Caos

Consulting, S.A.
64
PLIEGO PARA LA SELECCIÓN Y CONTRATACIÓN DE
EMPRESAS ADJUD1CATARIAS CLÁUSULAS
GENERALES
■ Empresa convocante: hipermereados Alariíaya .

■ Alcance del contrato: diseño y fabricación del dispositivo ThermoPC
■ Presupuesto; a definir por los licitadores
■ Fecha límite de presentación de ofertas: 15 días desde la fecha de
publicación. Fecha de publicación: 1 de junio.
1.1 Objeta del contrato
Parte de la estrategia publicitaria de Alaplaya para la sección de

informática de sus centros de distribución para la próxima campaña sfta,
se pretende regalar con cada ordenador personal vendido un iitivo
capaz de medir la temperatura ambiente, cuya medida pueda ser
directamente transmitida a un PC estándar, con el fin de ser mostrada, procesada
y/o registrada, por el mismo.
Los trabajos reseñados en eí presente pliego están orientados al diseño,

construcción, prueba y documentación, por parte de la empresa adjudicataria, de
un dispositivo hardware para la medida de la temperatura ambiente, conectado a
y gestionado mediante un ordenador personal, tipo PC. El suministro incluirá
también el software básico de manejo, así como la documentación técnica y de
usuario correspondiente.
La correcta terminación del alcance anterior, en condiciones de calidad, tiempo

precio, daría lugar a extender el contrato inicial para la fabricación en serie de
X>0 unidades del dispositivo desarrollado..
S Precio del contrato :
precio máximo de licitación para las. trabajos de diseño, construcción, prueba

y documentación del prototipo, así como la provisión del software
correspondiente, según lo reseñado en «1 presente pliego, no podrá exceder la
cantidad de 12.000 €, impuestos incluidos.
Cualquier mejora voluntaría al alcance definido deberá estar comprendida,

ualmente, en el precio máximo indicaído. dicionahnente, para que una oferta sea
admitida y evaluada, el licitante deberá dicar el precio oríentatlvo (can un
máximo del 10% de error) del dispositivo ofertado, para series de fabricación de
6.000 unidades.
© RA-MA APÉNDICE A: EJEMPLOS DE EVALUACIÓN ECONÓMICA DE PROYECTOS 257
Cualquier oferta en la que el precio de las unidades individuales, en seríes de

6.000 unidades, supere los 12,50 €, impuestos incluidos, serán automáticamente
eliminadas.
1.3 Plazo de ejecución del contrato
Con el fin de satisfacer las necesidades derivadas de la campaña navideña, los

trabajos propuestos en el presente pliego ileberán estar finalizados,
documentación técnica, de gestión y de usuario incluida, antes del. I de
septiembre del presente año.
Caso de prorrogarse el contrato, el adjudicatario se comprometerá, igualmente,

a suministrar 6.000 unidades del dispositivo desarrollada en los plazos
temporales siguientes
■ 3.000 unidades antes del 1 de noviembre del presente año,

■ 3.000 unidades antes del 2 de diciembre del presente año.
1.4 Forma de pago
Los trabajos que resulten de la adjudicación del contrato se abonarán, previa

aceptación por parte de Alaplaya y contra presentación de factura, a los 90 días
de la fecha de la misma,
1.5 Plazo de garantía
El adjudicatario deberá comprometerse formalmente a la previsión de un

período de garantía de 90 días, tras la entrega y aceptación de los trabajos de la
primera fase, contra cualquier defecto y vicio de los programas, materiales y
documentación entregada.
En caso de prorrogarse el contrato para la fabricación de las unidades

comercializares, el adjudicatario se deberá comprometer, igualmente, a
garantizar durante un año, desde su fecha de entrega alustrarlo final, cada una
de las unidades entregadas, contra todo defecto de fabricación y mal
funcionamiento. En tal caso, el contratista se compromete a retirar det almacén
central de Alaplaya en Madrid, reparar o sustituir sin cargo en un plazo no
superior a 72 horas, y devolver en el punto de reparto, cuantas unidades le sean
devueltas por causa de mal funcionamiento.
1.6 Propiedad intelectual del desarrollo
Sin perjuicio de lo establecido en la vigente Ley de Propiedad Intelectual (Real

Decreto 1/1996, del 23 de abril, modificada según Ley 5/1198, Ley 1/2000 y
l e v 22/?0fnv todos los diseños., nrntntino^ documentos v nrnímnnas
•esultarrtes útl presente contrato se consideran propiedad industrial de

lipermcreados Alapiaya, renunciando explícitamente el adjudicatario a
cualesquiera derechos patrimoniales derivados del uso y explotación de dichos
resultados.
DE FROPOSÍCIQNES Y SU CONTENIDO
Las proposiciones orientadas a la adjudicación de los trabajos objeto del

presente pliego deberán incluir, al menos, la siguiente documentación:
Propuesta técnica, describiendo, como mínimo:

1
El alcance del trabajo a realizar. :';,:;:;;;;.; - _ -
K La rnetodología a seguir para la realización del mismo, las herramientas a
emplear y los procedimientos de contrastaeión entre requisitos de usuario y
el producto terminado, así como la metodología de prueba y verificación.
• El diseño preliminar del producto, incluyendo la descripción funcional del
dispositivo y las interfaces de usuario.
Propuesta de gestión, describiendo el equipo de trabajo propuesto (CV

incluido), la organización y planificación de actividades, y cualesquiera otros
ispéelos relativos a la gestión del proyecto.
Propuesta económica, indícamlo claramente el precio de licitación, en euros

corrientes y con todos tos gastos e impuestos incluidos.
CRITERIOS PARA LA ADJUDICACIÓN
Para determinar el ofertante al que se le adjudicará la realización de los trabajos,

Se asignará a cada propuesta presentada una valoración objetiva, de entre 0 y 10
puntos, emanada del análisis técnico, díe gestión y económico de la oferta. La
rferta que mayor puntuación obtenga será, en condiciones normales, la
xijudicat&ria del contrato. . _ _ . ¿ . , _ : ;
Las proposiciones económicas se valorarán entre O y 5 puntos. Se asignarán

:ero puntos a las propuestas cuyo precio de licitación se corresponda con el
sresupuesto máximo de licitación (12.000 €, impuestos incluidos). Toda
proposición cuy© precio supere al precio máximo será automáticamente
descartada. De entre las proposiciones restantes, se asignará hasta 5 puntos a
iquélla o aquéllas cuyo precio coincida con la media aritmética de todas las
propuestas económicas presentadas. Las demás propuestas recibirán la
puntuación correspondiente a interpolar mediante sendas rectas, entre 0 y 5
auntos. v entre dicho valor medio v. reSDectivamente. el orecio máximo de
APÉNDICE A: EJEMPLOS DE EVALUACIÓN ECONÓMICA DF, PROYECTOS 259
licitación y el precio mínimo ofertado, La futieron é

según el precio propuesto se indica en la figura siguiente
La valoración técnica se obtendrá como un índice numérico de calidad, de entre

0 y 5 puntos, que incluirá la mayor o menor aceptación que merece la propuesta,
función de los criterios técnicos enunciados a continuación: „ „
Grado de respuesta general de la propuesta a los requisitos del Pliego. 0,5

puntos.
Viabilidad general de la propuesta, en cnanto a alcance y condiciones de
realización. 0,5 puntos.
Cirado de cumplimiento en cuanto a funcionalidad del producto ofertado.
0,5 puntos.
Nivel estético del producto ofertado, en relación a interfaeesde usuaria. 0,5
puntos.
Calidad general dd equipo de trabajo propuesto, y adecuación de los
perfiles profesionales de los miembros del mismo con el trabajo ofertado.
Experiencia previa del equipo de trabajo en la realización 4e trabajos
similares. 0,3 puntos.
Adecuación de los plazos propuestos para la ejecución de los trabajos con
los requisitos del Pliego. 0,5 puntos.
Calidad técnica y nivel de detalle <k la documentación a aportar pt
contratista. 0,5 puntos.
Aportaciones que» sin estar explícitamente solicitadas en el Pliego, puedaí
mejorar el resultado de los trabajos a realizar. 0,7 purrtos. Menor precio por
unidad para la fabricación en serie, en la segunda fase d contrato, de
6.000 unidades recurrentes. A tal efecto, se asignará puntuación
correspondiente mediante im criterio similar al adoptado para-evaluación
económica de la primera fase. 1 punto.
Para que una propuesta sea adjudicable, deberá obtener, al menos, 3.5 puntos €!
la valoración técníc
APÉNDICE A: EJEMPLOS DE EVALUACIÓN ECONÓMICA DE PROYECTOS 261
La resolución del medidor será de, alómenos, una décima de grado. El ofertante
de justificar cualquier valorpgfor que el reseñado.
5. Requisitos operativos unidad de Medici4il diseñada estará totalmente
autocbntenidata excepción del cable y eí cónectpr pitra:eLPCJ en una caja de
tamaño no superior a 15x15x5
La unidad se conectará al PC fnediante un cable, de, longitud no inferior a ;1,5

metros, vía puerto serie o tJSB.; kí; ¡a iniétfaz elegida ss la segunda, e!
dispositivo ThermoPC deberá 'funcionar indistintamente con puertos USB
versiones í.íy^.Gi"
La aplicación software para ht captura y presentación de Ja temperatura se podra

ejecutar eñ PC, Intel Peñlitpn I 0 superior, con capacidad de disco igual o
superior al MB y con 'mettídria RAM fe ai merios',^4 Mbytes.
Se entregarán dos aptieaoioñes:
La aplicadóti ThermaPCEXE, que se ejecutará bajo sistema operativa

DOS. También podrá ejecutarse dentro de una ventana DOS de Windows
La aplicación Win_Thi¿í"moPC.EXE* q«e se ejecutará en loúuvtiatena gráfica
La aplicación no-necesitará que en el,ordenador donde se vaya a ejecutar fiayg

otras aplicaciones instaladas! Cualquier libreríah módulo adicional que precise
para su correcto funcionamiento .liabrá de ser proporcionada junto con h
aplicación.
La aplicación deberárealfearse y poder compilarse con cualquier compilador dt

lenguaje Cs estándar ANSÍ.
4 Requisitos «te mterfasÉ
La unidad* a desarrollar tendrá xma única' ínterfaz hardware; consistente en una

línea serie ó USB, a conectar al PC.
La unidad de medición se alimentará a partir de la tensión proporcionada pui

puerto del PC. El adjudicatario del contato aera responsable de verificar la
viabilidad de; esta aproximación y, caao eonttarío* proponer esquemas
alternativos.
aplicación DOS a ejecutar en el PC se arrancará mediante un comando DOS
í:>tliermojpc <puerto>
I campo opcional puerto indicará el puerto físico al que está conectado el

dispositivo de medición de temperatura, siendo del tipo comí, com2, etc. para
dispositivos, diseñados para puerto serie, y lptl, Ipt2, etc. para dispositivos
conectados al puerto paralelo. Caso de omitir este parámetro, se interpretará la
lección comí o lptl. " / , » / -
campo opcional fe indicará él acceso al modo de calibración. En este modo,

programa solicitará el valor real de dos temperaturas, y ajustará la curva de
ilibración del dispositivo para que Jos "valores de las temperaturas leídas se
justen correctamente a los valores reales. La forma de la curva de calibrado
á dada, en general, por la curva de respuesta del dispositivo semiconductor
tcargado de la medición de la temperatura.
Al ejecutar et programa sin la opción de calibración, el software verificará que

existe un dispositivo de medición conectado al puerto indicado, mostrando un
mensaje de error en caso contrario, y deteniéndose después. Caso de existir el
dispositivo, mostrará un mensaje en pantalla del tipo "La temperatura medida es
de XX.X grados centígrados", deteniéndose a continuación.
La aplicación para Windows, WinJUtaeraePC, se ejecutará como cualquier

aplicación de Windows, y tendrá la misma funcionalidad que la versión para
MS-DOS, salvo que la ventana permanecerá en pantalla, y la temperatura
letectada por el dispositivo se actualizará una vez por segundo.
Entregables
Al finalizar el trabajo, y previo a su aceptación, el adjudicatario habrá

entregar, al menos, los siguientes elementos constitutivos del producto objete
del contrato:
■ Documento de diseño del dispositivo hardware y de la aplicación,

incluyendo descripción funcional y descripción de la arquitectura, esquema
eléctrico, así como planos y esquema del circuito impreso. Manual de
instalación y usuario del dispositivo y de la aplicación. Uno o más
disquetes de 1.44 Mbytes, formato 3.5", incluyendo el ejecutable de
fa aplicación o, en su defecto, programa de instalación de la misma.
Opcionalmente, el contratista podrá entregar la aplicación en un >rte CD-
ROf
íno o más disquetes de 1.44 Mbytes, formato 3.5", incluyendo el código

fuente de la aplicación. Opcíonalrnente, el contratista podrá entregar los
fuentes en un único soporte CD-ROM.
Unidad prototipo del medidor de temperatura, verificada y funcionando
correctamente
CONTINUACIÓN DEL CONTRATO
Tras la terminación del alcance del contrato, en condiciones satisfactorias para

Alaplaya, y previo acuerdo mutuo de ambas partes; s*e podrán extender los
trabajos, en un nuevo contrato, para la fabricación y entrega de 6.00Q unidades
recurrentes del dispositivo desarrollado. Como condición previa se exigirá que
el contratista:
■ Se compromete a entregar las unidades, en el almacén central de Alaplaya

en Madrid, en las cantidades y fechas reseñadas en el apartado 1.3 del
presente pliego.
■ Se comprometa a fabricarlas por un precio unitario igual o superior al
indicado en su documento de oferta» con un margen del ¡0%* por exceso o
por defecto, a justificar antes de la prórroga de los trabajos.
■ Se comprometa a proporcionar asistencia técnica y garantía contra defectos
de fabricación y mal funcionamiento para todas las unidades suministradas,
durante un año a contar desde el momento de la venta y entrega de cada
una
a su usuario final (fecha que vendrá determinada por la factura de compra o
el sello de garantía estampado por cualquiera de los, vendedores de
AlaplayaJ.
3.3 Análisis de los antecedentes
De inmediato, Armando Bronca se puso a analizar el Pliego, tras lo cual organizó una
pequeña reunión informal con Esteban Quete y los responsables del departamento de
microinformática de Alaplaya. De la lectura del Pliego y de la reunión Armando
extrajo las siguientes conclusiones acerca del contrato:
> Es un contrato de hasta 22 meses de duración (seis meses de desarrollo y

fabricación, más un año de garantía, con un margen de venta de los
equipos de 4 meses), que puede rondar los 87.0006 (un máximo de
12.000€ por el desarrollo del prototipo, y hasta 75.000€ por la fabricación
de las 6.000 unidades).
> No parece que el contrato suponga un riesgo técnico elevado. La
tecnología implicada es bastante asequible y conocida en Caos, y la
funcionalidad requerida es razonablemente sencilla. Sí hay un cierto

riesgo económico a la hora de valorar el coste de los componentes y
accesorios (caja, tornillería, etc.) para la fabricación en serie.
> El Cliente no está excesivamente preocupado por la calidad final del
dispositivo ThermoPC (lo que no quiere decir que no exija unos niveles
mínimos), ya que es un mero reclamo para la venta de los ordenadores
personales. Este punto de vista permite ahorrar costes de desarrollo y
utilizar componentes y materiales de regular calidad, así como diseñar
una interfaz de usuario básica.
> Por el contrario, el Cliente es muy sensible al coste del producto y, en
particular, al coste unitario de fabricación de cada dispositivo. Superar el
precio máximo fijado implicaría encarecer el ordenador personal más allá
de lo que el margen comercial permite.
> Además, el Cliente es inflexible en lo que atañe al plazo de entrega del
producto, ya que cualquier retraso impediría llegar a tiempo a la campaña
de Navidad, desbaratando el propósito del contrato. Esto supone, desde la
fecha de entrega de las ofertas, seis meses disponibles. De ellos, al menos
los últimos tres meses y medio serían para la fabricación, mientras que
uno se dejaría de margen para la evaluación de ofertas, formalización del
contrato, etc.
> Por otra parte, a tenor del interés mostrado al obtener los pliegos, se prevé
que presenten oferta, al menos, otras tres o cuatro empresas del sector. No
se conoce precedente de trabajo similar adjudicado por Alaplaya a otras
empresas, por lo que parece que las oportunidades de Caos son similares
a las de su competencia.
A la vista de lo anterior, y tras consultar con la Sra. Mática, Armando procede a

evaluar económicamente el proyecto.
3.4 Evaluación del proyecto
Para evaluar el proyecto ThermoPC, Armando decide plantearlo y organizarlo como

dos proyectos distintos y secuenciales en el tiempo. La razón principal para ello es que
no existen garantías de que, obteniendo el contrato de diseño y desarrollo, finalmente
se llegue a un acuerdo para fabricar las 6.000 unidades recurrentes. Un diseño poco
afortunado, un Cliente insatisfecho o un cambio de planes de la cadena de
hipermercados podría dar lugar a no extender el contrato.
3.4.1 IDENTIFICACIÓN DE LAS TAREAS A REALIZAR
Armando Bronca organiza una pequeña reunión con los responsables de hardware
(Alfonso Carrón), software (Javier Nés) y fabricación (Esther Malgín) de Caos
Consulting, en la que identifican y valoran las actividades a realizar, tanto para el
diseño y desarrollo del prototipo ThermoPC, como para la fabricación en serie del
mismo. El flujo básico de actividades queda reflejado en la figura A.3.
El flujo de actividades identificadas puede concretarse en las siguientes tareas:

D. Fase de diseño y desarrollo:
> DO: Gestión.

> DI: Diseño hardware y software del dispositivo. Se obtendrá un
esquema eléctrico del circuito, una máscara del circuito impreso, y un
diseño de alto nivel del software de control, desde PC. Se obtendrá
también un diseño mecánico. Todo lo anterior habrá de ser compatible
con los requisitos del Pliego.
> D.2: Fabricación. Se fabricará en el laboratorio de Caos la placa de
circuito impreso del prototipo, sobre el que se soldarán los componentes
electrónicos precisos, integrando el conjunto en una caja plástica, de la
que saldrá el cable y el conector de conexión al PC.
> D.3: Desarrollo del software. Se diseñarán a bajo nivel y se codificarán
en lenguaje C los dos programas software requeridos para el
funcionamiento del dispositivo.
> D.4: Integración y pruebas. Se probarán el hardware y software
desarrollados con un PC, prestando especial atención al procedimiento de
calibración del dispositivo, verificando que la unidad prototipo satisface
adecuadamente los requisitos de precisión del Pliego.
> D.5: Documentación. Se elaborará un manual de diseño (que contendrá
el esquema eléctrico y mecánico, la lista de componentes, el código
fuente de las aplicaciones, el procedimiento de calibración y ajuste de las
unidades, etc.) y un manual de usuario del dispositivo.
La figura A.4 muestra la organización temporal prevista para las actividades de diseño
y desarrollo. Para llevar a cabo esta planificación, se ha optado por suponer que la
fecha de comienzo efectiva se situará en torno al 1 de julio, lo que significa dejar un
mes "Ubre" para la presentación y evaluación de ofertas, y la negociación y firma del
contrato. Además, de esta manera, la primera fase terminaría a mediados de julio,
permitiendo organizar con relativa facilidad las vacaciones de los empleados de Caos.
Figura A.4 Planificación del proyecto ThermoPC, fase de diseño y

desarrollo
APÉNDICE A: EJEMPLOS DE EVALUACIÓN ECONÓMICA DF PROYECTOS 267
F. Fase de fabricación:
> FO: Gestión.

> Fl: Compras- Se negociará la adquisición y entrega de los componentes
electrónicos, mecánicos, caja y tornillería y embalaje, discos con la
aplicación software y documentación impresa para las 6.000 unidades a
fabricar.
> F2: Fabricación del circuito impreso. Se subcontratará a una empresa la
fabricación de las 6.000 tarjetas de circuito impreso (Caos carece de los
recursos para fabricar grandes tiradas de placas).
> F3: Montaje y prueba. Se soldarán los componentes, se integrará
mecánicamente en la caja, y se verificará el correcto funcionamiento de
cada unidad montada.
> F4: Embalaje. Se embalará cada unidad en su cartonaje, incluyendo
software y manual de usuario.
> F5: Garantía. Dos veces por semana, se reunirán las unidades devueltas,
y se repararán o sustituirán, durante 16 meses (Alaplaya cree que las
6.000 unidades se venderán en un máximo de 4 meses).
Nótese que, ya que Caos es una pequeña-mediana empresa de ingeniería, ha decidido

subcontratar a terceros la fabricación (en la segunda fase) de las placas de circuito
impreso y la duplicación de los discos de software y la documentación de usuario.
La figura A.5 refleja la organización temporal prevista, asociada a la fase de

fabricación. Según esta planificación, las actividades darían comienzo a principios del
mes de septiembre, y dejarían tres meses para llevar a cabo los procesos de
adquisición y compra, y montaje de las unidades. Nótese que existe un margen de mes
y medio entre la conclusión de la fase de diseño y el comienzo de la fase de
fabricación. Este margen permite, por un lado, absorber el tiempo que el Cliente tarde
en evaluar el prototipo y, llegado el caso, extender el contrato a la segunda fase y, por
otro lado, estar en condiciones de incrementar la cantidad de 6.000 unidades,
comenzando antes las actividades, si así lo decidiera el Cliente. También permite
organizar las vacaciones estivales del personal de Caos.
Figura A.5 Planificación del proyecto ThermoPC, fase de

fabricación (no se muestra el período completo de garantía)
A la hora de perfilar la planificación anterior, Armando Bronca podría haber optado

por comenzar antes las actividades de la fase de fabricación, disponiendo de un
margen de tiempo, antes de las fechas de entrega comprometidas, para imprevistos.
Sin embargo, Armando optó por no hacer uso de esa posibilidad, ya que, en general,
supone que el proyecto se haga "con menos prisas", dedicando más horas de esfuerzo
y, por tanto, incrementando el coste.
3.4.2 ESTIMACIÓN DE HORAS Y GASTOS (I): FASE DE DISEÑO

Y DESARROLLO
A continuación, Armando Bronca se reúne con cada uno de los responsables anteriores
para determinar qué esfuerzo humano es necesario para cada una de las tareas, y qué
costes y gastos adicionales pueden anticiparse. El resultado de las estimaciones
anteriores para la fase de diseño se muestra en la figura A.6.
1 GESTIÓN 12 ]2
2
3 DISEÑO HW/SW, ALTO NIVEL 16 16 32
4
5 KABRICACION DEL PRO 101IPO -1 16 2U
6
7 DESARROLLO SW 8 40 48
I
9 INTEGRACIÓN Y PRUEBAS 16 16
ID
11 DOCUMENTACIÓN 8 16
12
13
14
15
16
17
18
ly
211
Figura A.6 Estimación del esfuerzo asociado al diseño y desarrollo del

prototipo de ThermoPC
Para evaluar los costes y gastos, además de las horas de trabajo, Armando estima
necesario reservar:
> Los gastos asociados a la proporción correspondiente de horas de
ordenador y consumibles, que ascienden a 354€ y a 113€,
respectivamente.
> Unos 350 € para el coste de la placa, componentes, cables, conectores y
tornillería del prototipo (se harán tres unidades), repuestos, discos, etc.
> Unos 350 € para viajes y gastos de reuniones.
> Otros 350 €, para gastos varios.
> El 5% para contingencias en mano de obra y gastos varios, y el 3% en
otros gastos.
270 DIRECCIÓN Y GF.STION DE PROYECTOS
Teniendo en cuenta lo anterior, y con un beneficio global del 20%, el precio de la

primera fase del proyecto sería, tal y como muestra la figura A.7, de 7.782 €.
Incrementando el valor anterior en el 16% correspondiente al IVA, resulta un precio
de venta final de 9.027 €, cantidad inferior al tope máximo de la licitación.
Figura A.7 Presupuesto del proyecto ThermoPC, fase de diseño.
3.4.2 ESTIMACIÓN DE HORAS Y GASTOS (II): FASE DE FABRICACIÓN
Para la fase de fabricación, al ser de mayor volumen, la estimación debe hacerse con
un nivel de precisión mejor. Así, la evaluación de Armando de las horas de trabajo
necesarias, suponiendo que el período completo de fabricación abarca 3 meses, queda
como sigue:
Para las labores de negociación de compras de material, que ocuparán en

torno a una semana, estima necesarias 24 horas de personal técnico.
Para la fabricación propiamente dicha, parte de 10 personas trabajando

durante dos meses, montando placas y cajas, probando y embalando unidades
terminadas. A una medía de dos unidades por hora, supone 3.200 horas de
trabajo. Para ahorrar costes, Armando decide utilizar personal ajeno
(estudiantes de formación profesional), que suponen un coste de 7,5 € por
hora.
Para la provisión de los 14 meses de garantía, estima necesario un viaje al

almacén por semana, para sacar y entregar unidades, de dos horas de duración,
lo que equivale a 60 viajes, y a 120 horas de conductor-transportista (también
a 7,5 € por hora de coste). Por lo poco que conoce del mundo de los
hipermercados, cree que el Cliente aceptará una salida y entrega cada semana,
en lugar de cada 72 horas, como solicita el Pliego.
Para la reparación o sustitución de unidades, evalúa el esfuerzo en 8 horas

semanales de técnico de Caos (448 horas totales).
^ Para valorar la gestión total de la fase de fabricación, toma como referencia 8

horas semanales durante los tres meses de proyecto, más 20 horas adicionales
para negociar el contrato, y otras 112 para las 56 semanas de garantía (228
horas en total). Para ahorrar costes, supone que la actividad de gestión puede
ser desempeñada, excepcionalmente, por un ingeniero júnior.
En cuanto a los gastos, Armando los evalúa mediante la siguiente tabla, una vez
consultados los potenciales proveedores a utilizar en el proyecto:
CONCEPTO COSTE CANT. TOTAL

Viajes y Estancias: proyecto 30,00 20 600
Viajes: garantía (2x35Km) 14,70 60 882
Placa circuito impreso 0,75 6.000 4.500
Componentes 2,10 6.000 12.600
Cables y conectores 1,30 6.000 7.800
Caja y lomillería 0,60 6.000 3.600
Diskette/CD, duplicación y etiqueta 0,35 6.000 2.100
Copia del manual 0,15 6.000 900
Embalaje de cartón 0,10 6.000 600
Los costes anteriores son válidos para un pedido mínimo de 6.000 unidades. En caso
de realizar pedidos de inferior volumen, se incurriría en precios por unidad superiores.
Con la información anterior, la estimación de esfuerzo para la segunda fase del

proyecto queda tal y como muestra la figura A.8.
Introduciendo los datos resultantes en el formato de presupuesto, se obtiene el

resultado que muestra la figura A.9. Para ello, Armando tuvo en cuenta lo siguiente:
> Las horas de personal externo se introducen en el apartado de

subcontrataciones, fijando un valor por hora de 7,5 €. Así, no es necesario
definir nuevas categorías de personal.
> Igualmente, dichas horas no se computan en la estimación de costes para
ordenador y consumibles, pues las personas contratadas para montar y
embalar dispositivos, o para realizar las entregas y salidas de unidades, no
harán uso de dichos recursos.
> Se reservan 750 € para gastos varios.
i GISI1ON 228 228

2
3 COMPRAS 24 24
4
5 FABRICACIÓN DEL CIRCUITO IMPRESO
6
7 MONTAJE Y PRUEBAS 3.360
8
9 RMBAIAJE
10
11 GARANTÍA 120 448 568
12
13
14
15
16
17
18
19
20
Figura A.8 Estimación del esfuerzo asociado a la fabricación en

serie de ThermoPC
274 DIRECCIÓN Y GESTIÓN Dfc PROYECTOS
© RA-MA ________________APÉNDICE A: EJEMPLOS PE EVALUACIÓN ECONÓMICA DE PROYECTOS 275
En tales condiciones, y manteniendo el margen habitual del 20%, el precio de venta

del proyecto alcanza los 106.950 €, que se convierten en 124.062 € al añadirle el IVA.
Si se divide la cantidad anterior entre las 6.000 unidades a suministrar al Cliente, el
precio final por unidad (IVA incluido) resulta ser de 20,68 €, que es mucho más (el
65% más) de lo que los hipermercados Alaplaya están dispuestos a considerar.
El sobreprecio de la fase de fabricación no resulta fácil de enjugar. Aunque se

eliminara el margen, el coste por unidad seguiría siendo de 17,23 € (con IVA). Ni
siquiera renunciando al margen de la fase de diseño se logra reducir el precio por
debajo de los 17 € por dispositivo. Además, tampoco tendría ningún sentido (en
principio) que Caos renunciara a su margen comercial, y trabajara "gratis".
Tras una reunión con Esther Malgín, la responsable de fabricación de Caos

Consulting, con el objeto de analizar el problema planteado, Armando obtuvo las
siguientes conclusiones:
*" Caos es eficiente en la fase de diseño y desarrollo, cuyas actividades son del
tipo de las que la empresa está en condiciones de llevar a cabo (ingeniería y
desarrollo).
■*" Caos no es eficiente, sin embargo, en tareas de fabricación. Carece de las

instalaciones para ello, así como de maquinaria especializada. Automatizar la
fabricación del ThermoPC exigiría contar con una máquina de inserción
automática de componentes, y con una máquina de soldadura de los mismos.
También sería conveniente disponer de una máquina para la fabricación de las
placas de circuito impreso. En su lugar, Caos pretende subcontratar la placa a
terceros, y montar manualmente los 6.000 dispositivos.
■*" Puede abaratarse el coste por unidad de la fase de fabricación adquiriendo o

alquilando la maquinaria necesaria, o subcontratando el montaje de los
dispositivos a una empresa que cuente con dichas infraestructuras.
La primera de las opciones, adquirir o alquilar la maquinaria, no parece muy viable.

Su coste es muy elevado, el tiempo de uso sería muy breve (es dudoso que alguien
alquile las máquinas para sólo dos meses), y haría falta un cierto tiempo adicional para
que el personal de Caos aprendiese a manejarlas. Además, Caos no cuenta con
instalaciones donde colocar y utilizar tales herramientas.
La segunda opción parece más atractiva. Poniéndose en contacto con el suministrador

de placas de circuito impreso, Armando localizó una empresa que, por 1,5 € (más
IVA) por placa, insertaba y soldaba los componentes, colocaba el conector y el cable,
y probaba el dispositivo. Por 0,17 € más, colocaba la caja (y tornillería), y la embalaba
en la caja de cartón, junto con su manual y diskette.
En las condiciones anteriores, la tabla de costes de la fase de fabricación queda como

sigue:
CONCEPTO COSTE CANT. TOTAL
Viajes y Estancias: proyecto 30,00 20 600
Viajes: garantía (2x35Km) 14,70 60 882
Placa circuito impreso 0,75 6.000 4.500
Componentes 2,10 6.000 12.600
Cables y conectores 1,30 6.000 7.800
Caja y tornilleria 0,60 6.000 3.600
Diskette/CD, duplicación y etiqueta 0,35 6.000 2.100
Copia del manual 0,15 6.000 900
Caja 0,10 6.000 600
Montaje 1,50 6.000 9.000
Embalaje 0,17 6.000 1.020
Ahora, los gastos se incrementan en 10.020 € pero, por el contrario, se ahorran las
3.360 horas de personal montador. En estas nuevas condiciones, el presupuesto para la
fase de fabricación sería el mostrado en la figura A. 10.
Como puede verse, las modificaciones anteriores han supuesto reducir el precio por
unidad, con IVA, a 16,75 €, con un margen del 20%, y a 13,96 €, sin margen. Ambas
cifras continúan siendo inaceptables para el Cliente.
3.5 Decisión
Revisando cuidadosamente las estimaciones realizadas, Armando es capaz de rebajar

algunos costes, pero no los suficientes como para eliminar el 34% de sobreprecio por
unidad. Analizando el proceso contable, Armando observa que el coste de cada unidad
suministrada (fabricada y montada fuera de Caos) es de 12,04 €, lo que no deja
margen para las labores de gestión, compras y garantía, si se quieren obtener unos
beneficios razonables.
Además, Armando no cree que este proyecto pueda calificarse de estratégico, ni por el
producto resultante, ni por el Cliente en particular.
Por último, las consideraciones anteriores refuerzan la idea de que Caos no es el tipo
de empresa más adecuada para este proyecto, que requeriría una organización más
pequeña, con personal más apropiado (de menor cualificación y coste), con menores
gastos generales y especializada en los procesos de fabricación involucrados (y que
disponga de la maquinaria requerida).
Por todo ello, Armando cursa una comunicación interna a sus superiores,
recomendando no presentar oferta al concurso convocado por hipermercados
Alaplaya. Como alternativas, caso de que exista una razón fundada para sí presentar la
propuesta, Armando plantea:
> Presentar una propuesta sólo para la fase de diseño y desarrollo, y no para
la de fabricación. Esta opción permitiría que la cadena Alaplaya
contratase a Caos el diseño, y encargase a otra empresa (especializada en
fabricación) la segunda fase. Esta forma de actuar sólo tendría sentido si
los hipermercados Alaplaya hubiesen recibido una oferta alternativa
buena en precio, pero no confiasen excesivamente en su capacidad para
diseñar un buen producto.
Presentar la propuesta para las dos fases, en el precio resultante de la

evaluación realizada (16,75 € por unidad). Esta forma de proceder podría
ser la más adecuada en el caso de que Alaplaya no recibiese ofertas en los
precios fijados (tal vez, simplemente, porque el precio de fabricación y
suministro indicado en el Pliego no sea razonable).
c RA-MA_____________ APÉNDICE A: EJEMPLOS DK EVALUACIÓN ECONÓMICA DE PROYECTOS 279
4. ANÁLISIS Y EVALUACIÓN DE UN PROYECTO EN

CURSO
A lo largo de este libro se ha prestado especial atención a la manera de evaluar los
costes y ejecutar un proyecto cualquiera. Pero partir de un "papel en blanco" es mucho
más fácil que encarar un proyecto a medias. Antes de comenzar el trabajo es sencillo
realizar hipótesis (más o menos afortunadas) para estimar el alcance, el tiempo y el
coste asociados a la ejecución de un trabajo, y preparar una estimación y una oferta
acordes con dichas hipótesis iniciales.
Pero los proyectos, después, evolucionan por cauces diferentes. Como si tuvieran vida
propia, se desvían de las previsiones y de la planificación inicial (tanto más cuanto
peor fuesen las estimaciones iniciales) por causa de las diferentes contingencias y
eventos no considerados en un primer momento.
Hay varios motivos por los que puede ser necesario analizar y evaluar un proyecto en
curso. Puede que el proyecto vaya mal, y sea necesario diagnosticar las causas para
prever mecanismos de corrección. Puede que sea necesario cambiar al responsable del
mismo, y el nuevo encargado deberá conocer el estado real antes de aceptar la
responsabilidad de su dirección. Puede incluso que el análisis intermedio del proyecto
sea un procedimiento habitual de la Dirección de la empresa en proyectos de coste,
duración o interés estratégico elevado.
En esta sección se muestra un ejemplo de evaluación de un proyecto en curso, que

sirve de modelo para realizar "auditorías" de trabajos en ejecución, y proporciona
algunas herramientas básicas para ello.
A finales de la pasada semana, Armando Bronca, Director de Proyecto de la sección

de ingeniería de Caos Consulting, y responsable (entre otros) del proyecto de Flores
del Sur (véase el capítulo tercero), notificó su intención de rescindir su contrato con la
empresa, al haberle sido ofrecido el cargo de responsable de relaciones con los clientes
de una conocida cadena de comida rápida.
Tras un primer momento de desconcierto, aprovechado por otros Directores de

Proyecto de Caos para repartirse su despacho, su ordenador, su secretaria y otras
"migajas", Sandra Mática, responsable de la sección de ingeniería, se reunió con
Agustín Bre, ingeniero sénior de la sección, para encomendarle la dirección, a partir
de ese momento, del proyecto de Flores del Sur.
4.2 Visión general del proceso de análisis y evaluación

Agustín comentó con la Sra. Mática su deseo de auditar y diagnosticar el proyecto
antes de asumir la responsabilidad del mismo. A esto respondió Sandra que por
supuesto, que no había ningún problema, pero que habría de asumir la responsabilidad
de todas maneras, salvo que sintiese una atracción especial por la otra actividad que
había reservado para él, consistente en cambiarle el aceite a la flota de automóviles de
la Policía Nacional.
Tras tan "halagüeña" y prometedora conversación, Agustín preparó una "estrategia"

de diagnóstico del proyecto, para hacerse una idea del estado técnico, planificación y
situación económica del mismo, basada en el procedimiento mostrado en la figura
A.ll.
Figura A.l 1 Procedimiento de auditoría y diagnóstico del proyecto
4.3 Obtención de información
Agustín se reunió con Armando Bronca. Después de darle la enhorabuena por su

nuevo empleo, así como una copia de su curriculum vitae (por si acaso), le solicitó la
documentación de gestión del proyecto Flores del Sur, así como una descripción
verbal del estado del proyecto.
Armando le proporcionó a Agustín la documentación de presupuesto del proyecto

(véase el apartado 5 del capítulo tercero), incluyendo:
> La descripción de los paquetes de trabajo.

> Las estimaciones y el presupuesto inicial.
> La planificación temporal prevista.
> El documento de oferta.
> El contrato firmado con Flores del Sur.
Además, le hizo entrega de la documentación de gestión (minutas, resúmenes, lista de

acciones, etc.) y del último informe de evolución económica del proyecto, al final del
tercer mes del mismo, y que se muestra en la figura A. 12.
Figura A.12 Informe de evolución del proyecto de Flores del Sur,

mes 3
Al entregarle dicho informe, Armando Bronca hizo los siguientes comentarios:
> El primer mes de proyecto se gastaron 36 horas suyas y 120 del ingeniero
júnior, debido a la necesidad de invertir más tiempo en la especificación
del sistema. Además, hizo falta reunirse en dos ocasiones más de las
previstas con el Cliente, por lo que los costes superaron ligeramente los
previstos.
> Los meses segundo y tercero no se produjeron desviaciones

significativas.
> El avance del proyecto es bueno, y está de acuerdo con las estimaciones
iniciales.
> Desde el punto de vista del Cliente, la nueva persona encargada de los
recursos informáticos, Amador Denador, es ligeramente confÜctiva, y
suele obligar a Caos a dedicar más esfuerzo del previsto, generalmente
dedicado a pequeños cambios sin importancia, en el trabajo realizado.
Además, y a modo de resumen, Armando le entrega el último informe de situación

económica del proyecto, reflejado en la figura A. 13.
A continuación, Armando Bronca convocó al equipo de trabajo del proyecto (al

ingeniero júnior y al técnico, pues la pobre secretaria estaba pasando a máquina la
última oferta de Sandra Mática), y les informó de la nueva situación, dejándoles acto
seguido con Agustín, para que tuvieran su primera charla de proyecto.
Una vez Armando hubo abandonado la sala de reuniones, Agustín habló con el equipo
de trabajo, y tras un breve diálogo insustancial, abordó el tema del exceso de horas
consumidas. Las razones y opiniones que le dio el ingeniero júnior fueron las
siguientes:
> El trabajo estaba muy mal definido desde el principio. La oferta no

especificó exactamente qué haría la aplicación de gestión de stocks, y
Amador Denador (Flores del Sur) pide cada día nuevas prestaciones para
la misma.
> Además, él mismo dedicó, para la fase de especificación y diseño, 120
horas frente a las 100 inicialmente previstas, a causa de dicha
indefinición.
> Además, creía que Armando, pendiente de su situación personal y
consciente de su próxima marcha de la empresa, no había sido lo
suficientemente estricto con el Cliente, y aceptó cambios sucesivos, sin
tener en cuenta el impacto sobre el coste del proyecto.
> Para terminar, era de la opinión de que el trabajo estaba ciertamente
retrasado, y que se necesitarían al menos otras 100 horas para terminar la
aplicación.
Figura A.13 Informe de situación económica del proyecto
Por su parte, el técnico de soporte le hizo saber que las tareas de adquisición e
instalación del hardware habían transcurrido bien, y que sólo fueron necesarias 60
horas, frente a las 80 inicialmente previstas. También dijo que llevaba adelantada
aproximadamente la mitad de la tarea de integración (se habían instalado los sistemas
operativos, y el entorno Access, a falta de integrar la aplicación final).
Para terminar, Agustín se reunió (previa presentación por parte de Armando) con
Warren González y Amador Denador de Flores del Sur. Durante la reunión, ambos se
mostraron razonablemente satisfechos con el trabajo en curso. Sin embargo, al
terminar la reunión y ya en el pasillo, Amador le hizo unos cuantos comentarios al
respecto:
284 D1RKCC10N Y GESTIÓN DE PROYECTOS
> La especificación del sistema le parecía un poco débil. Se omitieron

muchos detalles que son necesarios para que, luego, el sistema pudiera
ampliarse a la futura plataforma de gestión de stocks.
> El diseño era bueno, pero se apoyaba en los requisitos anteriores, por lo
que tampoco asegura la posibilidad de ampliarlo al futuro sistema.
> La implantación marchaba a buen ritmo, pero como había tenido que
intervenir durante la misma para corregir las deficiencias de la
especificación, aún faltaban dos o tres semanas de trabajo para terminar
la aplicación. Sin embargo, tampoco parecía un problema grave, puesto
que aún faltaba más de un mes para la Patrona del Tanganillo, fecha en la
que el sistema habría de estar listo para su uso.
4.4 Evaluación del avance y diagnóstico
Con todos los datos anteriores, Armando se dispuso a realizar una evaluación del
avance del proyecto. Para ello, obtuvo sendas gráficas del consumo de recursos del
proyecto, que se muestran en la figura A. 14.
A tenor de los datos obtenidos, las desviaciones principales del proyecto son las
siguientes:
> Hacen falta más horas de ingeniero júnior y, en concreto, en torno a dos
semanas más de trabajo intensivo (80 horas).
> Hace falta más esfuerzo de dirección y gestión, destinado a consolidar el
diseño con el Cliente, y a supervisar el estricto consumo de las horas
pendientes. Esto supondría unas 30 horas más de categoría IS, teniendo
en cuenta las que se han consumido en el "traspaso de poderes" entre
Armando y él mismo.
> Hace falta prolongar las actividades de desarrollo de la aplicación hasta la
segunda semana del cuarto mes, retrasar la integración HW/SW y
solaparlo con la preparación del curso.
> Dicho solape obliga a que el técnico de soporte asuma la mayor parte de
la preparación del curso, y que la intervención del ingeniero júnior en la
misma se limite a la supervisión de dicha preparación.
> Los gastos en concepto de viajes y estancias se incrementarán en otros
1.800 €, a causa del incremento de viajes resultado del "traspaso de
poderes" y del mayor esfuerzo de gestión.
Figura A.14 Recursos consumidos y remanentes en el proyecto:

horas (arriba) e ingresos/costes (abajo)
Con los datos anteriores, Agustín preparó una nueva estimación económica del
proyecto, modificando los valores inicialmente previstos, con lo que obtuvo los
resultados que se muestran en la figura A. 15.
Figura A.1S Estimación modificada para el proyecto Flores del Sur

© RA-MA ________________ APÉNDICE A: EJEMPLOS DE EVALUACIÓN ECONÓMICA DE PROYECTOS 287
A la vista de dichos datos, se desprende que" los cambios anteriores implican

incrementar el coste del proyecto en 7.086 €, hasta alcanzar los 54.371 €. Como el
contrato está firmado a precio fijo, y no es revisable al alza, no cabe la posibilidad de
renegociar el precio. En estas condiciones, manteniendo el precio de venta (60.000 €,
IVA incluido) el margen quedaría negativo, por valor de 2.648 € o, lo que es lo
mismo, el 4,87 % de pérdidas.
4.5 Conclusiones
Agustín Bre, una vez realizado el diagnóstico, transmitió el resultado del mismo a
Sandra Mática, argumentado en los siguientes puntos clave:
■s" Por diversas razones (falta de especificación y supuesta falta de control en los
últimos tiempos) el proyecto va retrasado en el tiempo, y va a ser necesario
incrementar las horas de esfuerzo y retocar al alza los gastos de viajes.
^ Dicha revisión implica un sobrecoste de 7.086 €, que conduciría a un margen

negativo del 4,87% (perder 2.648 €).
**■ La planificación puede corregirse para que, ampliando la duración de las

actividades de desarrollo y solapándolas con las de formación, no sea
necesario corregir la fecha de finalización prevista.
Como los valores económicos resultantes eran claramente inaceptables, Agustín

propuso asignar la partida de contingencias inicialmente prevista (1.661€, descontando
los 270 ya consumidos) al cambio de Director de Proyecto (y suponer que ya no habrá
más contingencias durante el mes restante de trabajo), con lo que el margen pasaría a
ser del -1,8% (pérdidas de 987 €).
A la vista de lo anterior, la Sra. Mática tomó las siguientes decisiones:
*" Transmitir a Agustín Bre su favorable impresión con respecto al diagnóstico

formulado, y su decisión de que se encargase, a partir de ese momento, del
proyecto de Flores del Sur, corrigiendo los defectos detectados hasta el
momento.
■*" No aceptar el nuevo margen del -1.8%, para lo que conminó a Agustín a
obtener un 4,6% positivo (2.500 €) aplicando las siguientes medidas:
> No incrementar el número de horas disponibles para dirección y gestión
(las horas de Agustín), quien tendría que hacer un "esfuerzo" adicional
para sacar tiempo de otro lado (clara alusión a extender su horario de

trabajo, gratuitamente).
Ahorrar en torno a 1.000 € en viajes y gastos de estancia, utilizando
transportes y tarifas más económicas, o reduciendo el número de
desplazamientos.
APÉNDICE B
GESTIÓN DE PROYECTOS DE
DESARROLLO DE
SOFTWARE
1. INTRODUCCIÓN
La dirección y gestión de proyectos donde el objeto principal es el desarrollo o

mantenimiento de software05 no debería, en principio, ser muy diferente de la gestión
de cualquier otro proyecto. En concreto, deberían ser aplicables todas las técnicas y
herramientas descritas en este libro.
Y, en general, así es. Pero sin embargo, el desarrollo de programas software es una
tarea peculiar. El desarrollo de aplicaciones software es una tarea de muy alto valor
añadido. Prácticamente no se transforma materia alguna (salvo el intelecto de los
programadores), y "de la nada" se crean, con inversiones muy reducidas, aplicaciones
informáticas cuyo precio de mercado puede superar ampliamente el del más afinado
ingenio mecánico o electrónico.
Un programa de ordenador está compuesto por miles, a veces millones de líneas de

código, que se diseñan y desarrollan poco a poco, y se integran para formar rutinas,
módulos y programas,
Validar y verificar0'5 la calidad de un programa software no es sencillo. Cada una de

las líneas que lo componen está sujeta a errores, al igual que lo está el orden relativo
65
Software: programas, procedimientos, reglas y documentación asociada que se relaciona con
el funcionamiento de un sistema informático.
66
Los términos "validar y verificar" implican una doble acción: por un lado, probar
formalmente que el programa desarrollado responde a los requisitos del usuario y, por otro,
demostrar que funciona correctamente, sin errores.
en que se colocan las mismas, o el momento en el que se ejecutan. Por esta razón, y
teniendo en cuenta que cada línea se ejecuta sólo bajo determinadas circunstancias,
pueden pasar años hasta que se detecte un error en un programa67.
Un programa debidamente diseñado, desarrollado y probado es fácil de mantener,

sencillo de corregir y resulta económico actualizarlo y ampliarlo. Por el contrario, una
aplicación software mal diseñada o implementada es más propensa a errores, más
difícil de mantener, y su coste de ampliación se dispara.
Teniendo en cuenta estos hechos, así como la ingente cantidad de aplicaciones

informáticas que se desarrollan en nuestros días, junto con las particularidades de un
proyecto de este tipo, parece interesante abordar el problema, y analizar qué
características específicas conviene tener en cuenta, eventualmente, en la gestión de
proyectos de desarrollo de software. Estas características específicas tienen una fuerte
incidencia sobre el coste y el plazo de desarrollo, y no deben ser menospreciadas a la
hora de valorar el esfuerzo asociado al desarrollo de programas de ordenador.
2. CICLO DE VIDA DE UN PROYECTO DE DESARROLLO

DE SOFTWARE
El concepto de ingeniería del software engloba el conjunto de técnicas y

herramientas que se utilizan para desarrollar y poner en funcionamiento un programa o
aplicación que resuelva un problema concreto. Estas metodologías, en principio
independientes del problema concreto a resolver, son el resultado de varias décadas de
experiencia en el desarrollo y la utilización de software.
La ingeniería software parte del concepto de ciclo de vida de un programa

informático, y que incluye el conjunto de actuaciones y procesos que deben tenerse en
cuenta desde antes de que comience el desarrollo, y hasta que los programas
resultantes dejan de ser utilizados (por lo general, mucho después de poner en marcha
el sistema). En dicho ciclo de vida participan, tal y como se muestra en la figura B.l,
todos los agentes involucrados en la especificación, diseño, desarrollo, validación y
uso del software.
67
Y como botón de muestra, quién no recuerda el lamentablemente famoso "efecto 2.000", que
obligó a "de purar" mill ones de progra ma s e n t odo el mundo, algunos de ell os muchos a ños
después de haber sido creados.
68
Los aspectos más metodológicos (y menos "Je gestión") de este capítulo se han tomado de
otras obras que tratan específicamente temas de ingen iería software, entre las cuales merece la
pena mencionar los estándares de ingeniería software que utiliza la Agencia Espacial Europea
(ESA), fa miliar me nte c onocidos por s us si glas e n i nglés , E CS S (E ur ope an C oope r ation f or
Space Standardizatiori).
APÉNDICE B: GESTIÓN DE PROYECTOS DE DESARROLLO DE SOFTWARE 291
Figura B.l Interrelación de los agentes que configuran el proceso

de desarrollo de software
2.1 Fases del ciclo de vida
Aunque existen muchas metodologías de desarrollo de software y, por tanto, muchas

variedades dentro de la descripción del ciclo de vida, en realidad todas ellas
comprenden los mismos pasos y las mismas técnicas, si bien con nombres diferentes y
orientadas a clases de software ligeramente distintos. No obstante, en todo ciclo de
vida aparecen, más o menos, las siguientes fases:
^ Fase de análisis y planificación del sistema. Comprende:

> Definición de requisitos de usuario (RU).
> Definición de requisitos software (RS).
*• Fase de desarrollo. Incluye:
> Diseño de la arquitectura (DA).
> Diseño detallado y codificación (DD).
> Transferencia (TR).
*" Fase de operación y mantenimiento (OM).
2.1.1 FASE DE ANÁLISIS Y PLANIFICACIÓN
Si no se sabe exactamente qué es lo que hay que hacer, difícilmente se conseguirá

hacerlo, y más difícil aún resultará evaluar si se ha hecho lo que se pretendía. La fase
de análisis y planificación tiene como objeto definir exactamente qué es lo que se
pretende que el software a desarrollar haga, y cómo queremos que lo haga,

respondiendo a preguntas tales como:
> ¿Qué es lo que debe hacer el sistema?

> ¿Qué es lo que debe hacer el software a desarrollar?
> ¿En qué condiciones debe funcionar?
> ¿Qué limitaciones tendrá?
> ¿Cómo se implantará?
> ¿Qué recursos materiales, temporales y humanos hacen falta para ello?
> ¿Cómo se verificará que el sistema funciona correctamente?
La fase de análisis y planificación comienza con la definición del sistema global

(hardware, software, etc.) y la caracterización del problema a resolver, de donde se
extraen las pertinentes conclusiones acerca de las restricciones temporales,
económicas, etc.
La primera parte del análisis y planificación es la fase (o sub-fase) de definición de

los requisitos de usuario (RU), donde, a partir de la documentación del sistema,
entrevistas con el Cliente o usuarios, construcción de prototipos o cualquier otro
procedimiento que se estime oportuno, se "capturan" los requisitos que debe cumplir
el sistema con el fin de que satisfaga las necesidades del usuario.
El resultado de la fase RU es el documento de requisitos de usuario (DRU), que

debe negociarse con el Cliente y ser aprobado y congelado, como piedra angular del
desarrollo posterior, durante la reunión conocida como revisión de requisitos de
usuario (RRU).
A continuación se reseñan algunos aspectos de interés aplicables a la fase de

especificación de requisitos de usuario (RU):
^ La definición de los requisitos de usuario es responsabilidad única del usuario,

aunque participe o colabore el contratista^0 y el equipo de desarrollo.
*" Es conveniente distinguir entre requisitos necesarios y deseables. De esta
manera se facilita la labor de análisis de esfuerzo, plazos y costes, y es posible
proponer alternativas de prestaciones o alcance reducido en función del plazo
o presupuesto disponible. En concreto, facilita planificar un modelo de
desarrollo incremental o evolutivo (véase el apartado 2.2, en el que se
describen tales modelos de desarrollo), donde no toda la funcionalidad
prevista está disponible en la primera versión del software.
69
En los proyectos de desarrollo de software, tal vez en mayor medida que en otro tipo de
proyectos, es frecuente que las figuras del usuario y del Cliente (o contratista) estén disociadas.
Todo requisito de usuario debe ser verificable. Sólo de esta manera se asegura
que, al final del desarrollo, será posible determinar sin ambigüedad si el
resultado cumple o no cumple las condiciones contractuales fijadas.
Al terminar de especificar los requisitos de usuario, y antes de comenzar con

la siguiente fase, es preciso revisar formalmente dichos requisitos (durante la
reunión RRU, de revisión de requisitos de usuario).
Todos los requisitos conocidos deben figurar en el documento de requisitos de

usuario (DRU). El software desarrollado no tiene por qué satisfacer requisitos
no contemplados en dicho documento.
Una vez se dispone del DRU (documento de requisitos de usuario) comienza la fase de
análisis de los mismos, conocida como definición de requisitos del software (RS). El
objetivo de esta fase es construir un modelo conceptual de lo que debe hacer el
software (pero no de cómo lo hace), estimar el coste asociado al mismo (con una
precisión aproximada del 30%), y definir las responsabilidades individuales dentro del
equipo de trabajo.
Los objetivos anteriores, resultado de la fase RS, se plasman en el documento de

requisitos del software (DRS), que se revisa con el Cliente y el equipo de trabajo
durante la reunión de revisión de requisitos del software (RRS). El documento de
requisitos del software debe abordar, al menos:
> Requisitos funcionales: qué hace el software.

> Requisitos de prestaciones: a qué velocidad, con qué precisión, etc.
(siempre valores cuantificables y medibles).
> Requisitos de interfaz: cómo se manejará, desde el punto de vista del
usuario, o desde el punto de vista de la interconexión con otros programas
o equipos.
> Requisitos operativos: en qué plataforma se ejecutará, con qué sistema
operativo.
> Requisitos de recursos: cuánta memoria necesita, qué tipo y velocidad de
microprocesador.
> Requisitos de verificación: cómo se podrá comprobar que el software
funciona correctamente.
> Requisitos de aceptación: qué condiciones habrá de cumplir para ser
aceptado por el Cliente.
> Requisitos de documentación: qué tipo de documentación y en qué
formato habrá de adjuntarse al software.
^ Requisitos de seguridad™: cómo se garantizará la ausencia de riesgo

derivado del uso del software, para las cosas y las personas, y cómo se
protegerá el software contra acceso o uso no autorizado.
Requisitos de portabilidad: qué características tendrá que cumplir para
utilizarlo con otra plataforma hardware o en un entorno operativo distinto
al inicialmente especificado.
Requisitos de calidad y Habilidad: cómo se asegurará la calidad del
software a desarrollar, y cómo se evaluará la fiabilidad del mismo.
Requisitos de mantenibilidad: qué condiciones tendrá que cumplir para,
en el futuro, poder modificar o mejorar su funcionalidad o sus
prestaciones.
Requisitos ambientales: hacen referencia al volumen, masa, consumo,
temperatura de funcionamiento, etc. En general, son requisitos del
sistema completo, y no sólo del software.
Con respecto a la especificación de requisitos del software (RS), son de interés las
siguientes consideraciones:
**" Todo requisito del software deberá hacer referencia al requisito de usuario del
que se deriva, permitiendo así "trazar" el origen de los requisitos y facilitar su
verificación.
•* Es conveniente propagar el carácter de esencial o deseable de los requisitos de

usuario a los requisitos del software, para facilitar la planificación de modelos
de ciclo de vida incremental o evolutivos.
**" Todo requisito del software deberá ser verifícable.
^ Al terminar de especificar los requisitos del software, y antes de comenzar con

la siguiente fase, es preciso revisar formalmente dichos requisitos (durante la
reunión RRS, de revisión de requisitos del software).
^ Todos los requisitos conocidos deben figurar en el documento de requisitos

del software (DRS). El software desarrollado no tiene por qué satisfacer
requisitos no contemplados en dicho documento.
** Si se identifican requisitos cuya redacción o cuantificación no es aún posible,

también se incluirán en el DRU, indicando que el alcance concreto del
La terminología anglosajona distingue entre dos tipos de seguridad: la integridad de las

personas y los objetos materiales (safety), y la capacidad de resistir ataques e intentos de acceso
no autorizado (security).
>-MA________________ APF.NDICH B: GESTIÓN PC PROYECTOS DE DESARROLLO DE SOFTWARE 295
requisito está aún por definir (TBD, To Be Defined) o por confirmar (TBC, To
Be Confirmed).
^ Ningún requisito de usuario quedará sin reflejar en el DRS. En concreto, el

DRS incluirá una tabla donde se muestre la correspondencia entre requisitos
de usuario y requisitos del software.
■*" Los requisitos del software no harán referencia alguna a detalles de

implantación y, en especial, no harán referencia a la plataforma, ni a las
herramientas ni al compilador, salvo que se trate de restricciones para la fase
de diseño.
*" Los requisitos se describirán en términos de lo que el software deberá ser

capaz de hacer, y no de cómo lo hará.
La figura B.2 muestra el conjunto de actividades asociadas a la fase de planificación y

análisis del sistema.
Figura B.2 Fase de análisis y planificación
Es importante tener en cuenta que al concluir esta fase se da por terminada la

participación directa del Cliente o usuario, como parte interesada en el proceso de
definición del trabajo. A partir de este momento, al comenzar la fase de desarrollo, el
Cliente pasa a ser un supervisor del avance de los trabajos, como en cualquier otro tipo
de proyecto. Por esta razón, es conveniente, tal y como refleja la figura B.3, no dar por
terminada la parte de análisis y planificación mientras no se cuente con una
aprobación formal de los requisitos por parte del Cliente.
DESARROLLO
SOFTWARE
RRU /
RRS
APROBACIÓN
GESTOR / USUARIO
Figura B.3 No es conveniente comenzar el desarrollo mientras no
se hayan aprobado formalmente los requisitos de usuario y del
software
LECTURA. ESPECIFICACIÓN DE REQUISITOS DE USUARIO
Cualquiera que haya trabajado en un proyectó real sabe lo difícil que es dejar al
Cliente totalmente satisfecho. Es preciso terminar el trabajo, de forma correcta,
en el tiempo estimado, y con el coste previsto. Pero, de lo anterior, si bien el
plazo y el coste son magnitudes cuan tifi cables, ¿qué significa exactamente "de
forma correcta"!
La mayor parte de las discrepancias entre el Cliente y el equipo de trabajo a

hora de ejecutar un. proyecto; se derivan de la dificultad para satisfacer k
requisitos del usuario (sea o no el cliente final}. El trabajo realizado no satisfaz
las expectativas del Cliente, o no cumple al 100% con sus especificaciones.
Dar por terminado un trabajo cuando el usuario no está satisfecho no sólo aboc
a perder el Cliente, sirio que provoca un grado de insatisfacción, una pérdida
imagen y un sobreesfuerzo para reconducir el problema nada deleznables.
La raíz del conflicto reside* -en la mayor parte de los casos, en una
mí lecificación de ios requisitos de Usuario (o de] Cliente).
Alcance del proyecto
A menudo, un proyecto suele comenzar con una idea vaga acerca del
mismo al implantar una red de área loca", "desarrollar una base de
datos aplicación para gestión de pedidos1', "diseñar un chalet pareado
APÉNDICE B: GESTIÓN DH PROYECTOS DE DESARROLLO DE SOFTWARE 297
Además, el esfuerzo necesario (y el coste asociado) a l a ejecución de una tarca

depende fuertemente de estos detalles. No es lo* miséio una red de área local con
Windows que con UNIX. Ño cuesta igual desarrollar una base de datos
relacional con una irrterfaz: de usuario basado en ventanas qite un registro de
pedidos básico. No supone el mismo esftjerzo diseñar y edificar una pared en el
interior de un recinto que a la intemperie.
Los detalles concretos del proyecto, los requisitos, deben quedar claros antes de
comenzar a ejecutar el trabajo. El nivel ée especificación debe ser tai que
constriña ía solución de forma que, manteniendo los requisitos,, el Cliente no
pueda solicitar cambios ni modificaciones que supongan ui> esfuerzo adicional
significativo. . :
El problema de la definición (y especificación) de requisitos es la gran cantidad

de tiempo y esfuerzo que «uele suponer, Peor aún, a menudo el Cliente (que no
es experto en la materia) no desea participar en tina ronda de preguntas, de
detalles técnicos que no conoce, y prefiere transmitir sus necesidades de manera
más ambigua y relajada. Esta fornia.de colifiarse ingenuamente a la capacidad
del equipo de trabajo para imaginar y acertar sus -deseos es claramente una
fuente de conflictos posteriores.
Especificación de requisitos
Ponernos a trabajar en un diseño sin establecer antes los requisitos

nciales, corremos el riesgo de <jue dicho diseñó!. . " " . . " " No satisfaga los
requisitos básicos del Cliente. '.'' ."_' ;. No satisfaga otro tipo de
requisitos: aspecto, mtérfaces, prestaciones, etc.
El problema reside siempre en que el Cliente nos transmite el concepta del

problema, que ha de convertirse en requisitos de usuario, que s,e utilizan para
el diseña y construcción del objeto del trabajo (un sistema,, un circuito» tm
programa, etc.).
Salvo que el Cliente se involucre en la transformación del concepto a requisitos,

lo más probable es que nuestra interpretación no se ajuste al «en por cien a los
deseos del Cliente. Es, pues, necesario que el Cliente participe en la fase de
especificación del sistema.
298 DIRECCIÓN Y GESTIÓN Dt; PROYECTOS
Figura B.4 Evolución de un proyecto y actuaciones de validación y

verificación
ILa mejor manera de evitar readaptaciones y modificaciones posteriores al

sistema desarrollado es especificar correctamente el mismo desde el principio.
Aunque suele ser práctiea habitual que el Cliente se desentienda del proceso de
aseguramos que, después, será trivial determinar si tenemos o no obligación de

realizar los cambios que el Cliente pueda requerir. - - .;.;;;;;;;;; \ ;;;\
Especificación de requisitos
Los requisitos deben ser identificados tan pronto se comience con el trabajo (o,
preferiblemente, antes, para valorar económicamente el mismo con mayor
precisión), y escritos para, posteriormente, someterlos a la aprobación del
Cliente antes de comenzar el diseño del sistema.
A continuación se incluye un "decálogo", cot> algunas reglas básicas para

escribir los requisitos del sistema:
1. Separar requisitos según el tipo, anteriormente indicado (funcionales,

prestaciones, interfacesa etc.).
2. Escribir requisitos claros, breves y no descomponibles en requisitos más
3. Escribir requisitos de forma que sean útiles para el proveedor (o diseñador)

c inteligibles para el Cliente.
4. Escribir requisitos autocontenidos, que tengan significado en sí mismos, y

no duplicados en otros requisitos.
5. Escribir requisitos completos, esto es, que al juntarse con tos demás
requisitos no dejen "huecos" sin especificar
6. Escribir requisitos, y no soluciones de diseño (por ejemplo, en una red

LAN, especificar la velocidad y el alcance, y no el tipo de cable, salvo que
sea estrictamente necesario), '
7. Escribir requisitos que, a la hora de entregar el producto/sistema al Cliente,

sean fáciles de verificar por él mismo, indicar el procedimiento de
verificación cuando sea necesario.
8. Distinguir entre requisitos necesarios y requisitos deseables. Estos últimos

son aquellos que mejoran el sistema, pero que implican un incremento de
esfuerzo y/o coste apreciable, no siendo imprescindibles para el Cliente
(quien, en última instancia, debe admitir su no cumpHniiento).
9. Identificar los requisitos, aun cuando todavía no puedan caantificatse, con

el valor paramétrico sustituido por TBD (To Be Defined). Por ejemplo, a la
hora de especificar un equipo de radio» puede que no existan requisitos
específicos de volumen y peso pero, a la larga, tales requisitos acabarán
300 DIRBCC1ÓN Y GESTIÓN DE PROYECTOS
apareciendo. Es preferible identificarlos y no cuantiiicarlos, por ejemplo, de

Ia;rsiguie^te\ «lanera:. :>£i .peso del equipo no excederá los (TBD)
líUp'gr&wos".
10. Lo mismo sucede con los requisitos aún no congelados, donde la falta de
confirmación se indicará mediante las Siglas TBC (To B% Confirmed). Por
ejemplo, si el'Cliente aún no sabe cuántos equipos tendrá que mterconectar,
finalmente, se indicará, por ejemplo, como "£1 sistema habrá de
intereomefar entre 7y 10 equipos (TBG/\
Finálniente, en la iiteratura anglosajona; se dice que Gada requisito de la

espeGÍñcación tiene que ser "SMART'. SMART, además ée "inteligente", en
inglés, son las siglas de;
S de "specifk" o, en español Concreto

M . ÚQ^measwúbW'o, en español Cuantifícable
A de "'achievahíe^-Q, en español Realista
R de "re/evemf* o. en español; Pertinente
J . de ^tfackahié" o, en español Verifícable
Pero esto, a juicio del áutpr, no es masque un "inteligente" juego de letras.
2.1.2 FASE DE DESARROLLO
La fase de desarrollo comienza tras la aprobación formal de los requisitos del software
por parte del usuario o Cliente, y abarca hasta la puesta en fiincionamiento del sistema,
incluyendo tres sub-fases, de diseño de alto nivel, diseño detallado y transferencia.
La fase (o sub-fase) de diseño de alto nivel, también conocida como diseño

arquitectónico" (DA), tiene por objeto definir la estructura del software a desarrollar
a partir del modelo establecido en la fase RS. Dicha arquitectura se obtiene asignando
funciones a componentes software, y definiendo los flujos de datos y de control entre
dichas componentes.
Como resultado de la fase DA se obtiene el documento de diseño arquitectónico

(DDA), que se aprueba durante la reunión de revisión del diseño arquitectónico
(RDA). A continuación se reseñan algunos aspectos de interés aplicables a la fase de
diseño de alto nivel (DA):
71
La errónea traducción de bibliografía anglosajona está generalizando el uso y enquistando en
los documentos técnicos el término diseño arquitectural que, por supuesto, no aparece incluido
(hoy por hoy) en e! diccionario.
RA-MA _______________ Al'HNDICK B: GKSTIÓN »K PRQYHC'l'OS DF. DESARROLLO DE SOFTWARE 301
** Durante la fase de diseño de la arquitectura se adoptará y comenzará a utilizar

una metodología de diseño software concreta y reconocida.
^ La arquitectura del software se descompondrá en unidades de menor

complejidad. Preferiblemente se adoptará una metodología de tipo top-down.
^ Para cada elemento o componente del software se indicarán y describirán, al

menos, los datos de entrada, las funciones que desempeña y los datos de
salida.
"* Se estimarán durante esta fase los requisitos computacionales (CPU, memoria
y disco) para el entorno de desarrollo y el entorno operativo.
*" El resultado de la fase DA se revisará formalmente durante la reunión de

revisión del diseño arquitectónico (RDA).
<r
El resultado de la fase DA se plasmará en el documento de diseño de la
arquitectura (DDA), que contendrá, al menos, los principales componentes del
software y las interfaces entre ellos.
** El DDA incluirá una tabla donde se muestre la correspondencia entre

requisitos del software y elementos del diseño de alto nivel.
Tras la fase de diseño arquitectónico comienza la fase de diseño detallado (DD),

donde se refina hasta los detalles más significativos el diseño de alto nivel de la fase
anterior, se codifica, documenta y prueba.
Como resultado de la fase de diseño detallado se obtiene, aparte del código del
programa, el documento de diseño detallado (DDD) y el manual de usuario del
software (MUS), que se revisan durante la reunión de revisión del diseño detallado
(RDD).
Una parte importante del esfuerzo de la fase de diseño detallado se consume en la

verificación y pruebas del software, que debe realizarse a cuatro niveles diferentes:
> A nivel de unidad software.

> A nivel de integración de todas las unidades software.
> A nivel de validación del software con respecto a los requisitos del DRS.
> A nivel del sistema completo, según los requisitos de usuario (DRU).
302 D1RRCCION Y GESTIÓN DE PROYECTOS
Algunos aspectos de interés aplicables a la fase de diseño detallado (DD) son los que
se mencionan a continuación:
*■ Durante la fase de diseño detallado (DD) se descompondrá la arquitectura de

alto nivel en unidades de código, se codificará utilizando una metodología
concreta y reconocida, y se generará la documentación asociada.
■*■ Antes de aceptar cualquier unidad de código, cada una de las sentencias o
comandos del mismo deberá ejecutarse satisfactoriamente al menos una vez.
'*■ Todo módulo desarrollado será objeto de un test de integración.
^ El resultado de la fase DD será el código desarrollado, el documento de diseño

detallado (DDD) y el manual de usuario (MU).
^ El DDD incluirá una tabla donde se muestre la correspondencia entre

requisitos del software y módulos del diseño de detallado.
El software así diseñado, codificado y validado está listo para entrar en la fase de
transferencia (TR). En esta fase se instala el software sobre la plataforma (hardware)
final, se llevan a cabo los test de aceptación especificados, y se comprueba que el
programa satisface los requisitos para los que fue concebido. En tales condiciones, el
software recibe la aceptación provisional, y comienza su operación y uso.
Durante la fase de transferencia se genera el documento de transferencia (DTR),

donde se describen las actuaciones de instalación y verificación realizadas, así como el
documento de aceptación provisional.
A continuación se reseñan algunos aspectos de interés aplicables a la fase de

transferencia (TR):
^ En las pruebas de aceptación participará el usuario y el equipo de desarrollo.
■*" Las pruebas de aceptación fallidas darán lugar a cambios en el diseño del
software.
*" La verificación de que el software cumple los requisitos definidos abocará a la

aceptación provisional del mismo.
*" El resultado de la fase de transferencia incluirá el conjunto de informes de

aceptación, junto con la documentación asociada a los cambios realizados
durante la fase TR.
© RA-MA ________________ AFKNDK'F. R: GRSTION DE PROYECTOS DE DESARROLLO DK SOF rWARI: 303
La figura B.5 resume de forma gráfica las actividades y flujos descritos para la fase de
desarrollo del software.
Figura B.5 Fase de desarrollo
2.1.3 FASE DE OPERACIÓN Y MANTENIMIENTO
Muchos equipos de trabajo tienden a creer que su misión ha terminado cuando el

software está instalado y funcionando en las instalaciones del Cliente. Y sin embargo,
rara vez es así. Las peculiaridades de un producto software, tal y corno se describieron
al comienzo del apéndice, hacen que sea necesario supervisar el correcto
funcionamiento del mismo durante bastante tiempo después de haber sido entregado.
Tomemos como ejemplo un requisito de disponibilidad o de fiabilidad del sistema, o
un requisito (muy de moda hace algunos años) derivado del efecto 2000. Es muy
difícil garantizar de antemano que el programa se comportará adecuadamente en
circunstancias no previstas, o pasado un cierto tiempo, por lo que los test de
aceptación suelen incluir, a petición del Cliente, pruebas a largo plazo del software.
Esta fase de supervisión (y corrección de los vicios o defectos del producto) recibe el
nombre de fase de operación.
Sólo después de transcurrido ese intervalo el Cliente acepta definitivamente el

software, provisionalmente aceptado al terminar la fase de transferencia.
Al cabo del tiempo, el software definitivamente aceptado puede tener que ser
modificado, bien como consecuencia de errores detectados, bien como repuesta ante
nuevas necesidades del usuario. Esta fase recibe el nombre de fase de mantenimiento.
Durante la fase de operación y mantenimiento (OM), tal y como se muestra en la

figura B.6, se genera y actualiza el documento de historia del proyecto (DHP), que
reúne todos los errores y todas las modificaciones realizadas sobre el software, y que
permite calcular y analizar la fiabilidad del software, y el rendimiento del equipo de
trabajo (para futuros proyectos).
Figura B.6 Fase de operación y mantenimiento
2.2 Tipos de ciclo de vida
En el apartado anterior se describieron las 6 fases que todo proyecto de desarrollo

software debe contemplar: RU, RS, DA, DD, TR y OM. A continuación, es preciso
adoptar un modelo de ciclo de vida que defina en qué secuencia relativa se ejecuta
cada fase y, sobre todo, cómo se incorporan al ciclo de vida básico las subsiguientes
revisiones y cambios al software.
2.2.1 MODELO EN CASCADA
La figura B.7 muestra el ciclo de vida en cascada (o waterfalf). Es el modelo más

simple posible, conformado sin más que encadenar secuencialmente cada una de las
fases del ciclo de vida del proyecto.
©RA-MA APÉNDICE Bi GESTIÓN DE PROYECTOS DE DESARROLLO DE SOFTWARE 305
Figura B.7 Ciclo de vida en cascada (waterfalt)
En el modelo en cascada, cada fase se ejecuta una única vez, a continuación de la que
le precede y con inmediata anterioridad a la que le sigue. La única variación al
esquema secuencial se permite cuando en una fase se detectan errores o cambios que
deben introducirse, mediante iteración, en la fase inmediatamente anterior. Estas
interacciones se representan en la figura B.6 mediante flechas discontinuas.
El software desarrollado se entrega, en un único evento temporal, al final de la fase de

transferencia (TR).
Esta aproximación secuencial es válida para proyectos simples y de corta duración. El

proceso secuencial simplifica mucho las labores de gestión, y abarata el producto
resultante.
2.2.2 MODELO INCREMENTAL
El modelo incremental (que se representa gráficamente en la figura B.7), coincide con

el modelo en cascada hasta el final de la fase de diseño de alto nivel (DA). A partir de
ese momento, las fases DD, TR y OM se descomponen en un cierto número de
unidades menores, más simples y manejables, que se implantan por separado.
El objeto de este modelo es permitir entregas (releases) múltiples del producto, en

diferentes hitos temporales, lo que tiene mucho sentido, por ejemplo:
•" Cuando algunas funciones se necesitan antes que otras.
*■ Cuando es recomendable evaluar una versión antes de completarla con más

funcionalidad.
•■ Cuando el presupuesto para el desarrollo debe repartirse entre diferentes años

o ejercicios.
306 DIRECCIÓN Y ÜBSTION DE PROYECTOS
En cualquiera de los casos anteriores se supone que cada entrega funciona y puede
utilizarse por separado, incluso aunque tenga la funcionalidad restringida.
En la figura B.8 se observa cómo el ciclo de vida, para la primera entrega, coincide
con un ciclo de vida en cascada. En el momento en que finaliza la transferencia y se
produce la aceptación, sin embargo, comienza una nueva fase de diseño detallado y
transferencia (en paralelo con la operación y mantenimiento de la entrega inicial), en
la que se implanta la funcionalidad resultante del diseño de alto nivel, pero que no
pudo ser implantada en la primera versión.
Figura B.8 Ciclo de vida incremental
Tan pronto como la segunda entrega está disponible se da por concluida la fase de
operación y mantenimiento de la primera versión, que se sustituye por la segunda.
Puede haber, por supuesto, un número indefinido de versiones y entregas, pero todas
ellas basadas en los requisitos y en el diseño arquitectónico inicial.
Uno de los principales problemas de este modelo es la complejidad añadida a la

gestión del proyecto (en tiempo y recursos) frente al modelo en cascada, y el
sobrecoste asociado a desarrollar versiones separadas. Además, con este modelo se
complica y encarece el proceso de validación y prueba de cada versión.
& RA-MA _______________ APENÜICK B: GESTIÓN DE PROYECTOS DE DESARROLLO DE SOFTWARE 307
2.2.3 MODELO EVOLUTIVO
El ciclo de vida evolutivo (que se muestra en la figura B.9) se diferencia del

incremental en que no se reaprovechan las fases de requisitos ni de diseño
arquitectónico, y que todas las versiones del producto son el resultado de un ciclo
completo que incorpora toda la experiencia de los ciclos precedentes.
El modelo evolutivo se utiliza cuando existe la intención, a priori, de liberar en el

tiempo varias versiones del mismo desarrollo software. Es el modelo aplicable, por
ejemplo, a las sucesivas versiones del sistema operativo Windows y de tantos otros
sistemas y aplicaciones. Las motivaciones son, entre otras:
Se necesita que el usuario experimente con una versión inicial antes de estar
en condiciones de definir con más detalle los requisitos de usuario.
Se depende de nuevos desarrollos tecnológicos, que deberán incorporarse en

versiones futuras (por ejemplo, ordenadores más rápidos o con más memoria,
estándares de interfaz o comunicaciones en fase de consolidación, etc.).
Se cuenta con especificaciones y requisitos de usuario que aún no son firmes,

o no están lo suficientemente consolidados.
No hay tiempo suficiente para satisfacer todos los posibles requisitos, dejando
algunos de ellos para futuras versiones.
Como puede observarse en la figura B.9, cada versión del software se genera de
manera independiente. Cuando finaliza cada fase de transferencia se supervisa la fase
de operación y mantenimiento para capturar o consolidar los nuevos requisitos. Cada
vez que se dispone de dichos requisitos en número y detalle suficiente se da comienzo
a un nuevo proceso de especificación, diseño y desarrollo, que termina con la fase de
operación anterior tan pronto como existe una nueva versión disponible para ser
transferida.
Figura B.9 Cielo de vida evolutivo
Este modelo de desarrollo, tan común en nuestros días, no carece de inconvenientes.

La multiplicidad de versiones, y el hecho de que en cada una de ellas haya que
rediseñar y revalidar gran parte del sistema, hace que, al final, el coste del software
(coste por línea de código) se dispare con respecto al modelo en cascada, mientras que
la complejidad de la gestión del proyecto se incrementa de manera acorde.
Además, el modelo evolutivo obliga a mantener "vivas" varias versiones a la vez, en

el caso de que haya más de un usuario y no se produzca un cambio coordinado de
versiones entre todos los usuarios a la vez. Los costes asociados al control de
configuración del proyecto (véase el apartado 4 de este apéndice) se incrementan de
manera notable. También provoca frustraciones en los usuarios, que perciben cada
versión como una corrección de errores de la anterior y, en definitiva, como un
software aún no terminado por completo.
3. EVALUACIÓN ECONÓMICA
Pero el propósito de este apéndice no es servir como introducción a la ingeniería

software, pues ya existen múltiples referencias bibliográficas de gran calidad que
abordan ese tema en exclusiva. Más al contrario, el objetivo de estas secciones es
ayudar al responsable de un proyecto a identificar las peculiaridades de un trabajo de
este tipo que tienen incidencia sobre los aspectos de gestión del mismo, es decir,
sobre:
> La descomposición en actividades y tareas.

> La configuración del equipo de trabajo.
© RA-MA APÉNDICE B: GESTIÓN DE PROYECTOS DE DESARROLLO DE SOFTWARE 309
> La planificación más adecuada.

> El riesgo en el que se incurre.
> El control de configuración de los elementos del proyecto.
Y, en concreto, ayudar a estimar el coste asociado a realizar el proyecto.
Evaluar el coste de ejecutar un desarrollo de software es tarea compleja. El alto valor

añadido del proceso, el carácter casi intangible del producto, y la dificultad para
adecuar procesos informáticos a necesidades de usuario (con una cierta dosis de
subjetividad en muchos casos) hacen que la tareas de valoración económica en este
tipo de proyectos puedan resultar más complejas que en otros entornos proyectuales.
En genera], el proceso de estimación de costes viene dictado por la experiencia.

Cuando una empresa ha realizado aplicaciones informáticas de un determinado tipo en
ocasiones anteriores, está en condiciones de extraer un conjunto de indicadores muy
valiosos para estimar el coste de proyectos futuros, entre los que cabe citar:
*" El coste medio por linea de programa (incluyendo especificación, diseño,

desarrollo, documentación y pruebas).
El tiempo medio requerido por cada línea de programa.
Cuando las organizaciones o las personas se enfrentan con un nuevo proyecto de

desarrollo software y carecen de experiencia anterior, o dicha experiencia no es
aplicable a este tipo de desarrollos, la complejidad de la estimación se dispara. En
estas condiciones, conviene adoptar una metodología formal que facilite el análisis
detallado de costes y permita validar el proceso de estimación, así como supervisarlo
una vez comenzado el desarrollo. Para ello, es conveniente:
*" Realizar un análisis técnico del software a desarrollar y descomponer el

mismo en componentes (unidades, rutinas o funciones) muy concretas. El
error de valoración cometido en unidades pequeñas será siempre menor que el
error de una valoración global.
*■ Estimar, para cada componente, el tiempo necesario para su especificación,

diseño, desarrollo, documentación y prueba.
*" Para los componentes de difícil estimación, recurrir a un modelo de costes

reconocido, que proporcione un orden de magnitud inicial en función de algún
parámetro objetivo (número de líneas, número de personas, etc.), tal y como se
indica en el apartado 3.2.
310 DIRECCIÓN Y GESTIÓN ni. PROYECTOS
Al final, agregando los costes unitarios de cada componente se obtiene una valoración
global del desarrollo, a la que habrá que sumar los costes asociados a gestión y
dirección, interfaz con el Cliente, suministros, etc.
3.1 Participación del equipo de trabajo en cada fase
Los criterios de participación de personal en los proyectos, que se enunciaron en las

lecturas del capítulo 3 son perfectamente aplicables a los proyectos de desarrollo de
software.
La experiencia demuestra que el nivel al que se involucra en el proyecto cada tipo de

persona (según la categoría profesional a la que pertenece) cambia durante el ciclo de
vida del proyecto, según las siguientes pautas:
■*" El personal de mayor cualificación participa especialmente en las fases de

especificación de requisitos, y colabora en el diseño de alto nivel del sistema).
También participa en las tareas de validación.
■*" Este personal transfiere la mayor parte de la responsabilidad del proyecto a

personal cualificado de menor experiencia (ingenieros júnior) durante la fase
de diseño detallado.
*" Los ingenieros júnior, a la vez, delegan la mayor parte de las tareas de
codificación y transferencia en el personal de soporte técnico, al que
supervisan, y retoman el control al comenzar las tareas de validación y
verificación.
La figura B.10 muestra la participación relativa de cada categoría de personal en las

diferentes fases del proyecto, si bien hay que tener en cuenta que este tipo de reparto
varía en función del alcance y tipo de software a desarrollar.
© RA-VÍA APKNDICE B: GESTIÓN DE PROYECTOS DE DESARROLLO DI; SOFTWARE 311
RU RS DA DD TR PR OM
■ DI ■ 15 H IJ D TE D PA
Figura B.IO Volumen relativo de participación según categoría y
fase del proyecto
3.2 Modelos de costes de desarrollo software
También resulta útil recurrir al "saber popular" a la hora de cuantificar la proporción

de esfuerzo que debe asociarse a cada fase del proyecto.
En un proyecto de desarrollo de software los planificadores más inexpertos muestran

inexorablemente la tendencia a valorar el proyecto a partir del esfuerzo asociado a la
fase de desarrollo y codificación, minusvalorando o despreciando (aparte de las ya
consabidas labores de dirección y gestión) la importancia de las fases de análisis,
pruebas y validación.
Sin embargo, los modelos de costes habitualmente manejados por organizaciones que
disponen de experiencia práctica en desarrollos de este tipo reflejan, con rotunda
claridad, que el esfuerzo de desarrollo, codificación y transferencia es sólo una parte
del esfuerzo total.
En general, un buen punto de partida para estimar el esfuerzo relativo para cada fase
del proyecto es el modelo conocido como "40-20-40", según el cual:
> El 40% del esfuerzo total se destina a tareas de análisis y planificación, el

20% a codificación y transferencia, y el 40% restante a validación y
pruebas.
> Del 40% asociado a las tareas de análisis y planificación, a su vez, el 40%
se destina a labores de planificación, el 20% al análisis de requisitos, y el
40% restante a actividades de desarrollo.
3 i 2 DIRECCIÓN Y GESTIÓN DE PROYECTOS
La figura B.l 1 muestra de manera gráfica el reparto relativo del esfuerzo según los
criterios del modelo 40-20-40.
Figura B.ll Modelo de costes para pequeños desarrollos de

software
En la literatura técnica abundan los refinamientos al modelo anterior, que tratan de

evaluar, en primera instancia, los costes de desarrollo de software en función de
parámetros característicos del proyecto. Tal y como muestra la figura B.12, entre tales
parámetros, figuran características del software a desarrollar (tamaño, complejidad,
tipo de sistema, etc.), así como también las peculiaridades del equipo de trabajo
(tamaño, experiencia, disponibilidad, etc.) que inciden sobre el proceso de desarrollo.
Figura B.12 Estructura genérica de un modelo de costes

©RA-MA _______________ APÉNDICE B: GESTIÓN DE PROYECTOS DE DESARROLLO DE SOFTWARE 313
A partir de las variables de entrada mencionadas, el modelo aplicado determina un

conjunto de valores de salida que representan estimaciones de los factores
involucrados en la realización de los trabajos, incluyendo estimadores del esfuerzo, el
tiempo y el coste.
En general, los modelos de predicción de esfuerzo y coste utilizan formulaciones

empíricas para obtener aproximaciones válidas como punto de partida durante la fase
de planificación. Estos modelos suelen derivarse de análisis retrospectivos, internos a
las organizaciones, que tienen en cuenta la experiencia de la propia organización en un
cierto número de proyectos anteriores de similar alcance72.
A modo de ejemplo, el modelo de Walston y Félix 7"5 constituye una interesante

muestra de cómo obtener, de manera sistemática, valores iniciales que puedan servir
de orientación a la hora de estimar el coste de desarrollar una aplicación.
Para construir este modelo sus autores estudiaron un conjunto de 60 proyectos de

desarrollo de software, de reducido tamaño (entre 4.000 y 450.000 líneas de código),
derivando indicadores del esfuerzo, tiempo, número de personas y páginas de
documentación necesarias, en función del número de líneas del programa (L) a
desarrollar, según las expresiones:
E = Esfuerzo - 5.2 xL 0.9!

0.36
hombres-mes
D = Duración = 4.1x1 meses
D = Duración = 2.47xÉK3ñ meses
P = Personal = 0.54xE0/J personas
DOC = Documentación = 49 xL1'01 páginas
Resulta curioso que, pese a la "edad" del modelo, que ya va para los treinta años, aún
siga usándose (con coeficientes revisados) como primera aproximación a la evaluación
de costes.
Estos modelos, al partir de análisis retrospectivos de proyectos anteriores que las

organizaciones hicieron en su momento son, en general, muy dependientes no sólo del
tipo de software, sino también del entorno de desarrollo (organización y equipo de
trabajo). No es, pues, posible extrapolar directamente sus resultados a otro tipo de
entornos ni a otra clase de software.
" Los cambios en la metodología y herramientas de programación, tales como ¡os sistemas de
desarrollo software de tercera y cuarta generación, obligan a revisar estos modelos y a
adaptarlos a las características de dichas tecnologías.
J
C. Walston, C. Félix. "A method of programming measurement and estimation". IBM
systems Journal, vol. 16, n"l, 1977.
3.3 Coste de los cambios

Al evaluar el coste asociado al diseño, desarrollo e implantación de una aplicación
determinada, se supone que el punto de partida es un conjunto de requisitos de usuario
concretos, que permanecen inalterados en el tiempo (o, al menos, durante el ciclo de
vida del proyecto).
Lamentablemente, no siempre es posible contar con requisitos estables, bien porque se

han cometido errores al capturar los mismos, bien porque las necesidades del usuario
han cambiado con el tiempo.
En cualquiera de los dos casos, modificar los requisitos durante el ciclo de vida del
proyecto supone introducir modificaciones, de mayor o menor calado, al mismo, lo
que directamente repercute en el coste del sistema final.
Dependiendo del motivo del cambio de los requisitos, así como de los términos
contractuales establecidos, puede ser posible, o no, repercutir los costes del cambio al
Cliente. Pero, en cualquier caso, esos costes habrán de ser asumidos por alguna de las
partes.
El coste de un cambio en el alcance del trabajo depende en gran medida del momento
en el que se identifique la necesidad del mismo. Según avanza el ciclo de vida del
proyecto, el coste de un cambio individual se incrementa, según muestra la gráfica de
la figura B.13.
Figura B.13 Impacto económico de los cambios a los requisitos
En dicha figura se observa cómo los cambios a los requisitos implican costes bajos en
la etapa de análisis y planificación del sistema, costes que crecen de manera abultada
al comenzar las fases de diseño, pruebas y transferencia, y que se estabilizan durante
la fase de operación y mantenimiento.
Las razones de este comportamiento son fáciles de explicar. Durante las fases de
análisis y planificación se trabaja "sobre papel" para definir un modelo del sistema a
desarrollar. Los cambios en estas etapas tempranas del ciclo de desarrollo tienen
impacto sólo a efectos de dicho modelo y, por tanto, ocasionan molestias y
modificaciones, pero de coste reducido.
Según se avanza en las fases de diseño, cada decisión impone cambios no sólo en el
análisis y en la planificación anteriormente previstas, sino también sobre múltiples
detalles de implantación, cada vez de menos nivel, que se deciden durante el diseño
del sistema. Los costes de un cambio se incrementan notablemente al tener que revisar
el análisis del sistema y propagar las modificaciones sobre el diseño de alto nivel y el
diseño detallado.
El coste sigue aumentando proporcionalmente durante la fase de transferencia y

pruebas, pues cualquier cambio vuelve a repercutir sobre todas las actividades,
anteriores (análisis y planificación, diseño) y actuales (transferencia.y validación).
Por último, el coste de un cambio se estabiliza durante la fase de operación y

mantenimiento. Cuando el software ha sido transferido y (provisionalmente) aceptado,
cualquier cambio se convierte en una revisión de todo el ciclo de vida de producción
del programa.
La moraleja de lo anterior es simple:
El éxito económico de un proyecto de desarro/lo de software pasa por ¡

requisitos completos, consistentes y que permanezcan estables en el tiempo, asi
como de detectar e incorporar los cambios imprescindibles lo antes posible.
3.4 Coste de mantenimiento
Otra partida económica que habitualmente se minusvalora es la asociada al coste de

mantenimiento del software. Llegados a este punto, el responsable del proyecto tiene
que considerar dos aspectos:
Hasta cuándo dura la responsabilidad y el compromiso de encargarse del

mantenimiento. En general, todo contrato estipula una cobertura por garantía,
y la responsabilidad del equipo de trabajo se limita a dicho período,
exclusivamente. Incluso aunque se detecte un defecto en la realización del
software, el equipo involucrado no tiene por qué responsabilizarse del mismo
si se ha agotado dicho periodo. De esta manera el equipo de trabajo se protege
contra clientes que no asumen con el suficiente rigor su obligación de realizar
pruebas de aceptación, y que meses (o años) después reclaman por un defecto
que no se localizó en su momento.
*" Qué tipo de mantenimiento se incluye en el compromiso del contratista.

Típicamente, la responsabilidad del contratista abarca solamente el
mantenimiento correctivo, es decir, aquél orientado a corregir los defectos
de diseño e implantación del software. En otros casos, el Cliente solicita, por
separado, un contrato de mantenimiento extendido, que incluye, además del
correctivo:
> Mantenimiento adaptativo, orientado a adecuar el software a los
cambios que se produzcan en la organización del Cliente o en su entorno,
y que requieran modificaciones a los requisitos originales (y, por tanto, al
software).
> Mantenimiento perfectivo, orientado a refinar los requisitos iniciales,
definidos en su momento, a raíz del conocimiento adquirido a través de la
utilización del producto original.
Veamos un ejemplo. Supongamos que una empresa contrata a otra la implantación de

una aplicación software para la gestión de sus nóminas. Con el tiempo, se detecta que
el programa no suma correctamente las retenciones y descuentos de los empleados. La
corrección de dicho error forma parte del mantenimiento correctivo.
Supongamos ahora que, tras un cambio en la política fiscal del Gobierno, la empresa
necesita actualizar su aplicación para que las nóminas se calculen e impriman
utilizando las nuevas fórmulas y tablas de retenciones, y también para que funcione
con nuevas versiones del sistema operativo. Estas modificaciones formarían parte del
mantenimiento adaptativo.
Por último, supongamos que la empresa decide ampliar la aplicación de nóminas con
nuevas funciones de representación y análisis gráfico de las mismas. Dicha ampliación
se consideraría mantenimiento perfectivo.
El mantenimiento del software es conceptualmente (en este sentido) similar al

mantenimiento de un vehículo. El usuario no sólo estima el valor de compra, sino el
coste de mantener el vehículo en funcionamiento (correctivo y adaptativo), y el coste
de los elementos que vaya adquiriendo (sillas de bebé, porta-skis, etc.) según cambien
sus necesidades7^
Así pues y visto en conjunto, el contratante tiene que estimar el coste de mantener el
software que ha adquirido, y no sólo aquella parte destinada a corregir los potenciales
74
Sabido es que las marcas de automóviles utilizan los ingresos esperados por mantenimiento
de los vehículos para "ajustar" al máximo el precio inicial de venta, con el fin de ser
(aparentemente) más competitivas, recuperando el "descuento" a través de las futuras visitas
del usuario al taller. Esta política se ha extendido a las empresas de desarrollo SW, que cuentan
con que una fracción significativa de su facturación provenga de los contratos de
mantenimiento y actualización de los programas vendidos.
€> RA-MA _______________ APÉNDICE B: GESTIÓN DE PROYECTOS DE DESARROLLO DE SOFTWARE 317
errores del mismo (que suelen quedar cubiertos por la garantía). La figura B.14
muestra la importancia relativa de cada una de las partidas de coste de mantenimiento
mencionadas.
Figura B.14 Porcentaje medio de esfuerzo dedicado a cada tipo de

mantenimiento del software
4. CONTROL DE CONFIGURACIÓN
En el capítulo 5 se introdujeron los conceptos y aspectos básicos relacionados con el

control de configuración (gestión de la documentación y de los productos) de un
proyecto. En los proyectos de desarrollo software, a causa de la multiplicidad de
productos (rutinas, módulos, funciones, documentos, prototipos, etc.) y versiones, las
actividades de control de configuración cobran vital relevancia, y deben ser
cuidadosamente evaluadas y formalizadas, antes de comenzar las actividades, por el
responsable del proyecto.
En un proyecto de este tipo, todos los elementos y componentes relacionados con el

desarrollo del software deben ser objeto de control de configuración, y estar sometidos
a los procedimientos y normas relacionados con el mismo. En concreto, conviene
considerar configurables, al menos, los siguientes elementos:
> Documentación.
> Código fuente.
> Código objeto y ejecutables.
> Ficheros.
> Herramientas de desarrollo.
> Herramientas de validación y prueba.
> Conjuntos de datos (de prueba, de configuración, etc.).
De acuerdo con lo establecido en el capítulo 5, cada elemento de configuración estará

identificado unívocamente, y definido por su propósito, su funcionalidad, sus
requisitos y sus interfaces, indicando para cada uno el número de versión (y revisión)
actual.
Cada vez que alguna de las partes (Cliente, equipo de trabajo, usuarios) detecte algún
fallo o disconformidad en el software o en la documentación generada en el proyecto,
es conveniente generar, como parte de las actividades de control de configuración, una
hoja de notificación de disconformidad, donde se refleje y describa la misma, la
solución recomendada y la solución adoptada. La figura B.15 muestra un posible
formato para esta hoja de incidencias.
Figura B.15 Formato de notifícaeión de disconformidad
La notificación de una incidencia o disconformidad dará lugar, por lo general, a una

actuación que responda y fen su caso) resuelva la misma. A menudo la actuación
o KA-VI A _________ APÉNDICE B: OESTION DK PKOYHCTOS DE DESARROLLO DE SOFTWARE 319
pasará por introducir cambios en alguno de los elementos de configuración (código o

documentación). Considerar adecuadamente dichos cambios es vital para:
> Tener una idea clara de los cambios realizados sobre los elementos
configurables, los autores de los mismos, las razones de los cambios, etc.
> Plasmar documentalmente la evolución de las diferentes versiones y
revisiones de cada elemento confígurable.
> Dirimir a posteriori las responsabilidades derivadas de cambios (o no
cambios) en los elementos de configuración del proyecto.
> Controlar todas las disconformidades y documentar el proceso y
resolución de las mismas.
La figura B.16 muestra un posible formato para el informe de modificación del

software, como respuesta a un cambio al mismo, en el que se documentan los cambios
realizados, el responsable y la fecha, así como las razones de la modificación y el
esfuerzo asociado a las mismas.
Figura B.16 Formato de informe de modificación del software

Junto con el software, también los documentos del proyecto sufrirán modificaciones.
Un cambio en el software originado por una prueba fallida puede obligar a revisar y
actualizar todo el árbol de documentación del proyecto, incluyendo los documentos de
especificación de requisitos, los documentos de diseño y los documentos de test y
validación.
La figura B.17 muestra un posible formato para hoja de control de configuración de

cada documento. Por lo general, dicha hoja forma parte del propio documento (a
continuación de la portada), y sirve para reflejar qué versión del documento se está
manejando, y qué cambios y modificaciones incluye con respecto a ediciones
anteriores del mismo.
Aunque la figura muestra una hoja de estado para un documento, el concepto es

igualmente aplicable a cualquier otro elemento de configuración, incluyendo los
módulos o rutinas software.
Figura B.17 Formato de hoja de estado del documento

©RA-MA________________APÉNDICE B: GESTIÓN DE PROYECTOS DE DESARROLLO DE SOFTWARE 321
5. RECOMENDACIONES FINALES
A tenor de lo expuesto en este apéndice, surge de manera natural un conjunto de

recomendaciones que, explícitamente relacionadas con trabajos de desarrollo de
software, el responsable del proyecto debe tener en cuenta a la hora de evaluar y
planificar las actividades.
En lo que se refiere a la planificación del trabajo, es conveniente tener en cuenta que:
v Los desarrollos de software son tareas de muy alto valor añadido, donde la
transformación de bienes es prácticamente inexistente, y en las que el
resultado (el software) es un producto intangible de mucha complejidad y
difícil de analizar.
*" Conviene elegir y aplicar desde el principio un modelo de ciclo de vida y un

conjunto de metodologías de desarrollo, que se mantendrán durante todo el
proyecto.
■*" A diferencia de lo que ocurre en otro tipo de proyectos, no es conveniente

solapar las fases del desarrollo.
** Es imprescindible definir desde el principio un plan de validación del software

y un plan de aceptación del mismo que permita establecer un límite claro a las
obligaciones y a la responsabilidad del equipo de trabajo, ante el Cliente y/o
los usuarios.
Con respecto a los requisitos, cabe decir que:
*■ La correcta especificación de los requisitos es clave para la culminación, con

éxito, del proyecto.
*■ La especificación de los requisitos del usuario es responsabilidad úrtitv del

usuario (aunque se le preste la ayuda necesaria para desc.rvoherse
adecuadamente en dicha tarea).
^ Hay que definir requisitos completos, consistentes, verificables y qi •• se

propaguen a través de todo el ciclo de desarrollo del software.
Por último, de cara a la evaluación económica del proyecto, es interesante tener en

cuenta que:
^ Hay que valorar proporcionalmente el esfuerzo necesario para la gestión,

planificación, prueba y mantenimiento, y no sólo las actividades de desarrollo
y codificación.
*" Hay que valorar adecuadamente el impacto de un control de configuración

adecuado sobre el coste del proyecto.
*• Es conveniente hacer uso de un modelo de costes, preferiblemente adaptado a

las características del equipo de trabajo.
®° Es conveniente identificar claramente las tareas menos exigentes, y dejarlas en

manos de personal de menor categoría profesional.
** Las actividades de mantenimiento adaptativo y perfectivo pueden dar lugar a

contratos de alto valor e interés, no sólo económico sino también estratégico
(fidelización del cliente).
APÉNDICE C
CONTENIDO DEL CD-ROM
1. INTRODUCCIÓN
Junto con el libro se proporciona un CD-ROM (denominado disco en el texto) para PC

que contiene los formatos de los documentos de gestión de proyectos descritos en el
texto, así como las plantillas de las hojas de cálculo utilizadas para las estimaciones
económicas y los informes de evolución y avance de los proyectos, también reseñadas
a lo largo de los diferentes capítulos del libro.
Adicionalmente, en el disco se incluyen los formatos y plantillas correspondientes a

los ejemplos resueltos en los diferentes apartados del texto.
2. ESTRUCTURA Y CONTENIDO DEL DISCO
La figura C.l muestra la estructura y contenido del disco que se adjunta con el
presente libro.
Figura C.l Estructura y contenido del disco
En el directorio raíz del disco se encuentran, además de un archivo de texto con la

descripción del contenido, dos directorios:
El directorio [formatos contiene los formatos de los documentos y plantillas descritos

y utilizados a lo largo del texto y, en concreto, los subdirectorios
\formatos\documentos y \formatos\plantillas.
•* El subdirectorio \formatos\documentos contiene archivos de Microsoft Word

con los siguientes documentos:
> descripcion_pt.doc: formato de la descripción de paquetes de trabajo.

> estimacion_horas.doc: formato del documento de estimación de la carga
de trabajo, o de horas por tarea y categoría.
> fax.doc: formato de hoja de transmisión fax.
> comunicación jntcrna.doc: formato de comunicación interna.
> convocatoriajreunion.doc: formato para la convocatoria de una reunión
de proyecto.
> acta_reunion.doc: formato para la redacción de las actas de una reunión.
APÉNDICE C: CONTENIDO DEL CD-ROM 325
> resumen_reunion.doc: formato para la elaboración del resumen de una

reunión.
> estado_acciones.doc: formato para consignar el estado de las acciones
pasadas y pendientes del proyecto.
> informe_situacion.doc: formato para la redacción del informe de
situación, intermedio o final, de un paquete de trabajo o del proyecto.
> gestion_documentacion.doc: formato para la elaboración del control de
configuración de la documentación del proyecto.
> propuesta_cambio.doc: formato para la solicitud de un cambio durante
la ejecución de un proyecto, e información de utilidad para su análisis y
evaluación.
> registro_cambios.doc: formato para mantener el estado del control de
configuración de todos los cambios formales solicitados dentro del
ámbito del proyecto en curso.
> acta_recepcion.doc: formato para notificar al Cliente la entrega de
resultados finales o parciales del proyecto, y para que el Cliente acepte o
rechace formalmente dichos resultados.
> informe_cierre.doc: formato para la elaboración del informe de cierre
del proyecto.
> estado_documento.doc: formato de la hoja de estado de cada documento
de proyecto, sujeto a control de configuración.
> notificacion_disconformidad.doc: formato de hoja para la notificación
de disconformidades en programas, documentos y otros productos.
> modificacion_software.doc: formato de hoja de notificación de
modificaciones al software.
íS=
El subdirectorio \formatos\plantillas contiene las hojas de cálculo, en formato
Microsoft Excel, correspondientes a las siguientes plantillas descritas en el
libro:
datos_economicos.xls: incluye las hojas de cálculo utilizadas para

completar y calcular:
> Las estimaciones económicas del proyecto.
> El plan financiero.
> El informe de evolución económica.
> El informe de estado económico.
> El informe de cierre económico.
> Los indicadores (económicos, financieros y de gestión) del
proyecto.
> costes_Caos.xls: incluye la hoja de cálculo utilizada para calcular los

datos económicos básicos de la empresa ficticia Caos Consulting, S.A.,
según se describieron en el capítulo 1.
Por su parte, el directorio \ejemplos incluye los formatos y plantillas asociados a la

resolución de los ejemplos propuestos en el libro, y contiene, a su vez, tres
subdirectorios:
^ El subdirectorio \ejemplos\TrabajoEstival contiene los formatos y plantillas

del caso Un trabajillo estival para una estudiante de derecho, correspondiente
al apéndice A, apartado 2, del libro.
*■ El subdirectorio \ejemplos\ThermoPC contiene los formatos y plantillas del

caso ThermoPC, correspondiente al apéndice A, apartado 3 del libro.
*" El subdirectorio \ejemplos\FloresDelSur contiene los formatos y plantillas del

caso Red de área local para Flores del Sur, presentado en el capítulo 3 y
continuado en el apéndice A, apartado 4.
Por último, el directorio WocAdicional contiene otros ejemplos reseñados en el texto

y las lecturas del libro (cálculo del valor actual, índice de precios, etc.), junto con otras
referencias de interés para el lector.
ÍNDICE ALFABÉTICO
evolutivo 307
fases 291
acciones 181 incremental 305
estado de las aceptación provisional 182 tipos 304
actividad 302 cierre
crítica 76, 100 administrativo 16
virtual adaptaciones adjudicación 100 contable 16
administración análisis del valor 101 técnico 16
añadido análisis y planificación 202 cliente 40
anteproyecto árbol de tareas avance 153 creación de necesidades 48
curva de 25 codificación 291
económico 190 comunicación interna 164
técnico 291 concurso 47,50
4 abierto 54
75 negociado 54
B
objetivos 53
balance de ingresos y gastos barreras 184
223 publicidad 53
de entrada 185 restringido 54
de salida beneficio 183
40,41 conflictos interpersonales 208
extra 40,41 consultor 85
1 contingencias 10,91
223 contrato 39,215
adjudicación 15
camino critico de consultoría y asistencia 61
Caos Consulting de gestión de servicios públicos 61
carga de trabajo 100, 103 de obras 61
ciclo de vida 29, 112,228,255,279 de suministros 61
cascada 81, 112,235 no adjudicación 15
290 tipos 61
304 control de configuración 195,317
correcciones 202
coste 7
coeficientes de 91
consumibles 33
de los cambios 314
de mantenimiento 315
de oportunidad de transferencia 302

equipos informáticos 33 historia del proyecto 304
general 32
interno 84
laboral 31 E
material y equipo 84 efecto fiscal empresa 254
modelo 311 esfuerzo estado del 17
ocultos 87 arte estilo de 19
otros 35,84 dirección 4
por linea de programa 309 déspota-autoritario
subcontrataciones 84 indeciso 215
varios 87 negociador 214
viajes y estancias CPM 84 participativo 214
criterios de valoración curriculum 100 progresivo vitae 214
versión corta 57, 140, 143 EVA 214
Véase análisis del valor añadido
versión larga curriculum vitae 144 evaluación 308
147 económica F
145
D 139
fax 16
decisiones 213 fiabilidad 30
4
estratégicas 213 Flores del Sur 11
4
operativas 213 flujo de caja 3
11
tácticas 213 formato 0
desarrollo 291 aceptación 22
desviaciones 208, 236, 284 avance 1
18
causas 208 balance de ingresos y gastos 5
22
detección de oportunidades 12,39 comunicación interna 16
3
dirección de proyectos ' 24 control de configuración 200, 32
4
director de proyecto 25, 209 convocatoria de reunión 0
16
diseño arquitectónico 300 estado de las acciones 18
9
documento de 300 estado del documento 32
2
revisión 300 evolución económica 180
diseño de alto nivel 300 fax 16
8
diseño de la arquitectura 291 horas 80
4
diseño detallado 291,301 informe de modificación del software 31
revisión 301 informe de situación 9
19
documentación 228,317 informe de situación final 22
4
aspectos legales 215 informe económico de cierre 7
22
complementaria 197 minutas de reunión 17
6
conservación 229 notificación de incidencias 4
31
custodia 229 plan financiero 11
8
de gestión 197 presupuesto 0
92
difusión 229 propuesta de cambio 20
distribución 199 registro de estado de cambios 20
4
gestión de 196 resumen de reunión 17
7
no reutilizable 199 7
reutilizable 199 G
técnica 197
vinculante 215
documento Gantt 97
de diseño 300 gasto 7
de diseño detallado 301 estimación 268. 27
1
©RA-MA ______________________________________________________________ ÍNDICE ALFABÉTICO 329
gestión 22 fC
administrativa 26
de cambios 202 know-how Véase saber hacer
de compras 24, 88
de costes 23 T
de la calidad 23
de la comunicación 23 ligaduras 100
de la documentación 196 lucro 7
de los productos 201
de los recursos humanos 23 __
de recursos temporales Véase planificación -^*
de riesgos 24 MAC ,02
del alcance y contenido 23 mantenimiento 303
27
estratégica adaptativo 316
°Peratlva 2
A correctivo 316
ac uetede
P, " ™ perfectivo 316
tactlca 26
manual de usuario 301
tecmca 23
margen 8
mejora competitiva 72
H mejoras 202
mercado 40
historia del proyecto 304 estrategia de 45
holgura 100, 104 nichos de 40
horas MIC 101
estimación 268,271 modelo 9
40-20-40 311
de costes 311
Walstony Félix 313
impuestos 254
incertidumbre 10 ^
indicadores 230 ■*■*
230
beneficio negociación 34
componentes del coste 231 cuhuras de 35
coste por hora 231
de gestión 236
de ocupación laboral 234 O
económicos 230
proceso proyectual recursos 3

seguimiento trabajo en equipo 2
paquete de trabajo 75 159
actividades excluidas 78 2
descripción 77
R
PERT 100 recursos
plan de negocio 43 acopio 161
formato 44 consumidos 185,284
objetivos 43 financieros 161
planificación 96, 249, 266, 321 humanos 161
técnicas de
23, 97 materiales 161
pliego 5!, 56, 255 remanentes 185
administrativo 52,56 registro de estado de cambios 207
económico 52 relación de sustitución 83
técnico 51,56 requisitos 220,321
precio 14, 94, 143 ambientales 294
producto 41 de aceptación 293
profesional independiente 18 de calidad y fíabilidad 294
programa 5 de documentación 293
código 301 de interfaz 293
de ordenador 289 de mantenibilidad 294
programación 97 depbrtabilidad 294
propuestas de cambio 202 de prestaciones 293
prototipo \ 4 de recursos 293
proveedores ■88 de seguridad 294
proyecto 1 de verificación 293
aceptación 220 deseables 292
administración 25 funcionales 293
alcance 296 necesarios 292
auditoría 279 operativos 293
cambios 201 requisitos de usuario
ciclo de vida 11 definición 291,292
cierre 16,219 documento de 292
clásico 4 especificación 292,296
clasificación 3 revisión 292
de investigación 4 requisitos del software
desarrollo de software 289 definición 291,293
diagnóstico 189, 284 documento de 293
director de : 25 revisión 293
estudio de viabilidad 4 reunión 167
estudios y análisis 4 actas Véase minutas
evaluación 248, 264 agenda 168
evaluación económica 321 asistencia 170
externo 5 código de conducta 173
fases 11 con el Cliente 168
indicadores 230 convocatoria 168
industrial 4 de comienzo 167
interfaces 209 de revisión de requisitos de usuario 292
interno 5 de revisión de requisitos del software 293
memoria 4 de revisión del diseño arquitectónico 300
objetivos 1 de revisión del diseño detallado 301
plan financiero 109 desarrollo 17!
planos 4 interna 167
pliego de condiciones 4
precio 74
presupuesto 4
ÍNDICE ALFABÉTICO 331
minutas 174
resumen 177
riesgo 10 tareas 78
tasa de rendimiento interno 111
TIR Véase tasa de rendimiento interno
transferencia 291,302
saber hacer 220, 228 documento de 302
servicio 41
solicitud de información 62 V
solicitud de oferta 63
subcontrataciones 85 valor actual neto 111
suceso 100 valor actualizado 65
final 100 VAN Véase valor actual neto
inicial 100
sumario ejecutivo 44

00 A Direccion y Gestion de Proyectos II PDF

Cargado por

Información del documento

Título original

Derechos de autor

Formatos disponibles

Compartir este documento

Compartir o incrustar documentos

Opciones para compartir

¿Le pareció útil este documento?

¿Este contenido es inapropiado?

Copyright:

Formatos disponibles

00 A Direccion y Gestion de Proyectos II PDF

Cargado por

Copyright:

Formatos disponibles

Dirección y Gestión de Proyectos

Alberto Domingo Ajenjo Doctor

SOBRE EL AUTOR .................................................................................................. XVII

PRÓLOGO ................................................................................................................. XIX

PREFACIO A LA SEGUNDA EDICIÓN .............................................................. XXI

INTRODUCCIÓN ..................................................................................................... XXIII

CAPÍTULO 1. INTRODUCCIÓN A LA DIRECCIÓN Y GESTIÓN DE

4. GESTIÓN Y DIRECCIÓN .................................................................................. 22

CAPÍTULO 2. DETECCIÓN DE OPORTUNIDADES ................................... 39

CAPÍTULO 3. EVALUACIÓN DEL PROYECTO.......................................... 71

3. ESTIMACIÓN DEL COSTE Y EL PRECIO DEL PROYECTO ..................................... 74

CAPÍTULO 4. PREPARACIÓN DE LA OFERTA ......................................... 135

1. INTRODUCCIÓN ............................................................................................. 135

CAPITULO 5. SEGUIMIENTO DEL PROYECTO ........................................... 159

CAPÍTULO 6. CIERRE DEL PROYECTO.......................................................... 219

1. INTRODUCCIÓN .................................................................................................... 219

3. INFORME DE CIERRE DE PROYECTO ............................................................... 222

EPÍLOGO. LA GESTIÓN EN EL TERCER MILENIO ................................. 239

APÉNDICE A. EJEMPLOS DE EVALUACIÓN ECONÓMICA DE

1. INTRODUCCIÓN ............................................................................................ 247

APÉNDICE B. GESTIÓN DE PROYECTOS DE DESARROLLO DE

1. INTRODUCCIÓN ............................................................................................. 289

APÉNDICE C. CONTENIDO DEL CD-ROM ................................................. 323

1. INTRODUCCIÓN ............................................................................................. 323

ÍNDICE ALFABÉTICO .................................................................................... 327

FIGURA 1.1 EL PROCESO PROYECTUAL ........................................................................... 3

FIGURA 5.1 FORMATO DE FAX ............................................................................................................... 165

FIGURA 6.4 FORMATO DE INFORME DE SITUACIÓN FINAL ............................................................... 227

FIGURA E.l CONVERGENCIA DE FACTORES HACIA EL DESARROLLO DEL TELETRABAJO..................... 243

FIGURA A. 1 PLANIFICACIÓN TEMPORAL DEL ESTUDIO JURÍDICO ..................................................... 250

FIGURA B. 1 INTERRELACIÓN DE LOS AGENTES QUE CONFIGURAN EL PROCESO DE DESARROLLO

FIGURA C.l ESTRUCTURA Y CONTENIDO DEL DISCO ....................................................................... 324

Básicamente en la última mitad de este siglo (especialmente de a partir de la segunda guerra

En la actualidad encontramos una enorme cantidad de actividades humanas que presentan la

Alejandro Orero Giménez Catedrático, Universidad

Alberto Domingo Ajenjo

La Haya, Octubre de 2004

dinero, prestigio, satisfacción personal u otro tipo de recompensa). Parece lógico

A QUIEN VA DIRIGIDO ESTE LIBRO

En la obra el lector encontrará un análisis estructurado de las actividades de dirección

Profesionales de la gestión, sin experiencia o con escasa práctica en la materia,

"" Profesionales de otras disciplinas (técnicas o humanísticas), que hayan de

* Profesionales sin demasiada experiencia que, por la tipología o tamaño de la

ESTRUCTURA DEL LIBRO

El texto se ha dividido en seis capítulos. El primero de ellos es una introducción al

Los siguientes cinco capítulos abordan el alcance, la metodología y las herramientas

El capítulo cinco se dedica al seguimiento del proyecto, es decir, a la fase de ejecución

Además, el lector encontrará a lo largo de la obra numerosas lecturas complementarias

Alberto Domingo Ajenjo

Existen prácticamente tantas definiciones de proyecto como autores y obras al

A poco que se analice la anterior definición se observa un conjunto de características

> Persecución de uno o varios objetivos. Las actividades aisladas no

es satisfacer un conjunto de requisitos técnicos, a un coste dado, en las

Algo que se desprende de inmediato de las consideraciones anteriores, es que el

Algunos autores restringen1 algo más la definición de proyecto, imponiendo que

La figura 1.1 muestra otra forma de ver un proceso proyectual. El objeto de un

Figura 1.1 El proceso proyectual

1.1 Tipos de proyectos

continuación se incluye una posible clasificación básica de proyectos comunes,

Proyecto clásico. Este tipo de proyectos aborda la realización de una serie de

Proyecto de investigación. Los proyectos de investigación tienen como

Estudios y análisis. En ocasiones el alcance de un trabajo concreto se limita a

Estudios de viabilidad. A veces la complejidad del problema que se aborda