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.
2.
3.
1
I NTRODUCCIÓN ..................................................................................................... 1.1 Tipos de proyectos ..................................................................................... 1.2 La dimensión técnica, económica, comercial y estratégica de un proyecto.. 1.3 Costes, gastos, ingresos, margen y beneficio ...........................................
1 3 6 7
L ECTURA . MAXIMIZACIÓN DE BENEFICIOS EN LA EMPRESA .........................
9
1.4 El factor riesgo y las contingencias .......................................................... LAS FASES DE UN PROYECTO ...........................'..................................................... 2.1 Detección de oportunidades ..................................................................... 2.2 Preparación de la oferta ........................................................................... 2.3 Presentación (o no) y adjudicación (o no) ................................................ 2.4 Ejecución de los trabajos .......................................................................... 2.5 Cierre (y vuelta a empezar) ....................................................................... EL PROYECTO EN LA EMPRESA............................................................................. 3.1 Concepto de empresa ................................................................................ 3.2 Organización déla empresa ..................................................................... 3.3 Vinculación proyecto-empresa .................................................................
10 11 12 13 14 15 16 17 17 18 20
VIH DIRECCIÓN Y GESTIÓN DE PROYECTOS
4.
GESTIÓN Y DIRECCIÓN .................................................................................. 4.1 Dirección, gestión, administración y participación............................... 4.2 Gestión estratégica, administrativa y operativa .................................... 4.3 El encanto de la gestión ....................................................................... CAOS CONSULTING S.A., UNA EMPRESA MODELO ........................................ 5.1 Características generales de la empresa .............................................. 5.2 Costes laborales ................................................................................... 5.3 Costes generales .................................................................................. 5.4 Otros costes......................................................................................... 5.5 Margen comercial de Caos Consulting ................................................ 5.6 Facturación de Caos Consulting .......................................................... LECTURA. EL ARTE DE NEGOCIAR...... '. .............
22 24 26 27 29 29 30 32 33 33 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
PLAN DE NEGOCIO......................................................................................... 3.1 Objetivos del plan de negocio............................................................... 3.2 Formato de un plan de negocio............................................................ OPORTUNIDADES COMERCIALES ................................................................... 4.1 Oportunidades "perseguidas".............................................................. 4.1.1 El concurso ............................................................................... 4.1.2 Información acerca de las necesidades del Cliente..................... 4.1.3 Creación de necesidad en el Cliente .......................................... 4.1.4 Divulgación y publicidad .......................................................... 4.1.5 Ampliación del alcance de un proyecto o trabajo....................... 4.1.6 Continuación de trabajos anteriores ........................................... 4.2 Oportunidades "noperseguidas"......................................................... CONCURSOS .................................................................................................. 5.1 Objetivos de un concurso ..................................................................... 5.2 Publicidad del concurso ...................................................................... 5.3 El Pliego .............................................................................................. 5.4 Ventajas y desventajas.......................................................................... 5.5 Los concursos y la Administración ....................................................... 5.6 Peticiones de información ....................................................................
42 43 44 46 46 47 47 48 48 49 49 50 50 53 53 56 60 61 62
LECTURA. INFLACIÓN YESCALACIÓNDE PRECIOS ...........................................
63
CAPÍTULO 3. EVALUACIÓN DEL PROYECTO..........................................
71
1. 2.
71 72
5.
3.
4.
5.
INTRODUCCIÓN ............................................................................................. EVALUACIÓN Y DECISIÓN PRELIMINAR .........................................................
34
ÍNDICE IX
3.
ESTIMACIÓN DEL COSTE Y EL PRECIO DEL PROYECTO ..................................... 3.1 Análisis del trabajo a realizar .............................................................. 3.1.1 Estructura de paquetes de trabajo.............................................. 3.1.2 Descripción de los paquetes de trabajo ....................................... 3.2 Esfuerzo requerido ...............................................................................
74 75 76 77 79
LECTURA. RELACIONES DE SUSTITUCIÓN DE PERSONAL ..........................
82
Otros costes y gastos ............................................................................ 3.3.1 Subcon trataciones ..................................................................... 3.3.2 Costes varios ............................................................................
84 85 87
LECTURA. ESTRATEGIAS CON PROVEEDORES ..........................................
88
Presupuesto y precio de venta del proyecto .........................................
90
LECTURA. EL NÚMERO DE PERSONAS QUE PARTICIPAN EN UN PROYECTO
94
3.3
3.4 4.
PLANIFICACIÓN TEMPORAL DEL PROYECTO .................................................. 4.1 Técnicas de planificación .................................................................... 4.2
96 97
Técnicas PERT. ................................................................................... '.
100
LECTURA. "Am DIOS MÍO " YSUPROGRAMA DE OPTIMIZACIÓN DE VUELOS ...
105
PLAN FINANCIERO DEL PROYECTO ................................................................ UN EJEMPLO: EL PROYECTO DE FLORES DEL SUR ...........................................
Antecedentes ........................................................................................ Análisis de los antecedentes ................................................................. Identificación de las tareas a realizar .................................................. Estimación de horas y gastos ................................................................ Planificación temporal y recursos ........................................................ Plan financiero del proyecto ................................................................. Recomendación del responsable de la oferta........................................
109 112 113 114 116 121 128 130 132
LECTURA. LAS DIFERENTES FORMAS DE DAR UNPRECIO .........................
132
CAPÍTULO 4. PREPARACIÓN DE LA OFERTA .........................................
135
1. 2. 3.
135 136 138 140 142 143 144 145 147 148 150 153 154
5. 6.
6.1 6.2 6.3 6.4 6.5 6.6 6.7
4.
5. 6.
INTRODUCCIÓN ............................................................................................. OFERTAR, o NO OFERTAR.............................................................................. PREPARACIÓN DE LA OFERTA ........................................................................ 3.1 Oferta técnica ...................................................................................... 3.2 Oferta de gestión .................................................................................. 3.3 Oferta económica ................................................................................. CURRICULA VITAE Y REFERENCIAS DE LA EMPRESA ........................................ 4.1 Curriculum personal, versión larga ..................................................... 4.2 Curriculum personal, versión corta ...................................................... 4.3 Presentación y referencias de la empresa ............................................ PRESENTACIÓN (Y SEGUIMIENTO) DE LA OFERTA .......................................... ADJUDICACIÓN (o NO) DEL TRABAJO ............................................................. LECTURA. ESTILO DE COMUNICACIÓN ....................................................
X DIRECCIÓN Y GESTIÓN DE PROYECTOS
CAPITULO 5. SEGUIMIENTO DEL PROYECTO ........................................... 1.
I
2.
NTRODUCCIÓN ..................................................................................................... ANTES DE EMPEZAR A TRABAJAR .........................................................................
© RA-MA
159
2.1 Revisión de la oferta y del contrato ......................................................... 2.2 Organización y acopio de recursos .......................................................... 2.3 Intercambio de información en el proyecto .............................................. R EUNIONES .......................................................................................................... 3.1 Convocatoria de reunión ........................................................................... 3.2 Desarrollo de la reunión ...........................................................................
159 159 160 161 162 167 168 171
LECTURA, CÓDIGOS DE CONDUCTA .............................................................
173
3.3 Actas de reunión ........................................................................................ 3.4 Resumen de reunión .................................................................................. EL DÍA A DÍA DE LA GESTIÓN DEL PROYECTO ..................................................... 4.1 Estado de las acciones .............................................................................. 4.2 Avance técnico y económico .....................................................................
174 177 179 181 183
LECTURA, MÉTODOS DE ANÁLISIS DEL VALOR AÑADIDO ...........................
190
4.3 Informe de situación del proyecto .............................................................. CONTROL DE CONFIGURACIÓN ............................................................................. 5.1 Gestión de la documentación .................................................................... 5.2 Gestión de los productos generados .......................................................... CAMBIOS AL ALCANCE DEL PROYECTO ................................................................ 6.1 Propuesta motivada .................................................................................. 6.2 Análisis y evaluación ................................................................................. 6.3 Autorización o rechazo .............................................................................. 6.4 Implantación y seguimiento ....................................................................... 6.5 Registro de estado de los cambios ............................................................ OTRAS ACTIVIDADES ............................................................................................ 7.1 Conflictos interpersonales en el proyecto ................................................. 7.2 Interfaces del proyecto ............................................................................... 7.2.1 Interfaz con el Cliente .................................................................... 7.2.2 Interfaz con el equipo de trabajo ................................................... 7.2.3 Interfaz con el responsable de la gestión del proyecto .................. 7.2.4 Interfaz con la empresa .................................................................. 7.3 Decisiones, decisiones, decisiones ............................................................
194 195 196 201 201 203 205 205 206 207 208 208 209 210 211 212 212 213
LECTURA. ASPECTOS LEGALES Y VALOR CONTRACTUAL DE LA DOCUMENTACIÓN DEL PROYECTO ..........................................................
215
CAPÍTULO 6. CIERRE DEL PROYECTO..........................................................
219
1. 2.
219 220
3.
4.
5.
6.
7.
INTRODUCCIÓN .................................................................................................... ACEPTACIÓN ........................................................................................................
ÍNDICE XI
3.
INFORME DE CIERRE DE PROYECTO ............................................................... 3.1 Balance de ingresos y gastos ............................................................... 3.2 Resumen de cierre de proyecto ............................................................. 3.2.1 Informe económico ................................................................... 3.2.2 Informe de situación final ......................................................... 3.3 Tratamiento de la documentación generada ......................................... INDICADORES OBJETIVOS DEL RESULTADO DEL PROYECTO ............................ 4.1 Indicadores económicos de primer orden ............................................. 4.2 Indicadores financieros ....................................................................... 4.3 Indicadores de ocupación laboral........................................................ 4.4 Indicadores de gestión .........................................................................
222 223 225 225 226 228 230 230 232 234 236
EPÍLOGO. LA GESTIÓN EN EL TERCER MILENIO .................................
239
APÉNDICE A. EJEMPLOS DE EVALUACIÓN ECONÓMICA DE PROYECTOS .............................................................................................
247
4.
1. 2.
3.
4.
INTRODUCCIÓN ............................................................................................ UN TRABAJILLO ESTIVAL PARA UNA ESTUDIANTE DE DERECHO..................... 2.1 Introducción y antecedentes ................................................................ 2.2 Evaluación del trabajo ......................................................................... 2.3 Planificación ....................................................................................... 2.4 Costes y gastos..................................................................................... 2.5 Decisión ..............................................................................................
247 248 248 248 249 250 253
LECTURA. EL EFECTO FISCAL.......................................................................
254
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 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 ............................................................................................... 1. 2.
289
INTRODUCCIÓN ............................................................................................. CICLO DE VIDA DE UN PROYECTO DE DESARROLLO DE SOFTWARE ................ 2.1 Fases del ciclo de vida ......................................................................... 2.1.1 Fase de análisis y planificación .................................................
289 290 291 291
LECTURA. ESPECIFICACIÓN DE REQUISITOS DE USUARIO ..............................
296
2.1.2 Fase de desarrollo ..................................................................... 2.1.3 Fase de operación y mantenimiento .......................................... 2.2 Tipos de ciclo de vida ........................................................................... 2.2.1 Modelo en cascada .................................................................... 2.2.2 Modelo incrementa! .................................................................. 2.2.3 Modelo evolutivo ...................................................................... EVALUACIÓN ECONÓMICA ............................................................................ 3.1 Participación del equipo de trabajo en cada fase ................................. 3.2 Modelos de costes de desarrollo software ............................................ 3.3 Coste de los cambios ............................................................................ 3.4 Coste de mantenimiento........................................................................ CONTROL DE CONFIGURACIÓN ...................................................................... RECOMENDACIONES FINALES .......................................................................
300 303 304 304 305 307 308 310 311 314 315 317 321
APÉNDICE C. CONTENIDO DEL CD-ROM .................................................
323
1. 2.
INTRODUCCIÓN ............................................................................................. ESTRUCTURA Y CONTENIDO DEL DISCO .........................................................
323 323
ÍNDICE ALFABÉTICO ....................................................................................
327
3.
4. 5.
ÍNDICE DE FIGURAS CAPITULO 1
FIGURA 1.1 FIGURA FIGURA FIGURA FIGURA FIGURA FIGURA FIGURA FIÜURA
1.2 1.3 1.4 1.5 1.6 1.7 1.8 1.9
FIGURA 1.10 FIGURA 1.11
EL PROCESO PROYECTUAL ........................................................................... PROCESO DE ELABORACIÓN DE UN PROYECTO ........................................ EJEMPLO DE ORGANIGRAMA ....................................................................... ORGANIZACIÓN FUNCIONAL....................................................................... ORGANIZACIÓN PROYECTUAL..................................................................... ORGANIZACIÓN MATRiciAL ........................................................................ LA LABOR DEL DIRECTOR DE PROYECTO ................................................. PIRÁMIDE DE DECISIÓN EN LA EMPRESA ................................................... RAZONES PARA DAR EL SALTO A ACTIVIDADES DE DIRECCIÓN Y GESTIÓN ......................................................................................... RAZONES PARA NO DAR EL SALTO A ACTIVIDADES DE DIRECCIÓN Y GESTIÓN............................................................................................................. ORGANIGRAMA SIMPLIFICADO DE CAOS CONSULTING ........................ .'.
3 11 19 20 21 22 25 27 28 28 30
CAPÍTULO 2 FIGURA 2.1 FIGURA 2.2 FIGURA 2.3 FIGURA 2.4 FIGURA 2.5
FIGURA 2.6 FIGURA 2.7
PROCEDIMIENTO GENERAL PARA CONVOCAR UN CONCURSO .............. ANUNCIOS DE CONCURSOS PÚBLICOS CONVOCADOS EN EL BOLETÍN OFICIAL DEL ESTADO (BOE), A LA IZQUIERDA, Y EN UN DIARIO DE ÁMBITO NACIONAL,
51
A LA DERECHA ................................................................................................ 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 .......................................................................................... FUNCIÓN DE ASIGNACIÓN DE PUNTOS A LAS OFERTAS ECONÓMICAS RECIBIDAS .............................................................................. EVOLUCIÓN DEL IPC (ÍNDICE GENERAL, MEDIA NACIONAL) ESPAÑOL, DURANTE LOS ÚLTIMOS 30 AÑOS (FUENTE, INSTITUTO NACIONAL DE ESTADÍSTICA).................................................................................................. FACTORES QUE INTERVIENEN EN EL CÁLCULO DEL IPC ........................ EVOLUCIÓN DEL VALOR REAL (PODER ADQUISITIVO) DE UNA PESETA, DURANTE LOS ÚLTIMOS 35 AÑOS (FUENTE, INSTITUTO NACIONAL DE ESTADÍSTICA) .................................................................................................
55
57 59
64 66
67
CAPITULO 3 FIGURA FIGURA FIGURA
3.1 3.2 3.3
PROCESO DE PREPARACIÓN DE UNA OFERTA ........................................... ESTIMACIÓN DEL COSTE Y EL PRECIO DB UN PROYECTO........................ DESCRIPCIÓN DE UN PAQUETE DE TRABAJO .............................................
73 74 78
XIV DIRECCIÓN Y GESTIÓN DE PROYECTOS _____________________________________________ @RAMA
FIGURA 3.4 FIGURA 3.5 FIGURA 3.6 FIGURA 3.7 FIGURA 3.8 FIGURA 3.9 FIGURA 3.10 FIGURA 3.11 FIGURA 3.12 FIGURA 3.13 FIGURA 3.14 FIGURA 3.15 FIGURA 3.16 FIGURA 3.17 FIGURA 3.18 FIGURA 3.19 FIGURA 3.20 FIGURA 3.21 FIGURA 3.22 FIGURA 3.23 FIGURA 3.24 FIGURA 3.25 FIGURA 3.26
E STIMACIÓN DEL ESFUERZO NECESARIO PARA LLEVAR A CABO UN PROYECTO .............. M ODELO DEL ICEBERG , DE COSTES OCULTOS ................................................................... FORMATO DE PRESUPUESTO DE UN PROYECTO ................................................................. PLANIFICACIÓN INICIAL DEL PROYECTO DE INSTALACIÓN DE UN PORTÓN ..................... PLANIFICACIÓN MODIFICADA DEL PROYECTO DE INSTALACIÓN DE UN PORTÓN ............. E JEMPLO DE GRAFO DE PROYECTO .................................................................................... C ÁLCULO DE LOS VALORES MIC DE LOS SUCESOS DEL PROYECTO................................. C ÁLCULO DE LOS VALORES MAC DE LOS SUCESOS DEL PROYECTO ................................ C AMINO Y ACTIVIDADES CRÍTICAS DEL GRAFO PERT DEL PROYECTO ........................... C AMINO Y ACTIVIDADES CRÍTICAS DEL GRAFO PERT DEL PROYECTO ............................ SECUENCIA DE ACTIVIDADES DEL PROCESO DE PREPARACIÓN DEL AVIÓN ...................... FORMATO DE PLAN FINANCIERO DEL PROYECTO .............................................................. FLUJO DE ACTIVIDADES DEL PROYECTO F LORES DEL SUR ............................................... E STRUCTURA DE PAQUETES DE TRABAJO PARA EL PROYECTO F LORES DEL S UR ............. C ONTENIDO DEL P AQUETE DE TRABAJO "PT.0, GESTIÓN" ............................................. C ONTENIDO DEL PAQUETE DE TRABAJO "PT. 310, P REPARACIÓN DEL CURSO ".............. E STIMACIÓN DEL ESFUERZO ASOCIADO AL PROYECTO DE F LORES DEL S UR ................... E SFUERZO, SEGÚN CATEGORÍAS, EN EL PROYECTO DE F LORES DEL S UR ......................... E SFUERZO, SEGÚN ÁREAS FUNCIONALES, EN EL PROYECTO DE F LORES DEL SUR ........... PRESUPUESTO ESTIMADO PARA EL PROYECTO F LORES DEL SUR ..................................... PLANIFICACIÓN TEMPORAL PREVISTA PARA EL PROYECTO ............................................. PLAN FINANCIERO DEL PROYECTO FLORES DEL SUR ........................................................ E VOLUCIÓN DE INGRESOS Y GASTOS (E UROS) DEL PROYECTO F LORES DEL S UR............
81 87 93 98 99 101 102 103 103 107 108 111 117 118 119 120 122 123 124 127 128 131 131
FORMATO DE FAX ............................................................................................................... FORMATO DE COMUNICACIÓN INTERNA ........................................................................... FORMATO DE CONVOCATORIA DE REUNIÓN ...................................................................... Lo QUE SE DEBE Y NO SE DEBE HACER AL CONVOCAR UNA REUNIÓN .............................. FORMATO DE ACTAS DE REUNIÓN ..................................................................................... Lo QUE SE DEBE Y NO SE DEBE HACER AL REDACTARLAS ACTAS DE UNA REUNIÓN ... FORMATO DE RESUMEN DE REUNIÓN ................................................................................. Lo QUE SE DEBE Y NO SE DEBE HACER AL REDACTAR EL RESUMEN DE UNA REUNIÓN. FORMATO DE ESTADO DE LAS ACCIONES PASADAS Y PENDIENTES ................................... Lo QVP. SE DEBE Y NO SE DEBE HACER AL REDACTAR EL ESTADO DE LAS ACCIONES .. RECTA DE AVANCE TÍPICA DE LOS TRABAJOS DE UN PROYECTO ....................................... FORMATO DE AVANCE ECONÓMICO DEL PROYECTO ......................................................... R ECURSOS CONSUMIDOS FRENTE A LOS REMANENTES DEL PROYECTO .......................... R EPRESENTACIÓN GRÁFICA DE LAS HORAS, SEGÚN CATEGORÍAS, CONSUMIDAS ........... REPRESENTACIÓN GRÁFICA DE LA EVOLUCIÓN DE INGRESOS Y GASTOS .......................... FORMATO DE EVOLUCIÓN ECONÓMICA DEL PROYECTO ................................................... E VOLUCIÓN DEL CONSUMO DE HORAS DE TRABAJO DEL PROYECTO ............................... EVOLUCIÓN DE LOS INGRESOS Y GASTOS DEL PROYECTO ................................................. INFORME DE SITUACIÓN DE PROYECTO O PAQUETE DE TRABAJO ...................................... FORMATO DE GESTIÓN DE LA DOCUMENTACIÓN DEL PROYECTO .................................... FORMATO DE PROPUESTA DE CAMBIO ............................................................................... FORMATO PE REGISTRO DE CAMBIOS ............................................................................... R EPRESENTACIÓN GRÁFICA DE LOS INTERFACES EN UN PROYECTO ................................
165 166 169 171 175 176 178 179 182 183 184 186 187 187 188 189 190 190 196 200 204 207 210
FORMATO DE ACEPTACIÓN PARCIAL / FINAL DE LOS TRABAJOS ........................................ BALANCE DE INGRESOS Y GASTOS PARA EL CIERRE DEL PROYECTO ................................ FORMATO DE INFORME ECONÓMICO DEL CIERRE DE UN PROYECTO ................................
221 224 226
CAPÍTULO 5 FIGURA 5.1 FIGURA 5.2 FIGURA 5.3 FIGURA 5.4 FIGURA 5.5 FIGURA 5.6 FIGURA 5.7 FIGURA 5.8 FIGURA 5.9 FIGURA 5.10 FIGURA 5.11 FIGURA 5.12 FIGURA 5.13 FIGURA 5.14 FIGURA 5.15 FIGURA 5.16 FIGURA 5.17 FIGURA 5.18 FIGURA 5.19 FIGURA 5.20 FIGURA 5.21 FIGURA 5.22 FIGURA 5.23 CAPÍTULO 6 FIGURA 6.1 FIGURA 6.2 FIGURA 6.3
ÍNDICE DE FIGURAS XV FIGURA 6.4 FIGURA 6.5
FORMATO DE INFORME DE SITUACIÓN FINAL ............................................................... INDICADORES ECONÓMICOS DEL PROYECTO ................................................................
227 237
CONVERGENCIA DE FACTORES HACIA EL DESARROLLO DEL TELETRABAJO.....................
243
PLANIFICACIÓN TEMPORAL DEL ESTUDIO JURÍDICO ..................................................... PRESUPUESTO DEL ESTUDIO JURÍDICO ........................................................................ FLUJO DE ACTIVIDADES ASOCIADAS AL CONTRATO THERMOPC .................................... PLANIFICACIÓN DEL PROYECTO THERMOPC, FASE DE DISEÑO Y DESARROLLO ................ PLANIFICACIÓN DEL PROYECTO THERMOPC, FASE DE FABRICACIÓN .............................. ESTIMACIÓN DEL ESFUERZO ASOCIADO AL DISEÑO Y DESARROLLO DEL PROTOTIPO DE THERMOPC ...................................................................................... PRESUPUESTO DEL PROYECTO THERMOPC, FASE DE DISEÑO ......................................... ESTIMACIÓN DEL ESFUERZO ASOCIADO A LA FABRICACIÓN EN SERIE DE THERMOPC PRESUPUESTO DEL PROYECTO THERMOPC, FABRICACIÓN ........................................... PRESUPUESTO DEL PROYECTO THERMOPC, FASE DE FABRICACIÓN, VALORES
250 252 265 266 268
MODIFICADOS ...................................................................................................................................
277
PROCEDIMIENTO DE AUDITORÍA Y DIAGNÓSTICO DEL PROYECTO ................................... INFORME DE EVOLUCIÓN DEL PROYECTO DE FLORES DEL SUR, MES 3 ............................. INFORME DE SITUACIÓN ECONÓMICA DEL PROYECTO ................................................... RECURSOS CONSUMIDOS Y REMANENTES EN EL PROYECTO: HORAS (ARRIBA) E INGRESOS/COSTES (ABAJO)...................................................................................... ESTIMACIÓN MODIFICADA PARA EL PROYECTO FLORES DEL SUR ...................................
280 281 283
EPÍLOGO FIGURA E.l APÉNDICE A FIGURA A. 1 FIGURA A.2 FIGURA A.3 FIGURA A .4 FIGURA A.5 FIGURA A.6 FIGURA A.7 FIGURA A.8 FIGURA A.9 FIGURA A. 10 FIGURA A.11 FIGURA A.12 FIGURA A.13 FIGURA A.l 4 FIGURA A.l 5
269 271 273 274
285 286
APÉNDICE B FIGURA B. 1
INTERRELACIÓN DE LOS AGENTES QUE CONFIGURAN EL PROCESO DE DESARROLLO DE SOFTWARE...................................................................................................................................
291
FIGURA B.2 FIGURA B.3
FASE DE ANÁLISIS Y PLANIFICACIÓN .......................................................................... NO ES CONVENIENTE COMENZAR EL DESARROLLO MIENTRAS NO SE HAYAN
295
APROBADO FORMALMENTE LOS REQUISITOS DE USUARIO Y DEL SOFTWARE ...................
296
FIGURA B.4 FIGURA B.5 FIGURA B.6 FIGURA B.7 FIGURA B.8 FIGURA B.9 FIGURA B. 10 FIGURA B. 11 FIGURA B. 12 FIGURA B. 13 FIGURA B. 14
EVOLUCIÓN DE UN PROYECTO Y ACTUACIONES DE VALIDACIÓN Y VERIFICACIÓN ............. FASE DE DESARROLLO .............................................................................................. FASE DE OPERACIÓN Y MANTENIMIENTO ..................................................................... CICLO DB VIDA EN CASCADA (WATEBFALL)................................................................... CICLO DE VIDA INCREMENTAL ................................................................................... CICLO DE VIDA EVOLUTIVO ....................................................................................... VOLUMEN RELATIVO DE PARTICIPACIÓN SEGÚN CATEGORÍA Y FASE DEL PROYECTO . MODELO DE COSTES PARA PEQUEÑOS DESARROLLOS DE SOFTWARE ............................... ESTRUCTURA GENÉRICA DE UN MODELO DE COSTES ..................................................... IMPACTO ECONÓMICO DE LOS CAMBIOS A LOS REQUISITOS ............................................ PORCENTAJE MEDIO DE ESFUERZO DEDICADO A CADA TIPO DE MANTENIMIENTO DEL
298 303 304 305 306 308 311 312 312 314
SOFTWARE ........................................................................................................................................
317
FIGURA B. 15 FIGURA B. 16 FIGURA B.17
FORMATO DE NOTIFICACIÓN DE DISCONFORMIDAD ...................................................... FORMATO DE INFORME DE MODIFICACIÓN DEL SOFTWARE............................................. FORMATO DE HOJA DE ESTADO DEL DOCUMENTO .........................................................
318 319 320
ESTRUCTURA Y CONTENIDO DEL DISCO .......................................................................
324
APÉNDICE C FIGURA C.l
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 postventa, 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.
6 DIRECCIÓN Y GESTIÓN DE PROYECTOS
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).
8 DIRECCIÓN Y GESTIÓN DE PROYECTOS
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.
10 DIRECCIÓN Y GESTIÓN DE PROYECTOS
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.
12 DIRECCIÓN Y GESTIÓN DE PROYECTOS
2.1
© RA-MA
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.
14 DIRECCIÓN Y GESTIÓN DE PROYECTOS
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).
16 DIRECCIÓN Y GESTIÓN DE PROYECTOS
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: > > >
2.5
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.
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.
22 DIRECCIÓN Y GESTIÓN DE PROYECTOS
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. 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 M
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.
24 DIRECCIÓN Y GESTIÓN DE PROYECTOS
**" 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.
26 DIRECCIÓN Y GESTIÓN DE PROYECTOS
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,
28 DIRECCIÓN Y GESTIÓN DE PROYECTOS
© RA-MA
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 subsecciones 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.
30 DIRECCIÓN Y GESTIÓN DE PROYECTOS
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.
32 DIRECCIÓN Y GESTIÓN DE PROYECTOS
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 DI (4 personas) CO (4 personas) IS (11 personas) IJ (19 personas) TE (14 personas) PA (6 personas)
SUELDO BRUTO COSTES • - -ANUAL . - ; • ..: "SOCIALES 105.000 34.965 65.000 21.645 46.000 15.318 28.000 9.324 23.000 7.659 14.000 4.662
.
COSTE POR HORA 79,98 49,51 35,04 21,33 17,52 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
34 DIRECCIÓN Y GESTIÓN DE PROYECTOS
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 12.400
= 0,223
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* .
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.
36 DIRECCIÓN Y GESTIÓN DE PROYECTOS
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 perseasConcentrarse 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.
40 DIRECCIÓN Y GESTIÓN DE PROYECTOS
© RA-MA
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.
42 DIRECCIÓN Y GESTIÓN DE PROYECTOS
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.
> >
44 DIRECCIÓN Y GESTIÓN DE PROYECTOS
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) b) c) d)
La situación actual del mercado. El número e importancia (cuota de mercado) de los competidores. Las barreras de entrada y de salida. 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.).
CAPITULO 2: DRTECC1ON DE OPORTUNIDADES 45
©RA-MA
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) b) c) d) e)
Características generales. Diferencias con productos o servicios comparables de la competencia. Capacidad de evolucionar con el tiempo o capacidad para dar lugar a una familia de productos o servicios. Factores que pueden sumar o restar atractivo al producto. 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) b) c) d)
Estrategia de búsqueda de oportunidades. Canales de distribución. Forma de comercialización. 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) b) c) d)
Recursos humanos necesarios, y cualifícación de los mismos. Recursos materiales necesarios. Actividades a subcontratar y subproductos a adquirir. 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) b) c) d) e) f)
Hipótesis de trabajo utilizadas para las estimaciones económicas. Coste de poner en marcha la actividad. Coste del primer producto o servicio. Coste de productos o servicios adicionales (recurrentes). Coste de operación. Ingresos esperados.
46 DIRECCIÓN Y GESTIÓN DE PROYECTOS
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.
52 DIRECCIÓN Y GESTIÓN DE PROYECTOS
© RA-MA
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.
CAPITULO 2: DETECCIÓN DE OPORTUNIDADES 53
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: >
5.2
Obtener información acerca de las empresas disponibles (y dispuestas) para realizar este tipo de trabajos.
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
54 DIRECCIÓN Y GESTIÓN DE PROYECTOS
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.
CAPÍTULO 2: DETECCIÓN DE OPORTUNIDADES 55
CONSEJO GENERAL DEL PODER JUDICIAL Acuerdo de la Secretaria General del Consejo General del Poder Judicial por el que se anuncia concurso para la contratación de ¡a asistencia técnica para la elaboración de un estudio sobre la seguridad en las comanicaciones informáticas de los órganos judiciales en España. 1. Entidad adjudicadora; Consejo Genera] del Poder Judicial. calleMarqutsdela Ensenada, núme ro 8, 28071 Madrid, teléfono 91 700 61 00, tciefáx 700 63 51. 2. Objeto: Asistencia técnica para la elaboración de un estucho sobre la seguridad en las cwniuni cationes informáticas de los órganos judiciales en España. 3. Tramitación, procedimiento y forma de adju dicación: Concurso abierto de tramitación ordinaria. 4. Presupuesto base de licitación: 4.009.000 de péselas. 5. Garantía provisional: 2 por 100 del presu puesto de licitación. 6. Qbtrncion de documentación: Consejo Gene ral del Poder Judicial. Véase punto 1, y Centro de Documentación Judicial, calle Manterola. 13, 2.*, 20007 Donostia-San Sebastián, telefono 943 44 52 23, hasta el 31 de agosto de 1999. 7. Condiciones mínimas: Según pliegos. 8. Presentación de las ofertas o solicitudes de participación: Registro General del Consejo General del Poder Judicial, calle Marques de te Ensenada, número 8. planta baja, 28071 Madrid (horario de registro: líe lunes a viernes, de nueve a catorce 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), hasta el día 31 de agosto de 1999. 9. Apertura de proposiciones económicas: Ten 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.
CONCURSOS PÚBLICOS Mejora y acondicionamiento edificio Acc Canarias (CAN 142/99).. Por un importe de 31.223.833.- PTA (187.659 Euros). Suministro sistema de cargas artificiales transportables para prueba grupos electrógenos y sistemas eléctricos Región Canana (CAN 144/99). Por un importe de 10.397.750.- PTA (62.491,74 Euros). Estudio, análisis y verificación sistemas contraincendios D.R.N.A. Canaria (CAN 145/99). Por un importe de 5.747.500.- PTA (34.543,17 Euros). Ampliación sistemas iluminación Centro EmisoresReceptores del Pico de ta Gorra y Centro de Control (CAN 152/99). Por un importe de 21.943.480- PTA (131.883 Euros). Asistencia Técnica para el estudio de una red de comunicaciones por microondas para N.A. en la Región Canaria (CAN 153/99), Por un importe de 11.973.272.-PTA (71.960,8 Euros). Remodelación Antiguo Edificio Administrativo (CAN 154/99). Por un importe de 156.709.905 ■ PTA (941.845 Euros). Disponibilidad de documentación: Información en el D" Económico Administrativo de la Dirección Regional de Navegación Aérea. Ojo; de Garza, s/n. Telde, Gran Canaria. Teléfono: 928 57 70 20 y 928 57 70 21 Presentación de ofertas: Hasta las 13.30 horas del día 03/09/99, en el Departamento antes citado. Comunicación de empresas presentadas: A partir del día 07/09/99 en el tablón de anuncios de la Oficina de Contratación. Apertura de ofertas: Se comunicará oportunamente
PUBLICIDAD El importe de este anuncio será por cuenta de los adjudicatarios.
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.
56 DIRECCIÓN Y GESTIÓN DE PROYECTOS
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 PUNTOS 2.1.- REBAJAS AL PRESUPUESTO MÁXIMO
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
3 3,0
58 DIRECCIÓN Y GESTIÓN DE PROYECTOS
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.
CAPÍTULO 2: DETECCIÓN DE OPORTUNIDADES 59
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: L*
10+9+8+7+4
. . ^^ = — ------------------- = /.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.
60 DIRECCIÓN Y GESTIÓN DE PROYECTOS
Haciendo uso de la expresión anterior, la lista de puntos obtenidos por cada licitante queda como sigue: Licitante 1 2 3
4 5 6
Precio ofertado'' Puntuación 10,5 Descalificado 10 0 9 1,25 8 2,5 7 2,5 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.
62 DIRECCIÓN Y GESTIÓN DE PROYECTOS
© RA-MA
^ 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: >* >
5.6
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).
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.
CAPITULO 2: DETECCIÓN DE OPORTUNIDADES 63
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.
64 DIRECCIÓN Y GESTIÓN DE PROYECTOS
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 Vestido y calzado Vivienda Menaje Medicinas Transporte Comunicaciones . Ocio y cultura Enseñanza Hoteles, restaurantes y cafeterías Otros
•3,n% : 9,73 % 10,69 % 6,41 % 2,68 % 14,4% 2,99 % 6,76 % 1,67% 11,23% 7,39 %
La figura 2.6 muestra de manera gráfica la ponderación de cada uno
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.
66 DIRECCIÓN Y GESTIÓN DE PROYECTOS
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:
68 DIRECCIÓN Y GESTIÓN DE PROYECTOS
Mes 0. " 1-.000 ' ■ 1,000 67.500 67.500 0 Mes! 1,003 0,998, • 7.500 7,431 0 Mes 2■-; ims 0,995 7.5,00 7.463,. 0 Mesa1,008 O;993 . ' -7-500 • . 7.444 0 Mes 4 ','., 1,010 0,990 ' 7t5G0 • 7.425 0 Mes -5" 1,013 0,988 7S0Í3 7,407 0 Mesé 1,015 = 9,985 7.600 , , . 7,388 0 Mes 7 . t,018 "* 0,983 ' 7.5SO7,370 *~ 0 Mes 8 ■ 1,020 . 0,980 7.500' ' s 7.352 ' 0 Mes 9 1,023 - ; "0,978 . f,SOO"" 7.333 0 Mes 10 - 1,025 " \ OiWS 7.500 . 7.315 0 Mes 11tflm m . : 0,973. • ;_ 7300 7.297 0 Mes 12 1.03Q* - 0,970' 7.50Q 7.279 0 Ifes Í3:1.033 0,968 ^ " . 7.SQ0^ . - 7.260 0 Mes 14 1,036 0,966 7.500 ' 7J242 ' 0 Mes 15 1,038 «963 7.500. '7.224 . 0 Mes 16 1,041 "0,961 7,500 ■ 7.206 . 0 ,Mes 171,043 0,958 ' 7.500 7.Í88 0 Mes 18 . 1J346 0,95ó 7.5ÓÓ" 7.170, 0 Mes 191,049 „ .0,954 \ „ . 7.S00 " „« X163 0 : Mes 20 1,05! %M JJXtí 7-135 0 Mes 21 1,054 0.-949 7.500 7.117 0 Mes 22 1,056 0,947 7.500 7.099 0 Mes 231,05? ,0,944 . , . 7.5007.081 , 300.000 283.257 TOTAL
(Euroá
VALORACTUAL DEL MAf^EN (Euros)
240.000234.931
300.000
0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0
283.257 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á^ue, 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:
CAPÍTULO 2: DETECCIÓN DE OPORTUNIDADES 69
FLUJOS MONETARIOS ACTUALIZADOS, r-3% anual (0,257o mensual) Gastos (Eur)
1,000 Mesl Mes 2 Mes 3 Mes 4 Mes 5 Mes 6 Mes 7 Mes 8 Mes 9 Mes 10 Mes 11 Mes 12 Mes 13 Mes 14 Mes 15 Mes 16 Mes 17 Mes 18 Mes 19 Mes 20 Mes 21 Mes 22 Mes 23
1,005 1,008 1,010 1,013 1,015 1,018 1.020 1,023 1$25 1,028 1,030 1,033 Í.036 1,038 1,041 1,043 1,046 1,049 1,051 1,054 1,056 1,059
1,000 0,99$ 0,995 0,993 0,990 0,988 0,985 0,983 0,980 #,978 0,975 0,fT3 0,970 0,968 • ©,966 0,963 0,961 Q,95S 0,956 0,954 0,951 ff,949 0,947 0,944
TOTAL (Euros)
37.500 7.500 7.500 7.500 7JO0 7.500 7.500 7.500 7.500 7.500 7300 7.500 37.500 7.500 7.500 7.500 7.800 7.500 7.500 7.500 7.500 7.500 7.M0 7.500
VA_Sastos H
Ingresos (Eur)
VA_Ingresos
37.500 7.481 7.463 7 444
7.425 7.407 7-388 7.370 7J32 7.333 7.315 7.297 36,39 3 7.260 7.242 7.224 7.206 7,188 7,170 7.153 7.135 7.117 7.099 7.081
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.
72 DIRECCIÓN Y GESTIÓN DE PROYECTOS
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
74 DIRECCIÓN Y GESTIÓN DE PROYECTOS
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 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. i
Figura 3.2
28
Estimación del coste y el precio de un proyecto
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.
CAPITULO 3: EVALUACIÓN DEL PROYECTO 75
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 superestructuras 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
> >
3.1.2
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.
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.).
>
78 DIRECCIÓN Y GESTIÓN DE PROYECTOS
© RA-MA
>• 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
CAPITULO 3: EVALUACIÓN DEL PROYECTO 79
© RA-MA
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
30
etc.) que pueden incrementar notablemente el esfuerzo requerido 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.
CAPITULO 3: EVALUACIÓN DEL PROYECTO 81
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
82 DIRECCIÓN Y GESTIÓN DE PROYECTOS
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 100 horas X36,0
— 5.920 €, con un ingeniero sénior, y == 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
84 DIRECCIÓN Y GESTIÓN DE PROYECTOS
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.
CAPITULO 3: EVALUACIÓN DEL PROYECTO 85
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.
86 DIRECCIÓN Y GESTIÓN DE PROYECTOS
>
>
© RA-MA
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).
CAPÍTULO 3: EVALUACIÓN DEL PROYECTO 89
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
90 DIRECCIÓN Y GESTIÓN DE PROYECTOS
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^etivo 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
CAPITULO 3: EVALUACIÓN DEL PROYECTO 91
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.
92 DIRECCIÓN Y GESTIÓN DE PROYECTOS
© RA-MA
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.
CAPITULO 3: EVALUACIÓN DEL PROYECTO 93
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.
CAPITULO 3: EVALUACIÓN DEL PROYECTO 95
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.
CAPÍTULO 3: EVALUACIÓN DEL PROYECTO 97
^ 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).
98 DIRECCIÓN Y GESTIÓN DE PROYECTOS
> > >
>
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
33
Planificación inicial del proyecto de instalación de un portón
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.
CAPITULO 3: EVALUACIÓN DEL PROYECTO 99
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.
>
100 DIRECCIÓN Y GESTIÓN DE PROYECTOS
4.2
©RA-MA
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".
CAPITULO 3: EVALUACIÓN DEL PROYECTO 101
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
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.
102 DIRECCIÓN Y GESTIÓN DE PROYECTOS
> 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
104 DIRECCIÓN Y GESTIÓN DE PROYECTOS
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
CAPITULO 3: EVALUACIÓN DEL PROYECTO 105
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.
CAPITULO 3: EVALUACIÓN DEL PROYECTO 107
■ 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
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:
108 DIRECCIÓN Y GESTIÓN DE PROYECTOS
■ 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
A la vista de i •
Secuencia de actividades del proceso de preparación del avión
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
CAPITULO 3: EVALUACIÓN DEL PROYECTO 109
■ 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.
CAPITULO 3: EVALUACIÓN DEL PROYECTO 111
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.
112 DIRECCIÓN Y GESTIÓN DE PROYECTOS
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.
CAPITULO 3: EVALUACIÓN DEL PROYECTO 113
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.
114 DIRECCIÓN Y GESTIÓN DE PROYECTOS
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 subsecció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.
CAPITULO 3: EVALUACIÓN DEL PROYECTO 115
>
>
>
>
>
>
>
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.
>
18 DIRECCIÓN Y GESTIÓN DE PROYECTOS
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).
CAPÍTULO 3: EVALUACIÓN DEL PROYECTO 119
P.032-99
Referencia :
PAQUETE DE TRABAJO :
PT.O
Fecha:
Edición
01.12.04
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. P.032-99
Referencia:
PT.31Ü
PAQUETE DE TRABAJO:
Edición :
Fecha:
01.12.04
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"
CAPITULO 3: EVALUACIÓN DEL PROYECTO 121
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
(1
GESTIÓN
60
60
2 3
DISEÑO DEL SISTEMA
100
4
Análisis del sistema
110
8
60
5
Diseño HWSW
120
8
40
16
84 48
6 7
DFSAIÍROM,O DE1. SISTEMA
200
8
Desarrollo de la aplicación
210
9 10
Adquisición e instalación HW
22(1
Integración HW / SW
230
300
16
316
80
80
40
40
80
24
24
24
16
II 12
FORMACIÓN
300
13
Preparación del curso
310
14
Impartición del curso
320
8
16
64 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.
CAPITULO 3: EVALUACIÓN DEL PROYECTO 123
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.
124 DIRECCIÓN Y GESTIÓN DE PROYECTOS
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: > > >
70 km. ida y vuelta Varios TOTAL
15€ 25 € 40 /desplazamiento
Viajes a Sevilla, de 1 día de duración: > > >
Desplazamiento Gastos TOTAL
350 € 100 € 450 Euros /viaje
Viajes a Sevilla, de 2 días de duración: > > >
Desplazamiento Hotel Gastos
350 € 150€ 150 €
>
TOTAL
650 Euros/viaje
Euros
CAPÍTULO 3: EVALUACIÓN DEL PROYECTO 125
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:
>
41
3 x Ordenador Pentium 4 1 x Modem
5.400 € 200 €
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 4 x Segmentos de red
200 € 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 €.
CAPITULO 3: EVALUACIÓN DEL PROYECTO 127
HOJA DE ESTIMACIÓN ECONÓMICA DE PROYECTO
REFERENCIA : DIRECTOR :
Red de Sre local y BD de stock More 3 ÜBÍ Sur, S.A.
Arm
ene-05
FECHA INICIO
P 032-99 ndo Bronca S mav-05
PRECIO VENTA (SIN IVA): ESFUERZO: MARGEN:
1.A COSTES DE PERSONAL
CAT 1 (DI) ^AT 2 (CO) CAT 3(IS) ;AT 4 (IJ| CAT 5 (TE) CAT 6 (PA|
79.98 49.51 35.04 21,33 17,52 10,66
B4 488 160 48
1,69 1,69 1,69 1,69 1,69 1,69
2,00% 3,00% 4,00% 5,00% 5,00% 6,00%
C C 5.173 18.471 4.974 917
SUBTOTAL 1.B SUBCONTRATACIONES SU8CJ SUBC_2 SUBTOTAL 1.C COSTES VARIOS ORDENADOR: CONSUMIBLES : OTROS
780 780 780
2,34 0,75 3.09 : -, -------- 1
SUBTOTAL 1.D OTROS GASTOS
1,00 1,00 1,00
5,00% 5,00% 5.00%
MATERIAL/EQUIPO VIAJES / ESTANCIAS VARIOS :
TOTAL COSTES Y GASTOS
Z, PRECIO DE VENTA . 2.A MARGEN
PERSONAL SUBCONTRATACIONES COSTES VARIOS OTROS GASTOS
29.535 0 12,00%
12,00%
2 531 15.219 47 285
TOTAL
2.B PRECIO DE VENTA PRECIO DE VENTA, Euros, SIN ESCALACION INTERANUAL PRECIO DE VENTA, Euros, CON IVA al...
Figura 3.23
[
16.00%|
Presupuesto estimado para el proyecto Flores del Sur
;gi¡ra
128 DIRECCIÓN Y GESTIÓN DE PROYECTOS
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
CAPITULO 3: EVALUACIÓN DEL PROYECTO 129
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 DI CO IS IJ TE PA TOTAL
MES1
MES 2
MES 3
MES 4
TOTAL
29 90
17 150
16 135
8 175
15 160 80 8 263
23 SS 80 16 207
84 488 160 48 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.
130 DIRECCIÓN Y GESTIÓN DE PROYECTOS
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.
132 DIRECCIÓN Y GESTIÓN DE PROYECTOS
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.
CAPITULO 3: EVALUACIÓN DEL PROYECTO 133
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):
CAPÍTULO 4: PREPARACIÓN DE LA OFERTA 137
©RA-MA
>
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.
140 DIRECCIÓN Y GESTIÓN DE PROYECTOS
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.
142 DIRECCIÓN Y GESTIÓN DE PROYECTOS
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.
144 DIRECCIÓN Y GESTIÓN DE PROYECTOS
*" 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: > > > >
4.
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.
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".
CAPITULO 4: PREPARACIÓN DE LA OFERTA 145
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
146 DIRECCIÓN Y GESTIÓN DE PROYECTOS
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
CAPÍTULO 4: PREPARACIÓN DE LA OFERTA 147
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
4.2
>
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.
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.
148 DIRECCIÓN Y GESTIÓN DE PROYECTOS
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.
CAPÍTULO 4: PREPARACIÓN DE LA OFERTA 149
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:
150 DIRECCIÓN Y GESTIÓN DE PROYECTOS
EXPERIENCIA CORPORATIVA Proyecto : Comienzo : Descripción =
Plan de informatización de obras Feb-1995
Cliente :
MINISTERIO DE FOMENTO
Final :
Ene-1996
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 :
Comienzo : Descripción ;
Nov-1996
Final :
Proyecto ;
Abono-Bus
Cliente :
Comienzo : Descripción :
Jun-1998
Final :
Proyecto :
Red de área local de Flores del Sur Ene-2005
Comienzo : Descripción :
Proyecto ¡ Comienzo : Descripción :
5.
Agencia Espacial Euroasiática (ESA) Mar-1999
Implantación de una red de comunicaciones SDH para difusión de datos de telemetría de satélite entre Siberia y Mongolia. Ayuntamiento de Parrandilla la Viera (Lugo) Dic-2000
Diseño e implantación de un sistema de monedero electrónico y abono transportes para la red de autobuses de Parrandilla la Viera. Cliente :
Flores del Sur (Sevilla)
Final :
May-2005
Implantación de una red de área local con equipamiento hardware/software para la gestión integrada de pedidos, envíos y stocks. 05-NET (Operational Synchonous NETwork) Ene-2001
Cliente : Final :
Unión Europea ESPRINT) En curso
(Programa
Diseño detallado de los centros de conmutación de datos multimedia para redes corporativas de banda ancha.
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.
CAPITULO 4: PREPARACIÓN DE LA OFERTA 151
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.
CAPÍTULO 4: PREPARACIÓN DE LA OFERTA 153
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?
154 DIRECCIÓN Y GESTIÓN DE PROYECTOS
¿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
CAPITULO 4: PREPARACIÓN DE LA OFERTA 157
■
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
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:
160 DIRECCIÓN Y GESTIÓN DE PROYECTOS :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.
CAPITULO 5: SEGUIMIENTO DEL PROYECTO 163
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.
164 DIRECCIÓN Y GESTIÓN DE PROYECTOS
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.
168 DIRECCIÓN Y GESTIÓN DE PROYECTOS
> >
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
CAPITULO 5: SEGUIMIENTO DEL PROYECTO 169
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
NOMBRE
Sv
" HJKÍ:
AGENDA:
Ht HhHO : AGENDA.DÍK
Página I
Figura 5.3
Formato de convocatoria de reunión
•
• fttf 11
IMPRESA
170 DIRECCIÓN Y GESTIÓN DE PROYECTOS
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
172 DIRECCIÓN Y GESTIÓN DE PROYECTOS
©RA-MA
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.
174 DIRECCIÓN Y GESTIÓN DE PROYECTOS
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).
CAPITULO 5: SEGUIMIENTO DEL PROYECTO 175
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.
176 DIRECCIÓN Y GESTIÓN DE PROYECTOS
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
CAPITULO 5: SEGUIMIENTO DEL PROYECTO 177
©EíA-MA
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
FICHERO : Form:iH> Resumen Rennioii.díic
Figura 5.7
CARGO
III III 2IMI4
Formato de resumen de reunión
CAPÍTULO 5: SEGUIMIENTO DEL PROYECTO 179
Por su parte, la figura 5.8 muestra algunos aspectos a considerar al redactar el resumen de la reunión1.
Figura 5.8
4.
Lo que se debe y no se debe hacer al redactar el resumen de una reunión
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.
180 DIRECCIÓN Y GESTIÓN DE PROYECTOS
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
>
> >
4.1
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.
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).
182 DIRECCIÓN Y GESTIÓN DE PROYECTOS
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
4.2
Lo que se debe y no se debe hacer al redactar el estado de las acciones
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.
184 DIRECCIÓN Y GESTIÓN DE PROYECTOS
© RA-MA
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.
CAPÍTULO 5: SEGUIMIENTO DEL PROYECTO 185
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.
CAPITULO 5: SEGUIMIENTO DEL PROYECTO 187
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,
188 DIRECCIÓN Y GESTIÓN DE PROYECTOS
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.
CAPITULO 5: SEGUIMIENTO DEL PROYECTO 189
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.
190 DIRECCIÓN Y GESTIÓN DE PROYECTOS
Figura 5.17
Figura 5.18
Evolución del consumo de horas de trabajo del proyecto
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).
CAPITULO 5: SEGUIMIENTO DEL PROYECTO 191
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.
hfcras pristas
Hcrasreeles flUBFEB d9Q9StOG AaxeneEÍ
BE FB 32D B 460 7% 17 % 340 420 7% 16 % 5% 20 %
IWR 400 28 % 410 25 % 24 %
35 2 33 % 360 33 % 31 %
IWY 48 0 43 % 476 43 % 3£P/o
JL JU SB N 480 _32 160 >400 0 5*% 61 64% 73 % % 480 300 80 320 53 60 61% 63 % % % 44 51 53% 61 % % %
OC rev DC Total T490 493 320 4672 £G 100% 83 % % 3186 eap/o 61%
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).
192 DIRECCIÓN Y GESTIÓN DE PROYECTOS
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
CAPITULO 5: SEGUIMIENTO DEL PROYECTO 193
©RA-MA
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
TOTAL
H - = 5.223- Horas Avance
0,61
194 DIRECCIÓN Y GESTIÓN DE PROYECTOS
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.
CAPITULO 5: SEGUIMIENTO DEL PROYECTO 195
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.
196 DIRECCIÓN Y GESTIÓN DE PROYECTOS
© RA-MA
Informe de situación
NOMBRE DEL PROYECTO
[] Intermedio D Final
INFORME DE ACTIVIDAD / PROYECTO CLIENTE :
PROYECTO/PT: TITULO : RESPONSABLE : FECHA COMIENZO:
TERMINADO:
TRABAJO REALIZADO. ALTERACIONES AL ALCANCE PREVISTO
RESUMEN DEL ESTADO : 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
- Sí
i
No
Descripción
_
I l( III K< >: informe siluLición.
Figura 5.19
5.1
Informe de situación de proyecto o paquete de trabajo
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:
CAPÍTULO 5: SEGUIMIENTO DEL PROYECTO 197
&* 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 integrantesdel 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
198 DIRECCIÓN Y GESTIÓN DE PROYECTOS
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: > > 5* > > >
El tipo o naturaleza del documento (nota técnica, informe de situación, fax, etc.). El proyecto dentro del cual se genera. 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:
CAPÍTULO 5: SEGUIMIENTO DEL PROYECTO 199
1 CÓDIGO Tipo documento
CÓDIGO Tipo documento
FX
Fax
CI
MN NT
Minutas Nota técnica
RR DD
SP PL
Especificación Plano
IS
Comunicación interna Resumen de reunión Documento de diseño Informe de situación
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).
200 DIRECCIÓN Y GESTIÓN DE PROYECTOS
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 : RESPONSABLE :
REFERENCIA
: CLIENTE
:
HOJA:
1 1 í*f1' ' " *■ ■
—
Figura 5.20
—
Formato de gestión de la documentación del proyecto
SOPORTE
CAPITULO 5: SEGUIMIENTO DEL PROYECTO 201
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.
202 DIRECCIÓN Y GESTIÓN DE PROYECTOS
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
CAPITULO 5: SEGUIMIENTO DEL PROYECTO 205
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: ^ íS=
Identificar él alcance práctico del cambio. 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:
206 DIRECCIÓN Y GESTIÓN DE PROYECTOS
**
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.
CAPITULO 5: SEGUIMIENTO DEL PROYECTO 207
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
208 DIRECCIÓN Y GESTIÓN DE PROYECTOS
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.
210 DIRECCIÓN Y GESTIÓN DE PROYECTOS
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: >
> >
7.2.1
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.
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.
CAPITULO 5: SEGUIMIENTO DEL PROYECTO
211
*" 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.
212 DIRECCIÓN Y GESTIÓN DE PROYECTOS
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
CAPÍTULO 5: SEGUIMIENTO DEL PROYECTO 213
©RA-MA
referencia) los aspectos más concretos del trabajo. En general, la información más importante suele centrarse en los siguientes puntos: > > > > >
7.3
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?
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.
214 DIRECCIÓN Y GESTIÓN DE PROYECTOS
©RA-MA
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
216 DIRECCIÓN Y GESTIÓN DE PROYECTOS
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^et 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ó).
CAPITULO 5: SEGUIMIENTO DEL PROYECTO
217
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:
220 DIRECCIÓN Y GESTIÓN DE PROYECTOS
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
222 DIRECCIÓN Y GESTIÓN DE PROYECTOS
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 > > > > >
3.1
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.
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.
224 DIRECCIÓN Y GESTIÓN DE PROYECTOS
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).
CAPITULO 6: CIERRE DEL PROYECTO 225
© RA-MA
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,
226 DIRECCIÓN Y GESTIÓN DE PROYECTOS
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.
CAPITULO 6: CIERRE DEL PROYECTO 227
© RA-MA
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: TITULO : RESPONSABLE : FECHA COMIENZO:
CLIENTE :
TERMINADO:
TRABAJO REALIZADO. ALTERACIONES AL ALCANCE PREVISTO
DIFICULTADES ENCONTRADAS
OTROS COMENTARIOS
RESUMEN DEL ESTADO : Si
Modificaciones al alcance
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
228 DIRECCIÓN Y GESTIÓN DE PROYECTOS
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
4.
S5 RA-MA
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
CAPITULO 6: CIERRE DEL PROYECTO 231
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: Coste hora =
30.054-7.800-(l+0,08)-6.870-(l+0,03) „A „ ---------- ——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
CAPITULO 6: CIERRE DEL PROYECTO 233
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: End externo =
7.500 + 7.500 + 900 + 4.500 = 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:
234 DIRECCIÓN Y GESTIÓN DE PROYECTOS
r=
Ingresos - Costes _ Margen 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).
236 DIRECCIÓN Y GESTIÓN DE PROYECTOS
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.
CAPITULO 6: CIERRE DEL PROYECTO 237
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
238 DIRECCIÓN Y GESTIÓN DE PROYECTOS
©RA-MA
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.
240 DIRECCIÓN Y GESTIÓN DE PROYECTOS
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).
244 DIRECCIÓN Y GESTIÓN DE PROYECTOS
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.
248 DIRECCIÓN Y GESTIÓN DE PROYECTOS
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.
250 DIRECCIÓN Y GESTIÓN DE PROYECTOS
Figura A.l
2.4
© RA-MA
Planificación temporal del estudio jurídico
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 Revisión expedientes Elaboración conclusiones Curso de PC Elaboración informe Presentación
Mfyrrff 165 M 48 12 80 4
9,00 9,00 9,00 9,00 9,00
1.485 432 108 720 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.
252 DIRECCIÓN Y GESTIÓN DE PROYECTOS
© 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?
254 DIRECCIÓN Y GESTIÓN DE PROYECTOS
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
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
3.1
Introducción y antecedentes
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
256 DIRECCIÓN Y GESTIÓN DE PROYECTOS
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
258 DIRECCIÓN Y GESTIÓN DE PROYECTOS
•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
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.
262 DIRECCIÓN Y GESTIÓN DE PROYECTOS
aplicación DOS a ejecutar en el PC se arrancará mediante un comando DOS í:>tliermojpc 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 CDROf
APÉNDICE A: EJEMPLOS DE EVALUACIÓN ECONÓMICA DE PROYECTOS 263
í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
264 DIRECCIÓN Y GESTIÓN DE PROYECTOS
>
>
>
>
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.
APÉNDICE A: EJEMPLOS DE EVALUACIÓN ECONÓMICA DE PROYECTOS 265
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:
266 DIRECCIÓN Y GESTIÓN DE PROYECTOS
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.
268 DIRECCIÓN Y GESTIÓN DE PROYECTOS
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.
APÉNDICE A: EJEMPLOS DE EVALUACIÓN ECONÓMICA DE PROYECTOS 269
1 2 3 4 5 6 7
12
GESTIÓN
]2
DISEÑO HW/SW, ALTO NIVEL
16
16
32
KABRICACION DEL PRO 101IPO
-1
16
2U
8
40
48
16
16
8
16
DESARROLLO SW
I 9 ID 11 12 13 14 15 16 17 18 ly 211
INTEGRACIÓN Y PRUEBAS DOCUMENTACIÓN
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.
APÉNDICE A: EJEMPLOS DE EVALUACIÓN ECONÓMICA DE PROYECTOS 271
Figura A.7
3.4.2
Presupuesto del proyecto ThermoPC, fase de diseño.
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).
272 DIRECCIÓN Y GESTIÓN DE PROYECTOS
^ 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) Placa circuito impreso Componentes Cables y conectores Caja y lomillería Diskette/CD, duplicación y etiqueta Copia del manual Embalaje de cartón
14,70 0,75 2,10 1,30 0,60 0,35 0,15 0,10
60 6.000 6.000 6.000 6.000 6.000 6.000 6.000
882
4.500 12.600 7.800 3.600 2.100 900 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.
APÉNDICE A: EJEMPLOS DE EVALUACIÓN ECONÓMICA DE PROYECTOS 273
i
GISI1ON
228
228
2 3
COMPRAS
24
24
448
568
4
5
FABRICACIÓN DEL CIRCUITO IMPRESO
6
7
MONTAJE Y PRUEBAS
3.360
8 9
RMBAIAJE
10 11
GARANTÍA
120
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.
276 DIRECCIÓN Y GESTIÓN DE PROYECTOS
En las condiciones anteriores, la tabla de costes de la fase de fabricación queda como sigue: CONCEPTO
COSTE
Viajes y Estancias: proyecto
CANT.
TOTAL
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.
APÉNDICE A: EJEMPLOS DE EVALUACIÓN ECONÓMICA DE PROYECTOS 277
278 DIRECCIÓN Y GESTIÓN DE PROYECTOS
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_____________
4.
APÉNDICE A: EJEMPLOS DK EVALUACIÓN ECONÓMICA DE PROYECTOS 279
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.
4.1
Introducción y antecedentes
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.
280 DIRECCIÓN Y GESTIÓN DE PROYECTOS
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
4.3
Procedimiento de auditoría y diagnóstico del proyecto
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:
APÉNDICE A: EJEMPLOS DE EVALUACIÓN ECONÓMICA DE PROYECTOS 281
>
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.
282 DIRECCIÓN Y GESTIÓN DE PROYECTOS
> > >
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.
APÉNDICE A: EJEMPLOS DE EVALUACIÓN ECONÓMICA DE PROYECTOS 283
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
>
> >
4.4
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.
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.
APÉNDICE A: EJEMPLOS DE EVALUACIÓN ECONÓMICA DE PROYECTOS 285
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.
286 DIRECCIÓN Y GESTIÓN DE PROYECTOS
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
288 DIRECCIÓN Y GESTIÓN DE PROYECTOS
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.
290 DIRECCIÓN Y GESTIÓN DE PROYECTOS
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
2.1
Interrelación de los agentes que configuran el proceso de desarrollo de software
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
292 DIRECCIÓN Y GESTIÓN DE PROYECTOS
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.
APÉNDICE B: GESTIÓN DE PROYECTOS DE DESARROLLO DE SOFTWARE 293
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.
294 DIRECCIÓN Y GESTIÓN DE PROYECTOS
^
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.
296 DIRECCIÓN Y GESTIÓN DE PROYECTOS
DESARROLLO SOFTWARE APROBACIÓN GESTOR / USUARIO
RRU / RRS
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
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
APÉNDICE B: GESTIÓN DE PROYECTOS DE DESARROLLO DE SOFTWARE 299
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 M . ÚQ^measwúbW'o, en español A de "'achievahíe^-Q, en español R de "re/evemf* o. en español; J . de ^tfackahié" o, en español
Concreto Cuantifícable Realista Pertinente 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).
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
2.1.3
Fase de desarrollo
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.
304 DIRECCIÓN Y GESTIÓN DE PROYECTOS
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
2.2
Fase de operación y mantenimiento
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.
APÉNDICE Bi GESTIÓN DE PROYECTOS DE DESARROLLO DE SOFTWARE 305
©RA-MA
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.
308 DIRECCIÓN Y GESTIÓN DE PROYECTOS
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.
APÉNDICE B: GESTIÓN DE PROYECTOS DE DESARROLLO DE SOFTWARE 309
© RA-MA
> > >
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.
APKNDICE B: GESTIÓN DE PROYECTOS DE DESARROLLO DI; SOFTWARE 311
© RA-VÍA
RU
RS
DA
DD
TR
PR
OM
■ DI ■ 15 H IJ D TE D PA Figura B.IO
3.2
Volumen relativo de participación según categoría y fase del proyecto
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 D = Duración = 4.1x1 D = Duración = 2.47xÉK3ñ P = Personal = 0.54xE0/J DOC = Documentación = 49 xL1'01
hombres-mes meses meses personas 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.
314 DIRECCIÓN Y GESTIÓN DE PROYECTOS
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
APÉNDICE B: GESTIÓN DE PROYECTOS DE DESARROLLO DE SOFTWARE 315
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.
316 DIRECCIÓN Y GESTIÓN DE PROYECTOS
© RA-MA
*" 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
4.
Porcentaje medio de esfuerzo dedicado a cada tipo de mantenimiento del software
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.).
318 DIRECCIÓN Y GESTIÓN DE PROYECTOS
© RA-MA
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
320 DIRECCIÓN Y GESTIÓN DE PROYECTOS
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:
322 DIRECCIÓN Y GESTIÓN DE PROYECTOS
^ 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.
324 DIRECCIÓN Y GESTIÓN DE PROYECTOS
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
> > > > >
>
>
> > > >
íS=
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.
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.
326 DIRECCIÓN Y GESTIÓN DE PROYECTOS
© RA-MA
> 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
181 acciones 182 estado de las aceptación provisional 302 actividad 76, 100 crítica 100 virtual adaptaciones adjudicación 101 administración análisis del valor 202 añadido análisis y planificación 153 anteproyecto árbol de tareas avance 25 curva de 190 económico 291 técnico 4 75
B
balance de ingresos y gastos barreras de entrada de salida beneficio extra
184 223 185 183 40,41 40,41 1 223
camino critico Caos Consulting carga de trabajo ciclo de vida cascada
100, 103 29, 112,228,255,279 81, 112,235 290 304
evolutivo fases incremental tipos cierre administrativo contable técnico cliente creación de necesidades codificación comunicación interna concurso abierto negociado objetivos publicidad restringido conflictos interpersonales consultor contingencias contrato adjudicación de consultoría y asistencia de gestión de servicios públicos de obras de suministros no adjudicación tipos control de configuración correcciones coste coeficientes de consumibles de los cambios de mantenimiento
307 291 305 304 16 16 16 40 48 291 164
47,50 54 54 53 53 54 208 85
10,91 39,215 15 61 61 61 61 15 61
195,317 202 7 91 33 314 315
328 DIRECCIÓN Y GESTIÓN DE PROYECTOS
de oportunidad 33 equipos informáticos 32 general 84 interno 31 laboral 84 material y equipo 311 modelo 87 ocultos 35,84 otros 309 por linea de programa 84 subcontrataciones 87 varios 84 viajes y estancias CPM 100 criterios de valoración curriculum 57, 140, 143 versión corta 144 versión larga curriculum vitae
D decisiones estratégicas operativas tácticas desarrollo desviaciones causas detección de oportunidades dirección de proyectos director de proyecto diseño arquitectónico documento de revisión diseño de alto nivel diseño de la arquitectura diseño detallado revisión documentación aspectos legales complementaria conservación custodia de gestión difusión distribución gestión de no reutilizable reutilizable técnica vinculante documento de diseño de diseño detallado
147 145 139
213 213 213 213 291 208, 236, 284 208
12,39 ' 24 25, 209 300 300 300 300 291 291,301 301 228,317 215 197 229 229 197 229 199 196 199 199 197 215 300 301
de transferencia historia del proyecto
302 304
E efecto fiscal empresa 254 esfuerzo estado del 17 arte estilo de 19 dirección 4 déspota-autoritario 215 indeciso 214 negociador 214 participativo vitae 214 progresivo EVA 214 Véase análisis del valor añadido evaluación 308 económica F fax fiabilidad Flores del Sur flujo de caja formato aceptación avance balance de ingresos y gastos comunicación interna control de configuración 200, convocatoria de reunión estado de las acciones estado del documento evolución económica fax horas informe de modificación del software informe de situación informe de situación final informe económico de cierre minutas de reunión notificación de incidencias plan financiero presupuesto propuesta de cambio registro de estado de cambios resumen de reunión
16 30 4 11 4 3 11 0 22 1 18 5 22 16 3 32 4 0 16 18 9 32 2 180 16 8 80 4 31 9 19 22 4 7 22 17 6 4 31 11 8 0 92 20 20 4 17 7 7
G Gantt gasto estimación
268.
97 7 27 1
©RA-MA ______________________________________________________________ ÍNDICE ALFABÉTICO 329
gestión 22 administrativa 26 de cambios 202 de compras 24, 88 de costes 23 de la calidad 23 de la comunicación 23 de la documentación 196 de los productos 201 de los recursos humanos 23 de recursos temporales Véase planificación de riesgos 24 del alcance y contenido 23 27 estratégica 2 °Peratlva A ac uetede P, " ™ tactlca
26
tecmca
23
H historia del proyecto holgura horas
304 100, 104
fC know-how
T
ligaduras lucro
100 7
MAC
mantenimiento adaptativo correctivo perfectivo manual de usuario margen mejora competitiva mejoras mercado estrategia de nichos de MIC
estimación
268,271 40-20-40 de costes Walstony Félix
impuestos incertidumbre indicadores beneficio componentes del coste coste por hora de gestión de ocupación laboral económicos
Véase saber hacer
254 10 230 230
231 231 236 234 230
negociación cuhuras de
__ -^* ,02 303 316 316 316 301 8 72 202 40 45 40 101 modelo 311 311 313 ^ ■*■* 34 35
O
9
330 DIRECCIÓN Y GESTIÓN DE PROYECTOS proceso proyectual recursos seguimiento trabajo en equipo paquete de trabajo actividades excluidas descripción PERT plan de negocio formato objetivos planificación técnicas de 23, pliego administrativo económico técnico precio producto profesional independiente programa código de ordenador programación propuestas de cambio prototipo proveedores proyecto aceptación administración alcance auditoría cambios ciclo de vida cierre clásico clasificación de investigación desarrollo de software diagnóstico director de : estudio de viabilidad estudios y análisis evaluación evaluación económica externo fases indicadores industrial interfaces interno memoria objetivos plan financiero planos pliego de condiciones precio presupuesto
75 78 77 100 43 44 43 96, 249, 266, 321 97 5!, 56, 255 52,56 52 51,56 14, 94, 143 41 18 5 301 289 97 202 \ 4 ■88
1 220 25 296 279 201 11 16,219 4 3 4 289 189, 284 25 4 4 248, 264 321 5 11 230 4 209 5 4 1 109 4 4 74 4
R
3 2 159 2
recursos acopio 161 consumidos 185,284 financieros 161 humanos 161 materiales 161 remanentes 185 registro de estado de cambios 207 relación de sustitución 83 requisitos 220,321 ambientales 294 de aceptación 293 de calidad y fíabilidad 294 de documentación 293 de interfaz 293 de mantenibilidad 294 depbrtabilidad 294 de prestaciones 293 de recursos 293 de seguridad 294 de verificación 293 deseables 292 funcionales 293 necesarios 292 operativos 293 requisitos de usuario definición 291,292 documento de 292 especificación 292,296 revisión 292 requisitos del software definición 291,293 documento de 293 revisión 293 reunión 167 actas Véase minutas agenda 168 asistencia 170 código de conducta 173 con el Cliente 168 convocatoria 168 de comienzo 167 de revisión de requisitos de usuario 292 de revisión de requisitos del software 293 de revisión del diseño arquitectónico 300 de revisión del diseño detallado 301 desarrollo 17! interna 167
ÍNDICE ALFABÉTICO 331
minutas resumen riesgo
saber hacer servicio solicitud de información solicitud de oferta subcontrataciones suceso final inicial sumario ejecutivo
174 177 10
220, 228 41 62 63 85 100 100 100 44
tareas 78 tasa de rendimiento interno 111 TIR Véase tasa de rendimiento interno transferencia 291,302 documento de 302
V valor actual neto valor actualizado VAN
111 65 Véase valor actual neto
