1

ADMINISTRACIN DE PROYECTOS:
ALCANCES Y METODOLOGA DE DISEO.
-------------------------------------------------------------------------------------------------
A. Alcances de la Administracin de Proyectos.
1. Introduccin.

Antes de entrar propimente en lo que se refiere a Administracin de Proyectos, es conveniente

precisar algunos alcances del concepto de Proyecto que sirve de trasfondo a toda la exposicin.
Desde un principio es necesario aclarar,- para no entrar en discusiones semnticas estriles -, que
muy bien pudiera hablarse, en ciertos casos, en ves de proyecto, de programas, sub-
programa, e incluso de sub-proyecto, sin embargo, ocuparemos el trmino proyecto en sentido
genrico, dejando que el propio contexto en que se use la expresin defina los alcances que
adquiere el trmino en cada ocasin.

Distinto es el caso referente al grado de concrecin del contenido de los proyectos. Aqu tenemos
que separar algunos de los conceptos, a fin de no caer en malentendidos. Hay algunos llamados
proyectos, de los cuales slo existe una idea general, una intencin o tan slo un nombre,
mientras que en otros casos, por proyecto se entiende la ejecucin de una obra de ingeniera o
incluso, la operacin de ciertas instalaciones. En el contexto que nos interesa, - cul es el de
examinar los problemas de administracin de proyectos-, no podemos aceptar una definicin tan
amplia; por lo tanto un requerimiento operativo de la nocin proyecto que ocuparemos, es que el
proyecto est en un estado que requiera administracin.

Esto puede entenderse en dos sentidos que, como veremos, son fcilmente asimilables: a) un
proyecto es administrable cuando tiene definido objetivos y medios para alcanzarlos; es decir,
cuando ya pas las etapas de formulacin, evaluacin, negociacin del financiamiento y decisin
final y llegga la etapa de ejecucin; y b) cuando no se han pasado esas etapas, lo que hay que
administrar es el proceso de trnsito de la idea-proyecto a travs de todas las instancias y etapas
necesarias para alcanzar el estado en que el proyecto se pueda ejecutar. Desde luego este proceso
de trnsito es en si un proyecto de ejecucin, que pudiera llamarse formulacin, evaluacin y
aprobacin de XX, siendo XX el proyecto que despus se va ejecutar. Si no es as, vemos que la
nocin b) es similar a la a), lo nico que no se refiere a ejecutar XX, sino a transitar XX por las
etapas previas a la ejecucin
 2

2. Los Proyectos como Estados Transientes.

Para entrar en materia necesitamos introducir ciertos conceptos que pueden aclarar el sentido de la
exposicin y que, a la vez, permitan vislumbrar el origen de los problemas que sufren algunos
proyectos.

Por proceso entenderemos un conjunto de acciones sistemticas encaminadas a obtener un

resultado determinado; el resultado que ser producto del proceso. Para poder desarrollar sus
acciones, un proceso necesita apoyarse en una estructura, que est compuesta por personas, bienes
fsicos, costumbres, etc. Todos los cuales forman un sistema, por estar interrrelacionados con miras
a obtener el fin comn que es el producto deseado. Si bien el sistema sirve de soporte al proceso,
los productos se obtienen a partir de la utilizacin de ciertos insumos que son tomados por el
sistema del medio o entorno, a fin de ir transformndolos en el o los productos deseados, los cuales
sern entregados nuevamente al medio, para su utilizacin o consumo. El circuito econmico se
cierra considerando que cada transaccin de bienes o servicios del sistema con el medio tiene una
contrapartida monetaria, que permite equilibrar el valor de los flujos de insumos y de productos.

Diremos que un proceso ha alcanzado un estado de rgimen cuando es capaz de mantener

indefinidamente una situacin de equilibrio productivo. Cuando hablamos de capacidad de
mantener un equilibrio, ajustndose a las variaciones previsibles, siempre y cuando no
sobrevengan cambios mayores inesperados. Desde luego, pequeos desequilibrios estacionales
que tienden a compensarse en el tiempo no alteran la condicin de rgimen.

Precisamente, un estado de rgimen se caracteriza por la capacidad de entregar fluidamente los

productos requeridos por el medio, y absorbiendo las variaciones menores que pueden
producirse en el medio o entorno. Un proceso o estado de rgimen necesita ser administrado, en
el sentido que continuamente hay que estar tomando las decisiones necesarias para mantener la
fluidez de operacin en medio de las fluctuaciones del ambiente.

Los estados de rgimen no surgen de la nada: a ellos se llega mediante un proceso tambin, pero
un proceso destinado a producir o mejorar la estructura de apoyo que necesita el estado de
rgimen que se busca. Para alcanzar una estructura dada es necesario pasar previamente por una
 3

etapa en que esa estructura est en construccin o modificacin. La construccin o modificacin

de una estructura es un estado transiente que, al contratio de la estabilidad y permanecia del
estado de rgimen, tiene una duracin definida y un propsito terminal; a lo largo de l la
naturaleza de las acciones, -y por lo tanto, la estructura necesaria para realizarlas-, va cambiando
constantemente.

Este proceso de transformacin o creacin de las estructuras necesarias para alcanzar un estado
rgimen, necesita ser administrado tambin, pero reconociendo que es un proceso diferente, tanto
en cuanto al producto esperado, como al proceso productivo. Por obvio que parezca esto, -
planteado a este nivel de abstraccin, en la prctica no siempre hay claridad al respecto, y ah
tenemos a Ministerios de Salud o de Educacin administrando construcciones de edificios, o a
empresas que tienen una sola organizacin tanto para administrar sus operaciones como sus
ampliaciones . Sobre este punto volveremos cuando tratemos el punto de la organizacin
administrativa de apoyo para la ejecucin de proyectos.

Un par de ejemplos ayudan a aclarar las ideas:

Ejemplo I:

Hay un pequeo restorn, atendido por su dueo, quien hace de cocinero. Se transforma luego en
un restorn ms grande, en el cual el dueo slo pretende preocuparse de la administracin
financiera y del local.

Aqu, el primer estado de rgimen es claro; el pequeo local con su propietario-cocinero pudo
haber seguido indefinidamente en operaciones. El segundo estado de rgimen est tambin
definido, pero es diferente al primero: la escala de operaciones es diferente y las funciones del
dueo tambin son diferentes; tambin el nuevo restorn podra seguir indefinidamente con sus
operaciones. Ahora bien, cmo se pas de un estado de rgimen a otro?. Posiblemente hubo
que cerrar el primer local y construir otro ms amplio, hubo que comprar ms mesas, sillas, etc.
y, -muy importante-, hubo que transformar el propietario-cocinero en propietario-administrador.

Este proceso de transformacin es un transiente: en l lo que sucede es cualitativamente diferente

a lo que sucede en los estados de rgimen; si en estos ltimos el objetivo que se busca es la
 4

satisfaccin gastronmica de los clientes, es el transiente lo que se pone como objetivos son cosas
como construir un edificio o reentrenar ciertos recursos humanos. Evidentemente un buen
administrador para el objetivo gastronmico y la organizacin en que se apoya no tiene por qu
ser los ms idneos para construir un edificio o para capacitar recursos humanos.

Ejemplo II:

Alguien tiene la encomiable idea de establecer un programa de Maestra en Administracin

Pblica. Al cabo de un cierto tiempo el programa est funcionando a plena carga.

Aqu, nuevamente, tenemos dos estados de rgimen deiferentes: en el primero, hay una idea que,
si no se emprenden acciones concretas, podra seguir como el enunciado de algo deseable, en
forma indefinida. El segundo estado de rgimen, -la Maestra funcionando-, tambin pueden
mantenerse en forma indefinida, una vez que ha sido alcanzado. El transiente sera del primer
estado de rgimen al segundo, como por ejemplo: disear cursos, obtener recursos, contratar
profesores, obtener locales adecuados, etc.

Nuevamente, las estructuras administrativas en que se apoyan estos procesos -los dos estados de
rgimen y el transiente-, son diferentes porque sus objetivos son diferentes. Incluso las personas
que administran estos procesos no tienen por que tener las mismas caractersticas: el primer
estado -la idea-, pudiera ser administrado por un poltico que busca apoyo para la idea, traducido
en recursos para desarrollarla; el segundo estado -el transiente -pudiera requerir una dosis de
ingeniera de sistemas acadmicos, y el tercer estado -la Maestra funcionando-, pudiera
beneficiarse de la administracin de un acadmico de gran prestigio en Administracin Pblica.

Estos ejemplos ilustran el punto de la administracin del estado transiente es diferente de la

administracin de los estados de rgimen, en cada caso en particular. Queda abierta la
interrogante si acaso la administracin de estados transientes en general es lo suficientemente
diferente de la administracin de cualquier otro proceso, como para justificar un estudio por
separado de ella.

Un proyecto es un estado transiente, toda vez que lo que se busca con un proyecto es instalar la
capacidad necesaria para desarrollar un proceso en estado de rgimen. As podemos hablar del
 5

Proyecto de Ampliacin del Restorn del ejemplo primero y del Proyecto de Implantacin de la
Maestra en el segundo ejemplo.

La Administracin de Proyectos, por lo tanto, se refiere a la aplicacin de principios gerenciales

al proceso transiente de creacin o ampliacin de las estructuras capaces de soportar estados de
rgimen de procesos que entregan productos finales al medio.

Hay una serie de caractersticas que diferencian el problema administrativo en uno y otro tipo de
proceso:

a) Los proyectos entregan productos nicos, mientras que los procesos en estado de rgimen
pueden entregar un flujo de productos similares. En consecuencia, una serie de decisiones
basada en la experiencia que se va acumulando, son posibles en los procesos en rgimen, pero no
en los proyectos. Esto acenta el nfasis en la planificacin y programacin previa a nivel de
detalle como indispensable en la Administracin de Proyectos.

b) Por entregar productos en forma repetitiva, las estructuras de soporte del proceso en rgimen
tiene un carcter de permanentes, mientras que en el caso de los proyectos, cuando se ha
terminado una fase de l, se pasa a una nueva fase que requiere una estructura de apoyo distinta,
lo cual significa que la estructura de apoyo distinta, lo cual significa que la estructura de apoyo de
un proyecto debe ser variable en el tiempo. Esto significa que si bien en los procesos en rgimen
las estructuras organizativas pueden ser de tipo funcional, en un proyecto conviene que sean el
tipo de organizacin por objetivos.

c) Por el carcter temporal y variable de las estructuras de apoyo, el personal que trabaja en
proyectos requiere normas de administracin diferentes de las del personal que trabaja en
estructuras permanentes.

d) Del mismo modo, el manejo presupuestario y contable, el sistema de informacin y control, y

el resto de elementos organizacionales, toman caractersticas especiales en el caso de la
Administracin de Proyectos.
 6

Son estas peculiaridades las que justifican dedicar un libro especial a la Administracin de
Proyectos.

3. Los Objetivos de los Proyectos.

Siguiendo con la necesidad de precisar y aclarar conceptos, nos encontramos con un problema de
comn ocurrencia, que se refiere a la ambigedad de lo que se entiende por objetivos de un
proyecto.

De nuestros prrafos anteriores fluye naturalmente la nocin que lo que se busca con un proyecto
es desarrollar la estructura de apoyo que permita que un proceso alcance un estado de rgimen.
Esto nos lleva a preguntarnos qu se necesita para alcanzar dicho estado de rgimen. En el caso
del restorn era fcil determinar que el estado de rgimen se alcanzaba con una planta fsica
ampliada ms un propietario en capacidad de administrar; es decir, tenemos una ecuacin del
siguiente tipo:

1) Estado de rgimen = Planta fsica + Propietario capaz

alcanzado ampliada de administrar

Es claro que el ejemplo era muy sencillo y es claro tambin que nada nos asegura que por el solo
hecho de ampliar la planta fsica nos asegura que van a llegar nuevos clientes, de modo que es
posible que la ecuacin no est completa, sino que falten ms condiciones, como Clientes
satisfechos en cantidad adecuada, a fin de que el estado rgimen sea realmente estable. En todo
caso, el punto es que para poder administrar un proyecto hay que caracterizar completamente el
estado al que se desea llegar. La ecuacin general sera, entonces:

2) Estado de rgimen = Condiciones necesarias

alcanzado todas cumplidas

Aqu est ya el primer problema: definir cuales son todas las condiciones necesarias para
garantizar que el estado que se alcance sea realmente de rgimen. En una realidad que es
compleja, no siempre se logra una enumeracin adecuada acerca de cules son estas condiciones
necesarias, y esto trae trastornos a veces graves en los proyectos.
 7

Siendo que el propsito de un proyecto es establecer la estructura que permite alcanzar el estado
de rgimen, sus objetivos deben ser, naturalmente, los de cumplir con todas las condiciones
necesarias, segn lo expresa la ecuacin (2). De aqu que hablemos que un proyecto pueda
dividirse en varios subproyectos destinados cada uno de ellos en cumplir parte del total de
condiciones necesarias.

Cuando hablemos de cumplir condiciones estamos ante un nuevo problema: a menudo las
condiciones que deben ser cumplidas requieren factores que no estn al dominio del
administrador del proyecto . Por ejemplo, se puede hacer campaa publicitaria para el nuevo
restorn, pero no se puede garantizar absolutamente que se forme una clientela estable de tamao
adecuado al nuevo local. En el mismo sentido, se podr matricular al propietario en uno o varios
cursos de administracin, pero no se podr garantizar que resulte un administrador capaz de
manejar su nuevo negocio. En cambio si es posible garantizar que la vajilla y cubiertos alcancen
para 100 personas.

Esto nos lleva a introducir el concepto de objetivo operacional como el resultado que realmente
se puede garantizar, -como, por ejemplo, colocar un aviso en el peridico o contratar un curso de
administracin por correspondencia-. Evidentemente los resultados operacionales no son
exactamente iguales al cumplimiento de las condiciones que aparecen en la ecuacin (2). Esto no
quiere decir que esas condiciones no pueden cumplirse, sino que no es posible que el
Administrador del Proyecto garantice el cumplimiento de esas condiciones con los elementos que
tiene bajo su comando.

Esto lleva a un nuevo tipo de ecuacin que toma la siguiente forma:

3) Condicin = Resultados operacionales + Supuestos vinculantes

cumplida alcanzados cumplidos

Los supuestos vinculantes son todas las suposiciones, presunciones o expectativas que, al ser
ciertas, permitiran que los resultados operacionales impliquen el cumplimiento de las
condiciones. Por ejemplo, si al resultado operacional de matricular al propietario del restorn en
un curso de administracin, se agrega que se cumplen los supuestos de que i) el propietario
 8

asiste regularmente al curso, ii) el curso es adecuado para lo que necesita el propietario, iii) el
propietario aprende y iv) el propietario aplica lo aprendido, estaremos mucho ms cerca de
cumplir la condicin de la ecuacin (1). Estos supuestos por lo general caen fuera de lo que
puede manejar el Administrador de Proyecto, -especialmente el supuesto iii)-, y es por ello que
solo puede comprometerse al resultado operacional.

De aqu que los objetivos operacionales de un proyecto conformen una ecuacin que no se
desprende necesariamente de la (2), sino que la complementa.

4) Proyecto = Objetivos operacionales para cada condicin

terminado cumplidos.

Aqu nos encontramos con la necesidad de una definicin del alcance del proyecto . Es obvio que
algunos supuestos son totalemnte ajenos a la influencia que sobre ellos pueda ejercer desde el
cargo de Administrador del Proyecto, pero tambin es evidente que sobre algunos supuestos s se
pudiera ejercer alguna influencia, e incluso, algunos de ellos pudieran garantizarse, con lo cual se
convertiran en objetivos o resultados operacionales. Hasta dnde llegar con el proyecto,
entonces? No hay una respuesta clara, precisa y tajante, y de ah nuestra aclaracin inicial acerca
de la posibilidad de llamar programa; sub-programa, proyecto o sub-proyecto a lo que
nosostros genricamente entendemos por proyecto.

Esta situacin de definir bordes, si bien no puede ser resuelta en trminos tericos o doctrinarios,
debe ser resuelta en forma no ambigua en cada caso en particular. Si una condicin de la
ecuacin (3) depende muy fuertemente de la materializacin de un supuesto, algo deber hacerse
para tratar de influir en que dicho supuesto se cumpla, o deje de ser importante, esto es, por
ejemplo:

a) Extender los bordes del proyectos y dar al Jefe de Proyecto alguna responsabilidad sobre
factores que influencian ese supuesto.
b) Montar un proyecto diferente, a cargo de otra persona y otra organizacin, destinado a
controlar o influir sobre ese supuesto.

c) Establecer un acuerdo de coordinacin con quienes pueden influenciar ese supuesto.

 9

d) Modificar el proyecto para compensar de alguna forma un posible no cumplimiento de la

condicin del estado de rgimen que no se puede garantizar.

Cualesquiera que sea la resolucin, en algn momento hay que definir la frontera del alcance del
proyecto, es decir, aquello sobre lo caul se tratar de lograr resultados operativos y aquello sobre
lo cual slo esperar que resulte favorable. Si no se hace este corte, el Administrador no sabr
qu se espera de l y el proyecto entrar en dificultades.

Un caso muy especial de delimitacin del borde de cobertura de un proyecto es el que se da

cuando dos o ms instituciones deben cooperar y se hacen todos los estudios suponiendo que as
va a ser, para encontrarse despus que tal cosa no sucedi y que mientras una institucin hizo su
parte, otras se atrasaron o no lo hicieron. Peor aun es el caso en que no se prest atencin a los
supuestos, se hizo un presupuesto y despus result que hubo que invertir grandes cantidades en
lograr que lo que se haba supuesto, realmente ocurriera.

Todas estas consideraciones son previas a la etapa de ejecucin, y por lo tanto corresponden a lo
que es concepcin y diseo tcnico del proyecto. Es indispensable que estos puntos estn
resuletos antes de empezar la ejecucin y una de las tareas primeras del Administrador de la
ejecucin debe ser verificar que estn claros los bordes del proyecto y que ste podr entrar en
funciones cuando quede terminado.

Volviendo a nuestro hilo de exposicin y juntando ahora las ecuaciones (2), (3) y (4) tenemos la
relacin resumida que seala:

5i) Estado de = Objetivos + Supuestos

rgimen todos Operacionales todos vinculantes
alcanzado cumplidos realizados

o, lo que es lo mismo.

5ii) Estado de rgimen = Proyecto terminado + Supuestos

alcanzado realizados
 10

Las ecuaciones (2) y (4) no pueden disociarse. Si (2) se considera aislada de (4), no da una pauta
para establecer qu acciones concretas hay que desarrollar, y todo queda en una nebulosa. Por
otra parte, (4) sin (2) es slo una lista de cosas por hacer, que no puede garantizarse que est
completa sin cotejarla con (2).
Entre ambas definen los objetivos del proyecto.

Resumiendo ahora lo expuesto, a fin de darle un contenido concreto, es comn encontrar que se
entremezclan dos planes de anlisis cuando se requiere definir los objetivos del proyecto.
Por una parte, es objetivo de un proyecto alcanzar un estado de rgimen determinado, y es
necesario que el Administrador conozca ese punto de llegada y que se responsabilice por lograr
todos los resultados operacionales que sean necesarios. Por otra parte, el proyecto general se
podr desglosar en proyectos parciales, cada uno de los cuales busca uno o ms resultados
operativos, que por si solos, aislados, no aseguran la obtencin del objetivo final. Buscar el
cumplimiento de estas condiciones necesarias, pero no suficientes tambin es llamado proyecto,
el cual debe administrarse en bsqueda del mero resultado operacional. Es un error frecuente
confundir algunos resultados operacionales con el proyecto general, como lo muestran los casos
mencionados.

4. El Campo de la Administracin de Proyectos.

Esta separacin de conceptos nos lleva a tratar de especificar el campo de la Administracin de

Proyectos: i)hay que hacer primero un gran esfuerzo por imaginar y establecer cules objetivos
parciales completan la lista de resultados necesarios para cumplir el objetivo parcial hay que
asociar uno o ms objetivos operacionales que puedan garantizar en ms alto porcentaje la
obtencin de los objetivos operacionales (ecuacin 4).

Desglosar el objetivo final en objetivos parciales puede hacerse de diversas maneras: en el fondo
equivale a describir las condiciones necesarias que deben darse para obtener el resultado final
buscado. En un mundo que es complejo y en el cual se mezclan factores polticos, sociales,
culturales, econmicos, tecnolgicos, etc., definir cules condiciones son necesarias para obtener
un resultado final determinado no es una tarea mecnica, sino requiere conocimiento, habilidad y
sentido de la situacin: es decir, colinda con una creacin intelectual artstica.
 11

Definir luego cules resultados operacionales se acercan ms a inducir los resultados parciales
definidos como necesarios, es ya una tarea algo ms tcnica, que tiene mucho de poltica,
especialmente cuando hay alternativas entre las cuales decidir: mientras que garantizar el
cumplimiento de los objetivos operacionales cae de lleno en el rea de manejo tcnico gerencial.

La Administracin de Proyectos abarca el conjunto de esta tareas y tiene, por lo tanto, alcances
que van ms all de lo meramente tcnico.

B. Metodologa de Diseo Administrativo.

1. Designacin de un jefe de proyecto.

El proceso de definicin de objetivos debe terminar en algun momento; las ecuaciones (2), (3) y
(4) dan la base para ello. Se haya encontrado o no que es satisfactorio el conjunto de objetivos
operacionales, lo cierto es que lo que procede posteriormente es organizar las actividades que
llevan a la obtencin oportuna de ellos. Nos encontramos, entonces, en la parte del campo de la
Administracin de Proyectos que es bsicamente tcnica y gerencial.

Este cambio desde la fase de diseo de objetivos operacionales a la fase de administracin de los
procesos necesarios para obtenerlos, es de carcter cualitativo y, por consiguiente, lleva a
plantearse la cuestin acerca de la necesidad de asignar la responsabilidad de administrar este
proceso a un especialista. Como deciamos en un ejemplo anteior, no es lo mismo cocinar que
dirigir la construccin del local de un restorn, ni es lo mismo promover una idea que obtener los
productos promovidos.

El primer caso para proceder a la ejecucin de un proyecto es la designacin de un responsable de

ella, o Jefe de Proyecto. Hay que tener claro que esto no significa nombrar un jefe para
administrar el estado de rgimen futuro, sino tan solo un responsable del rgimen transiente. Esto
es muy importante, pues si se confunden las cosas, se nombrar como jefe del proyecto a algn
funcionario idneo para funciones que son del todo diferentes de la de direccin del proyecto.
Tal es el caso de ejecutivos de lnea en una organizacin que mezclan la direccin de su trabajo
 12

en rgimen con la direccin de la modificacin de las estructuras de soporte de l: a veces esto

resulta bien, pero a menudo hay fracasos estrepitosos.

Desde luego, nada impide que una persona en particular pueda dirigir a la vez procesos muy
diferentes, poero ms bien est sera la excepcin que la regla, lo cual lleva a recomendar que no
se piense automticamente en un ejecutivo en lnea como eventual jefe del proyecto, sino que se
parta de una base de seleccin diferente, en lo cual por excepcin pudieran estar incluidos por
candidatos algunos ejecutivos de lnea.

Por otro lado, por lo general, incluso en proyectos relativamente pequeos, la tarea de direccin
de la ejecucin es de carcter complejo, lo cual hace necesario que el Jefe de Proyecto le dedique
toda su atencin y todo su tiempo. La experiencia muestra que cada vez se entrega la direccin
de un proyecto a un jefe de lnea de la organizacin permanente de la institucin en la cual se
realiza el proyecto, sin apartarlos de las obligaciones de su cargo permanente, estas ltimas
ocupan tal parte de su tiempo y atencin, que muy pronto el proyecto cae en dificultades graves.

El slo enunciado de las responsabilidades que debe asumir el jefe de proyectos, indica que las
habilidades que debe tener no son meramente tcnicas, sino de carcter Gerencial, ya que su
misin fundamental es planificar, dirigir y controlar actividades de distintas disciplinas, tan
variadas y complejas como pueden ser las actividades de una empresa.

Es difcil sealar un perfil de las cualiades que debe poseer el jefe del proyecto, toda vez esto es
muy coyuntural; sin embargo, hay algunas facetas de su personalidad que seran deseables.

a) Amplitud de visin sobre lo que debe lograr. Que entiendan que los resultados que deben
obtenerse se logran con el aporte valioso de todo tipo de disciplinas y puntos de vista.

b) Habilidad Gerencial para dirigir grupos humanos multidisciplinarios y obtener de ellos

iniciativas imaginativas que contribuyan a innovar productivamente los mtodos de ejecucin del
proyecto.

c) Habilidad para relacionarse con el ambiente que rodea el proyecto, a fin de facilitar las
relaciones necesarias.
 13

d) Capacidad y coraje para tomar decisiones rpidas y seguras en los momentos en que surgen
los inevitables imprevistos.

e) Prestigio, que a menudo es el resultante de poseer las cualidades anteiores.

La enumeracin anteior no significa que el Jefe de Proyecto deba reunir calificaciones mximas
en cada uno de los puntos sealados, pero si necesita tener alguna cuota de habilidad en cada una
de ellas, de modo que logre un balance global satisfactorio. Por difcil que sea encontrar una
persona con todas esas caractersticas, es necesario hacer un esfuerzo por buscarla, puesto que su
influencia va a ser decisiva.

No son pocos los proyectos que se han empantanado innecesariamente debido a una direccin
vacilante o inepta. Peor an es la situacin de proyectos que simplemente no tienen un jefe
responsable, ya sean porque las actividades diversas se dispersaron entre varios responsables de
operaciones del estado de rgimen pre-proyecto, o porque se nombr como jefe de proyecto a un
ejecutivo de lnea sin tiempo de dedicrselo al proyecto.

El Jefe de Proyecto, una vez escogido, debe recibir atribuciones que estn en concordancia con la
responsabilidades que asume. Entre estas atribuciones est, desde luego, su capacidad de
intervenir en la escogencia de quines sern sus colaboradores ms inmediatos. Otras
atribuciones se refieren a su papel dentro de la institucin en que se desarrolla el proyecto, cosa
que veremos en los prrafos referentes al diseo de organizacin.

2. El desglose de objetivos.

Una vez que el Jefe de Proyecto se ha posesionado de sus funciones, debe abocarse a las tarea de
organizar su trabajo. Su primera preocupacin es lograr que la definicin de objetivos del
proyecto vaya siendo desglosada en resultados menores, ms parciales, ms concretos, de menor
plazo y ms fciles de controlar.
 14

Esta es una tarea similar a la de establecer las condiciones necesarias para cumplir un estado de
rgimen, es decir, para cada objetivo operacional ya definido, del proyecto, hay que establecer un
conjuto de condiciones que deben ser satisfechas. Cada una de estas condiciones es as un sub-
objetivo que debe ser alcanzado, a fin de que el objetivo se cumpla a su vez. Podemos decir as
que el proyecto se descompone en sus objetivos operacionales y que cada uno de stos se
descompone a su vez en sub-objetivos.

La descomposicin puede continuar, tomando cada sub-objetivo y analizando cul es el conjunto

de condiciones necesarias de las cuales depende, y establecer el cumplimiento de cada una de
stas como un sub-sub-objetivo.

A travs de este procedimiento se va especificando cada vez ms el tipo de resultados que deben
ser obtenidos a fin de lograr por ltimo dar trmino al proyecto. Estas especificaciones deben
contener:

a) Caracteristicas cualitativas y cuantitativas de los bienes y servicios que se desean obtener.

b) Plazo y condiciones en que estos bienes o servicios deben estar disponibles, y

c) Costo que est dispuesto a pagar por esos bienes y servicios (presupuesto).

Estas especificaciones van constituyendo una pirmide, en la cual pueden reconocerse diversos
niveles de desagregacin. La definicin de estos objetivos de distinto nivel llega al estudio de los
procesos necesarios para alcanzar los resultados correspondiente y esto significa la definicin de
los subsistemas principales de la ejecucin y de la organizacin.

La definicin de los sub-sistemas requiere de la participacin de funcionarios bien calificados

con especialidad en los aspectos fundamentales de cada uno de ellos, pero tambin con
habilidades Gerenciales. Por ello se recomienda que al definir los sub-objetivos principales, el
Jefe de Proyecto elija y solicite a la Direccin Ejecutiva de la institucin la designacin de los
funcionarios que van a ser los responsables o jefes de los sub-sistemas, de modo de trabajar con
ellos en el anlisis de los procesos necesarios para desarrollar los sub-sistemas correspondientes.
 15

Lo anteior permite que cada responsable o jefe de sub-sistema participe en el proyecto desde la
definicin de la parte que estar a su cargo, lo que procura innumerables beneficios por la
compenetracin en los objetivos perseguidos y en sus implicaciones y por su participacin en la
toma de decisiones respecto de las estrategias y procedimientos que se seguirn. Al estudiar los
procesos de los sub-sistemas puede ser que en todos o en algunos de ellos, hayan sub-objetivos de
los sub-sistemas cuyo logro requiera de procesos que convenga realizar como un todo, lo que
corresponde al concepto de sub-sub-sistema o paquete de trabajo. Al identificar y decidir la
conveniencia de su tratamiento separado, es recomendable elegir y obtener la designacin de los
funcionarios que debern hacerse cargo de la ejecucin de cada uno de ellos, de modo que, al
igual que los responsables o jefes de los sub-sistemas, participen desde el comienzo en las
actividades que estarn a su cargo.

Al definir los procesos de cada sub-sistema, deben establecerse las interfases que tengan con
elementos ajenos a la institucin ejecutora; tambin debe evaluarse la importancia de cada una de
esas interrelaciones, y la forma en que deben materializarse durante el desarrollo del proyecto.

Del mismo modo anotado para los sub-sistemas, los responsables de los paquetes de trabajo, al
definir los procesos correspondientes debern cuidar de establecer las interfases que deben tener
stos, tanto con los otros paquetes de trabajo, como con los otros sub-sistemas y entidades ajenas
a la institucin.

El procedimiento de desglose continuar hasta obtener la identificacin de las actividades ms

finas que conviene definir. En cada etapa de desglose es aplicable la recomendacin de designar
al responsable de ejecutarla, de modo que tambin se aplique a l las ventajas de su participacin
desde el comienzo del proyecto.

No obstante que la forma del grfico piramidal resultante es muy similar a la de la estructura de
organizacin permanente o de rgimen que vemos en la mayora de las instituciones, debe tenerse
presente que su significado es diferente porque aqul representa una divisin por especialidades
funcionales permanentes, en tanto que sta representa el desglose de los objetivos de un proyecto
especfico. Su diferencia radica en que los organigramas, las casillas significan cargos
especficos ordenados verticalmente en relacin al orden jerrquico, y en donde los cargos
colocados en la parte superior, son aqullos donde se ejerce mayor autoridad y los cargos
 16

inferiores corresponden a los niveles de operacin de tareas con menos funciones de autoridad y
ms de realizacin. En el desglose analtico de objetivos se presentan los sub-objetivos
actividades necesarias a desarrollar y que integrados de abajo hacia arriba conforman el objetivo
general.

Este desglose permite tener una visin completa del proyecto ya que se puede llegar a conocer la
totalidad de elementos que intervienen en el logro del objetivo final. Una utilidad adicional
consiste en que si estas actividades se ordenan secuencialmente por procedencia, forman la base
de la planeacin y programacin del Proyecto. Adems a partir de un desglose analtico de
objetivos se puede elaborar la organizacin del proyecto con base a los objetivos del mismo.

La organizacin se disea asignando cargos especficos para cada casilla o grupo de casillas
afines del desglose analtico de objetivos.

El procedimiento seguido para el desglose analtico presenta algunas ventajas que conviene dejar
establecidas. Como ventajas sustanciales aparece el proporcionar una visin acabada hasta el
nivel de detalle que se fije, de los requerimientos del proyecto y de sus interrelaciones.

En particular el procedimeitno proporciona:

i)Un marco para identificar el proyecto en forma separada se las unidades de la organizacin
permanente que deben intervenir en su ejecucin, as como del sistema contable de la institucin
ejecutora, de las fuentes de recursos, o cualquier otro acondicionamiento ajeno a los
requirimientos propios y especficos del proyecto.

ii) Un modelo descriptivo para la ejecucin del proyecto centrado en los objetivos y sub-
objetivos, que ayudan a definir las interrelaciones entre sus componentes y entre stos y el medio
externo.

iii) Un medio para establecer correlaciones entre las especificaciones de cada sub-objetivo.
 17

iv) Una identificacin lgica de las actividades y paquetes de trabajo que interesa controlar, lo
que da una base fundamental para la forma que adoptar en definitiva la organizacin para el
proyecto.

v) Una base racional para decidir la asignacin a cada unidad organizacional que se establezca, de
las actividades que debe cumplir y del personal, mquinas, materiales y presupuesto que
necesitan, as como para la determinacin del tiempo que emplear cada actividad.

vi) Los elementos para estudiar el sistema de informacin y control de la ejecucin a nivel de la
unidad organizacional, del paquete de trabajo del sub-sistema y del Gerente del proyecto.

vii) Un medio para sumarizar las actividades, personal, presupuestos y recursos, en una forma
lgica que facilite la administracin del proyecto.

3. La planeacin de las actividades.

El ejercicio del desglose analtico sirve prcticamente como una lluvia de ideas para ir armando
las diferentes etapas de los procesos que sern necesarios para llegar a los objetivos
operacionales. Su principal aporte es, desde luego, sealar las grandes lneas que debe tener la
organizacin que sirva de soporte para la ejecucin del proyecto; en este sentido, entrega criterios
que pueden ser traducidos de inmediato en acciones prcticas. Sin embargo, el mero desglose
analtico no permite atacar otro problema que es fundamental: el orden cronolgico que deben
realizarse las actividades que se van identificando. Este otro problema se ataca mediante los
procesos de planeacin y programacin.

En la etapa de planeacin, lo que interesa es resolver cualitativamente el problema de la

secuenciacin, analizando las alternativas que presentes. Se trata de establecer las relaciones de
precedencia que son de carcter lgico -por ejemplo, la instalacin de una maquinaria
necesariamente es posterior a su compra y entrega-, e incluso de definir polticas globales a
seguir, de carcter econmico o tecnolgico, -por ejemplo, se harn obras por administracin o se
contratran llave en mano-. En esta etapa se puede ir complementando el desglose analtico ya
que al ir ordenando en el tiempo, o al ir decidiendo politicas, pueden ir surgiendo metas
intermedias que constituyen tareas que debieran estar en el desglose analtico o pudiera ir
 18

apareciendo interrelaciones que lleven a modificar los criterios de agrupacin de sub-sistemas o

de paquetes de trabajo. En una palabra, la planeacin es, prcticamente simultnea y
complementaria con el desglose analtico, -aunque en un informe es ms elegante presentar
primero el desglose y despus la planeacin.

La etapa de programacin consiste en la asignacin de recursos a las actividades planeadas. Es

as una etapa fundamentalmente cuantitativa. El principal recurso que debe asignarse es el tiempo
disponible para la realizacin de cada actividad, y le siguen despus los recursos humanos,
financieros, de equipos, etc. En la etapa de programacin se trata de buscar las formas ms
econmicas de llevar a cabo los planes. Como es lgico, la programacin a menudo seala
aspectos crticos de programacin, o que la abaraten. En la prctica, enconces, planeacin y
programacin son procesos que tienden a fundirse en uno solo,toda vez que se hace difcil
disociar la definicin del qu y cmo hacer algo, de la definicin de quin, cundo, con qu y con
quin.

Ms an al bajar por la pirmide organizacional se da el hecho que las acciones que quedan
programadas a un cierto nivel -es decir, con fecha, responsable etc. , asignados-, son metas a
cumplir para los niveles inferiores y el cumplimiento de estas metas debe ser primero planificado
y luego progrmado a un nivel de desagregacin ms bajo.

Existen varios mtodos para lograr disear la planeacin y organizacin formal del sistema. Uno
de ellos es utilizando el diagrama de flujo, el cual permite pasar el planteamiento de los objetivos
al diseo de interrelacin de los procesos obteniendo los siguientes resultados:

- Interrelacin de los procesos a travs del origen de sus insumos y del destino de sus
efluentes.
- Diseo de la organizacin al nivel de precisin deseado.
- Delimitacin clara y precisa de los sub-objetivos.

El Diagrama de Flujo permite, a travs del anlisis de la transformacin insumo - proceso -

producto, obtener un esquema en el que se pueden identificar:
a)Los sub-objetivos o productos intermedios necesarios para lograr el objetivo o producto
principal a alcanzar o producir, y concordantemente.
 19

b) Los sub-procesos necesarios para lograr un objetivo o producto final.

c) Cules insumos requiere sub-proceso.

d) Cules productos se dan a cada sub-proceso.

e)La interrelacin de los sub-procesos, definida a travs de reconocer en cules sub-procesos se

originan sus insumos, y a cules sub-procesos van los productos, ahora como insumos.

La forma de proceder es muy simple: se trata de tomar las actividades definidas en el desglose
analtico al mayor nivel de desagrecin y organizarlas en forma secuencial, de modo de
representar las relaciones producto-insumo del proceso de transformacin que es la ejecucin del
proyecto; esto es equivalente a pensar que cada actividad terminada entrega algo un producto-
que, o bien es terminal y va al entorno para ser consumido, o bien es intermedio, es decir, es
tomado por otra actividad del mismo proyecto: un insumo. As, en el diagrama, dibujando una
caja para cada actividad del nivel analtico ms desagregado, tendremos que definir mediante una
lnea el destino del producto de cada actividad; estas flechas o van a parar a otra caja, o indican
salida del sistema.

Hay que tener presente que la construccin del Diagrama de Flujo es una prueba de consistencia
de la planeacin. En efecto, si ocurriera, por ejemplo, que una caja del diagrama entrega un
producto que ninguna caja de las definidas previamente est en condiciones de recibir, y ese
producto no es terminal, entonces es claro que falt definir una parte del plan. Del mismo modo,
est mostrando una omisin importante. Estos cabos sueltos en el diagrama sealan de
inmediato las incosistencias; un poco ms difcil es encontrar los errores de planeacin que no se
expresan como cabos sueltos. Uno de esos errores es la existencia de crculos viciosos (loops),
que resultan cuando no hay claridad en el orden secuencial, cosa que sucede a menudo cuando
dos o ms personas tratan de plantear. Otros errores se encuentran recorriendo el diagrama en el
sentido contrario a las flechas, para ver si cada actividad est recibiendo los insumos que
verdaderamente necesita. En fin, un poco de prctica va formando la experiencia necesaria para
planear con cierta soltura, o, al menos, para revisar una planeacin y empaparse del mensaje que
encierra.
 20

Avanzada ya la planeacin, se puede emprender dos tareas, que, aunque simultneas tienden a
reforzarse mutuamente: la programacin y organizacin para la ejecucin del proyecto. Tal como
fue expresado anteriormente, planeacin, programacin y organizacin no son tareas estancas
sino que se avanza en ellas en forma iterativa y simultneas.

4. La programacin de la ejecucin.

Programar es asignar recursos a las actividades planeadas. Para asignar los recursos es preciso
introducir como factor central el uso del tiempo. Respondiendo primero la pregunta del cundo
se necesitan los recursos, es posible atacar luego el problema de quin, puede realizar cada
actividad.

Las tcnicas de programacin ms usadas en los proyectos son las de programacin por redes, en
alguna de sus variantes como PERT, CPM, ABC, PCS, u otras. La fisolofia de todas ellas es la
de asignar tiempos de duracin a cada una de las actividades contenidas en el plan de trabajo y, a
partir de este dato, ir construyendo una serie de derivaciones lgicas, como caminos crticos,
holguras ya sea totales, libres, dependientes o independientes, fechas ms tempranas de inicio,
fechas ms tardas de trmino, probabilidades de cumplimiento de las fechas etc., que dan un
marco para racionalizar la asignacin de recursos, buscando ya sea el diseo de tiempo mnimo o
el del costo mnimo, o el de una probabilidad dada del cumplimiento, alguna mezcla de esos
criterios o de otros que pudieran presentarse.

La metodologa de la programacin por redes parte por establecer la secuencia de actividades en

una manera algo ms estricta de lo que se hizo como planeacin empleando ciertos artificios o
convenciones que son propios del modelo particular de programacin que se est siguiendo. Esta
secuencia permite construir una red, que no es ms que un dibujo de la secuencia lgica, pero
hecho con la simbologa y convencionalismo de un mtodo en especial. La red construida pasa a
ser un modelo del poryecto que hay que realizar. Este modelo es slo una representacin grfica,
hasta que es especificado con datos acerca de la duracin esperada de cada actividad. La
duracin de las actividades puede ser estimada en base a la experiencia previa de quienes hayan
trabajado antes en ellas; las estimaciones pueden ser simples promedios, o pueden ser
 21

distribuciones de probabilidades, de acuerdo con el mtodo que est empleando. Contando ya

con esas estimaciones para cada actividad de la red, empieza el clculo de ella, es decir, se inicia
la aritmtica necesaria para calcular las fechas que resultan de la forma de la red y de las
duraciones previstas. Estas fechas permiten definir caminos crticos, holguras, etc., que luego
puedan ser vertidos a cronogramas de trabajo.

En los cronogramas puede estudiarse el problema de las necesidades de recursos en cada

momento del tiempo, y empezar as a tomar decisiones acerca de quin har cada cosa, cundo la
empezar y cundo deber estar terminada.

Con el clculo de la red se puede entrar a profundizar en el conocimiento que se tiene del
problema que hay que resolver. Este mayor conocimiento permite detectar algunos aspectos que
no haban surgido en la etapa de planeacin. Por ejemplo, ciertas actividades pudiesen ser
desarrolladas con otra tecnologa, tal vez ms cara, pero ahorradora de tiempo. O bien pudiese
ser que la asignacin de un recurso escaso obligue a poner en secuencia actividades que no lo
estaban, segn el anlisis lgico.

En fin, la programacin ayuda a sealar qu aspectos de la planeacin pudieran ser reestudiados.

En este sentido, la programacin no slo es la asignacin de recursos, sino que tambin es la
actividad que permite revisar la planeacin hasta optimizarla, bajo algn criterio establecido.

5. El diseo de la organizacin para la ejecucin del proyecto

Todo el trabajo hecho hasta el momento, de racionalizar el aspecto fsico de la ejecucin de los
proyectos, descansa implicitamente en el supuesto que existen medios organizacionales o
intenciones de cumplir los programas. Sobre la parte de intenciones de ajustarse a un programa,
no es mucho lo que podemos decir, salvo que no es sto algo que pueda darse por sobreentendido,
ni mucho menos. Desgraciadamente, la utilizacin de tcnicas nuevas y la misma racionalidad de
los enfoques, ponen en evidencia a ejecutivos de corte emprico, quienes no siempre tratan de
subirse al carro de las nuevas tecnologas pero, a la vez. boicotean su desarrollo pleno. Esto, si
bien es inevitable, es, al menos, susceptible de ser aminorado, como veremos en las secciones
finales de este trabajo.
 22

El otro aspecto, las suposicin que habra estructuras organizativas capaces de conducir el
proyecto segn lo planificado y programado, puede ser manejado en una forma racional.

El primer punto a considerar para el diseo de la organizacin es la naturaleza de las relaciones

tcnicas entre las labores propias del proyecto, y aquellas de las institucin en cuyo seno se
desarrolla el proyecto. Tenemos aqu dos casos extremos: el de mucha relacin y el de ninguna o
poca relacin. En el primer caso, el proyecto es slo una ampliacin de las operaciones normales
de la institucin, de modo que el proyecto puede desarrollarse dentro de la institucin,
aprovechando parte o todas las estructuras organizacionales existentes. En el segundo caso, -por
ejemplo. construir un comedor para los empleados del Ministerio de Agricultura-, es obvio que no
hay condiciones para ocupar la estructura organizacional permanente en una ejecucin eficiente
del proyecto; se debe montar, entonces, una estructura administrativa separada de la permanente,
y exclusiva para el proyecto.

Este segundo caso es ms fcil de resolver en trminos tericos, aunque presente algunas
complicaciones que es necesario analizar. A primera vista, parecera que la organizacin ideal
puediera ser una genuina organizacin por objetivos, es decir, tomar el cuadro de desglose
analtico y empezar a asignar responsabilidades, segn la cascada de objetivos a cumplir; habr
as un responsable global (el Jefe de Proyecto), varios responsables de los objetivos desglosados
al primer nivel, cada uno de los cuales ir definiendo el personal que necesita y personalizando
responsabilidades; resultarn asi responsables para los objetivos de segundo nivel, quienes
repetirn el proceso de seleccin de personal y nominacin de responsables al tercer nivel. Con
esto se cumplira, aparentemente, con lo que se anda buscando: una organizacin centrada en el
objetivo. Sin embargo, surgen algunos peros, que hay que considerar.

Hay algunos servicios, como la contabilidad, o la misma atencin a los trabajadores del Proyecto
en comedores, que no puede o no conviene que estn muy descentralizados; es necesario, por lo
tanto, crear estructuras organizativas que no responden directamente a los objetivos del plan de
trabajo, sino que son necesarias como apoyo logstico a todos las unidades organizacionales
sustantivas. Esto es fcil de hacer, y en algunos casos es muy claro el carcter que adoptan
estas estructuras de apoyo, pero hay los inevitables casos limites, en que no est claro si conviene
descentralizar. Un jemplo tpico es el de los vehculos y de los talleres de mantenimiento: hay un
permanente debate si acaso debe haber pool de choferes, vehculos y facilidades de reparacin
 23

estn asignados a las unidades sustantivas y los servicios de mantenimiento estn centralizados;
en la prctica se encuentran que en los casos lmites no hay normas claras.

El criterio para resolver estos casos lmites, siempre, el buen sentido: por ejemplo, si una unidad
organizacional va a ocupar, supongamos, un dibujante por toda la vida del proyecto, no es lgico
que ese dibujante pertenezca a una unidad organizacional diferente; en cambio, si los servicios
del dibujante son espordicos, y hay otras unidades que tambin necesitan espordicamente
servicio de dibujo, no es lgico que en cada ocasin se contrate y luego se despida al dibujante,
sino que es preferible que el dibujante pertenezca a una unidad de apoyo que d servicios a los
dems: as se le aprovechar mejor.

De acuerdo a este criterio, para cada objetivo habra que ubicar primero, todas las unidades
necesarias para alcanzarlo y estudiar luego la carga de trabajo de cada una de ellas, a fin de
determinar si es preferible dejar cada unidad detectada adscrita solamente a ese objetivo, o si es
preferible juntar algunas similares en una sola, fuera de la estructura por objetivos y en funcin de
apoyo. Esta estructura tcnica de apoyo sera similar a la estructura administrativa de apoyo
logstico.

Las unidades separadas pasan a construir unidades funcionales de apoyo a los sub-sistemas
operativos, con la misin de dar a cada uno de ellos el servicio que necesitan en el momento
oportuno esto implica la necesidad de una programacin cuidadosa de las fechas en que deben
trabajar para cada sub-sistema operativo y la totalizacin de la demanda de recursos para servir a
todos ellos en cada perodo, de modo de asegurar que pueden atender todas las demandas que
reciben.

De este modo, el criterio fundamental para discernir cules unidades se integran a un sub-sistema
operativo y cules se separan como unidades de apoyo, estar dado por el grado de exclusividad
de servicio a un sub-sistema operativo o por la posibilidad de crear dos o ms unidades similares,
cada una con pleno empleo en los correspondientes sub-sistemas operativos.

El modo de relacionarse de las unidades sustantivas o por objetivos, con las unidades de apoyo
tcnico, da lugar a la llamada organizacin matricial, que tiene diversas variantes. Lo que
caracteriza a estas relaciones en el grado de ambigedad que se crea es una aparente doble
 24

dependencia del personal tcnico de apoyo: por un lado pertenece a una unidad, -que tiene un
jefe, quien debe evaluar rendimientos, dar estmulos, promover etc.-, mientras que por otro lado,
en un momento determinado est realizando un trabajo para otra unidad, -a menudo, fsicamente
instalado en ella-, que tambin tiene sus procedimientos de evaluacin de trabajo. Esta
ambigedad debe resolverse, ya sea en trminos que lo que la entidad de apoyo presta sean las
personas u equipo, que pasan a depender de la unidad sustantiva en forma temporal, o bien que
preste servicios terminados, manteniendo la unidad de apoyo el mando sobre personas y equipo y
responsabilizndose del trabajo realizado, cosa que no ocurrira en el modo anteior: es la
diferencia que existe entre alquilar una casa y vivir en un hotel.

Como puede apreciarse, hay muchas alternativas que pueden combinarse en el diseo de una
organizacin. La decisin que se tome deber contemplar la naturaleza del trabajo, la economa
de recursos, la personalidad de los involucrados, etc., lo cual abre un amplio campo creativo en
bsqueda de las soluciones ms eficaces; es decir, se puede practicar aqu la parte artstica de la
ciencia del diseo administrativo.

Es evidente que el diseo de la organizacin en los casos de proyectos que tienen estructura
administrativa propia y exclusiva es ms sencillo que en el caso inverso, en que el proyecto se
desarrolla en el seno de una institucin-madre, que ya tiene una organizacin-formal e informal-,
que sirve a propsitos distintos al proyecto, pero que cuenta con unidades administrativas que
coiciden con las que aparentemente necesitan el proyecto.

En este caso, se parte con un pie forzado, pues una parte del diseo ya est hecho, -bien o mal-, y
debe considerarse como dato del problema. Aqui pueden suceder muchas cosas, que van desde
una situacin en que la estructura permanente se traga el proyecto, perdiendo ste su identidad
organizativa y reduciendo a su jefe a una figura decorativa; hasta el caso inverso, en que el
proyecto tiene gran respaldo y maneja tantos recursos que termina por subvertir la organizacin
madre, al exigirle esfuerzos para los cuales no est preparada. Estas son situaciones extremas,
desde luego, pero de comn ocurrencia; tambin hay situaciones intermedias donde hay ms
equilibrio entre lo que significa el proyecto y la estructura administrativa propia de l-, con lo que
significa la estructura permanente de la organizacin madre, especialemnte con la parte de ella
que da servicios al proyecto.
 25

El tipo de problemas que nace ahora es que partes importantes del proyecto escapan totalmente al
control del jefe del proyecto, o de los jefes que reportan al jefe del proyecto. Los responsables
del proyecto deben negociar entonces con jefes de igual nivel jerrquico la obtencin de los
servicios o de las personas que necesitan, lo cual cambia apreciablemente sus funciones. El tipo
de relaciones que se establecen entre la organizacin madre permanente y la estructura encargada
del proyecto, es tambin de carcter matricial, pero con un grado mayor de complejidad, ya que
los servicios de apoyo tienen ahora otras funciones que cumplir, -adems de apoyo al proyecto-,
funciones que son ms permanentes y, por lo mismo difciles de desatender.

Dejaremos hasta aqu los comentarios acerca del diseo de la organizacin que debe ajustarse a
la realidad de la institucin madre, entendiendo por realidad los aspectos formales e informales, a
fin de sacar de una situacin que no es ptima para el proyecto, el mayor partido posible.

6. La asignacin de responsabilidades en tareas concretas

El diseo de organizacin que se logre, siguiendo cualesquiera de las modalidades que recin
mencionbamos, no es ms que un esquema rgido, que sirve como marco de referencia para
poner en la actividad cotidiana. Este marco es valioso en cuanto permite orientar la resolucin de
problemas en general, pero no es muy adecuado para resolver las cosas en detalle; esto es
frente a una actividad en particular, definir quin debe ser informado, quin hace el trabajo,
quin supervisa, etc.

Muchas veces estos aspectos parecen demasiado minuciosos y no son sometidos a anlisis; y no
se prev un diseo para ellos, pero tambin se ha encontrado, en la prctica, que muchos de los
problemas de coordinacin operativa, e incluso, muchos de los roces personales u
organizacionales, se deben a que estos detalles obvios no haban sido resueltos, y se haban
creado situaciones de malentendidos o de celos, duplicaciones u omisiones, tan lamentables como
evitables. La prctica aconseja, pues, no considerar tan obvio lo trivial y darle alguna atencin a
definir con mucha claridad los roles a cumplir con los distintos participantes en algunas acciones
administrativas. Esto especialmente vlido para el caso de las relaciones matriciales.

La definicin de roles se realiza mediante dos instrumentos: la descripcin de funciones de cargo,

que recoge en forma genrica lo que se espera que sean las responsabilidades de cada jefe, y, en
 26

forma -ms especfica, las matrices de responsabilidad por tarea. Estas ltimas son cuadros de
doble entrada, en los cuales se cruzan los nombres de las unidades organizacionales contra el
listado de las tareas por hacer, con gran desagregacin. Empleando una clave, en la interseccin
de cada cargo y cada tarea, se seala el tipo de responsabilidad especfica de este cargo con
respecto a esa tarea; por ejemplo: ejecuta el trabajo, recibe informacin, toma decisin, etc.

Las matrices de responsabilidad por tareas, o grficos tarea- responsabilidades, son de gran
utilidad para el diseo en detalle y constituyen un instrumento valiossimo como complemento de
la descripcin de responsabilidades genricas de cada cargo. En particular, su uso se justifica por
la naturaleza transitoria de la organizacin para la ejecucin de proyectos; en el caso de
regmenes permanentes, es la constumbre o el hbito, quien se encarga de establecer los modos de
relacionamiento dentro de la organizacin, la cual se va acomodando en base a la experiencia
repetida; en cambio, como dijimos anteriormente, en el caso de los proyectos, no hay ocasin de
desarrollar y consolidar estos hbitos, por lo cual se necesita reemplazar el procedimiento de
acomodo paulatino por el diseo previo.

7. El diseo del sistema de informacin y control

El diseo de organizacin que hemos venido comentando en las pginas anteriores, slo logra dar
una visin esttica, que corresponde a presuponer que el programa de trabajo que se logr disear
va a ser cumplido con toda precisin. La realidad es diferente: siempre un programa es la mejor
estimacin que podemos realizar acerca de lo que viene ms adelante, pero multiplicidad de
factores hacen que, luego, esas estimaciones no se cumplan exactamente. Resulta as que el
desarrollo real de la ejecucin de las actividades del programa difiere, por lo general, de lo
programado. Esto es inevitable y no anula la programacin, desde luego, sino que, lo contrario, la
justifica.

Frente al hecho de la imposibilidad del cumplimiento exacto de los programas, se plantea la

necesidad de conocer, oportunamente, a lo largo del desarrollo del programa., la medida en que la
ejecucin real se va apartando de lo programado a fin de tomar las medidas correctivas que sean
necesarias. Esto es lo que se llama control de ejecucin del proyecto
 27

El control se basa en un procedimiento de tres etapas: a) medicin del avance real de la

ejecucin, b) comparacin con el programa previo y evaluacin de la gravedad de las
divergencias y c) adopcin y puesta en marcha de las acciones correctivas que sean del caso.

Para poder desarrollar este control, se cuenta, segn lo que hemos tratado hasta el momento, con
una programacin de referencia y con un esquema organizativo que establece a quin compiten
ciertas responsabilidades; lo que nos falta es disear un sistema de informacin que permita que
i)se realicen las mediciones de avance real, cundo, dnde, cmo y por quin corresponda; ii) los
datos recogidos sean transportados y procesados adecuadamente, a fin de poder evaluar el avance
real contra el programado; iii) los resultados de las evaluaciones, si son desfavorables, sean
comunicados a los afectados, para la adopcin de decisiones correctivas, y iv) las decisiones
tomadas sean transmitidas a los responsables de ponerlas en prctica y a los responsables de
mantener al da la programacin. Todo esto recibe el nombre de diseo del sistema de
informacin y control para la administracin de la ejecucin del proyecto.

El subsistema de informacin y control dentro del sistema organizativo general, necesita un

centro orgnico que lo atienda. La Unidad de Programacin y Control viene a ser como el centro
nervioso al cual concurren todas las informaciones sobre avance del proyecto, para ser odenadas e
interpretadas a fin de evaluar los avances, en tiempo para tomar decisiones correctivas. Aqu el
nfasis se pone en el sentido de oportunidad: para que se pueda ejercer control, la informacin
debe ser recibida, procesada e interpretada, mientras haya tiempo aun de corregir lo que va mal; y
no esperar constatar que algo sali mal ya, para buscar modos de contrarrestar los efectos nocivos
que este mal resultado pueda tener. Lo que se busca es prevenir mayores problemas, en vez de
reparar daos ya causados.

Esta concepcin del tiempo y la oportunidad choca, a veces, con sistemas ms tradicionales que
vinculan la informacin con la contabilidad.

Por gil que sea un sistema contable, siempre va a ser ms lento que un sistema solamente de
informacin, y, en algunos casos, esa diferencia de velocidad puede redundar en atrasos en tomas
de decisiones que pueden ser muy caros. Esto no quiere decir que los sistemas contables no
sirvan o no sean parte del sistema de informacin y control; solamente seala que hay dos tipos
 28

de variables que controlar: el avance fsico, vigilado por la Unidad de Programacin y Control, y
el avance financiero, controlado a travs de la Contabilidad.

La programacin financiera debe ser una transcripcin de la programacin fsica a trminos

financieros. Los cronogramas de trabajo de avance fsico, y stos, en cronogramas de pagos de
esos recursos, los cuales se resumen en un presupuesto. Este presupuesto de desembolso se
contrabalancea con un presupuesto de entradas, que normalmente adquiere la forma de un
compromiso con una o ms entidades financistas. El control financiero consiste, entonces, en
cuidar que los desembolsos reales sigan el ritmo convenido con el financista, a fin de no tener
problemas de falta de recursos monetarios; esto se puede lograr con una combinacin de
manipulacin de la fecha de desembolsos especficos, -dentro de ciertos lmites-, y acuerdos de
reprogramacin, celebrados oportunamente con los financistas.

Un problema especial que presenta el control contable-financiero es que las categoras de anlisis
que interesan al financista difieren de las categoras de anliss que maneja el ejecutor del
proyecto. De aqu que la contabilidad deba ser diseada en funcin de las necesidades de
informacin que tiene el financista -con los agregados necesarios para uso del ejecutor, desde
luego-. As, por ejemplo, al ejecutor le interesara saber en qu se deben hacer los pagos del
equipo y en qu moneda.

Este distinto enfoque de cul es la informacin necesaria y cmo debe registrarse es el que hace
recomedable separar el sistema de informacin del avance fsico del sistema contable, aunque las
decisiones correctivas que se apliquen como producto del control ya sea fsico o financiero,
tengan que tomar en cuenta la realidad global del proyecto. Del mismo modo, el control de
algunas variables, como inventarios, por ejemplo, cae a medio camino entre el control fsico y el
financiero, lo cual hace que no pueda divorciarse estos tipos de control. Es la realidad concreeta
de cada proyecto la que recomendar la forma de organizar el control.

8. El Manual del Proyecto

Una vez que est completo el trabajo de diseo hay que preocuparse por hacer conocidas la
organizacin y el plan de trabajo. Esto significa generar un documento que recoja nombres de
responsables, atribuciones, delimitaciones de autoridad, fechas de compromisos, cifras,
 29

diagramas, etc. El Manual de Proyectos debe constituirse as en un instrumento de trabajo, que

permita que cada quien conozca con seguridad cul es su papel y su responsabilidad dentro de la
organizacin que debe ejecutar el proyecto.

El Manual debe irse preparando a medida que avanza el diseo administrativo; a su vez, la
preparacin del Manual sirve de gua para verificar que se han atendido todos los detalles del
diseo administrativo.

9. Preocupacin por el ambiente de trabajo.

Las secciones anteriores han ido recogiendo algunas de las facetas ms tcnicas en lo que se
refiere al diseo administrativo para la ejecucin de un proyecto. Varias consideraciones caben
aun, pero que no se refieren a aspectos especficos, sino al conjunto de la organizacin con que se
cuente para ejecutar el proyecto.

En primer lugar, una organizacin est compuesta por seres humanos. El mejor diseo
administrativo, la mejor programacin o el mejor sistema de informacin, fallan si no se logra
desarrollar un ambiente de trabajo estimulante, que permita desarrollar creatividad e iniciativa.
Por su propio carcter de obra nica, no repetitiva, un proyecto necesita esos aportes creativos
pero muchos ms necesitan un ambiente favorable, las personas que hacen posible la ejecucin
del proyecto. Pasar a llevar a la gente, no consultar opiniones, menospreciar al nacional frente al
extranjero o viceversa, dar ms credibilidad al extrao que al local, actuar con prepotencia,
promover con arbitrariedad etc., son cosas que no pueden evitarse con un diseo administrativo,
sino que forman parte del ambiente cultural que se desarrolla en el interior de la organizacin.
Este ambiente no puede ser descuidado, porque de l depende en gran medida el xito de la
administracin de la ejecucin del proyecto.

Muy relacionado con lo anteior est la flexibilidad del diseo. Un proyecto pasa por varias fases
a lo largo de su ejecucin, lo cual hace que toda la organizacin tenga una dimensin temporal
variable, pero no es recomendable un cambio contnuo de las personas o de sus atribuciones, lo
cual hace que, necesariamente, haya que adaptar funciones a las personas existentes en la
organizacin. Esto puede parecer paradgico, pero no lo es: en los estados de rgimen, las
funciones son estables, de modo que hay que buscar las personas ms idneas para trabajos
 30

determinados; en cambio en los proyectos, las caractersticas de los trabajos varan con rapidez y,
-dentro de ciertos lmites-, es preferible distribuir con flexibilidad la carga entre la gente
disponible en forma estable en la organizacin, que despedirla y contratar nueva gente por
perodos cortos. Lo que pueda perderse en eficiencia se gana en ambiente: dedicacin y
mstica.

En este mismo sentido, la magnitud del esfuerzo del diseo administrativo tiene que estar en
relacin con el tamao y complejidad del proyecto. Es obvio que en un proyecto pequeo, en que
trabaja media docena de personas, la comunicacin entre ellas es muy personal y que no se gana
mucho con un Manual elaboradsimo; en este caso, -y atendiendo a lo sealado en el prrafo
anteior-, se desarrolla una organizacin informal que refleja la interaccin de las personalidades
del equipo, y esto trasciende cualquier intento de reglamentar relaciones mediante un diseo
exhaustivo. Por otro lado, en proyectos granges y complejos, con gran cantidad de gente; no hay
posibilidad de interrelacin estrecha de todos los involucrados, las relaciones de trabajo son ms
impersonales y es necesaria la definicin de roles y responsabilidades. Un proyecto cualquiera
cae en algn punto del espectro de tamaos y complejidad; es imposible definir normativamente
cunto diseo formal necesita para operar eficazmente: ste debe de ser un juicio de su jefe
responsable. Una muy baja especificacin de funciones y responsabilidades puede provocar
confusin y frustracin. Una excesiva formalizacin puede crear ambientes depersonlizados y
poco estimulante.

Como en todo trabajo de diseo, es posible que, por mucho cuidado que se haya puesto, se hayan
cometido errores que la experiencia diaria se encargar de poner en manifiesto. Aqu hay que
tener mucho criterio para distinguir los casos en que lo que corresponde es actuar sobre la
realidad, para apegarse a lo que seala el diseo previo; y en caso en que lo que hay que hacer es
variar el diseo para que interprete ms fielmente el contexto real. El primer caso es el caso
tpico del control, en que se introducen medidas correctivas para cumplir un programa
determinado. Pero hay otros casos en que lo que ocurre no es una desviacin de lo real frente a lo
programado, sino un error de programacin, que uno puede corregir, reconocindolo, o puede
ocultar, culpando a la realidad de desviarse. Es necesario mantener una posicin sana y madura
frente a esta alternativa: cualquier diseo debe de estar sujeto a la crtica de la experiencia y ojal
que esta crtica sea una autocrtica. Esto contribuye a mejorar los ambientes de trabajo.
 31

Nunca est de ms pensar que la gente que trabaja en un proyecto quiere conocer los objetivos de
lo que est heciendo, los avances que se van logrando, las dificultades que hay que superar etc.
Del mismo modo, es necesario premiar a quienes se destacan excepcionalmente y darlo a conocer
al resto. La gente puede comprometerse en campaas de embellecimiento, de prevencin de
accidentes, de ahorro de materiales etc., y esto es algo que debe buscarse y, una vez obtenido,
estimularse.

La conclusin de todo esto es que el diseo, como simple ejercicio de ingeniera administrativa,
pueda resolver parte de los problemas organizativos; pero que otra parte depende del nivel de las
relaciones humanas que logren darse en la organizacin y que hay veces en que conviene relajar
los diseos a fin de ganar puntos en ambiente de trabajo.

Tomado de: Diseo Administrativo para la Ejecucin

de Proyectos - Casos y Ejemplos. ICAP - BID,
San Jos Costa Rica 1979.

Preparado por: Ing. Rigoberto Ovidio Magaa Barrientos

Proyecto ELS/89/001 - PNUD/DTCD/BID