Gestión Integrada de Proyectos-3

Empresas y organizaciones en la sociedad de hoy
61
3. La calidad en los proyectos de carcter nico
1 La proyectacin: tecnologa y servicio

La actividad de la proyectacin supone la presencia
de dos conceptos, que, pudiendo ser en muchos casos antagnicos, en cambio, sumados adecuadamente proporcionan una gran fortaleza en su exposicin:
la tecnologa asociada al diseo (TD) y el servicio.
Considerar nicamente que proyectar supone disear con la aplicacin de las tecnologas necesarias
para la resolucin de un conflicto es un error, porque
ello nos llevara a proponer soluciones, en muchos
casos, antieconmicas, inadecuadas en el tiempo o
en el espacio, o simplemente no deseadas por quien
es el receptor de la UA. Pero tambin es un error el
considerarlo exclusivamente un servicio porque ello
implicara un probable divorcio entre la utilidad de
la UA y la necesaria concepcin progresista de la labor del proyectista que debe ir siempre asociada con
su esfuerzo y con el del corporificador, que debe interpretar los deseos del cliente y las soluciones del
proyectista.
La ingeniera y la arquitectura deben aplicar las
TDs ms adecuadas para la resolucin del conflicto
que se plantea. Con todo, tan til puede ser una TD
ya superada por el tiempo como la que la investigacin define como la ms moderna.
Es deber inexcusable del proyectista escrutar la
posibilidad de utilizacin de aquella que represente
ms avance en todos los sentidos y ah, una vez ms,
resulta extraordinariamente ventajoso que el tcnico
comparta sus planteamientos dentro de un grupo
multidisciplinar. Los avances, fuera de los genios
que son la excepcin, se consiguen a travs de equipos con buena organizacin y sobre todo mucha paciencia que no quiere decir laxitud.
En ese equipo no debe quedar descolgado los

que posteriormente debern materializar la idea. Y
nos estamos refiriendo a los contratistas y suministradores, que genricamente tambin denominamos
corporificadores. Aqu el gestor del PU debe utilizar los instrumentos de la IV y de la IS y procurar
que el diseador utilice todos los argumentos disponibles para resolver el conflicto, haciendo que esta
resolucin sea la ms adecuada. Y eso pasa, sin duda, por tener en cuenta todos los actores. Esa ser
una de las labores fundamentales del gestor.
Pero la actividad de la proyectacin no es slo la
plasmacin de un trabajo visualizado sobre una UA
basada en el ingenio y en la aplicacin de unas TDs,
sino que es tambin, y sobre todo, un servicio que se
realiza a peticin de alguien que desea se le suministre algo que puede concretarse en elemento corpreo.
En definitiva se trata de dar respuesta, desde el punto
de vista de la tecnologa a un conflicto planteado.
Esta dicotoma ya deja percibir cules sern los
problemas. Es que acaso debe el proyectista proyectar alguna UA con bajo nivel tcnico por que as se lo
pide el cliente? Prestara el tcnico en ese caso un
buen servicio, a pesar de haberse olvidado del principio arriba enunciado de que debe proyectar utilizando
las tecnologas ms avanzadas y que sean las adecuadas? Es lcito utilizar tecnologas que, favorecindole a l, perjudiquen al vecino? Debe un corporificador cerrar los ojos y construir algo que cree
firmemente no va a cumplir los objetivos deseados
por el cliente por falta de funcionalidad o resistencia?
Etc. Parece que la deontologa deber decirnos algo al
respecto. Pero en todo caso, una de las respuestas pasa por introducir un concepto inherente a la actividad
de la proyectacin como es el de la calidad.
Los autores, 2001; Edicions UPC, 2001.
Gestin integrada de proyectos
62
Construcciones y Obras de Infraestructura

(COISA) y Estructuras y Cubiertas (ECSA) dos de
las ms grandes constructoras europeas, se asociaron temporalmente en una unin temporal de empresas (UTE) para llevar a cabo la construccin de un
gran recinto ferial para un ayuntamiento de una ciudad del sur de Europa con ms de un milln de habitantes. La inversin prevista en el proyecto era de
36,1 Meuros; sin embargo, durante la fase de concurso, la UTE ofert una baja de un 28% quedando
su precio en 26 Meuros.
Las dos empresas, pero sobre todo COISA, tenan
el hbito de recalcular los aspectos ms importantes
del proyecto una vez eran conocedoras de haber sido adjudicatarias de alguna construccin. En este
caso hicieron lo mismo. Segn sus propias declaraciones, el objeto de ste laborioso trabajo era asegurarse de que el proyecto estaba bien y no habra
problemas en el resultado final. Las citadas empresas decan sentirse corresponsables en el producto
final a pesar de no ser los proyectistas. (Sin embargo, lo que algunos directores de obra creen es que
estas empresas recalculan los proyectos por otros
dos motivos menos responsables: por un lado intentan encontrar algn error que les permita forzar
una va para aumentar la facturacin ms all del
presupuesto inicial y, eso s, esta vez sin ninguna rebaja sobre el precio estndar y con toda probabilidad con un sustancioso incremento. El otro motivo
es simplemente tratar de encontrar soluciones alternativas al proyecto, de menor coste para ellas.)
AVANZADA
A
D
E
C
U
A
D
A
TECNOLOGA Y
DISEO
SUPERADA
La obra tena una duracin prevista de 20 meses.

A los 8 meses de iniciadas las obras, se inici la prefabricacin, en hormign, de unas lminas de la cubierta, de seccin curvilnea y con una superficie
aproximada, cada una, de unos 4 m2. A los pocos das de desencofrar las primeras piezas, se transportaron desde el taller de prefabricacin al emplazamiento de las obras.
Tres das ms tarde, aparecieron unas fisuras en
buena parte de la superficie de la mayora de las lminas construidas. La GPU inst a la direccin facultativa DF a estudiar las causas de las mismas
y su repercusin en las caractersticas resistentes de
la cubierta. La UTE opinaba que era un problema
de error proyectual: haba menos hierro del necesario. Su punto de vista lo dej patente en, al menos,
un par de las reuniones de coordinacin que se hacan semanalmente. La DF, sin embargo, atribua
las fisuras a problemas en el transporte desde el taller de prefabricacin a las obras.
La UTE, a pesar de lo indicado por la DF, insisti en su argumento y sin previo aviso y sin atenerse
al procedimiento previsto, continu la prefabricacin de la cubierta incrementando la cantidad de armadura. La GPU inst a la DF y a UTE: A una, a
definirse de una forma clara sobre la bondad de su
propio clculo, y con ello de la inocuidad del probable exceso de hierro que UTE estaba montando y, en
todo caso, a ordenar el cese o continuacin de los
trabajos de UTE para controlar todo lo que se estaba haciendo, antes de que la GPU, en nombre de la
propiedad tuviera que intervenir en forma radical. A
FORMA
SERVICIO
FONDO
Fig. 3.1 La proyectacin: La TD y el servicio
PROYECTACIN
La calidad en los proyectos de carcter nico
la otra le advirti de las consecuencias que poda

tener su proceder. Se estaba atribuyendo una responsabilidad que deba corresponder fundamentalmente a la DF, adems de desobedecer rdenes concretas que deba haber acatado.
La GPU promovi una reunin en la que estaban
presentes la DF y UTE, sta ltima con sus calculistas, que eran el propio fabricante de las placas prefabricadas y un ingeniero externo contratado al
efecto por la UTE. En la reunin, la UTE mostr
planos realizados por el fabricante de las placas y
explic los clculos de su ingeniero externo, que
coincidan entre s en la necesidad de reforzar la cubierta. La DF se limit a escuchar y a admitir de
forma general que haba algo que cambiar, sin llamarle error, y se comprometi a entregar en los prximos das unos planos nuevos con la solucin definitiva.
Pasada una semana, la DF, entreg a la GPU
unos planos nuevos, con una memoria explicativa,
para que fueran suministrados, a su vez, a la UTE.
Los planos coincidan exactamente con los del fabricante de las placas. No entreg ningn clculo.
cin: la del proyectista, la del cliente y la del corporificador. Eso querra decir que los tres estaran de
acuerdo con el resultado final y probablemente ello
habra supuesto que todos habran compartido una
misma vibracin a lo largo del proceso de realizacin, lo que sin duda habra colaborado en el resultado final.
Para llegar a ese final feliz, esto es: tcnico satisfecho porque ha aplicado las tecnologas y la imaginacin ms adecuada + ms corporificador satisfecho porque ha cumplido sus expectativas + cliente
satisfecho porque la UA conseguida es la que quera,
y los tres satisfechos porque se habrn conseguido
los niveles de rentabilidad, cuanto menos razonables, resultara apropiado que la proyectacin se
plantease como un servicio tecnolgico de calidad.
Porque, al final, la calidad viene a significar lo mejor
que para cada uno se puede conseguir.
El gestor debe aqu adoptar la actitud del animador constante e incansable al desaliento que mantiene
viva la llama de la necesidad de la mejora constante.
En esta lucha, con frecuencia puede encontrarse solo,
incluso sin el apoyo de su propio cliente. Y es que la
tensin que llega a almacenarse puede inducir a un
cierto cansancio que favorece una cierta laxitud generalizada, lo que es un caldo de cultivo para la aparicin de errores que, luego, nadie perdona.
2 La calidad como aglutinante.

El papel del gestor
El mejor resultado que se podra obtener en el diseo
de una UA es que se consiguiera una triple satisfac-
COOPERACIN + ENTENDIMIENTO
CORPORIFICADOR
SATISFECHO
Rentabilidad
Progreso
PROYECTISTA
SATISFECHO
63
CLIENTE
SATISFECHO
Rentabilidad
Formacin
Funciones
objetivo
conseguidas
Fig. 3.2 Esquema de la calidad completa
CALIDAD
CONSEGUIDA
64
En estos contextos, la implantacin de un plan de

calidad en un proyecto, repercute en dos tipos de
costes: los que se suelen llamar costes de la calidad
y los de la no calidad.
3 Caractersticas de la calidad
3.1 Actitud
La calidad parte de una disposicin de nimo, compartido por toda la cadena de actores, de llevar a cabo el proyecto. Esta disposicin es la que provoca
una accin colectiva de hacer las cosas bien mediante un trabajo bien desarrollado.
En ese sentido, si falla un eslabn las consecuencias son nefastas y el objetivo, por lo general, no se
cumple. En todo caso, quien tiene que asumir con
ms fuerza esa actitud es el propio director del proyecto y con mucha ms razn los ms altos ejecutivos del cliente. A partir de esa asuncin, por parte de
los mximos responsables de que no se entiende que
se puede elaborar una UA falta de calidad, el resto es
ya ms fcil: transmitir una mentalidad al resto del
equipo e incluso adoptar nuevas tecnologas, si ha
lugar, resulta, paradjicamente, ms sencillo. El gestor, como ya se dijo anteriormente, es, en todo este
proceso, el animador e impulsor de ideas y actitudes
que favorezcan el objetivo.
Con todo ello se obtiene un resultado doble, uno
el que se refiere a la referida mejora de la calidad, y
el otro el de conseguir que todas las personas vibren
en un objetivo comn, lo que redunda en una mejora, tambin, del clima y del nivel de relacin entre
todo el equipo.
Ningn plan para mejorar la calidad puede funcionar si no existe una actitud positiva haca ello de todas
las personas y las organizaciones que las sustentan.
3.2.1 Costes de la calidad

Son aquellos en que incurre la organizacin (entendiendo como tal la que forman solidariamente o de
forma individual, el cliente, el proyectista, el corporificador y el gestor), que est dispuesta a mejorar lo
que hace. En ese sentido se puede generalizar, conceptualmente, que se incurre en dos tipos bsicos:
costes de prevencin y costes de evaluacin.
Los costes de prevencin son aquellos que se
toman para evitar la aparicin de errores y en ese
sentido, la organizacin debe asumir con carcter
general un conjunto de acciones tales como: mantenimiento de unos recursos suplementarios mnimos
para asegurar el servicio (seguridad, suministro de
energas durante el proceso, realizacin y aceptacin
de procedimientos, charlas de informacin, reuniones de coordinacin, compra y mantenimiento de
equipos, visitas conjuntas a subcontratistas y UsA
similares, construccin de modelos y maquetas etc.).
De forma particular, cada actor debe asumir
otros gastos que inciden exclusivamente en el papel
y especialidad que a cada uno le toca jugar: nos estamos refiriendo, por ejemplo, a costos de supervisin
de los diseos (por parte de la GPU), ensayos de materiales y trabajos (corporificador), captacin de informacin para el diseo (proyectista), suministro de
informacin (cliente), etc.
3.2 Coste
El gestor ha de considerar permanentemente el coste

como un factor a considerar en todo aquello que hace. Bajo esta premisa ya parece lgico que si intenta
promover una calidad razonable en aquello que se
est proyectando, piense si eso le va a repercutir en
un aumento del coste de la UA. Y desde luego, independientemente de que ste tiene que funcionar de
acuerdo a las hiptesis previstas.
Hay que partir de la base de que el cero errores, o el: funcionar siempre, supone hacer algo
ms de lo que en principio uno cree que tiene que
tiene que hacer para que simplemente funcione.
CONTECSA era una compaa del sector siderrgico de Girona que fabricaba mallas electrosoldadas para el sector de la construccin y decidi
implantarse en la provincia de Sevilla al socaire del
impulso inversor en la obra pblica que se inici
con la preparacin de la Exposicin Universal de
1992. El esquema de recursos tcnicos que se defini para llevar a cabo el proyecto fue el siguiente: la
direccin general de CONTECSA encarg a Luis
Entenza, joven y brillante ingeniero y MBA por el
IESE, la coordinacin y las funciones de gestor del
proyecto. Se pretenda, con ello, que se iniciara en
65
COSTES DE LA CALIDAD
PREVENCIN
Supervisin
ensayos
Test al cliente
Supervisin de
informes
Supervisin cumplimiento
Admisin costos razonables
objetivos
Ensayos
Procedimientos
EVALUACIN
Admisin soporte
tcnico
Fig. 3.3 Costes de la calidad: Prevencin y evaluacin
las labores de gestin en forma prctica, a la vez

que actuaba de controlador. La ingeniera fue adjudicada a OMNIA CONSULTING, compaa especializada en temas siderrgicos.
A la hora de la negociacin de los recursos tcnicos que la ingeniera deba suministrar para el control de la ejecucin de las obras, el Director de OMNIA propuso el traslado, de forma permanente, de
uno de sus tcnicos especialistas en control a Sevilla.
Ello comportaba un coste de 5.800 euros/mes para
CONTECSA. La propuesta fue rechazada. El director general de CONTECSA argument que, estando
como iba a estar, Luis dedicado a tiempo completo al
asunto, estara prcticamente de forma constante en
las obras. Su inexperiencia podra venir compensada
por visitas peridicas de algn ingeniero de OMNIA
a las obras y por las instrucciones que ste le dejase
para saber como actuar en cada momento.
A pesar de no estar de acuerdo, Pedro Olea, Director de OMNIA, acept, dada la excelente relacin entre ambas compaas, con el convencimiento
de que con un esfuerzo suplementario por su parte,
se sabra encontrar una solucin a cada problema
que apareciese (incluso el de cambiar la forma de
control establecida). En todo caso, Pedro decidi,
adems de encargar a un ingeniero que realizara las
dos visitas al mes acordadas, actuar l mismo de supervisor del Encargo, acudiendo una vez al mes a
las obras. Con respecto a Luis, Pedro se encarg, l
mismo, de tutorizarlo.
Las obras fueron encargadas a CONSTRUCCIONES HURTADO, pequea empresa constructora lo-
cal cuyo propietario era una persona muy conocida

en la zona: diligente habladora y muy servicial; que
a todo deca que s, pues todo tena solucin. OMNIA
no estaba muy de acuerdo con la eleccin. Hubiera
querido una compaa ms profesional, pero la decisin estaba en manos de CONTECSA que aleg que
el conocimiento de HURTADO del entorno (autoridades, compaas de servicios, etc.) favorecera las
buena marcha de los trabajos. Al final, OMNIA acept la decisin comprometindose a colaborar en todo
lo posible para que el resultado final fuera aceptable.
Los primeros trabajos de movimiento de tierras
ya ofrecieron problemas. Insospechadamente, ese
ao llovi en la provincia de Sevilla lo que no haba
llovido en los ltimos 10 aos, y continuamente haba que estar deteniendo los trabajos para retirar
los blandones producidos a consecuencia de las lluvias. Luis Entenza se vea continuamente en problemas sin saber qu decisiones tomar ante la presin
del contratista que le urga a que le dejara continuar
los trabajos so pena de no cumplir los plazos. Adems, los ensayos sobre la compactacin solan tardar un poco de tiempo en mostrar los resultados.
Luis, las veces que iba a las obras, se pasaba el
tiempo yendo y viniendo a un restaurante prximo a
ellas para telefonear a OMNIA y pedir consejo de
cmo y qu decidir. Su interlocutor ordinario era
Carlos Saldana, el ingeniero, tambin joven, a quien
Pedro Olea haba encomendado el proyecto y que
iba las dos veces previstas al mes a Sevilla. De todas
formas, con mucha frecuencia, Luis hablaba con el
propio Pedro a quien sola consultar los problemas
66
ms complicados aunque los hubiera tratado con

Carlos con anterioridad, como era lo previsto.
Un da que haban quedado en las obras Pedro y
Luis, ste no acudi: tuvo un accidente conduciendo
su propio coche mientras iba a visitar a un fabricante de cubiertas y muri en el acto. La conmocin en
el equipo fue dramtica. Resultar difcil que las
personas que lo conocieron puedan olvidarle, a l y
a la que forma en que fue cortada una vida con tanta fuerza y con tan prometedor futuro.
Para sustituirle, el director general de CONTECSA contrat a Fernando Santos, un ingeniero tcnico
de gran experiencia, fundamentalmente en instalaciones, que adems de atender la fbrica de Sevilla,
supervisara obras en otras fbricas del grupo.
Una semana del mes de mayo, llegaron a las
obras Fernando y Carlos y se encontraron que uno
de los camiones del contratista estaba pisando con
sus ruedas la tierra que se estaba vertiendo sobre
una zanja de unos 100 metros de largo y sobre la
que se haba colocado, con anterioridad un tubo de
desage. La zanja tena un ancho de 1,5 a 2,5 m. y
una profundidad de entre 1 y 5 m. y estaba situada
prxima al talud de tierras que les separaba del vecino, cuyo terreno estaba unos 4 m. ms bajo.
Ambos dijeron al contratista que esa no era manera de compactar las tierras. Que debera hacerlo
con un rodillo compactador y no con las ruedas de
los camiones. El contratista, hombre que superaba
con creces la edad de Fernando y Carlos, respondi
que l se haba comprometido a entregar una determinada calidad al final de los trabajos y que era de
su responsabilidad la forma en que deba acometerlos: nadie poda darle lecciones de cmo tena que
hacer las cosas. l respondera por todo (se senta
herido en su amor propio) Fernando y Carlos asintieron y le emplazaron a esa responsabilidad.
Termin el contratista de verter y compactar
todas las tierras, tanto las que estaban sobre la zanja del desage como las del rea que la rodeaba ya
que toda ella estaba destinada a almacn del producto final (mallas electrosoldadas de redondo de
acero). Posteriormente inici la pavimentacin
Pasados dos meses, se acab el montaje de la
maquinaria en el interior de las naves y se inici la
fabricacin. A las pocas semanas, el almacn exterior se empez a llenar de malla electrosoldada. La
zona que empez a llenarse primero fue la ms pr-
xima al talud que era donde estaba la valla de lmite

del solar
Quince das despus, el gerente de la fabrica llam urgentemente a Pedro Olea: toda el rea de ms
de 100 m a lo largo del talud se haba hundido. La
tierra haba fluido y gran parte del talud se haba
desplazado. La zona que estaba ms hundida era
precisamente donde haba habido la zanja.
En un arranque de orgullo malherido, el contratista, a instancias del director de OMNIA, empez la
reparacin. Segn sus propias palabras, no pensaba que una accin tan, aparentemente sin importancia (se refera a la compactacin), pudiera causar
tal desaguisado. Asumi su responsabilidad y tras
algunas dudas, termin los trabajos. Segn dijo, no
poda consentir que alguien ms pudiera ver el estado en el que haba quedado la campa.
Pero cuando al parecer sum con calma el importe de la reparacin que haba asumido (190.000
euros), y aconsejado por un ingeniero amigo suyo,
empez una cruzada para recuperar lo que se haba
gastado.
Los hechos que sucedieron a continuacin, eran
los esperables: el contratista ech la culpa de todo a
la ingeniera y al gestor. La ingeniera y el gestor, al
contratista y el cliente acab harto de llamadas
telefnicas, y de las presiones de toda ndole a que
el contratista le estaba sometiendo para intentar recuperar algo de lo que haba invertido. Intervinieron
peritos, abogados, compaas de seguros Y al final, el contratista no llev el caso a los tribunales y
tampoco recuper ni un cntimo. El silencio por
parte de todos result ser el fin de la historia, que
parece haber quedado resuelta a complacencia de la
ingeniera y el Cliente.
Sin embargo, la relectura de estos prrafos me
sugiere que deberan haberse producido comportamientos muy diferentes a los aqu expuestos.
Los otros costes en los que se incurre son los

costes de evaluacin que deben hacerse como es
natural por proyecto. En ese sentido se pueden valorar: los costes derivados de la supervisin de los
informes realizados para analizar la profundidad
cientfica con que se hacen o el grado de asuncin de
responsabilidades tcnicas que asumen, el tiempo
destinado a la evaluacin del grado de cumplimiento
COSTOS DE CALIDAD
PREVENCIN
- Recursos suplemen. mnimos
- Realizacin procedimientos
- Informacin
- Actualizacin documentos
EVALUACIN
- Recursos suplemen. mnimos
- Reuniones cliente
- Visados
- Reuniones control
67
COSTOS DE LA NO CALIDAD
INTERNOS
- Recursos suplen. mnimos
- Requisicin prdidas disquetes
- Horas extra procedimientos urgentes
- Financieros
- Rehacer facturas
- Rehacer documentos
EXTERNOS
- Pleitos
- Financiacin
- Incobrables
- Reparacin UA
- Aumento primas
OPORTUNIDAD
- Clientes propios
- Posibles clientes
Fig. 3.4 Costes de la calidad y la no calidad
de los objetivos, etc., y todos ellos vlidos para cada

uno de los actores que intervienen. Pero sobre todo
hay que considerar el tiempo y los costos asociados,
necesarios para testar el grado de satisfaccin del
cliente que, en definitiva, es lo que ms interesa conocer.
Para una GPU este control ha de hacerse doble:
por un lado el del propio gestor a travs de un proceso continuo de intercambio de opiniones sobre la
marcha del proceso. El otro control lo debe hacer algn alto ejecutivo de la ingeniera que realiza la gestin, quien de forma neutral y ajena, pregunta de forma directa al cliente acerca de su satisfaccin a
travs de un corto test que impida la contradiccin o
que la circunvale para encontrar lo que realmente
piensa.
3.2.2 Costes de la no calidad

Son los ocasionados como consecuencia de una mala proyectacin o ejecucin. Algunos son causados
por un intento de mejorar las cualidades que antes de
la proyectacin o ejecucin se despreciaban y que
una vez corporificada la UA se intentan conseguir.
Otros son simplemente lesiones graves de la calidad
que llegan a atentar incluso contra el funcionamiento. Son los ms gravosos y estn fundamentados,
probablemente, en que no se han asumido los costes
antes comentados en 3.2.1 (que comparativamente
puede ser despreciables). Y es que resulta difcil obtener una buena calidad si previamente no existe un
acto voluntario de asuncin del hecho que se desea
obtener algo mejor de lo que ordinariamente se obtiene.
Por lo general, la autocomplacencia en lo de que
ya se dispone, provoca la prdida de la agudeza necesaria para percibir los cambios que hace falta introducir para conseguir una UA con cualidades superiores que eleven el nivel de prestaciones. Como se
ha dicho con anterioridad, la GPU debe alentar el
ejercicio de la insatisfaccin permanente para que
cliente, proyectista y corporificador no cesen en el
empeo de la mejora constante.
Para un fcil anlisis se pueden desglosar stos
en internos y externos.
Los costes internos son los que se generan en el
interior del propio equipo de proyectistas una vez se
ha entregado el diseo en su totalidad para su revisin por la GPU y antes de la entrega definitiva de la
UA. Son consecuencia de errores que comportan un
gasto con desembolso directo de dinero o con implicaciones monetarias indirectas, pero que al final suponen un costo
Podran catalogarse como tales:
El alargamiento del plazo por deficiente planificacin.
Coste de reposicin por la prdida de programas y proyectos almacenados en disquetes.
Coste de procedimientos urgentes (horas ex-
68
COSTES DE LA NO CALIDAD
INTERNOS
Recursos
internos/externos
EXTERNOS
Recursos administrativos
Costos
reparaciones
y soporte extra
Incobrables
Recursos administrativos extra
Recursos internos extras
Recursos financieros extra
Fig. 3.5 Costes de la no calidad
tra,..) para rehacer planos, clculos, memorias, etc.

como consecuencia de la revisin del diseo.
Costes financieros por el alargamiento del plazo de cobro.
Costes por interferencias con otros proyectos
en elaboracin al juntarse los plazos por tener que
rectificar errores en uno de ellos.
Costes por rehacer facturas por deficiente
coordinacin entre el departamento de contabilidad
y el director del proyecto.
De mayor importancia se citan, dentro de los
costes externos los llamados costes de oportunidad
que se refieren a:
Clientes que no vuelven a contratar como consecuencia de la accin directa y negativa de algn
actor.
Clientes que hubieran contratado y no lo han
hecho por haber recibido deficientes referencias de
otros clientes.
Respecto a los primeros, su conocimiento es inmediato cuando se constata que el cliente contrata a
la competencia en igualdad de condiciones sin dar, siquiera, opcin a concursar. Previsiblemente una conversacin directa con l puede ratificar la sospecha.
El segundo caso, esto es, los clientes que no contratan por recibir referencias negativas, resulta ms
difcil de conocer; pero un seguimiento cuidadoso de
cmo ha ido el proceso de adjudicacin y con una o
varias conversaciones posteriores de algn directivo
de la ingeniera con la persona adecuada del cliente,
se puede llegar a saber.
Segn Peugeot, un cliente satisfecho equivale a

la obtencin de 7 clientes nuevos; en cambio un
cliente insatisfecho puede provocar la prdida de 25

clientes. En compaas de servicios, estas cifras varan pero se puede estimar que los costes de captacin de nuevos clientes que sustituyan a los que se
han perdido son del orden de 5 veces superiores que
el coste de mantener a los existentes mediante la
prestacin de unos buenos servicios, y por otra parte, un cliente satisfecho puede originar 3 clientes
nuevos amn de que vuelvan a contratar a la primera ocasin de que disponga.
Se cita a continuacin la conocida regla del 1-10100.
Costes de prevencin
Costes de evaluacin
10
Costes de la no calidad
100
(UA defectuosa)
Fig. 3.6 Regla del 1-10-100
De acuerdo con este esquema, cada unidad monetaria invertida en prevencin, producira los mismos efectos que 10 invertidas en la evaluacin que
impediran un coste de 100 por razn de fallos. Por
lo tanto, resulta ms rentable actuar con medidas
preventivas y de inspeccin y evaluacin que no hacerlo.
3.3 Intangibilidad
Uno de los inconvenientes que se produce en un
mercado imperfecto (el de la proyectacin es uno de
ellos) cuando se disea con baja calidad, es que en
muchos casos sta no se llega a percibir de forma inmediata o directa. El no tener cercano un elemento
de comparacin (por ejemplo no est cercana la
competencia, no hay exceso de demanda, no est el
cliente educado para una aproximacin prxima de
lo que es mejor,) hace que el efecto positivo o negativo sea intangible a corto plazo.
NO ELEMENTO
COMPARACIN
RESULTADO
MEDIO/LARGO
PLAZO
MENORES EXIGENCIAS
FINAL IRREMEDIABLE
SIN POSIBILIDAD DE REACCIN
Fig. 3.7 Esquema de la Intangibilidad de la calidad
DE
DIRECTIVOS
DE
RESTO
EQUIPO
COSTE
DE
CALIDAD
- Prevencin
- Evaluacin
Este hecho puede provocar una insensibilizacin

del proyectista y una relajacin en los sistemas de
control del gestor, que provoca:
Menor exigencia en sus sistemas de control.
Menor exigencia en la formacin propia.
Menor exigencia en la incorporacin de tcnicos preparados.
Por lo tanto, hay que huir de la necesidad de una
mejora de la calidad del proceso por la peticin de
los clientes, que, por otra parte, independientemente
de la intangibilidad, muchas veces no avisan cuando
las cosas no van, en su opinin, bien. Simplemente
actan, dejando al gestor o al proyectista sin capacidad de reaccin. En definitiva, hay que programar en
calidad pensando que, su intangibilidad puede estar
cegando la visin de unas consecuencias desagradables de una mala gestin.
3.4 Universalidad
INSENSIBILIZACIN
ACTITUD
69
Ya se mencion cuando se trat las caractersticas de

la actitud. No se puede conseguir una mejora de la
calidad en el diseo de una UA si no se produce un
consenso general de toda la organizacin, y ese es
uno de los grandes objetivos que justifican la accin
del gestor, que se preocupa de que todos los actores
se sientan implicados para que la meta comn sea la
tan manida calidad total (CT).
La complejidad genrica de la proyectacin hace
que sea relativamente fcil y probable la aparicin
del error que puede motivar el desencadenamiento
de situaciones no deseadas. Son, ordinariamente,
INTANGIBILIDAD
DE NO
CALIDAD
- Internos
- Externos
A CORTO:
(intangible)
A LARGO:
(no avisa)
Fig. 3.8 Las cuatro caractersticas de la calidad
UNIVERSALIDAD
MUCHOS
PUNTOS
ERROR
MUCHOS
IMPLICADOS
70
muchas las fases de prestacin del servicio o muchas

las unidades en las que se descompone (decenas de
planos, informes, memorias, anlisis, construccin,
contrataciones, retroalimentaciones,). Todo ello
hace que las medidas que deben adoptarse para conseguir una calidadglobal, tengan que estar soportadas no por elementos aislados de la organizacin, sino por todo su conjunto, y en todas las fases de
desarrollo del proceso.
Estos comentarios anteriores resultan en la prctica casi imposibles de cumplir, ya que el gestor debe intentar conseguir esa universalidad haciendo
partcipes a diferentes actores, que en sus estrategias
no tienen por qu tener identificada la calidad como
elemento definidor de sus acciones: algunos esperan
solamente hacer negocio; otros cumplir con lo estipulado en su contrato; otros buscan su encumbramiento,..Pero, en todo caso, ese es el reto y quizs
sa es la justificacin de la existencia del gestor que
intenta aunar intereses que, en algunos momentos,
son abiertamente contrapuestos.
En el cuadro que a continuacin se muestra, se menciona lo que para Nolan, Norton & Co. es y no es la CT.
El concepto cero defectos que justifica, en parte,
la adopcin de la calidad total como objetivo resulta
obviamente matizado cuando lo que se presta, adems,
es un Servicio como es el de la GPU, ya que en este
caso resulta imposible cuantificar todos los defectos.
Pero tambin por esta razn, resulta ms apremiante el hecho que se involucre a toda la organizacin (en-
tendiendo como tal a los ya mencionados actores que

pueden estar bajo su control o susceptibles de ser gestionados: diseadores, colaboradores, ayudantes, suministradores, usuarios, cliente,). Es por eso que si
el proyecto no lo contempla, debe, a travs de procedimientos, relacionar y coordinar a todos ellos.
4 Valor y percepcin de la calidad

Se vuelve aqu, a los orgenes del tema. No se puede
disociar en la gestin de proyecto, la tecnologa aplicada con su diseo especfico, del servicio que se
transmite. En ese sentido se constata que el cliente
percibe siempre, por parte del proyectista y del gestor, la UA y, por otro, un conjunto de intangibles que
conforman el servicio.
En ese sentido resulta importante hacer un buen
tratamiento del entorno que conforma esa percepcin por parte del cliente. As, es obligacin fundamental por parte del gestor del proyecto y de los directivos de la compaa de ingeniera que presta el
servicio, atender a dos planteamientos en origen: las
expectativas previas y la percepcin del servicio.
4.1 Las expectativas previas

Aparecen ya en la fase de contratacin de la GPU, y
ms concretamente en la oferta de servicios y es que,
ES
NO ES
Una filosofa de direccin
Un programa nuevo
Una concepcin rupturista
El camino de siempre
Un enfoque estructurado y orientado

a la identificacin y solucin de problemas
Fuegos de artificio
Consistente en acciones directivas
Consistente en eslganes
Liderado por la direccin
Responsabilidad de todos
A largo plazo
A corto plazo
Soportado por el control estadstico de

calidad y otras herramientas
Dirigido por el control estadstico de

calidad y otras herramientas
Adoptado por todos
Delegado
Fig. 3.9 Qu es y qu no es la calidad segn N.N.& Co.
con el nimo de conseguir el contrato de la gestin,

resulta tentador ofrecer algunos que, en realidad,
despus resultar difcil realizar.
En ese proceso de contratacin, el cliente llega
en la mayora de los casos a convencerse de que realmente recibir los servicios que se le aseguran; por
lo tanto se generan unas expectativas con las que
despus se medir el grado de cumplimiento del servicio comprometido.
La habilidad del gestor ha de ser la de transmitir
con claridad la lnea de lo que va a hacer posteriormente y que ello sea lo que, al satisfacer al cliente,
haga decantar al mismo por su propuesta de servicio.
Se trata, por tanto, de que el punto de partida de ambos sea el mismo. As, al final no habr discrepancias
ni dudas sobre la bondad o no de un buen servicio.
71
A partir de una definicin de lo que espera recibir el cliente, hay que tener en cuenta que las expectativas generadas no son necesariamente inalterables. Pueden ser objeto de variacin producida por
cambios en el sistema (FH, UA, ambiente) o por modificaciones de la frontera. Esta modificacin de expectativas puede llevarla a cabo el propio cliente con
lo cual, el gestor, debe ser lo suficientemente hbil
como para captarla y acomodarla al servicio a aplicar. Tambin pueden producirse por cambios en los
resultados que se vayan obteniendo a causa de la
gestin del proyecto (responsabilidad del gestor). En
todo caso cuando el cambio se produce, hay que hacer una buena gestin de las evidencias.
4.2 Percepcin del servicio. La gestin

de las evidencias
COSTE
PLAZOS
EXPECTATIVAS
PREVIAS
de
CONTENIDO
SISTEMA DE
ACTUACIN
INICIALES
MODIFICACIONES
EN GESTIN
Fig. 3.10 Las expectativas previas en la calidad
Han de quedar definidos, por ejemplo:

Coste:
El cliente debe saber con exactitud cules son los honorarios (contrapartida de
la prestacin), as como los orgenes y
causas de una posible modificacin.
Plazos:
El inicio y final de la actuacin de la
GPU. Las etapas intermedias, si es que
hace falta, y los condicionantes para su
cumplimiento.
Contenido: La UA a gestionar ha de ser definida de
una manera muy concreta o muy vaga,
pero con las fronteras bien definidas,
de forma, que lo que espera recibir el
cliente sea lo mismo que lo que el gestor le ha dicho le va gestionar.
Sistema de
actuacin: La metodologa que se utilizar para la
consecucin de los fines debe quedar
explcita as como los roles de los diferentes actores.
La actividad de la proyectacin no ha de contemplarse como un flujo unvoco. Esto es, que el tcnico
disea (proyectista) y el cliente recibe el objeto diseado.
Es un proceso ms complejo por el cual la UA ha
de contener en s misma todo un resumen de relaciones diseador-cliente que van ms all de las cualidades funcionales o estticas que pueda producir la
UA y que sern aceptadas o no por su receptor.
En este ltimo sentido se orienta el contenido de
este apartado. A lo largo del proceso de gestacin
de la UA, el cliente ir percibiendo todo un cmulo
de sensaciones, propuestas, justificaciones, actitudes, que al final ayudan a delimitar las fronteras y el
contenido de aqulla. Eso quiere decir que, de una u
otra manera, todos juegan un papel de actor en el
proceso y se establece una relacin biunvoca que
condiciona la bondad del servicio. No interesa tanto
el valor de la UA en s misma, sino el valor que le da
el que la recibe, y lo que tiene que tener claro el diseador es que gran parte de esa valoracin depende
de como l vaya planteando al perceptor, los frutos
de su ingenio.
A partir de ah, hay que estar muy pendiente de
conocer qu y cmo valora el perceptor, para no caer
en el espacio vaco de disear algo que no se quiere.
A lo largo del proceso de diseo, el cliente, poco
o mucho, lanza mensajes de aquello que est percibiendo, viendo o recibiendo. El diseador, absorto
72
en muchos casos en su propio diseo puede no estar

en constante sintona con los mensajes del cliente, y
ha de ser (en la mayora de los casos) el gestor quien
cubra esa funcin mediadora y quien deba hacer una
buena gestin de las evidencias que enderece las
desviaciones, no tan slo propias sino tambin las
del propio diseador.
Uno de los servicios que con ms relevancia
ofrece una GPU al cliente para convecerle de que va
realizar una buena gestin del proceso, es el control
del plazo de ejecucin. Para ello pone a disposicin
del proyecto los ms sofisticados programas informticos que, combinando variables, permiten ver lo
que est sucediendo desde varios puntos de vista.
Lo cierto es que excepto en proyectos complejos
(una central nuclear o una planta petroqumica por
ejemplo), estos programas resultan (a menudo) excesivamente farragosos para ser manejados en su
amplitud y con todas sus posibilidades. Por otra parte la presentacin de los resultados no siempre suele
ser lo suficientemente clara y perceptible o, si se
quiere, lo suficientemente sencilla como para que el
perceptor no tenga que hacer un curso acelerado para entender la informacin que se le quiere transmitir.
Con todo ello, en proyectos sencillos, no es ni
necesario ni aconsejable utilizar programas informticos complicados y posiblemente con los habituales
de tratamientos de textos se puedan confeccionarse
grficos, resmenes etc., que den una visin clara de
la situacin y ayuden a decidir lo que se puede hacer
en cada momento para corregir desviaciones.
Pues bien, cuando ocurre esa situacin hay que
convencer al cliente de que lo que se le prometi no
es necesario cumplirlo y de que posiblemente sea
improcedente hacerlo. Las expectativas que se le generaron al principio por la promesa de la aplicacin
de una tcnica sofisticada y de gran alcance para
controlar, mejor que otros, su proyecto, deben ser reconducidas para que la percepcin que ahora tenga
no sea de que la tcnica de gestin, que se le est
aplicando, est desfasada en el tiempo y es de baja
calidad. Al contrario, hay que ir por la va de demostrar que se est aplicando una tcnica ad hoc, gil,
comprensible y eficaz.
Las actuaciones que debe llevar a cabo la GPU
para hacer una buena gestin de las evidencias tal
que no haya menoscabo en el grado de percepcin
que del servicio vaya teniendo el cliente, han de

comprender, no slo las que responden a desviaciones de su propia incumbencia sino, en muchos casos,
como ya se dijo anteriormente, las que corresponden
a otros actores, fundamentalmente al diseador. Ello
hace ms complicado y, sobre todo, ms delicado, su
trabajo. Se relacionan a continuacin algunas de las
sugerencias que se deben tener en cuenta.
Diligencia: es la resolucin con prontitud de las
expectativas generadas por peticiones del Cliente o
por propuestas propias.
La laxitud en el cumplimiento de los acuerdos
con el cliente o a sus peticiones conforma un marco
agresivo a la recepcin posterior de cualquier mensaje. Ello ocurre cuando el cliente se encuentra ante
una falta de diligencia por parte del gestor. En ese
momento, se promueve en el ambiente un estado de
nimo proclive a la duda, a la aspereza, intolerancia
o a la incomprensin. Resulta normal encontrar casos en que malos proyectos son defendidos esplndidamente por gestores diligentes y, por contra, buenos proyectos son examinados con lupa y criticados,
en exceso, cuando son gestionados por tcnicos perezosos y en general poco diligentes.
Por otro lado, echarle la culpa sistemticamente
al diseador es un arma de doble filo. Primero porque, posiblemente, haya sido elegido por el propio
cliente y ser de su confianza; segundo porque el
gestor ha debido, a travs de la gestin del diseo
(GD), controlar la bondad del mismo, que aunque no
haya sido completamente (hacerlo as, sera como
repetir el proyecto), y por lo tanto se transforma en
casi corresponsable del mismo; y tercero porque una
de las caractersticas de la accin del gestor es la de
conciliador de voluntades, y naturalmente una actitud de enfrentamiento resulta nefasta para los intereses del cliente.
Un planteamiento similar podramos hacer si hablramos del corporificador. La responsabilidad del
gestor, es tal, que recoger los fracasos o los xitos
de todos los actores.
La autoestima: consiste en valorar el propio trabajo y darle el tono que se merece, exigiendo, a la
vez, su reconocimiento y respeto.
El cliente, mientras recibe una UA o la gestin
que sobre ella se realiza, percibe no slo sus efectos
inmediatos (funcionalidad, esttica) sino el cmo y
la forma en que se presenta. La nitidez de un diseo,
INFORMES
ACTITUDES
CONSIDERACIONES
Y
ACTITUDES
PERCEPCIN
CLIENTE
ACCIONES
UA
73
GESTIN
DE
LAS
EVIDENCIAS
- DILIGENCIA
- AUTOESTIMA
- ANSIEDAD
- QUEJAS
- til
- restitucin
defic.
- restitucin
confianza
MENSAJES
Fig. 3.11 Esquema general de la gestin de las evidencias
por ejemplo, no implica una simplicidad carente de

ingenio. La grandeza del proyecto va insoslayablemente unida al sentido comn que a menudo se confunde con una falta de rigor. No se trata aqu de aadir
una parafernalia que enmascare esa falta de ingenio,
pero si darse a uno mismo el valor que se merece.
La subvaloracin que por sencilla (que no simple) se da en algunas ocasiones al propio trabajo, hace que el usuario (cliente) perciba que le estn ofreciendo algo carente del valor que l cree que debe
tener. La subvaloracin del propio trabajo provoca
un doble efecto negativo: a) el usuario llega a considerar que la UA es fruto de un trabajo poco riguroso;
y b) el usuario se considera menospreciado.
El resultado de una inexistente autoestima puede
traducirse en una indiferencia o en la aparicin de un
sentimiento de duda por parte del cliente de la capacidad de quien le est gestionando el proceso, o de
quien est proyectando la UA.
Todo lo contrario: una autoestima razonable, que
no grotesca, puede hacer ver al receptor de la UA
que est en manos de alguien que valora su propio
trabajo lo suficiente como para confiar que lo que
desarrolla ser proporcional a la estimacin por lo
que est haciendo y cmo lo est haciendo.
Evitar la ansiedad: hay clientes que se interesan
por la marcha del proceso y hay otros a los que slo
les interesa conocer cul es el producto final. El caso
que nos ocupa se refiere a los primeros.
Muchos proyectistas son reacios a hacer partcipe al cliente de la marcha de los trabajos. Piensan
que les pueden entorpecer el proceso de diseo: si
se ha confiado en ellos, pues que les dejen hacer. Y
ante este principio, prefieren no informarle excesivamente hasta que no tengan configurada la solucin.
Esta actitud, suele ser poco recomendable si el

cliente es de los que se mencionaban al principio, de
aquellos que quieren saber qu es lo que se les est
proyectando. La sensacin de ansiedad ante la desinformacin puede generar un clima poco propicio a
un buen entendimiento, lo que predispone a la aparicin de una actitud agresiva cuando se preste a recibir el resultado del proceso de diseo.
El gestor, nuevamente, debe ofrecer sus buenos
oficios para limar la aspereza y servir de cauce de
comunicacin entre diseador y cliente. Efectivamente, el gestor conoce el proceso de proyectacin y
entiende las supuestas interferencias que no desea
el diseador se produzcan por una presin incontrolada del cliente. Tambin conoce lo que quiere el
cliente, sus objetivos y su ansiedad al no saber lo que
se est cociendo. Por lo tanto, entendiendo a ambos y teniendo su confianza, le resulta fcil establecer un sistema de comunicacin en la que l hace
muchas veces de intermediario, que evita ese estado
de ansiedad que ya hemos dicho es indeseable.
Las Quejas: la generacin de una UA es un proceso del todo imperfecto por la imposibilidad, casi
inevitable, del conocimiento y/o utilizacin de todos
los datos de entrada que intervienen o son susceptibles de ser tenidos en cuenta. Ello hace que se produzcan situaciones que crean conflictos entre proyectista, cliente y gestor, y fundamentalmente entre
los dos primeros. Una consecuencia de ello es la
aparicin, en el recipientario, de una sensacin de
que hay algo que no se est haciendo como l cree
que debera hacerse, y a partir de aqu ha de salir de
forma natural la queja.
Y hay que tener en cuenta que si, pasado un cierto tiempo desde el inicio de un proyecto, se constata
74
que el cliente no ha emitido ninguna queja, ello no

quiere decir en absoluto que se est en el buen camino. Tambin es probable que ocurra lo siguiente:
El cliente no se est enterando de lo que se est proyectando.
El cliente no ha cogido la suficiente confianza
como para emitir una queja amistosa.
En el primero de los casos la situacin es peligrosa ya que se corre el peligro de que se est proyectando algo no deseado por el receptor de la UA,
lo cual hace complicada la postura del proyectista y
del gestor. En realidad no se sabe si al final ser
aceptado el diseo de la UA.
En el segundo caso se confirmar el hecho de
que no ha habido una buena conexin entre el cliente
y el proyectista, lo que descalificar por otra parte
la actuacin del gestor. Y si, pasado el tiempo, el
cliente necesita que alguien le proyecte otra UA y no
vuelve a solicitar los servicios de alguno de los dos
tcnicos o de los dos, stos no entendern porque no
se les ha vuelto a llamar dado que las cosas fueron
tan bien la primera vez pues no recibieron ninguna
queja. La realidad es que no consiguieron conectar
suficientemente con el cliente y ste no les cogi
ninguna confianza.
En cualquier caso si se llega producir una situacin potencialmente capaz de generar una queja, el
gestor debe facilitar que se produzca sin que el asunto pase de ah, para ello hace falta que el cliente perciba:
a) Que la queja es til: se puede llegar a entender
que existan deficiencias en el diseo o que el servicio en general no sea el adecuado para satisfacer las inquietudes del que lo recibe. El espritu
de comprensin y aceptacin de las personas es
ms del que uno se imagina, pero en cambio resulta autnticamente desmoralizador el que se sepa que no hay posibilidad alguna de que la queja,
la protesta, llegue a ningn fin positivo. Esa sensacin de impotencia provoca a su vez un rechazo
general de todo el proceso y de la percepcin que
del servicio se tiene.
a) Ante una queja del receptor del diseo, se ha de
actuar de forma inmediata estudiando y reconsiderando las actuaciones que se estn llevando a
cabo para recomponer la situacin.
b) Se restituye la deficiencia: si despus de emitida
la queja y asumida la deficiencia en la tecnologa
o en el servicio, no se modifica el curso de los

acontecimientos y se cambia de forma clara, difana y sobre todo rpida, la sensacin de impotencia por parte del cliente seguir dominando la situacin. Se ha de ver de forma fsica, y con
actitudes, que la gestin se ha cambiado y se regresa al punto de partida volviendo a apuntar en la
lnea correcta.
lvaro Real, director en Catalua de SOMI,

compaa de ingeniera espaola de nivel internacional, estaba dialogando con Jorge De Buendia, director general de Gases Criognicos S. A. GCSA,
compaa alemana que posea una planta de produccin en un polgono industrial de Tarragona.
Era una de las conversaciones que habitualmente tenan, en la que hablaban de todo un poco: situacin
econmica del pas, nuevos avances en los procesos
industriales y, claro est, de los planes de inversin
de GCSA. lvaro y Jorge se entendan bastante bien
y SOMI era la ingeniera ordinaria de la empresa
alemana.
Dentro de un par de aos deca Jorge, haremos una nueva planta. Espero que me propongas como ingeniero director del proyecto a Joan Sala: es
un excelente tcnico y para lo que pensamos hacer
necesitamos los mejores tcnicos vuestros.
Por supuesto asegur Alvaro, pero espero
que hasta entonces podamos hacer otras cosas juntos
La conversacin haba empezado y termin
igual: hablando de las familias; por cierto, la de
Jorge tena que trasladarse a Tarragona ya que las
oficinas centrales en Barcelona se mudaban para ir
junto a donde estaban las plantas de produccin.
Era la nueva poltica de GCSA.
No pasaron tres meses y lvaro recibi una llamada desde Tarragona de Vicen Sendra, director
tcnico de CGSA, en la que le solicitaba una oferta
para el proyecto y la direccin de unas instalaciones
de un nuevo compresor de produccin de aire que
estaban comprando. Vicen era hombre de pocas
palabras y el mejor conocedor de la planta de produccin de gases.
En ese momento, SOMI tena bastante trabajo.
Todos sus ingenieros estaban muy ocupados pero,
como es lgico, a GCSA haba que atenderle siem-
pre. El proyecto no era muy importante as que

lvaro decidi encargar el proyecto a un joven ingeniero que se haba incorporado haca un ao en rgimen de eventualidad, por 3 aos, que era el lmite
marcado por la legislacin laboral.
Con el paso de las semanas, el joven ingeniero,
iba informando a lvaro del avance del proyecto,
que con algunas deficiencias, propias de la inexperiencia, parece que iba hacia adelante. Pero al cabo
de 2 meses al ingeniero le sali un empleo estable y
decidi marcharse de SOMI.
Para cubrir su baja en GCSA, lvaro encarg la
continuacin del proyecto a Manuel Carrasco, un
ingeniero senior de 59 aos experto en instalaciones
y fundamentalmente en climatizacin, que justo en
aquellos momentos tena poco trabajo.
Pasadas algunas semanas de trabajo, Manuel hizo algunos comentarios a lvaro acerca de que el
director tcnico, Vicen Sendra, era difcil de tratar.
lvaro le insista en que era importante entenderse
con su cliente y apel a su experiencia para terminar el encargo satisfactoriamente.
Sin embargo, alertado por ese comentario, lvaro fue a ver al director tcnico y ste le transmiti
que haban habido algunas disfunciones con el cambio de personas Temas que ya se haban hablado
con el primer ingeniero (que, recalc, tena poca experiencia) haba que repetirlas ahora con Manuel
Carrasco. Adems entenda que no se hacan las cosas con la suficiente celeridad.
De vuelta a la oficina, lvaro tuvo varias conversaciones con Manuel para tratar de enderezar el
asunto. Volvi apelar a su experiencia, y ste le asegur que tratara de cambiar el rumbo de los acontecimientos, pero, asegur que toda la culpa la tena
el propio Vicen, ya que ni l mismo saba lo que
quera.
A las pocas semanas se termin el trabajo.
Pasados unos meses de terminada la colaboracin con GCSA, lvaro telefone a Jorge para preguntarle acerca del proyecto de la nueva planta que
tiempo antes le haba comentado. Jorge en tono grave le dijo que ya la haban contratado a otra ingeniera. lvaro se quedo mudo y pidi verle para hablar con ms detenimiento.
Una semana despus en las oficinas de CGSA se
produjo esta conversacin:
No he tenido ms remedio que tomar la deci-
75
sin que conoces. asegur Jorge Vicen me dijo

que haba quedado muy descontento con vuestro ltimo trabajo y que no quera colaborar con vosotros
en este proyecto que era mucho ms comprometido.
Y, como puedes suponer, no puedo ponerme en contra de lo que opinen mis tcnicos.
No tena la menor idea de que Vicen estuviera
tan disgustado se extra Alvaro Ni siquiera
nos habis pedido oferta estoy desolado
Lo siento, pero debais haber tenido ms cuidado y estar ms atentos a cmo estabais haciendo
las cosas. Es muy comprensible lo del cambio de
personas, pero nosotros no somos responsables de
ello. Adems es algo con lo que hay que contar y no
por ello se ha resentir el trabajo.
Es frustrante se lament lvaro. Hemos estado durante varios aos trabajando para vosotros
haciendo cosas pequeas, y el da en que, por fin,
hay que acometer un proyecto importante, viene otro
y se lo lleva y ni nos enteramos
Tambin lo siento yo respondi Jorge. Y el
caso es que vosotros erais nuestra ingeniera. Ni
siquiera pedamos ofertas a otras compaas
Siempre confibamos en vosotros. Pero vuestra ltima actuacin lo ha cambiado todo. Ahora deber
pasar algn tiempo para que volvamos a confiar. Te
sugiero que dejes pasar 8 o 9 meses y luego ya volveremos hablar
Te parece oportuno que vaya a hablar con Vicen? pregunt Alvaro.
Por supuesto, pero espera un tiempo.
c) Restablecer la confianza en la seguridad: en un

proceso de prdida de sintona entre cliente y proyectista o entre cliente y gestor, la emisin de una
queja puede no llegar ni siquiera a producirse si se
percibe una falta de seguridad en la resolucin del
problema por parte del recipientario. Se prefiere,
en ese caso, obviar la queja y en todo caso, acudir
a otras fuentes que merezcan ms confianza.
Por un lado, por tanto, el cliente puede percibir
que el proyectista o el gestor ponen obstculos a la
solucin de la queja, y por otro, puede tener la conviccin de que a pesar de que se diga que se va a
cambiar, previsiblemente no se asumir con la suficiente credibilidad como para asegurar, de forma
clara, que se seguir una lnea de progreso y positi-
76
vismo. En ese caso, el cliente lo que hace es no quejarse o hacerlo de forma inamistosa y agria. El resultado final suele ser muy negativo para el gestor.
El gestor, en cambio, ha de transmitir siempre
una sensacin de seguridad en todo lo que hace y dice, y ello no est reido con la flexibilidad, sino con
la incompetencia. Un diseador o un gestor capaces
de transmitir confianza y seguridad tienen, tambin,
asegurado un buen final de su tarea.
Ante un error, se ha de restablecer nuevamente la
confianza desde la seguridad de que se est en disposicin de afrontar el cambio y los nuevos compromisos. Ese restablecimiento, por otra parte, debe ser inmediato. El tiempo, aqu, juega muy en contra del
causante del error. Se puede asegurar que en muchos
casos, es una cuestin de horas. La rapidez en la correccin ayuda enormemente a establecer ese marco
de seguridad que devolver la confianza.
4.3 Valor del servicio

Se valora de forma diferente por parte de la empresa
gestora o por el cliente. Este ltimo relaciona lo que
l considera que es la calidad que se le ofrece y el
precio que paga por ello.
Expectativas previas + Percepcin del servicio = Valor del Servicio
Precio + Otros costos
La frmula es vlida tanto para el proyectista como para el gestor. En el caso del gestor, como ya se
ha indicado, resulta algo ms complicado porque en
las expectativas y en la percepcin se suman, subliminalmente, las que proporciona la GPU con las del
proyectista.
El precio es el importe econmico que el cliente
abona al gestor por su trabajo; y el trmino otros
costos engloba aquellos que son externos al gestor,
pero son directamente necesarios para la obtencin
de la UA en condiciones aceptables y complementarios al costo del diseador o del gestor. Es el caso de
controles extra de calidad, reparaciones, sobreprecios por errores, consultores externos en general,
etc. Y es que ocurre, algunas veces, que el cliente se
ve obligado a contratar otros servicios paralelos a los
del gestor y el proyectista o simplemente a hacer desembolsos no previstos, porque es la nica forma,
supuesta, que le da a l seguridad de que se acabe el

proceso de forma satisfactoria.
El gestor, analiza de forma diferente el valor del
servicio que est desarrollando: calcula el margen
que ha obtenido y lo relaciona con la inversin que
ha tenido que hacer. Un clculo ms realista aade a
esta relacin, un factor de repeticin que indica el
nmero de veces (frecuencia de uso) que, debido a la
influencia de los buenos resultados conseguidos,
vuelve a ser contratado el gestor por el mismo o por
otros clientes.
Margen Frecuencia de uso
Inversin
La obtencin de un encargo para gestionar requiere, por lo general, cinco veces ms esfuerzo que
repetir con un cliente conocido. Eso quiere decir que
la principal fuente de encargos para una ingeniera
son los clientes en activo.
Es mucho ms rentable repetir encargos con un
mismo cliente aunque sea con menor margen, que
intentar conseguir otro diferente y nuevo. Como es
lgico esto no quiere decir que haya que prescindir
del intento de obtener nuevos clientes. Todo lo contrario. Es necesario disponer de una cartera variada,
lo que da ms seguridad a la continuidad de cualquier empresa (esta es una teora general comnmente aceptada). Lo que se quiere decir es que hay
que cuidar mucho a los clientes en activo porque son
parte fundamental en la garanta de estabilidad.
5 Contenido de la calidad
Las especiales caractersticas y valoraciones atribuidas a la calidad en la proyectacin, hacen que el contenido de la misma encierre a la vez tres sumandos:
tecnologa y diseo, ausencia de errores y buena
gestin.
5.1 Tecnologa y diseo

Se trata de aplicar la tecnologa y el diseo adecuados para cada caso con la mira puesta permanentemente en el progreso.
Como se ve, hemos incluido en el mismo paquete la tecnologa y el diseo TD. Es un intento de
impedir que la mejora en los conocimientos que permiten el progreso, sea independiente del aspecto formal que, entendemos, debe conjugar la esttica con
la funcionalidad.
El divorcio que durante muchos aos ha habido

entre ambos T y D, ha causado con frecuencia tambin un divorcio entre profesionales con formaciones
regladas diferentes que parecan, no tan slo olvidarse de uno de los dos sumandos, sino incluso despreciarlo. As por ejemplo, los ingenieros tradicionalmente dicen no tener demasiado en cuenta el diseo,
en beneficio de la funcionalidad y en general de la
tecnologa. En cambio, muchos arquitectos pueden
incluso obviar intencionadamente los aspectos ms
tcnicos, en beneficio de la esttica. A partir de aqu,
tambin existen numerosos profesionales tanto ingenieros como arquitectos que son muy conocidos,
precisamente por tener a gala el proyectar teniendo
en cuenta ambos conceptos. Aunque lo ms comn es
que el trabajo est repartido entre profesionales diferentes y de lo que se trata es de trabajen juntos.
Un ejemplo de lo que se est diciendo arriba es
la famosa Torre de Comunicaciones de Barcelona,
construida al socaire de los JJOO del 92, bautizada
posteriormente como Torre de Collserola. El proyecto recay en el conocido arquitecto ingls Norman
Foster que fue el ganador de un concurso internacional entre diferentes arquitectos de fama mundial.
Su diseo y propuesta funcional, en general, fueron
las ms aceptadas por el jurado.
Una vez realizado el proyecto constructivo, se
procedi por la empresa pblica encargada de la
gestin del proceso, Torre de Collserola S.A., a realizar un concurso entre diferentes constructoras. Como el proyecto era de gran envergadura, no slo por
su montante econmico, sino tambin por la singularidad del proceso de construccin que debera realizarse, se presentaron al concurso las compaas
ms importantes del sector. El contrato recay en C
y MZOV.
Pues bien, la oferta consista, no solo en una
componente econmica sino tambin en una propuesta de construccin de la torre que inclua
significativas modificaciones en el diseo original,
77
para hacerlo ms constructivo. Los cambios fueron introducidos por un ingeniero contratado para
la ocasin por la empresa constructora que, respetando el diseo, trataba de introducir las componentes tcnicas necesarias para hacer viable la UA.
La obra se termin con xito, y hoy es una de los
smbolos ms emblemticos y visibles de la Barcelona postolmpica.
En todo caso, la separacin drstica de funciones, tecnolgicas y de diseo, es un error. La base de

la que han de partir ambas es la misma: el progreso y
este implica a ambos, as que no deben ir disociadas
ni debe acometerse una olvidndose de la otra.
Claro est que para conseguir esto es necesario
no solamente cambiar mentalidades, sino incluso
modificar los aspectos troncales en algunas carreras
tcnicas que hacen posible que la formacin de algunos profesionales permita la existencia de visiones
divergentes del arte de la proyectacin.
Conviene comentar tambin que decir que hay
que aplicar una TD adecuada no debe suponer una
patente de corso para seguir utilizando sistemas tradicionales de proyectar con la excusa de la seguridad, y
de que se utilizan los que ya han sido suficientemente
probados. El tcnico tiene la inexcusable obligacin
de mejorar lo que ya sabe o lo que ya dispone, as como la de investigar continuamente con el horizonte
claro de que de lo que se trata es de disear o construir una UA (la ms til desde todos los puntos de
vista) para el usuario.
Lo dicho anteriormente no es bice para que en
muchos casos sea conveniente aplicar procedimientos
tradicionales de diseo, o diseos y componentes tradicionales. Pero ni la moda ni el continuismo deben
nublar la mente de un buen diseador, que debe pensar
exclusivamente en prestar el mejor servicio al usuario,
no en su propia complacencia ni en su pereza.
Para controlar estos extremos, la labor del gestor
vendr sustentada fundamentalmente por lo que llamamos la gestin del diseo (GD) y la gestin de la
calidad (GC), velando porque, sobre la base de las
caractersticas y el estilo del proyectista, previamente admitidos por el cliente, se est proyectando con
la TD adecuada, que cumpla, adems, los objetivos
marcados por el cliente. Y como ya se desarrollar
en captulos posteriores habr que atender a la ido-
78
TECNOLOGA
TD
DISEO
AUSENCIA
ERRORES
GESTIN
OPERACIN
CALIDAD
PRODUCTO
Fig. 3.12 Sumandos que integran la calidad del producto
neidad de las hiptesis, a la constructibilidad, a la

composicin esttica, etc.
5.2 Ausencia de errores

La proyectacin y la consecuente corporificacin
son unas de las actividades que ms fcilmente pueden generar errores por dos razones fundamentales:
una porque son unas actividades con gran influencia
de la persona humana, y otra porque suelen intervenir un gran nmero de ellas.
La masiva maquinacin (ordenadores) ha hecho
disminuir notablemente el nmero de errores, pero
sigue persistiendo en gran medida la actuacin humana, complementada por los ordenadores.
Por otra parte, en los proyectos complejos se requiere la actuacin de especialistas que aseguren ese
nivel tecnolgico sealado anteriormente y ello hace
necesario una buena coordinacin que ayude a alejar
el peligro de la aparicin de errores.
Para evitar la aparicin de errores se requiere un
compromiso global por parte de todos. Es decir, no
se trata de que el tcnico responsable del diseo haga una campaa particular para eliminarlos. Toda la
cadena de desarrollo de la UA debe asumir su cuota
de responsabilidad (calidad total) y todos deben evitar el mnimo error. Slo cuando se consiga esto, podr decirse que se empieza a dar calidad.
La ausencia de errores significa tambin que no
debe permitirse, bajo ningn concepto, que salga un
documento del centro de trabajo con el mnimo
error. Todo lo que se entregue estar bien: nada se
puede disculpar. Y eso, lgicamente, es una labor
autnticamente universal de toda la organizacin.
Aqu, por lo tanto, hay una labor de convencimiento
y comunin de todas las personas en los ideales y
formas de trabajo.
El gestor, sin embargo, debe cuidar de diferenciar aquellos documentos que elabora por s mismo:
informes, ensayos, anlisis, etc., con los que controla por parte del proyectista o corporificador. Aquellos deben ser asumidos en su integridad pues su responsabilidad es total, en cambio stos ltimos lo
sern en la medida y proporcin del compromiso adquirido, del tipo de control a realizar y de su profundidad.
Para el control del diseo del Museo de Arte Moderno de la ciudad de Miers, los tcnicos de la ingeniera SISTEMAS DE INGENIERIA S.A., y dentro
del anlisis de los clculos de la estructura de la cubierta, procedieron a revisar una de las vigas de
hormign. Eran piezas de gran canto de entre 1 y
2,5 m. de altura e iban apoyadas por pilares, tambin de hormign, con luces variables que podan
llegar a los 25 m. Se eligi una de las ms comprometidas, revisndose a fondo punto por punto: hiptesis, clculos, memoria, especificaciones, mediciones, planos,..
De su detallado anlisis se pudo comprobar la
bondad del trabajo realizado por el prestigioso arquitecto responsable del proyecto, Francisco Tras
de Wurtz, que a su vez haba delegado el clculo de
la estructura de la cubierta en una ingeniera local.
A partir de ah, se comprob, de forma general, si el
resto de las vigas mostraban magnitudes comparables. Como as fue, se dio por bueno el conjunto de
esa parte del proyecto.
El proceso de proyecto y revisin se fue haciendo de forma continuada, analizndose algunos temas al cien por cien y otros de forma aleatoria o segn la importancia de la partida o el asunto. En
todo caso, lo que no se quera era volver a hacer o
recalcular era el proyecto en su integridad, pues
ello hubiera hecho inviable la propia contratacin
de la GPU. A medida que se iba proyectando, la
GPU iba estudiando las propuestas de Tras de
Wurtz y as fueron corrigindose algunas de ellas y
confirmndose otras. Al cabo de unos 10 meses de

trabajo el proyecto se dio por terminado y sali a
concurso pblico.
El concurso fue ganado por Procesos de Construccin S.A., empresa lder en el sector, con una
facturacin que rondaba los 2.500 Meuros anuales.
Tres semanas antes de que debiera iniciarse el
izado de las grandes vigas de cubierta, la constructora anunci que haba repasado el proyecto de todas ellas, sin excepcin y haba detectado que haban cuatro a las que le faltaba hierro para armar.
Ninguna de ellas coincida con la testada por la
GPU. Pidi un incremento de precio de 125.000 euros y aprovech la oportunidad para solicitar al
ayuntamiento un plus econmico de 32.000 euros
por recalcular las vigas.
5.3 Gestin de la operacin

As como la ausencia de errores es un sumando que
requiere el consenso absoluto del equipo, ste a que
ahora nos referimos depende fundamentalmente del
director del proyecto para el equipo de diseo, y
del gestor de la GPU para el conjunto en general de
todos los actores que intervienen.
Para una buena gestin de la operacin, esto es,
para que el diseo y/o corporificacin de la UA se
lleve con xito, se requiere, ante todo, que el gestor,
79
por un lado, conozca bien lo que el usuario necesita

para poder transmitirlo con certeza al proyectista y,
por otro, que su liderazgo (en trminos de coordinacin) sobre el resto de actores sea asumido con naturalidad y sin reticencias. Para ello, el gestor debe
transmitir la suficiente confianza en sus conocimientos y en capacidad de gestin, de forma que su intervencin se vea siempre como un apoyo, ms que como un control, aunque lgicamente ste es un
aspecto que, ineludiblemente, debe hacerse patente
en algunas fases del proceso.
El gestor utilizar las FI (funciones instrumento)
para desarrollar las FN (funciones ncleo), como
elementos bsicos que garanticen su buena actuacin. Y en todo caso resaltamos, respecto del usuario, que debe conocer con precisin:
Las funciones y parmetros que se requieren de
la UA
El servicio que ha de producir (fiabilidad, duracin, disponibilidad,..)
El plazo previsto
El coste deseado
Las condiciones en la relacin
La misin del recipientario
Todo ello alimenta los datos para que el gestor
promueva la estrategia necesaria para que se produzca la seguridad en el funcionamiento del servicio
que probabilsticamente se considere ptima. La estrategia quedar definida en los trminos indicados
en el captulo anterior.
PROYECTISTA
Pedidos
PROVEEDORES
HOMOLOGADOS
SISTEMA CALIDAD
PROYECTISTA
Plan de calidad
Medidas correctoras
GPU
PLAN
CALIDAD
UA
SISTEMA CALIDAD
INGENIERA
CLIENTE
Medidas correctoras
Plan de calidad
CORPORIFICACIN
PROVEEDORES
HOMOLOGADOS
SISTEMA CALIDAD
CONTRATISTA
Pedidos
PROVEEDORES
HOMOLOGADOS
Fig. 3.13 Esquema general de un plan de calidad y los actores que intervienen
80
6 Aseguramiento de la calidad
Una vez asumido por la GPU el objetivo de conseguir trabajar con calidad en las condiciones mencionadas en los prrafos anteriores, el camino lleva a
desarrollar un plan de aseguramiento de la calidad
(PAC) que permita la certeza de que se van a realizar
todas las acciones que consigan hacer una buena
gestin y obtener una ausencia de errores.
En todo caso, en este captulo se van a exponer
las generalidades y principio bsicos del PAC para
dejar a uno posterior, el detalle de las acciones concretas a travs de las FN, que hemos denominado
gestin de la calidad (GC).
En ese sentido convendra recordar primero la
definicin que sobre el aseguramiento de la calidad
concreta la UNE-6001:
conjunto de acciones planificadas y sistemticas que
son necesarias para proporcionar
la confianza adecuada
de que un producto o servicio satisfaga los requisitos
dados sobre la calidad.
Y sobre el plan para el aseguramiento de la calidad, recordaremos el esquema adjunto enunciado
por la UNE-66001:
DEFINICIN
FILOSOFA
La estructura organizativa, las Documentos descriptivos

responsabilidades, los procesos
y los recursos necesarios para
llevar a cabo la gestin de la
Implantacin
calidad.
PARA CADA ACCIN

Prevenir las improvisaciones
Verificar los resultados
Guardar pruebas escritas
En el inicio de las actuaciones, la GPU debera

recabar primero el conocimiento de los sistemas y
planes de calidad que los otros actores tienen establecidos para la gestin de la UA, con objeto de inte-
grarlos en lo posible con en el suyo y llevar a cabo

una accin ms eficiente.
A partir de aqu se est en disposicin de redactar el plan de calidad.
6.1. Plan de calidad

La norma 66001, que ilustra el vocabulario a emplear, lo define como: Documento que recoge las formas de operar, los recursos y la secuencia de actividades ligadas a la calidad, que se refieren a un
determinado producto, servicio, contrato o proyecto.
Responden a un deseo especfico de asegurar la
calidad en un proyecto concreto, bien por peticin
del propio cliente o bien por conviccin de la GPU.
Ordinariamente se basar en el PAC de la ingeniera
que lleva a cabo la gestin, complementndolo con
los planes de calidad que tengan otros actores en el
proceso.
El contenido del plan reflejar:
Los objetivos a alcanzar.
Las responsabilidades concretas de cada persona.
Programas de inspeccin, ensayo, examen y
auditoras en todas las etapas de diseo y/o construccin.
Procedimientos e instrucciones a aplicar (MPR).
Procedimiento para cambiar el plan (MPR).
La elaboracin se sugiere que sea hecha por
personas con experiencia y que responda todo el
documento a propuestas prcticas y asumibles. Si
un plan, a medida que transcurre el tiempo sufre olvidos o resulta difcil de mantener, habr representado un esfuerzo baldo y crear frustracin entre
sus redactores y menosprecio en quienes lo deben
asumir.
Empresas y organizaciones en la sociedad de hoy
81
4. El equipo de gestin de un PU y el pensamiento sistmico
Proyectistas
D
ire
c
fa
ul
ta
amar
a
tiv
Organ
izar
ca
ifi
Contr
EQUIPO
CLIENTE
GESTOR
M
ot
in
ist
ro
en
g
er
r
iva
ola
ntr
Co
Se
rvi
cio
s
p
bli
cos
atista
Su
mi
nis
tro
s
cc
Progr
an
Pl
El equipo de una GPU guarda muchas similitudes con

el equipo de realizacin de un proyecto. De hecho, casi todas las especialidades tcnicas que hay en ste, se
repiten en la gestin del mismo. Prcticamente slo se
excluye el equipo de representacin grfica.
Y es lgico, ya que si se trata de gestionar el proyecto y la ejecucin de una serie de disciplinas tcnicas, ya se puede comprender que los tcnicos asignados para el control han de ser, como mnimo, de
un nivel parecido al de los que han debido proyectar.
En todo caso, se requiere de ellos probablemente
mayor capacidad para atender un espectro ms amplio
de asuntos, mayor poder de abstraccin y sntesis, y
siempre un gran sentido comn, que permita ordenar,
controlar, planificar, programar y coordinar, e incluso
auditar, un trabajo, y esto ltimo, sin tener que repetirlo. Ya se ve que ello implica la necesidad, tambin, de
disponer de una solida formacin, por un lado y, por
otro utilizar tcnicas especficas que lo hagan posible.
Resulta muy prximo a la idea de lo que es un
gestor, lo que David H. Maister comenta en su libro
True professionalism, sobre su concepcin de lo que
es un profesional: Dice exactamente que a real professional is a technician who cares. Se podra parafrasear, en nuestro caso que: un gestor es un profesional que se cuida de todo. Y con matizaciones no
va desencaminada esta sentencia, aunque somos ms
partidarios de enunciar que: un gestor es el profesional que soluciona los conflictos.
Tambin, en general, se desprende la necesidad
de disponer de un equipo que no busque la confrontacin y s el encuentro. Sus actuaciones siempre
han de venir mediatizadas por el hecho de estar con-
trolando a un conjunto de profesionales que han sido

escogidos porque su capacidad ha pasado la prueba
de una seleccin lgica. Son, por tanto, los ms idneos para el cliente, que por cierto es el mismo que
el de la GPU. As que resulta conveniente que su actuacin se vea siempre, ms como un apoyo y soporte que como un control. Y sobre todo debe actuar de
impulsor de medidas y actitudes que favorezcan la
consecucin de los objetivos del cliente.
Tambin deber intentar controlar o al menos influir en las actuaciones de otros actores, en principio
ajenos a la misin proyectual, como son las autoridades pblicas, las empresas de servicios, etc., sobre
los que, adems, no se tiene ninguna influencia directa, pero que la suya, en el proyecto, s que puede
ser importante, y en ocasiones trascendental. El ritmo y carcter de la visin que se tiene de la GPU depender, sin duda, del talante y capacidades tcticas
del gestor designado como director del encargo.
Su
1 El equipo gestor
Fig. 4.1 Universo de la gestin
82
1.1 Definicin del equipo gestor

No siempre se solicita a una GPU las mismas funciones ni con la misma intensidad. Aqu la flexibilidad de las compaas consultoras es bastante elevada
y el mismo tipo de gestin tambin lo es. Ello quiere
decir que segn la UA a gestionar y las necesidades
del cliente, el equipo puede variar.
Tambin suele ser corriente que el equipo sea
mixto, con personas del cliente y otras de la consultora para cubrir las deficiencias o vacos tcnicos
que aqul tenga.
El 31 de enero de 1994, las chispas de un equipo

de soldadura que se estaba utilizando en unos trabajos en el escenario del Gran Teatro del Liceo de
Barcelona, causaron un incendio que destruy la totalidad del edificio, dejando un rastro de ruinas que
conmocion al mundo entero.
El Teatro del Liceo era conocido como uno de
los ms famosos centros opersticos del mundo. Un
cantante lrico no se senta plenamente realizado si
no llegaba a cantar en ste impresionante escenario
al que asista un pblico adicto y fervoroso que tena el teatro como algo suyo y lo asuma como consustancial con el paisaje cultural y tambin urbano
de las Ramblas el paseo ciudadano barcelons ms
famoso, donde se encontraba ubicado.
El espectculo era dantesco y el sentimiento de
frustracin de muchos barceloneses al ver desaparecer de forma catastrfica uno de los signos de identidad de la ciudad, sembr el desconcierto y el desnimo.
Inmediatamente las autoridades catalanas recibieron muestras de apoyo y solidaridad que venan
de todas partes el mundo y muy especialmente del
mundo de la cultura. Y tambin, inmediatamente se
procedi a elaborar un plan que permitiera la reapertura del teatro en el tiempo ms corto posible.
Se puede decir que el inters general, compartido por todos, de proceder a la reconstruccin inmediata pudo ms que el cmulo de dificultades iniciales y de planteamiento que configuraban el marco de
origen. Efectivamente, haba muchos tcnicos que
opinaban que deba reconstruirse en otro lugar;
otros opinaban lo contrario. Haba quienes pensaban que deba hacerse con una arquitectura moder-
na; otros que deba conservarse el estilo original. Y,

sin nimo de agotar la lista de dificultades, haba
quienes pensaban que deba modificarse la estructura de propiedad del futuro teatro. Tampoco hay que
despreciar el hecho que las decisiones sobre todo
ello pasaban porque se pusieran de acuerdo cuatro
administraciones pblicas gobernadas por partidos
polticos diferentes, amn de los propietarios particulares que con sus aportaciones iniciales permitieron en su da su construccin. La decisin que marc de forma definitiva todas las actuaciones fue la
de que el teatro fuera inaugurado en 1999.
El rgano de gestin principal era el Consorcio
del Teatre del Liceu, del que se derivaban un consejo ejecutivo y un consejo tcnico. La direccin general corra a cargo de Josep Caminal y se encomend
al ingeniero Ernest Serra la Direccin Ejecutiva de
la reconstruccin, lo que de hecho le supona asumir
la misin inherente al gestor director ejecutivo del
encargo que lideraba la GPU.
El proyecto y la direccin facultativa de la reconstruccin recay en el arquitecto Ignasi Sol
Morales que form un equipo con diferentes especialistas: en estructuras, en instalaciones, arquitectos tcnicos, etc. Recibi el encargo de manos del
consejo ejecutivo.
Para gestionar el proyecto y las obras en su vertiente tcnica, Ernest Serra form un equipo que tena como base a la compaa de ingeniera y consultora IDOM que proporcionaba la asistencia tcnica
a las labores de:
GD (gestin del diseo), GAPROV (gestin de
aprovisionamiento), GCOR (gestin de la corporificacin), GCL (gestin de la calidad), GPL
(gestin del plazo), GC (gestin del coste) y la
GR (gestin del riesgo). IDOM destin para ello
a un equipo que estaba liderado por un arquitecto/ingeniero que desarrollaba acciones de direccin tcnica, adjunto al director ejecutivo y que
controlaba las de otros especialistas en las reas
de estructuras y geotecnia. El propio director
tcnico supervisaba las instalaciones y la arquitectura.
Para completar la GCOR, se contrat a un arquitecto tcnico, y para la GPF a la empresa
EGI, que llevaba la planificacin al da.
Eventualmente la GPU se nutri de especialistas
que asesoraban a la direccin ejecutiva de forma
El equipo de gestin de un PU y el pensamiento sistmico
puntual. Este equipo se complementaba con el soporte administrativo necesario.

La inversin prevista en la construccin era de
unos 106,2 Meuros y la previsin de su inauguracin era a partir de la primavera de 1999, en funcin de los intereses de programacin.
Conocidas las necesidades del cliente se trata de

definir, por tanto, el equipo necesario para llevar a
cabo la misin proyectual encomendada.
La definicin podr hacerse utilizando el esquema de las funciones ncleo FN que sern las reas
de actuacin que tendr que abordar el equipo, que
utilizar unos instrumentos FI, lo que ayudar a
concretar los tcnicos necesarios.
1.1.1 Composicin del equipo gestor

El nmero de personas involucradas en la gestin es
poco representativo del volumen de trabajo, ya que
es recomendable disponer de un equipo reducido pero permanente, que asuma el contenido global del
proyecto y se mantenga hasta el final del proceso.
Sin embargo pueden intervenir muchos especialistas
en diferentes momentos (en la GD, por ejemplo) que
despus de realizar la actividad que tienen asignada
no vuelven a intervenir ms o a hacerlo de forma
muy selectiva y corta.
83
En funcin de las FN a llevar a cabo y de la importancia del proyecto se requerir un equipo ms o

menos numeroso. Incluso en proyectos pequeos, algunas funciones y actividades pueden ser realizadas
por las mismas personas, mientras que en otros proyectos deben ser realizadas por personas distintas
pues la cantidad de trabajo as lo aconseja. De todas
formas, genricamente se considera que deben existir los siguientes puestos: gestor, tcnico ayudante,
tcnicos en planificacin y costes, tcnicos especialistas en diferentes materias, tcnicos en mediciones
y presupuestos y tcnicos de administracin y secretara.
Tradicionalmente se ha dicho que en el desarrollo de los proyectos, la figura clave era el director del
proyecto. Eso es indudable y probablemente en la
gestin de un proyecto de carcter nico GPU
ocurre igual con la figura del gestor. En l descansa
todo el edificio en el que se sustenta la gestin.
Existe, sin embargo, en la GPU una funcin de liderazgo an mayor que en la direccin del proyecto,
por cuanto aqu el director deja en manos de los especialistas algunos de los asuntos que l no domina un
calculista de estructuras, por ejemplo, puede condicionar la labor de diseo del director del proyecto.
En cambio el gestor imprime un carcter muy personal de cmo y cunto se debe controlar, planificar,
organizar y dirigir un proyecto. Incluso los especialistas de la GPU, que controlan a los que realizan el
proyecto, necesitan del liderazgo del gestor.
CLIENTE
Necesita de
la GPU
P l a n i fi c a r
Programar
Coordinar
Controlar
M o t iva r
FUNCIONES
Sobre
Diseo
Calidad
Plazo
M. ambiente
Otros objetivos
Coste
Licencias
Riesgos
Corporificacin
REAS
ACTUACIN
Con
Planificacin
Procedimiento
Recursos y org.
I. Valor
I. Simultnea
I N S T RU M E N T O S
Conforman
Fig. 4.2 Esquema global actuacin GPU
EQUIPO
ASIGNADO
84
PERSONAS
ACTIVIDAD
- GESTOR
Planificacin
Programacin
Coordinacin
Control
Motivacin
Representacin
- TCNICO GESTOR AYUDANTE
Planificacin
Programacin
Organizacin
Control
- TCNICO PLANIFICACIN Y
COSTES
Mantenimiento planificacin
Preparac. doc. cont. costes
Valores previsionales
- TCNICOS ESPECIALISTAS
Rev. proyectos
Control corporificacin
Control certificaciones
Control suministros
Control calidad
Control seguridad
Control medio ambiente
- TCN. MEDI. Y PRESUPUESTOS
Rev. mediciones
Rev. precios
Rev. certificaciones
- ADMON. Y SECRETARA
Administracin documentos
Fig. 4.3 Funciones del equipo GPU
Sin embargo no se pretende restar importancia al

labor del resto del equipo. Sin desear siquiera iniciar
el tema, vale asegurar en forma rotunda, que la labor,
por ejemplo del tcnico especialista en mediciones y
presupuesto es clave en una GPU. En efecto, uno de
los errores ms comunes en un proyecto se produce
en las mediciones y por tanto una de las labores ms
trascendentes de una buena auditora de proyecto y
la GPU la efecta en la GD es asegurar que la medicin es la que corresponde y, si no lo es, hay que
encontrar la real antes de que sea demasiado tarde.
En todo caso creemos ms oportuno, a la hora de
analizar el equipo gestor, dentro del contexto de este
libro que pretende dar una visin general sobre la
GPU, prestar especial atencin al gestor, dejando el
anlisis de las caractersticas del resto del equipo para
otros tratados ms concretos en aspectos de detalle.
1.2 Funciones del gestor de una GPU

El gestor resume en sus funciones todas las caractersticas que acoge una GPU. No excluye prctica-
mente ninguna y aunque algunas las ejecuta de forma

ms o menos elemental o sencilla, no por ello deja de
asumirlas como un conjunto, haciendo as abstraccin del propio concepto sistmico que del proyecto
se tiene que tener. Se definirn a continuacin estas
funciones, dejando el desarrollo concreto de las actividades para cuando en captulos posteriores se
acometa el anlisis de las FN. Las funciones que lleva a cabo un gestor son bsica y fundamentalmente:
planificacin, programacin, coordinacin, control,
motivacin y representacin.
1.2.1 Planificacin
Es probablemente la funcin ms importante que tiene que hacer un gestor. Muchos proyectos desembocan en un fracaso por la precipitacin en su inicio o
por la creencia que sobre la marcha se arreglan las
cosas. Otros fracasan porque una vez realizada la
planificacin inicial sta queda, exclusivamente, como referencia lejana y formal de lo que deba haber
sido. Existe un dicho entre los profesionales que
conviven en el mundo proyectual, que dice que: los

planes estn para que no se cumplan. Y este desidertum es el que el gestor debe romper.
La planificacin es el establecimiento de unas
actividades, recursos y estrategias que, debidamente
priorizados, interrelacionados y ordenados en el
tiempo, hacen que se produzcan unos acontecimientos o evitan que se produzcan otros nocivos para la
obtencin de unos objetivos (otra definicin ms tcnica y su relacin con la programacin se comentarn ms adelante).
Y es que errar es ms fcil que acertar, as que
tomar las precauciones para salvar esa mayor dificultad resulta, no slo conveniente, sino prudente.
En 1980 el departamento de justicia de un gobierno de una regin europea sac a concurso las
obras de un establecimiento penitenciario. La inversin prevista era de 38 Meuros. El proyecto haba sido encomendado a los arquitectos Ben Moure y
Amele Iuges de Saira quienes desarrollaron un modelo de crcel con fuerte contenido formal al uso del
estilo de diseo imperante en la poca en esa regin.
El departamento de justicia, a travs de su Secretaria General Tcnica Magda Laer, contrat para controlar el proceso los servicios de la compaa
consultora IASA, ingeniera especializada en project
management que deba apoyar a los tcnicos del departamento en el control de las diferentes fases de
desarrollo de los trabajos: proyecto, concurso pblico y obras de construccin.
Las obras fueron adjudicadas a la empresa OCG,
Obras y Contratas Generales S.A., con una baja sobre el presupuesto de proyecto de un 35%, e inmediatamente IASA se reuni con OCG para ajustar los detalles de la planificacin que debera cumplirse. Se
contrastaron las ideas que afectaban, sobre todo, a
elementos que se influenciaban entre s (cimentaciones con estructuras, instalaciones con cielos rasos,
) y otros que tenan que ver con el entorno (suministro
de gas con puesta en marcha de las cocinas, carretera
ms prxima con vial de entrada, etc.). Se estudiaron
con ms detalle aquellas actividades que se consideraban crticas para el cumplimiento del plazo final.
Se lleg, en todo caso a un consenso que respetaba la
fecha contractual, y se iniciaron las obras.
A la semana de la adjudicacin, OCG present
85
un proyecto alternativo al de los arquitectos que, sin

variar el aspecto formal, propona gran cantidad de
variantes constructivas y de calidades de los materiales. El precio se mantena en su integridad y el
plazo tambin.
El nuevo proyecto fue analizado en profundidad
por IASA y se desestim en su mayor parte ya que
introduca numerosas variantes que iban en detrimento de la calidad y la seguridad, por lo que los
trabajos se iniciaron respetando el proyecto original.
Dos meses despus de iniciadas las obras, los
responsables directos de ellas por parte de OCG,
iniciaron una campaa de insinuaciones y comentarios sobre los ruinosos resultados econmicos que
para su empresa iba produciendo la obra y que el
departamento deba de permitir que se subieran algunos precios. De hecho, a los seis meses presentaron un modificacin al alza del presupuesto inicial
por importe de 3,1 Meuros.
IASA, representando al departamento de justicia, llev a cabo el mayor peso en las mltiples reuniones que se tuvieron para analizar y discutir las
razones y las cifras que motivaban tal peticin. Despus de un ltimo informe por parte de la ingeniera, el departamento de justicia decidi no admitir
ningn aumento pues estimaba que era injustificado.
Ante tal decisin, OCG paraliz de facto las
obras por espacio de seis meses, que reanud previo
pago por parte del departamento de una prima de
310.000 euros. Las obras acabaron tambin 8 meses
ms tarde de lo previsto. El coste final sufri, adems, algunas modificaciones al alza, por cambios en
el proyecto y aumentos en las mediciones que supusieron alrededor de los 300.000 euros ms.
Para planificar adecuadamente es muy recomendable hacerlo basndose en una concepcin sistmica del conflicto (idea o problema) a resolver. Para
ello se tiene que tener en cuenta que:
a) La resolucin del conflicto consecucin de todos
los objetivos tiene que ser contemplada de forma
global, relacionando en todo momento el sistema
con su entorno.
b) Se tiene que segmentar el conjunto sistemaentorno en subsistemas capaces de ser analizados de
forma individualizada.
86
c) Hay que sintetizar todos los subsistemas y relacionarlos entre s, ya que cada uno por s solo no
se justifica si no es por que contribuyen a la consecucin de objetivos comunes.
d) Los sistemas sobre los que ordinariamente acta
un gestor son fundamentalmente abiertos y activos. Eso quiere decir que la planificacin ha de
responder a ello, convirtindose en una funcin
en permanente cambio.
Llegados a este punto conviene reflexionar brevemente sobre unos cuantos principios bsicos de la
teora de sistemas, cuya terminologa y consecuencias estamos utilizando en estos primeros captulos,
y de manera muy especfica en el anlisis de la funcin de la planificacin. Estos comentarios pueden
ayudar a terminar de poner en situacin al lector.
Introduccin a la teora de sistemas
Se entiende como sistema un ente formado por diferentes elementos de distintas naturaleza, cantidad
o composicin que se relacionan entre s, se definen
entre unas fronteras y se encuadran en un entorno.
Todo ello de conforma en un conjunto que globalmente puede ser perfectamente diferenciado de
otros. El conjunto as formado es distinto de los elementos que lo componen.
Cuando se plantea un determinado conflicto, la
forma de resolverlo proporciona, sin duda, la oportunidad de utilizar metodologas muy diversas, que tienen que ver, la mayora de las veces, con la cultura
de quien decide resolverlo o en donde se plantea el
mismo.
Uno de los procedimientos cientficos ms recomendables es el que utiliza la teora de los sistemas y
que con ms asiduidad se conoce como el proceso
sistmico. Su uso proporciona instrumentos y objetos
de anlisis con una gran cobertura y espectro en la
definicin del conflicto y con un mtodo muy racional que permite abordarlo con gran amplitud. El proceso sistmico para acometer la gestin de proyectos,
tiene la ventaja de que siempre tiene presente el objetivo final a cumplir, y a la vez permite un anlisis diferenciado de los componentes. As se entiende, por
ejemplo, que la oportunidad en el establecimiento de
determinadas actividades que formen parte de una
planificacin venga justificada cuando teleolgicamente coincidan sus objetivos y slo en ese caso.
Planteamiento bsico de un sistema.

En teora proyectual, cuando se pretende resolver un
conflicto, hay que plantearse la metodologa sistmica de la forma ms til para obtener el mejor de los
resultados. Y ello nos conduce a planteamientos diferentes en origen.
El enfoque ms general consiste en desagregar el
sistema a travs de los elementos que lo forman. Las
caractersticas de los elementos que componen un
sistema se pueden sintetizar en:
Cada elemento con ser independiente repercute
o es repercutido por algn otro
Cada elemento se justifica por cuanto es til
para el resultado final (teleologa)
Cada elemento puede a su vez generar otro sistema subsistema
Cada elemento o subsistema tiene propiedades
diferentes de las del sistema que lo engloba
ENTORNO
ALREDEDORES
FRONTERAS
SISTEMA
ELEMENTOS
ALREDEDORES
Fig. 4.4 Esquema general de un sistema
El entorno es el marco en donde se implanta el

sistema
La frontera marca los lmites de actuacin del
sistema
Los alrededores son los aledaos de influencia
del y al sistema
Los elementos son los componentes que integran el sistema
El sistema unidad de actuacin (UA) factor humano
(FH) ambiente (AMB).
Es el sistema bsico que permite analizar los tres
elementos primigenios que se relacionan con la aparicin de un conflicto por resolver en su fase ms
elemental.
ENTORNO
ALREDEDORES
UA
FH
AMB
FRONTERAS
Fig. 4.5 Esquema sistema UA-FH-AMB
a) La UA es el elemento mas o menos corpreo

que ha de acoger, en s, la solucin al conflicto planteado. Para su definicin conviene tener presente
que: (Los artefactos y sus proyectos-J.Blasco)
Exigencia
Fa
ct
or
an
m
hu
Funcionamiento
na o recibe. Su inclusin como elemento de composicin primordial en el sistema arroja unas enormes posibilidades de investigacin para una correcta y completa solucin al conflicto. Entre ellas,
el que corresponde al anlisis de los deseos o al
anlisis del usuario que se producen en la fase de
concepcin. Este ltimo, por ejemplo, suele ser el
gran olvidado de los procesos proyectuales, y en el
mejor de los casos lo que se produce es una limitacin a la hora de conocer todos los usuarios posibles. En realidad suelen estudiarse slo los ms importantes y a duras penas. Prima ms el resultado
final, sin apreciar con profundidad para quin ha
de ser ese resultado.
Pautas
Entradas
Salidas
87
El usuario de la planta de regeneracin de disolventes de Valls Qumica S.A. puede ser mltiple: el
jefe de mantenimiento, el jefe de produccin, el director de planta, el transportista que se lleva el residuo slido a la planta de incineracin, el analista
del departamento de medio ambiente de la administracin que controla los efluentes, o el transportista
que entrega la materia prima.
Instrucciones
Informacin
Fig. 4.6 Condicionantes de actuacin en la resolucin

de un conflicto
Su comportamiento est predeterminado por su

composicin interna
Su funcionamiento se regula por leyes
Su vida es limitada
La interfase FH-UA es muy importante
Algunas de sus cualidades ms importantes dependen de su coste econmico.
Una UA puede ser la planta de fabricacin de

polietileno de Repsol en Tarragona, el programa de
gestin del municipio de Madrid, la grabacin del
ltimo disco compacto de Oasis, el nuevo Palacio de
Congresos de Valencia o el macroconcierto de los
Tres Tenores en el Camp Nou de Barcelona.
b) El factor humano (FH) es el destinatario de

la UA. Es el que la usa, controla, proyecta, gestio-
Utilizar, por tanto, este modelo sistmico, proporciona una visin muy detallada del problema,
que ayuda a situarlo en sus justos trminos.
En todo caso, para el anlisis sobre el factor humano, hay que tener en cuenta lo siguiente:
La mudabilidad de sus valores, criterios o juicios dan lugar a comportamientos errticos
Es flexible y adaptable
Es, por su propia naturaleza, limitado y relativamente frgil
c) El ambiente AMB, es el medio donde el
factor humano (persona) gestiona y/o usa la UA, y
supone un mundo fsico, social y econmico, sobre
el que hay que tener en cuenta, entre otras consideraciones, las siguientes:
El medio evoluciona y presenta fluctuaciones
El propio FH y la UA supeditan su variabilidad
y lo alteran
El medio, al oponerse al FH y a la UA con leyes fsicas, qumicas, biolgicas y sociales, les degrada o envejece.
88
El sistema tridimensional de Hall.

Es, a nuestro entender, un anlisis complementario
del anterior y que nace del subsistema formado a partir del elemento UA. En efecto, aqu Arthur D. Hall
propone un planteamiento para el proceso proyectual
que est basado en la desagregacin de la propia UA
en otro sistema, y sobre ella reflexiona en tres dimensiones que ayudan a concebirla: la dimensin temporal, la lgica y la del rea del conocimiento.
La dimensin temporal, atiende a la bsqueda de
la UA que resuelve el conflicto, sobre la base de una
secuenciacin del proceso por fases que se producen
por razn exclusivamente de su concatenacin en el
tiempo. (As lo explica J.M. Aguinaga en La morfologa tridimensional de Hall).
En nuestro caso, si se adapta todo ello a la estricticidad de los proyectos de carcter nico (PU), las
fases seran las siguientes:
1. Planificacin del programa
2. Diseo preliminar
3. Desarrollo del diseo
4. Corporificacin
5. Puesta en marcha
6. Funcionamiento
7. Desmantelamiento
La dimensin lgica, considera el proceso como
un conjunto de consecuencias y causalidades que
atienden a la razn, desligndolo de las apariencias
sensibles, y en cambio profundiza en las causas que
hacen que unos sucesos repercutan en otros o deban
ser su consecuencia o fundamento. Exige, por tanto,
esta dimensin, un anlisis profundo que invita a no
caer en la tentacin de la frivolidad recubierta de supuesta agilidad. Desde estas premisas las fases seran las siguientes:
1. Definicin del conflicto
2. Adopcin de objetivos y criterios de valoracin de soluciones
3. Exploracin de soluciones posibles
4. Perfilar las soluciones existentes
5. Optimizacin de las soluciones vlidas
6. Adopcin de las decisiones oportunas
7. Preparacin de las acciones a emprender
La dimensin del rea de los conocimientos invita a concretar cul de las reas del saber hay que utilizar en cada una de las diferentes fases en que nos
encontremos en las otras dos dimensiones. Hall las
clasifica en funcin del menor a mayor grado de abstraccin que se necesita a la hora de procedimentar
las actuaciones que de su utilizacin se derivan:
1. Ingeniera
2. Medicina
3. Arquitectura y arte
4. Empresa
5. Derecho
6. Direccin
7. Ciencias Sociales
Manejando estas tres dimensiones se logra analizar cada elemento de una forma desagregada lo que
permite profundizar en un grado suficientemente coherente. Aguinaga recoge en su escrito Aspectos sistmicos del proyecto el esquema que se conoce como
caja morfolgica de Hall, y que transcribimos aqu.
En la matriz tridimensional, el elemento S(2,3,3)
representa un estado de anlisis tal, que utilizando
criterios y bases arquitectnicas (3), se estn explorando soluciones (3) en la fase del diseo preliminar
(2). En cambio, el elemento S(4,6,5) suscita un estado en el que se analizan las repercusiones jurdicas
(5), y con ello se toman las decisiones oportunas en
ese mbito jurdico (6) cuando se est corporificando la UA (4). (Ver fig. 4.7).
El Grupo ASOR, AICRAG ODAGLED (AAOD)

era un grupo familiar que posea el 49% de las acciones de una empresa dedicada a la fabricacin de
componentes del automvil cuyo centro fabril principal se encontraba en la localidad catalana de
Montorns del Valls. Las oficinas y su segundo centro estaban situados en los lmites de la ciudad de
Barcelona con St. Adri del Valls.
El otro 51% de propiedad estaba en manos de
una multinacional italiana con fbricas en diferentes puntos de Europa.
La fbrica de Montorns del Valls estaba situada en una parcela propiedad del Grupo AAOD.
En 1992, tras un ao de resultados muy comprometidos (definicin del conflicto), iniciaron un proceso de reestructuracin que tena dos ejes fundamentales: la disminucin de costes y la mejora de la
plantilla para adaptarla a las nuevas exigencias del
mercado (exploracin de soluciones).
La disminucin de costes exiga un reagrupamiento de sus procesos productivos (ingeniera) as
Definicin objetivos
Adop. objetivos y C.V.S
Exploracin soluciones
Perfilar soluciones exis.
Adopcin decisiones op.
Preparacin acciones a emp.
89
Planificacin programa
Diseo preliminar
Desarrollo diseo
Ingeniera
Corporificacin
Medicina
Arquitectura y arte
Puesta en marcha
Funcionamiento
Empresa
Desmantelamiento
Derecho
Direccin
Ciencias sociales
Fig. 4.7 Modelo morfolgico de Hall
como de sus ncleos de gestin (empresa). Eso representaba, al final, un traslado de las instalaciones
ms rentables de St Adri a Montorns. Las oficinas
de St. Adri se pondran a la venta o se remodelaran
par transformarlas en viviendas (arquitectura y derecho). Pero el reagrupamiento, forzaba a adquirir en
Montorns, una parcela lindante con la del Grupo
AAOD. Sin embargo, al ser dos parcelas diferentes,
no era posible tratarlas como una nica unidad. Haba que respetar el ordenamiento urbanstico: dejar
mrgenes sin construir en cada uno de los lindes, volumetra en funcin de cada una de las superficies,
etc. As que se inici un proceso de anlisis y
propuestas de modificacin del plan general de ordenacin urbanstica (arquitectura e ingeniera) que
contemplaba tambin la transformacin de dos propiedades diferenciadas en otra nica (derecho).
El proceso requiri planificar un programa (adopcin de objetivos) y unas bases de medida (criterios de
valoracin). Y la confianza que al grupo le fueron
dando los primeros pasos por serles positivos los resultados, permiti avanzar en la toma de decisiones,
contratando a INCISA, ingeniera que inici trabajos

concretos (perfilar soluciones existentes) e incluso
realiz el diseo preliminar de la nueva planta (UA).
Como se ve, el planteamiento proyectual resulta

mucho ms complejo, y sobre todo ms rico cuando
se ve desde una perspectiva sistmica. Y si a la vista
de un proyectista, el proyecto puede quedarse reducido a elementos muy concretos (realizar un diseo,
dirigir una obra,) para un gestor es muy distinto.
El gestor lo ve, adems que, desde el punto de vista
del diseo, desde otras pticas diferentes pero complementarias todas ellas, que le fuerzan a disponer
de conocimientos y experiencias que ordinariamente
el proyectista no aplica, porque no le interesa, no conoce o no se le solicitan.
Clasificacin de los sistemas.
Los sistemas conviene clasificarlos por su grado de
relacin con el entorno en abiertos o cerrados, y por
90
su mayor o menor grado de actividad en activos y

pasivos. As por ejemplo, los abiertos son aquellos
entre los que existe una movilidad de las variables
que los componen con un trasvase de influencias y
acciones entre sus elementos y el entorno. En ellos
las fronteras pueden llegar a ser difusas y los alrededores tienen una influencia que puede derivar en permanente.
Los sistemas activos son aquellos en que sus elementos cambian sus caractersticas por la movilidad
de las variables que los definen. Existen influencias
entre todos ellos y se puede actuar desde el exterior
y modificarlas mediante acciones concretas.
Los sistemas difcilmente se puede llegar a clasificar como completamente cerrados o completamente pasivos. En cambio s se puede afirmar que unos
son ms o menos pasivos o ms o menos cerrados. Y
darse cuenta de ello es importante para un gestor,
porque indudablemente si se es capaz de percibir en
profundidad el grado la actividad o apertura, se
habrn sentados las bases para hacer una planificacin realista. Precisamente uno de los errores detectados en el fracaso de una planificacin es el desconocimiento de las influencias de determinados
factores sobre otros.
Una planta de regeneracin de disolventes es un

sistema abierto y activo: a) la normativa (ejemplo
de entorno) cambia con el tiempo; b) segn el tipo
de producto a tratar (elemento), el tipo de destilacin (elemento) ser diferente. Los productos a tratar como pueden ser barnices o aceites (frontera)
pueden cambiar en el futuro. Lo mismo podramos
opinar de otros entornos: legislacin laboral, competencia,; otros elementos: contratistas, instalaciones mecnicas; otras fronteras: lmites fsicos
de la instalacin, grado de emisin de los efluentes, u otros alrededores: posibles cambios de legislacin europea, vas rpidas de relativa proximidad a los lindes fsicos,
Muchas veces, las influencias que motivan cambios en la planificacin responden tambin a influencias no slo de elementos internos al sistema
(un inadecuado diseo por ejemplo,) sino a otros
que se consideran exclusivamente de entorno (falta
de permisos, contratacin inadecuada, etc.). En ello

la metodologa sistmica ayuda a encontrar las races de los posibles problemas.
El pensamiento sistmico favorece la abstraccin creadora ya que no solo reduce los hechos a
una simple causa-efecto, sino que los engloba en un
conjunto, lo que permite situarse en un plano superior tal que, desde una reflexin intelectual global,
suministra armas de decisin que escapan a quien
acta exclusivamente resolviendo los problemas uno
a uno. Esa abstraccin permite llegar a intuir, incluso, que la solucin al conflicto planteado sea precisamente no resolverlo. Es decir, no admitir como dato de partida que existe ese conflicto a resolver,
porque: a) puede ser irresoluble, b) puede no existir
tal conflicto, c) puede no ser bueno para el cliente o
usuario el que se afronte y resuelva, o d) puede que
sea otro el conflicto que haya que resolver. En cualquier caso, el procedimiento se inicia con el propsito de resolver lo planteado, no para evitarlo.
1.2.2 La programacin
Es la funcin inmediatamente consecuente de la planificacin, ya que supone la definicin de las fechas
y las cargas en trminos de tiempos que las actividades planificadas deben aportar al proceso proyectual.
Si la planificacin se entiende que debe ser una
funcin viva y en continua revisin, programar encierra an ms incertidumbre en cuanto al aseguramiento de su fiel cumplimiento. La programacin
supone una prediccin con una apuesta sobre los
costes en tiempo y recursos de lo que otros tienen
que hacer y sobre los que no se dispone del control.
El proceso tanto de planificar como de programar se inicia en la definicin de la misin. Sin embargo los programas sobre los que al final se trabaja
son los que contractualmente se asumen por parte de
los proyectistas, suministradores y constructores.
Esos programas, nacen de un POG, programa de objetivos generales, que es elaborado por la GPU de
acuerdo con el cliente. Este programa responde a lo
que desea el cliente y respeta los contenidos de los
objetivos a cumplir.
Los programas contractuales PRC, provienen del
POG que marca los lmites, y son realizados normal-
91
Cliente
MISIN
Cliente
DEFINICIN OBJETIVOS
Cliente
PLANIFICACIN Y
RECUR. GENERALES
Gestor
PLANIFICACIN
Y
PROGRAMACIN
ACTIVIDADES
PLANIFICACIN
Y
PROGRAMACIN
SERVICIOS
PLANIFICACIN
Y
PROGRAMACIN
CORPORIFICACIN
Suministradores
y otros actores
Gestor
INTEGRACIN PROGRAMAS
Retroalimentacin
Fig. 4.8 Actividades que realizan los actores
mente por los propios suministradores y corporificadores ya que ellos conocen mejor que nadie sus propios recursos y las capacidades de los mismos, as
que los combinan de tal manera que permitan el
cumplimiento de sus contratos. Sin embargo el gestor no permanece neutral ante estas propuestas, sino
que las analiza y valida su posibilidad, en funcin de
s mismas y como consecuencia de su integracin
con el resto de entradas.
A partir de la integracin de toda la informacin
disponible, la GPU desarrolla un programa final que
consolida todos los dems y que seguir durante todo el proceso.
Como principio general habra que decir que la
programacin es tanto ms til cuanto:
Sea realista
Considere el mayor nmero de actividades o

hitos posibles que sean influyentes
Sea compartida por todas las partes
Sea fcil de elaborar y de realimentarse
Sea fcil e inequivocamente interpretable
Se mantenga al da
Tanto la funcin de planificar como la de programar requieren una gran experiencia por parte
del gestor que debe ser capaz de acertar en la bondad de la relacin de unas actividades o la asignacin de recursos tcnicos que al final determinan
unos tiempos de ejecucin de la UA. Se tratar por
tanto de acertar en cules (planificar) son
las actividades o hitos que hay que considerar y
cunto y cundo (programar) deben ocurrir
stas.
92
1.2.3 La coordinacin
Resulta la funcin, en la que junto a la de la motivacin, el gestor deja notar ms su impronta y liderazgo.
Se trata de conjugar los esfuerzos de todas las
partes implicadas para la consecucin de un fin comn aceptado por todos y fundamentalmente por el
cliente y usuarios.
La coordinacin es la que da sentido a unas acciones parciales que aparentemente son independientes y que sin aquella, podran ser contradictorias o ftiles.
Y para que las lgicas de actuacin de cada uno
de los actores sean congruentes, hay que mantener
un equilibrio en el sistema, que permita:
La utilizacin de las mismas bases de partida
para todo el mundo, que haga posible llegar a unas
soluciones parciales que conformen una unidad a
partir de unas partes (unidad teolgica).
Un funcionamiento ordenado del mercado
perfecto de las tareas. De tal manera que cada gru-
po de los que integran el conjunto de elementos

(contratistas, suministradores de equipos, proyectistas, cliente, usuarios, organismos pblicos vinculantes,) conozca todo lo que para ellos es interesante
o necesario de lo que estn haciendo el resto.
Una heurstica forma de hacer global, conocida y compartida por todas las partes, que sea compatible con las heursticas particulares de cada parte
y que sea capaz de conseguir los resultados apetecidos.
Si tuviramos que resaltar alguno de los aspectos
que matizan la labor de coordinacin que otros llaman, tambin, de organizacin, cabra mencionar
la adecuada asignacin de papeles y responsabilidades, y sobre todo el planteamiento de un sistema de
informacin y documentacin lo suficientemente
gil y libre de toda sospecha, que permita que todo
el mundo se sienta satisfecho de la informacin que
recibe.
Aqu, conviene comentar lo importante que resulta la informacin y la documentacin en una organizacin caracterizada por ser un sistema abierto
CONFLICTO
LGICA DE
RESOLUCIN
GLOBAL
INFORMACIN
MATRIZ DE
REPONSABILIDADES
LGICA
ACTOR 1
LGICA
ACTOR 2
LGICA
ACTOR 3
UA
Fig. 4.9 Esquema coordinacin lgica
93
DEFINICIN
ORGANIGRAMA
FUNCIONAL
Tareas
internas
DEFINICIN
PAUTA GENERAL
TODOS LOS
ACTORES
Relaciones
entre
actores
UA
+
DEFINICIN
PAUTA
PARTICULAR
MIEMBROS
GPU
Fig. 4.10 La coordinacin entre las tareas
y activo, como suelen ser la mayora de planteamientos que se encuentran en el mundo proyectual:
las personas suelen actuar casi siempre con criterios
propios germinados tras largas y profundas reflexiones hechas en el tiempo y que han conformado una
cultura que de forma subliminal est presente en todo lo que hacen. De hecho, cuando alguien acta de
una manera supuestamente espontnea no es tal: actuara igual si lo meditara mucho. Pues bien, en muchas ocasiones la informacin que recibe la persona
en cuestin, no cambia un pice su determinacin
para actuar en uno u otro sentido. Sin embargo se
siente marginada porque no dispone de ella, y su
comportamiento posterior resulta afectado por ese
sentimiento de marginacin, lo que hace que esa
pretendida unidad de acciones que se desea conseguir se ve seriamente afectada. Obvio resulta comentar que hay veces que la informacin resulta
esencial para acometer un determinado trabajo, por
lo que en ese caso es imprescindible informar so pena de obtener resultados negativos ms rpida o
contundentemente.
A mayor asuncin individual de responsabilidades, las personas por lo general desean estar ms
informadas, ya que como es lgico desean conocer
si lo que estn haciendo, que responsablemente de-
sean que sea til, se ver afectado o no por lo que

no est en sus manos conocer en el momento que se
produce, y por tanto necesitan que alguien se lo
transmita. Muchas de las incomprensiones entre las
personas son, a menudo, provocadas por una falta
de informacin o por una ausencia de sta. Y en un
proyecto, navegar en un mar de incomprensiones
genera una tormenta de desconfianzas, que complican enormemente la consecucin de los objetivos y,
por supuesto, hacen poco agradable el trabajo. Al
final, el hundimiento de alguien o de algo, est
garantizado. Es cuestin de tiempo. Tambin es
cierto que casi siempre se est a tiempo de rectificar.
Aqu la labor del gestor es fundamental, ya que
con toda probabilidad, ninguno de los actores va a
tener un inters especial en proceder a informar al
resto a menos que ello le suponga un beneficio claro.
Por lo tanto, no se trata de un problema simple de
sensibilidades, sino de autoresponsabilidad teleolgica en consecucin de un objetivo que no es slo de
uno y que en ocasiones ni tan slo le afecta directamente pero que es el motivo por el que se est dentro del proceso proyectual.
El gestor, por tanto, debe intentar que la informacin sea:
94
En lo posiblefluida y universal
Necesariamenterpida y veraz (incluido completa)
Y por ltimo, hay que sealar que toda informacin, si se quiere que sea til, ha de obtener una respuesta: informar sin ms puede salvar alguna que
otra responsabilidad, pero no resuelve un problema.
Y en el caso que nos ocupa, esta consideracin an es
ms provechosa. Pinsese que el gestor debe coordinar acciones de actores tan distintos como lo son una
administracin pblica y un contratista de unas
obras, por no citar ms que a dos. Si la informacin
que se recibe o no es del agrado de uno o simplemente no mueve a una accin proactiva, seguro que su
eficacia ser muy limitada. As que es absolutamente
necesario conocer qu es lo que piensan los otros sobre las ideas o acciones de unos. Por tanto ha de obtenerse una biunivocidad de la informacin, que por
otra parte enriquecer enormemente al conjunto.
Normalmente esta retroalimentacin se obtiene
con mayor libertad a travs del dialogo personal y no
tanto en la respuesta escrita que siempre recoge tintes de justificacin, prevencin cuando no de reivindicacin. Gestionar un proyecto a base exclusivamente de documentos escritos no es recomendable:
alarga los asuntos, ayuda a crear ambientes crispados, y en general tampoco ayuda a resolver todos los
problemas. Hace falta informar por escrito, pero es
ms imprescindible entenderse hablando. As que
el gestor debe hablar mucho con todos y tratar de ser
un interlocutor fcil y accesible.
Era una de las reuniones quincenales de obra en

la que asistan todas las partes afectadas en el proceso de construccin de un complejo ldico-cultural
que una comunidad autnoma de Espaa construa
en una ciudad.
El proyecto, con 62 Meuros de presupuesto, haba sido contratado a Thio Zenn, un famoso arquitecto japons, y su representante en Espaa, Rodolfo
Pie, acuda a la reunin cada quince das. Como
apoyo local, haba elegido a una ingeniera conocida de la zona.
La obra haba sido contratada a una UTE entre
dos grandes empresas nacionales.
Era una macroreunin a la que estaban asintiendo:
Por Thio Zenn: Rodolfo Pie, arquitecto peruana de origen japons que en las obras estaba in situ,
y era el representante en Espaa mencionado anteriormente.
Por la empresa constructora: Marcial Redondo, Gerente de la Obra; Juan Ubeda, jefe de obra;
Cayetano Pals, ingeniero jefe de la oficina tcnica
de la obra; el responsable de suministros; el jefe de
seguridad y el administrador principal.
Por la ingeniera local: Alberto Perns, ingeniero responsable del proyecto que actuaba como
direccin facultativa DF; y un ingeniero de instalaciones.
Por la comunidad autnoma: el arquitecto jefe
de los servicios de arquitectura de la consejera y
una arquitecta asignada al proyecto.
Por el control de calidad: un arquitecto tcnico.
Por el project management: el gestor principal,
que realizaba visitas peridicas y el gestor de obra,
Vicente Mesa, que era quien gestionaba la obra in
situ.
En un momento determinado, el gestor principal,
conmin a Alberto para que entregara ya el diseo
de los soportes de una cercha suspendida, que resultaba de vital importancia disponer en esos momentos. Si no poda hacerlo, deba decirlo con claridad
para que se pudieran adoptar las medidas pertinentes.
Sin esperar una respuesta Marcial Redondo,
el gerente de la obra por parte de la constructora, terci en el ambiente y sacando una libreta
dijo:
- Nuestra empresa est ya cansada de reclamar a
la ingeniera los detalles constructivos que afectan a
bastantes partes del proyecto. No es algo que nos
corresponda hacer. Eso debera hacerlo la ingeniera. Hay cosas que estn pendientes desde hace meses. Yo no hago ms que reclamar las cosas: Se me
pide que las solicite por escrito y se me contesta por
escrito, lo que dilata las soluciones: Esta obra se
est dirigiendo por fax.
- Si no lo creis, comprobad cul est siendo el
proceso de solucin de los soportes de los que se habla continu Marcial mientras mostraba a todos un
par de hojas, que se transcriben a continuacin
y que constatan el intercambio de notas sobre el
asunto:
95
CIUDAD CULTURAL MEDITERRNEA

UTE OBRAS Y SERVICIOS Y FERCON, S.A.
DOSIER CERCHAS
27 DE AGOSTO DE 1996
FECHA
ESCRIBE
RECIBE
CONTENIDO
11-nov-95
11-nov-95
28-ene-96
13-feb-96
18-feb-96
PALS
PERNS
PALS
PERNS
PALS
PERNS
PALS
PERNS
PALS
PERNS
20-feb-96
21-feb-96
PERNS
PERNS
PALS
PALS
24-feb-96
25-feb-96
PALS
PALS
PERNS
PERNS
25-feb-96
PERNS
PALS
3-mar-96
PALS
PERNS
10-mar-96
12-mar-96
PALS
PERNS
MESA
REDONDO
24-abr-96
30-abr-96
PALS
PALS
PIE
PIE
30-abr-96
5-may-96
PERNS
PALS
PALS
PERNS
7-may-96
PALS
PIE
16-may-96
19-may-96
PERNS
PALS
PALS
PIE
19-may-96
20-may-96
2-jun-96
6-jun-96
9-jun-96
PALS
PIE
PALS
PERNS
UBEDA
PIE
PALS
PIE
UBEDA
PERNS
11-jun-96
1-jul-96
PIE
UBEDA
UBEDA
PERNS
7-jul-96
8-jul-96
14-jul-96
UBEDA
UBEDA
UBEDA
PERNS
MEIN
PERNS
15-jul-96
23-jul-96
25-jul-96
30-jul-96
UBEDA
PIE
UBEDA
UBEDA
PERNS
UBEDA
PIE
MEIN
31-jul-96
UBEDA
PERNS
1-ago-96
PERNS
UBEDA
Soldadura o atornilladas? (contradiccin en proyecto)

Atornillada. Si UTE quiere soldadura, que lo solicite
UTE solicita la ejecucin con soldadura
DF admite sistema soldadura
UTE solicita 21 aclaraciones sobre todas y cada una de las cerchas
UTE solicita reunin inminente
El proyecto es correcto
La informacin que tiene UTE no ha decidido el subcontratista
El retraso se debe a que UTE no ha decidido el subcontratista
No hay modificaciones con respecto al proyecto
UTE solicita contestacin a preguntas y pide reunin urgente
La informacin que tiene UTE es insuficiente para la ejecucin
Para subcontratar queremos proyecto de ejecucin y no esquemas
La indefinicin est influyendo en el ritmo de la obra
Habr un incremento de coste si se ejecuta despus de la cubierta
UTE necesita urgentemente aclaraciones a las preguntas
Contesta a parte de las dudas planteadas por UTE
El retraso que alega UTE es estrategia para poder pedir dinero
UTE pide contestacin a ms preguntas y una reunin urgente
Peligra el ritmo de la obra
UTE expone preocupacin por ritmo y posible sobrecoste
Que la UTE cumpla con sus compromisos y subcontrate ya.
No hay ninguna modificacin con respecto al proyecto
La oficina tcnica es un parapeto para pedir dinero a la propiedad
Se remiten a la DF borradores de planos AS BUILT para conformidad
UTE coloca mnsula con taco sobre bloque con resultado negativo
UTE queda a la espera de indicaciones de DF
DF necesita conocer datos concretos sobre colocacin de mnsula
UTE explica cmo se coloc la primera mnsula
UTE sigue realizando pruebas con diversos tamaos y tipos de taco
UTE recibe maana material, y empieza da 9 ejecucin cerchas
Si no hay contestacin a consultas, se ejecutar segn proyecto
Es decir, tornillera mtrica o a bloque de hormign
DF remite solucin A, con mnsulas colgando de vigas
UTE ha recibido solucin A que supone cambio de proyecto
Para valorarlo y aprobacin de la propiedad UTE plantea 12 dudas
UTE tiene equipos parados y material fabricado que habr que readaptar.
UTE formula una duda ms
DF remite solucin B, con mnsulas colgando de vigas
UTE plantea 10 dudas de esta solucin B
La ejecucin se est llevando a cabo mal, incumpliendo rdenes
La DF ha cambiado proyecto una vez empezada la obra
UTE sufre retrasos e incremento de coste por modificaciones
UTE pasa a valorarlo para aprobacin de la propiedad
UTE ruega se paralice unidad hasta la definicin exacta y aprobado
Se urge a UTE a aplicar el sistema de fijacin dada por la DF
UTE remite listado de elementos pendientes de definicin
UTE remite dos soluciones de barandilla valoradas
UTE tiene parado auditorio B por falta de informacin
La obra est bloqueada por indefinicin de DF en cerchas 1,2,3 y14
Se recuerda a DF temas pendientes de cerchas, barandillas, puentes
UTE solicita reunin lo antes posible
Se recuerda a DF temas pendientes de cerchas, barandillas
DF solicita planing sobre diversos trabajos en auditorios
Existe retraso, ya que todo pasa por definicin de cerchas y focos
Se remite lista de asuntos pendientes de cerchas, puentes y barandillas
Son unidades paralizadas sin solucin por la DF
Es intolerable el perjuicio econmico causado
UTE va a desmontar andamios hasta solucin y aprobacin definitiva
Se recuerda a DF temas pendientes de cerchas, focos, barandillas
La obra se va a paralizar si no se toman medidas oportunas
DF aportan posibles soluciones para cerchas 1,2,3 y 4
96
1.2.4 El control
A partir de la prediccin razonable realizada en la
planificacin y en la programacin, el gestor ha de
conocer regularmente el estado de su cumplimiento
de tal manera, que ha de permitirle evaluar, proponer acciones y predecir el resultado final. Ello lo
realizar mediante la comparacin de los programas reales de cumplimiento de actividades y objetivos con los programas patrn.
El proceso de control hay que ir hacindolo de
una forma casi constante. Por eso es necesario que
las planificaciones y programaciones estn presentadas de una forma sencilla y entendible, para su
percepcin eficaz tras una visin rpida. Al menos
desde el punto de vista de la accin del gestor ya
que, dentro del equipo, es quien se ocupa de un mayor nmero de temas, por lo cual ha de dosificar su
tiempo, profundizando en aquellos asuntos que se
declaren como de alto riesgo o de mayor importancia. En todo caso sta es una funcin que l ha de
dirigir.
Al margen de esa cotidianidad del control, cada

perodo especfico de tiempo (una semana, un mes,
dos meses, depende del proyecto) hay que hacer
uno ms pormenorizado y que se explicar cundo
se hable de las diferentes FN. Ese control empieza
por una recuperacin de los contenidos de los objetivos iniciales (programa patrn) que se testan con el
cliente/usuario para asegurar que continan siendo
vlidos en ese momento concreto. El test es hecho
directamente por el gestor que es el que sabe pulsar
con ms sensibilidad tanto la percepcin del cliente
sobre la marcha de los trabajos como los cambios de
rumbo que se deban adoptar para favorecer la misin.
Corresponde tambin al gestor evaluar el estado
de la situacin y proponer directamente a los ejecutores del proyecto (proyectistas, constructores,) o
a travs del cliente, las medidas correctoras que permitan enderezar si es preciso el camino que se est siguiendo.
Con todos los datos en la mano que le proporcionan todos los actores, el gestor ha de hacer otra pre-
PLANIFICACIN & PROGRAMACIN

Cdigos entrada
Objetivos
- Planificacin
Procedimientos
- Recursos
Cdigos salida
ACOMENTIENDO
LA SOLUCIN
AL CONFLICTO
GPU
Informaciones
- Productos
- Elementos UA
- Documentos
- Servicios
Accin
correctiva
Objetivos
- Plazo
- Calidad
- Seguridad
- Otros
TEST
CMO SE
EST
HACIENDO
CONTROL
Fig. 4.11 El control de las acciones de un equipo de gestin
Objetivos
- Plazo
- Calidad
- Seguridad
- Otros
TEST
diccin razonable sobre lo que va a ocurrir. Lo deseable es que la prediccin venga apoyada por la
mayor cantidad posible de datos cientficos que puedan avalar la apuesta por el nuevo futuro que se propone: la existencia de das de lluvia podra justificar
das de retraso en un plazo, el nmero de fallos de un
motor puede justificar en cambio de marca, etc. Y
en todo caso, la experiencia en situaciones similares
suele ayudar mucho a la hora de dar un mayor peso a
la prediccin.
1.2.5 La motivacin
Es una funcin que permanentemente realiza el gestor y que es especialmente necesaria en tiempos de
crisis. La primera accin de motivacin se ha de producir a principio del proceso, el gestor debe ser capaz de integrar los diferentes intereses de todas las
partes para que confluyan en los objetivos de la misin proyectual. Posteriormente, y de forma continuada: deber infundir a todas las personas y entidades involucradas un permanente estado de nimo
positivo, que les permita:
No perder nunca de vista cules son los objetivos
Afrontar siempre los problemas con sus mejores capacidades y en sus niveles ms altos
Para conseguir lo anterior de las personas, el gestor deber:
Recordar permanentemente los objetivos y no
darlos nunca por perdidos
Involucrar a todos los actores en la mejora de
las soluciones
Conseguir crear una cierta conciencia de grupo
Inspirar confianza, tcnica y humana y a todos por igual
Dar ejemplo de entereza, disponibilidad y garra
Los objetivos suelen estar muy claros para todos
en los inicios del proceso. Pero con el paso del tiempo se desdibujan como consecuencia por una parte
del cansancio, y por otra de la aparicin de nuevos
inputs que ponen en duda la actualidad de aquellos.
Frente a estas dudas, el gestor debe esgrimir de una
manera continuada la vigencia de los mismos, siempre que sea evidente su actualidad, y en el caso de
que exista una patente imposibilidad de cumplirlos,
habr, de forma rpida, de plantear otros que hagan
verosmil las actuaciones de todos.
97
Para poder conseguir que cada uno de los actores

d lo mejor de s mismo, es decir, como explica
Mihaly Csikszentmihalyi: que fluyan en el trabajo; es una buena prctica involucrar a todos los actores, en mayor o menor medida, en la bsqueda de
las mejores soluciones. Si se est en la etapa proyectual, eso se consigue incorporando al debate, no solo
a los proyectistas que de por s ya lo estn sino
tambin al cliente, a posibles contratistas, a suministradores de equipos, los representantes de entidades
pblicas afectadas, etc.
Si se est en fase de corporificacin, y aunque el
proyecto ya est hecho, habr que dar posibilidades
de introducir mejoras a los propios corporificadores:
se podra hacer mejor?, qu otros pasos podran
aumentar la contribucin de cada uno? Se tratar de
convencer a las personas de que en lugar de dedicar
energas a escatimar esfuerzos, deben buscar maneras de perfeccionar lo que hacen. Eso convertir el
trabajo de cada uno: yesero, arquitecto, programador, instalador elctrico, etc., en algo importante,
adems de que sin duda sern ms felices.
A nadie se le escapa que conseguir que unas partes tan diferentes y que individualmente tienen objetivos particulares distintos, y en algunos casos divergentes, converjan en unos mismos objetivos y
pongan en su consecucin el mismo inters, resulta
arduo difcil. Y es que, si entre miembros de un mismo equipo de proyectistas por ejemplo ya resulta
complicado que todos estn permanentemente motivados y que vayan en una misma direccin, mucho
ms difcil resulta conseguirlo de todos los equipos y
a la vez: proyectistas, contratistas, clientes, organismos pblicos, etc. Conseguir la conciencia de
grupo, pasa por:
Que existan unos objetivos comunes para todos
Obtener una buena interrelacin entre todas las
personas
Probablemente ser capaz de motivar es una consecuencia de la disposicin de una cierta capacidad
de liderazgo. Y en este caso debera resaltar la cualidad tpica en los lderes, de su predisposicin para
inspirar confianza de manera que no se vea al gestor, por ninguna de las partes implicadas, como un
mero controlador o como una correa de transmisin
del cliente. Se le ha de ver, en cambio, como alguien
cuya misin es la de ayudar a la consecucin de
unos objetivos, que a todos interesa conseguir.
98
Independientemente de que haya algunas personas que de forma estrictamente natural inspiran confianza, sta se gana o pierde por la propia actuacin
personal. Hay, en ese sentido, dos vas para mantenerla: la ausencia de la mentira, y la generosidad,
que significa, tambin, la predisposicin para ayudar sin contrapartida aparente. La confianza basada
en tenencia de conocimientos es otra cosa.
Y una mencin ltima sobre el ejemplo que debe
dar el gestor. En efecto: a lo largo del proceso proyectual se llega a cotas de mxima tensin entre los
miembros del grupo como consecuencia lgica de
que sus roles son diferentes, y las consecuencias negativas que un fallo de alguno incide en los intereses
de otro. De tal forma que, en muchos momentos, parece que no hay salida si no es la ruptura o el incumplimiento de los objetivos de forma dramtica. Pues
bien, en esos casos el gestor debe mantener la firmeza de nimo, sin caer en la simpleza, de tal forma
que su ejemplo haga concebir esperanzas al resto de
que siempre hay una solucin aceptable.
En todo, como ya se ha mencionado en otras ocasiones, es imprescindible el dialogo a travs del contacto personal continuo, acompaado, como es habitual en una GPU, del soporte escrito cuando sea
necesario para asegurar la trazabilidad de las actuaciones.
1.2.6 La representacin
Uno de los motivos que llevan a un cliente a la contratacin de una GPU externa a su organizacin o a
formar un equipo, sea propio o ajeno, para acometer
un proyecto, es la imposibilidad de destinar personas
de su propio entorno a llevar a cabo la gestin, bien
por falta de tcnicos adecuadamente calificados para
el asunto, o por falta de tiempo para hacerlo.
Eso quiere decir que la GPU, y ms concretamente
el gestor, es quien con ms frecuencia se encuentra,
ante el resto de actores, como representante de los intereses del cliente. No slo en los aspectos tcnicos
frente a los proyectistas, sino en los administrativos y
de relacin en general con suministradores, organismos pblicos, vecinos, etc. En todo caso suele quedar
fuera de sta funcin, las correspondientes a los poderes usuales en los administradores de sociedades que
continan estando siempre en posesin del cliente.
En 1997, La compaa VALENCIANA DE CEMENTOS, perteneciente al Grupo CEMEX, lleg a

un principio de acuerdo con el desarrollador dans
KHURT THORSON para iniciar un proceso que llevara a construir una autntica ciudad de 5.000 viviendas en el trmino municipal de Villajoyosa (Alicante) con 10.000 m2 de techo.
El proyecto prevea la contratacin de un master
plan a los arquitectos Norman Foster y Smith Berns.
A partir de este primer diseo, seran encargados a
un grupo de unos 10 arquitectos el proyecto de otros
tantos grupos de viviendas que recogeran estilos y
caractersticas propias de las correspondientes a
cada arquitecto. Los arquitectos se pretenda que
fueran de diversas nacionalidades y se escogieron
en funcin de lo que cada uno de ellos significaba en
el mundo del sector residencial o de servicios relacionado con los usos de las edificaciones. Se pensaba acudir a arquitectos de prestigio.
VALENCIANA DE CEMENTOS aportaba el suelo con alrededor de 1,4 Ms de Ha, en buena parte ya
urbanizado, aunque debera soportar algunas modificaciones fruto del master plan. KHURT THORSON
efectuara la construccin y colocara las viviendas
dentro del mundo financiero, previsiblemente europeo, de fondos de pensiones, fondos de inversin,
mutuas, etc. Los usuarios seran previsiblemente
pensionistas o personas prximas a la jubilacin
con buen poder adquisitivo y procedentes de diferentes pases europeos aunque previsiblemente no se
descartan fueran de otras nacionalidades. El complejo tendra una excepcionales reas comerciales y
de servicios de todo tipo (mdicos, deportivos, culturales, etc.) apropiados para el tipo de usuario.
El plan era para su cumplimiento en 8 aos.
El 5 de septiembre de 1997 se reunieron en Benidorm, Jos M lvarez, representante de VALENCIANA DE CEMENTOS, Mercedes Bayo, representante de KHURT THORSON y Marcos Serer y Pablo
Benlloch, Director Corporativo de IDOM y Director
de IDOM en Valencia, respectivamente. IDOM era
una ingeniera especializada en la gestin de proyectos. ste fue el planteamiento que Jose M y Mercedes hicieron a Marcos y Pablo:
Ya os he explicado los antecedentes y los objetivos de nuestras compaas. concluy Jose M:
K. T. quiere construir todo este complejo de edifi-
cios, pero no tiene intencin de desplazar a Espaa

las personas que previsiblemente sean necesarias
para dirigir y controlarlo todo. Desea, sin embargo,
contratar a un equipo local que haga el management y en el que pueda confiar. En todo caso, s pondr a un coordinador que, a modo de director tcnico, le representar en Espaa y que pertenece a una
gran ingeniera danesa que trabaja habitualmente
para K.T. El equipo de gestin que se forme ser
quien represente a K.T. y controle tcnica y econmicamente todo el proceso. Por lo tanto, necesitamos contratar a una ingeniera que nos merezca toda la confianza. Como podis suponer he solicitado
oferta a otras ingenieras.
El gestor suele representar al cliente en muchas

ocasiones y naturalmente a la propia ingeniera o
grupo de trabajo formado para llevar a cabo la GPU.
Y esa doble representacin le lleva a mantener determinadas distancias y aproximaciones que debe valorar de forma continuada, testando su actuacin con
contactos frecuentes con el cliente, que es quien define la misin y con ella los lmites en los que se ha
de mover.
1.3 Conocimientos de un gestor de PU

Hay que partir de la base de que un gestor debe fundamentalmente dirigir y no ejecutar. Ello, por tanto,
CONFLICTO
nos ha de llevar a la conclusin de que los conocimientos, capacidades y experiencias han de ir siempre en la lnea de la conduccin de hombres y planes.
Se citan a continuacin algunos de los conocimientos necesarios:
La misin del proyecto MP.
Debe conocer a los usuarios en toda la extensin que esa afirmacin merece: necesidades,
experiencias, problemas latentes, apetencias,
etc.
A lo largo del proceso de gestacin del proyecto y de su corporificacin, debe llegar a conocer mejor que nadie el contenido global del
proyecto y sobre todo sus carencias y puntos
fuertes, incluso mejor que el propio proyectista. Eso se puede conseguir si se piensa que el
gestor adopta desde el inicio, sobre todo si se
realiza la GD, una actitud crtica en busca de la
excelencia, utilizando armas como la IV o la
IS, que al director del proyecto le cuesta mucho poner en marcha, forzado en muchos casos
por las prisas.
Las actividades previsibles del proyecto y el
contenido de las mismas. La interdependencia
de una con las otras.
El detalle del entorno del sistema: instituciones
implicadas, los proveedores, los servicios afectados, los condicionantes tcnicos, legales, urbansticos, las mejoras tecnolgicas.
La planificacin y el seguimiento de la misma.
QUE ASUME
el
GESTOR
CON CONOCIMIENTOS
Y EXPERIENCIAS
DE
CONFLICTO
99
ENTORNO
Fig. 4.12 Conocimientos de un gestor
ORGANIZACIN
100
Conocimientos sobre tcnicas de gestin.

Conocimiento sobre las caractersticas humanas y tcnicas de todos los actores.
Conocimientos sobre costos, sistemas de financiacin y contratacin.
Conocimientos tcnicos amplios y de carcter
general tanto de proyecto como de construccin.
Y no est de ms, sino todo lo contrario, que
especficamente y en algn tema concreto, el
gestor se encuentre ms fuerte y pueda aportar
unos conocimientos especficos. Esta suma:
experiencia general y especializacin en un tema muy concreto, se cree que es extremadamente til, tanto para la gestin en s como para el desarrollo integral de la persona.
Queremos hacer una reflexin especfica acerca
de la apuesta que algunos equipos de gestin hacen
sobre que lo importante es la experiencia en el campo de la gestin, despreciando en buena medida las
experiencias de carcter tcnico que ha de poseer un
gestor. Es ms, en algn caso, hay quienes se vanaglorian de dedicarse exclusivamente a gestionar proyectos y nunca proyectan o dirigen facultativamente obras.
A nuestro entender esto es un error, ya que la autoridad moral de un equipo de GPU y especficamente del gestor, deriva de la seguridad que destilan
sus actuaciones por poseer la experiencia sobre lo
que gestiona: un gestor que haya proyectado poco o
haya dirigido pocas corporificaciones a nivel facultativo suele cometer graves errores a la hora de proponer cambios o mejoras en el diseo, en la planificacin o en la construccin: le falta la experiencia de
haberlo hecho con anterioridad y se encuentra siempre en la cuerda floja delante de buenos proyectista o
constructores. Por supuesto los mayores errores derivan de la no actuacin delante de problemas que
no es capaz de detectar por falta de esa experiencia.
Recuerdo la sorpresa del gestor de un gran proyecto de un parque de ocio, cuando uno de los proyectistas le indic que el nico sitio por donde no
deba instalarse la valla de proteccin del recinto de
trabajo era precisamente por donde debiera de instalarse la definitiva. Haba estado ordenando su instalacin y llevaba ms de un 1 Km. Prcticamente
casi toda estaba afectada por el movimiento de tierras as que no se mantuvo en pie ms que unas pocas semanas.
Tambin desconoca la necesidad de implantar
en las obras glibos mnimos para el paso de vehculos con el fin de asegurar la indemnidad de las lneas de AT. La consecuencia fue que un volquete
con la cuchara levantada se llev una de ellas por
delante y se quedaron a oscuras por unas horas los
pueblos de alrededor.
Ese mismo equipo de GPU propuso un planning
en donde el proyecto de un edificio tena un plazo de
ejecucin seis veces inferior a lo lgico. Su inters
en acortar los plazos les llev a proponer sta y
otras medidas. Como es de suponer, sus propuestas
eran destrozadas habitualmente por los proyectistas.
Al final quienes dictaban el planning eran stos ya
que demostraban que slo se poda hacer en el tiempo que ellos decan.
En cambio lo que s haca el equipo de la GPU
era preparar una documentacin muy llamativa y
espectacular de planificaciones, esquemas y cuadros, con abundantes y bien combinados colores.
Pero a la hora de defender como apoyo al cliente
propuesta tcnicas, careca del suficiente rigor que
dicta la experiencia.
Aun cuando la especificidad de los conocimientos tecnolgicos ha de recaer en diferentes miembros

del equipo de gestin, el gestor en concreto ha de
disponer de una consolidada experiencia en proyectacin y direccin de obras antes de ser capaz de
gestionarlas. Por eso es recomendable, tambin al
contrario de lo que muchos piensan, que el gestor
asuma de vez en cuando labores de proyectista para
estar al da y no ver siempre el proceso desde el mismo lado lo que sin duda le resta credibilidad sobre
todo debido a la cambiabilidad y progresividad de
los procesos proyectuales, que pueden dejarle fuera
de contexto si no los practica.
1.4 Capacidades de un gestor de PU

Lgicamente las capacidades de un gestor deben ser
aquellas que le permitan acceder a los conocimientos necesarios para acometer la gestin y que, como
se ha dicho, son fundamentalmente las de direccin

ms que las tcnicas, aun cuando stas son inevitables para poder entender los problemas que se le
plantean y sobre ellos disear una solucin.
Las capacidades se circunscriben alrededor de
tres ncleos: la tecnologa, la capacidad de liderazgo
y la de organizacin.
Se enuncian algunas de las capacidades y habilidades consecuentes, incluyendo entre ellas las que
Robert B. Reich atribuye a las analistas simblicos
(ver El trabajo de las naciones):
Pensamiento sistmico. Considerando la realidad como un sistema de causas y efectos
Capacidad para motivar a las personas y al grupo
Abstraccin y aptitud para estimular la creatividad
Capacidad para la organizacin de personas y
medios
Capacidad para medir por anticipado el alcance
de las medidas que propone y sus repercusiones
El gestor necesita
Capacidad de ascendencia e influencia basada

en el reconocimiento profesional que predispone que
se le respete y en algn caso admire
Capacidad de comunicacin
Capacidad para atender temas diferentes al
mismo tiempo
Su autoridad y prestigio debe resumirse en una
capacidad que le haga ser lider entre los lderes (hay
un director de proyecto, un cliente,). De tal manera que el cliente pueda descansar en l para afrontar
situaciones complicadas o no previstas con planteamientos adecuados a los fines perseguidos
La capacidad de liderazgo se mide en los procesos que generan dificultad o enfrentamientos (cuando el terico lder del proyecto director se enfrenta al contratista y los objetivos peligran, por
ejemplo, entonces ha de surgir el gestor). En aquellos sencillos o carentes de confusionismo y complicacin no hace falta un lder, sino un ensamblador
que se limite a poner las cosas con cierto orden para
que funcionen, lo que naturalmente tampoco resulta
fcil, pero no es lo mismo.
1.5 Las actitudes de un gestor
CAPACIDADES
Tecnolgicas
101
Liderazgo
Organizativas
necesarias para afrontar el
CONFLICTO
Fig. 4.13 Capacidades de un gestor
Capacidad para el trabajo en equipo

Debe de tener habilidad para la negociacin,
sabiendo que por un lado l representa al cliente, y
por otro que los dems actores lo han de ver como
un colaborador
Capacidad de adaptacin a las diferentes circunstancias que pueden hacer cambiar la misin en
algunos de sus aspectos en el transcurso del proceso
El ejercicio de las funciones de un gestor de un proyecto de carcter nico, conlleva una implicacin
dentro de un contexto, que de por s ya es complicado. Existe un conflicto a resolver cuya solucin tcnica se le ha encomendado a un proyectista que es
erigido, obviamente, en director del proyecto. Pero las tericas capacidades individuales de ste u
otro especialista no son suficiente para resolver el
conflicto, ya que hay otras implicaciones que se deben tener en cuenta misin y que hacen que las
personas que colaboran en el proceso proyectual deben entresacar de s mismas lo mejor y ms adaptable a las exigencias del proyecto.
Para conseguir eso, el gestor debe actuar en
consonancia con lo que se desea. Sus actitudes sern tanto o ms positivas cuando sean capaces de
generar un estado de nimo en el equipo que provoque que cada uno de ellos utilice sus mejores armas, y sus capacidades al mximo nivel de rendimiento. Eso, como se sabe, es relativamente fcil
conseguirlo en forma momentnea y coyunturalmente, pero extremamente difcil que se mantenga
102
CAPACIDADES
+
CONOCIMIENTOS
Deben manifestarse en
ESTADO
ANMICO
EN EL
EQUIPO
ACTITUDES
AFLORAMIENTO
HABILIDADES
DEL EQUIPO
Fig. 4.14 Esquema general de capacidades + conocimientos + actitudes de un gestor
en el tiempo. El procedimiento para hacer durar ese

estado de nimo pasa, sin duda, porque el gestor
mantenga esas actitudes de forma tambin permanente: ya se sabe que las propuestas, consejos, sugerencias, etc., son poco efectivos si no van acompaadas del ejemplo. En este caso, las actitudes
que deja ver el gestor y que ahora algunas de ellas
se resumen:
La actitud de prestacin de servicio.
El optimismo debe prevalecer en cualquier situacin.
La intencin de permanente ayuda. Lgicamente, sin dejar de asignar la responsabilidad a
quien la tenga.
Actitud de seriedad en todos los planteamientos alejndose de ligerezas sin base suficiente, tanto
desde el punto de vista tecnolgico como econmico. No hay nada balad.
Mantener en el ambiente un sentido de la calidad en todo cuanto se hace.
Actitud de exigencia consigo mismo.
Considerar cada proyecto como un reto y que

esa actitud sea visible para todos los dems.
Igualdad de trato tanto para los contratistas y
suministradores como con los proyectistas
Actitud de progreso. Infundir en los proyectistas la necesidad de que tienen que proyectar pensando en la mejora constante y en los ltimos avances
que se conozcan sobre los temas que se abordan.
Positivismo. Hay que enfocar todos los asuntos
desde la vertiente de que aquellos tiene una solucin
que puede satisfacer. Esta actitud debe mantenerse
incluso en la crtica y sobre todo en ella.
Coherencia en los planteamientos sobre todo
delante de su equipo colaborador. Mantener una
misma lnea para evitar desasosiegos y sorpresas.
Una actitud negativa y de enfrentamiento con y
entre el resto de actores impedir el afloramiento de
todas las habilidades posibles en los miembros del
equipo. Y las que aparezcan lo harn, con toda probabilidad, mermadas por la desidia, el mal humor, la
prevencin, el miedo o el espritu de venganza.

Gestión Integrada de Proyectos-3

Cargado por

Información del documento

Título original

Derechos de autor

Formatos disponibles

Compartir este documento

Compartir o incrustar documentos

Opciones para compartir

¿Le pareció útil este documento?

¿Este contenido es inapropiado?

Copyright:

Formatos disponibles

Gestión Integrada de Proyectos-3

Cargado por

Copyright:

Formatos disponibles

Empresas y organizaciones en la sociedad de hoy

3. La calidad en los proyectos de carcter nico

1 La proyectacin: tecnologa y servicio

En ese equipo no debe quedar descolgado los

Los autores, 2001; Edicions UPC, 2001.

Gestin integrada de proyectos

Construcciones y Obras de Infraestructura

La obra tena una duracin prevista de 20 meses.

Fig. 3.1 La proyectacin: La TD y el servicio

Los autores, 2001; Edicions UPC, 2001.

La calidad en los proyectos de carcter nico

la otra le advirti de las consecuencias que poda

2 La calidad como aglutinante.

Fig. 3.2 Esquema de la calidad completa

Los autores, 2001; Edicions UPC, 2001.

Gestin integrada de proyectos

En estos contextos, la implantacin de un plan de

3.2.1 Costes de la calidad

El gestor ha de considerar permanentemente el coste

Los autores, 2001; Edicions UPC, 2001.

La calidad en los proyectos de carcter nico

Fig. 3.3 Costes de la calidad: Prevencin y evaluacin

las labores de gestin en forma prctica, a la vez

cal cuyo propietario era una persona muy conocida

Los autores, 2001; Edicions UPC, 2001.

Gestin integrada de proyectos

ms complicados aunque los hubiera tratado con

xima al talud que era donde estaba la valla de lmite

Los otros costes en los que se incurre son los

Los autores, 2001; Edicions UPC, 2001.

La calidad en los proyectos de carcter nico

Fig. 3.4 Costes de la calidad y la no calidad

de los objetivos, etc., y todos ellos vlidos para cada

3.2.2 Costes de la no calidad

Los autores, 2001; Edicions UPC, 2001.

Gestin integrada de proyectos

Recursos internos extras

Recursos financieros extra

Fig. 3.5 Costes de la no calidad

tra,..) para rehacer planos, clculos, memorias, etc.

Segn Peugeot, un cliente satisfecho equivale a

cliente insatisfecho puede provocar la prdida de 25

Se cita a continuacin la conocida regla del 1-10100.

Fig. 3.6 Regla del 1-10-100

Los autores, 2001; Edicions UPC, 2001.

La calidad en los proyectos de carcter nico

Este hecho puede provocar una insensibilizacin

Ya se mencion cuando se trat las caractersticas de

Fig. 3.8 Las cuatro caractersticas de la calidad

Los autores, 2001; Edicions UPC, 2001.

Gestin integrada de proyectos

muchas las fases de prestacin del servicio o muchas

tendiendo como tal a los ya mencionados actores que

4 Valor y percepcin de la calidad

4.1 Las expectativas previas

Una filosofa de direccin

Una concepcin rupturista

Un enfoque estructurado y orientado

Consistente en acciones directivas

Liderado por la direccin

Soportado por el control estadstico de

Dirigido por el control estadstico de

Adoptado por todos