gestión integrada de proyectos-9

1 Definicin y consideraciones generales

Hemos previsto una doble definicin para la GCD:La GCD es la funcin instrumento FI que uti-liza la GPU para mantener a todos los actorescon la informacin precisa para desarrollar sutrabajo, sirviendo de nexo de unin entre todosellosTambin se identifica como la FI que formaliza,ordena y deja constancia de las actuaciones quese llevan a cabo a travs del resto de las funcio-nes, ya sean ncleo o instrumentoDicho lo anterior, conviene apuntar ya en esta

primera consideracin, que una de las tendencias deun gestor es la de convertir esta funcin instrumentoen una funcin ncleo, con lo que de facto, se con-vierte en un objetivo ms. Y no resulta difcil imagi-nrselo; ya que es tentador creerse tan importantecomo determinante por disponer de los medios decomunicacin y documentacin. De tal manera queello se convierte prcticamente en un fin.

Con el anterior planteamiento es posible enten-der que exista quien base una buena parte de su ges-tin en el uso del arma la informacin que le pro-porciona la disposicin de datos que comprometen yresponsabilizan al resto de los actores. Esta situacinsuele producirse desde una posicin y sentimientode debilidad, fruto de la incapacidad, o la falta de ex-periencia o de autoridad moral. Y en ese aspecto,hay tambin que afirmar que basar la GPU en elmontaje de un sistema documental que trate de tenercontrolada la responsabilidad de todos los actoreses un error importante que probablemente haraguas en un plazo ms o menos breve. Muy al con-trario, el sistema de comunicacin y documentacin

que debe preparar un gestor debe ser fundamental-mente un instrumento de ayuda para todos los acto-res, adems de ser ligero, abierto, accesible, fcil demanejar y admitido por todos. sta ser una de lasbases de nuestra propuesta para una buena GCD.

Tambin hacemos referencia a la comunicacinentendindola como la informacin biunvoca, quepermite transmitir lo que se desea a quien correspon-da, recibiendo a la vez la constancia, desde la otraparte, de que ha llegado y se ha asumido, en los tr-minos y con el espritu que se transmita. No bastacon enviar una informacin y creer que con eso se hasalvado la responsabilidad: el objetivo no es enviar lainformacin sino resolver el conflicto.

En este captulo atenderemos fundamentalmentea la comunicacin y documentacin que se generafundamentalmente entre el equipo gestor con fre-cuencia se le llama simplemente el gestor para abre-viar y el resto de los actores.

Albert Mart era el director tcnico de INMOBI-LIARIA TURO, compaa que desde haca unosaos haba iniciado un despegue impresionante abase de combinar la promocin de edificios de ofici-nas con la de centros residenciales de pequeosapartamentos para personas que quieren vivir contodos los servicios in situ: restaurante, mdico, salasde reuniones, jardines, gimnasio, etc. Son centrosutilizados, sobre todo, por personas que han llegadoa la edad de la jubilacin y que no quieran vivir nien las residencia-hoteles tradicionales de la 3 edadni tampoco lo quieren hacer totalmente aislados.

Estbamos reunidos a primeros de junio de 1999a raz de una propuesta que les estbamos haciendo

Empresas y organizaciones en la sociedad de hoy 327

15. Gestin de la comunicacin y la documentacin (GCD)

sobre la GPU de un proyecto de oficinas de caracte-rsticas singulares: era un edificio de 32 plantas quedeban construir para albergar la sede corporativade una multinacional afincada en Barcelona.

Albert reflexionaba ante Rafael y yo mismo Ra-fael era nuestro director comercial sobre la actitudque deberan tener las personas que debamos inte-grar dentro del equipo que podra gerenciar la ope-racin, y nos pona el ejemplo de un ayudante suyoa quien el ao anterior solicit que le preparara uninforme sobre la evolucin del sector de oficinas enla ciudad condal.

El informe, yo lo tena que entregar a mi jefeen el plazo de un mes nos dijo Albert. Y para ha-cerlo, le dije a mi ayudante que yo le dara unos da-tos que le hacan falta. Al cabo de tres semanas lellam a su despacho para reclamarle el informe, y lme contest que no lo haba hecho porque yo no lehaba dado los datos para hacerlo. Y era verdad, am se me haba olvidado. A vosotros os parece quel no me tena que haber reclamado esos datos? Pe-ro si yo soy su propio cliente, adems de su jefe! Co-mo yo no le haba dado la informacin, l no se ha-ba molestado en hacer nada ms y no habapreparado el informe. Increble, no?

Me revientan continu, aquellos que ven sal-vada su responsabilidad si no son informados o queinforman y no se preocupan de nada ms. La infor-macin debe ser algo ms.

Y tena razn Albert. La informacin debe mutarseen comunicacin y ella en espritu de encontrar la so-lucin a lo que se plantea. Nunca ha de ser objetivo ens misma. S en cambio ha de favorecer el dilogo y elintercambio de opiniones que, cuanto menos, ayuda aencontrar caminos o procedimientos de actuacin mseficaces y adaptados al proyecto de que se trate.

2 Sistema de la GCD

La GCD es un subsistema ms de los existentes en elconjunto de la gestin del proyecto, que se basa, co-mo el resto de ellos, en la misin que hay quedesempear, y ms concretamente en la filosofa deactuacin que hay que imprimir y los objetivos per-seguidos en la estrategia.

Aparece la GCD desde el mismo comienzo delas actuaciones, pues desde el primer da ya se debenlevantar actas de las reuniones; o, si se afina ms, an-tes que nada, hay una peticin de oferta para la ges-tin y una oferta adjudicada. Es decir, el sistema do-cumental existe desde el primer momento.

Esta premura en la aparicin de los primeros re-tazos de la gestin de la comunicacin y documenta-cin hace que de por s sea bastante cambiante y mo-dificable, pues la prctica lleva a la conclusin deque algunas frmulas utilizadas en un principio, seabandonan por ineficientes y, en cambio, aparecenotras ms adaptadas a la situacin: tipo de cliente, deproyectistas o a los objetivos. No debemos, por tan-to, empearnos en mantener a ultranza unos docu-mentos y formas de hacer estndares; ni utilizarotros/as que hayan tenido un buen resultado en ante-riores ocasiones. Cada caso es diferente, y aunquehay que empezar por los conocidos y utilizados; laagilidad, practicidad y eficiencia nos llevarn con to-da probabilidad a definir lo necesario, y no ms queello, para hacer una buena gestin.

Los elementos del Sistema GCD, son los si-guientes:

La estructura de desagregacin del proyecto yel sistema de calidad. Ambos representan el ncleode todo el entramado y sirven de gua para tratar to-dos los asuntos.

Los actores e interlocutores intervinientes, quesern los usuarios del sistema.

El tipo de comunicaciones que se utilizarn,que define la red que nexar a todos los actores.

Y los documentos y el tratamiento que sobre

Gestin integrada de proyectos328

Estrategia+

FilosofaProyecto

EXPEDICINY

ARCH

IVOS

DO

CU

ME

NTA

CI

N

TIP

O

DE

COMUNICA

CIN

INTERLOCUTORES

EDP

Fig. 15.1. Sistema de GCD

Gestin de la comunicacin y la documentacin (GCD) 329

Centro Penitenciario de Can BriansBarcelona. 1992

ellos se haga, que proporcionar la constancia escri-ta correspondiente.

Y gravitando sobre estos elementos estar la filo-sofa del proyecto y los objetivos a conseguir. Y si alprincipio advertamos de la tentacin y peligro deobjetivar en s misma a la GCD, tambin habr queadvertir del peligro ste, casi ms inminente decrear un sistema alejado de los deseos del cliente odel inters del resto de los actores y del propio pro-yecto, montando una parafernalia a la que nadiehace caso y a la que nadie recurre cuando se quierensolucionar los problemas (montar un sistema que es-t pensado para ser utilizado delante de un juez si lascosas no van bien, es un excelente recurso de protec-cin, pero puede perfectamente no resolver el con-flicto que hay que resolver).

La eficiencia y el concepto del valor siemprehan de ser los compaeros de viaje del gestor. Y esoconduce como se ha dicho a reconsiderar variasveces, a lo largo del CVPU, el sistema que se estutilizando para tratar de evitar que la rutina lleve aun consumo innecesario de tiempo y medios, tantopropios como ajenos.

3 La estructura de desagregacin delproyecto EDP y el sistema de calidad

Ya se ha hablado en anteriores ocasiones de la EDP,que consiste en un ejercicio de asuncin del proyec-to por medio de un anlisis pormenorizado de lo quehay que hacer, descomponiendo el proceso en activi-dades y partidas que permitan conocer todos los pa-sos que hay que acometer para concluir la UA.

La EDP puede basarse en los procesos de planifi-cacin y programacin, listando las actividades ypartidas en el orden y la prelacin en que se han deefectuar. Tambin se puede preparar, dividiendo lasactividades en grupos asociados a las empresas opersonas que las tienen que ejecutar. Otra forma, enfin, que se podra utilizar, es la del agrupamiento porigualdad de tecnologas a aplicar en su proyectacino construccin.

En cualquier caso, este es el punto de arranquepara iniciar el proceso de una GCD; si se dispone deun sistema de calidad que hay que cumplir, ste obli-ga, adems, a un conjunto de prcticas y a la utiliza-cin de documentos especficos.

En una GCD, la EDP da al gestor la gua sobre loque debe comunicar y archivar. Y el sistema de cali-dad estandariza las prcticas que tratan de minimizarlos errores y aumenta la precisin en la prestacindel servicio. El sistema de calidad debe llevar inclui-do la EDP.

4 Interlocutores

Conviene desde un principio conocer los nombres delas personas que sern interlocutores generales y es-pecficos de temas de especialidad, en cada uno delos actores:

Cliente (director de proyecto, control financie-ro, explotacin, etc.)

Proyectista/s (director de proyecto, diseo con-ceptual, responsable civil, instalaciones, ergo-noma, etc.)

Constructor/suministrador (jefe de construc-cin, compras, gerente, etc.)

Gestin integrada (gestor, responsable planifi-cacin, responsable costos, etc.)

Otros actores (administraciones pblicas, com-paas de servicios, etc.)

El conocimiento de los interlocutores vendrasociado al conocimiento de la capacidad de deci-sin que cada uno puede tener, as como quin deberecibir la documentacin, la genere quien la genere.

Conocer los interlocutores, aunque se pretendeque sea desde la primera reunin de inicio de la ges-tin, no siempre es posible y lo normal es que se va-yan consolidado los nombres de las personas que re-almente van a actuar, y que tienen peso en el proceso.

Respecto a los interlocutores externos, como esel caso de las administraciones pblicas en proyec-tos importantes, incluso se llegan a nombrar a perso-nas ex profeso para la negociacin y resolucin deproblemas, as que la comunicacin adquiere el ca-rcter de una ms dentro del circuito que se esta-blezca.

5 Universo de la comunicaciny documentacin

La comunicacin es un sistema divergente, entendi-do como la capacidad para expandirse centrfuga-


mente, en funcin de la autonoma per se de sus ele-mentos y de los intereses que ellos defienden. No esposible conseguir una unidad completa de actuacinque permita obtener un sistema unidireccional, porlo que el gestor, a lo mximo que puede tratar de lle-gar, es a coordinar aquellas informaciones que, vi-niendo de cualquiera de los integrantes (elementos osubsistemas), sean relevantes para el proyecto y seanecesaria su puesta en comn.

El universo de la comunicacin en un CVPU di-recciona en mltiples sentidos y todos los actoresutilizan los medios que creen ms oportunos as co-mo los receptores de sus emisiones. Y el papel delgestor es el de tratar de regular todas aquellas emi-siones que sea jurdicamente posible regular, as co-mo el de transformarlas en comunicacin, paraobtener la mxima eficiencia de ellas.

En la fig. 15.2 que se adjunta a continuacin pue-de apreciarse la complejidad que representa el quecada uno de los actores pueda actuar haciendo usode su facultad de informar y no tanto de comuni-car, as como la dificultad del gestor de hacer posi-

ble el que todos los actores dispongan de la informa-cin precisa para hacer bien su trabajo.

5.1 La sistemtica a aplicar

Independiente de las posibilidades mltiples de in-formacin abiertas, el gestor debe proceder a esta-blecer una sistemtica que en lneas generales con-temple:

Mientras el gestor vaya desarrollando las fun-ciones establecidas en su contrato con el cliente, iremitiendo informes a su atencin, en los que:

Explique la situacin Prevenga de sucesos negativos cuando es

necesario Haga anlisis previsionales de los objetivos Deje constancia de hechos de inters Sugiera caminos a seguir

El procedimiento de trabajo adoptado proba-blemente sugerir la celebracin de reuniones, de lascuales levantar acta que remitir a cada uno de los


Informes, actas, faxc. electrnico

PROYECTISTA

Documentos deproyecto

Ofertas, informes, cartas,fax. c. electrnico

Documentos proyectode detalle

Cartas, fax,c. electrnico

Informes, cartas,actas, fax, c. electrnico

cartas, fax,c. electrnico

CLIENTE

OTROS ACTORESAduanas, compaasservicios, Ad. Pblica

CONSTRUCTORSUMINISTRADOR

GESTOR

Reenvo

Fig 15.2. Universo de la comunicacin y la documentacin

asistentes. Si de ella derivara alguna informacin pa-ra otro actor que no hubiera asistido, preparar uninforme, carta, etc. con la informacin, que har lle-gar al interesado.

A partir de la informacin recibida de algunode los actores, que sea til para los otros, redactarun documento que distribuir a quien corresponda.Y, fundamentalmente respecto al proyectista, se pre-ocupar de que ste disponga de la informacin ne-cesaria para proyectar, que pueda provenir del clien-te, de los contratistas y suministradores, de lasadministraciones pblicas, de las compaas de ser-vicios y de cualquier otro.

Se preocupar de que el cliente conozca con eldetalle suficiente:

Las propuestas y soluciones definidas por elproyectista

Todas las implicaciones que la solucin ge-nera

Se preocupar de asegurarse que los contratis-tas/suministradores son conscientes del trabajo quetienen que realizar y de las rdenes que reciben.

Los documentos de proyecto editados por elproyectista deben ser enviados al gestor, a su vez,una vez haya pasado el trmite establecido de revi-sin, sern reenviados al cliente y a los suministra-dores y constructores de la UA.

Una copia de toda la documentacin generadao recibida por el gestor debe quedar en poder delcliente.

Como el resto de elementos del sistema, la co-municacin depende mucho de la filosofa que debeimperar en el proyecto y de la estrategia establecida.La estrategia, por ejemplo puede condicionar el tipo


Emisor documento Receptor objeto

Proyectista Cartas, faxes, c.electrnico Constructor Solic. informacin Cliente Relac.contractuales

relativ. al proyecto Otros actores Solic. Informacin

Documentos del proyecto Gestor Anlisis y reenvo aconstruct. y cliente

Const./sumin. Cartas, faxes, c.electrnico Adm. pblicas Solic. informacin Compaas serv. Solic. Informacin Proyectistas Dando inf. tcnica Gestor Dando inf. tcnica

Doc. proyecto c. construido Gestor Rev./env. cliente

Gestor Cartas, faxes, c.electrnico Cliente Estado proyecto Otros actores Sol. informacin

Proyectista Relac. proyectoEquipo gestor Coordinacin

Cliente Est. proyecto/inf.

InformesProyectista Relac. proyecto

Actas Cliente InformacinProyectista InformacinContrat/suminist. InformacinEquipo gestor InformacinOtros actores Informacin

Adm. y cas serv. Cartas, faxes, c.electrnico Cliente InformacinRequerimientos

de comunicacin que debe implantarse con los acto-res externos al proceso (administraciones pblicas,prensa, etc.).

En cualquier caso, el sustrato de la comunicacinsiempre es la comunicacin verbal, que permite man-tener uno de los lineamientos genricos de la GPUcomo es el de la motivacin (los otros dos, como serecordar, eran la satisfaccin del cliente y el im-pulso de mejora constante ver capitulo 1). Y evi-dentemente la comunicacin escrita es la que forma-liza la gestin, dejando constancia de lo que convieney sirviendo de recordatorio de las actuaciones com-prometidas por cada uno de los actores.

Tambin se puede enfocar la comunicacin enfuncin de la direccin que lleva. En ese sentido sepuede hablar de comunicacin externa, que va di-rigida a los actores ms externos al proceso (admi-nistraciones pblicas, prensa, etc.) e interna, diri-gida a los actores directamente involucrados en elCVPU.

En todos los casos, el principio bsico es el de laidea de la biunivocidad aludida en pginas anterio-res, que se refiere a la prctica que lleva a que cadavez que se informa se asegure que el interlocutor harecibido la informacin y que es consciente de ello.Eso se puede hacer por la va de solicitar una confor-midad personal o travs de persona autorizada opor la constatacin mediante la comunicacin verbala la que aludamos, que acta como sustrato de todoel sistema.

En cuanto la comunicacin entre los miembrosdel equipo gestor, se hace a travs fundamentalmentede reuniones de coordinacin que suelen ser formal-mente un da antes de las reuniones de seguimientocon el cliente y/o proyectista. Son reuniones en lasque se intenta unificar criterios de actuacin para conel resto de los actores y revisar el estado de los objeti-vos, as como los medios que habra de utilizar elpropio equipo o el resto de los actores para corregiraquellos aspectos que deban ser corregidos. En todo


COMUNICACIN

Estrategia yfilosofa proyecto

Interna

Proyectista

Cliente

Externa

Administracin pblica

Verbal

Escrita

Reuniones

Reuniones especialidad

Contratos informales

InformesActasCartas, fax, c. electrnicoLibro rdenesLibro incidenciasNotas obraDocumentos de proyecto

Fig. 15.3 Tipo de comunicacin

caso las conclusiones de esas reuniones, as como lastareas a realizar deben estar reflejadas por escrito, atravs de instrucciones y actas que puedan quedargrabadas dentro del correo electrnico interno.

5.2 Tipos de comunicacin

En los ltimos apartados, hemos tratado de explicarla complejidad y dificultad de realizar una buena co-municacin y tambin se han mencionado diferentesinstrumentos que se utilizan y que en las prximapginas vamos a tratar de desarrollar y matizar.

Hablaremos de la comunicacin informacinbiunvoca desde el punto de vista del gestor paracon el resto de los actores, aunque introduciremosalgunos instrumentos, como son los propios docu-mentos de proyecto, las instrucciones tcnicas deconstruccin y los libros de ordenes e incidencias,que, aunque no son competencia del gestor, stedebe impulsar su utilizacin o revisar sus conte-nidos.

La comunicacin, en trminos generales, se pue-de analizar desde el punto de vista de la forma: oraly escrita, y desde el punto de vista de los actores in-tervinientes: externa e interna. (Ver fig. 15.3).

5.3 Comunicacin verbal

Se lleva a cabo de manera formal en:

Reuniones de coordinacin Reuniones de especialidadInformalmente se producen a lo largo del ciclo

innumerables contactos y reuniones que actan depreparacin para las formales, de explicacin de de-cisiones, y en general estos contactos son laminado-res en algn caso y provocadores en otros, de te-mas y situaciones que se desea que se inicien o seapacigen.

Probablemente uno de los problemas que tiene lacomunicacin verbal sobre todo la informal es eltiempo que consume y por ende la no disponibilidaddel mismo para otros asuntos que deben resolverse.Sin embargo est muy demostrada la utilidad de staperdida de tiempo porque de ella se pueden sacarconsecuencias y datos que es muy difcil que se con-

sigan por la va de la comunicacin escrita o simple-mente de la verbal formal.

A travs de un estructurada aunque no for-mal comunicacin verbal, un gestor puede llegar asaber realmente:

Cul es la verdadera causa de por qu un con-tratista se est retrasando

Si el cliente est realmente contento con la ac-tuacin de la GPU

Qu objetivos de verdad son los que interesan Si hay motivos polticos para algunas decisiones Etc.Es evidente que la comunicacin escrita es de su-

ma importancia y no solo debe mantenerse sino quehay que pensarla muy bien y, planificadamente, de-sarrollarla sin tregua; pero queremos poner un espe-cial nfasis en todo lo que significa el contacto per-sonal del equipo de gestin y preferentemente delpropio gestor con el resto de actores, fundamental-mente con el cliente y los proyectistas. Contacto quegenera esa informacin biunvoca de la que habl-bamos y que sin duda va a ser la que marcar las v-as de entendimiento y confianza. Posteriormente, esabsolutamente cierto que son los hechos los que da-rn crdito a todo lo hablado; pero un buen entendi-miento personal allana las dificultades, reinterpretalos errores y agranda los aciertos, y en definitiva si-ta los resultados en su justo trmino en funcin,tambin, de los esfuerzos realizados.

Es evidente que el entendimiento personal tie-ne que ver mucho con la llamada qumica de unarelacin, que hace que dos personas se entiendanmejor prescindiendo de otras consideraciones msvisibles: conocimientos, trabajo y racionalidad engeneral. Y esta consideracin parece que podra in-habilitar a algunos gestores para que tuvieran unabuena comunicacin verbal con algunos actores.Puede ser cierto. Pero tambin lo es el hecho que unbuen gestor no lo puede ser cualquiera; as que ya depor s deben seleccionarse los tcnicos antes de asu-mir ese tipo de responsabilidad sobre todo el ges-tor, responsable del equipo de la GPU.

En todo caso, existe la posibilidad de un aprendi-zaje para saber cmo comunicar, y sobre todo esel inters en ello el que hace que se pueda ampliar elabanico de candidatos para cubrir ese puesto con efi-cacia, aunque a algunos les cueste ms esfuerzo quea otros. El inters es un valor en alza, susceptible


de generar confianza, y por ende un buen argumentopara lograr una buena comunicacin.

Las reuniones de coordinacin son las que demanera continuada y estructurada se realizan a lolargo del ciclo, de seguimiento de los trabajos que sevienen desarrollando. Los temas que se suelen tratarson, entre otros, los siguientes:

Lectura y aprobacin, si cabe, del acta de lareunin anterior. Lectura del orden del da y solici-tud de tratamiento de otros puntos.

Comunicacin del gestor o cliente a todos losactores de temas que pueden interesar.

Puntos crticos a debatir. Repaso del estado de las tareas que, de acuer-

do con la planificacin, se estn desarrollando. Ex-posicin de detalles, si cabe, por parte del especia-lista. Problemas que hayan surgido y que debanpresentarse a la mesa para su conocimiento o reso-lucin.

Estado de la planificacin. Comentarios sobremedidas a adoptar en caso de desviaciones.

Estado del plan de costes. Comentarios sobremedidas a adoptar en caso de desviaciones.

Estado del cumplimiento de otros objetivos: di-seo, calidad, medio ambiente, licencias, etc.

Listado de temas pendientes por resolver yplan de actuacin con responsables para cada uno delos asuntos.

Uno de los objetivos de las reuniones de coordi-nacin es el de servir de impulso a acciones que pos-teriormente, de manera formal o informal, se desa-rrollarn a lo largo del periodo que media hasta laprxima reunin. La cadencia de las reuniones de-pende del tipo de proyecto. Para proyectos de inves-tigacin pueden establecerse mensualmente o quizsms a menudo. Para proyectos de consultora, de-pende tambin del tiempo total, pero pueden hacersecada dos o tres semanas. Para proyectos de edifica-cin o ingeniera, es normal que se realicen cada unao dos semanas.

Creo que de esta reunin deben de surgir otrasnuevas entre vosotros, que resuelvan asuntos que nohace falta que vengan a esta mesa eso deca Alfre-do Matas, presidente del Parque de las Tecnologas,gerente del proyecto y responsable mximo del mis-mo.

Y creo que tienes razn confirm lvaro Viei-ra, coordinador del proyecto. Sobre todo porque s-lo tenemos dos meses para hacerlo a partir de queobtengamos todos los datos, y no podemos perder niun minuto.

El Parque de las Tecnologas era una experien-cia nica que el gobierno de una comunidad aut-noma espaola haba emprendido en 1996 aunqueya haca varios aos que se estaba gestando laidea. El propsito era crear un rea habitable enque convivieran la ecologa, el respeto al medioambiente, las tecnologas de telecomunicacionesms avanzadas y la convergencia de dos usos: el dela residencia de personas que suelan utilizar el pro-pio domicilio para su trabajo, con el uso terciariopara empresas del sector de tecnologas audiovi-suales, telecomunicaciones, servicios, investiga-cin, etc.

Para el proyecto se seleccion, despus de unconcurso internacional, al arquitecto ingls DickMayor, que elabor el master plan. Posteriormente,se adjudic tras otro concurso pblico el proyectoejecutivo a SISTEMAS DE INGENIERA Y ARQUI-TECTURA SIA, ingeniera espaola con ramifica-ciones en todo el mundo y de una gran experienciaen las tecnologas del proyecto.

El proyecto contemplaba una central de energasque cogeneraba a partir de gasoil el gas an no ha-ba llegado, pero se estaba preparado para ello ycompletaba la produccin elctrica con colectoressolares. Todo el parque estaba preparado para pro-ducir su propio consumo. La definicin de vialesrespetaba en lo posible la orografa; se mantena to-do el entorno paisajistico, incluso se proyectaron es-tanques para mantener la fauna autctona que utili-za el agua como hbitat. Haba red de aguareclinada para riego, red neumtica de basuras, yrecogida de forma selectiva. La circulacin de auto-mviles estaba restringida.

El proyecto tena el apoyo del programa Thermiede la Unin Europea y por supuesto del gobiernoautnomo. La inversin prevista era del orden de 70Meuros.

Las reuniones de coordinacin en fase de pro-yecto se realizaban cada semana en la sede oficialde la sociedad Parque de las Tecnologas. Estabandirigidas por Alfredo Matas que gestionaba el pro-yecto y, para apoyarse, en la gestin dispona de un


equipo propio de consultores que de forma selectivale ayudaban en la toma de decisiones en reas deenergas renovables, telecomunicaciones, arquitec-tura y civil.

El orden del da lo propona la ingeniera encar-gada del proyecto y Matas lo recompona de acuer-do con su criterio. Con frecuencia sola ser el mismoque indicaba la ingeniera.

Los asistentes permanentes a las reunioneseran:

Alfredo Matas (presidente y gestor del proyec-to en fase de proyecto)

lvaro Vieira (coordinador general por partede SIA)

Emilio Pey (ingeniero de telecomunicaciones ydirector del proyecto por parte de SIA)

Alberto Roma (arquitecto asesor de Alfredo) Marcos Heines (ingeniero energtico de SIA) Marina Alamis (arquitecta de SIA) Renato Dol (ingeniero asesor general de Al-

fredo)Puntualmente y a peticin de SIA o Alfredo se in-

corporaban a las reuniones: Mateu Server (ingeniero civil asesor de Alfredo

y que diriga obras anexas al parque, tambin porencargo de Parque de las Tecnologas)

Juan Settle (experto en energas renovables,asesor de Alfredo)

Sebastin Real (ingeniero telecomunicaciones,asesor de Alfredo)

Marta Bosch (gerente de Parque de las Tecno-logas)

Jorge Solo y Diego Ventura (ingenieros exper-tos en urbanizacin e hidrulica de SIA)

Responsables de la compaa de aguas o deelectricidad de la Comunidad

Mike Copperfield y Louis Guinnes, arquitectosdel equipo de Dick Mayor

Tal como prevea Alfredo, adems de esta reu-nin durante la semana siguiente a cada reunin seproducan contactos casi diarios entre todos los im-plicados: haba reuniones, conversaciones telefni-cas y cruces de faxes entre Emilio Pey y SebastinReal en el tema de las comunicaciones. Lo mismoocurra con Marina Alamis y Alberto Roma en ar-quitectura (las propuestas urbansticas y paisajsti-cas eran llevadas a las reuniones de coordinacinen las que los arquitectos de Dick Mayor daban su

opinin y constataban si modificaban o no, el espri-tu del master plan).

Por su parte al ingeniero energtico Marcos Hei-nes le tocaba ser el intrprete didctico de la pro-puesta energtica del parque que, por ser novedosa,explicaba repetidas veces sobre una pizarra cadavez que alguien nuevo se incorporaba a las reunio-nes. Al margen de las reuniones, mantena conversa-ciones fluidas con Juan Settle y con los responsablesde las compaas elctricas.

Para los asuntos de ingeniera civil: vialidad,drenajes, encauzamiento del torrente, etc., Jorge So-lo y Diego Ventura dialogaban con frecuencia conMateu Server.

De la marcha general de los trabajos y de laprioridad de los mismos, implicaciones econmicas,etc., Alfredo hablaba casi a diario con lvaro.

Muchos de estos contactos, se traducan en faxescruzados, pero la mayora se quedaban en acuerdosverbales que se iban integrando por escrito en losdocumentos proyectuales.

Dos semanas antes del plazo de los dos meses,SIA an no haba recibido el estudio geotcnicoque se haba solicitado por escrito y que era nece-sario para calcular la estructura y las cimentacio-nes de los edificios de energa, residuos slidos ur-banos y centro de telecomunicaciones; as quesolicit un aplazamiento de la fecha de entrega final.lvaro se comprometi a terminar todo el proyectoen tres semanas una vez hubiera recibido esa infor-macin.

Alfredo se sorprendi ante el hecho que SIA notuviera esa informacin y que l no lo hubiera sabidohasta entonces. Pero Emilio Pey director del pro-yecto le record que haca dos meses que se habasolicitado por escrito: Mateu Server, encargado porParque de las Tecnologas de contratar los serviciosgeotcnicos, recibi la bronca correspondiente.

A los pocos das, SIA recibi un adelanto del es-tudio y, a las tres semanas ms tres das de gra-cia, se entreg el proyecto.

Tres das ms tarde de la entrega, Alfredo le re-crimin a lvaro que, en su momento, le deba ha-ber recordado a l personalmente y no slo dejarlopor escrito que SIA an no dispona del estudio ge-otcnico, situacin que ahora haba permitido a SIAsolicitar un aplazamiento de la entrega final, con loque se haba producido el retraso. De todas formas


se manifestaba contento del trabajo y de la relacinentre Parque de las Tecnologas y SIA: la comunica-cin haba sido buena, y el proyecto en su conjuntoera, tambin, un buen proyecto.

A pesar de lo anterior, la percepcin de Alfredopoda no haber sido esa, porque la ausencia de esareflexin verbal, con la que ahora le haba recrimi-nado a Alvaro, poda haberse interpretado comouna tctica para alargar el plazo de entrega del pro-yecto, y tambin era interpretable como una argu-cia, impropia de una buena relacin.

Las reuniones de especialidad no suelen revestirla periodicidad tan inflexible como las de coordina-cin, sin embargo no por ello son menos importan-tes. De hecho, en muchos proyectos, son las que au-tnticamente resuelven los problemas, as que hayque fomentarlas.

En los proyectos de mucha envergadura, posible-mente el cliente disponga de interlocutores capacesde asumir o discutir, en su caso, los temas que sobrediferentes tecnologas le proponga el proyectista pe-ro, en todas las situaciones, ha de ser el gestor quienaporte sus propios tcnicos que deben aconsejar alcliente sobre la lnea que est llevando el proyecto; ypor lo tanto ellos deben asistir tambin a las reunio-nes e incentivar su realizacin.

Tanto estas reuniones como las de coordinacines conveniente que acaben en un documento escritoque resuma el contenido de lo hablado.

Las comunicaciones exclusivamente verbalespueden desarrollarse tanto a nivel interno (entre ac-tores prximos al proyecto), como a nivel externo,con otros que, aunque tengan singular importancia,no estn directamente involucrados con dedicacinexpresa en el proyecto. Es el caso de las adminis-traciones pblicas. Efectivamente, las relaciones en-tre ellas son de trascendental importancia pues, entreotras cosas, de ellas depende la concesin de permi-sos que permitan la explotacin de la UA.

De las reuniones con la administracin pblica,rara vez se concluye con algn documento escritopor parte de ella, excepto cuando se le solicita tam-bin por escrito algn tipo de respuesta que estprevisto que pueda darse. Ni siquiera es frecuenteconseguir respuestas parciales que permitan al pro-yectista seguir uno u otro camino. Los cauces buro-

crticos estn muy reglamentados y los funcionariosno arriesgan una opinin o emiten un dictamen si notienen todos los datos que se prev deban tener. Entodo caso es imprescindible mantener esos contactosverbales, aunque se corra el riesgo de que no secumplan algunos de los trminos oficiosamente pre-acordados.

Otras comunicaciones verbales externas son conlos posibles corporificadores, dentro del proceso depuesta en accin de la ingeniera simultnea, paradetectar la constructibilidad del diseo de los pro-yectistas o bien en la fase de aprovisionamiento entodas las conversaciones previas. Tambin hay co-municaciones cuando se trata de recabar datos oaclaraciones durante la comparacin

5.4 Comunicacin escrita

Sin duda es la que hay que tener ms estructurada yclara pues en ella ha de quedar reflejado todo el ciclocon sus pasos, propuestas, decisiones. Son el diarioy el recordatorio para todos los actores y, por su pro-pia condicin, resultan insustituibles en el segui-miento tcnico, econmico o legal del proceso.

La visin sistmica en la resolucin de los pro-blemas, y en general al afrontar un conflicto, tam-bin se lleva a cabo en el sistema de comunicacin;es por ello que se utilizan diferentes vas que, de pors, tambin reflejan distintos sistemas con sus reglasde actuacin y formas concretas. As es como apare-cen los sistemas de informes, actas, cartas, faxes, co-rreo electrnico, libros de rdenes, libros de inciden-cias y notas de rdenes en los momentos de lacorporificacin. (Ver fig. 15.5).

Como es lgico, no slo el gestor genera infor-macin escrita; tambin lo hacen el resto de actores,tal como se indica en 5.

5.4.1 Informes

Son el instrumento ms comn y estandarizado delque se sirve un gestor para mantener una comunica-cin escrita con todos los actores y especialmentecon el cliente, usuario principal de la UA. De hecholos informes se suelen remitir exclusivamente alcliente, pero segn el escrito de que se trate y la filo-sofa definida al principio para la relacin entre las


partes, se editan copias para otros actores que intere-sa que conozcan el contenido.

Las cartulas de los informes es conveniente quedispongan de una informacin mnima que permitauna rpida identificacin y su posterior archivo. As,suelen llevar: ttulo, nmero, clasificacin decimalsegn la EDP o un centro de costes que se cree, n-mero de copias y a quin va dirigida cada una deellas.

Sobre los informes hechos por otros actores, sepropondr la inclusin del mismo tipo de identifica-cin para favorecer un archivo conjunto tanto porparte del cliente como por inters propio. Aunquepara el archivo propio, y en cualquier caso, si no vie-ne con la identificacin prevista por imposibilidadde obligar a su cumplimiento (administraciones p-blicas por ejemplo) se deber incluir a mano cuandollegue a disposicin de la GPU.

En 5. Se anticiparon en lneas generales culeseran los objetos ordinarios que acometen los infor-mes. Los tipos ms interesantes para conocer son:

Informes generales y peridicos de seguimientodel proyecto, que son informes que segn el tipo deproyecto y su duracin, tienen usualmente un carc-ter quincenal, mensual o bimensual. En ellos se haceuna descripcin de la situacin y se hace una extra-polacin previsional de esa situacin al final del CV-PU.

El informe suele apoyarse en documentacingrfica (fotografas, croquis, esquemas, etc.) queayudan a una comprensin rpida de la situacin.

El receptor del informe suele ser el interlocutorordinario por parte del cliente y los informes suelenser ms frecuentes durante la construccin de la UA,ya que en las fases de concepcin, desarrollo ymientras se hace el proyecto, en la fase de imple-

mentacin, suele ser ms frecuente informar y co-municar a travs de las actas de reuniones o los in-formes especficos.

En octubre de 1996 la ingeniera que desarrolla-ba la gestin integral del proyecto del Palacio deCongresos de Valencia realiz su informe mensualcuyo contenido responda al ndice siguiente: 1 Comentarios generales

1.1 Organizacin1.1.1 Responsabilidades de SNF & P en la direc-

cin de la obra1.1.2 Organismos oficiales. Compaas de servi-

cios2 Actividades realizadas

2.1.1 Actividades en el mes de octubre2.11.1 Grfico de la situacin porcentual de ca-

da captulo de obra3 Actividades previstas para el mes de noviembre4 Desviaciones del proyecto original

4.1 Propuestas de cambio de estructura secunda-ria

4.2 Muros de contencin y cimentacin4.3 Piedra natural (pavimentos y revestimientos)4.4 Cerramientos exteriores

5 Documento de avance. Estado de certificacin5.1 Avance de la obra. Octubre-96

5.1.1 Avance de obra por captulos5.1.2 Grfica comparativa de avance de obra5.1.3 Grfica comparativa ampliada de avance

de obra5.2 Reportaje fotogrfico5.3 Muestras5.4 Estado de certificaciones5.5 Adelanto/retraso en la obra


IT.n: 6290/015

C.D.: 4.2

Fecha: 5/03/99

Anexo:

Encargo:

Ttulo:

SIAArch.

SIA PT PT PT

VISITA AL TORRENTE PUIGDERRS

Parque de las Tecnologas

Cop

ias

Fig. 15.4. Cartula tipo de un informe

6 Puntos crticos6.1 Procesos de fabricacin de las vigas y placas

de cubierta6.2 Asuntos pendientes6.3 Brise-soleil

6.3.1 Solucin de proyecto6.4 Perforaciones en los forjados de los auditorios6.5 Depsito enterrado6.6 Control de calidad6.7 Control de ejecucin6.8 Seguridad e higiene

ANEXO 1 Plan actualizado de certificacionesmensuales

ANEXO 2 Relacin de personal en obra el da25-10-96

ANEXO 3 Procedimiento de visita de obra ANEXO 4 Reportaje fotogrficoANEXO 5 Resultados del control de calidad

Dos aspectos que convendran resaltar de un in-forme peridico de seguimiento son los relativos alos puntos crticos que hay que acometer y que confrecuencia involucran al propio cliente; y otro asuntointeresante es el apartado que intenta hacer una ex-trapolacin de lo que ocurrir de seguir la mismatendencia en el trabajo que se est realizando hastaesa fecha. Como medida prctica, adems se haceuna extrapolacin para todo el proyecto, se aconsejaconcretar lo que ocurrir en los prximos 30 das(cuando no, menos) a la edicin del informe.

Otro tipo de informe son los informes ejecutivos,que conforman documentos de un nmero escaso dehojas, dirigidos a la presidencia o direccin generaldel cliente, que pretende resumir en no demasiadosprrafos y de forma bastante grfica y sinttica, elestado de la cuestin, abordando aspectos claves delproyecto.

Lo ordinario es que los aspectos clave de este ti-po de informes se refieran al presupuesto y al plazo,pero no estn descartados otros objetivos que, en to-do caso, se acuerdan con el cliente y ms concreta-mente con el receptor final.

Lo trascendente es, en definitiva, que el gestorsepa qu tipo de informes resultan de utilidad, dejan-do aquellos aspectos que complican la lectura o noaaden nada efectivo al anlisis para la toma deci-siones o para el conocimiento de lo que existe.

Estos informes se suelen hacer a lo largo de todoel CVPU.

Tambin a lo largo de todo el ciclo, se realizaninformes especficos sobre temas diversos que co-rresponden a diferentes aspectos de la EDP que inte-resa que conozca el cliente, el proyectista o algunootro de los actores. As por ejemplo se suelen hacerinformes sobre la marcha concreta de la construc-cin de algn elemento especfico en un taller, sobreel estado de un permiso de legalizacin de la activi-dad, sobre la evolucin del coste de una parte signi-ficativa del proyecto, sobre la revisin de las hipte-sis de diseo de algn elemento, etc.

Se hacen informes que hablan del coste, de la se-guridad, del medio ambiente, del plazo, etc. Entreellos, unos que revisten singular importancia son losque definen bases de inicio o hiptesis de partida deltrabajo de cada actor que responden a deseos expre-sos del cliente o a objetivos a cumplir. Estos infor-mes se llevan por el gestor a las reuniones de inicio yse solicita oficialmente al cliente la validacin y alactor que sea, su aceptacin expresa. En esa reuninse levanta el acta correspondiente para que se forma-lice la situacin.

5.4.2 Actas de reunin

Se pueden considerar como un tipo de informe ms,lo que facilita un archivo conjunto de los documen-tos.

La preparacin de la reunin se hace a travs delorden el da que el gestor debe emitir unos das antesdel previsto para la reunin, y enviarlo a todos losactores. Este documento preparatorio incluir el da,la hora de inicio, los asuntos a tratar con el tiempoasignado para cada uno de ellos, as como los asis-tentes previstos.

Las actas las redacta el gestor y deben reflejar unresumen de lo hablado con indicacin de:

Aprobacin de la lectura del acta de la reuninanterior, o en su caso la introduccin de las modifi-caciones a que hubiera lugar. De su lectura puedeninducirse reflexiones que, o bien se resuelven porquepertenecen a lo tratado el da anterior o bien se dejanpara ser tratados segn el orden del da previsto paraese momento.

Si hay temas urgentes, lo lgico es que sean losprimeros en ser tratados.


Si hay un asunto especficamente mencionadopor uno de los actores, se indicar cul es la fuente.

Para cada asunto es recomendable, indicar elobjeto de su tratamiento: para informacin o paraque algn otros actor acometa alguna accin (en esecaso, se citar al actor).

Se suele dejar constancia de los asuntos pen-dientes, si los hay, as como la fecha de su posibletratamiento si es posible.

De las actas, una vez escritas, se ha de enviar unacopia a cada uno de los integrantes de la reunin auto-rizados para ello y al cliente en cualquier situacin.

En el proyecto del Parque de las Tecnologas,mientras se estaba haciendo el diseo, en la fase deimplementacin, una de las actas de reunin que se le-vantaron fue la que se muestra en la pgina siguiente.

5.4.3 Cartas, faxes y correo electrnico

Muchas de las comunicaciones que hasta hace pocosaos eran verbales, han pasado, en los ltimos tiem-pos, a ser escritas a la luz de la facilidad que los me-dios han provocado para que as sea.

Las ventajas que lo anterior comporta son dos:por un lado, son mucho ms explcitas y tratan el te-ma que sea sin ambages y, por otro, dejan constan-cia de los asuntos. De esas ventajas se liberan otrascomo son la economa de los medios y recursos, y elaprovechamiento de los mismos en otros temas.

Cuando se quiere sumar rapidez a formalidad yprecisin, se suele enviar un fax y a continuacin seenva la misma documentacin por carta. La carta,en todo caso, sigue siendo el documento formal quese utiliza cuando se quiere distinguir el contenido deforma especial respecto a como se podra suponer enotros tipos de comunicacin. De hecho lo que termi-na de conferirle un grado de seriedad y validez, jur-dicamente hablando, es el poder ser enviada bajo elsoporte de un fedatario pblico. Aunque ya se puedeentender que no es una va demasiado amistosa decomunicarse, pero hay ocasiones en que no existemejor procedimiento.

El correo electrnico sigue teniendo un auge ex-traordinario y se le augura un crecimiento muchomayor, ya que permite un archivo y redistribucin

mucho ms rpido y accesible que las cartas y faxes.En todos los casos, en el envo de estos tipos de do-cumentos siempre se habra de indicar:

Una referencia del asunto tratado: n de pro-yecto, clasificacin segn la EDP o clasificacin porcentro de costes y el asunto en cuestin.

Las copias que de l se hacen y a quin se re-miten.

Persona/s que editan el documento.Y retomamos en este punto el significado del tr-

mino de gestin de la comunicacin, para hacernfasis en lo que mencionamos en las primeras pgi-nas de este captulo en el sentido de que, cuando seutilizan esta vas para generar la informacin preci-sa, el sistema an est incompleto, quedando pen-diente la biunivocidad del intercambio. Esto es, ase-gurarse que el receptor de la informacin la harecibido, y que se est consiguiendo el efecto espe-rado y no otro.

A este respecto conviene matizar que no siempreel escrito llega a ser lo suficientemente afortunadoen su redaccin como para acertar en lo que se quie-re transmitir y con el tono requerido; por eso es con-veniente apoyarlos siempre con una comunicacinverbal, o una confirmacin, tambin por escrito, deque se ha recibido, para testar si se est de acuerdo ono con lo redactado; para en definitiva, estar segurode que se entiende lo que el redactor quiere que seentienda.

Estos aspectos, un gestor debe cuidarlos mucho,dada su condicin de aunador de voluntades y es-fuerzos, en pro de unos objetivos que tienen que sercomunes para todos. Una deficiente interpretacinde algn escrito puede generar suspicacias que sinduda no ayudarn lo ms mnimo a generar la con-fianza necesaria en la GPU que permita hacer esa la-bor de convergencia de todos los actores.

5.4.4 Libros de rdenes e incidencias

Son instrumentos utilizados en los proyectos de edi-ficacin, tanto en el rea industrial como arquitect-nica, que se disponen en las obras para ser utilizadopor los directores facultativos de las mismas.

El libro de rdenes, como su nombre indica, reco-ge los mandatos de la direccin facultativa que son deobligado cumplimiento para el contratista. Este ins-trumento resulta extremadamente til cuando se pre-



PUNTOS TRATADOS

AGUAS MUNICIPALES comenta un cambio en el trazado del colector dela red de saneamiento para evitar atravesar la zona de Son Espaol.AGUAS proporcionar a SIA las coordenadas exactas del punto de cone-xin.

Se plantea un cambio en la ubicacin de los depsitos de las redes de aguapotable y terciaria. AGUAS proporcionar tambin estas coordenadas.Se tendr en cuenta que en la red de agua terciaria es necesario incorporarvlvulas de alivio. Este agua sobrante debe ir a parar a la red de saneamien-to, no al torrente, ya que no est libre de patgenos.

SIA indicar el tipo de sondeo, mquina y tipo de estudio a realizar.

SIA realiza la propuesta de ubicacin del edificio de energa.

SIA debe pensar en la viabilidad de esta solucin teniendo en cuenta que lazona propuesta es la de acceso a la parcela 6.5.

SIA comenta las conversaciones mantenidas con ESD la semana anterior.La conclusin de estas conversiones es que la informacin que aparece enel master plan, con relacin a clculos energticos es bastante preliminar.

Se comentan las diferentes alternativas para la recogida selectiva.

Se entrega el informe de la visita del pasado 4/03/99. SIA ha recorrido eltrazado del torrente y se ha reunido con los Servicios Hidrulicos de la Co-munidad que, a priori, estn de acuerdo con la solucin del torrente pro-puesta por SIA.Se presenta el informe sobre los modelos de gestin de

TEMA

Red de saneamiento

Red de agua potable yterciaria

Estudio geotcnico

EdificioEnerga/RSU

Energa

Instituto Bess

Torrente

Telecom

ACCIN

AGUAS

AGUAS

SIA

SIA

INFO

INFO

INFO

PT

IT.n: 6290/015

C.D.: 3.2

Fecha: 12/03/99

Anexo:

Encargo:

Ttulo:

SIAArch.

SIA2

PT3

PT4

PT5

Acta de reunin del da 8/3/99

Parque de las Tecnologas

Cop

ias

6

Lugar: Oficinas de PTAsistentes:PT Sr. Matas

Sr. RomaR. DOL Sr. DolI. BESS Sr. MentzAGUAS MUNICIPALES Sr. RicoSIA Sr. Vieira

Sr. HeinesSr. SolteroSra. AlamisSr. Pey

sentan situaciones de conflictividad de cara a posiblesrepercusiones jurdicas, o simplemente para dar msfuerza a las peticiones o indicaciones de la direccinfacultativa. El gestor debe recomendar la utilizacinde este instrumento desde el primer momento.

El libro es suministrado por el colegio oficial co-rrespondiente donde se ha llevado a visar el proyecto y,cada vez ms, va teniendo mayor peso dado el constan-te incremento de la peticin de responsabilidades comoconsecuencia del impulso que la mejora de la calidad yla exigencia para con la misma se est teniendo.

En 1982 los propietarios de un edificio de apar-tamentos situado en el ncleo residencial de la esta-

cin invernal de esqu de Baqueira Beret, en los Pi-rineos espaoles, interpusieron una demanda contrala constructora, promotora y direccin facultativade las obras por defectos de obra en los cerramien-tos de la fachada.

Los cerramientos laterales se haban construidoa base de bloques de hormign prefabricado deunos veinte cm de espesor sin cmara de aislamien-to y estaban recubiertos exteriormente con una capade mortero de color, adherida de forma directa sinningn tipo de elemento intermedio (malla de aceropor ejemplo,). Al cabo de unos cuantos aos, sehaba comenzado a desprender la capa dejando aldescubierto los bloques de hormign poroso. Losdesprendimientos se producan por trozos y algunos


Dejan constancia

Preacuerdo

Definen solucin

PrevnDejan constancia

Establecen acuerdos

Confirma

Presentan

Informan

Avisan

Como construir yexplotar

Concretan

Motiva

Avisan

Expli

ca

frontera

Concretan in situ

DOCUMENTOSPROYECTO

Explican situaciones

INFORMES

NOTASOBRA

LIBROSORDENES E

INCIDENCIAS

CARTAS

ACTAS

Mat

iza

COMUNICACIN VERBAL

COMUNICACIN VERBAL

Fig. 15.5 La Comunicacin escrita y su frontera con la verbal

lo haca desde mas de 30 m de altura. El desprendi-miento, adems de provocar inseguridad manifiestaen los alrededores del edificio, dejaba al descubiertola pared, provocando la entrada de humedad en lasviviendas.

Ya en 1975 los propietarios haba protestadoante la promotora por la existencia de muchos de-fectos en la construccin. Y fruto de estas protestas,se lleg a un acuerdo entre los integrantes de la co-munidad de propietarios y la promotora mediante elcual aqullos reciban cada uno una cantidad alza-da de 3.000 euros en metlico y con ello se dabanpor satisfechos. Los propietarios firmaron docu-mentos por los que daban por recibidas las vi-viendas.

Pero en 1982, los propietarios volvieron a pro-testar y, esta vez, concretamente por la fachada ypor va judicial.

La demanda corri un periplo digno de una ca-rrera de fondo. Se instruy en Madrid, donde estabala sede social de la empresa constructora. En 1987cinco aos ms tarde de la demanda el juez dictexcepcin de incompetencia territorial, y absolvien primera instancia al promotor y al constructor. Eljuez envi los papeles a Vielha (Lrida), que se ocu-paba de los asuntos del Valle de Arn.

Contra dicha sentencia recurrieron los propieta-rios, al principio fue admitido a trmite; pero unavez iniciado el proceso, en abril de 1987, fue decla-rado desierto el recurso de apelacin al no constarel escrito de personacin dentro del trmino con-ferido: en julio de 1988 se declararon nulas todaslas actuaciones.

Vuelto a instarse el recurso de apelacin, en di-ciembre de 1988 fue admitido y en enero de 1989 sedeclararon conclusos los autos.

En diciembre de 1989, a la vista de que an nose haba designado da para el juicio, el abogado dela comunidad present un escrito, alegando un gra-ve deterioro de la fachada con riesgo para vidas hu-manas a causa de los frecuentes desprendimientosdel revoque de la fachada. La idea era forzar al tri-bunal a dictar sentencia para no incurrir en graveresponsabilidad.

En septiembre de 1990, ocho aos despus de lainterposicin de la demanda, la Audiencia Provin-cial de Madrid dict una sentencia en que condena-ba a la promotora y a la empresa constructora soli-

dariamente a la reparacin de la fachada, que fueevaluada en alrededor de 300.000 euros.

En cuanto al arquitecto, fue declarado absuelto,basndose en que al existir en el libro de rdenescorrespondiente a la construccin del edificio deque se trata, mltiples anotaciones sobre deficien-cias observadas en la construccin y manera de re-mediarlas, as como la anotacin de que considerade que no recibi la obra efectuada.

La fachada fue reparada a costa de la construc-tora, sin que se sepa el grado de acuerdo que tuvocon la promotora y se aprovech la reparacin paraadherir a la pared una capa de aislamiento.

El libro de incidencias, en cambio, tiene la mi-sin de ser testigo de sucesos que la direccin facul-tativa considera graves y que pueden afectar o hanafectado a la seguridad para las personas. El directorfacultativo de la construccin redacta en el libro losincidentes que crea oportuno resear y debe enviaruna copia de lo escrito al departamento correspon-diente de la autoridad local, segn lo que en cada ca-so est legalmente establecido. A partir de ese mo-mento se ha hecho partcipe del problema a laadministracin pblica, lo que significar un avalpara las decisiones que se deban de tomar.

Suele ser normal que se notifique en el libro deincidencias algn accidente laboral, o actuacin muyinadecuada de algn actor que pueda poner en peli-gro vidas humanas. Y tambin suele ser inmediato elque se personen en el lugar de los hechos inspectoresde seguridad que, adems de investigar los hechosdenunciados, ponga en jaque a todo el sistema, revi-sando esa y otras situaciones.

El gestor de obra en cualquier caso, debe preocu-parse de que ambos libros se transformen en docu-mentos tiles utilizados en la medida de lo necesa-rio.

5.4.5 Notas o instrucciones tcnicas deconstruccin

Durante la construccin de la UA, corresponde al di-rector facultativo la emisin de las rdenes a los di-ferentes contratista, que supongan actuaciones sobrela UA, ya que es una responsabilidad no transferible.Pero sus rdenes deben ser aprobadas por el gestor


del proyecto, an cuando modifiquen los objetivosinicialmente aprobados y que han servido de basepar la misin del director facultativo. As por ejem-plo no puede dar rdenes sin aprobar que modifi-quen el precio, la calidad, el impacto medioambien-tal, la seguridad, etc. En esas y otros ocasiones laGPU debe autorizar, como representante de la pro-piedad, cualquier modificacin.

La GPU tambin emite instrucciones tcnicas deconstruccin que afectan fundamentalmente a rde-nes de secuencias de construccin que afectan al pla-zo, as como otras que repercuten en el coste, as co-mo las relativas a cualquier objetivo cuyo controlest reservado al gestor o compartido con l.

En todos esos aspectos, suele ser normal que mu-chas rdenes del proyectista se emitan por escritocon notas internas que estn incluidas dentro de unprocedimiento general de actuacin. Pues bien, deacuerdo con ese mismo procedimiento, que puedeestar incluido dentro del manual de procedimientos,los constructores o suministradores, tienen que abs-tenerse de seguir las rdenes dadas si consideran queellas pueden dar lugar a una reclamacin econmicapor su parte, a un aumento de plazo, etc. En esos ca-sos se debe solicitar el consentimiento de la GPU.(Lo lgico, en general, es que de todas las rdenes,siempre haya una copia para la GPU que va evaluan-do la procedencia de la misma.)

En todo caso, la proximidad a los hechos por par-te del gestor y su equipo, hace fcil la situacin y ha-ce, tambin poco viable que, en un ambiente de rela-cin razonable, se produzcan disfunciones en lasactuaciones o problemas de competencia. Slo cuan-do no se han sabido plantear desde un principio losdiferentes roles de forma coherente y tambin con-tractualmente o cuando el gestor no ha llegado a ga-narse la confianza de los diferentes actores, es cuan-do aparecen los problemas de competencias y segenera el caldo de cultivo propio de un final no dese-ado y en contra, al menos, de los intereses del cliente.

5.4.6 Los documentos de proyecto

Nos referimos aqu a los documentos generados porlos diferentes actores que, de forma escrita y grfica,representan las formas y contenidos de la UA que elconstructor y suministrador deben transformar en al-go material. Todos ellos deben ser controlados y ges-

tionados por la GPU que, sin pretender asumir o sos-layar la responsabilidad que tienen sus autores, ha detratar de asegurarse, en el mayor nivel de confianzaposible, que:

Son suficientes Son correctos, tcnicamente hablando Responden a los intereses del cliente Respetan los condicionantes insoslayables (me-

dio ambiente, seguridad, urbanismo, etc. ) Cada actor conoce aquellos documentos que,

generados por otros, l necesita para el desarrollo desus propias funciones, y adems en su ltima ver-sin.

Los actores que preparan documentos diversossobre el proyecto son entre otros:

Proyectistas: memorias, presupuestos, pliegos decondiciones, planos, presupuestos, estudios de segu-ridad, etc.

Suministradores: planos de equipos, catlogos,planes de mantenimiento, manuales de autoseguri-dad, manuales de funcionamiento, valores de funcio-namiento, etc.

Contratistas: Planos cmo construido, planesde mantenimiento, presupuestos, manuales de fun-cionamiento, etc.

Compaas de servicio: condiciones de funcio-namiento del servicio.

Administraciones Pblicas: condiciones sobreinstalacin, construccin, medio ambiente, seguri-dad.

Laboratorios de ensayo homologados: valoresde ensayo sobre resistencia de materiales, aislamien-to, desgaste, etc.

Especialistas: estudios viabilidad, mercado, ma-teriales, geotcnicos, etc.

La gestin que sobre este tipo de documentacinlleva a cabo el gestor, se inicia ya en la fase de con-cepcin y se basa, fundamentalmente, en actuar co-mo punto neurlgico sobre el que gravita y se con-densa casi toda la informacin que luego distribuyea quien corresponda.

Una vez el gestor recibe un documento de pro-yecto y lo revisa para asegurarse que cumple las es-pecificaciones mnimas que permitan el cumpli-miento de los objetivos (est claro que la revisin nopuede ser exhaustiva pues la responsabilidad profe-sional del proyectista debe impedir el ejercicio de unnuevo proyecto por parte del gestor y la dilucin de


esa responsabilidad) la reenva a quien corresponda(normalmente al cliente y a los contratistas y provee-dores). El envo al cliente podra ser a travs del ca-nal abierto que se tiene en un portal electrnico ex-clusivo para l. Al resto puede ser enviado va fax,internet o correo ordinario. Adjuntamos un esquemade envo de documentacin proyectual a los diferen-tes actores.

Proyectista enva documentos de proyecto agestor / project manager

Gestor verifica y da el V B Gestor guarda la nueva versin en el servidor El gestor enva notificacin a la lista de distri-

bucinEn todo caso hay informaciones que no es preci-

so que pasen a travs del gestor como son, por ejem-plo, las que habitualmente el proyectista demanda dealgunos suministradores que le ayudan a disear(IS). Sin embargo, para evitar errores y olvidos, esconveniente que, dentro del manual de procedimien-tos, se redacte uno que aclare el sistema e impidadisfunciones. La actualidad y realismo del manualhar que, en este sentido, se pueda ir modificando elcontenido del procedimiento, para evitar que la ex-

cesiva concentracin de informacin haga perderagilidad al sistema.

Como repetidas veces se ha comentado, la GCD esun simple instrumento para facilitar el proceso y no unfin. Por lo tanto al menor atisbo de percepcin de ex-ceso de burocracia, prdida de realismo o falta de agi-lidad, hay que proceder a cambiar el procedimiento.

6 Archivo de la documentacin

Para el archivo de documentacin, proponemos esta-blecer el sistema utilizado como modelo dentro de losprogramas que aseguran la calidad tipo ISO o similar.

Uno de los sistemas que ahora recomendamos esel que confiere al director del encargo el gestor laresponsabilidad del archivo del proyecto en cuestiny por lo tanto de su ordenacin y de la normativa aaplicar en funcin de la misin del proyecto (laseformas de actuar). Normativa que, como es lgico,debe seguir tambin las directrices del propio plande calidad especfico del trabajo.

El procedimiento que se podra establecer en l-neas generales sera el siguiente:


FAX

FAX

GESTOR

INTERNET

PROYECTISTA

CLIENTE

CONTRATISTASY

PROVEEDORES

RTC

OK!

Fig. 15.6. Transmisin de documentos del proyecto


Fig. 15.7 Estndar de control de comunicacin


2

1

3

4

5

6 12

11

10

9

8

7DEFINICIN

ALCANCE

DOC. PROYECTO

PLANIFICACIN

COSTES

CALIDAD

CONTRATACIONES

SEGURIDAD Y SALUD

GESTIONES OFICIALES

MEDIO AMBIENTE

COMUNICACIONES

RECURSOS

MEN PRINCIPAL

2

1

3

4

5

DEFINICIN INICIAL

MODIFICACIONES

EDP

CONSULTA PROCEDIMIENTO

MEN PRINCIPAL

2. ALCANCE

2

1

3

4

5

6

PLANOS

MEMORIA

PLIEGOS CONDICIONES

ESPECIFICACIONES COMPRAS

PRESUPUESTO


3. DOCUMENTOS PROYECTO

7 MEN PRINCIPAL

2

1

3

4

5

PLANIFICACIN GENERAL INICIAL

SEGUIMIENTO Y ACTUALIZACIN

INFORMES ESPECFICOS


MEN PRINCIPAL

4. PLANIFICACIN

2

1

3

4

5

6

PLAN GENERAL DE COSTES

CUADRO DE SEGUIMIENTO

CERTIFICACIONES

INFORMES ESPECFICOS


MEN PRINCIPAL

5. COSTES

2

1

3

4

PLAN CONTROL DE CALIDAD

INFORMES ESPECFICOS


MEN PRINCIPAL

6. CALIDAD

2

1

3

4

5

6

DEFINICIN Y OBJETIVOS INICIALES

MODIFICACIONES


RECEPCIN MENSAJES

ENVIAR MENSAJES

MEN PRINCIPAL

1. DEFINICIN Y OBJETIVOS

6.1 Clasificacin decimal

En funcin de la EDP y a la filosofa que emane delpropio proyecto, el gestor establecer una clasificacindecimal por reas temticas, que servir para identificartodos los documentos. (Ver en las figs. 15.7 y 8 estn-dares de control de documentos manual o electrnico).

6.2 Entradas y salidas de documentos

Se registrarn indicando un nmero de orden, fecha,destinatario, remitente, asunto y nmero de encargo.La indicacin se har en el propio documento o en el

de acompaamiento (caso de disquetes, por ejemplo,pero si no hubiera carta se har una nota a mano).

Toda la documentacin se enviar al gestor, quela archivar l mismo o la secretara del encargodepende de la organizacin interna de cada consul-tora. Se recomienda siempre que una copia de losdocumentos recibidos o emitidos sea para el cliente.

6.3 Responsabilidades del gestor

Adems de preparar la clasificacin decimal, indica-r la distribucin de documentos y visar la salida detodos los documentos que salgan al exterior.


2

1

3

4

5

6

PAQUETES

DOCUMENTOS DE PETICIN DE OFERTAS

INFORMES COMPARACIN

CONTRATOS


MEN PRINCIPAL

7. CONTRATACIONES

2

1

3

4

5

6

ESTUDIO DE SEGURIDAD Y SALUD

PLAN DE SEGURIDAD Y SALUD

INFORMES ESPECFICOS

PARTES DE ACCIDENTES


MEN PRINCIPAL

8. SEGURIDAD Y SALUD

2

1

3

4

5

ENTIDADES IMPLICADAS

CORRESPONDENCIA

AUTORIZACIONES Y/O APROBACIONES


MEN PRINCIPAL

9. GESTIONES OFICIALES

2

1

3

4

PLAN GENERAL GESTIN

INFORMES ESPECFICOS


MEN PRINCIPAL

10. MEDIO AMBIENTE

2

1

3

4

5

6

ENTRADA CORRESPONDENCIA

SALIDA CORRESPONDENCIA

INFORMES MENSUALES

INFORMES Y ACTAS


MEN PRINCIPAL

11. COMUNICACIONES

2

1

3

4

PLANIFICACIN DE LOS RECURSOS

MATRIZ DE RESPONSABILIDADES


MEN PRINCIPAL

12. RECURSOS

Fig. 15.8 Pantallas programa para arcchivo on line


6.4 Responsabilidades de la secretaradel encargo

Correspondera a la secretara la apertura de carpetasdel archivo, la distribucin de documentos y el ar-chivo.

Algunas de las consideraciones que habra quehacer son las siguientes:

Respecto al gestor: cualquier informacin para ser incluida en

la red, debera pasar por un control de cali-dad que se establezca con anterioridad

incluir en la red slo aquellas informacioneso datos que previamente han pasado un pro-ceso de discusin interna tanto entre los tc-nicos de la GPU como entre ellos y el pro-yectista. Y eso para impedir que tanto eldiseo del proyectista como las gestionesque se estn haciendo sean puestas en crisisconstantemente e impidan un trabajo normalde los componentes de los equipos.

Respecto al proyectista:

los envos de informacin al gestor hay queprocurar que sean tambin por va electrni-ca para favorecer el tratamiento posterior ysu inclusin en el sistema

los envos que desde el gestor se le hagantambin se preferir que sean por va elec-trnica, aunque frecuentemente es til quese acompaen con correos, con un mayor omenor grado de seguridad jurdica y real ensu recepcin.

Respecto al cliente: Es conveniente que est limitado y controla-

do el nmero de personas con capacidad pa-ra reenviar mensajes ya que pueden condi-cionar el trabajo tanto de la GPU como delequipo de proyecto.

Respecto a contratistas y suministradores: los envos que se les hagan, adems de que lo

sean va correo electrnico, y al igual que encaso del proyectista, es til en algunas oca-siones que vayan acompaados o sean susti-tuidos por envos certificados tradicionales.

Sabes qu me recuerdan estos momentos en queparece que se estn acabando las cosas pero no ter-minan de acabar? me trat de explicar lvaro.

Pues mira, me acuerdo de las primeras sema-nas cuando estbamos empezando y pareca que noacaban de arrancar las obras. La constructora de-ca que empezaba pero no empezaba y ahora diceque acaba, pero no acaba. En las primeras semanasperdimos un montn de tiempo, ahora nos pasa lomismo. Lo curioso es que, tanto antes como ahora,eso iba y va en detrimento de su facturacin, lo queno me acaba de encajar concluy.

lvaro es un buen amigo mo, y era el gestor delproyecto del Palacio de Congresos de San Antonio.Haca nueve meses que haba sido inaugurado ofi-cialmente por la ms alta representacin del pas,inauguracin oficial que fue seguida por la real atravs de un congreso internacional de arquitectos.Pues bien, el comentario de lvaro vena a cuentode que la compaa constructora adjudicataria de laconstruccin del palacio y de su aparcamiento sub-terrneo, situado a unos cincuenta o sesenta metrosde aqul, haba seguido trabajando todos aquellosmeses.

Se haba dedicado la constructora a terminar al-gunos detalles solicitados por el arquitecto, modifi-cando algunos errores de menor importancia oconstruyendo pequeas obras que poda entenderseque eran nuevas, aunque los arquitectos de RichardCoster decan que deban estar incluidas en el pre-supuesto original.

El caso es que, poco o mucho, el equipo de ges-tin que diriga lvaro haba seguido involucradoen el proyecto nueve meses ms de lo previsto. Esosupona que cada semana haba siempre dos o tres

horas que Pedro Montes, el gestor de la construc-cin, dedicaba al seguimiento de las obras, o almantenimiento de alguna reunin a la que, de vez encuando, tambin asista lvaro.

Las obras de finalizacin podan haberse hechoen cinco o seis semanas, pero la discusin si estabano no incluidas en el presupuesto inicial, o el procesode averiguar quin era el culpable del error que ha-ba que subsanar, haba hecho que los trabajos sealargasen muchas semanas ms.

Lo que no entiendo me deca Pedro delante deAlvaro es como la constructora no tom la decisinde terminar rpidamente las obras teniendo comotienen pendiente de cobrar, casi 6 Meuros que co-rresponden a la liquidacin final. Para m es comoun misterio. Si yo fuera el presidente de esa compa-a, pedira explicaciones muy serias, al jefe de obrao al delegado en San Antonio, de por qu ese dineroest en la cuenta corriente del ayuntamiento y no enla de la empresa.

Los resultados obtenidos en el palacio de con-gresos eran francamente positivos. Desde el da dela inauguracin, no haba tenido uno de descanso.Haba programados congresos y reuniones de todotipo. Se poda decir que tena una agenda de com-promisos completa para los siguientes veinticuatromeses. El edificio, adems, haba colmado todas lasexpectativas puestas en el proyecto: era luminoso,moderno, acogedor, y las instalaciones haban fun-cionado a la perfeccin. Sin duda era un orgullo pa-ra el alcalde de la ciudad, para Luis Vilaso, que fueteniente-alcalde, y hoy es consejero del gobierno; yen general para toda la ciudad.

Quienes estaban ms molestos eran lvaro Resery Pedro Montes de la compaa de ingeniera que

Empresas y organizaciones en la sociedad de hoy 351

16. Fase final del CVPU

segua atendiendo a la gestin del proyecto, los ar-quitectos de Richard Coster que seguan yendo deLondres a San Antonio de vez en cuando y CarlosSanjos, gerente de la sociedad municipal que cons-trua el palacio por mandato del ayuntamiento. Todosellos estaban soportando el tener que reunirse de vezen cuando para discutir y presionar a la constructoracon el fin de que terminara lo poco que le quedaba.

Estas eran algunas de las consideraciones y so-luciones que se trataban en casi todas esas reunio-nes y que me comentaron lvaro y Pedro:

No se entiende cmo la constructora no termi-na las obras de una vez, lo que le permitira cobrarcasi 6 Meuros

La mejor solucin es rescindir el contrato conla constructora y contratar a otra que termine lascuatro tonteras que quedan

Lo que queda no condiciona en absoluto elfuncionamiento del palacio por eso est tardandotanto en acabarse Se debera penalizar a la cons-tructora por no terminarlo todo en la fecha pre-vista

La constructora factura tanto al ao, que 6Meuros no significan nada para ella. Puede seguiresperando y seguir discutiendo unos cuantos milesde euros durante unos cuantos meses ms

Estas cosas que quedan, deberan considerarseparte del mantenimiento del palacio y por tantoabordarse desde esa ptica. Los proyectistas y ges-tores ya no pintamos nada aqu. Adems, cada daque pasa sale una cosa nueva y nos seguirn lla-mando como sigamos viniendo por aqu

Sigo sin entender la postura de la constructo-ra,

lvaro y Pedro, queran proponer algo definitivoa Carlos Sanjos para terminar, de una vez, con lasituacin.

1 Fase final. Consideraciones generales

La fase final es el ltimo eslabn del ciclo de un pro-yecto de carcter nico, y es el perodo de tiempoque requiere el proceso para poder comprobar que laUA est terminada y se deja en las mejores condicio-nes para la explotacin; tambin entonces se sacanconclusiones para el siguiente proyecto: esta posturaes algo diferente a lo que suele producirse cuando loque se quiere es acabar cuanto antes y salir corrien-do para poder empezar otro proyecto.

Son dos filosofas diferentes y, por qu no,perfectamente vlidas. La diferencia fundamental es-triba en que la segunda no ofrece demasiado valoraadido positivo a la sociedad, a las empresas, nitampoco a los propios profesionales que han interve-nido. La primera, en cambio, culmina la carrera delaprendizaje y del valor mediante el encuentro de lasolucin que se ha buscado a lo largo del proceso,y de la que slo se tiene constancia cuando se ponenlos resultados en manos de quien los tienen que re-cibir y utilizar. (No hay aprendizaje realmente, hastaque existe la confrontacin con la realidad que eradesconocida, y esa realidad llega al final del CVPU).


Revisin yaceptacin

Recopilacindocumentacin Evaluacin

AprendizajeGPUTransferencia

usuarios

Enseanza ausuarios

TransferenciaInternaGPU

ReubicacinequipoGPU

Fig. 16.1 Esquema de la fase final

Se cierra el circulo del valor aadido personal sise agrega, al aprendizaje anterior, la posibilidad de laenseanza, mediante la preparacin, entrega y mues-tra de lo proyectado al explotador y/o usuario delproducto, debidamente documentado.

Desde el punto de vista de la GPU, la fase finales una ocasin nica para retomar el proyecto, orde-nar todas las circunstancias acaecidas hasta enton-ces, y transformar los puntos negativos en oportuni-dades de mejora para el futuro, y eso, tanto delantedel cliente que se est dejando, como pensando enlos futuros que vendrn. Las gestiones y documentosque se generan pueden ayudar a ello.

Para el cliente es la oportunidad de empezar bienuna nueva fase de otro ciclo, la de la explotacin dela UA. Empezar bien supone partir de la disposicinde:

Resultados confrontados y seguros de la bon-dad del funcionamiento de la UA

Unos buenos procedimientos para el mante-nimiento de los equipos y el funcionamiento de laUA

Una buena formacin inicial del equipo de ex-plotacin que favorezca una pronta entrada en rgi-men

Una documentacin tcnica cmo construidoque ayude a la explotacin.

Una documentacin oficial y de proyecto com-pleta que evite confrontaciones y malos entendidoscon los organismos pblicos.

En todo ello debe redundar una buena gestin dela fase final de un CVPU.

2 Trabajos a realizar por la GPU en esta fase

De acuerdo con las consideraciones hechas anterior-mente, la fase final comprender los siguientes tra-bajos fundamentales de la GPU:

Revisin y aceptacin de la UA con listado yconclusin de gestiones y asuntos pendientes

Recopilacin para entrega al cliente /usuario dela documentacin generada

Transferencia de la UA al cliente-usuario

Fase final del CVPU 353

Transfer. deconocimiento

Transfer. deconocimiento

Revisiny

aceptacinUA

Transf.de la UA

alcliente

Transf.InternaGPU

Desact.y reubic.equipo

Cierredel

encargo

Listado degestiones y

asuntospendientes

EntregaDocumentos

y listadosque pasana mante-nimiento

Evaluacintrabajo

Evaluacindel trabajoen la GPU

Fig. 16.2 Trabajos a realizar en la fase final

Transferencias internas de la GPU. Evaluacin deltrabajo realizado y propuestas de medidas de progreso

Desactivacin y reubicacin del equipo Cierre del encargo y del CVPU con evaluacin

del trabajoDe la lectura del estado de actividades, podr

desprenderse que en todas ellas hay una incidenciamuy directa del propio gestor, responsable del equi-po de gestin. Probablemente, la intensidad de su ac-tuacin sea similar a la que tuvo que imprimir en losinicios del encargo, cuando deba sentar las bases dela gestin, definiendo bien los lmites de la actua-cin, los interlocutores, qu es lo haba que hacer,los procedimientos, etc. Ahora se trata de dejar lascosas claras y completas antes de terminar, perotambin ha de conseguir que se cierre el ciclo en elplazo ms breve posible sin que se resienta ni la per-cepcin que del servicio tenga el cliente ni la reali-dad de los objetivos a cumplir.

3 Revisin y aceptacin de la UA

El proceso de revisin y aceptacin de una UA no selleva a cabo exclusivamente al final del CVPU, sinoque se va produciendo a lo largo de toda la fase deimplementacin en aquellos elementos susceptiblesde ser analizados y aprobados de forma indepen-diente sin esperar a un anlisis de conjunto.

Esa es la razn por la que la revisin final puedeser relativamente rpida si se compara con la magni-tud de la UA. Sin embargo hay un enemigo claro a lahora de la revisin final. Nos referimos a las prisaspor el cumplimiento del plazo. Frente a ello, est lafigura de la recepcin provisional hay legislacio-nes que, en los proyectos oficiales, no la admiten.Pero, a pesar de ella, sigue habiendo un peligro quehay que soslayar: una recepcin provisional puedeeternizar la solucin definitiva de los problemas.

3.1 Caractersticas que se deben considerar en larevisin y aceptacin de una UA

A lo largo de todo el ciclo se ha ido desarrollando untrabajo, compartido por un conjunto de actores, queinterpretando los deseos del proyectista, que a su vezha hecho lo propio con los del cliente, han llegado ala materializacin de una idea o de una solucin(corporificacin). Pero el resultado final puede, conmucha probabilidad, no coincidir exactamente conlo previsto inicialmente.

Efectivamente, la funcin puede haber aumentado,disminuido o haberse modificado en algn sentido. Elfuncionamiento puede ser diferente a lo esperado y ha-berse especificado en los pliegos de condiciones ini-ciales y los resultados, cuantitativos o cualitativos,tambin pueden ser diferentes. Y normalmente todo


Nuevasespecificaciones

Nuevosdiseos

Nuevasdimensiones

Nuevasprestaciones

Cambiosestticos

Incrementoscoste

Cambiosconstructibilidad

Cambiosmercado

Procesostecnolgicos

Proceso decorporificacin

FUNCIN QUE LORESUELVE

Pliegos de condicionesModificaciones tcnicasModelo referencia

UA

CONFLICTO

Fig. 16.3 Esquema de revisin y aceptacin de una UA

ello ha sido consecuencia del propio progreso que elproyecto ha sufrido como consecuencia de condicio-nantes de toda ndole: coste, tecnologa, plazo, contra-tista,

Esta situacin, deseada o no, es previsible; porello es recomendable que a lo largo del CVPU se va-ya dejando constancia de los sucesivos cambios conel fin de disponer, en el momento en que se necesi-ten, de un modelo terico del que partir.

La revisin para aceptacin debe ser hecha por eldirector del proyecto encargado y responsable oficialde la supervisin de los trabajos de construccin y/omontaje, que emitir un informe con el resultado dela misma. El contenido de la revisin y su profundi-dad deben ser aprobados por la GPU, en nombre dela propiedad, aunque algunos de los extremos de lamisma estarn ya explcitos en los documentos deproyecto o en el mismo contrato entre propiedad ycontratista.

Paralelamente, el gestor hace una revisin msligera a modo de prueba que, en todo caso, trata deconfirmar o no el informe ms profundo de la direc-cin de proyecto.

En los puntos siguientes, se explicitan y comen-tan, de forma resumida, algunas de las actividadesque se deben hacer y que corresponden a la misindel director del proyecto responsable de la direccinde los trabajos. El gestor utilizar los mismos argu-mentos de control aunque slo de la magnitud y enla profundidad que a su juicio si no existe algnacuerdo formal con la propiedad que lo acote debahacerse para certificar la bondad de los documentosde revisin que reciba.

3.2 Marco de referencia

Tal como sealbamos en el punto anterior, a la horade la revisin y aceptacin de la UA, se parte confrecuencia de un nuevo marco de referencia, defini-do por los cambios o modificaciones que se hayanido introduciendo a lo largo del ciclo. Este marco lodeben preparar conjuntamente el proyectista y elgestor sobre la base de la documentacin escrita quese haya ido generando. Fundamentalmente sern:

Informes tcnicos sobre nuevas propuestas he-chas por el proyectista, que se han llevado a cabo yque modifiquen los supuestos iniciales.

Actas de acuerdos entre cliente, proyectista yconstructor o suministrador sobre cambios y nuevosasuntos incorporados a la UA

rdenes indicadas en el libro de rdenes Documentos grficos que modifiquen los ini-

ciales Nuevos contratos Nuevas rdenes de compra Modificaciones contractualesGeneralmente los cambios no son tanto por las

condiciones funcionales a las que debe responder laUA, sino debidos a aspectos de menor calado quehacen referencia a modificaciones en la instalacinde equipos, trazados, materiales, etc. El problemaestriba en que, algunas veces, no hay constancia his-trica escrita de quin emiti la orden de un cambio,y por qu se hizo. Eso crea problemas a la hora de laaceptacin.

El gestor debe, por tanto, ir preocupndose de re-coger, a lo largo del ciclo, la constancia escrita y jus-tificada de todas aquellas variaciones para despusconformar ese nuevo marco de referencia que permi-te realizar una revisin que pueda ser aceptada, almenos en sus hiptesis de partida, por todos los ac-tores.

3.3 Revisiones dimensionales

Esta revisin ya se ha debido ir haciendo a lo largodel proceso, tanto por el proyectista como por el ges-tor, y en esta fase se limitar a lo que se correspondacon la planificacin del momento y a lo que la GPUo el proyectista consideren como fundamental y que,aunque se haya revisado con anterioridad, parezcaprudente que se deba volver a revisar antes de suaceptacin final.

Es el caso de: Glibos bajo gras u otros elementos fijos o

mviles que concreten espacios no discutibles Dimensiones de salidas de emergencia Dimensiones de pasos de salida para equipos

instalados en el interior de las salas Retranqueos en construcciones como conse-

cuencia de ordenanzas urbansticas Dimensiones generales de una UA que deban

acoplarse posteriormente en espacios limitados Etc.

Fase final del CVPU 355

(Se hace mencin con frecuencia al proyectista yal director del proyecto. Se entiende que son dos for-mas de designar a la misma persona o al conjunto deellas que hacen esa funcin. Tambin, para abreviar,si las utilizamos en el contexto de las fases de imple-mentacin y final, entendemos que estn encargadasde la direccin de los trabajos de corporificacin,aunque es conocido que se pueden contratar equiposdiferentes para el proyecto y para la direccin de suconstruccin o montaje.)

3.4 Revisiones cualitativas

Tambin estas revisiones deben haberse ido hacien-do a lo largo del proceso de construccin. Es eviden-te que no se puede esperar al final para dictaminarsobre la calidad de lo entregado. Eso llevara a irre-versibles situaciones no deseadas, cosa que ya ocu-rre con frecuencia, pues no siempre se llega a tiempopara testar la calidad de algn elemento de la UA yse tiene que aceptar tal cual queda, para evitar unmal mayor como sera la paralizacin de una puestaen marcha.

3.4.1 Revisin de la calidad de los materiales

Al final del ciclo se reciben los ensayos realizadosen los ltimos materiales, o en conjuntos de ellos, loque permite tomar, en su caso, la decisin de laaceptacin correspondiente. El nmero y las caracte-rsticas de los ensayos estarn perfectamente deter-minados en el plan de calidad que realiz el proyec-tista, que ya constaba en el propio proyecto, que seredact al inicio de la construccin por quien debahacer la direccin de los trabajos, si fueran tcnicosdiferentes.

En todo caso, el coste de todos los ensayos debeestar incluido en el presupuesto en una partida que locontemple y que est en el entorno del 1% del totalen los casos de proyectos de edificacin. En otros ti-pos de proyectos: modelos de equipos, vehculos,acontecimientos, utensilios, etc., esta cifra puede serfrancamente mayor o ligeramente menor. Cada casoes diferente y debe estudiarse en profundidad.

El contenido de los documentos de ensayo juntocon los informes procedentes de los laboratorios ylas hojas de homologacin de los materiales proce-

dentes de los fabricantes, se incluirn en el informefinal sobre calidad.

3.4.2 Revisin de la calidad de los acabados

Probablemente es la aceptacin ms problemticapues no siempre est clara la especificacin del pro-yecto en que se hace alusin a ello. Muchas veces sehace referencia en el proyecto a un tipo de acabadoque viene definido como: buen construir, prcticalocal, buena calidad, tipo x o, en el mejor delos casos, se indica un modelo a seguir (otra instala-cin, producto, construccin existente, UA en gene-ral,). Tambin est claro que el coste asignado yadefine un acabado, determinado por los modelosque se encuentran en el mercado y que suponen unelemento de comprobacin: normalmente, un mayorcoste implica un mejor acabado.

El trmino acabados debe expresar no slo losque se refieren a la envoltura de los elementos deuna UA y de toda ella, sino al de la yuxtaposicin,unin y ensamblaje de los mismos, que puede per-mitir conformar unidades ms complejas. Y es que,probablemente, en ese trabajo de engarzamiento deelementos, es donde se produce la mayor o menorcalidad de un conjunto.

Los elementos aislados son, por lo general e inde-pendientemente de su aspecto superficial, perfecta-mente calificables como de buen acabado. Es pre-cisamente cuando se combinan con otros cuando seproducen las disfunciones estticas o proporcionan,incluso, resultados cuantitativos finales negativos:

* Las piezas secundarias que sirven para launin de elementos ms fundamentales, determinantambin calidad de acabado (tornillos, soldadura,perfiles, soldaduras, etc.).

* Una unin mal hecha, adems de proporcio-nar, objetivamente, una imagen esttica indeseable,puede producir una fuga.

* Una superficie rugosa, puede ser ms o menosadmitida desde el punto de vista esttico, pero tam-bin puede producir un rozamiento indeseado en unproceso mecnico o una molestia en el uso peridi-co del elemento por parte del usuario.

* Un canto vivo en una pieza emplazada en unlugar de riesgo, puede generar una sensacin de in-seguridad que comporte, tambin, un malestar en eluso del espacio.


* Una unin entre dos elementos, hecha con ma-terial que se descomponga con el tiempo, puede pro-ducir adems de su separacin, un efecto esttica-mente no previsto e indeseable.

* La pureza o anarqua no programadas en ladefinicin de las lneas o volmenes de un elementoes muy probable que genere disfunciones para el usode una UA.

3.5 Comprobacin de resultados

Es una comprobacin que propugnamos que debe ha-cerse conjuntamente por las partes implicadas: elpropio constructor del elemento, el proyectista y laGPU representante de la propiedad. En muchos casosa este grupo de tcnicos se aaden los pertenecientesa laboratorios u otros, que tcnicamente es precisoque estn presentes para testar la bondad de las cifrasobtenidas. Si cada actor, por su parte, hiciera la com-probacin, es muy posible que se obtuvieran resulta-dos distintos, con lo que hara falta otra ms que tu-viera el consenso de todos. As que lo mejor esempezar por ah y se ahorran tiempo y discusiones.

Normalmente las pruebas que se deben efectuarpara el conocimiento de los resultados de cada ele-mento o de la UA en su globalidad, estn especifica-das en los pliegos de condiciones tcnicas, en lasofertas de los propios contratistas o fabricantes o enlos contratos. En todo caso, y con carcter general,hay que tener en cuenta, en el inicio del proceso decomprobacin, lo siguiente:

La comprobacin d

gestión integrada de proyectos-9

Documents