Introduccion Gestion Proyectos

MSTER EN DISEO,
GESTIN Y DIRECCIN DE
PROYECTOS
MSTER EN DISEO,
GESTIN Y DIRECCIN DE
PROYECTOS
G10: Introduccin a la Gestin de
Proyectos
ndice
Introduccin a la gestin de proyectos
1. Introduccin ..................................................................
................................ 1
2. Concepto ....................................................................
................................... 3
2.1. Persecucin de uno o varios objetivos .......................................
.............. 4
2.2. Actividades planificadas, ejecutadas y supervisadas .......................
.......... 4
2.3. Disponibilidad limitada de recursos .......................................
.................. 4
2.4. Limitacin de tiempo ........................................................
...................... 4
3. Clases de proyectos .........................................................
............................... 5
3.1. Criterios de proyectos ....................................................
........................ 5
3.2. Por objeto ................................................................
............................. 5
3.2.1. Proyecto clsico ..........................................................
................ 5
3.2.2. Proyecto de investigacin .................................................
............ 6
3.3. Por actividad .............................................................
............................ 6
3.3.1. Estudios y anlisis .......................................................
................ 6
3.4. Por rol del usuario .......................................................
.......................... 6
3.4.1. Proyecto externo ........................................................
................ 6
3.4.2. Proyecto interno ........................................................
................. 7
3.5. Por campo de ingeniera .....................................................
.................... 7
3.5.1. Productos naturales. Ingeniera agronmica, oceanogrfica,
forestal y minera ..............................................................
........... 7
3.5.2. Infraestructuras y edificaciones. Ingeniera civil, construccin ........ 7
3.5.3. Productos manufacturados. Ingeniera industrial, mecnica,
electrnica, automtica, qumica, aeronutica, naval ..................... 7
3.5.4. Servicios/sistemas ligados a ingeniera elctrica, energa,
telecomunicacin, informtica ......................................................
7
3.6. Por naturaleza del resultado ..............................................
..................... 8
3.6.1. Proyecto de ingeniera.....................................................
............. 8
3.6.2. Proyecto industrial .....................................................
................. 9
INTRODUCCIN A LA GESTIN DE PROYECTOS
3.6.3. Otra clasificacin de los proyectos industriales podra ser ............... 1
1
4. Fases genricas de un proyecto ................................................
....................... 12
4.1. Fase de definicin ..........................................................
........................ 14
4.1.1. Definicin del proyecto ...................................................
............. 14
4.1.2. Deteccin de una necesidad, problema o rea de oportunidad ........ 15
4.1.3. Estudios de prefactibilidad o previabilidad .............................
........ 17
4.2. Fase de concepcin ..........................................................
...................... 17
4.2.1. Concepcin ................................................................
................. 18
4.2.2. Estudios previos ........................................................
.................. 19
4.2.3. Seleccin de proyecto .....................................................
............. 34
4.2.4. Aprobacin del proyecto ...................................................
........... 34
4.2.5. Estructura de descomposicin del proyecto (EDP) ..........................
42
4.3. Fase de construccin ........................................................
...................... 43
4.3.1. Planificacin de actividades y recursos ...................................
....... 43
4.4. Fase de puesta en marcha ..................................................
.................... 57
4.4.1. Ejecucin del proyecto ....................................................
............. 57
4.4.2. Alternativas para la ejecucin del proyecto ...............................
..... 62
4.5. Fase de cesin ..............................................................
......................... 64
4.5.1. Transferencia de la unidad de actuacin (o proyecto)
al cliente / usuario ...........................................................
............ 65
5. Gestin de proyectos ..........................................................
............................. 68
5.1. Introduccin ................................................................
.......................... 68
5.2. Gestin de proyectos ........................................................
...................... 68
5.2.1. Nocin de gestin de proyectos ..............................................
...... 69
5.2.2. La gestin de proyectos segn el PMBOK ......................................
71
5.2.3. Estados de una mala gestin de proyectos ..................................
.. 92
5.2.4. Razn de la gestin de proyectos ............................................
..... 94
5.3. Herramientas y tcnicas de gestin ............................................
............. 96
5.3.1. Iniciacin ................................................................
.................... 96
5.3.2. Planificacin .............................................................
................... 98
5.3.3. Control y seguimiento ...................................................
............... 115
5.3.4. Cierre ..................................................................
....................... 126
5.4. Modelos de madurez de gestin de proyectos ..................................
......... 127
5.4.1. Capability Maturity Model ...............................................
.............. 127
5.4.2. Modelos de madurez ......................................................
.............. 129
5.4.3. Implantacin de la madurez ................................................
......... 134
6. Conclusiones ................................................................
.................................. 136
Anexo
1. Sistema de la calidad (ISO 9000-9004) .......................................
..................... 141
1.1. El plan de calidad del proyecto ...........................................
.................... 144
1.2. Objetivos de la calidad ...................................................
........................ 144
1.3. Autoridad y responsabilidad ...............................................
..................... 144
1.4. Mtodos de trabajo y programas de inspeccin ..................................
...... 146
1.5. Metodologa para cambios y otras medidas ....................................
.......... 146
1.6. Documentacin del plan de calidad ...........................................
.............. 146
2. El estudio de viabilidad ....................................................
............................... 147
2.1. Cmo alcanzar el objetivo? ...................................................
................ 148
2.2. Parmetros de un proyecto viable ............................................
............... 148
2.3. Contenido de un estudio de viabilidad .....................................
................ 148
2.4. Factores que pueden diferenciar los estudios de viabilidad ................
........ 148
2.5. Fases que debe contener un estudio de viabilidad ..........................
.......... 148
2.5.1. Resumen operativo .......................................................
.............. 149
2.5.2. Antecedentes e historial del Proyecto ...................................
........ 150
2.5.3. Estudio de mercado ......................................................
.............. 150
2.5.4. Estudio tcnico ...........................................................
................ 152
2.5.5. Marco legal y social en la evaluacin de proyectos ........................
. 158
2.5.6. Estudio econmico .........................................................
............. 159
2.5.7. Evaluacin econmica ........................................................
......... 159
Bibliografa
INTRODUCCIN A LA
GESTIN DE PROYECTOS
O B J E T I V O S
- Conocer los aspectos esenciales que definen una Teora de Proyectos, reconociend
o los tipos de proyectos
existentes, para as poder identificar y definir las fases de un proyecto, con el
apoyo de herramientas de
planificacin y programacin de proyectos.
- Una vez concluido este captulo tendremos un enfoque general, para entender de f
orma rpida y sencilla, los
pasos a seguir para llevar a cabo un proyecto.
- Comprender la nocin de proyectos y el rol que ocupa el PMBOK en la constitucin d
e un cuerpo doctrinal
internacional de gestin de proyectos.
- Conocer algunas de las principales herramientas y tcnicas empleadas en la gestin
de proyectos.
- Conocer el rol de los modelos de madurez de gestin de proyectos y comprender la
importancia
1. INTRODUCCIN
A lo largo de la historia, la preocupacin del hombre por la naturaleza de todo lo
que le
rodea ha pasado por distintas etapas y sufrido importantes cambios.
Figura 1.1: Evolucin del hombre.
Con la llegada del Renacimiento aparece una enorme curiosidad por la naturaleza
y el
mundo que le rodea, surgiendo la inquietud de profundizar en las cosas para
comprenderlas mejor mediante unos esquemas muy simplistas.
As y en los comienzos del Renacimiento, nace el mtodo del anlisis, el cual, permite

trabajar actuando en tres etapas sucesivas:
a.
Se separa el todo en las partes que lo constituyen.
b.
Se estudia el comportamiento de cada parte.
c.
Se vuelven a ensamblar todas las partes, que aisladamente ya se han
entendido, tratando de comprender el conjunto.
El anlisis ha sido el mtodo de trabajo tpico y esencial de la Edad Moderna y de la
revolucin Industrial, y la adopcin de ese mtodo frente a los problemas del universo

ha llevado en filosofa a la teora del reduccionismo:Todo puede reducirse a partes
fundamentales, que no pueden reducirse ms.
Con el tiempo, esta necesidad de resolver un problema por partes, exponiendo un
proceso racional y cientfico, llev a definir etapas cada vez ms establecidas y
definidas, dando lugar a metodologas y procesos de trabajo. Todo esto, de forma
natural, llev a identificar pasos de resolucin de problemas, cuyo cumplimiento fre
nte a
las necesidades sociales y las limitaciones tecnolgicas, requera un esfuerzo de
organizacin. As, se llega a la idea de un proyecto.
2. CONCEPTO
Entendemos como proyecto el conjunto de actividades planificadas, ejecutadas y
supervisadas que, con recursos finitos, tiene como objetivos crear un producto o

servicio nico.
En trminos ms formales, Un proyecto es una operacin de envergadura y
complejidad notables, singular, con unas fechas definidas de inicio y finalizacin
. Es un
trabajo no repetitivo, que ha de planificarse y realizarse segn unas especificaci
ones
tcnicas determinadas, con un presupuesto preestablecido y una organizacin temporal

con la participacin de varios departamentos de la empresa que se desmantela cuand
o
termina el proyecto y tal vez tambin con la colaboracin de terceros.
Otras definiciones, dadas por otros autores, as como las caractersticas de los
proyectos son:

Los proyectos involucran una gran cantidad de tiempo y costo, que es necesario el

involucramiento del control de la administracin para ser cumplido dentro del
tiempo y los lmites de costo... las tcnicas dirigidas hacia el control de los cost
os,
tiempo, recursos y financiacin del proyecto durante el proceso.
Operacin cientfica que lleva a conseguir un objetivo material predeterminado por
modificaciones de la realidad exterior mediante unas acciones humanas que han
sido seleccionadas y ordenadas con anticipacin, de acuerdo a unos criterios.
(Gestin Integrada de Proyectos, Serer Marcos, 2001).
Planta y disposicin que se forma para un tratado, o para la ejecucin de una cosa
de importancia, anotando y extendiendo todas las circunstancias principales que
deben concurrir para su logro. (Diccionario de la Real Academia de la Lengua
Espaola).
Conjunto
de documentos que a partir de una situacin concreta permiten
transformar una realidad en un perodo de tiempo determinado. (De Cos y Trueba,
1990).
Estos conceptos emergen de observar que las tareas humanas se organizan bajo cie
rtas
condiciones, cuyo manejo y aprovechamiento prefiguran las cualidades que afectan

todo proyecto. Estas cualidades son:
2.1. PERSECUCIN DE UNO O VARIOS OBJETIVOS
Las actividades aisladas no constituyen por s solas, un proyecto. Para que exista
un
proyecto, debe existir una coordinacin de actos orientados a la consecucin de uno
o
varios objetivos, integrados entre s y estructurados, tanto de ndole tcnica como
econmica. En general, el objetivo general de un proyecto es satisfacer un conjunt
o de
requisitos a un coste dado en las condiciones ms eficientes.
2.2. ACTIVIDADES PLANIFICADAS, EJECUTADAS Y SUPERVISADAS
La coordinacin de actividades es condicin sine-qua-non (sin una secuencia) para qu
e a
las mismas, en su conjunto, se les pueda calificar de proyecto. De hecho, un pro
yecto
exige que exista vinculacin entre las actividades, puesto que persiguen un objeti
vo
comn. Esa vinculacin debe plasmarse en forma de planificacin (tcnica, temporal y
econmica) cuya correcta ejecucin supervisada es clave para el xito o fracaso del
proyecto.
2.3. DISPONIBILIDAD LIMITADA DE RECURSOS
El proceso proyectual implica la bsqueda de la eficiencia en el uso de los recurs
os para
obtener el resultado perseguido. Si los recursos son ilimitados, desaparece el c
oncepto
de eficiencia y con l la naturaleza proyectual de las actividades.
2.4. LIMITACIN DE TIEMPO
Un proyecto debe estar acotado en trminos del principio y el fin mismo. El final
de un
proyecto se alcanza cuando se cumplen los objetivos prefijados, o cuando se hace

evidente que dichos objetivos no pueden alcanzarse (fracaso del proyecto). Por o
tro
lado, aunque el proyecto tenga que estar acotado en el tiempo, no sucede lo mism
o con
sus resultados, que pueden perdurar con carcter indefinido (por ejemplo, una cate
dral).
Con esto, los proyectos, se caracterizan por:
-Tener objetivos especficos;
-Deben completarse dentro de un periodo determinado;
-Tener inicios y trminos bien definidos;
-Deben completarse dentro de las restricciones de un presupuesto;
-Ser ejecutados por un equipo; y,
-Ser nicos.
3. CLASES DE PROYECTOS
El concepto de Proyecto puede presentar concepciones diferentes segn mentalidades
y
modos de hacer en los distintos mbitos profesionales. Existen dos ramas profesion
ales
estrechamente vinculadas al mundo de los proyectos y a los procesos de decisin: l
os
ingenieros (tcnicos) y los empresarios (promotores, evaluadores y gerentes) que
pertenecen a campos profesionales donde es posible encontrar deformaciones en su

concepto de proyecto, generalmente asociadas a visiones restrictivas de la reali
dad.
Clasificar un proyecto concreto no es sencillo, ms bien es complejo, pues su vari
edad
y diversidad es muy alta. Sin embargo, es posible sugerir una tipologa general
dependiendo de algunos criterios.
3.1. CRITERIOS DE PROYECTOS
La tipologa general aqu presentada utiliza criterios de distincin:
Por objeto, o por el objeto que esta tratando el proyecto;
por actividad, o dependiendo de alguna fase en el ciclo de vida de un producto;
por rol del usuario, por el contexto en el cual se desarrolla el proyecto;
por campo de ingeniera, o por la disciplina, ciencia y/o tcnica que predomina en e
l
proyecto;
por naturaleza del resultado, o por el tipo de producto a obtener.
Nota: Debe aclararse que estos criterios ni son todos ni son determinantes.
3.2. POR OBJETO
3.2.1. Proyecto clsico
Se aborda la realizacin de una serie de documentos que define la obra o trabajo a

realizar para su ejecucin en un futuro. El alcance comprende la identificacin,
evaluacin, organizacin y valoracin de las actividades que faltan para conseguir o
culminar el resultado perseguido, pero en su alcance no est comprometida la
realizacin de las mismas. El resultado es una memoria, unos planos, un pliego de
condiciones y un presupuesto y, a lo sumo, un prototipo o maqueta del objeto en
cuestin.
3.2.2. Proyecto de investigacin
Su objetivo es aportar en su conclusin un conjunto de conocimientos nuevos en una

disciplina y materia concreta, a menudo desconocida al comienzo de los trabajos.
Su fin
es que otros se vean beneficiados, sea en entornos industriales o acadmicos. El
resultado es una memoria de investigacin donde, aparte del planteamiento del
problema a resolver y la descripcin del estado del arte, se resean los trabajos
realizados, los resultados de los mismos y las conclusiones pertinentes, junto c
on las
lneas de investigacin futuras propuestas en esa disciplina concreta.
3.3. POR ACTIVIDAD
3.3.1. Estudios y anlisis
En ocasiones el alcance de un trabajo concreto se limita a analizar o estudiar l
a
informacin disponible acerca de los aspectos tcnicos, econmicos, ambientales y
sociales de un determinado problema. En este caso el proyecto recibe el nombre d
e
estudio (comprensin o conocimiento del problema o anlisis (examen del problema par
a
comprender los principios del mismo).
Estudios de viabilidad
Los estudios de viabilidad deben proporcionar la base-tcnica, econmica y comercial

para la decisin de invertir en un proyecto industrial. En estos estudios se deben
definir
y analizar los elementos crticos relacionados con la fabricacin de un producto dad
o,
junto con otros enfoques posibles a tal produccin. Un estudio de este tipo debe d
ar por
resultado un proyecto con capacidad de produccin definida en un emplazamiento
seleccionado, utilizando una o varias tecnologas determinadas en relacin con
materiales e insumos especficos con costes de inversin y produccin identificados, e

ingresos por concepto de ventas que produzcan un rendimiento determinado respect
o
de la inversin.
3.4. POR ROL DEL USUARIO
3.4.1. Proyecto externo
Los proyectos externos a la organizacin son aquellos en los que el cliente es aje
no a la
empresa, que hace los trabajos. Se rige fundamentalmente por criterios de mercad
o,
incluyendo competitividad y eficacia.
3.4.2. Proyecto interno
Los proyectos internos a la organizacin, son aquellos en los que el cliente es de
la
misma empresa que desarrolla los trabajos.
3.5. POR CAMPO DE INGENIERA
Por campo de ingeniera, se tienen proyectos diversos:
3.5.1. Productos naturales. Ingeniera agronmica, oceanogrfica, forestal y
minera
La obtencin de productos naturales requiere unos proyectos muy en contacto con el

medio que se va a tratar, con mucho trabajo de campo y la necesidad de un gran
soporte documental, pero con escasa interrelacin entre los equipos y mquinas
necesarios, lo que evita la necesidad de una definicin minuciosa de los mismos qu
e
condicione las fases posteriores del trabajo.
3.5.2. Infraestructuras y edificaciones. Ingeniera civil, construccin
La construccin de infraestructuras y edificaciones de todo tipo se apoya en disci
plinas
fundamentales como topografa, geotecnia y resistencia de materiales, y exige
proyectos detallados con profusin de clculos y planos, pero cuya ejecucin es
prcticamente independiente, en el tiempo, de los documentos que configuran el
proyecto.
3.5.3. Productos manufacturados. Ingeniera industrial, mecnica,
electrnica, automtica, qumica, aeronutica, naval
Los productos manufacturados exigen unos proyectos muy complejos, con muchas
disciplinas implicadas y numerosos equipos, mquinas y aparatos interconectados, q
ue
exigen gran atencin y abundantes especificaciones.
3.5.4. Servicios/sistemas ligados a ingeniera elctrica, energa,
telecomunicacin, informtica
En este caso hablamos de productos cuya esencia es intangible, por su naturaleza

inmaterial que dificulta su manipulacin corprea.
3.6. POR NATURALEZA DEL RESULTADO
Proyecto de ingeniera. En este caso estamos ante un proyecto de accin, donde
esencialmente se persigue resolver un conflicto definiendo cual sera el potencial

sistema solucin. Proyecto industrial. A diferencia de los proyectos clsicos, los
proyectos industriales comienzan y terminan en s mismos, dando lugar a un product
o o
servicio terminado (sin que ello sea obstculo para que otros proyectos comiencen
posteriormente desde los resultados del primero). Involucra una planificacin en l
a
ejecucin de actividades orientadas a un fin concreto (el bien o servicio) por lo
que una
vez finalizado el mismo, la replicacin de los resultados no constituira un proyect
o en s
mismo. Este tipo de proyectos, por su relevancia y generalidad se detallan a
continuacin.
3.6.1. Proyecto de ingeniera
Los Proyectos de Ingeniera tienen una serie de caractersticas comunes que se citan
a
continuacin:
Complejidad
Como consecuencia de las mltiples variables que entran a formar parte de los
proyectos, as como las numerosas relaciones que entre ellas existen, se puede dec
ir
que el proyecto es un sistema organizado, generalmente complejo.
Integrabilidad
La mayora de los proyectos que se realizan en la actualidad se caracterizan por l
a
necesidad de cubrir todas las etapas desde el principio (proyectos completos o
integrales), cuando slo existe una idea de algo que queremos materializar hasta e
l final,
cuando se ha transformado en una realidad. No obstante, a veces se tiene la impr
esin
que se suprimen algunas etapas intermedias. Esto no es del todo cierto, lo que o
curre
simplemente es que se utilizan otras vas, recurriendo a informaciones ya existent
es o
simplificaciones.
Multidisciplinariedad
Los proyectos que a veces se llevan a cabo son de tal envergadura que se necesit
a un
amplio equipo de profesionales cada uno de ellos expertos en una disciplina, con

amplios conocimientos tcnicos. Por ello, una tercera caracterstica para proyectos
de
ingeniera complejos e integrales es la disponibilidad de conocimientos
multidisciplinarios.
Globalidad del sistema
Un proyecto no puede ser considerado como una mera yuxtaposicin de sus cuatro
documentos formales bsicos (memoria, planos, pliego de condiciones y presupuesto)
,
sino que deben de contemplarse con una visin de conjunto las relaciones entre los

distintos elementos que lo constituyen.
Relacin con el exterior
Los proyectos guardan un intercambio con su medio exterior o entorno, del que
consumen recursos (naturales, sociales, econmicos,...) y al cual emiten bienes y
servicios. En este sentido la estimacin de los efectos de los proyectos y de las
actividades empresariales con relacin al medio ambiente (evaluaciones de impacto
ambiental, diagnsticos ambientales y ecoauditoras) y al medio humano (impacto
social), son aspectos prioritarios hoy en da.
Precisa de un plan
Para el empleo de recursos involucrados, el proyecto deber dotarse de un programa
de
actividades especficas que permitan alcanzar los objetivos concretos del sistema,

dentro de unos plazos fijados. Necesitar, adems, un plan de gestin econmico y
financiero.
Flexibilidad y capacidad de adaptacin
Un proyecto deber mantener un cierto equilibrio y estabilidad internos a pesar de
las
perturbaciones que recibe por los seguros cambios en las variables del entorno:
factores
ambientales, polticos, tecnolgicos, legales, etc. En ocasiones, la dificultad de p
oder
prever si los efectos de los cambios sern beneficiosos o contrarios a los interes
es del
proyecto, hacen necesaria esta flexibilidad o capacidad de adaptacin del proyecto
.
3.6.2. Proyecto industrial
Los proyectos industriales se diferencian de los otros en la menor importancia q
ue se
atribuye a las caractersticas del terreno donde se localiza desde el punto de vis
ta
tcnico, adems se exige una definicin precisa de todos los equipos y mquinas que
componen el sistema de produccin. En este tipo de proyectos la fase documental se

puede desarrollar independientemente de equipos y mquinas hasta un determinado
momento, pero a partir del cual es imprescindible la definicin y seleccin de stos.
Los
equipos y mquinas pueden quedar obsoletos o sufrir variaciones importantes en sus

costes o prestaciones.
El diseo, construccin, ensayos, puesta en marcha y cesin de un proyecto industrial,

constituyen una secuencia de actividades que se extienden a lo largo de un prolo
ngado
perodo de tiempo (en ocasiones del orden de varios aos), y que representa una
considerable inmovilizacin de capitales, recursos inmateriales y humanos. Por
consiguiente, el seguimiento de dichas actividades mediante un adecuado
procedimiento de planificacin y control no slo puede proporcionar reducciones de
tiempo (tanto directamente como indirectamente, solucionando situaciones que
producirn retrasos antes de que aparezcan), sino que dichas reducciones son
fcilmente objetivables en unos valores econmicos que justifican los recursos
destinados a dicha planificacin. Una clasificacin bastante representativa de los
proyectos industriales con independencia de su origen podra ser:
-Grandes proyectos de inversin,
-instalaciones y plantas industriales,
-lneas y unidades de produccin, y
-mquinas, equipos y sus elementos.
Grandes proyectos de inversin
Realmente este tipo no se puede considerar un proyecto, sino ms bien es un estudi
o
econmico que lo acompaa, tanto desde el punto de vista de la demanda prevista
como de los costes de produccin y de sus consecuencias sociales y polticas: creacin

de empleo, desarrollo regional, etctera. Dependiendo de sus resultados indica si
el
proyecto tiene o no futuro en el mercado. Si sus resultados son negativos, los p
royectos
suelen morir sin ver la luz y si son positivos, se utilizan como base para las p
osteriores
etapas del proyecto, que habitualmente implica grandes inversiones.
Instalaciones y plantas industriales
La realizacin de estos proyectos constituye el captulo ms amplio e importante dentr
o
de la ingeniera industrial y para ello es necesario la construccin de plantas e
instalaciones, que constituye un proyecto completo con todas sus fases y aspecto
s.
En la construccin de un proyecto industrial intervienen frecuentemente numerosas
empresas desarrollando trabajos muy diferentes entre s pero que precisan una estr
echa
coordinacin para alcanzar los objetivos parciales y globales, dicha coordinacin se

inicia a travs de un lenguaje comn y una clara visin de cules son los objetivos y la
s
responsabilidades de cada uno, dichos objetivos y responsabilidades son no solam
ente
tcnicos y econmicos, sino temporales, y se halla involucrados entre s. Cada trabajo

tendr normalmente su propia programacin, pero todas ellas deben combinarse y
entrar en el marco de la programacin global.
Los sectores, instalaciones y plantas ms tpicos son los que se enumeran a
continuacin: Industria electrnica, Robtica y automtica, Industria de transformacin,
Plantas de proceso (Refineras, Petroqumicas, Fertilizantes, Qumica inorgnica),
Industria de la alimentacin, Farmacia, Pasta, papel y cartn, Cemento, Centrales
elctricas (Hidrulicas, Trmicas, Nucleares), Siderurgia y metalurgia, Industria
aeronutica y espacial, Industria naval, y Lneas y unidades de produccin.
Unidades y lneas de produccin
El estudio y diseo de las unidades y lneas de produccin de los edificios e
instalaciones que forman las grandes plantas industriales constituyen por s mismo
s
proyectos independientes que, en muchas ocasiones estn interconectados.
Mquinas, equipos y sus elementos
El estudio de las mquinas y equipos que forman parte de cualquier instalacin
industrial, e incluso algunos elementos de stos constituyen tambin por s mismos un
proyecto.
3.6.3. Otra clasificacin de los proyectos industriales podra ser
Segn la naturaleza del proyecto (especialidad).
El volumen de la inversin.
El objeto del proyecto.
El proceso que utiliza.
Por la naturaleza del proyecto
Por su naturaleza o especialidad, hay que recurrir a la clasificacin de los disti
ntos
sectores industriales. Esta clasificacin coincide con la lista enumerada anterior
mente
en el punto instalaciones y plantas industriales.
Por el volumen de la inversin
Pequeo, Mediano o Grande.
Por el objeto del proyecto
Nueva instalacin, Ampliacin (Modificaciones de proceso, Nuevas lneas, Nuevos
productos, Cuellos de botella), Mejora (Econmica: Aumento de calidad, Reduccin de
costes; Social: Seguridad, Proteccin ambiental), Mantenimiento y, Traslado.
Por el proceso que utiliza
Su naturaleza (Mecnico, Fsico, Fsico-qumico), Su origen (Propio, De terceros),
Propietario del proceso, Empresa de ingeniera licenciada o, Suministradores de eq
uipos
principales.
La multiplicidad de tecnologas, empresas y tareas, dificulta la obtencin de una vi
sin
global que, sin embargo, es la que debe adoptar el jefe del proyecto. La planifi
cacin
permite alcanzar esta visin de conjunto.
4. FASES GENRICAS DE UN PROYECTO
Los tipos de proyectos que pueden realizarse son muy variados, dependiendo del s
ector
productivo que se encarga de llevarlos a cabo, del usuario al que va destinado,
adems
de la diversa tecnologa utilizada para su construccin, que puede variar mucho de u
n
proyecto a otro. No obstante, muchos autores con experiencia en proyectos de sec
tores
muy diferentes (aeronutica, biologa, construccin, informtica, etc...) coinciden en l
a
forma de realizar el proyecto. Todos ellos siguen prcticamente las mismas pautas
en su
desarrollo, por lo que el proyecto evoluciona de forma natural con aspectos comu
nes.
As, su ciclo de vida, con el que nace, se desarrolla y muere un proyecto puede di
vidirse
en cinco fases:
1. Definicin.
2. Concepcin.
3. Construccin.
4. Puesta en marcha.
5. Cesin.
Estas fases pueden superponerse en el tiempo. A veces no es necesario la finaliz
acin
de una para empezar la siguiente, pueden realizarse de manera paralela, aunque,
eso s,
depende nica y exclusivamente del proyecto que se quiere llevar a cabo. El equipo

encargado de llevarlo a la prctica es el que decidir el tiempo empleado para cada
una
de las fases y si stas pueden o no coincidir. La evolucin temporal de estas fases
se
refleja a continuacin:
Figura 4.1: Fases genricas de un proyecto.
Las fases de un proyecto, a partir de la divisin genrica, son:
1. Fase de Definicin:
-Definicin del proyecto (definicin).
-Deteccin de una necesidad, un problema, o una oportunidad.
-Estudios de prefactibilidad o previabilidad.
2. Fase de Concepcin:
-Concepcin (definicin).
-Estudio de factibilidad o viabilidad (anteproyecto).
-Seleccin del proyecto.
3. Fase de Construccin.
-Planificacin de actividades y recursos.
-Planificacin y programacin del proyecto.
-Plan de calidad del proyecto.
4-Fase de puesta en marcha.
-Ejecucin del proyecto.
-Operacin y gestin.
-Evaluacin de resultados (Ex - Post).
5-Fase de Cesin.
4.1. FASE DE DEFINICIN
Todo proyecto surge para satisfacer una necesidad. Como consecuencia, aparecern
una serie de ideas que intentarn proponer la solucin a sta. De todas formas, hay qu
e
incidir en un aspecto: la idea normalmente es una proposicin que se pone de manif
iesto
para solucionar una necesidad pero puede ocurrir que aparezca antes de que se ha
ya
planteado el problema.
4.1.1. Definicin del proyecto
La idea central del sistema a construir a travs del proyecto, puede provenir de
diferentes fuentes: resultar a partir de otro desarrollo, de problemas existente
s en la
organizacin, o de la observacin de posibilidades existentes. La fase de definicin e
s
aquella en la que la idea se concreta y se realizan los estudios y evaluaciones
preliminares.
Durante la fase de definicin se analiza el entorno, se preparan previsiones, se e
valan
objetivos y alternativas, y se realiza un primer examen de la misin, objetivos, c
ostos y
programa de desarrollo del sistema. Es tambin en esta fase de definicin donde se l
lega
al estudio de factibilidad, que permitir posteriormente una evaluacin ms detallada
si,
como consecuencia del mismo, se decide seguir adelante.
Si la fase de definicin se enfoca adecuadamente permitir eliminar aquellos proyect
os
que no tienen posibilidad de supervivencia. Las tasa de frustracin de los proyect
os
potenciales durante la fase de definicin es alta: debe ser as, puesto que los estu
dios
realizados durante esta fase deben identificar aquellos proyectos que poseen un
elevado
riesgo y son tcnica y econmicamente o en relacin al entorno, irrealizables, y en
cualquier caso, es mejor no continuar con un proyecto cuando es de papel que cua
ndo
es de acero y hormign.
4.1.1.1. Objetivos
En todo proyecto debe de existir una primera fase de definicin que especifique qu
es
lo que desea hacer, en qu consiste, cundo queremos hacerlo, cmo realizarlo y a qu
costo. En muchos casos el cliente tiene una idea, unos objetivos ms o menos
definidos, un problema o una necesidad y se valora de forma ms o menos precisa
segn se fe en su intuicin o realice estudios de apoyo (oportunidad, viabilidad,
rentabilidad, costo, beneficio, financiacin, etc.) decide llevarla a trmino.
Esta definicin no debe ser de larga duracin ni costosa, pero fundamental para el r
esto
de las fases, si tienen lugar, estn orientadas en el sentido que maximiza la prob
abilidad
de xito. La incgnita que desea aclararse es que debe de realizar el sistema una ve
z
construido o para qu debe de servir, no cmo lo har ni cmo se llegar a realizarlo,
aunque la separacin de estos aspectos no sea demasiado fcil en general, ni nuestra

educacin nos prepares especialmente para ello. Al final de la fase debe de estima
rse si
la definicin es lo suficientemente interesante como para proseguir investigando e
l
tema.
4.1.2. Deteccin de una necesidad, problema o rea de oportunidad
Representa la fase de deteccin de necesidades, dentro de un contexto limitado por
el
analista, donde define de manera clara y especfica, las situaciones reales y actu
ales del
sistema, dando oportunidad a hacer ciertas predicciones del posible comportamien
to
futuro del rea con necesidad, pero sin establecer jerarqua dentro del anlisis.
Para poder identificar estas situaciones, es preciso tambin cuantificar las neces
idades
del cliente, interno y externo, en un contexto cultural que en cierta medida res
ponde a
factores sociolgicos y psicolgicos.
PARA IDENTIFICAR PROBLEMAS BUSQUE ESTOS SIGNOS ESPECFICOS
Revise las salidas contra los criterios de
desempeo
Demasiados errores. Trabajo terminado lentamente.
Trabajo hecho incorrectamente. Trabajo hecho en forma
incompleta. Trabajo que no se realiza del todo.
Observe el comportamiento de los empleados Alto ausentismo. Alta insatisfaccin en
el trabajo. Alta
rotacin de personal.
Escuche retroalimentacin externa de: vendedores,
clientes, proveedores, etc.
Quejas. Sugerencias de mejoras. Prdida de ventas.
Menores ventas.
Tabla 4.1. Lista de acciones.
Las mejoras a los sistemas pueden ser definidas como cambios que darn como
resultado, beneficios aumentados y que valen la pena. Existen muchas posibilidad
es de
mejoras, incluyendo:
a.
Aceleracin de un proceso.
b.
Agilizacin de un proceso mediante la eliminacin de pasos innecesarios o
duplicados.
c.
Combinacin de procesos.
d.
Reduccin de los errores en la entrada por medio de cambios en formas y
pantallas VDT.
e.
Reduccin de salida redundante.
f.
Mejora en la integracin de sistemas y subsistemas.
g.
Mejora en la satisfaccin del trabajador con el sistema.
h.
Mejora de la facilidad de interaccin de los clientes, proveedores y vendedores,
con el sistema.
Se encuentra dentro de las capacidades del proyectista, el darse cuenta de las
oportunidades para mejoras. Sin embargo, las personas que estn en contacto diario

con el sistema, pueden ser mejores fuentes de informacin acerca de las mejoras qu
e
deben de ser hechas. Si las mejoras ya han sido sugeridas, se necesita la experi
encia
propia para que ayude a determinar si valen la pena y la forma en que pueden ser

implementadas.
Aunque la lista de mejoras dada anteriormente es larga, no es exhaustiva. La par
te difcil
de sugerir o implementar mejoras, es que deben de valer el desconcierto y costo
del
cambio.
La metodologa ms til para llegar a conocer cul es la razn por la cual el cliente dese
a
obtener la unidad de actuacin, pasa por tratar de obtener un conjunto de respuest
as
para que el gestor consiga tres avances substanciales: centrar a su cliente, ayu
dndole
a definir mejor sus propias querencias; el segundo, conocer la sintona por la que
se ha
de mover la gestin de proyectos nicos; y en tercer lugar, acercarse al conocimient
o
que el cliente tiene de sus propios deseos y/o necesidades. Las respuestas se de
bern
tener de las siguientes preguntas: qu y para qu, a quin, por qu, dnde, cundo,
cmo, cuntas veces, cunto tiempo y a qu costo.
Cuando los requerimientos del sistema son definidos inicialmente en respuesta a
una
necesidad identificada del consumidor, el objetivo es desarrollar y producir (o
construir)
una configuracin que llevar a cabo las funciones tal y como se definieron.
Dicho proceso de traducir estos requerimientos especificados inicialmente a una
entidad
funcional, debe de contemplarse no slo de manera oportuna, sino tambin debe de
llevarse a cabo efectiva e eficientemente.
En otras palabras, dada una necesidad definida, un sistema debe desarrollarse ex
pedita
y econmicamente e incorporar las caractersticas esenciales de desempeo,
efectividad y calidad. Esto se lleva a cabo mediante la aplicacin adecuada de mtod
os
de diseo con el estado del arte, la integracin oportuna de disciplinas de diseo
adecuadas, la habilitacin optimista de prcticas de consecucin expeditas, etc.
4.1.3. Estudios de prefactibilidad o previabilidad
Previo al estudio de factibilidad, deben estar claros los siguientes puntos:
a.
Inters y prioridad de la idea del proyecto.
b.
Diagnstico racional del rea del proyecto.
c.
Viabilidad tcnica del futuro proyecto: estudio de alternativas estratgicas para
determinar las metas y su seleccin.
d.
Viabilidad econmica y poltica.
e.
Viabilidad legal.
f.
Viabilidad social.
g.
Identificacin de problemas y obstculos derivados de la puesta en marcha del
proyecto.
h.
Estudio de las fuentes de financiacin.
i.
Beneficiarios del proyecto.
El resultado de esto puede ser, el archivo del proyecto para una consideracin fut
ura,
rechazo en forma definitiva o pasar a la fase de estudio de factibilidad.
4.2. FASE DE CONCEPCIN
En esta fase los aspectos ms relevantes mencionados anteriormente se han de
concretar ms, es decir, se tienen que identificar con ms precisin los recursos
necesarios, especialmente los recursos humanos, que juegan un papel muy importan
te
en la elaboracin de un proyecto. En relacin con el coste del proyecto, tambin se
intentar dar cifras ms exactas. Hay que acotar exactamente lo que se va a hacer, h
ay
que definir de forma muy concreta el problema que se pretende resolver.
Se determinarn todos los objetivos del proyecto, cada uno de los cuales trata de
cubrir
alguno de los problemas especficos que pueden incidir decisivamente en el resulta
do
global. Estos objetivos varan de un proyecto a otro, pero hay algunos que son com
unes
en todos los proyectos: calidad, plazo y precio.
Es en este momento cuando debe hacerse una buena planificacin para el desarrollo
del
proyecto, establecer las fechas de inicio y final de cada una de las actividades
. Tambin
se elabora la documentacin: normativas, manuales, procedimientos, descripcin de
actividades, presupuestos, impresos, etc., que ayuda a llevar un control ms estri
cto y
saber en cada momento qu es lo que se ha realizado y qu es lo que falta para llega
r al
final. Los documentos del proyecto son el instrumento de comunicacin ms importante

del proyecto y permite un buen entendimiento entre todos los grupos que intervie
nen en
l.
Si es posible, se disea el prototipo, (que consiste en la reproduccin, normalmente
a
escala natural, del producto o de algunos de sus componentes), se construye y se

realiza una simulacin. Es una fase de creacin de lo que hay que hacer y de cmo se
har, considerando los estudios previos, concepcin del proyecto, concepcin de los
objetivos y con la idealizacin de la estructura de la descomposicin del proyecto.
4.2.1. Concepcin
Representa la fase de generacin de las ideas y su enmarcado, delimitacin y la
naturaleza de los objetivos, las necesidades, los usuarios, la filosofa la viabil
idad
tcnica, econmica o social, as como los riesgos predecibles. El nacimiento de un
proyecto se corresponde con una idea, en un principio, poco definida. En esta fa
se, se
requerir un esfuerzo creativo importante, que permita identificar las posibilidad
es que
constituyen un proyecto potencial.
El equipo que desarrolla esta fase no es necesariamente el que continuar con las
fases
posteriores, sin embargo, es recomendable que el gestor del proyecto se mantenga

desde un principio y sea no solamente quien ms conoce el proceso en su forma y en
su
fondo sino quien, adems, servir de nexo de continuidad con el resto del equipo, el

cual se ampliar y cambiar de acuerdo a las necesidades.
La definicin de los objetivos de los proyectos, no es siempre una tarea exclusiva
del
cliente, pues puede contar para eso, con el asesoramiento y las sugerencias de l
os
tcnicos que lo van a ejecutar, pero es quien debe de explicar lo que quiere, adop
tar las
decisiones que permitan precisar el contenido y finalmente, aprobar los objetivo
s que se
hayan establecido en el proceso de negociacin con los encargados de desarrollar e
l
proyecto.
Durante la ejecucin del proyecto, el cliente debe de realizar un seguimiento lo
suficientemente cercano de la evolucin del mismo, de su grado de avance y del niv
el
de consecucin de los objetivos.
La contratacin de una empresa externa o el encargo a otro departamento interno, n
o
permite que el cliente se desentienda de la marcha del proyecto, y a limitarse a
cumplir
sus obligaciones financieras y esperar que el desenlace final sea satisfactorio.

Debe de seguir de cerca la evolucin del proyecto y los plazos de control, velando
que
se alcancen los niveles de calidad establecidos, tomando las decisiones que pudi
esen
ser de su competencia para facilitar el avance y estimulando con su inters y aten
cin a
los tcnicos para evitar una relajacin que redundara en prdida de eficacia.
4.2.1.1. Concepcin general
Puesto que el proyecto se considera realizable, hay que definirlo desde el punto
de vista
tcnico y realizar un estudio detallado de cada una de las soluciones posibles, qu
e
todava estn en consideracin, con ensayos, maquetas, etc., si es necesario a fin de
elegir la solucin a adoptar o por lo menos restringir el abanico de posibilidades
.
El documento final presenta una proposicin completa y coherente, con las
caractersticas tcnicas principales, calendario, estimacin de costos (ms precisa que
la anterior), recursos necesarios, plan financiero probable, y recomendaciones p
ara la
fase siguiente. Puede adoptarse la decisin de abandonar el proyecto o seguir.
4.2.1.2. Concepcin detallada
Se realiza la descomposicin del proyecto en subproyectos o macroactividades,
realizando el anlisis de las mismas, a fin de poder proceder a su asignacin a los
entes
que las van a realizar (en su caso debern de preparar las modalidades de contrata
cin).
Se establece la organizacin bsica de la realizacin: especificaciones tcnicas, costos
,
calendario, formas de gestin y control, ensayos previos a la recepcin, etc.
4.2.2. Estudios previos
Se realiza la descomposicin del proyecto, en subproyectos o macroactividades,
realizando el anlisis de las mismas, a fin de poder proceder a su asignacin a los
entes
que las van a realizar (en su caso se debern preparar las modalidades de contrata
cin).
Se establece la organizacin bsica de la realizacin: especificaciones tcnicas, costos
,
calendario, formas de gestin y control, ensayos previos a la recepcin, etc.
La factibilidad, significa determinar si el proyecto propuesto ayuda a que la or
ganizacin
logre sus objetivos generales. Y si es posible de lograr, con los recursos actua
les de la
organizacin, desde el punto de vista: tcnico, econmico y operacional.
ASPECTOS A CONSIDERAR EN LA CONCEPCIN GENERAL
DEFINICIN TCNICA
Misin Precisarla - Mantenerla.
Objetivos Concretarlos. establecer jerarqua. Preservarlos.
Actuacin regular Funcionamiento normal y detallado.
Actuacin degradada Funcionamiento detallado del sistema en caso de incidente.
Actuacin inicial Funcionamiento detallado del sistema durante la puesta.
Prestaciones Resultados segn los modos.
Descripcin Exhaustividad en la descomposicin del sistema en niveles y del
proyecto en actividades.
Tecnologas Precisar las incgnitas y el riesgo. Aceptar cambios.
Calidad / fiabilidad Estudio de conjunto y de detalle.
Ensayos Definicin precisa de las pruebas parciales y de conjunto, previas
para dar de alta elementos, subsistemas y el sistema.
DEFINICIN DE MEDIOS
Financieros Costos, presupuestos, plan de financiacin.
Mano de obra Tipos, equipos de gestin y direccin del proyecto. Limitaciones en
especialidades raras.
Materiales Prever: alquiler, construccin, compra.
DEFINICIN DE CALENDARIO
Exigencias externas Puntos fijos obligados. Interfaces.
Duracin de actividad Ciertas, aleatorias. optimistas.
Restricciones Potenciales, acumulativas, incompatibles.
ORGANIZACIN DEL PROYECTO
Organizacin Estructura tipo proyecto, convencer, decidir.
Plantilla Disponibilidad de recursos humanos.
Soporte Disponibilidad de los recursos de soporte.
Contratos Descomposicin de unidades, tipo.
Sistemas de informacin Circuitos adaptados al proyecto. Cuadro.
Relacin informacin / decisin Formalizar lneas de autoridad.
Tabla 4.2. Concepcin general del proyecto.
4.2.2.1. Estudios de factibilidad y viabilidad
El estudio de viabilidad es estrictamente detallado, con un mayor consumo de rec
ursos,
lleva consigo una reduccin del grado de incertidumbre y una mayor cuantificacin y
definicin de los costos y beneficios del proyecto a lo largo del tiempo (el mximo
nivel
de incertidumbre en el propuesto en esta fase, debe ser no mayor al 25%).
El anlisis de viabilidad requiere de informacin primaria; adems de los aspectos ant
es
mencionados, debe incluir los siguientes puntos:
Anlisis de los condicionantes que incidirn en el proyecto.
Localizacin y tamao.
Diseo de ingeniera a nivel ante-proyecto.
Definicin y detalle del plan de explotacin.
Seleccin de alternativas estratgicas.
Definicin concreta de los objetivos del proyecto.
Tecnologas de produccin o transformacin con diseo casi definitivo (ingeniera
del proceso).
Identificacin y cuantificacin de los costos y beneficios del proyecto, desde las
siguientes perspectivas: econmica, social y ambiental.
Identificacin, organizacin y anlisis de agentes y beneficiarios.
Posibilidades de mercado y canales de comercializacin.
Propuesta de organizacin, administracin y gestin del proyecto.
Posibilidades de financiacin: comunitaria, nacional, autonmica, local.
Estudio a fondo del marco legal.
Evaluacin multicriterio del proyecto.
Calendario de ejecucin.
Puesta en marcha.
Los resultados del estudio de viabilidad, llevarn a:
Archivarse para una reconsideracin futura.
Modificarse en su formulacin.
Raramente se rechazan en forma definitiva.
Pasar a la aprobacin final.
Para este estudio (viabilidad), el nivel de incertidumbre en el presupuesto es i
nferior al
10%.
Ya hemos visto anteriormente que una de las fases del proyecto es la que se refi
ere a la
realizacin de diversos estudios previos antes de decidir definitivamente acometer
el
proyecto.
Los estudios previos se reducen muchas veces a un estudio de la viabilidad del p
royecto
solamente desde tres puntos de vista:
Tcnico.
Econmico.
Financiero.
Un estudio serio de viabilidad abarca mayor diversidad y exige la realizacin de u
na serie
de estudios parciales de distinto tipo como son:
Estudio de mercado.
Tamao del proyecto.
Tecnologa.
Localizacin.
Emplazamiento.
Impacto ambiental.
Estimacin de la inversin.
Financiacin.
Presupuesto de ingresos y gastos: flujo de carga, evaluacin y anlisis.
No obstante, es posible suprimir algunos de ellos, ya que el entorno general don
de se va
a situar el posible proyecto permite efectuar simplificaciones. Por ejemplo, un
estudio de
viabilidad puede caracterizarse de la siguiente manera:
Figura 4.2: Secuencia de estudios.
Durante esta subfase puede concretarse el organigrama tcnico del proyecto (WBS-
Work Breakdown Structure), establecido en primera aproximacin seguramente antes.
Un organigrama tcnico es la descomposicin funcional de las tareas del proyecto, un
a
lista de las tareas organizada en forma jerrquica o de rbol. El trabajo puede
subdividirse en tantos niveles como sea necesario para alcanzar el tamao de tarea
s
deseado. El nivel ms bajo de la divisin debe ser lo suficientemente fino como para

permitir visibilidad y control adecuados sin crear un volumen tal de tareas que
sea
inmanejable administrativamente.
4.2.2.2. Estudios de mercado
Otro campo que frecuentemente requiere de estudios previos es el referente al
mercado, o la demanda existente o potencial. El proyecto requiere de estudios pr
evios
referentes a la demanda existente y potencial o a las condiciones de comercializ
acin de
los mismos. Como la demanda est en funcin del precio, ser necesario efectuar
estimaciones de la misma para distintos precios y de igual modo limitarla
geogrficamente porque la localizacin del nuevo proyecto depende en gran medida del

tamao del mercado y de la distribucin de los posibles consumidores.
La investigacin de esta demanda exigir el estudio de todos los antecedentes
existentes y muy especialmente de las series estadsticas disponibles sobre el bie
n en
cuestin: de produccin, comercio exterior y consumo, as como series de precios e
ndices de los mismos y series de ingresos nacionales y de crecimiento de la pobla
cin.
Antes de lanzar un nuevo producto podremos estar interesados en conocer si exis
te o
no demanda para el mismo y en qu condiciones; antes de construir una nueva planta

de fabricacin ser necesario saber qu cantidades de los productos a fabricar puede
absorber el mercado; antes de construir una autopista habr que prever el volumen
de
trfico esperable y las tarifas de peaje que podrn ser percibidas.
4.2.2.3. Tamao del proyecto y tecnologa
El estudio de mercado proporciona una informacin fundamental para poder determina
r
el tamao del proyecto, es decir, la capacidad de produccin durante un perodo de
tiempo de funcionamiento que se considera normal.
La eleccin del tamao est limitada por arriba por la demanda insatisfecha que se va
a
cubrir y, por abajo, por la unidad mnima de produccin rentable. Esta cantidad mnima

no es universal, sino que depende del entorno socioeconmico del proyecto y de las

caractersticas del mercado que debe abastecer.
En la mayora de los casos es poco reconocida pero tiene gran importancia la futur
a
poltica de ventas de la sociedad promotora, en la fijacin del tamao, ya que la
organizacin de las ventas, la fijacin de precios, la poltica de distribucin, las
comisiones y descuentos, la necesidad de servicios postventa, etc., deben
materializarse en un programa de ventas y, consecuentemente en un programa de
produccin.
Otros factores importantes que hay que tener en cuenta a la hora de fijar el tam
ao son
los costes de produccin y distribucin, el proceso tecnolgico, el volumen de la
inversin y la financiacin disponible.
La seleccin de la tecnologa a utilizar tambin juega un papel muy importante. Se
tendr en cuenta los costes de la propia tecnologa, de la inversin que supone y los
futuros costes de produccin, as como el desarrollo de tecnologas competitivas de
prxima o posible aparicin.
Los costes de operacin, los de las materias primas y las cargas financieras de la

inversin total no demasiado elevadas deben proporcionar un producto rentable.
4.2.2.4. Localizacin, emplazamiento e impacto ambiental
La localizacin y emplazamiento adecuados sern aquellos que nos proporcionen
mejores resultados econmicos. Para ello ser necesario analizar las variables conoc
idas
como fuerzas o factores de localizacin, esto es: coste de transporte de materias
primas
y productos, disponibilidad y coste relativo de los recursos, como costes de man
o de
obra y servicios (energa, agua, etc.) y los factores polticos, sociales, administr
ativos y
legales. Los factores polticos, sociales, administrativos y legales son cada vez
ms
decisivos y pueden llegar a ser vitales. Esto ocurre cuando las facilidades fisc
ales, las
subvenciones y en general las ayudas estatales, regionales o municipales, otorga
das
habitualmente por razones polticas, alcanzan cuantas importantes.
El estudio del impacto ambiental es cada vez ms importante en el momento de
determinar la localizacin y emplazamiento del proyecto. En Espaa, siguiendo las
directrices de la Unin Europea, se publicaron los decretos 132/1986 sobre evaluac
in
de impacto ambiental y 1131/1988 que aprueba el reglamento para la ejecucin del
anterior. El primero de ellos incluye los requisitos administrativos que se debe
n tener en
cuenta en un estudio de este tipo, a la vez que presenta un listado de todos los
tipos de
proyectos que han de someterse preceptivamente a evaluacin. El segundo decreto
incluye un reglamento detallado sobre los conceptos y el contenido que debe tene
r un
estudio de impacto ambiental.
Se considera que hay impacto ambiental cuando la realizacin de un determinado
proyecto altera el medio ambiente incidiendo en alguno de sus componentes, prest
ando
especial importancia cuando se altera la salud o el bienestar de la comunidad, d
el
hombre.
Para determinar los efectos que un determinado proyecto puede tener sobre el med
io
ambiente se realizan los estudios de impacto ambiental (EIA), que permiten ident
ificar,
predecir, interpretar y comunicar estos efectos. Las posibles alteraciones se va
loran
tanto en su magnitud como en el tiempo.
Estas evaluaciones exigen seleccionar unas magnitudes significativas y unas unid
ades
de medida; en este caso las magnitudes que se han de elegir son los denominados
indicadores de impacto, definidos como aquellos parmetros que mejor definen los
efectos del proyecto en el medio ambiente por ser exclusivos, medibles y
representativos. De todas estas magnitudes se har un estudio de tres situaciones
distintas: estado cero, estado futuro sin proyecto y estado futuro con proyecto.

El estado cero define las condiciones ambientales actuales y las caractersticas fs
icas,
biolgicas, sociales y econmicas del entorno; el estado futuro sin proyecto extrapo
la la
situacin anterior en el tiempo, mientras que el estado futuro con proyecto sera
precisamente el estado cero ms el impacto ambiental que el proyecto ocasione.
Posibles localizaciones sern aquellas en las que resulta mnima la suma de los cost
es
de transporte de las materias primas hasta la planta y de los productos hasta el

mercado.
El factor predominante para elegir el rea de localizacin en el caso de que existan

diversas soluciones rentables ser el coste de los terrenos en funcin de sus
caractersticas (calidad del suelo, infraestructura disponible, ordenanzas existen
tes,
etc.).
4.2.2.5. Estimacin de la inversin
Los distintos estudios mencionados anteriormente tienen un carcter tcnico y es
necesario completarlos con otros de carcter econmico y financiero.
La estimacin de la inversin requerida por el proyecto se intentar realizar de la fo
rma
ms exacta posible. Debe estudiarse anticipadamente el presupuesto, la distribucin
en
el tiempo, y qu recursos van a utilizarse para financiar la inversin. As mismo, ana
lizar
las posibles fuentes financieras a emplear, el costo de financiacin segn el tipo d
e
recurso empleado y las condiciones requeridas, para tener acceso a una u otra fu
ente.
En sta se deber diferenciar entre el capital necesario para el proyecto desde su
consideracin como centro de transformacin de recursos, es decir, el capital fijo o

inmovilizado y el capital requerido para el posterior funcionamiento normal de l
as
instalaciones, es decir, el capital de trabajo o capital circulante.
El capital fijo est constituido por el valor monetario de los activos fijos, que
comprenden todo el conjunto de bienes que se adquieren una sola vez durante la
ejecucin del proyecto y se utilizan a lo largo de su vida til. El capital fijo vie
ne
condicionado por diversos factores, que pueden variar de un proyecto a otro, per
o todos
tiene stos en comn:
Ensayos, investigaciones y estudios previos.
Constitucin y organizacin de la empresa que realice el proyecto.
Terrenos y recursos naturales.
Ingeniera.
Instalaciones provisionales.
Instalaciones de produccin y auxiliares.
Puesta en servicio.
Intereses durante el perodo de construccin.
Varios e imprevistos.
Lgicamente la importancia de cada uno de ellos ser muy variable y muy distinta de
uno a otro tipo de proyecto. El capital circulante tambin es muy variable de un
proyecto a otro, desde casi cero (proyectos de edificacin para arrendamiento) has
ta
valores muy elevados (proyectos agroindustriales con financiacin de cosecha). ste
depende de la poltica financiera, de los sistemas de distribucin y comercializacin
y de
los niveles de stocks fijados.
La inversin requerida supondr el anlisis de diferentes fuentes de financiacin. Es
aconsejable asegurar estas fuentes incluso antes del estudio de viabilidad para
evitar
cualquier tipo de estudio en vano si desde un principio no se dispone de medios
monetarios suficientes. Las fuentes de financiacin en una primera clasificacin se
pueden dividir en internas y externas. Las internas son las que utilizan los pro
pios
fondos generados por la empresa en su actividad anterior al nuevo proyecto
(autofinanciacin), y las externas son las distintas modalidades del mercado de
capitales: acciones, obligaciones, bonos y prstamos. Los prstamos a su vez pueden
ser crditos bancarios (comerciales y a corto, medio y largo plazo), crditos a la
exportacin y crdito de proveedores.
Es necesario que el proyecto sea solvente para garantizar financiacin exterior y
as,
ofrecer garantas a las entidades financieras. De todos modos, en la actualidad es

frecuente utilizar los propios fondos generados por el proyecto, es decir, el fl
ujo de caja
que sea capaz de generar, como principal garanta para conseguir las facilidades
financieras necesarias para su ejecucin. Ello forma parte importante de lo que se

conoce como ingeniera financiera.
4.2.2.6. Presupuesto de gastos e ingresos: flujo de caja
La tendencia actual es estudiar por separado el flujo de caja de los proyectos (
y a partir
de ese estudio establecer su rentabilidad) y la financiacin necesaria. Con ello s
e
consigue un mejor conocimiento de las caractersticas del proyecto.
El cash-flow o flujo de caja operativo del proyecto corresponde a la diferencia
entre los
fondos generados cada ao y las inversiones realizadas durante el mismo, y ello a
todo
lo largo de la vida del proyecto.
Los fondos que el proyecto genera cada ao son el resultado de sumar el beneficio
despus de impuestos y las cantidades destinadas a amortizacin. La diferencia entre

los ingresos y los gastos del proyecto a lo largo de su vida til independientemen
te de
las inversiones genera un beneficio bruto. Si descontamos los impuestos
correspondientes obtenemos el beneficio neto.
Los gastos del proyecto se dividen en los propios costes de produccin y la
amortizacin de la inversin.
Los costes de produccin son diversos y dependen de la naturaleza del proyecto, pe
ro
los que mencionamos a continuacin son frecuentemente comunes en la mayora de
proyectos:
Materias primas y otros materiales.
Servicios auxiliares.
Mano de obra.
Coste de las ventas.
Seguros, impuestos y alquileres.
Varios e imprevistos.
La amortizacin del inmovilizado, que no incluye los terrenos, tiene por objeto ha
cer
frente a la depreciacin y obsolescencia de las instalaciones, creando un fondo co
ntable
para permitir reponer en su momento las instalaciones amortizadas.
Todos los costes expuestos anteriormente son directos, evolucionan en forma
inversamente proporcional al plazo de ejecucin del proyecto. Acortar el plazo sup
one
incrementar los costes y viceversa, aunque slo se produce esto para ciertos lmites
de
coste y plazo.
Existen tambin otros costes, que, aunque poco significativos en la mayora de
proyectos viene bien mencionarlos, su crecimiento es directamente proporcional
aumento del plazo, y stos son por ejemplo, el alquiler de las instalaciones en la
s que se
realiza el proyecto, adems de los gastos generales como electricidad, telfono, etc
.
Una demora en el proyecto somete al cliente a unos perjuicios que podran evaluars
e, es
ms, en ciertos casos se habr pactado una indemnizacin al cliente por cada da o cada
semana de demora, con lo que resulta evidente que este tipo de coste es proporci
onal al
plazo.
4.2.2.7. Evaluacin y anlisis de proyectos
Finalmente la ltima serie de estudios previos corresponde a la evaluacin y anlisis
de
la informacin tcnica, y especialmente econmica, que proporcionan los estudios
anteriormente descritos.
Si una empresa decide acometer un proyecto ser normalmente porque piensa que va a

resultar rentable, salvo ciertos casos especiales como inversiones de carcter
estratgico o inversiones obligadas por razones legales o de otro tipo. Frecuentem
ente,
sin embargo, incluso en empresas que presumen de una gestin muy profesional, se
toman decisiones sobre proyectos sin que exista un estudio siquiera somero de la

rentabilidad esperable.
La limitacin de los recursos disponibles tanto en el sector pblico como en el priv
ado,
obliga a realizar una evaluacin y por ello deben administrarse de la forma ms efic
az
posible.
El proyecto deber ser rentable, tanto en valores absolutos como comparativos, es
decir, la rentabilidad de un proyecto es una condicin previa para que se decida l
levarlo
a cabo. En el caso de instituciones sin fines de lucro, la rentabilidad econmica
no ser
una meta pero no significa que la inversin deba realizarse sin la debida reflexin
y sin
saberse el costo beneficio que se preve lograr, supera los costos o dificultades
que son
predecibles.
Existen dos tipos distintos de evaluacin del beneficio, el social, que trata de c
onseguir
el mejor beneficio para la comunidad, y el empresarial, que trata de obtenerlo p
ara la
organizacin promotora e inversora.
El criterio ms utilizado para la evaluacin de proyectos industriales es el empresa
rial,
ya que en economas de mercado suelen ser acometidos de esta forma. Sin embargo, e
s
posible trasladar estos criterios a la evaluacin social utilizando precios social
es y
teniendo en cuenta los efectos indirectos.
Los criterios de rentabilidad se enuncian a continuacin:
Tasa de rentabilidad
Definida como beneficio por unidad de capital empleado, distinguiendo si se trat
a slo
de capitales propios o se incluyen tambin los crditos utilizados.
Lgicamente, resulta claro que un proyecto ser interesante si su tasa de rentabilid
ad
prevista no slo es positiva sino que es superior a la que se podra obtener deposit
ando
el dinero en un banco o invirtindolo en deuda del estado.
Este clculo en forma tan simple como se ha expuesto permitira comparar proyectos
diferentes siempre que su duracin no fuese superior a un ao, lo que representa un
caso bastante especial. Si el proyecto tiene una duracin mayor, como es normal, e
l
clculo queda desvirtuado por el distinto valor que tienen los importes monetarios

pagados o recibidos en diversos momentos de tiempo.
Perodo de recuperacin del capital
Tiempo necesario para recuperar el capital que se ha invertido y, por tanto, a p
artir de
qu momento los ingresos derivados del proyecto representan ya beneficios y no mer
a
recuperacin de lo anteriormente invertido.
Teniendo en cuenta este perodo slo ser vlido comparar proyectos que tienen una
duracin similar y cuyo comportamiento de gastos e ingresos es homogneo y
relativamente estable en el tiempo.
Velocidad de rotacin del capital
Definida como cociente entre el valor bruto de la produccin anual (ventas) y el c
apital.
Todos los criterios anteriores para comparar proyectos tienen el inconveniente d
e operar
(sumar, restar, etc.) con unidades monetarias de aos diferentes, cuyo valor es ta
mbin
diferente. Si se suman unidades monetarias de aos distintos se comete un grave er
ror.
Ello es particularmente importante si se comparan proyectos con una gran extensin
en
el tiempo o cuyas inversiones o ingresos se producen en perodos de tiempo muy
diferentes.
En general, lo que se hace es actualizar todas las cifras de gastos e ingresos a
unidades
del ao inicial, para lo que se aplican dos criterios, el valor actual neto y la t
asa interna
de retorno.
Valor actual neto (VAN)
Definido como la suma de los distintos flujos de caja generados por el proyecto,

descontados a un determinado tipo de inters, ser:
n
CCC
C
12
nt
VAN
=-C0
++
+
...+
=-C0
+S
2
nt
(1+
k)(1+
k)(1+
k)
t=1
(1+
k)
Frmula para calcular el VAN
Donde:
Ct = flujos de caja.
C0 = capital inicial invertido.
k = tasa de actualizacin.
t = aos de duracin del proyecto.
El flujo de caja al comienzo del proyecto, habitualmente, ser negativo, ya que en
ese
primer perodo la inversin ser previsiblemente alta y todava no se habr generado
ningn beneficio. Por esa razn en la ecuacin anterior los primeros trminos suelen
tener signo negativo.
Subsiste, sin embargo, un problema prctico importante: Qu tasa de actualizacin
debemos aplicar para efectuar los clculos? Es evidente que el hecho de aplicar un
a
tasa mayor o menor altera los clculos y lo hace de una forma que puede modificar
notablemente las conclusiones. Si se aplica una tasa ms baja, el grado de actuali
zacin
es menos acusado y, por tanto, se ven menos afectados los proyectos de mayor
duracin; si, por el contrario, se aplica una tasa ms alta, las cantidades ms alejad
as
en el tiempo resultan reducidas en una mayor proporcin.
Por lo tanto, como estamos estimando resultados futuros previsibles siempre se p
odrn
encontrar argumentos para aplicar una tasa de actualizacin mayor o menor. De toda
s
formas, esta dificultad se evita si aplicamos el criterio de la tasa interna de
retorno.
Tasa interna de retorno (TIR)
Definida como la tasa de actualizacin para la cual el VAN ser igual a cero, es dec
ir, no
se genera beneficio, los ingresos son iguales que los costes.
El inters de la TIR radica en la comodidad que supone, al tratarse de una tasa de

inters, el poder compararla con el coste real del dinero en el momento del estudi
o. Si la
TIR del proyecto es similar al coste del dinero en el mercado, el proyecto tendr
muy
escaso inters, ya que ser ms cmodo y menos arriesgado invertir en productos
financieros con tasas de inters fijas y con escaso o nulo riesgo. Cuanto ms alta s
ea la
TIR, mejores perspectivas de rentabilidad ofrecer el proyecto.
Antiguamente el clculo del TIR resultaba muy laborioso al tener que realizarse po
r
tanteo, probando con la ayuda de tablas auxiliares creadas para este fin qu valor
del
beneficio neto actualizado se obtena para diversas tasas de actualizacin hasta dar
con
aquella para la que el beneficio era nulo. En la actualidad el empleo de las cal
culadoras
electrnicas financieras y los ordenadores personales facilitan este clculo.
La TIR resulta muy til, no slo para comparar proyectos con inversiones diferentes
sino
tambin para decidir sobre el inters de un nico proyecto aislado. Un proyecto ser
rentable por s mismo siempre que su TIR sea superior al coste financiero de los
recursos que vayan a ser empleados para su financiacin.
Todos estos criterios anteriores pueden ayudar a la evaluacin de un proyecto, per
o hay
que tener en cuenta que algunos de los datos utilizados, principalmente los del
estudio
del mercado, son a veces poco fiables y por lo tanto en el caso de que varen las
cifras
estimadas las consecuencias pueden ser ms o menos importantes. Por ello, es por l
o
que se deben estudiar otros factores: el punto de nivelacin del proyecto, anlisis
de
sensibilidad y anlisis de riesgo.
Punto de nivelacin (UMBRAL DE RENTABILIDAD)
Llamado tambin punto muerto o de equilibrio, es aquel volumen de produccin donde
se igualan los ingresos y los costes. Suele expresarse en porcentaje de la produ
ccin, en
ese punto, sobre la produccin total prevista y se obtiene grficamente por la
interseccin de las curvas de ingresos y costes totales, que se convierten en rect
as
realizando ciertas simplificaciones.
Figura 4.3: Punto de nivelacin.
Anlisis de sensibilidad
Mediante este anlisis se mide la influencia de la variacin de determinados element
os
en el resultado econmico de un proyecto. Los principales elementos a estudiar son
el
precio de venta, volumen de la produccin, los costes fijos, etc.
El resultado econmico no depende por igual de todos estos elementos, ser ms
sensible a unos que a otros y es por ello que se estudiarn y revisarn con mayor
atencin aquellos que sean ms influyentes.
En la ilustracin 5 se representan diversas curvas donde en abscisas se indican va
lores
de factores importantes para establecer la rentabilidad como inversin, precios de

venta, precios de materias primas, etc. y en ordenadas los valores que indican l
a
rentabilidad en aplicacin de los distintos criterios estudiados: VAN, TIR, perodo
de
recuperacin del capital, etc. As, observamos la variacin de las rentabilidades en
funcin de los valores de los factores elegidos como de mayor importancia para el
resultado econmico del proyecto.
Figura 4.4: Anlisis de sensibilidad.
Anlisis de riesgo
Se define como riesgo de un proyecto la gama de posibles rentabilidades que se p
ueden
obtener de dicho proyecto. Si la rentabilidad se conociese con certeza, no exist
ira
riesgo; mientras que si la gama fuese infinita, la incertidumbre sera total.
Para estudiarlo se aconseja seleccionar detenidamente los elementos ms importante
s
para este anlisis. ste es el paso ms complejo, aunque la utilizacin de medios
informticos que existen en la actualidad facilita extraordinariamente esta tarea
y es por
ello que existen programas comerciales que permiten hacer este estudio con gran
rapidez.
Establecido un modelo informatizado del proyecto en estudio, es muy fcil modifica
r los
valores de los elementos considerados y obtener inmediatamente las variaciones d
e la
posible rentabilidad segn todos y cada uno de los criterios que se quieran aplica
r.
La dificultad no radica en el aspecto tcnico, pues es posible conocer la rentabil
idad de
cualquier inversin, sino en la conducta real de los consumidores que es imposible
de
predecir. Se puede haber realizado un importante estudio de mercado y resultar
posteriormente totalmente errneos los datos utilizados.
El xito de muchos proyectos est ligado a la intuicin, a la visin personal, al
entusiasmo, de los responsables que han liderado la idea y la han puesto en prcti
ca.
4.2.3. Seleccin de proyecto
Los proyectos vienen de muchas fuentes diferentes y por muchas razones. No todos

deben ser seleccionados para un estudio posterior. Es necesario examinar los pro
yectos
prospectivos desde una perspectiva de sistemas, de tal manera que se est
considerando el impacto del cambio propuesto sobre la organizacin compleja. Los
criterios para la seleccin de proyectos (de sistemas) son:
-Respaldo de la administracin.
-Temporizacin adecuada para comprometerse con el proyecto.
-Posibilidad de logro de mejoras de los objetivos de la organizacin.
-Que sea prctico en trminos de recursos para los analistas y la organizacin.
-Que el proyecto sea valioso comparado con otras formas en que la organizacin
puede invertir los recursos.
4.2.4. Aprobacin del proyecto
Finalizados los estudios previos, la organizacin promotora del nuevo proyecto deb
e
proceder a su estudio y anlisis antes de tomar ninguna decisin. Se trata de una
decisin difcil y trascendente por lo que suele tomarse a un nivel muy elevado de l
a
estructura empresarial o de la organizacin administrativa.
Si la decisin es negativa no proceder continuar ningn tipo de accin. En ocasiones
los estudios previos no son suficientemente claros y contundentes, y es necesari
o
profundizarlos ms o incluso complementarlos en algunos aspectos. En estos casos l
a
decisin se aplaza hasta disponer de la nueva informacin requerida. Finalmente,
cuando la informacin es suficiente y la conclusin positiva, se puede tomar la deci
sin
de aprobar el proyecto y acometerlo a corto plazo. Sin embargo, incluso en estos
casos
suelen detectarse algunos posibles puntos dbiles de la nueva inversin, y es necesa
rio
efectuar estudios adicionales para consolidar la decisin.
En la mayor parte de las ocasiones siempre habr determinados aspectos en los que
el
proyecto sea ms vulnerable y ser necesario tenerlos en cuenta a lo largo del
desarrollo, para conseguir los mejores resultados finales. Una vez tomada la dec
isin de
acometer el proyecto, debemos resguardarnos cuidadosamente de la tentacin
consistente en querer empezar a toda prisa intentando hacer gala de un gran dina
mismo
y preocupacin por el cumplimiento de los plazos establecidos. En este momento es
necesario desarrollar una de las etapas esenciales para la buena gestin y marcha
posterior, la etapa de preparacin y organizacin del proyecto.
Uno de los errores ms importantes y graves en gestin de proyectos es querer arranc
ar
con excesiva premura la obra, sin haber prestado la atencin debida a una serie de

tareas previas de preparacin, organizacin y planificacin que son imprescindibles pa
ra
garantizar la calidad de la gestin y el xito posterior de toda la operacin.
La definicin del proyecto, donde se analiza detenidamente el proyecto, se elabora
una
declaracin sobre el problema, en la que se define de forma muy concreta el proble
ma
que se pretende resolver, con sus diversos grados de necesidad, con las diversas

opciones tcnicas existentes, contemplando si se dispone de los recursos financier
os y
humanos precisos para seleccionar la mejor y ms adecuada alternativa. Naturalment
e
sta es la forma ideal de hacerlo, pero hay situaciones en las que la definicin del

proyecto evoluciona a medida que avanza el trabajo, simplemente porque ni el clie
nte
ni el equipo del proyecto son capaces de definir en su totalidad las necesidades
del
cliente.
4.2.4.1. Definicin del proyecto en cuanto a su alcance y contenido
Definir el alcance y contenido del proyecto significa establecer definitivamente
el
tamao, el proceso de fabricacin, la ingeniera preliminar, la localizacin, el
emplazamiento y el impacto ambiental y social. El tamao, fijado inicialmente en
funcin del mercado previsto, habr de ajustarse al proceso de fabricacin seleccionad
o
y a los equipos y materiales disponibles. En ocasiones estos factores, aparentem
ente
secundarios, imponen serias limitaciones al tamao previsto para una nueva instala
cin.
El proceso tecnolgico ya estar definido, o por lo menos identificadas y evaluadas
las
distintas alternativas viables, caso frecuente en proyectos de tipo qumico, metalr
gico
o energtico.
La ingeniera preliminar, adaptada a la tecnologa seleccionada, ser el punto de part
ida
para la ingeniera bsica. La localizacin y el emplazamiento, conjuntamente con las
consecuencias ambientales previstas para la instalacin, deben estar ya decididos,

especialmente la primera. Pueden existir alternativas para el emplazamiento defi
nitivo,
que se dilucidar durante la ejecucin de la ingeniera bsica, pero es preferible decid
ir
este punto en este momento del proyecto. De hecho, la anterior definicin del alca
nce y
contenido del proyecto no significa que todo est resuelto. Se conoce perfectament
e la
situacin y los mrgenes de seguridad de todos los factores fundamentales, y de ello
s
se parte para las etapas posteriores.
4.2.4.2. Definicin del presupuesto. Estimacin de la inversin
La estimacin del presupuesto debe estar ya fijada, aunque con mrgenes de toleranci
a
suficientes para compensar las indefiniciones de esta etapa del proyecto.
4.2.4.3. Definicin del proyecto en el tiempo. Planificacin
Se efectuar una primera planificacin, muy general, de las distintas etapas del
proyecto. Para ello se debern analizar y corregir los datos de los estudios previ
os.
Tambin se introducirn ya una serie de plazos parciales, importantes, que pueden
condicionar el cumplimiento de la planificacin general establecida. Realizada ya
la
primera planificacin se iniciar la ingeniera bsica.
4.2.4.4. Definicin del proyecto en cuanto a su forma de ejecucin
Existirn, probablemente, diferentes alternativas disponibles para la realizacin de
l
proyecto. Se deber tomar la decisin de quin va a realizar ese estudio, directamente
la
organizacin promotora del proyecto o si se va a solicitar colaboracin exterior, lo
s
servicios de un consultor o de una empresa de ingeniera.
Si se decide por la segunda opcin el grado de colaboracin puede ir desde una mera
asistencia en puntos especficos a travs de una empresa consultora, hasta un contra
to
llave en mano y a precio fijo, que llevar a cabo un contratista general, pasando po
r
unos posibles servicios de ingeniera, o incluso de direccin profesional de constru
ccin,
realizados por una empresa de ingeniera.
4.2.4.5. Definicin del proyecto en cuanto al equipo responsable
Tambin, y de acuerdo con la forma de ejecucin seleccionada, habr que decidir cul
va a ser el equipo responsable de la ejecucin del proyecto, quines lo van a formar
,
cules van a ser sus responsabilidades, cmo se van a organizar y quin lo va a dirigi
r.
La eleccin del director del proyecto es fundamental, ya que su figura es un eleme
nto
clave para el buen desarrollo del trabajo y acertar en su designacin es la mejor
forma
de asegurar el xito del proyecto.
El director del proyecto es el mediador y punto de contacto (y referencia) para
los
diferentes agentes del sistema, ya sean internos (sus superiores en la empresa,
el
equipo de trabajo, etc.) o externos (cliente, proveedores, subcontrastistas, etc
.). Sus
objetivos son:
-Conseguir que el equipo de trabajo funcione adecuadamente.
-Conseguir que el cliente est satisfecho.
-Obtener buenos resultados para la empresa.
4.2.4.6. Objetivos del proyecto
Para conseguir los objetivos y el resultado que el proyecto pretende alcanzar es
preciso
poner en juego determinados recursos y desarrollar un conjunto de actividades qu
e
contribuyan a acercarse gradualmente al final previsto. Por lo tanto, el tener d
efinidos
los objetivos y haber nombrado un director de proyecto es importante, pero no
suficiente, aunque ste quiera alcanzar la meta con toda su voluntad.
El camino que conduce a dicha meta es normalmente largo y plagado de dificultade
s y
obstculos, por lo que ser necesario desplegar toda clase de esfuerzos y habilidade
s.
Pero, antes, es preciso elegir y trazar ese camino.
Es aconsejable poner todos los objetivos del proyecto por escrito como mnimo por
las
siguientes razones:
El proceso de redactar los objetivos obliga a clarificarlos. Es frecuente que, c
uando
tenemos un objetivo slo en la cabeza, no est siquiera muy claro para nosotros,
mucho menos para los dems.
Al poner los objetivos por escrito, todos los miembros del equipo del proyecto
pueden tener acceso a ellos, de forma que no se olvide nada.
Es ms probable que haya unidad de accin cuando se persigue un objetivo comn.
Para alcanzar la mxima efectividad como director, es til que el lector piense que
su trabajo consiste en alcanzar los objetivos del proyecto y ayudar
simultneamente a los miembros del equipo del proyecto a alcanzar sus propios
objetivos. De esta forma, se crea un compromiso con el esfuerzo del proyecto, lo

que en definitiva dar lugar al alineamiento de los miembros del equipo con la
orientacin general que sigue el proyecto, condicin necesaria para el xito.
Cuanto mayor sea la participacin en el establecimiento de objetivos vlidos de
trabajo, con responsabilidad sobre los resultados, mayor ser la motivacin para
alcanzarlos. Esto no significa que sea necesaria una participacin total para la
gestin de un proyecto, sino que, cuando es factible, los miembros del equipo
estarn ms comprometidos con los objetivos si han tenido algo que ver con su
fijacin.
Por ltimo, slo se pueden medir los progresos con respecto a aquello hacia lo que
se progresa. Por tanto, los objetivos constituyen una meta hacia la que avanzar,
y
permiten medir los progresos realizados en el proceso. Recordemos: si no sabemos

adnde vamos, cmo vamos a saber que hemos llegado?
La declaracin de los objetivos se deber de hacer de la forma ms clara posible para
los
cuales se prepararn los pasos especficos de implantacin. As, se podr saber cundo
se estn alcanzando los resultados deseados. A continuacin se ofrecen unas
orientaciones que pueden servir de ayuda:
Una declaracin de objetivos debe ser especfica; es decir, no puede ser una
declaracin vaga y borrosa, del tipo quiero lo mejor.
Los objetivos deben ser mesurables, siempre que sea posible. Esto puede ser muy
difcil de conseguir. A continuacin se exponen las unidades de medida para los
objetivos cuantificables:
- Unidades de tiempo - Fases
- Tasas de frecuencia - Percentiles
- Ratios - Cuartiles
- Nmeros ndice - Deciles
- Porcentajes - Desviaciones medias
- Promedios - Correlaciones
- Agregados numricos - Volmenes
- Grados - Unidades de produccin
En el caso de que el objetivo sea no cuantificable, debe utilizarse una prueba
cualitativa, es decir, no podemos saber si se ha alcanzado un objetivo si no
disponemos de pruebas o criterios para utilizar.
Deben encajar con los objetivos de mximo nivel de la organizacin. Por lo que se
refiere a los proyectos, esto significa que los objetivos establecidos por los g
rupos
funcionales deben respaldar la consecucin de los objetivos generales del proyecto
.
A su vez, los proyectos se eligen de forma que permitan alcanzar los objetivos
generales de la organizacin.
Los objetivos deben traducirse, si es posible, en elementos tangibles, que puede
n
ser constituidos por informes de evaluacin, recomendaciones escritas, etc., es
decir, algo material que resulte de utilidad como medida o demuestre que se ha
alcanzado un hito.
Los objetivos deben ser comprensibles, es decir, deben estar formulados para que

otras personas entiendan lo que se pretende lograr. Este hecho es a menudo causa

de problemas importantes en las organizaciones.
Deben estar limitados en el tiempo, si es posible.
Resulta til establecer un orden de prioridades cuando es necesario alcanzar
algunos objetivos para llegar a otro.
Cuando sea oportuno, debe asignarse un factor de riesgo a los objetivos, de form
a
que las dems personas de la organizacin sean conscientes de ese riesgo.
En la declaracin de los objetivos, se debe decir qu se va a conseguir, no cmo
conseguirlo.
El objetivo debe ser alcanzable. La gente no se comprometer con objetivos poco
realistas.
Se debe especificar asimismo un nico resultado final. Cuando se combinan varios
objetivos en la misma declaracin, resulta difcil comprender bien lo que se est
diciendo.
Los problemas de cada proyecto son muy particulares, tanto en su nmero como en su

naturaleza, de ah que los objetivos puedan variar mucho de uno a otro proyecto. S
in
embargo hay una serie de aspectos del proyecto que habitualmente se convierten e
n
crticos y alrededor de los cuales suelen establecerse siempre los objetivos princ
ipales.
stos son:
-La capacidad de produccin.
-La calidad del producto.
-Los costes de produccin.
-Los plazos de ejecucin.
-Y el presupuesto de la inversin.
Los tres primeros se refieren claramente a la calidad global del proyecto, por l
o que es
habitual establecer como objetivos principales de cualquier proyecto los de cali
dad,
plazo y precio.
Capacidad de produccin
Un objetivo principal prioritario ser alcanzar la capacidad de produccin dentro de
los
plazos establecidos, subordinndose a esta situacin, si es necesario, otros aspecto
s
importantes del proyecto.
Se deber asegurar desde el momento inicial el volumen establecido para la capacid
ad
de produccin porque algunos proyectos son muy sensibles a las variaciones de
produccin.
Calidad del producto
En algunos casos (industria de alimentacin y farmacutica, qumica fina, etc.) es
imprescindible cumplir exactamente las especificaciones de calidad del producto.
Los
usos y aplicaciones del producto, las exigencias de un mercado de exportacin, la
calidad ofrecida por la competencia, etc., pueden fijar esta necesidad.
Costes de produccin
Determinados proyectos son muy delicados, y resulta imprescindible realizar un
desarrollo de ingeniera perfecto con el fin de respetar totalmente las caractersti
cas del
proceso. Los costes de produccin pueden llegar a ser muy elevados como
consecuencia de la existencia de un funcionamiento deficiente debido a cambios o

errores que provocar averas.
Plazos de ejecucin
El tiempo es el elemento principal en toda planificacin, que consiste ante todo e
n situar
en el tiempo las tareas a realizar, cmo sabe un director de proyectos cunto tiempo
va
a llevar un proyecto, aun suponiendo que sepa cuntos recursos humanos hay
disponibles para elaborarlo? La respuesta, naturalmente, la da la experiencia. E
n un
proyecto si una tarea se ha realizado un nmero elevado de veces se conoce la dura
cin
media, y sta se puede utilizar como base para la realizacin de una estimacin.
Una de las hiptesis de partida en la estimacin del tiempo en un proyecto es que se

utilizan duraciones medias si no se especifica lo contrario. As, si un proyecto s
e
compone de un nmero elevado de actividades, la realizacin de algunas de stas
llevar ms de la duracin media estimada, y por el contrario otras se realizarn en un
plazo por debajo de esa media. Esta forma de trabajar nos asegura que el proyect
o se
realizar en torno al plazo medio previsto.
Existe la posibilidad de aumentar el plazo de finalizacin del proyecto para aumen
tar la
probabilidad de finalizacin en la fecha programada. Consecuencia de ello sera un
aumento del coste presupuestado del proyecto, tal vez hasta el punto de que el t
rabajo
se quede sin financiacin. Es por ello que se utiliza la hiptesis mencionada
anteriormente. Slo puede elaborarse una duracin media prevista para una actividad
si
se supone que el trabajo va a ser casi idntico a otro hecho anteriormente, y que
la
persona o personas a quienes se asigne la tarea van a tener cierto nivel de apti
tud. A
una persona con menor nivel de actitud le supondr ms tiempo realizar un trabajo, y
a
la inversa, una persona con mayores aptitudes probablemente har el trabajo ms
deprisa. As, se realizarn los ajustes teniendo en cuenta la experiencia o habilida
d de
las personas a quienes se asigna la tarea.
Tambin es conveniente remarcar que no existe una correlacin exacta entre
experiencia y velocidad en la realizacin del trabajo. No siempre una persona con
ms
experiencia har el trabajo ms rpido que otra menos experimentada, y presionar a la
gente no siempre da buen resultado.
Otro factor a tener en cuenta es cunto tiempo productivo va a dedicar cada da a la

tarea la persona de que se trate. Hay que tener en cuenta el tiempo que no se de
dica al
proyecto, y en ste hay que incluir la asistencia a las reuniones, atender el telfo
no,
esperar a proveedores y otras actividades que reducen el tiempo disponible para
dedicar
al trabajo en el proyecto.
Tambin es conveniente tener en cuenta aquellas personas con experiencia mnima a la
s
que se intentar asignar aquella tarea ms parecida de la que se tenga experiencia.
Si
prcticamente no existe experiencia que se pueda utilizar como base para la estima
cin,
tal vez sea adecuado emplear tcnicas PERT, mtodo DELPHI o algn otro mtodo de
estimacin. Para la aplicacin del mtodo DELPHI al proyecto, consulte el lector la ob
ra
de Burril y Ellsworth.
Slo para determinados tipos de proyectos existen manuales con tablas de promedios

que contienen las duraciones medias previstas para actividades tpicas, as como
factores de ajuste para compensar la localizacin geogrfica, las condiciones
meteorolgicas y otras variables, por ejemplo, en los proyectos de construccin.
En cambio, en los proyectos en los que no existen este tipo de tablas, se recurr
e a datos
histricos de proyectos anteriores.
Los retrasos no previstos pueden demorar la entrada de ingresos procedentes del
proyecto, y en consecuencia retrasar los plazos de amortizacin de los crditos
bancarios con los que se financi el proyecto.
Presupuesto de la inversin
Una de las preocupaciones importantes en cualquier proyecto es la limitacin
econmica. En ocasiones es imprescindible mantener el proyecto dentro de los
presupuestos asignados, cuando existen limitaciones de recursos, crditos caros, p
oca
capacidad de endeudamiento o simplemente rentabilidades no demasiado claras.
4.2.5. Estructura de descomposicin del proyecto (EDP)
Al hablar de la estimacin, debe quedar claro que estimar la duracin de una tarea e
s
mucho ms sencillo que estimar la duracin de un proyecto, que est formado de
multitud de tareas.
En el caso que se deba realizar una estimacin rpida para decidir si debe llevarse
a
cabo un proyecto, es suficiente compararlo con otro anterior introduciendo los a
justes
necesarios para las diferencias ms evidentes.
Si interesa un mayor grado de exactitud es conveniente realizar una descomposicin

minuciosa de todos los incrementos o tareas que va a ser necesario realizar, ell
o
permitir profundizar ms en los aspectos ms problemticos y realizar una estimacin
con una exactitud relativamente buena. Este desglose facilitar estimar los recurs
os
necesarios para el proyecto, su posible coste y el tiempo preciso para su ejecuc
in.
La estructura de descomposicin de un proyecto debe iniciarse con un organigrama,
en
forma de rbol o pirmide, y en el que aparezcan los distintos niveles en que pueden

organizarse todas las actividades necesarias para la total ejecucin del proyecto,

escalonndose desde el nivel superior a los ms inferiores.
La descomposicin del proyecto exige dividirlo en tareas y stas a su vez en subtare
as
para descomponerlas finalmente en paquetes de trabajo (PT), es decir, al nivel d
e detalle
requerido. Los paquetes de trabajo se definen como aquellas partes del proyecto
que
pueden ser desarrolladas por una persona u organizacin con plena responsabilidad
sobre las mismas.
La divisin ms pequea de un proyecto se considerar un paquete de trabajo si cumple
las siguientes caractersticas:
El trabajo que representan es una subdivisin natural del trabajo total del proyec
to.
Su alcance y contenido es nico y no est duplicado.
Puede ser desarrollado por una persona u organizacin con plena responsabilidad.
Ha de ejecutarse con un perodo de tiempo determinado, con fechas programadas
de comienzo y terminacin.
Puede asignrsele un presupuesto para su realizacin susceptible de expresarse en
unidades monetarias, horas de trabajo u otras unidades.
Para realizar la estimacin del coste total del proyecto, primero se determinar el
coste
de cada paquete de trabajo, luego se sumarn los costes de los paquetes de trabajo
que
formen parte de una subtarea para obtener el coste de sta, y as sucesivamente hast
a
calcular el coste total del proyecto.
4.3. FASE DE CONSTRUCCIN
Una vez superada la fase de concepcin, se decide continuar adelante con el proyec
to o
no. Si se decide la primera opcin, entonces se pasa a la siguiente fase, que es l
a fase
de construccin.
El proyecto es ahora, cuando toma forma, se materializa. Es posible que esta sea
la fase
ms larga y costosa. No es una fase de estudio, por lo tanto se debe prestar espec
ial
atencin a la planificacin, seguimiento y control del proyecto, as como una buena
gestin de los recursos. En sntesis esta fase es una corporificacin de lo ya definid
o y
concebido, en algo concreto y material.
4.3.1. Planificacin de actividades y recursos
Planificacin equivale, en su concepto, a configuracin del futuro. Planificar es se
guir
un proceso encaminado a fijar y desarrollar objetivos y/o medidas que conduzcan
a
alcanzar la totalidad o bien, una determinada parte de estos objetivos.Durante l
a
planeacin se determina:
La misin, objetivos, metas y estrategias del proyecto
La estructura de desagregacin de trabajo.
Los diagramas de precedencia de actividades.
La programacin en el tiempo basada en los diagramas de precedencia.
El plan para el soporte de recursos del proyecto.
Los proyectos tienen en general un desarrollo sucesivo en fases o etapas ntimamen
te
relacionadas. Se puede decir que la actividad de proyectar cumple un ciclo que
encuentra su origen en una realidad existente y finaliza en la misma realidad,
transformndola con arreglo a unos objetivos y unos ciertos criterios propuestos.
En
este ciclo, integrado por una serie de actividades pueden distinguirse algunas e
tapas
claramente diferenciadas por sus medios y fines y que frecuentemente, se llevan
a cabo
de forma competa y sucesiva.
A principios de la dcada de los 80s, la disciplina denominada Direccin de Proyectos
recibi un gran impulso con la creacin de software especializado que corra en los
ordenadores personales. Sobre todo, la creacin del software Harvard Project Manag
er,
en 1983, concentr el inters del management en la confeccin de presupuestos,
organigramas y metodologas de manejo de recursos para los proyectos.
El Harvard Project Manager gener diagramas PERT / CAM, diagramas de Gantt, curvas

de costos acumulados, diagramas de cantidad de recursos y numerosas tablas. Se
trataba, en efecto, de un paquete que integraba software para planificacin y cont
rol de
proyectos. Desde entonces, el software para direccin de proyectos se ha convertid
o en
una herramienta de trabajo verdaderamente eficiente. Y a medida que se haca cada
vez
ms sofisticado, tambin se tornaba ms difcil aprender y usar. Un paquete de
software como el Harvard Project Manager poda ser aprendido en un da. Ahora bien,
el
software actual requiere por lo menos cinco das de aprendizaje. Con la creciente
demanda de entrenamiento en software de direccin de proyecto, surge una pregunta
obvia: quin debe ser entrenado? Inicialmente se supona que los managers de
proyecto seran los usuarios naturales del software. Pero la existencia demostr que
si
se segua ese camino, los directores de proyectos dedicaran la mayor parte del tiem
po
a trabajar con el software y poco tiempo a ocuparse del proyecto en s.
Hoy en da la mayora de las organizaciones que emplea software para direccin de
proyectos ha establecido consultores internos o grupos de apoyo que son los expe
rtos
en software. Esas personas tienen la responsabilidad de mantenerse actualizadas
respecto de los desarrollos ms recientes en el software de planificacin, confeccin
de
presupuesto y asignacin de recursos. Tambin deben traducir esos desarrollos en
aplicaciones prcticas que pueden ser usadas por los miembros del equipo de proyec
to.
En general, se puede decir que el software para direccin de proyectos es benefici
oso y
til para los profesionales, porque impone pautas para la direccin de proyectos que
son
aceptadas luego por muchas organizaciones. Por otra parte, si todos los empleado
s de
una organizacin utilizan el mismo software para trabajar en diversos proyectos, l
os
datos de planificacin y control llegan a ser comparables. Adems, la direccin
sistematizada sensibiliza a la gente para valorar la dimensin del proyecto. Mient
ras
planifican y realizan las actividades de sus proyectos por medio del software de

direccin, acumulan datos histricos que despus pueden ser usados para orientarse en
el manejo de proyectos futuros. Actualmente, cuando alguien pregunta: Cunto
tiempo se demora en verificar cincuenta lneas de cdigo?, los miembros del equipo
pueden responder revisando las cifras del trabajo anterior, que han sido archiva
das por
el software de direccin del proyecto. Pero el software tambin tiene algunas
desventajas. En primer lugar, impone al equipo de proyecto una carga administrat
iva
mayor, que no siempre se ve justificada por los beneficios derivados de la utili
zacin del
software. En segundo lugar, este instrumento de trabajo es bastante rgido, de mod
o
que muchos de los diagramas que crea tienen una importancia relativa en ciertas
organizaciones. Y, por ltimo, este software contribuye a perpetuar la idea de que
el
management del proyecto se ocupa principalmente de las tcnicas conocidas, como lo
s
diagramas de PERT / CPM y las curvas de costo acumulado, cuando en realidad el
management de proyecto debe concentrarse tambin en cuestiones blandas como,
por ejemplo, la poltica de los proyectos, el manejo de los recursos y la definicin
de las
necesidades de la compaa.
4.3.1.1. Programacin del proyecto
Durante esta etapa se establece una organizacin, identificando a los individuos q
ue
van a participar en el proyecto, decidiendo de quin van a depender y definiendo l
os
lmites de su autoridad, obligaciones y responsabilidades.
No obstante, tambin es muy conveniente que la formulacin del proyecto, una vez
adoptadas las necesidades previas, se refleje en un documento, que puede ser sim
ple y
breve, pero que ha de recoger con claridad los objetivos bsicos del proyecto. Se
trata
de un seudo-contrato entre el cliente y el director de proyecto que sirva de marco
de
referencia al desarrollo posterior del proyecto. Este documento es un mecanismo
de
organizacin muy til para la direccin de proyectos y as llevar un control del proyect
o
a lo largo de la vida de ste, puede estar constituido en realidad por varios cuad
ernos en
el caso de proyectos muy grandes.
Tcnicas de planificacin
Planificar es buscar la mejor combinacin posible entre los objetivos del proyecto
y los
recursos de que se dispone o a los que se puede recurrir, con sus correspondient
es
limitaciones, costes y rigideces.
La experiencia muestra que muchos directores de proyecto planifican poco o nada,
o
que los planes que crean resultan inadecuados. Trabajar sin un plan es la esenci
a del
planteamiento desordenado. Si se trabaja en estas circunstancias el director de
proyectos no tiene el control, que es uno de los requisitos ms importantes del di
rector,
o sea, que es muy probable que el proyecto sea un fracaso.
Cuando se habla de control se refiere comparar dnde estamos con dnde se supone
que deberamos estar, y la nica manera de saber dnde deberamos estar es
compararlo con un plan. As, se observarn mejor los progresos. Cuando se analice es
ta
situacin si se detectan posibles desviaciones con respecto al objetivo se emprend
ern
acciones correctoras.
El problema de muchos directores de proyectos es que no planifican porque segn el
los
no tienen tiempo. Esta actitud es probable que desencadene una crisis en el proy
ecto.
No obstante, an cuando se planifica se cometen errores. De stos el ms frecuente es
no implicar en el proceso de planificacin a la gente que debe ejecutar el plan. S
i el
director del proyecto planifica el trabajo de otras personas sin contar con ella
s es muy
probable que estime un tiempo de realizacin menor del que realmente les llevar.
Adems, estas personas no trabajan a tiempo completo en la actividad del proyecto.

Es frecuente encontrarse con la necesidad de afrontar varios proyectos al mismo
tiempo, por lo que habr diversos directores de proyectos. En este caso hay un dir
ector
de funcin que se encargar de distribuir los limitados recursos de la forma ms
conveniente. Ello crea problemas: por un lado el director del proyecto, deseoso
de
alcanzar los objetivos del proyecto querr disponer de los recursos que considere
necesarios en el momento oportuno, pero es posible que el director de funcin no l
e
proporcione lo que desea porque ste debe atender los requerimientos de los distin
tos
directores de proyecto.
Habitualmente se representa la planificacin de un proyecto en un diagrama de Gant
t,
situando en el eje de ordenadas la relacin de actividades a realizar y en el eje
de
abscisas la escala de tiempos.
Una adecuada planificacin de proyectos debe producir siempre dos Gantt diferentes
: el
Gantt de actividades que se ha descrito anteriormente, y el Gantt de recursos, q
ue sita
en el eje de abscisas los diversos recursos disponibles.
La necesidad de hacer coherentes ambos diagramas de Gantt es mayor cuantos ms
proyectos deban planificarse y mayor cantidad de recursos se ponga en juego, ell
o a su
vez dificulta conseguir una combinacin ptima de objetivos y recursos.
Las caractersticas ms importantes para la planificacin de proyectos son las
siguientes:
Se refleja en dos diagramas de Gantt: Gantt de actividades y Gantt de recursos.
Es
el resultado de probar diversas combinaciones posibles de actividades y
recursos.
Ha de ser constantemente seguida y frecuentemente actualizada.
En
general, no ser posible efectuar una buena planificacin ni mantenerla
actualizada si no se dispone de apoyo informtico para su tratamiento, como
veremos ms adelante.
En la mayor parte de los proyectos no hay un nico planteamiento que se pueda apli
car
a la resolucin del problema. Cuando esto ocurre se denominan problemas abiertos.
Slo un nmero reducido de proyectos se pueden considerar problemas cerrados, como
por ejemplo, la revisin de un generador de energa averiado, donde una vez se ha
diagnosticado el defecto del generador, el planteamiento para la reparacin del ap
arato
est bastante definido. Tratar de planificar un proyecto a largo plazo de forma de
tallada
a veces no es conveniente porque en muchos casos cuando finaliza una fase del
proyecto se toman decisiones que afectan al trabajo posterior.
Una forma til de afrontar un proyecto para evitar este tipo de problemas es plani
ficar
por fases, es decir, planificar nicamente hasta el nivel de detalle que se conoce
hasta
ese momento. Esta forma de planificar no resulta aceptable cuando imponer una fe
cha
lmite antes de iniciar el proyecto es de importancia vital, como por ejemplo un l
ibro que
tenga que estar publicado y entregado en la fecha que se estrena la pelcula, para

obtener beneficios a costa del xito de sta. No obstante, hay casos con fecha lmite
en
los que es til la planificacin por fases.
Si se utiliza este planteamiento al finalizar cada una de las fases se debern ten
er dos
documentos de planificacin: un plan de fase y un plan de proyecto. El plan de fas
e se
prepara a nivel de tarea o de paquete de trabajo, y proporciona el trabajo detal
lado que
va a realizarse en la siguiente fase. El plan del proyecto es el plan general pa
ra la parte
restante del proyecto, y en l se especifica la fecha de terminacin, la estimacin de

recursos necesarios y el coste hasta la finalizacin del proyecto.
Los grafos
Existen diversas tcnicas de planificacin de proyectos basadas en el empleo de graf
os
(PERT, CPM, etc.), que son las representaciones grficas en las que los diferentes

puntos de un conjunto se relacionan entre s mediante enlaces que, generalmente es
tn
orientados en una direccin.
La tcnica de los grafos es idnea para observar mejor las tareas que forman el
proyecto, que en el dibujo se identifican con letras, cmo estn relacionadas y en q
u
orden se deben ejecutar, es decir, facilitan la comprensin para personas que no s
on
tcnicas en la materia (clientes, etctera). Las actividades precedidas inmediatamen
te
por ms de una, o sea, que llegan a ellas dos o ms arcos no se pueden iniciar hasta

que no estn las anteriores finalizadas.
En el grafo se pueden incluir actividades de tiempo de duracin cero, conocidas co
mo
actividades ficticias, que normalmente no existen en la realidad como tal, pero
se
incluyen por una de las dos razones siguientes:
Para indicar la existencia de una relacin de precedencia que de otra forma sera
difcil de representar grficamente.
Para llamar la atencin en el momento de la planificacin o del seguimiento, sobre
un acontecimiento previsto, como una reunin a celebrar en cierta fecha o
diferentes puntos de control que el director del proyecto quiere establecer para
un
mejor seguimiento de la obra.
El camino crtico
Estas tcnicas tienen especial inters cuando al grafo se le aade el plazo de tiempo
previsto para cada una de las actividades. El tiempo es el elemento principal en
toda
planificacin.
Se conoce como camino una secuencia de arcos tal que el extremo final de cada ar
co
coincide con el extremo inicial del siguiente. La longitud o plazo de duracin de
un
camino es la suma de las longitudes o tiempos de los arcos que componen dicho
camino.
Normalmente existen diferentes caminos para desplazarse de un vrtice a otro, y
pueden tener o no la misma longitud. La duracin total del proyecto viene dada por
el
camino ms largo que adems determina la fecha ms temprana en que puede estar
terminado el trabajo que recibe el nombre de camino crtico:
El camino crtico permite comprobar si la planificacin efectuada coincide con los
objetivos del proyecto, sino habr que buscar nuevas alternativas.
Las actividades que componen el camino crtico reciben el nombre de crticas. Un
cambio en el tiempo de duracin de una actividad crtica tambin cambia la
duracin total del proyecto. Si una actividad crtica se retrasa tambin lo har la
duracin del proyecto, y viceversa, si una actividad crtica se acorta tambin
supondr una reduccin del tiempo total del proyecto.
Los cambios en el periodo de duracin de una actividad no crtica no influyen en el
proyecto, a no ser que la tarea sea tan grande que se haya vuelto a su vez crtica
.
El camino crtico permite controlar mejor las actividades crticas o las que podran
hacerse crticas con facilidad, que son las que ms preocupan porque pueden
afectar negativamente en la duracin del proyecto.
El camino crtico puede llegar a ser muy difcil de realizar en proyectos de tamao
importante y es por ello que se recomienda la ayuda de un ordenador. Cuando haya
ms
de un camino crtico se debe intentar que slo quede uno, as reducimos el riesgo tota
l
del proyecto.
Las holguras
Ya se ha dicho anteriormente que existen tareas en las que un cambio en su perio
do de
duracin no influye en la duracin total del proyecto. Se dice que son actividades q
ue
tienen holgura, es decir, que su tiempo de inicio y finalizacin se puede desplaza
r,
siempre dentro de unos lmites, sin afectar a la duracin del proyecto.
Fecha final forzada
La mayor parte de las veces se impone una fecha final al proyecto. Esta fecha fi
nal
puede ser anterior a la fecha ms temprana de finalizacin del proyecto. Cuando esto

ocurre, qu opciones tenemos? Una sera adelantar la fecha de inicio del proyecto,
pero sta queda descartada porque la fecha de comienzo viene a menudo dictada por
la
disponibilidad de recursos o algn otro factor. La otra opcin es acortar el program
a, y
cmo? acortando el camino crtico, es decir, reducir la duracin de algunas de las tar
eas
que lo componen.
Control y seguimiento del proyecto. Acciones correctoras
Una de las responsabilidades del director del proyecto y de otras instancias jerr
quicas
involucradas en la operacin, es el seguimiento y control de los resultados. Es po
r ello,
que una vez estudiados los resultados se podrn adoptar acciones correctoras si fu
ese
necesario. El control del proyecto, puede decirse que empieza en el momento en q
ue se
inicia el proceso de definir los objetivos mediante contactos y negociaciones co
n el
cliente. Los objetivos son mltiples: resultado o calidad, coste y plazo. El objet
ivo de
resultado se reflejar en las correspondientes especificaciones tcnicas; el objetiv
o de
coste se desglosar en un presupuesto por actividades y por recursos; el objetivo
de
plazo se concretar en una adecuada planificacin del proyecto.
Un buen director de proyectos deber ser capaz de adoptar las medidas necesarias q
ue
crea conveniente para corregir posibles desviaciones con respecto a lo que se ha
ba
previsto anteriormente a medida que avanza el proyecto, por lo tanto, deber domin
ar
en todo momento su evolucin. Es conveniente, pues, una definicin clara y concisa d
e
los objetivos antes de empezar a trabajar. Cuanto mejor definidos estn, mejor
encaminado ir el equipo del proyecto y se evitarn desviaciones innecesarias que
corregir.
El fin principal de la planificacin no es hacerla muy bien para acertar, para que s
e
cumpla exactamente lo que habamos previsto, como creen muchas personas, sino que
es un instrumento de gestin que define el marco de referencia en que nos queremos

mover.
Modificacin de los lmites
A veces, se debern reconsiderar de una forma ms o menos profunda los objetivos
inicialmente establecidos, ya sea por nuevas circunstancias o a peticin del clien
te. Ello
se denomina modificacin de los lmites. Cuando se lleva a cabo esta actuacin no
significa que se hayan producido desviaciones respecto las previsiones iniciales
y haya
que emprender acciones correctoras, sino que simplemente aparezcan hechos nuevos

que aconsejen replantearse los objetivos iniciales.
Estas reconsideraciones son a veces la causa de conflictos e insatisfacciones, t
anto
para el cliente como para el equipo del proyecto. Adems, quejas comunes de tcnicos

que trabajan en los proyectos son las continuas peticiones por parte de los clie
ntes para
aadir cosas que no haban sido previstas con anterioridad o cambiar algunas de ella
s.
Adems, estas peticiones de los clientes, en muchos casos son poco claras, y
consecuentemente se las responde con vaguedad. Los clientes no dan importancia a
los
cambios que piden y piensan que no van a repercutir en el proyecto, pero para el
equipo
del proyecto supone un gran esfuerzo. sta conducta por parte del cliente puede
perjudicar seriamente el proyecto, causando retrasos. No obstante, el director d
el
proyecto no debe sentirse ofendido, sino mantener una actitud de profesionalismo
y
objetividad estudiando las consecuencias que pueden tener estos cambios en el
desarrollo del proyecto e incorporarlas siempre que sea oportuno y una vez final
izada
esta labor presentar al cliente los nuevos objetivos propuestos.
Se deber levantar acta para dejar constancia en todas las reuniones, as como de la
s
conversaciones en las que se traten temas de especial inters, porque es imposible

acordarse de todo transcurridos unos meses y ello llevar a incomprensiones,
desacuerdos, etc.
Los objetivos deben ser compartidos por cliente y equipo del proyecto para evita
r
futuras interpretaciones divergentes que pueden llevar a conflictos. Desde un pu
nto de
vista formal, la definicin inicial de los objetivos debe considerarse como un con
trato
formal entre cliente y director de proyecto. Cualquier alteracin de los lmites sup
one
una modificacin de algunos de los aspectos sustanciales de dicho contrato, es por
ello
que debe realizarse entre las mismas partes y con el mismo grado de rigor y sole
mnidad.
En la prctica todo esto puede resultar pesado y formalista pero no tiene por qu se
r as.
No debe pensarse un acuerdo como algo laborioso, simplemente podra ser una carta
o
la firma de un acta en una reunin. Cuanto mayor sea la buena relacin entre ambas
partes ms rpido se realizar el acuerdo.
No es necesario revisar el acuerdo cuando la modificacin es pequea, es aconsejable

recopilar algunas de stas para tener un conjunto de dimensin significativa.
Control de la calidad
Aunque hemos destacado en todo momento la importancia de los objetivos de coste
y
plazo para el xito del proyecto, no puede olvidarse que el objetivo ms importante
de
los tres es el de resultado o calidad porque es el que refleja el deseo original
del cliente.
Una definicin de calidad adecuada a las necesidades de ingeniera es la establecida
por
la norma UNE 66-001-00: conjunto de caractersticas de un producto o servicio que
le
confieren su aptitud para satisfacer unas necesidades expresadas o implcitas.
El control de la calidad slo es posible si se parte de unas especificaciones clar
as,
previamente definidas, conocidas y compartidas por ambas partes. El control de l
a
calidad consiste en comparar el trabajo que se est ejecutando con las especificac
iones
y comprobar si se estn respetando o si existen diferencias significativas, todo e
llo
mediante la realizacin de anlisis y estudios peridicos, aplicando las tcnicas
pertinentes en cada tipo de proyecto y en cada una de sus etapas. Este control r
equiere
conocimientos tcnicos profundos en la materia que se trate, mediante anlisis,
mediciones y muestreos. En muchos casos, por la importancia y la labor de sta tar
ea,
ser preferible encomendarla a personas o empresas especializadas con el fin de
garantizar la objetividad y eficacia del control.
La responsabilidad del control de la calidad incumbe tanto al cliente como al di
rector de
proyecto. Para el cliente un seguimiento del desarrollo del proyecto es de sumo
inters
si quiere comprobar que las especificaciones establecidas se van cumpliendo, sin
o al
final se puede encontrar con la sorpresa de un resultado insatisfactorio sin pos
ibilidad
de corregir. Para el director del proyecto, significa la obligacin de crear la ob
ra con las
especificaciones establecidas para mantener el compromiso que tiene con el clien
te.
La calidad ha de contemplarse como calidad funcional y no como calidad intrnseca
o en
abstracto. Para entender esta idea un ejemplo podra ser el de un automvil. ste no
tiene mayor calidad por el material de que est hecha su carrocera sino por su nive
l de
funcionamiento y prestaciones. Muchos conflictos se producen por los diferentes
puntos de vista del tcnico que realiza el proyecto y el cliente. A veces el tcnico

intenta buscar una calidad ms elevada para hacer una obra ms interesante
profesionalmente alejndose de las especificaciones del cliente.
El control de calidad debe ser preventivo y no realizarlo una vez finalizada la
obra. El
control de calidad a posteriori nicamente servir para comprobar que no se ha
alcanzado el nivel de calidad deseado. Si se detectan defectos a posteriori ser
normalmente imposible o inviable corregirlos por elevados costes de reparacin. Po
r ello
debe efectuarse a lo largo de toda la obra con tiempo para ir corrigiendo posibl
es
deficiencias que no suponen costes aadidos importantes. Para garantizar la calida
d de
un proyecto son necesarias una serie de acciones por parte del director del proy
ecto,
que son seleccin, formacin y motivacin:
Seleccin
El primer paso necesario para garantizar la calidad del trabajo es seleccionar
adecuadamente al equipo que va a colaborar en el proyecto. El director del proye
cto
deber formar un equipo adecuado en cantidad y capacidad a las exigencias del
proyecto. Si se trabaja con personas inadecuadas es improbable que se consiga un
a
calidad satisfactoria aunque se establezcan medidas de control.
El director del proyecto, no obstante, deber tener en cuenta la preparacin de su
equipo, no podr exigir objetivos muy difciles si el equipo con el que trabaja no e
st
suficientemente capacitado. Tambin en gran medida el xito del proyecto depender
de los subcontratistas y colaboradores externos que se seleccionen.
Formacin
El equipo de un proyecto no siempre est formado por personas con experiencia, es
posible que algunos jvenes formen parte de ste, por lo que una de las
responsabilidades del director del proyecto y los ms experimentados es formar a e
stos
jvenes, imponiendo una metodologa eficaz de gestin de proyectos que garantice el
cumplimiento de los objetivos esencial para el xito del proyecto.
Si el ambiente de trabajo no es demasiado profesional, influir negativamente en l
a
formacin de estos jvenes, donde aprendern toda clase de trucos y maas negativas.
Motivacin
La motivacin de los miembros es fundamental para garantizar la calidad del trabaj
o.
Para ello se deber llevar una constante actividad de control y de gestin. En este
control se incluye desde felicitar a un tcnico que ha realizado muy bien su labor
hasta
obligar a repetir un trabajo que se ha efectuado incorrectamente.
La calidad no se consigue mediante discursos y prdicas realizadas muy de vez en
cuando, sino con decisiones concretas, mejorando da a da los procedimientos y
corrigiendo errores, que sirvan de estmulo permanente al trabajo serio y profesio
nal.
Control de los plazos
La gestin del proyecto en cuanto al seguimiento y control de los plazos consiste
en una
buena planificacin previa donde se han especificado las actividades a realizar, l
os
recursos a emplear, los plazos de cada actividad y la situacin en el tiempo de di
chas
actividades. No obstante, siempre se producen desviaciones, pero si la planifica
cin ha
sido realizada con detalle estas desviaciones no supondrn un gran problema y ser
relativamente fcil corregirlas. Lo importante es saber exactamente qu desviaciones
se
estn produciendo en cada momento para actuar en consecuencia para tomar medidas
correctoras que permitan acortar los plazos o recuperar el tiempo perdido, aport
ando
mayores recursos, incrementando la productividad, subcontratando ciertas tareas,

realizando horas suplementarias, etc. As, la planificacin nunca est acabada, sino q
ue
est constantemente realizndose y actualizndose segn los acontecimientos que van
producindose da a da, podramos definirla como planificacin dinmica.
Antes de contar con el apoyo de los ordenadores esta planificacin era muy costosa
o
imposible. stos efectan simulaciones y ajustan los datos de un modelo existente,
cambiando alguna de sus variables independientes. La realizacin de simulaciones o
la
replanificacin a la vista de los datos reales resulta ser una tarea simple y casi

instantnea que podemos efectuar cuantas veces sea necesario.
Una de las causas principales que producen retrasos en los proyectos y que hacen

perder el control sobre su evolucin es la existencia de tareas o actividades de l
arga
duracin o aquellas que no producen resultados visibles hasta su ejecucin. Un ejemp
lo
de proyecto que se puede observar su evolucin y apreciar si lo hace de forma rpida
o
lenta es la construccin de un edificio.
Pero hay otros casos en los que es ms difcil observar esto, por ejemplo, en la
fabricacin de un elemento complejo puede ocurrir que no dispongamos de informacin
sobre si el proveedor que se encarga de realizar este proyecto est avanzando al r
itmo
previsto para finalizar en la fecha establecida o si se estn produciendo retrasos
graves.
Lo mismo ocurre cuando se trata de obras de contenido ms inmaterial como puede se
r
el desarrollo de aplicaciones informticas o la realizacin de estudios de consultora
.
En las tareas de corta duracin y contenido material su evolucin es fcilmente
observable, pero en las actividades de larga duracin o naturaleza inmaterial, la n
ica
solucin es el establecimiento de puntos de control suficientemente cercanos en el

tiempo para garantizar que en todo momento sepamos dnde estamos. Estos hitos de
control hacen la misma funcin que los tradicionales mojones que encontramos en la
s
carreteras y que nos indican nuestra situacin y nuestra distancia desde el origen
o
hasta el destino.
Los hitos de control es una de las ayudas ms importantes para el xito del proyecto
. Se
debern establecer cuantos sean necesarios para tener todas las actividades
controladas y as detectar posibles desviaciones pronto. Un periodo de tiempo
recomendable para efectuar un control eficaz es un mes, a lo sumo dos, pero peri
odos
ms elevados pueden ser peligrosos en el sentido de perder el control sobre la act
ividad.
La identificacin de los hitos de control puede efectuarse dividiendo una activida
d de
larga duracin en varias tareas ms cortas o bien creando actividades especficas de
control, frecuentemente llamadas actividades ficticias, como efectuar una visita
al
proveedor, celebrar una reunin, presentar un informe de avance, realizar una prue
ba
parcial, etc.
El control de los plazos del proyecto se realizar de forma que para cada tarea se

especifiquen las fechas siguientes:
-Fecha early: lo ms pronto que la actividad puede ser realizada.
-Fecha late: lo ms tarde que la actividad puede ser realizada sin alargar el
camino crtico.
-Fecha inicialmente prevista para la realizacin de la tarea.
-Fecha que actualmente est prevista para realizar la tarea, una vez conocidas ya
las fechas reales de las actividades realizadas.
-Fechas en que realmente se ha ejecutado una actividad.
Tambin es importante conocer la diferencia entre el tiempo de trabajo y el plazo
transcurrido. Cuando se planifica un proyecto se tiene en cuenta el nmero de hora
s,
das o semanas y el nmero de unidades de los recursos que vamos a utilizar para
realizar la tarea. Por ejemplo, se supone que para realizar una tarea se necesit
an
1.200horas/hombre y que vamos a disponer de tres personas a pleno tiempo, que
dedicarn 400 horas a la tarea. Si el nmero de horas de trabajo por semana es el
normal, 40 horas, entonces cada persona estar trabajando 10 semanas.
Pero el plazo de realizacin de la tarea no tiene que coincidir con las 10 semanas
, puede
ser muy diferente, bien mayor o bien menor, por diversos motivos: en primer luga
r
puede ser mayor porque en ese plazo puede haber das festivos, vacaciones, ausenci
as
de algunas personas que se encargan de la tarea, etc.; en segundo lugar, en ocas
iones,
el plazo es bastante independiente de las horas de trabajo que exige, por ejempl
o, al
pedir una licencia a una administracin: una vez pedido el permiso es necesario es
perar
el plazo de respuesta sin que ello suponga dedicar horas/hombre a la tarea. En e
l caso
contrario, que el plazo de la tarea sea menor que la suma de horas de dedicacin
necesarias. En el ejemplo expuesto, si se realiza el trabajo con tres personas p
ero con
dos turnos, el plazo total podra reducirse a cinco semanas.
Control de costes
La metodologa a seguir es anloga a la indicada en los casos anteriores: se hace un
a
valoracin econmica de los recursos que se prevea utilizar en cada una de las tareas

que se compara con la informacin real de los costes para realizar acciones correc
toras
si fuese necesario. La dificultad del control de costes es no disponer de una in
formacin
de suficiente calidad sobre los costes reales. Este estudio normalmente se reali
za con
una contabilidad analtica, herramienta temida en muchas empresas por su pesadez,
complejidad y desconfianza de la calidad de su contenido.
En la gestin de un proyecto hay que tener en cuenta el conjunto de conceptos de c
oste
diferentes que existe, normalmente unos pocos conceptos representan el 80 o 90 p
or
100 de los costes totales de acuerdo con la ley del 20/80. Para dominar el 90 po
r 100
del coste total del proyecto tal vez sea suficiente controlar tres o cuatro conc
eptos, que
varan de un proyecto a otro, pero generalmente sern algunos de los siguientes:
-Mano de obra propia.
-Maquinaria propia o ajena.
-Subcontratacin.
-Compras.
Estos costes, que representan la mayor parte del presupuesto del proyecto, son l
os
costes directos. En algunos casos, pueden darse otros conceptos importantes, com
o
amortizaciones, gastos de viaje, etc.
Es muy frecuente creer que el proyecto va muy bien hasta que al finalizar la obr
a, se
comprueba que el resultado econmico ha sido insatisfactorio. Para evitar este tip
o de
problemas se recurre a un sistema de contabilidad analtica que permita conocer pr
onto
y con suficiente exactitud los costes producidos, si es posible a nivel de las t
areas para
llevar un control eficaz de los costes del proyecto. Algunas empresas, al no dis
poner de
un sistema de contabilidad analtica lo suficientemente bueno montan su propio sis
tema
ms simple y barato pero capaz de darles la informacin necesaria.
Costes internos
Estos costes son ms difciles de controlar por no existir una factura normal y un p
ago
al exterior. Normalmente los costes internos ms importantes son los correspondien
tes
a la mano de obra, aunque tambin se puede aplicar a otros recursos como la
maquinaria. Los costes internos suelen incluirse en algunas empresas como gastos

generales y fijos incluidos en la nmina de la compaa e incluso en otras se consider
a
que el coste de estos recursos es cero a efectos del proyecto. Consecuencia de e
llo: no
poder controlar estos costes. Este problema tiene fcil solucin: crear un documento

que permita facturar a los proyectos los tiempos que dedican los diversos tcnicos

empleados, pero en algunos casos no se implanta por temor a su rechazo.
Una buena gestin del proyecto es saber si el coste real de una determinada tarea
ha
sido el que inicialmente se haba previsto y si estamos consumiendo recursos en un
a
cantidad menor, igual o superior a lo planificado. Se debe comprobar si existen
diferencias significativas entre el coste que habamos previsto y el real. Si exis
ten
desviaciones se adoptarn medidas correctoras.
Lo que nos interesa para un buen control de los costes de un proyecto es el segu
imiento
de los costes directamente producidos por el mismo. Estos costes directos no son
slo
los que forman la mayor parte del presupuesto del proyecto, sino que son los que

pueden ser gobernados y gestionados en el mbito del proyecto.
Los costes indirectos, y en particular los gastos generales, no es que no exista
n, pero
como se tratan de gastos fijos y su gestin es ajena al mbito del proyecto no se
pueden imputar al proyecto. Por ejemplo, si un departamento de contabilidad que
tiene
un coste X y que lleva diversos proyectos Para qu sirve repartir X entre los N
proyectos acometidos por la empresa? No sirve para nada, se trata de un coste fi
jo que
no tiene apenas nada que ver con la actividad de los proyectos, si se quisiera i
ncluir en
los gastos del proyecto se debera recurrir a convenios discutibles para repartir
este
coste. No se puede conocer el verdadero del proyecto.
Los mtodos CPM / Pert de programacin del proyecto
Existen diversos mtodos que utilizan como soporte los grafos o redes, de los que
destacan los sistemas CPM y PERT, semejantes en sus aspectos generales. Ambos
utilizan los sucesos o acontecimientos como vrtices o nodos de la red, y los arco
s o
flechas que los unen son las tareas o actividades, orientados en el sentido del
desarrollo
del proyecto. El CPM utiliza, para fijar la duracin de las actividades, tiempos e
stimados
establecidos en funcin de experiencias anteriores y de los resultados de proyecto
s
similares. El PERT, al principio estaba destinado a programar proyectos con part
es
importantes de los mismos en fases de investigacin y desarrollo (I+D), y por lo t
anto,
no se podan basar en estadsticas anteriores disponibles.
Para resolver este problema, en el mtodo PERT se utilizaron conceptos y mtodos de
clculo probabilstico. El resultado de este estudio fue establecer una frmula
aproximada para el clculo del tiempo previsto ms probable de las distintas tareas.
En
el caso concreto de proyectos I+D el tiempo de duracin de las tareas tiene un carc
ter
claramente aleatorio.
4.4. FASE DE PUESTA EN MARCHA
En esta fase cuando se realizan los ensayos para comprobar que el proyecto cumpl
e con
todas sus especificaciones y detectar posibles desajustes. Si la informacin recog
ida no
proporciona la suficiente confianza para aprobarlo se deber estudiar minuciosamen
te
cuales son los errores cometidos, posibles desviaciones respecto de las
especificaciones fijadas para rectificar y llegar a la solucin deseada.
Este tipo de rectificaciones ayuda a las personas encargadas de llevar a cabo el

proyecto a adquirir ms conocimientos y aplicarlos en posibles proyectos futuros.
En sntesis, es la fase de, por ejemplo, arrancar la planta, y observar y corregir
detalles
y problemas que surgen.
4.4.1. Ejecucin del proyecto
La ingeniera bsica, ingeniera de detalle y gestin de compras, tres fases distintas p
ero
consecutivas y con el mismo objetivo final: dar un soporte documental al proyect
o.
La ejecucin del proyecto incluye todas las actividades de ingeniera, gestin de
compras, construccin y montaje y puesta en servicio del proyecto, hasta iniciar s
u
operacin normal.
4.4.1.1. Ingeniera bsica
La ingeniera bsica se pone en prctica una vez se han actualizado los estudios previ
os,
tras los correspondientes estudios sobre el correcto seguimiento del proyecto. S
e puede
definir sta como los documentos que definen inequvocamente el proyecto, su alcance

y su coste. Tambin mencionar que esta ingeniera bsica puede realizarla la propiedad

o una empresa de ingeniera independiente. Debe de haberse definido de la mejor fo
rma
posible para evitar posibles confusiones en el caso que sea llevada a cabo por o
tra
empresa.
En esta fase se debe obtener cierta informacin que ser el punto de partida para la

ingeniera de detalle, que es la siguiente fase. La informacin requerida de la que
se ha
hablado es la implantacin general, clara, y materializada en planos, adems de los
correspondientes planos de cada rea de produccin con todos los elementos que
consumen unos fluidos y producen otros, ofreciendo de forma bien clara su situac
in.
Tambin deben incluirse los datos para el proyecto de las reas de servicios general
es y
auxiliares, es decir, superficies, alturas y la situacin del almacn de piezas de
recambio, de los talleres de mantenimiento y laboratorios. Para el dimensionamie
nto de
los aparcamientos se debe saber el nmero de personas que formar la plantilla.
Se deber conocer la reglamentacin oficial de los locales destinados a reas sociales
,
pero no es suficiente con ello, sino que se deber hacer un minucioso estudio de l
os
turnos de los trabajadores, sexo, poltica social, etc. para adaptarlos a sus cost
umbres y
proporcionarles comodidad.
Es ahora el momento de incidir en los aspectos que se han ido considerando duran
te
todo este captulo, la importancia del clculo del presupuesto y la planificacin efic
iente,
tratando de mantener las fechas programadas o incluso, porqu no? Mejorarlas, si es

posible. Es por ello que se debe actualizar el presupuesto que se consider en los

estudios previos. Antes se permiti un error considerable a la hora de estimar el
presupuesto pero ahora se recalcular y se dar la estimacin definitiva.
Antes de proseguir con la siguiente etapa es necesario la aprobacin de la ingenie
ra
bsica, eso s, una vez estudiados y discutidos todos los detalles, caracterizados p
or
bsicos y casi inamovibles de cara al futuro, y como es normal en estos casos,
reflejarla por escrito, darle un soporte documental.
4.4.1.2. Ingeniera de detalle
La ingeniera de detalle utiliza la informacin recogida en la etapa anterior, ingen
iera
bsica, para proceder a su fabricacin. De ah destacar la importancia de la fase
anterior, porque la exactitud del procedimiento llevado a cabo en ella para esti
mar todos
los factores depender del xito del proyecto. En la ingeniera de detalle los princip
ales
departamentos que intervienen son diversos: de infraestructura, arquitectura y
construccin, estructuras y cimentaciones, mecnica, electricidad, tuberas,
instrumentacin y control. Todos estos departamentos debern trabajar de una forma
coordinada, el resultado del trabajo de unos departamentos es el punto de partid
a para
otros. Si no hay coordinacin entonces empezarn a producirse fallos, con el
consecuente retraso y encarecimiento del proyecto.
Es necesario al final de esta fase tener toda la informacin necesaria para llevar
a cabo
la compra de los equipos y materiales as como la construccin y montaje de las
instalaciones.
Gestin de compras
Despus de haberse facilitado la informacin necesaria puede llevarse a cabo la gest
in
de compras, es decir, para la realizacin del proyecto es necesario abastecerse co
n los
materiales y equipos convenientes que una vez adquiridos sern entregados en el lu
gar
de la obra. De ello se encarga un equipo que recibe el nombre de servicio, aunqu
e
tambin se designa con los nombres departamento o divisin. La gestin de compras
ser ms eficiente cuanto menor sea el coste de estos materiales y equipos, eso s,
siempre cumpliendo la calidad fijada y realizndolas en plazos de tiempo considera
bles.
Construccin y montaje
Ahora suponemos ya que todas las actividades de estudio, organizacin y planificac
in
han sido completadas de forma satisfactoria y que, por tanto, el proyecto est lis
to para
recibir la orden de comienzo y pasar a la fase de construccin y montaje. El desar
rollo
del proyecto a partir de este momento estar en gran medida condicionado a que las

etapas preparatorias se hayan realizado correctamente pues, de lo contrario, pro
nto
empezarn a presentarse problemas de toda ndole: tcnicos, humanos y de gestin. Sin
embargo, si los objetivos del proyecto estn claramente definidos, si se dispone d
e un
director de proyecto idneo y de un equipo adecuado, si se ha realizado una
planificacin coherente, etctera, el proyecto est ya encarrilado por el buen camino
y
las cosas sern notablemente ms fciles.
En esta fase es posible probar los productos y servicios terminados para ver si
se
alcanzan todas las metas de rendimiento. En el caso del desarrollo de un nuevo
producto, es el momento en que suelen comenzar las campaas de venta. Una vez
lanzada la campaa de venta siempre se corre el riesgo de descubrir fallos tcnicos
que
impidan realizar las entregas prometidas.
En la fase de construccin y montaje el proyecto se materializa, se le da forma fsi
ca ya
sea una planta, unas instalaciones, etc. De todas formas con la fase anterior, g
estin de
compras, se inicia lo que se denomina la ejecucin del proyecto. Si se han produci
do
errores en las anteriores fases ahora es cuando surgirn los problemas, porque cor
regir
el proyecto, una vez materializado, supone un elevado coste.
Hay varias alternativas en cuanto se refiere a la realizacin de las obras, pero l
o ms
frecuente es que la obra se deje en manos de un contratista general o varios
contratistas especializados distintos, siempre supervisado por un tercero, norma
lmente
la empresa de ingeniera.
En el caso de un nico contratista las decisiones las suele tomar ste, por lo tanto
la
participacin de la empresa de ingeniera est limitada. Esta alternativa se utiliza
sobretodo en los proyectos de edificacin.
Sin embargo, cuando participan varios contratistas, el papel de la empresa de in
geniera
es muy importante, porque sta es la que se encarga de dirigir y coordinar la
construccin y montaje. El nmero de supervisores depender del volumen de la obra,
aunque suele haber uno por especialidad.
Puesta en servicio
Por ltimo, la puesta en servicio. Para evitar posibles resultados negativos, es
conveniente realizar pruebas con los productos antes de envirselos a los clientes
. Las
compaas de desarrollo de software generalmente piden a algunos clientes que
prueben sus productos, para comprobar el buen funcionamiento de stos antes de que

empiece la campaa de publicidad para el pblico en general.
Una vez materializado el proyecto es hora de ponerlo en funcionamiento, es ahora

cuando empieza la ltima de las fases del proyecto, la puesta en servicio. sta a su
vez
se divide en tres etapas: pruebas, puesta en marcha y puesta en operacin, que sue
len
coincidir a la hora de ejecutarse, se realizan de forma simultnea normalmente.
En esta fase hay una nica persona que dirige y coordina todos los movimientos, el
jefe
de operacin.
4.4.1.3. Ingeniera de desarrollo
Las fases ingeniera de detalle, gestin de compras, construccin y montaje, adems de
la puesta en servicio constituyen la ingeniera de desarrollo, es ahora cuando el
proyecto empieza a materializar, primero a travs de documentos y posteriormente d
e
forma fsica.
La Teora General del Proyecto terminar su cometido cuando las instalaciones queden

en funcionamiento, a pesar de que el proyecto como sistema siga vivo y en desarr
ollo.
Sin embargo, la Teora General del Proyecto no puede reducirse solamente a los
aspectos tcnicos, y tiene que incorporar elementos esenciales para el proyecto
moderno como son los econmicos y de planificacin, y sobre todo los de control de l
os
mismos. La calidad tcnica tambin deber controlarse, estableciendo los programas
adecuados de aseguramiento de la calidad.
La Teora General del Proyecto no va a suministrar las distintas tecnologas especfic
as
que el carcter tcnico del proyecto requiere; esta Teora presupone el conocimiento y

dominio de esas tecnologas por parte de las personas que integran el equipo del
proyecto. Los integrantes del equipo debern utilizar estas tcnicas con la mayor
eficacia y rapidez.
El proyecto es una entidad con vida propia que se va desarrollando en el tiempo
y las
fases que lo constituyen se van sucediendo unas a otras, y con frecuencia mantie
nen
solapamientos importantes.
En el campo industrial hay que distinguir los ciclos de vida del producto y del
proyecto
que lo origina. stos son semejantes pero difieren en algunos aspectos. El del pro
ducto
se extiende mucho ms en el tiempo, y su estudio es importante desde el punto de v
ista
estratgico, ya que la empresa productora debe prever con tiempo suficiente el
momento que el producto dejar de funcionar en el mercado para as retirarlo o
actualizarlo para convertirse en otro producto diferente que lo sustituya.
Figura 4.5: Ciclo de vida de un proyecto.
Los ciclos de vida de los proyectos, con independencia de los sectores a que
pertenezcan, son semejantes, y todos ellos tienen caractersticas comunes.
4.4.2. Alternativas para la ejecucin del proyecto
Existen diferentes alternativas para la ejecucin material del proyecto, qu alternat
iva
elegir? Los objetivos fijados en el proyecto nos ayudarn a elegir esta alternativ
a,
decisin muy importante, porque el xito o fracaso del proyecto dependen en cierto
modo de esta eleccin.
Los protagonistas principales en la ejecucin material del proyecto son tres: la
propiedad, el proyectista y el contratista, que siempre participan, aunque a vec
es su
situacin en el proyecto no sea muy clara y aparezca enmascarada ante un observado
r
no profesional. Las alternativas tradicionales son tres, en funcin de los tres
protagonistas de la ejecucin material del proyecto: utilizar como proyectista al
propio
personal de la propiedad, los servicios de un consultor ya sea persona fsica o ju
rdica o
como tercera opcin una empresa de ingeniera. Estas tres soluciones tienen infinida
d
de variantes e incluso combinaciones entre ellas. A continuacin se enumeran:
4.4.2.1. Alternativa proyectista - profesional de la propiedad
Normalmente se entiende por propiedad, en sentido genrico, la empresa propietaria
de
las futuras instalaciones, que est desarrollando el proyecto y que va a ser su op
eradora
y usuaria. Podr ser:
-Una empresa ya existente lanzada por un grupo promotor.
-Una filial o subsidiaria de una empresa ya existente.
-Ampliacin de una empresa ya existente.
Esta alternativa sigue siendo muy utilizada, principalmente para la ejecucin de
proyectos pequeos o medianos, de tecnologa conocida y desarrollados por empresas
con suficiente experiencia. Si la empresa no dispone de la tecnologa necesaria se
la
suministra otra empresa, normalmente extranjera.
La persona clave de esta alternativa es el proyectista, un ingeniero de la propi
edad, es el
que realiza la transferencia de tecnologa y a veces tambin se encarga de preparar
toda
la documentacin del proyecto. Realiza diferentes acciones, desde redactor del pro
yecto
hasta firmante y responsable del mismo. Esta persona acta en estrecha colaboracin
con el director del proyecto, que puede ser el director tcnico de la empresa, y s
i sta es
pequea el propio director general.
Habitualmente, se contrata a una empresa constructora que, actuando como contrat
ista
general, realiza desde la ingeniera de detalle hasta la puesta en marcha de las
instalaciones.
Pero hay empresas que tienen sus propios departamentos de ingeniera, capaces de
desarrollar totalmente los nuevos proyectos de la empresa, aunque esta forma dir
ecta
de ejecucin del proyecto tiene ms inconvenientes que ventajas:
a.
Ventajas: en las ejecuciones directas de un proyecto por parte de la empresa
las ventajas son mnimas, salvo en casos muy concretos que enumeramos a
continuacin:
-Las empresas que se pueden permitir la ejecucin directa de un proyecto
son suficientemente grandes con una tasa de inversin importante para
mantener un departamento de ingeniera.
-El personal tcnico del departamento de ingeniera puede ser suficiente para
ejecutar el proyecto cuando ste sea sencillo o muy repetitivo. La repeticin
le permite conocer a suministradores y contratistas, y a stos familiarizarse
con un tema que fcilmente pueden repetir.
-En los proyectos donde las mquinas constituyen la mayor parte de la
inversin y se tienen que poner obligatoriamente en contacto con los
suministradores (trenes de laminacin, plantas de embotellado, mquinas de
papel).
b.
Inconvenientes: los inconvenientes son generalmente grandes, y habitualmente
el proyecto termina con un coste mayor:
-El personal tcnico propio, habitualmente de produccin, presta menor
atencin a su cometido principal, producir, y ello provoca una disminucin
de la produccin.
-Salvo en los departamentos de ingeniera propios, los tcnicos de
produccin no son los mejores proyectistas, ya que su experiencia es muy
distinta y les es ms difcil disear soluciones tcnicamente acertadas que a
la vez sean econmicas.
4.4.2.2. Alternativa proyectista-consultor
La propiedad utiliza los servicios de uno o varios tcnicos, proyectistas profesio
nales,
habitualmente en calidad de consultores, que redactan la documentacin tcnica del
proyecto y supervisan tcnicamente la construccin y los montajes. No necesariamente

se tiene que recurrir a consultores independientes, sino tambin a una empresa de
consultora o de ingeniera.
La diferencia entre consultores y empresas de ingeniera es que los primeros son
expertos en uno o varios campos muy concretos y limitados, en cambio los segundo
s
son un grupo de profesionales capaces de abarcar coordinadamente todos los mltipl
es
aspectos tcnicos, econmicos, administrativos y de gestin que un proyecto lleva
consigo.
4.4.2.3. Alternativa proyectista - empresa de ingeniera
La propiedad utiliza como proyectista una empresa de ingeniera, quien no slo redac
ta
la documentacin tcnica del proyecto tanto de la ingeniera bsica como de detalle,
sino que tambin prepara y gestiona la compra de todos los equipos y la contratacin
de
obras civiles y montajes, supervisa estos trabajos durante la construccin y colab
ora
tambin en la puesta en marcha de las instalaciones.
Ventajas e inconvenientes:
-Habitualmente, si se utilizan los servicios de una empresa de ingeniera, a pesar

de su coste, se ve reducido el coste total del proyecto.
-El uso de contratistas individuales supone una reduccin de costes, porque si se
utilizan los servicios de un contratista general, ste contrata a subcontratistas
y
ello puede suponer un incremento de porcentaje del 15% como mnimo en
concepto de gastos generales, administracin y beneficio del contratista general.
-El hecho de utilizar los servicios de diferentes contratistas individuales supo
ne
que cada uno realizar la parte del proyecto de la que sea experto.
-La empresa de ingeniera puede conseguir mejores precios para sus clientes, ya
que conoce el mercado muy bien y tiene buenas relaciones con suministradores.
Ello reduce la inversin en equipos y materiales del proyecto.
4.5. FASE DE CESIN
En esta ltima fase, se da por acabado el proyecto y se produce la transferencia d
e
responsabilidades, de recursos y de tecnologa. Se realiza una reflexin sobre los
conocimientos adquiridos durante la realizacin del proyecto para no volver a come
ter
los mismos errores en futuros proyectos, es decir, un anlisis a posteriori del pr
oyecto,
preguntndose qu se ha hecho bien y qu se ha hecho mal. Si no se realiza esto, es
probable que se repitan los errores del ayer. Lo ideal sera realizar este anlisis
en cada
paso del proyecto. Esta reflexin debe quedar archivada en una base de datos.
En cesin, es una fase que incluye la entrega del resultado del proyecto a quienes
le
usarn, y de una reflexin del trabajo realizado.
4.5.1. Transferencia de la unidad de actuacin (o proyecto) al cliente /
usuario
La labor de recopilacin de la documentacin generada hecha por el equipo gestor, qu
e
debe tambin testar la bondad de la misma tanto en lo que se refiere a la utilidad
en
general, como la precisin y amplitud mnima necesaria. La transferencia de la unida
d
de actuacin al cliente, no debe limitarse, por tanto, a una entrega de la
documentacin. Lo indicado es una entrega personal que lleve incorporada las
explicaciones necesarias para lo usuarios ms prximos a cada uno de los sistemas qu
e
conforman la unidad de actuacin. Por lo general hay tres tipos de entregas:
-
Entregas econmico-financieras.
-
Entregas de relaciones contractuales y oficiales.
-
Entregas tcnicas.
Cada una de ellas suele tener diferentes receptores, aunque se recomienda que la

documentacin generada se prepare en un solo bloque con un ndice conjunto. El
explotador, en todo caso, decide despus si le interesa hacer separatas para archi
var
temas distintos en diferentes departamentos. La experiencia muestra que, por lo
general, todos los documentos se tienen que relacionar entre s, as que es
recomendable que puedan estar todos controlados y contemplados en forma conjunta
.
De hecho, entre los documentos recopilados, de acuerdo a la siguiente figura, ya
se ve
que algunos documentos tcnicos, como puede ser una recepcin provisional,
tambin pueden generar disposiciones econmicas por parte de uno u otro actor, as
que stos debern ser transferidos tambin al responsable econmico-financiero de la
unidad de actuacin.
4.5.1.1. Transferencias internas de la Gestin de proyectos de carcter nico
La evaluacin tiene una finalidad ms amplia que la de sacar consecuencias para el
futuro. Sirve tambin para evaluar tcnicamente al equipo que ha intervenido. Por el
lo
algunos de los aspectos rebasan el espritu de simple transferencia tecnolgica. En
todo
caso, son datos de los que se pueden sacar conclusiones para el siguiente proyec
to a
gestionar. Se realiza a travs de una evaluacin interna y otra externa.

Evaluacin interna del equipo gestor: est hecha por el gestor del proyecto,
ayudado en algn caso, por un auditor, y tiene como misin, determinar si los
servicios desarrollados por la gestin, se han llevado a cabo con las previsiones
realizadas. El receptor de la evaluacin es, en primer lugar, la gerencia de la
organizacin que lleva a cabo la gestin. Pero fundamentalmente est pensada para
producir el aprendizaje del resto de los tcnicos. Por tanto, sus conclusiones son

para ellos.
Desde estas premisas, debern comprobarse:
Si se han cumplido los objetivos internos de la misin del proyecto, evaluando y
buscando la clave en:
-Desviaciones del plazo.
-Desviaciones del costo (interno y externo).
-Desviaciones en la calidad.
-Desviaciones en los honorarios.
-Dedicacin total.
-Errores detectados por el cliente.
-Medios extraordinarios y no previstos, empleados.
-Reclamaciones u opiniones, en general, del cliente sobre el servicio prestado.
-Desviaciones en el procedimiento.
-Fallos durante el encargo.
-Posibilidades de mejora.
-Funcionamiento del equipo.
-Observaciones del gestor o su jefe inmediato.
Si se han cumplido los objetivos externos de la misin del proyecto, buscando
claves en:
-Desviaciones en el plazo.
-Desviaciones en el presupuesto.
-Desviaciones en los medios previstos por los contratistas.
-Desviaciones en la calidad de materiales, equipos, instalaciones o acabados.
-Medios extraordinarios y no previstos, empleados.
-Efectividad de los procedimientos y documentacin utilizados: utilidad o
inutilidad. Mejoras a introducir en el futuro.
-Problemas de seguridad.
-Problemas en la gestin del medio ambiente.
-Problemas y soluciones tcnicas extraordinarias en un proyecto.
-Problemas y soluciones extraordinarias en contratacin.
-Problemas y soluciones tcnicas extraordinarias en corporificacin.
-Errores no detectados por la gestin.
-Fallos en la coordinacin de todos los actores.
-Problemas en la obtencin de permisos oficiales.
-Costos de acometidas de servicios, administraciones pblicas y otros ajenos a la
unidad de actuacin.
-Observaciones del gestor.
Se levantar un acta de la evaluacin que quedar archivada en el apartado de
calidad, si es que hay un sistema homologado, o simplemente en la documentacin
del encargo.

Evaluacin externa del equipo gestor: tiene como objeto determinar el grado de
adecuacin de servicio desarrollado por la gestin de proyectos a las necesidades
del cliente, y por su conducto llegan a conocer aspectos impensables de la gestin

que podran pasar desapercibidos en el caso que no se hiciera.
La lleva a cabo una persona ajena al desarrollo del encargo a propuesta del gest
or,
en funcin de la disponibilidad y el nivel de cercana a la persona del cliente
mediante un cambio de impresiones (reunin, conversacin, etc.) con el cliente en
cuestin para conocer su opinin y comentarios sobre:
-
Grado de satisfaccin del cliente.
-
Cumplimiento de plazos.
-
Cumplimiento de costos.
-
Capacidad de respuesta transmitida (relacin gil?).
-
Capacidad de coordinacin.
-
Capacidad de motivacin.
-
Adecuacin al trabajo realizado al contrato.
A cada una de estas preguntas, la respuesta del cliente ha de ser fcil, por lo qu
e se
aconseja que se amolde, de ms positivo a menos, al esquema de: MB (muy bien), B
(bien), R (regular), M (mal o malo) o MM (muy mal o malo). El receptor de la eva
luacin
es el gerente de la organizacin que lleva a cabo la gestin.
5. GESTIN DE PROYECTOS
5.1. INTRODUCCIN
Gestin de Proyectos es una dimensin dentro de un proyecto y no es en s el proyecto.

Esto muestra, por una parte, la dependencia de la gestin de proyecto al tipo de
proyecto dentro del cual participa y, por otra parte, la existencia de una serie
de
limitaciones debidas a la existencia y oportunidad de determinados recursos,
imposiciones y condiciones del medio, y compromisos y restricciones organizacion
ales.
Todo en su conjunto produce un paquete de documentacin, el cual contiene y reflej
a la
historia del proyecto en todas las reas en que se haya desenvuelto, y la evolucin
del
resultado finalmente obtenido con la metodologa de e-business.
En particular, la gestin de proyectos se enfoca en buscar un marco estructurado p
ara la
gestin exitosa, buscando aportar un completo conjunto de herramientas y tcnicas.
Motivo por el cual este captulo parte revisando la nocin de gestin de proyectos segn

los diversos tipos de proyectos para introducirse luego en mostrar la gua PMBOK,
documento estndar internacional sobre el tema.
Por ltimo, se revisan una serie de modelos de madurez de gestin de proyectos, los
cuales permiten tener un marco de referencia que ayuda a superar la falta de hab
ilidades
y competencia y adems un medio de ir mejorando la calidad en gestin de proyectos.
5.2. GESTIN DE PROYECTOS
Gestin de Proyectos es una dimensin dentro de un proyecto y no es en s el proyecto.

Por ello es conveniente revisar de qu manera el proyecto englobador cambia la vis
in a
tener respecto de cmo usar la gestin de proyectos.
La gestin de proyectos intenta conseguir una planificacin coherente con los objeti
vos
de una organizacin y del propio proyecto, igualmente que el desarrollo del proyec
to se
acerque a lo planificado y supere las vicisitudes del medio y del da a da. Como un
a
manera de proveer un lenguaje universal y comn entre los profesionales de proyect
os,
el Project Management Institute ha desarrollado el PMBOK, un documento con el cu
al se
espera que la prctica de gestin de proyectos se convierta en un cuerpo doctrinal y

referencial para los profesionales del rea. Por esta razn se presenta la gestin de
proyectos desde el punto de vista del PMBOK.
5.2.1. Nocin de gestin de proyectos
El concepto de proyectos difiere segn diversas visiones, adems que un proyecto es
un sistema dentro del cual coexisten dos dimensiones, la de gestin y la de
construccin. Segn esto, la gestin de proyectos es un sistema que debe construirse y

ser adaptado al punto de vista de proyecto que se maneje.

Proyecto como produccin de artefactos. Aqu por gestin se entiende la
programacin de actividades y ver que se cumplan.

Proyecto como consecucin de objetivos. Aqu el proyecto es un conjunto de
actividades concretas para un determinado resultado, y la gestin intenta que tale
s
actividades cumplan con las necesidades presupuestas de antemano, siendo en
esencia una anticipacin a un objetivo o a un estado de realidades predefinidas.

Proyecto de accin. Aqu el proyecto persigue finalidades, sin necesidad de seguir
un plan de trabajo. El proyecto es actuar siguiendo finalidades o fines y la ges
tin
es poder anticiparse a las transformaciones o cambios de estado del proyecto y d
el
entorno que se producen conforme la finalidad se va alcanzando o alejando.
Para ilustrar las diferencias entre el tipo de gestin de proyectos que uno u otro
tipo de
proyecto requiera, se puede decir lo siguiente:
-En los primeros dos casos, el gestor de proyectos parte de que conoce qu
conseguir y para ello busca y se nutre de varios cmos, cundos, quines y
cuntos; y,
-En el ltimo caso, el gestor de proyectos debe ayudar a buscar el qu se desea,
para lo cual dispone de varios cmos que le ayudan a conseguir el qu.
Sin embargo, aceptando cierto grado de formalizacin respecto de la gestin de
proyectos asociada al proyecto como productor de artefactos, debido a que es ms
sencillo controlar y regular recursos respecto cuando hay una meta clara, que cu
ando
ella no existe (en este caso la meta es conseguir una meta), Kerzner sugiere que
gestin
de proyectos es la planificacin, organizacin, direccin y control de los recursos de
una empresa para un objetivo de relativo corto plazo que ha sido establecido par
a
completar y conseguir metas y objetivos especficos.
Siguiendo con esta primera acepcin, Kirsch seala que gestin de proyectos es la
aplicacin de tcnicas, mtodos, herramientas y heursticas formales e informales, las
cuales emplea un gestor de proyectos en la motivacin y gua de un equipo de persona
s
para llevar un proyecto dentro de un conjunto dado de restricciones.
Visto as, la gestin de proyectos pone a disposicin de los gestores de proyectos un
conjunto de instrumentos de trabajo que le permiten asumir un proyecto y superar
sus
vicisitudes tal que: se anticipe a los problemas, mejore el hacer futuro, y acte
de forma
adecuada ante eventos no presupuestados.
En todo caso, debe tenerse claro que la gestin de proyectos es un medio a disposi
cin
del gestor para construir una solucin dentro de las mejores condiciones para quie
nes
estn dentro del proyecto y para quienes se beneficiarn del uso del producto o serv
icio
resultante. Por este motivo, el gestor de proyectos es una persona cuyo fin es h
acer uso
armonioso de una serie de recursos intelectuales (conocimiento, creatividad) y
corpreos (trabajo fsico, esfuerzo mental), con especial cuidado y atencin a las
personas. Es una labor donde especialistas actan con libertad como parte de un to
do
(figura 5.1).
Figura 5.1: El fin de la gestin del proyecto.
Generalizando un poco, la gestin de proyectos se debe entender como un cmulo de
informacin sobre instrumentos y prcticas que se pone a disposicin de personas para
hacer un uso ptimo y robusto de recursos bajo su responsabilidad frente a restric
ciones
y contingencias para el cumplimiento de metas trazadas de antemano. Todo lo ante
rior
relacionado con tres parmetros clsicos de gestin: tiempo, coste y desempeo, para
mejorar la calidad y conseguir un riesgo cero.
No obstante, el valor agregado de esta informacin depender de la utilidad que le
otorgue el gestor del proyecto: conseguir lo que se le pide, resolver un conflic
to,
aprender del hacer haciendo y, salir airoso de las vicisitudes diarias. Esto dep
ender de
la habilidad que adquiera, tanto por capacidad personal como resultado de un pro
ceso
de formacional.
5.2.2. La gestin de proyectos segn el PMBOK
La forma de organizar los esfuerzos y experiencia de gestin de proyectos se han
llevado adelante mediante el arte de las personas en el rol de gestor de un proy
ecto o
varios (programa). Organizar todo aquello en un cuerpo doctrinal formal se ha vi
sto
dificultado por dos razones:
No se ha manifestado un cuerpo o ncleo central al cual ceirse los gestores para
recabar experiencias y tener un dominio comn de discusin.
La
gestin de proyectos es cultural, pues depende de las caractersticas y
singularidades del grupo de personas que constituye y se relaciona con el proyec
to.
Estas razones han hecho que hoy en da existan diversas asociaciones dedicadas al
estudio de proyectos tales como:
AEIPRO. Asociacin Espaola de Ingeniera de Proyectos.
AFITEP. Association Francophone de Management de Project.
IPMA. International Project Management Association.
PMI. Project Management Institute.
SMP. Socit suisse de Management de Project.
Project Management Institute. El Project Management Institute (PMI) es una
organizacin internacional orientada a la difusin y determinacin de las mejores
prcticas de gestin de proyectos. En este afn, produce documentos que describen
prcticas generalmente aceptadas de gestin de proyectos.
PMBOK. El ms importante de los documentos publicados en la actualidad por el PMI
es
el PMBOK, A Guide to the Project Management Body of Knowledge.
El propsito de esta gua es describir el conocimiento y las prcticas usadas en vario
s
tipos de proyectos. Durante veinte aos se han estado revisando y discutiendo cules

son los proyectos cuyo conocimiento y estudio aporta valor y utilidad a la prctic
a de
proyectos. Este esfuerzo se ha traducido en identificar prcticas de gestin de
proyectos aplicables a cualquier proyecto. La importancia del PMBOK, por sobre t
oda
compilacin y mejora de prcticas, es que provee una base formal para fundar
proyectos, guiando y orientando a gestores de proyectos sobre la forma de llevar

adelante la construccin de resultados. Para ello, no obstante, es menester adapta
r los
contenidos del PMBOK al dominio tcnico de cada proyecto en particular.
La utilidad del PMBOK se refleja en ser actualmente el estndar ANSI/PMI 99-001200
01
(PMI, 2000) y por cumplir, segn Welch, con gran detalle el estndar ISO 10006
de gestin de proyectos. Adems, por su propia concepcin, homogeneiza el
conocimiento sobre la profesin de gestin de proyectos, siendo considerado pilar o
base de sistemas internacionales de certificacin para Directores de Proyecto
promovidos por el PMI y el IPMA, ambos en asociacin con muchas otras asociaciones

de Proyectos locales.
Gestin de proyectos segn el PMBOK. Segn el PMBOK, gestin de proyectos es la
aplicacin de conocimiento, herramientas y tcnicas a actividades de un proyecto en
orden a satisfacer los requerimientos del proyecto, Todo este conocimiento, habi
lidades,
herramientas y tcnicas se distribuyen y usan a lo largo de varios procesos de ges
tin
de proyectos.
Cada proceso de Gestin de Proyectos pertenece a un rea de Conocimiento de Gestin
de Procesos y se asocia a un Grupo de Procesos de Gestin (figura 5.2).
Figura 5.2: Componentes del PMBOK y sus relaciones.
5.2.2.1. reas de conocimiento de gestin de proyectos
Las nueve reas de conocimiento, Project Management Knowledge Areas, se describen
en la tabla 5.1.
1. Fuente: Project Managemet Institute. Enlace web: http://www.pmi.org/info/defa
ult.asp
[Ledo: 26 de mayo del 2006].
REAS DE CONOCIMIENTO DESCRIPCIN
#4. Gestin de la Integracin
Incluye los procesos requeridos para asegurar que todos los elementos del proyec
to son
coordinados adecuadamente.
#5. Gestin del Alcance
Incluye los procesos requeridos para asegurar que el proyecto incluye y consider
a
solamente el trabajo requeridos para completar el proyecto satisfactoriamente.
#6. Gestin del Tiempo
Incluye los procesos requeridos para asegurar el trmino temporal preciso y adecua
do
del proyecto.
#7. Gestin del Coste
Incluye los procesos requeridos para asegurar que el proyecto se concluye dentro
del
presupuesto aprobado.
#8. Gestin de la Calidad
Incluye los procesos requeridos para asegurar que el proyecto satisface la neces
idades
para las cuales fue definido.
#9. Gestin de Recursos Humanos
Incluye los procesos requeridos para hacer un uso ms efectivo de las personas
involucradas en el proyecto.
#10. Gestin de las Comunicaciones
Incluye los procesos requeridos para asegurar una generacin, recoleccin,
diseminacin, almacenamiento y disposicin final en tiempo y de forma apropiada, de
la
informacin del proyecto.
#11. Gestin del Riesgo Es el proceso sistemtico de identificar, analizar y respond
er a los riesgos del proyecto.
#12. Gestin del Abastecimiento
Incluye los procesos requeridos para adquirir los bienes y servicios que el proy
ecto
requiere para su funcionamiento desde fuera de su desempeo y funcionamiento.
Tabla 5.1. reas de conocimiento de gestin de proyectos.
a. Gestin de la Integracin
La gestin de integracin del proyecto incluye los procesos requeridos para asegurar

que los diferentes elementos del proyecto son coordinados adecuadamente. Se ocup
a
de encontrar el equilibrio entre los objetivos posibles y sus alternativas, con
el fin de
satisfacer o colmar las necesidades y expectativas de las entidades involucradas
en el
proyecto. Mientras que todos los procesos de direccin de proyectos son de alguna
forma integradores, los de esta rea lo son de manera fundamental. La Gestin de la
Integracin del proyecto se utiliza cuando se necesita estimar un coste para un pl
an de
imprevistos o cuando se deben identificar los riesgos asociados con diferentes
alternativas de personal. Sin embargo, para que un proyecto sea completado con xi
to,
tambin debe producirse la integracin de otras muchas reas. Por ejemplo:
El trabajo del proyecto debe ser integrado con las operaciones en curso de la
organizacin ejecutora, la metodologa e-business, por ejemplo.
Deben integrarse el alcance del producto y del proyecto (rea 5).
Deben integrarse los resultados de las distintas especialidades funcionales (com
o
pueden ser las especificaciones de la arquitectura e-business o los planos
elctricos, mecnicos y civiles en un proyecto de ingeniera).
b. Gestin del Alcance
La Gestin del Alcance del proyecto comprende los procesos requeridos para asegura
r
que el proyecto contiene todo el trabajo necesario y solamente el trabajo necesa
rio, para
completar el proyecto con xito.
Esta rea est relacionada principalmente con la definicin y control de lo que est o n
o
est incluido en el proyecto.
En el contexto del proyecto, la palabra alcance puede referirse a lo siguiente:
Alcance del producto: Son las caractersticas y funciones que deben incluirse en l
a
iniciativa o solucin e-business.
Alcance del proyecto: Es el trabajo que debe llevarse a cabo para entregar una
aplicacin e-business con las caractersticas y funciones especificadas.
La integracin debe considerar los siguiente:
Los procesos,
herramientas y tcnicas empleados para dirigir el alcance del
producto son diferentes segn sea el rea de aplicacin y normalmente son
definidos como parte del ciclo de vida del proyecto, el cual puede ser la
metodologa e-business y/o el modelo de desarrollo en un proyecto informtico.
Lo que debe tenerse cuidado, es que un proyecto consta de un nico producto,
pero este producto puede tener elementos auxiliares, cada uno de ellos con su
propio alcance del producto, separado pero interdependiente. Por ejemplo, un
nuevo sistema telefnico generalmente incluir cuatro elementos auxiliares:
hardware, software, formacin e instalacin. En el caso de una iniciativa e-
business, cuya solucin es una aplicacin e-business, ella constar de una serie de
hardware, software y procedimientos de trabajo vinculados a la manutencin de la
arquitectura e-business y de un conjunto de aplicaciones de software especficas y

procedimientos de operacin ligados que permiten la operacin de la aplicacin e-
business.
La comprobacin de que se ha completado el alcance del producto se realiza segn
los requerimientos del mismo, mientras que el alcance del proyecto se realiza se
gn
el plan del proyecto. Estos dos tipos de gestin del alcance deben estar
perfectamente integrados para asegurar que los trabajos del proyecto darn como
resultado el producto especificado.
c. Gestin del Tiempo
La Gestin del Tiempo incluye los procesos necesarios para asegurar la conclusin de
l
proyecto en los tiempos establecidos. En algunos proyectos, especialmente en los
mas
pequeos, la secuencia de actividades, la estimacin de la duracin de las actividades
y
el desarrollo del programa estn tan ntimamente ligados que se consideran como un
nico proceso (por ejemplo, pueden desarrollarse por una sola persona en un perodo
de
tiempo relativamente corto). No obstante el PMBOK presenta estos procesos separa
dos
y distintos porque las herramientas y tcnicas para cada uno son diferentes. Respe
cto
de esta rea, la nica consideracin es que no existe consenso entre los profesionales

de la gestin de proyectos sobre la relacin entre actividades y tareas, pues:
En muchas reas de aplicacin, se considera a las actividades compuestas por
tareas. Esto es lo ms normal y lo ms utilizado.
En otras reas, se considera a las tareas compuestas por actividades.
Sin embargo, la consideracin ms importante no es el termino que se utilice, sino s
i el
trabajo a realizar es descrito de forma precisa y si es comprendido por las pers
onas que
deben realizarlo, distinguiendo claramente cuando algo se compone de otra cosa.
Esta
consideracin es muy importante en un proyecto e-business, donde el trabajo
interdisciplinario de diversos profesionales, informticos, economistas, administr
adores
de empresa, electrnicos, etc., pueden manejar distintas acepciones de lo mismo. E
n
este caso, lo prioritario es fijar el glosario de trminos oficiales del proyecto.

d. Gestin del Coste
La Gestin de Coste del proyecto incluye los procesos necesarios para asegurar que
el
proyecto se finaliza dentro del presupuesto aprobado. La Gestin de Costes del
proyecto est relacionada con el coste de los recursos necesarios para completar l
as
actividades del proyecto. Sin embargo, la gestin de costes del proyecto debera
considerar tambin el efecto que tiene la toma de decisiones del proyecto sobre lo
s
costes de utilizar el producto del proyecto. Por ejemplo, la limitacin del nmero d
e
revisiones del diseo puede reducir los costes del proyecto, a expensas de un aume
nto
en los costes operativos del cliente. Esta visin ms global de la gestin de costes d
el
proyecto se suele llamar coste del ciclo de vida. Este tema es especialmente rel
evante,
por ejemplo, en un proyecto e-business, pues, por una parte, la iniciativa e-bus
iness es
un cambio cultural respecto de cmo enfrentar la gestin de un negocio y en cmo
plantearse una organizacin de fronteras virtuales y, por otra parte, la aplicacin
e-
business final es en s misma la incorporacin a una organizacin de un tipo de
tecnologa en muchas ocasiones nueva, adems, de hardware y software cuya gestin
requiere tratamiento especial y de gran cuidado, con los costes que ello signifi
ca.
Estos costes involucran, por ejemplo, conseguir profesionales adecuados para con
struir
la aplicacin e-business y profesionales que luego puedan responder a las continge
ncias
de la operacin de la aplicacin e-business. Como parte de la Gestin del Coste:
En muchas reas de aplicacin, la prediccin y anlisis del futuro rendimiento
financiero del producto del proyecto se realiza fuera del proyecto. Cuando se
incluyen estas predicciones y anlisis, la Gestin de Costes incluir procesos
adicionales y numerosas tcnicas de direccin general como la tasa interna de
retorno (TIR), el valor actual neto (VAN), perodo de recuperacin del capital y
otros.
Esta gestin debera de considerar las necesidades de informacin de las entidades
involucradas en el proyecto: diferentes entidades pueden medir los costes del
proyecto de diferentes maneras y en distintos momentos. Por ejemplo, el coste de

un artculo de un proveedor puede ser medido cuando se ha autorizado su compra,
cuando se ha pedido, cuando se ha pagado o cuando se ha contabilizado.
Cuando los costes del proyecto se utilizan como un componente de un sistema de
recompensa y reconocimiento, deberan estimarse y presupuestarse separadamente
los costes controlables y los incontrolables, para asegurar que las recompensas
reflejan el desarrollo real del proyecto.
En algunos proyectos, especialmente en los mas pequeos, la planificacin de
recursos, la estimacin de costes y el presupuesto de costes estn tan ntimamente
ligadas que se ven como un solo proceso (por ejemplo, puede desarrollarlas una
sola persona en un perodo de tiempo relativamente corto). No obstante el PMBOK
presenta estos procesos separados y distintos porque las herramientas y tcnicas
para cada uno son diferentes.
e. Gestin de la Calidad
La Gestin de la Calidad del proyecto incluye los procesos necesarios para asegura
r que
el proyecto satisfar las necesidades para las que se ha llevado a cabo. Con esto
se
incluyen todas las actividades de la direccin que determinan la poltica de la cali
dad,
objetivos y responsabilidades, as como su desarrollo por medios tales como
planificacin de la calidad, control de la calidad, aseguramiento de la calidad y
mejora de
la calidad, dentro del sistema de la calidad.
El mtodo bsico de gestin de calidad a seguir debe ser compatible con el que la
Organizacin Internacional de Normalizacin (ISO) ha detallado en las series de norm
as
ISO 9000 y 10000. Este mtodo generalizado tambin debera ser compatible con
mtodos de gestin de la calidad vinculados a Deming, Juran, Crosby y otros, y otros

como la gestin de la Calidad Total (TQM) o la mejora continua.
La calidad es el conjunto de caractersticas de una entidad que constituyen su
capacidad para satisfacer necesidades implcitas o evidentes.
La Gestin de la Calidad debe dirigirse tanto a la direccin del proyecto como al
producto del proyecto. Un fallo en el cumplimiento de las exigencias de la calid
ad en
alguna dimensin puede tener consecuencias negativas serias para alguna o todas la
s
entidades involucradas en el proyecto. Por ejemplo:
Cumplir los requerimientos del cliente mediante un trabajo excesivo del equipo d
el
proyecto puede producir consecuencias negativas como un incremento en la
rotacin de personal.
Cumplir los objetivos de programacin del proyecto, acelerando las revisiones de l
a
calidad planificadas, puede producir consecuencias negativas cuando existan
errores que no sean detectados.
Un aspecto crtico de la Gestin de la Calidad en el contexto del proyecto es la
necesidad de convertir las necesidades implcitas en necesidades evidentes a travs
de
la Gestin del Alcance del proyecto.
El equipo de direccin del proyecto debe tener cuidado de no confundir calidad con

grado. Grado es una categora o rango dado a entidades que, teniendo el mismo uso
funcional, tienen diferentes requerimientos de calidad. La baja calidad es siemp
re un
problema; el bajo grado puede no serlo. Por ejemplo, un producto de software pue
de ser
de alta calidad (sin errores, manual fcilmente legible) y bajo grado (pequeo nmero
de
aplicaciones), o de baja calidad (muchos errores, documentacin del usuario mal
organizada) y alto grado (numerosas aplicaciones).
Determinar y conseguir los niveles adecuados de calidad y grado son las
responsabilidades del gestor del proyecto y del equipo de direccin del proyecto.
El equipo de direccin del proyecto debe saber tambin que la gestin de la calidad
moderna complementa a la direccin de proyectos moderna. Por ejemplo, ambas
disciplinas reconocen la importancia de:
La satisfaccin del cliente: tratar de cumplir o exceder las expectativas del clie
nte.
Esto requiere tanto la conformidad con las especificaciones (el proyecto debe
producir lo que se dijo iba a producir), como la adecuacin para su uso (el produc
to
o servicio producido debe satisfacer las necesidades reales).
La prevencin sobre la inspeccin: el coste de evitar los errores siempre es mucho
menor que el de corregirlos.
Responsabilidad de la gestin: el xito requiere la participacin de todos los
miembros del equipo, pero permanece la responsabilidad de la direccin de
suministrar los recursos necesarios para lograrlo.
Procesos dentro de fases del ciclo reiterativo planificar-ejecutar-comprobar-act
uar.
Adems, las iniciativas de mejora de la calidad llevadas a cabo por la organizacin
ejecutora (por ejemplo, la gestin de la calidad total, TQM), la mejora continua,
y otros)
pueden y deben mejorar la calidad de la direccin del proyecto, as como la calidad
del
producto del proyecto.
Sin embargo, hay una diferencia importante sobre la que el equipo de direccin del

proyecto debe estar muy precavido: la naturaleza temporal de los proyectos impli
ca que
las inversiones en mejora de la calidad del producto, especialmente la prevencin
de
defectos y las pruebas, deben frecuentemente soportarse por parte de la organiza
cin
ejecutora dado que el proyecto puede no durar lo suficiente para recoger la reco
mpensa.
f. Gestin de Recursos Humanos
La Gestin de Recursos Humanos del proyecto incluye los procesos necesarios para
aprovechar ms efectivamente al personal relacionado con el proyecto, incluyendo a

todas las entidades involucradas en el proyecto (patrocinadores, clientes,
contribuyentes individuales y otros). Hay gran cantidad de literatura sobre las
relaciones
interpersonales en un contexto operativo continuo. Algunas de las muchas ideas
extendidas son:
Liderazgo, comunicacin, negociacin y otras ms aptitudes clave en la direccin
general.
Delegacin, motivacin, enseanza, apadrinamiento y otros temas relacionados con
el trato personal.
Creacin de equipos, resolucin de conflictos y otros temas relacionados con el
trato en grupo.
Anlisis del grado de preparacin., reclutamiento, retencin, relaciones laborales,
seguridad e higiene en el trabajo y otras elementos relacionados con la funcin de

administracin de recursos humanos.
La mayor parte de este material es aplicable al liderazgo y a la direccin de pers
onas en
proyectos y el gestor del proyecto y el equipo de direccin del proyecto deben est
ar
familiarizados con estos conceptos.
Sin embargo, deben ser tambin sensibles a la aplicacin de estos conceptos en el
proyecto. Por ejemplo:
La naturaleza temporal de los proyectos supone que las relaciones personales y d
e
la organizacin sern, generalmente, temporales y nuevas. El equipo de direccin
del proyecto debe tener cuidado a la hora de seleccionar tcnicas que sean
apropiadas para estas relaciones temporales.
La naturaleza y el nmero de entidades involucradas en el proyecto cambiarn a
menudo segn el proyecto va pasando por las distintas fases de su cielo de vida.
Como consecuencia de esto, tcnicas que son aptas en una fase determinada,
pueden no ser efectivas en otra fase. El equipo de direccin del proyecto debe
prestar especial atencin en utilizar las tcnicas apropiadas a las necesidades
actuales del proyecto.
Las actividades administrativas de los recursos humanos son rara
vez una
responsabilidad directa del equipo de direccin del proyecto. Sin embargo, el
equipo debe conocer suficientemente los requerimientos administrativos para
asegurar su cumplimiento.
g. Gestin de las Comunicaciones
La Gestin de Comunicaciones del proyecto comprende los procesos necesarios para,
en el momento y manera adecuados, asegurar la elaboracin, recopilacin, distribucin,

archivo y disposicin definitiva de la informacin del proyecto. Proporciona las
conexiones clave entre personas, ideas e informacin, que son necesarias para el xi
to
del proyecto. Esto se hace para que cualquier persona implicada en el proyecto d
ebe
estar preparada para enviar y recibir comunicaciones en el lenguaje del proyecto
, y debe
comprender que las comunicaciones que se realizan entre personas afectan al proy
ecto
en su conjunto.
La aptitud de la direccin general para la comunicacin est relacionada, pero no es l
o
mismo, que la Gestin de Comunicaciones del proyecto. Comunicacin es un trmino
general y comprende una gran cantidad de aspectos que no se circunscriben solame
nte
al contexto del proyecto. Por ejemplo:
Modelos
emisor-receptor (lazos de realimentacin, obstculos a las
comunicaciones, etc.).
Eleccin del medio (cundo comunicar por escrito y cundo hacerlo verbalmente,
cundo escribir un memorando informal y cuando hacer un informe formal, etc.).
Estilo de escritura (voz activa frente a voz pasiva, estructura de las oraciones
,
eleccin de vocabulario, etc.).
Tcnicas de presentacin (lenguaje del cuerpo, diseo de ayudas visuales, etc.).
Tcnicas de direccin de reuniones (preparacin de una agenda, tratamiento de
conflictos, etc.).
Esta rea es de importancia ya que muchos proyectos fallan por problemas de
comunicacin. Por esta razn, es responsabilidad del gestor de proyectos crear un
ambiente dentro del proyecto propicio para una efectiva comunicacin intra e inter
grupal
que permita que todas las partes estn informadas de manera fluida. Lo
importante es no dar sorpresas, menos al cliente. Por esto, las comunicaciones n
o
deben depender de informes aislados, sino que es bueno aprovechar las reuniones
para
comunicar. No hay que olvidar que una buena frase puede ser mejor que un cuidado

informe de estado.
h. Gestin del Riesgo
La gestin de riesgos del proyecto incluye los procesos relacionados con la
identificacin, anlisis y respuesta a los riesgos del proyecto. Incluye maximizar l
os
efectos positivos de los distintos eventos y minimizar las consecuencias de sus
efectos
negativos. Las diferentes reas de aplicacin utilizan, con frecuencia, diferentes
nombres para los procesos aqu descritos. Por ejemplo:
La identificacin y cuantificacin de riesgos se tratan, en algunas ocasiones, como
un solo proceso y el proceso combinado puede llamarse anlisis o evaluacin de
riesgos.
Al desarrollo de respuestas a riesgos se le denomina algunas veces Planificacin d
e
respuestas o mitigacin de riesgos.
El desarrollo y el control de las respuestas ante el riesgo se tratan algunas ve
ces
como un solo proceso, pudiendo ser denominarse dicho proceso combinado gestin
de riesgos.
Esta rea, en muchos casos definida como funcin, es una de las ms importantes hoy
en da debido al entorno cambiante en que se desenvuelven los proyectos e-business
en
particular, y cualquier proyecto en general. Durante la fase de planificacin, el
gestor de
proyecto necesita realizar una valoracin realista de riesgos y desarrollar un pla
n para
controlarles. Para ello debe considerar como factores de riesgo:
-El tamao del proyecto;
-La estructura del proyecto; y,
-La experiencia con la tecnologa.
Debe tenerse presente que los riesgos de un proyecto aumentan conforme crece, es

poco estructurado (es decir, los requerimientos no se definen bien y probablemen
te
cambien durante el proyecto) y hay menos experiencia del equipo en la tecnologa a

usar. En estos casos adoptar un enfoque de contingencia es una estrategia adecua
da de
gestin de los diversos tipos de riesgo, para las cuales existen diversos tipos de

herramientas de integracin externa, interna y de control y planificacin (figura 5.
3).
Figura 5.3: Enfoque de contingencia de Gestin de Riesgo.
Proyectos con una estructura pequea se pueden beneficiar de herramientas de
integracin externa para crear relaciones efectivas entre el equipo del proyecto y

los clientes de la organizacin. Por ejemplo:
-Seleccionar al gestor del proyecto y a los miembros del equipo del proyecto
desde la misma organizacin que recibir el producto;
-Mantener una representacin de clientes en todas, o casi todas, las reuniones de
revisin del proyecto; y/o,
-Mantener una amplia difusin y distribucin de los informes de estado del
proyecto dentro de la organizacin.
Proyectos que
involucran el uso de nueva tecnologa deberan confiar ms en
herramientas de integracin interna, las cuales han sido diseadas para mejorar la
competencia y operacin tcnica del equipo como una unidad integrada. Por
ejemplo:
-
Seleccionar o disponer de miembros experimentados;
-Contar con un gestor del proyecto con gran dominio tcnico y experiencia
probada en gestin de proyectos;
-
Mantener frecuentes reuniones de estado del proyecto con los miembros.
Grandes proyectos,
con una gran estructura deberan ser gestionados con
profusin de herramientas de gestin y de control. Estas herramientas, representan
un esfuerzo sistemtico y disciplinado de planificacin y control. Por ejemplo, WBS,

presupuestos, planes y procedimientos de seguimiento.
Mientras la eleccin de un enfoque adecuado para gestionar el proyecto es de gran
importancia, es importante una valoracin de los riesgos, lo cual incluye:
-El propsito de la identificacin de riesgos es desarrollar una lista de los riesgo
s
que pueden afectar el proyecto y su producto.
-El anlisis de riesgos consiste de valorizar la exposicin al riesgo, la probabilid
ad
e impacto de cada uno de ellos.
-La priorizacin de los riesgos produce una lista de riesgos priorizados segn el
impacto que un riesgo tiene en el proyecto y el producto.
Con esto se puede planificar segn los riesgos de mayor impacto e incidencia,
planteando planes de contingencia para hacerles frente y monitorearles. Es impor
tante
que los riesgos sean valorizados continuamente cuando se monitorean para mantene
r
actualizada una lista de, por ejemplo, los 10 riesgos de mayor prioridad e incid
encia.
i. Gestin del Abastecimiento
La Gestin del Abastecimiento del proyecto incluye los procesos requeridos para la

adquisicin de bienes y servicios, producto en general, en el exterior de la organ
izacin
ejecutora. Esta gestin requiere una perspectiva de comprador como parte de una
relacin comprador-proveedor. Esta relacin se puede dar a muchos niveles en un
mismo proyecto. Dependiendo del rea de aplicacin, al proveedor se le puede llamar
contratista, vendedor o suministrador. El proveedor dirigir normalmente su trabaj
o
como un proyecto. En tales casos:
El comprador se convierte en
cliente y es as, una entidad involucrada en el
proyecto clave para el proveedor.
El equipo de direccin de proyectos del proveedor debe estar interesado en todos
los procesos de direccin de proyectos, no slo en aquellos de este rea de
conocimiento.
Los trminos y condiciones del contrato se convierten
en un dato clave para
muchos de los procesos del proveedor. El contrato puede contener realmente los
datos (por ejemplo, entregas principales, hitos clave, objetivos de coste) o pue
de
limitar las opciones del equipo del proyecto (por ejemplo, en los proyectos de
diseo se requiere frecuentemente la aprobacin del comprador de las decisiones
de asignacin de personal).
5.2.2.2. Grupos de procesos de gestin
Los grupos de procesos de gestin, Management Processes Groups, son agrupaciones
de procesos de gestin de proyectos relacionados con las cinco fases de un proyect
o:
Iniciacin (IP), Planificacin (Pl), Control (CoP), Ejecucin (EP) y Cierre (ClP).
La figura 5.4 muestra la relacin entre estos grupos y la tabla 5.2 presenta su
descripcin.
Figura 5.4: Grupos de procesos de gestin.
El nivel de actividad de estos grupos de procesos durante el proyecto vara en el
tiempo
tal como ilustra la figura 5.5.
Figura 5.5: La relevancia de los grupos de procesos de gestin a lo largo del proy
ecto.
CDIGO GRUPO DE PROCESOS DESCRIPCIN
IP Procesos de Iniciacin Autorizar el proyecto o fase.
PP Procesos de Planificacin
Definir y refinar objetivos y seleccionar el mejor curso alternativo
de accin para conseguir los objetivos que el proyecto persigue
alcanzar.
EP Procesos de Ejecucin Coordinar personas y otros recursos para llevar adelante
el plan.
CoP Procesos de Control
Asegurar que los objetivos del proyecto son conseguidos
midiendo y monitoreando el progreso regularmente a travs de
identificar variaciones respecto de plan, para as tomar acciones
correctivas cuando sea necesario.
ClP Procesos de Cierre Formalizar la aceptacin del proyecto fase y poniendo todo
en un
orden coherente.
Tabla 5.2. Grupos de procesos de gestin.
5.2.2.3. Procesos de gestin de proyectos
Los Procesos de Gestin de Proyectos son el eje de toda la propuesta del PMBOK (ta
bla
5.3), constituyendo el centro de las mejores prcticas de gestin de proyectos. En l
a
codificacin X.Y de cada proceso, la X indica el nmero de rea de conocimiento a la
cual pertenece, mientras la Y es un correlativo. A cada proceso se le asocian en
tradas y
salidas y un conjunto de herramientas y tcnicas de gestin. Esta representacin de la

gestin de proyectos, ha sido una de las principales aportaciones del PMBOK al mun
do
de la investigacin y de la profesin de proyectos, al mostrar de manera clara que
existen, por una parte, procesos de gestin y, por otra parte, herramientas y tcnic
as
donde, los primeros usan las segundas a conveniencia segn necesidades y habilidad
es
del gestor y de los participantes.
# PROCESO DE GESTIN
DE PROYECTOS DESCRIPCIN
4.1 Desarrollo del plan del proyecto Integrar y coordinar los planes de proyecto
s e integrarlos en un informe coherente y
consistente.
4.2 Ejecucin del plan de proyecto Llevar a cabo el plan de proyecto desarrollando
las actividades incluidas en dicho plan.
4.3 Control general de cambios Coordinar los cambios que se producen a lo largo
de todo el proyecto.
5.1 Iniciacin Autorizar el proyecto o fase.
5.2 Planificacin del alcance Desarrollar un informe escrito del alcance que sirva
de base para las futuras decisiones del
proyecto.
5.3 Definicin del alcance Subdividir las principales entregas del proyecto en com
ponentes ms pequeos y manejables.
5.4 Verificacin del alcance Formalizar la aceptacin del alcance del proyecto.
5.5 Control de cambios del alcance Controlar los cambios en el alcance del proye
cto.
6.1 Definicin de actividades Identificar las actividades especficas que se deben d
esarrollar para cumplir con las principales
entregas del proyecto.
6.2 Ordenacin de las actividades Identificar y documentar las distintas interrela
ciones entre actividades.
6.3 Estimacin de la duracin de las
actividades Estimar el nmero de jornadas laborales que se necesitarn para terminar
cada actividad.
6.4 Desarrollo del programa Analizar la secuencia de actividades, su duracin y la
s necesidades de recursos para elaborar
el programa del proyecto.
6.5 Control del programa Controlar los cambios del programa del proyecto.
7.1 Planificacin de recursos Determinar qu recursos (personal, equipamiento, mater
iales) y qu cantidad de cada uno de
ellos se debe utilizar para desarrollar las actividades del proyecto.
7.2 Estimacin de costes Desarrollar una aproximacin (estimacin) de los costes de lo
s recursos necesarios para
completar las actividades del proyecto.
7.3 Presupuesto de costes Asignar la estimacin general de costes a cada uno de lo
s elementos de trabajo.
7.4 Control de costes Controlar los cambios que se produzcan en el presupuesto d
el proyecto.
8.1 Planificacin de la calidad Identificar qu normas de la calidad son ms important
es para el proyecto y determinar cmo
cumplirlas.
8.2 Aseguramiento de la calidad Evaluar el desarrollo general del proyecto sobre
una base establecida, con el fin de tener la
seguridad de que el proyecto satisfar las ms importantes normas de la calidad.
8.3 Control de la calidad
Realizar un seguimiento de los resultados especficos del proyecto para determinar
si cumplen
las normas ms importantes sobre la calidad e identificar la manera de eliminar la
s causas de
un desarrollo no satisfactorio.
9.1 Planificacin de la organizacin Identificar, documentar y asignar las funciones
, responsabilidades y relaciones jerrquicas del
proyecto.
9.2 Adquisicin de personal Reunir los recursos humanos que sea necesario asignar
al trabajo del proyecto.
9.3 Desarrollo del equipo Desarrollar las aptitudes individuales y de grupo para
mejorar el desarrollo del proyecto.
10.1 Planificacin de comunicaciones
Determinar las necesidades de informacin y comunicaciones de las entidades involu
cradas en
el proyecto: quin necesita qu tipo de informacin, cundo la van a necesitar y cmo les
ser
enviada.
10.2 Distribucin de informacin Poner a disposicin de las entidades involucradas en
el proyecto la informacin necesaria en el
momento adecuado.
10.3 Informe de realizacin Recopilar y distribuir la informacin sobre el desarroll
o del proyecto. Esto incluye el informe de
situacin, la evaluacin del progreso y las previsiones.
10.4 Cierre administrativo Elaborar, reunir y distribuir la informacin necesaria
para formalizar una fase o la terminacin
del proyecto.
11.1 Planificacin de la gestin de riegos Decidir el enfoque y el plan para la gest
in del riesgo del proyecto.
11.2 Identificacin de riesgos
Determinar qu tipo de riesgos es probable que afecten al proyecto y documentar la
s
caractersticas de cada uno de ellos.
# PROCESO DE GESTIN
DE PROYECTOS DESCRIPCIN
11.3 Evaluacin de riesgos Realizar un anlisis cualitativo de los riesgos y sus con
diciones para priorizar sus efectos sobre
los objetivos del proyecto.
11.4 Cuantificacin de riesgos Medir la probabilidad y el impacto de los riesgos y
estimar sus implicaciones sobre los objetivos
del proyecto.
11.5 Planificacin de las respuestas a
riesgos
Desarrollar procedimientos y tcnicas para mejorar las oportunidades y reducir las
amenazas
respecto de los objetivos del proyecto.
11.6 Monitoreo y control de riesgos Monitorear los riesgos residuales, identific
ar nuevos riesgos, ejecutar planes de reduccin de
riesgos y evaluar su efectividad a lo largo del ciclo de vida del proyecto.
12.1 Planificacin de aprovisionamientos Determinar qu aprovisionar y cundo.
12.2 Planificacin de la peticin de
ofertas Documentar las necesidades del producto e identificar los potenciales su
ministradores.
12.3 Peticin de ofertas Obtener presupuestos, ofertas y propuestas adecuadas.
12.4 Seleccin de suministradores Elegir entre los potenciales proveedores.
12.5 Administracin del contrato Dirigir las relaciones con los proveedores.
12.6 Cierre del contrato Finalizar la relacin contractual, incluyendo la resolucin
de cualquier tema abierto.
Tabla 5.3. Procesos de gestin de proyectos.
5.2.2.4. Relacin entre grupos, reas y procesos
La relacin entre grupos, reas y procesos se presenta en la tabla 5.4. En esta tabl
a,
cada x indica la pertenencia de procesos de rea de conocimiento en un grupo de
procesos. Aunque los procesos en cada rea pueden aparecer como elementos aislados

con conexiones bien definidas, en la prctica pueden solaparse e interaccionar de
una
manera no detallada aqu. Estos procesos interaccionan entre ellos, as como con los

procesos en las otras reas de desarrollo. Cada proceso puede requerir esfuerzos d
e una
o mas personas o grupos de personas, segn sean las necesidades del proyecto.
Generalmente, cada proceso ocurre al menos una vez en cada fase del proyecto.
IP PP EP CoP ClP
Gestin de la Integracin
Gestin del Alcance
Gestin del Tiempo
Gestin del Coste
Gestin de la Calidad
Gestin de Recursos Humanos
Gestin de las Comunicaciones
Gestin del Riesgo
Gestin del Abastecimiento
x
x
x
x
x
x
x
x
x
x
x
x
x
x
x
x
x
x
x
x
x
x x
x
x
Tabla 5.4. Relaciones entre grupos, reas y procesos.
En particular, segn la importancia relativa, cada proceso en un grupo cumple un r
ol
principal o facilitador segn sea, respectivamente, prioritario o de relevancia o
sencillamente se le considere un complemento al objetivo del grupo. Estas relaci
ones se
muestran en la tabla 5.5. A modo de ejemplo, la figura 5.6 ilustra el Grupo de P
rocesos
de Control (PP).
Figura 5.6: Grupo de Procesos de Control.
REAS DE
CONOCIMIEN
TO
GRUPO DE
PROCESO
S DE
INICIACI
N
GRUPO DE PROCESOS DE
PLANIFICACIN
GRUPO DE
PROCESOS DE
EJECUCIN
GRUPO DE PROCESOS DE
CONTROL
GRUPO
DE
PROCESO
S DE
CIERRE
#4. Gestin de
la Integracin
5.1.
Initiation
(p)
4.1. Project Plan
Development (p)
4.2. Project Plan
Execution (p)
4.3. Overall Change
Control (p)
#5. Gestin del
Alcance
5.1. Scope Planning (p)
5.3. Scope Definition (p)
5.4. Scope Verification (f)
5.3. Scope Change Control (f)
#6. Gestin del
Tiempo
6.1. Activity Definition (p)
6.2. Activity Sequencing (p)
6.3. Activity Duration Estimating
(p)
6.4. Schedule Development (p)
6.5. Schedule Control (f)
#7. Gestin del
Coste
7.1. Resource Planning (p)
7.2. Cost Estimating (p)
7.3. Cost Budgeting (p)
7.4. Cost Control (f)
#8. Gestin de
la Calidad 8.1. Quality Planning (f) 8.2. Quality
Assurance (f) 8.3. Quality Control (f)
#9. Gestin de
Recursos
Humanos
9.1. Organizational Planning (f) 9.2. Team
Development (f)
#10. Gestin de
las
Comunicaciones
10.1. Communications Planning
(f)
10.2.
Information
Distribution (f)
10.3. Performance Reporting
(p)
10.4.
Administrat
ive Closure
(p)
#11. Gestin del
Riesgo
11.1. Risk Management Planning
(p)
11.2. Risk Idenrifiaction (f)
11.3. Risk Assessment (f)
11.4. Risk Quantification (f)
11.5. Risk Response Planning (f)
11.6. Risk Monitoring and
Control (f)
#12. Gestin del
Abastecimiento
12.1. Procurement Planning (f)
12.2. Solicitation Planning (f)
12.3. Solicitation
(f)
12.4. Source
Selection (f)
12.5. Contract
Administration
(f)
12.6.
Contract
Close-out
(p)
Tabla 5.5. Relacin entre grupos de procesos, reas de conocimiento y procesos de ge
stin de proyectos.
p: principal; f: facilitador (cursiva).
TIPO DE PROBLEMA DE GESTIN McCONNELL GLASS PURBA et al. REDMILL
GESTIN DE
INTEGRACIN
Planificacin
Exceso de
requerimientos
(producto)
Usuarios se resisten
Incapacidad de los
usuarios en
comunicar
requerimientos
(elemento humano)
Poca claridad en los
requerimientos
Abandono de
tiempo en el inicio
(proceso)
Promotor est
perdido
Ejecucin
Prdida de tiempo
en el inicio
(proceso)
Poltica antes que
desarrollo
(personas)
Poltica
organizacional
(aspectos polticos)
Cambiar de
herramientas a
mitad del proyecto
(tecnologa)
Cambios
tecnolgicos
elegidos
Falla en el uso de
metodologas del
desarrollo
Diseo inadecuado
(proceso)
Convergencia
prematura o
excesivamente
frecuente (proceso)
Falta de
participacin del
usuario (personas)
Equip. polticos
(aspec. polticos)
Poltica indiv.
(aspec. polticos)
Aadir ms personal
a un proyecto
retrasado
(personas)
Tiras y aflojas en la
negociacin
(producto)
Mejores prcticas y
lecciones son
olvidadas
Mala gestin de las
fases de desarrollo
(elemento humano)
Ms especificacin
Pruebas
insuficientes (error
humano)
Control
Falta de control
automtico del
cdigo fuente
(tecnologa)
Cambios son
pobremente
gestionados
Cambios en las
prestaciones
(producto)
Falta de control de
cambios
Cambios en las
necesidades de
negocio
Incapacidad de
acomodar cambios
a requerimientos de
negocios (elemento
humano)
GESTIN DEL
ALCANCE
Iniciacin
Desarrollo orientado
a la investigacin
(producto
Falta de un proyecto
efectivo del
proyecto (personas)
Planificacin
Gestores no
comprenden las
necesidades de los
usuarios
Incapacidad de los
usarios en
comprender las
implicaciones de los
requerimientos de
negocios (elemento
humano)
Planificacin
insuficiente
(proceso)
Alcance mal
definido
Mala planificacin
(elemento humano)
Expectativas poco
realistas (personas)
Expectativas porco
realistas (elemento
humano)
Sndrome de la
panacea tecnolgica
Estrategia de
implementacin
dbil (elemento
humano)
Mejoras prcticas y
lecciones son
olvidadas
Sobreestimacin de
las ventajas del
empleo o de nuevas
herramientas o
mtodos
(tecnologa)
Ejecucin
Limitaciones
tcnicas
Polticas de la
unidad informtica
de la organizacin
(aspectos polticos)
Control
Mejoras prcticas y
lecciones son
olvidadas
Control insuficiente
de la directiva
(proceso)
GESTIN DE
COSTES
Planificacin
Omitir tareas
necesarias en la
estimacin (proceso)
Tiempo y presupuesto
inadecuado
Estimaciones erradas Estimaciones erradas
No se hace estimacin
Control Recursos insuficientes
(elemento humano)
GESTIN DEL
TIEMPO
Planificacin
Omitir tareas
necesarias en la
estimacin (proceso)
Plazos irreales
Tiempo y presupuesto
inadecuado.
Estimaciones erradas
No se hace estimacin
Control
Planificar ponindose
al da ms adelante
(proceso)
Programa a destajo
(proceso)
GESTIN DE LA
CALIDAD
Planificacin
Se carece del personal
con las habilidades
adecuadas
Ejecucin Oficinas repletas y
ruidosas (personas)
Control
Escatimar en el
control de la calidad
(proceso)
GESTIN DE
RECURSOS
HUMANOS
Planificacin
Ilusiones (personas)
Motivacin dbil
(personas)
Personal mediocre
(personas)
Se carece de personal
con habilidades
adecuadas
Insuficientes
habilidades tcnicas
(elemento humano)
Ejecucin
Empleados
problemticos
incontrolados
(personas)
Pobres
desarrolladores
(elemento humano)
Desarrolladores
meticulosos
(producto)
Poltica individual
(aspectos polticos)
Hazaas (personas)
Fricciones entre los
dientes y los
desarrolladores
(personas)
Falta de participacin
de los implicados
(personas)
GESTIN DE
COMUNICACIONES
Planificacin
Insuficientes
habilidades tcnicas
(elemento humano
Estrategia de
implementacin dbil
(elemento humano)
Ejecucin
Mejores prcticas y
lecciones son
olvidadas
Control
con las habilidades
adecuadas
Cierre
negociacin
(personas)
Falta de participacin
de los usuarios
(personas)
GESTIN DEL RIESGO
Planificacin Gestin de riesgo
insuficiente (proceso)
Control
negociacin
(personas)
GESTIN DEL
APROVISIONAMIENTO
Planificacin Fallos en los
contratados (proceso)
Incapacidad para
tratar con contratistas
y vendedores
(elemento humano)
Ejecucin
Incapacidad para
tratar con contratistas
y vendedores
(elemento humano)
Control Recursos insuficientes
(elemento humano)
Cierre
con las habilidades
adecuadas
Tabla 5.6. Diversos tipos de problemas de gestin clasificados segn el PMBOK.
5.2.3. Estados de una mala gestin de proyectos
Los errores mostrados en la tabla 5.6 y muchos otros ms, ocurren y han sido
reportados profusamente en la literatura. No obstante, se han podido determinar
algunos estados que indican una gestin de proyectos inefectiva o de que es pruden
te
plantearse usarla. Estos estados de un proyecto son:
Modo ajustado (crunch mode);
Marcha mortal (death march); y,
Fuera de control (runaway).
5.2.3.1. Modo ajustado
El modo ajustado, para Glass, describe un proyecto que se encuentra extremadamen
te
ajustado a la programacin. Se habla que existen fuertes presiones que sienten los

participantes del proyecto. Es el estado cuando el proyecto anda por los lmites d
el
programa de trabajo, ms bien superndolo. En este estado, dentro del proyecto
informtico comienza a notarse que:
-
Las semanas tienen siete das y los das 24 horas;
-
Los das son cortos y las noches largas;
-
Empiezan las primeras fugas;
-
Hay una 'ralentizacin' de la motivacin;
-
Se suceden las re-planificaciones de forma frecuente;
-Etc.
5.2.3.2. Marcha mortal
La marcha mortal, segn Glass, describe un estado en que el proyecto tiene una
programacin difcil de conseguir. Se habla que hay olor a fracaso (esto huele mal)
entre los participantes. Para Yourdon, un proyecto en marcha mortal posee una
valoracin de riesgo de falla sobre el 50 por ciento (incluyendo riesgos tcnicos, d
el
personal, legales, polticos, etc.). Segn Ribera este estado es un Modo Imposible d
e
trabajo debido a que:

El plazo es inferior a la mitad de lo que racionalmente se precisa;

El personal asignado es inferior a la mitad que habitualmente se asignara a un
proyecto de estas caractersticas;

El presupuesto se ha recortado a la mitad, y,

La funcionalidad, requisitos, y otros aspectos tcnicos son superiores al doble de
lo normal.
El mismo Ribera acota, que es estas situaciones surgen preguntas como: Qu hace un
chico como yo en un proyecto como ste o Cmo puedo sobrevivir a este proyecto
sin perder mi salud fsica y mental y mi dignidad?.
5.2.3.3. Fuera de control y escalada
Un proyecto fuera de control, o Runaway, describe un estado o un estado de cosas
manifestadas cuando un proyecto est cerca o despus de su trmino. Sencillamente, el
proyecto est fuera de sus lmites, o ya no tiene lmites, hablndose, segn Glass, que
el proyecto fall o est pronto a fracasar.
Cuando se est fuera de control, se puede decir que estamos ante una bola de nieve
, la
cual resulta de una escalada de errores por motivos, que segn Keil y Mixon, se de
ben a
factores psicolgicos, sociales y organizacionales. Estos errores son consecuencia
de
una gestin inadecuada, fallida o nula, que pone al personal y especialmente a ges
tores,
ante una variedad de problemas que supera sus capacidades de gestin y de resolucin

de problemas. Esta situacin hace que un error lleve a otro, producindose una caden
a
creciente, una escalada de problemas de gestin, debido al cansancio, fatiga y
desorientacin que supone la tensin de la situacin.
Lo anterior es lo que se llama escalada y romperla requiere una alta capacidad d
e
superar el estrs fsico y mental que supone un rescate, hundimiento o salvamento
parcial del proyecto.
5.2.4. Razn de la gestin de proyectos
Se ha dicho que la gestin de proyectos es una manera de hacer frente a problemas
y
retos. Tambin hemos aadido los estados de un proyecto que presenta problemas de
gestin. Ahora se presentan razones ms concretas que justifican la gestin de
proyectos en un proyecto en general y en un proyecto de base tecnolgica. Ellas so
n:
-Actuacin predictiva; y,
-Recuperacin.
5.2.4.1. Actuacin predictiva
Para varios autores, una forma de actuar predictivamente en los problemas de ges
tin,
es anticiparse a ellos con una completa y adecuada gestin de proyectos, la cual p
uede
medirse si con la gestin se garantizan alcanzar los siguientes Factores Crticos de
xito
(planteados por Jurison):
Objetivos claramente definidos.
Apoyo claro y total de la direccin.
Presupuesto adecuado y realista.
Programa coherente, racional y realista.
Participacin y confianza real del cliente y usuarios.
Buen liderazgo del proyecto.
Revisiones continuas, constructivas y positivas del proyecto.
Gestin y control eficiente y eficaz del cambio.
Buenas comunicaciones entre integrantes del proyecto.
Anticiparse
y solucionar los problemas que surjan con una gestin de
contingencias.
5.2.4.2. Recuperacin
Otros autores sealan que la gestin de proyectos permite determinar el momento y la
s
acciones de recuperacin de un proyecto, igualmente de que estas acciones se lleve
n
delante de manera adecuada. En este caso se habla de una de-escalacin y/o la
convocacin de un caballero blanco.
a. De-escalar
En una de-escalacin se toman acciones que permitan superar los diversos problemas

de gestin ante una escalada. Para Ribera recuperarse de una escalada puede ser:
-Recortar la envergadura del proyecto;
-Aumentar la productividad mediante mejoras a corto plazo; y/o,
-Asumir que el proyecto no terminar a tiempo, atrasar el plan y adoptar medidas
de control de daos.
Lo que para Glass se traduce en tomar acciones en el siguiente orden de preferen
cia:
-
Extender las fechas;
-
Usar mejores procedimientos de gestin;
-
Ms personal;
-
Ms fondos;
-
Reduccin en alcance del proyecto;
-Mejores metodologas de desarrollo;
-Cambiar tecnologa; y,
-Abandonar el proyecto.
Acciones que, para Montealegre y Keil, no tendran ningn efecto si no se apela a la

colaboracin y cooperacin de los participantes involucrados en el proyecto o,
sencillamente, des-institucionalizar el proyecto, dejando la de-escalacin como un

problema interno de gestin a superar internamente.
b. El caballero blanco
Una forma posible de superar los problemas de gestin es contratar a un experto en

salvar proyectos, aquella persona milagrosa que viene a salvar todo mal funciona
miento
y a intentar recuperar el proyecto: el caballero blanco (knight white). En este
tipo de
solucin debe considerarse la asesora y la consultora en proyectos como un medio
vlido de conseguir algn caballero blanco.
5.3. HERRAMIENTAS Y TCNICAS DE GESTIN
Para completar este captulo de gestin de proyectos no se deben olvidar una serie d
e
herramientas y tcnicas de gestin. Estas herramientas y tcnicas se presentan a
continuacin vinculadas los grupos de procesos, lo cual no significa que ellas slo
sean
de aplicabilidad a un solo grupo. Igualmente, muchas de ellas se encuentra sopor
tadas
por diversas herramientas informticas.
5.3.1. Iniciacin
La iniciacin es el proceso de reconocimiento formal de que se va a desarrollar,
construir de forma material y tangible, una solucin de negocio compuesta de
componentes humanos y de hardware y software. El compromiso aborda el desarrollo

de un nuevo proyecto o de que un proyecto ya existente se va a continuar en su
siguiente fase.
Este comienzo formal conecta el proyecto con las operaciones en curso de la
organizacin ejecutora. En algunas organizaciones, un proyecto no est formalmente
iniciado hasta tener completo un estudio de viabilidad, un plan preliminar o alg
una forma
equivalente de anlisis que, como tal, tambin ha tenido que ser comenzado
separadamente. Esto involucra trabajar con el cliente para identificar las entid
ades clave
en la organizacin para entrevistarles.
En particular, algunos tipos de proyectos, especialmente los de servicio interno
y los de
desarrollo de nuevos productos (de ingeniera), se inician informalmente y se real
iza una
pequea parte del trabajo para asegurar los requisitos necesarios para lograr el
comienzo formal del proyecto.
5.3.1.1. Motivaciones del proyecto
En la iniciacin es importante determinar con claridad el motivo por el cual proye
cto se
inicia, la cual puede deberse a alguna o varias de las siguientes causas:
Una demanda del mercado (por ejemplo, una compaa petrolfera comienza un
proyecto para construir una nueva refinera en respuesta a la continua escasez de
gasolina).
Una necesidad de negocio (por ejemplo, una compaa de formacin comienza un
proyecto para crear un nuevo curso para aumentar sus ingresos).
La demanda de un cliente (por ejemplo, un suministrador elctrico comienza un
proyecto para construir una nueva subestacin para abastecer a un nuevo parque
industrial).
Un avance tecnolgico (por ejemplo, una empresa electrnica comienza un nuevo
proyecto para desarrollar un videojuego, despus de la generalizacin del
videocassette).
Una necesidad legal (por ejemplo, un fabricante de pinturas comienza un proyecto

para fijar las directrices del manejo de materiales txicos).
Estas causas tambin pueden llamarse problemas oportunidades, o requerimientos del

negocio. Lo fundamental de todos estos trminos es que la direccin suele tener que
tomar una decisin sobre cmo responder a ellos.
5.3.1.2. Seleccin del gestor del proyecto
El gestor del proyecto es habitualmente seleccionado al final de la conceptualiz
acin del
proyecto, una vez aprobado. El gestor del proyecto es una persona responsable de

dirigir, gestionar y administrar todo el proyecto.
Su responsabilidad central es coordinar todas las actividades para satisfacer lo
s
objetivos del proyecto en tiempo y presupuesto. Su rol es diferente de un lder tcn
ico o
un desarrollador, cuyas responsabilidades se relacionan con la integridad tcnica
del
producto.
Entre sus diversas responsabilidades se puede destacar:
-Informar a la direccin;
-Comunicacin con usuarios;
-Planificacin y programacin;
-Coordinacin de actividades y tareas;
-Control de presupuesto, programa, riesgo y calidad;
-Gestin de personal; y,
-Entregar resultados.
La tarea del gestor es dar visibilidad y gestionar compromisos. Encontrar una pe
rsona
para esta tarea no es sencillo, pues pocas personas cumplen con todas las
cualificaciones para proyectos complejos, menos an que tenga experiencia y est
disponible. Por este motivo, muchas empresas crean una Oficina de Proyectos para

gestionar mejor los proyectos y crear un pool de futuros gestores.
Gestores efectivos deberan tener siguientes habilidades de: comunicacin,
organizacin, construccin de equipo, liderazgo; negociacin, actuacin por objetivos,
capacidad de trabajo bajo presin y competencia tcnica.
Se recalca que la competencia tcnica es til y sirve bastante, pero habilidades de
gestin e interpersonales son ms importantes para un gestor de proyectos, de hecho,

tener roce en el trato de personas, puede ser determinante al momento de escoger e
l
gestor de un proyecto, ms que sus cualificaciones y experiencia tcnica.
Los gestos exitosos son generalistas, no especialistas tcnicos. An ms, en muchas
ocasiones provienen de muchas reas de la organizacin y no necesariamente del
mundo de la informtica.
5.3.2. Planificacin
La planificacin requiere un fuerte esfuerzo de estimacin para preparar las accione
s
conducentes a conseguir el producto y cumplir con los objetivos, y de seleccin de

personal para cumplir con las tareas y actividades definidas. Todo esto da lugar
a un
informe de alcance y al plan del proyecto.
Esta es una etapa de comprensin del proyecto que implica:
Entrevistar directivos
para conseguir comprender el modelo de negocios, la
situacin de mercado actual, objetivos y metas de negocio e intenciones iniciales
sobre cmo Internet puede ayudar al logro de los objetivos y las metas.
Revisar procesos de negocios claves y la infraestructura que les soporta.
Revisar y analizar la situacin actual frente al potencial uso de entrar en Intern
et
(presencia de un sitio web con respecto a la visibilidad actual, efectividad com
o
medio de comunicacin, facilidad de uso/navegacin, desempeo completo, solidez
de la arquitectura tcnica, etc.).
Revisar y analizar el actual uso de intranets para promover la comunicacin intern
a
y la comparticin de datos.
Revisar polticas y procedimientos establecidos en los procesos operacionales
asociados o con relacin a los potenciales objetivos e-business.
Todos estos elementos han de aparecer detallados en el Plan del Proyecto y en el

Informe del Alcance.
5.3.2.1. Estimacin
5.3.2.1.1. Estimacin del trabajo
La definicin del alcance comprende la subdivisin de las principales entregas del
proyecto (identificadas en el informe del alcance) en componentes ms pequeos y
manejables con el fin de:
Mejorar la precisin de las estimaciones de costes, programa y recursos.
Definir las bases para la medida y control de la realizacin del proyecto.
Facilitar una clara asignacin de responsabilidades.
La adecuada definicin del alcance del proyecto es crtica para el xito de un proyect
o.
Cuando hay una pobre definicin del alcance, se puede esperar que se eleven los co
stes
finales del proyecto debido a los inevitables cambios que interrumpen el ritmo d
el
proyecto, causan repeticiones de tareas, aumentan los plazos de entrega, y dismi
nuyen
la productividad y la moral, de la plantilla.
Una herramienta til para estimar el trabajo a realizar lo constituye la Estructur
a de
Descomposicin del Proyecto (WorkBreakdown Structure, WBS).
a. WBS
La base de las actividades de planificacin lo constituye el WBS. Un WBS descompon
e
el proyecto en una estructura jerrquica bien definida de tareas o actividades
gestionables, cuya representacin puede ser una tabla o un rbol.
El nmero de niveles depende principalmente del tamao del proyecto y las preferenci
as
del gestor del proyecto. Es importante que se expliquen todas las actividades ne
cesarias
para completar el proyecto y que sean asignadas a un entidad (persona u organiza
cin)
de manera clara y precisa anulando toda posibilidad de ambigedad.
Un WBS es una agrupacin de elementos del proyecto orientada a las entregas del
proyecto, que organiza y define el alcance completo del proyecto: trabajos que n
o estn
en la EDP quedan fuera del alcance del proyecto. As, el WBS provee as un marco
fundacional para programar, presupuestar y controlar el proyecto. Una vez defini
do, el
proceso de estimacin comienza. Esto no evita que puedan servir para otros proyect
os
o se reutilicen.
La descomposicin comprende la subdivisin de las principales entregas del proyecto
en
otros componentes ms pequeos y manejables de forma que las entregas sean
definidas con suficiente detalle para responder a las futuras actividades de] pr
oyecto. La
descomposicin comprende los siguientes pasos principales:
1.
Identificar los principales elementos del proyecto. En general, los principales
elementos sern las entregas del proyecto y la direccin del proyecto. Sin
embargo, siempre se deben definir los principales elementos dependiendo de
como el proyecto sea realmente dirigido. Por ejemplo, las fases del ciclo de vid
a
pueden constituir un primer nivel de descomposicin, con un segundo nivel
determinado por las entregas (figura 5.7) o por algn otro criterio organizativo
(figura 5.8).
2.
Decidir si se pueden realizar las adecuadas estimaciones de duracin y costes al
nivel de detalle para cada elemento. El significado de adecuadas puede variar en

el curso del proyecto (la descomposicin de una entrega que se ha de producir
en un tiempo lejano puede no sea posible). Para cada elemento, hay que pasar
al Punto 4 si se ha logrado el detalle adecuado y al Punto 3 si no es as (esto
quiere decir que los diferentes elementos pueden tener diferentes niveles de
descomposicin).
Figura 5.7: WBS de una estructura de descomposicin por fases.
3.
Identificar los elementos constituyentes de una entrega. Los elementos
constituyentes se deberan describir en trminos de resultados verificables y
tangibles, para facilitar la medida de la realizacin. Los elementos
componentes-del proyecto deben definirse, como se hace con los elementos
principales, en la misma forma como se terminar realmente el trabajo del
proyecto.
Resultados tangibles y verificables pueden incluir tanto servicios como
productos (por ejemplo, el informe de situacin se puede describir como
informe de situacin semanal; para un elemento manufacturado, los elementos
constituyentes podran incluir varios componentes individuales ms el montaje
final). Repetir el punto 2 para cada elemento constituyente.
Figura 5.8: WBS de una planta de tratamiento de aguas residuales.
4. Verificar si se ha realizado la descomposicin correcta:
-Son necesarios y suficientes los elementos en el nivel inferior para
completar el elemento descompuesto? Si no es as, se deben modificar los
elementos constituyentes (aadir, eliminar o redefinir).
-Est cada elemento clara y completamente definido? Si no es as, se deben
revisar o ampliar las descripciones.
-Se puede programar correctamente cada elemento?, presupuestar?,
asignar a una unidad especfica de la organizacin (por ejemplo, un
departamento, equipo o persona) que aceptar la responsabilidad de
concluir satisfactoriamente el elemento? Si no es as, se requieren revisiones
que proporcionen un adecuado control.
b. Work packages
Cada nivel descendente representa una descripcin cada vez ms detallada de los
elementos del proyecto. Cada elemento en la EDP es asignado a un nico identificad
or;
el conjunto de estos identificadores a menudo se denomina cdigo de cuentas. Los
elementos de los niveles ms bajos de la EDP se suelen denominar paquetes de traba
jo
(work packages). Estos paquetes de trabajo pueden ser descompuestos an ms.
Las descripciones de los elementos de trabajo se renen frecuentemente en un
diccionario de la WBS. Este diccionario incluye generalmente descripciones de pa
quetes
de trabajo as como otra informacin de planificacin como fechas del programa,
presupuestos de costes y asignaciones de personal.
c. Otros tipos de WBS
No se debe confundir una WBS con otros tipos de estructuras de descomposicin
utilizadas para presentar informacin del proyecto.
Otras estructuras comnmente utilizadas en algunas reas de aplicacin son:
Estructura de descomposicin contractual, que se utiliza para definir el nivel de
informacin que el proveedor suministrar al comprador. La WBS contractual tiene
normalmente menos detalle que una WBS utilizada por el proveedor para dirigir su

propio trabajo.
Estructura de descomposicin organizativa, que muestra qu elementos de trabajo
han sido asignados a qu unidades de la organizacin. Un organigrama.
Estructura de descomposicin de recursos, que es una variacin de la estructura de
descomposicin organizativa, y se utiliza normalmente cuando se asignan los
elementos de trabajo a personas individuales.
Lista de materiales, que representa
una relacin jerrquica de los montajes,
submontajes y componentes necesarios para fabricar un producto manufacturado.
Estructura de descomposicin de tareas, que es prcticamente lo mismo que una
WBS correctamente realizada. La estructura de descomposicin de tareas se utiliza
ampliamente en reas en las que el trmino WBS es incorrectamente utilizado para
referirse a una lista de materiales.
5.3.2.1.2. Estimacin de coste y programacin
Los dos enfoques esenciales para estimar el coste y la programacin necesaria de u
n
proyecto son dos.
a. Enfoque arriba-a-abajo y abajo-a-arriba
1. Enfoque arriba-a-abajo.
Esta es una estimacin por analogas que significa utilizar el coste real de
anteriores proyectos similares como base para la estimacin del coste del
proyecto actual.
Se usa frecuentemente para estimar los costes totales del proyecto cuando la
informacin detallada sobre el proyecto es escasa (por ejemplo, en las fases
iniciales de un proyecto). La estimacin por analogas es una forma de juicio
experto.
La estimacin por analogas es generalmente ms barata que otras tcnicas,
pero tambin suele ser menos precisa. Es ms fiable, cuando los proyectos
anteriores son realmente similares y no solo en apariencia, y las personas o
grupos de personas que realizan las estimaciones tienen la experiencia
necesaria.
2. Estimacin abajo-a-arriba.
Esta tcnica comprende la estimacin de costes de tareas individuales:
sumando las estimaciones individuales se consigue el coste total del proyecto.
El coste y la precisin de la estimacin de abajo-a-arriba depende del tamao de
las tareas individuales: cuanto ms pequeas son las tareas tanto ms se
incrementa el coste como la precisin. El equipo de direccin del proyecto debe
sopesar si la precisin adicional justifica el mayor coste.
Ambos mtodos o enfoques se usan en conjunto y se requieren varias iteraciones has
ta
alcanzar resultados que puedan considerarse satisfactorios.
b. GANTT, PERT y CPM
Conseguir una buena programacin es un reto, no obstante es razonable y alcanzable
.
Ella debe tener el compromiso del equipo al completo, para lo cual se recomienda
que
cada miembro o grupo del equipo determine las tareas a realizar y el tiempo para

cumplirlas. La programacin para grandes proyectos usualmente comprende un
programa master, mostrando principales actividades e hitos y dejando el detalle
en subprogramas.
La forma ms comn de presentar un programa es una carta GANTT que muestra las
actividades contra una escala de tiempo horizontal (figura 5.9). Las cartas GANT
T son
herramientas populares para comprender y facilitar la creacin y revisin del progra
ma.
Esto da lugar a una red de programa que muestra las inter-relaciones.
Figura 5.9: Carta GANTT2.
Estas inter-relaciones se muestran habitualmente como redes PERT (Program Evalua
tion
Review Technique, figura 5.10) y CPM (critical path method). Ambos mtodos son
bastante similares en el uso de flujogramas, grafos o redes de dependencia para
mostrar
las inter-relaciones.
2. Fuente: Barcel. M. La gesti dun projecte informtic. UOC. Pp. 15-16.
Figura 5.10: PERT3.
Otra ventaja de las redes de programacin (schedule networks) es que pueden usarse

para identificar y seguir el camino crtico del proyecto. Todos estas tcnicas de
representacin, son instancias de un diagrama de precedencias.
c. Diagrama de precedencias
Este es un mtodo de elaborar un diagrama en red del proyecto usando nodos, que
representan las actividades, conectados mediante flechas, que muestran las
dependencias (figura 5.11): el mtodo del diagrama de precedencias. Esta tcnica se
denomina tambin actividades en los nodos y es el mtodo utilizado en la mayora de lo
s
programas de software para la gestin de proyectos. El mtodo del diagrama de
precedencias se puede realizar manualmente o mediante ordenador.
Figura 5.11: Diagrama de precedencias.
3. Fuente: Barcel. M. La gesti dun projecte informtic. UOC. pp. 9-10.
El mtodo incluye cuatro tipos de dependencias o relaciones de precedencia:

Terminacin-a-comienzo: la actividad inicial debe terminar antes de que la activid
ad
final pueda comenzar;

Terminacin-a-terminacin: la actividad inicial debe terminar antes de que la
actividad final pueda terminar;

Comienzo-a-comienzo: la actividad inicial debe comenzar antes de que la activida
d
final pueda comenzar; y,

Comienzo-a-terminacin: la actividad inicial debe comenzar antes de que la
actividad final pueda terminar.
En el mtodo del diagrama de precedencias, el tipo ms habitual de relacin lgica es el

terminacin-a-comienzo. Las relaciones comienzo-a-terminacin se utilizan rara vez y

cuando se utilizan, es nicamente por ingenieros de programacin profesionales. Usar

las relaciones comienzo-a-comienzo, terminacin-a-terminacin o
comienzo-a-terminacin con el software para gestin de proyectos puede producir
resultados no esperados, ya que estos tipos de relaciones no han sido suficiente
mente
probados. Otros mtodos similares son:

Mtodo del diagrama de flechas. Este es un mtodo de elaboracin de un diagrama
en red del proyecto que utiliza flechas para representar las actividades y las
conecta a nodos que muestran las dependencias (figura 5.12). Esta tcnica
tambin se denomina actividades en las flechas y, aunque menos corriente que el
mtodo del diagrama de precedencias, es la tcnica que se elige en algunas reas
de aplicacin. El mtodo del diagrama de flechas utiliza solamente dependencias
terminacin-a-comienzo y puede necesitar el uso de actividades ficticias para
definir correctamente todas las relaciones lgicas. El mtodo del diagrama de
flechas se puede realizar manualmente o mediante ordenador.
Figura 5.12: Diagrama de flechas.

Mtodos de diagramas condicionales. Las tcnicas de diagramas tales como los
modelos GERT (Tcnica de Revisin y Evaluacin Grfica) y sistemas dinmicos,
permiten tratar actividades no secuenciales tales como lazos (por ejemplo una
prueba que se debe repetir ms de una vez) o condicionadas (por ejemplo, una
actualizacin del diseo que sea solamente necesaria si la inspeccin detecta
errores). Ni el mtodo del diagrama de precedencias ni el mtodo del diagrama de
flechas permiten tratar lazos o actividades condicionadas.

Redes patrn. Se pueden utilizar redes normalizadas para facilitar la preparacin de

los diagramas en red del proyecto. Pueden incluir un proyecto completo o
solamente una parte de l. A las partes de una red se las suele denominar subredes

o fragmentos de redes. Las subredes son especialmente tiles cuando un proyecto
incluye varias partes idnticas o casi idnticas, como las plantas de un edificio al
to
de oficinas, los ensayos clnicos en un proyecto de investigacin farmacutica, o
los mdulos del programa en un proyecto de software.
d. Camino crtico
El camino crtico del proyecto es el conjunto de actividades que toma mayor tiempo

completarlo. En esencia, el camino crtico determina cuando el proyecto terminar. L
as
tareas en el camino crtico requieren atencin especial de la gestin debido a que no
dejan espacios libres u holguras en la programacin, de hecho no puede atrasarse b
ajo
ningn concepto.
Debe hacerse notar que un proyecto puede tener muchos caminos crticos y que las
variaciones en la duracin de las tareas puede ir de un camino a otro. El camino c
ritico
resulta tambin de utilidad para identificar programaciones de riesgo.
El camino crtico es una tcnica anlisis matemtico que comprende el clculo terico
para el comienzo y terminacin, con mayor antelacin y mayor retraso, de todas las
actividades del proyecto sin tener en cuenta las limitaciones del conjunto de re
cursos.
Las fechas resultantes no son el programa, sino que indican los periodos de tiem
po
dentro de los que la actividad debe ser programada, dadas las limitaciones de lo
s
recursos y otras restricciones conocidas.
En esencia, el Mtodo del Camino Crtico es un mtodo de optimizacin que calcula una
fecha de comienzo y terminacin, la de mayor adelanto y la de mayor retraso, para
cada
actividad, basndose en la secuencia de relaciones lgicas ya especificada y en la
simple estimacin de duraciones. El objetivo del mtodo del camino crtico es calcular
el
margen con el fin de determinar qu actividades tienen la menor flexibilidad de
programacin. Los algoritmos del mtodo del camino crtico se utilizan a menudo en
otros tipos de anlisis matemtico.
Algunas variaciones ocurren respecto de un GERT y un PERT.

GERT. Permite el tratamiento probabilstico tanto de las relaciones lgicas como de
las estimaciones de la duracin de las actividades (por ejemplo, algunas actividad
es
pueden no desarrollarse, otras se pueden desarrollar solamente en parte, y otras

pueden desarrollarse ms de una vez).

PERT. Utiliza las relaciones lgicas secuenciales y una media ponderada de la
estimacin de duraciones para calcular la duracin del proyecto. Aunque hay
diferencias superficiales, el PERT difiere del GERT principalmente en que utiliz
a el
concepto de distribucin (valor esperado) en lugar de la estimacin ms probable
originalmente utilizada en este ltimo (figura 5.13). El PERT en s mismo apenas se
usa hoy en da, aunque las estimaciones realizadas para el PERT se usan
frecuentemente en los clculos del CPM.
Figura 5.13: Clculo de la duracin de un proyecto mediante PERT.
Un caso especial de anlisis matemtico es la reduccin de plazos, que busca la manera

de reducir el programa del proyecto sin alterar su alcance (por ejemplo, lograr
las fechas
impuestas u otros objetivos del programa).
La reduccin de plazos incluye tcnicas tales como:

Crashing. Es una tcnica en la que se analizan el coste y los cambios del programa

para determinar cmo obtener la mayor reduccin posible con el menor incremento
de costes. El crashing no siempre produce una alternativa viable y da lugar,
frecuentemente, a un incremento de los costes.

Camino acelerado. Consiste en realizar actividades en paralelo que normalmente s
e
realizaran en serie (por ejemplo, empezar a codificar en un programa de software
antes de completar su diseo, comenzar a construir las cimentaciones para una
refinera de petrleo antes d realizar el 25 por ciento de la labor de ingeniera, o
empezar a comprar hardware sin tener definida la infraestructura e-business).
Normalmente esta tcnica conduce a repetir tareas y frecuentemente incrementa el
riesgo.
e. Programa del proyecto
El programa del proyecto4 incluye al menos las fechas planeadas de comienzo y la
s
previstas de terminacin para cada actividad.
El programa del proyecto se puede presentar en forma de resumen (el programa
bsico) o en detalle. Aunque puede presentarse en forma de tabla, es ms frecuente
presentarlo grficamente, utilizando uno o ms de los siguientes formatos:

Diagramas en red del proyecto con informacin aadida sobre fechas. Estos
diagramas normalmente muestran la lgica del proyecto y las actividades del
camino crtico del proyecto.

Diagramas de barras, tambin llamados diagramas de GANTT. Muestran las fechas
-de comienzo y terminacin de las actividades as como las duraciones esperadas,
pero normalmente no muestran las dependencias. Son relativamente fciles de
interpretar y se usan frecuentemente en los informes de direccin.

Diagramas de hitos. Son similares a los diagramas de barras (figura 5.14), pero
identifican el comienzo o la terminacin programados de las principales entregas y

las conexiones externas clave.
4. El programa del proyecto se considera preliminar hasta que la asignacin de rec
ursos ha sido confirmada. Esto
normalmente ocurre antes de la terminacin del desarrollo del plan del proyecto.
Figura 5.14: Diagrama de hitos.

Red dimensionada. Es una mezcla de diagramas en red del proyecto y de diagramas
de GANTT en la que se muestra la lgica del proyecto, la duracin de las
actividades y la informacin del programa (figura 5.15).
Figura 5.15: Red dimensionada.
5.3.2.1.3. Estimacin de coste y presupuesto
Otras tareas de estimacin son de coste y presupuesto. En un proyecto informtico, e
l
coste del presupuesto se mide en funcin de las horas de esfuerzo dedicadas a las
tareas. La estimacin es un anlisis histrico ajustado a las capacidades y habilidade
s
de cada miembro.
La estimacin cubre todas las actividades del WBS, incluyendo la propia gestin del
proyecto y sus funciones de apoyo, como el aseguramiento de la calidad y el
seguimiento de los planes de riesgo, por ejemplo. La estimacin debe incluir coste
s
directos no laborables, y los costes indirectos o de overhead. Los costes direct
os se
calculan de las horas-hombre multiplicadas por su valor de mercado o acordado. L
os
costes directos no laborables incluyen outsourcing, consultores, viajes, cenas,
etc.
El presupuesto total del proyecto es determinado agregando todos los costes dire
ctos e
indirectos. Es buena prctica incluir salvaguardas de gestin para contingencias y
problemas no anticipados. Una reserva del 5 al 10% no es extraa usual y puede ser

mayor en proyectos mayores o de alto riesgo.
El presupuesto debe asignarse a individuos u organizaciones siguiendo el WBS. El

presupuesto marca la lnea base (baseline) sobre la cual medir el desempeo del
proyecto. Una herramienta adecuada es la curva-s que muestra los costes acumulad
os,
la cual provee la representacin grfica del presupuesto en funcin del tiempo segn la
programacin del proyecto.
Figura 5.16: Curva de coste acumulado.
5.3.2.1.4. Seleccin de los miembros del equipo
La ejecucin de un proyecto es como los deportes, la diferencia entre el miembro ms

productivo y el menos productivo puede ser amplia. No obstante se deberan selecci
onar
los mejores. Por este motivo es importante tener en consideracin que las habilida
des a
buscar no son solamente tcnicas, sino habilidades para solucionar problemas e
interpersonales. An ms, debe recordarse siempre que un buen miembro tiene una alta

auto-estima y un fuerte compromiso hacia el xito de un proyecto.
Cualquier Test a realizar debe crear equipos con una mezcla equilibrada de habil
idades y
personalidades. Muchos programadores o personas del mbito tcnico son personas
introvertidas y pensativas que basan sus decisiones en hechos en lugar de sentim
ientos
y valores personales. Ellos tienen a encontrar dificultades en construir relacio
nes y ver
el proyecto desde el punto de vista del usuario. Por ello, formar un equipo equi
librado no
es una labor sencilla.
5.3.2.2. Plan de proyecto
La planificacin culmina con el plan del proyecto. Este documento describe el enfo
que
completo para desarrollar la aplicacin e-business y sus sistemas informticos
componentes. Es un documento que informa a la gestin, a los miembros del equipo y

al cliente. Es como un mapa que sirve para guiar al proyecto y sus involucrados.

El plan del proyecto es un documento formal y aprobado que se utiliza para dirig
ir y
controlar la ejecucin del proyecto. Debera ser distribuido segn defina el plan de
Gestin de Comunicaciones (por ejemplo, la direccin de la organizacin ejecutora
puede necesitar un plan general con pocos detalles, mientras que un contratista
puede
necesitar muchos detalles de un solo tema). En algunas reas de aplicacin, se usa e
l
trmino plan integrado del proyecto para referirse a este documento.
Debe establecerse una clara distincin entre el plan del proyecto y las bases para
medir
la realizacin del proyecto. El plan del proyecto es un documento o conjunto de
documentos que debera esperarse que cambien a medida que haya ms informacin
disponible sobre el proyecto. Las bases para la evaluacin de la realizacin del pro
yecto
representa un control de direccin que normalmente slo cambiar intermitentemente y
en estos casos, los cambios sern realizados nicamente como respuesta a un cambio
autorizado del alcance del proyecto. En este documento se especifican aspectos d
e
desarrollo, los subproductos a entregar, requerimientos de recursos, programacin,

responsabilidades organizacionales y presupuestos, y el proceso de gestin. Adems,
incluye factores de riesgo y estrategias de gestin del riesgo, y describe de que
manera
se gestiona y asegura la calidad. Establece el coste y las bases de la programac
in para
gestionar y controlar el proyecto. Adems en s mismo es parte efectiva del sistema
de
control del proyecto.
Hay muchas maneras de organizar y presentar el plan del proyecto, pero normalmen
te
incluye lo siguiente (estos puntos se describirn con ms detalle ms adelante):
Justificacin del proyecto.
Descripcin de los puntos de vista o estrategia de la direccin del proyecto (un
resumen de los planes de direccin para cada una de las otras reas).
Establecimiento del alcance, que incluye las entregas y objetivos del proyecto.
WBS al nivel al que se realizar el control.
Estimacin de costes, fechas programadas de inicio de actividades y asignacin de
responsabilidades al nivel de la EDP, en el que ser ejercido el control.
Bases para la evaluacin de la realizacin del proyecto en cuanto a programa y
costes.
Principales hitos y fechas objetivo para cada uno.
Personal requerido o clave.
Riesgos clave, incluyendo las restricciones y supuestos y las respuestas previst
as
para cada uno.
Planes
auxiliares de direccin, incluyendo el plan de gestin del alcance del
proyecto, el plan de direccin del programa, etc.
Temas abiertos y decisiones pendientes.
Se deberan incluir otros resultados de la planificacin del proyecto en el plan for
mal,
basndose en las necesidades de cada proyecto en particular. Por ejemplo, el plan
del
proyecto para un gran proyecto incluir, normalmente, un organigrama del proyecto.

Para probar la adecuacin del plan, el gestor del proyecto debe preguntarse:
El plan permite gestionar el proyecto de forma adecuada?
El plan provee informacin suficiente para que los miembros del equipo planifiquen
y ejecuten su trabajo?
Se cuenta con el compromiso de la direccin y del equipo del proyecto?
5.3.2.3. Informe de alcance
El Informe del Alcance constituye una base documentada para la adopcin de las
futuras decisiones del proyecto y para confirmar o desarrollar entre las entidad
es
involucradas en el proyecto aportando un entendimiento comn del alcance del mismo
.
Segn progresa el proyecto, puede ser necesario revisar o depurar el informe del
alcance, para reflejar los cambios en el mismo. El informe del alcance debe incl
uir, bien
directamente o por referencia a otros documentos, lo siguiente:

Justificacin del proyecto: la necesidad del negocio que debe ser resuelta por el
proyecto. La justificacin del proyecto constituye la base para la evaluacin de
futuros compromisos.

Producto del proyecto: un breve resumen de la descripcin del producto.

Entregas del proyecto: una lista a modo de resumen de los subproductos cuya
completa y satisfactoria entrega marca la finalizacin del proyecto. Por ejemplo,
las
principales entregas de un proyecto de desarrollo de software pueden incluir el
lenguaje de trabajo del ordenador, un manual de usuario y un gestor del programa

interactivo. Cuando sean conocidas, las exclusiones deben ser identificadas,
teniendo en cuenta que cualquier cosa no incluida explcitamente es implcitamente
excluida.

Objetivos del proyecto: los criterios cuantificables que deben cumplirse para qu
e el
proyecto se considere un xito. Los objetivos del proyecto deben incluir, al menos
,
medidas de costes, programa y calidad. Los objetivos del proyecto debe tener un
atributo (por ejemplo, coste), un patrn o unidad fundamental (por ejemplo, dlares
USA) y un valor absoluto o relativo (por ejemplo, menos de 1,5 millones). Los
objetivos no cuantificables (por ejemplo, la satisfaccin del cliente) constituyen
un
riesgo elevado.
En algunas reas de aplicacin, las entregas del proyecto son llamadas objetivos del

proyecto mientras que los objetivos del proyecto son llamados factores crticos de

xito.
5.3.3. Control y seguimiento
El control es una etapa de valoracin del trabajo realizado buscando aprovechar bu
enas
prcticas y analizar las debilidades del proyecto e-business tomando de referencia
los
datos recogidos durante el seguimiento.
5.3.3.1. Aseguramiento de la calidad
El aseguramiento de la calidad (Quality Assurance, QA) asegura que el producto c
umple
con los requerimientos y provee la funcionalidad y calidad deseada.
La calidad, como los requerimientos de desempeo tcnico, debe ser especificada en
trminos cuantitativos que claramente comprensibles por el cliente y los miembros
del
equipo. Adems, mientras el equipo se compromete a construir la calidad en el
producto, una prctica frecuente es contar con alguien dedicado y separado del equ
ipo
cumpliendo funciones de asegurador de calidad. El principal propsito del
aseguramiento de la calidad es detectar errores y corregirles rpidamente. La dete
ccin
y correccin temprana puede resultar en beneficios de coste y tiempo significativo
s.
De hecho, el coste de corregir errores en la etapa de diseo es un 10% de corregir
le en
la etapa de prueba.
La herramientas bsicas para el aseguramiento de la calidad son las revisiones tcni
cas
y las pruebas. Las revisiones tcnicas son efectivas cuando encuentran defectos
tempranamente y encuentran diferentes tipos de error probar. Las prcticas ms
comunes de aseguramiento de las calidad los walkthroughs, las inspecciones y las

pruebas.
Ambos tipos de revisiones son efectivas para la deteccin temprana de errores en
requerimientos, interfaces, diseo, codificacin o manufactura, y documentacin. El
seguimiento del proceso de calidad, requiere mtricas precisas. Por ejemplo, dos
mtricas usadas habitualmente en el desarrollo de software son:
Densidad de defectos (nmero de defectos por 1.000 lneas de cdigo fuente).
Eficiencia de
remocin de defectos (porcentaje de defectos removidos en una
operacin: revisin de cdigo o una prueba).
Walkthroughs
Un walkthrough son reuniones informales en la que los miembros del equipo revisa
n el
diseo o cdigo para identificar mejoras y problemas.
Inspeccin
Las inspecciones son revisiones ms formales donde revisores usan listas de cheque
o
(checklists) para estimular la revisin y recurren a registros de control y
retroalimentacin sistemtica para mejorar el proceso de desarrollo.
Prueba
La prueba es medio ms comn de asegurar la calidad. Es el ejercicio sistemtico de
buscar y detectar defectos donde lo fueron hallados anteriormente. Conducidos e
nivel
de unidad y de sistema, sirven para verificar la funcionalidad y calidad del sis
tema.
5.3.3.2. Tiempo y coste
a. Proceso de control del proyecto
El propsito del control del proyecto es:
-
Mantener el proyecto en curso y cercano al plan de trabajo;
-Identificar problemas antes de que ocurran; e,
-Implementar planes de recuperacin antes que los daos sean irreparables.
El proceso involucra comparar el progreso con el plan y tomar acciones correctiv
as
conforme existan desviaciones que afecten el desempeo y/o el plan; y proveer
retroalimentacin (figura 5.17).
Figura 5.17: Control del proyecto.
Para un control a tiempo y efectivo, el gestor del proyecto debe tener completa
visibilidad del avance del proyecto. Para ello, se debe efectuar un monitoreo y
seguimiento sistemtico. El grado de formalidad y frecuencia de monitoreo depende
del
tipo de proyecto, aunque siempre debe enfocarse en el coste, programacin y
desempeo tcnico.
b. Control del coste y del programa
El seguimiento del coste y de la programacin involucra comparar el estado actual
contra lo presupuestado en cuanto coste, tiempo y etapas.
Desviaciones significativas del plan requieren atencin prioritaria del gestor del
proyecto
para tomar una accin correctiva a tiempo. Conocer la desviacin no es suficiente, h
ay
que identificar la causa del problema. Si la desviacin del plan es grande, se deb
e decidir
si se replanifica.
Para tener visibilidad de estas decisiones, el coste y la programacin son analiza
dos de
forma integrada. Estar dentro del presupuesto no es suficiente si las tareas no
se
completan a tiempo. Similarmente, completar tareas de acuerdo al programa no bas
ta si
los costes se han disparado. En este anlisis, disponer de la WBS provee la base
fundamental para comparar coste y programa contra el plan.
c. Valor ganado
Aunque las cartas GANTT y los informes de acumulacin de reportes proveen
indicadores tiles del estado del proyecto, presentan limitaciones. La limitacin pr
imaria
es que son complejos y difciles de analizar, particularmente para grandes proyect
os con
muchas tareas. Esta complejidad puede conducir a una percepcin distorsionada del
estado del proyecto. Una tcnica para proveer una mejor, ms holstica visin del
progreso del proyecto es la tcnica del valor ganado (Earned Value Technique).
Originalmente creada para un mejor seguimiento de proyectos gubernamentales a gr
an
escala, es hoy en da herramienta habitual en los proyectos informticos.
La tcnica mide el valor del trabajo realizado en trminos del presupuesto asignado
al
trabajo. Permite separar las variaciones de coste y programacin en trminos
monetarios.
La variacin en coste se debe a la variacin en el precio del trabajo realizado mien
tras la
variacin en la programacin se debe al trabajo realizado fuera de los tiempos
programados.
El valor ganado y las variaciones son calculadas para una actividad simple, un g
rupo de
actividades o el proyecto completo. De las variaciones de coste y programacin es
posible determinar indicadores de desempeo de coste y programacin del proyecto.
Estos ndices proveen visibilidad instantnea sobre el desempeo del proyecto. Esto
ayuda al gestor del proyecto a estimar el coste para terminar y el coste actual
a la
fecha, basado en el desempeo a la fecha.
La tcnica se basa en tres parmetros bsicos:

Presupuesto planeado (planned budget): coste presupuestado de trabajo planificad
o
(budgeted cost of work scheduled, BCWS).

Coste actual: coste actual de trabajo realizado (actual cost for work performed,

ACWP).

Valor ganado (earned value): Coste presupuestado de trabajo realizado (budgeted
cost for work performed, BCWP).
Variacin del coste (cost variance, CV) se calcula de la siguiente manera:
CV = BCWP - ACWP
Una variante negativa indica un coste excesivo.
Variacin de la programacin (schedule variance, CV) se calcula de la siguiente mane
ra:
SV = BCWP BCWS
Una varianza negativa indica que el proyecto esta fuera de programacin. Ambas
varianzas son expresadas en trminos monetarios, pero tambin pueden expresarse en
porcentajes de la siguiente manera:
% CV = CV / BCWP
% SV = SV / BCWP
El ndice de desempeo de coste (cost performance index, CPI) est calculado como:
CPI = BCWP / ACWP
El CPI puede usarse para calcular el coste del proyecto o el coste estimado al
completarlo (estimate at completion, EAC). Una frmula simplificada para EAC es:
EAC = BAC /CPI
Donde BAC (budgeted cost at completion) es el coste bsico o presupuestado para
terminar el proyecto.
Similarmente, es posible calcular el ndice de desempeo de la programacin (schedule
performance index, SPI) de la siguiente manera:
SPI = BCWP / BCWS
Por ltimo, una versin simplificada para estimar la duracin del proyecto o tiempo
estimado para terminar el proyecto (estimated time to completion, ETC) se puede
calcular de la siguiente manera:
ETC = OD / SPI
Donde OD es la duracin original (original duration, OD).
d. Revisin
1. Encuentros de revisin.
Encuentros de revisin son instrumentos vitales en el control del proyecto. El
propsito es valorizar el progreso e identificar reas de desviacin desde el plan
para proponer acciones correctivas. Los encuentros son el mecanismo para
discutir abiertamente problemas presentes y futuros y proveer un marco de
comunicacin habitual, si se desea.
Los encuentros:
-Proveen visibilidad a los planes y su progreso, y crean oportunidades para
obtener y reforzar compromisos con los participantes.
-Son ms efectivos cuando ellos son programados a intervalos regulares
(semanalmente es lo habitual) y siguiendo una agenda establecida y
acordada por los involucrados.
-Deberan contar con la presencia de personas representativas de las reas
involucradas para tener respuestas adecuadas, negociar soluciones y hacer
compromisos.
-Son diferentes de una revisin tcnicas y/o de calidad, donde se dedica
especial atencin a detectar y corregir problemas ms que revisar el
progreso.
-Son diferentes de una reunin de gestin o de direccin, donde el gestor de
proyecto se rene con un directivo o un comit de direccin, para informar
del proyecto y su integracin en la estrategia organizacional.
2. Informes de estado.
Los informes de estado son preparados y enviados de forma regular para
informar a las personas externas a la organizacin. Ellos deben ser cortos y
oportunos.
3. Agenda del proyecto.
Una agenda tpica incluye:
-Detalle del progreso programado (principales hitos, programa y costes);
-Avance de actividades especficas;
-Estado de determinados tems y/o recursos;
-Planificacin futura; y,
-Estado de las reas de alto riesgo.
4.
Informe de alcance e informe de realizacin.
Es conveniente mantener actualizado el informe del alcance con el fin de
mostrar los cambios al plan del proyecto. Las nuevas versiones del informe de
alcance deben ser mantenidas en la biblioteca del proyecto y los cambios y
alteraciones ser gestionadas de manera adecuada e informadas a las personas
pertinentes afectadas.
Aparte y vinculados al informe de alcance estn los Informes de Realizacin, los
cuales organizan y resumen la informacin reunida a lo largo del proyecto y
presentar resultados de cualquier anlisis. Estos informes deben proporcionar
los tipos de informacin y nivel de detalle requerido por las distintas entidades
involucradas, tal y como establece el Plan de Comunicaciones.
5.3.3.3. Desempeo y evaluacin
a. Control de desempeo tcnico
El control del desempeo tcnico es el proceso de asegurar que todos los
requerimientos son satisfechos a travs de revisiones de diseo.
1.
Revisiones tcnicas.
Estas revisiones son usualmente mantenidas en los principales hitos (por
ejemplo, al trmino de las fases del ciclo de vida) pero pueden hacerse en otros
instantes. El propsito de estas revisiones es mostrar el logro actual o predecir
objetivos tcnicos potenciales. El progreso de los objetivos tcnicos debera
hacerse con mtricas apropiadas. Una prctica til de contar con
representantes de los clientes en las revisiones tcnicas para asegurar criterios
comunes de las necesidades y evitar sorpresas futuras.
2.
Mtricas.
Las mtricas proveen visibilidad de lo conseguido y sus tendencias ofrecen un
medio predictivo para actuacin futura. Ellas deben estar basadas en normas y
estndares, esencialmente cuantitativas, adems de acordadas entre las partes.
b. Cambio y control de la configuracin
El control del cambio es un concepto simple, pero complejo en su detalle. An el
requerimiento mejor preparado requiere cambios, especialmente cuando de software
se
trata, una vez se disea y se prueba.
Muchos proyectos fallan por cambios incontrolados que van ms all de los
requerimientos definidos inicialmente o acordados previamente. En varios casos
conducen a situaciones de escalada. Para ayudar a la deteccin y seguimiento del
cambio es esencial contar con un sistema de control de cambios que incluya
herramientas automatizadas, y un ncleo de gestin del cambio o grupo de control de
cambios.
Un sistema de control de cambios es un conjunto de procedimientos documentados y

formales que definen los pasos a seguir para realizar cambios en los documentos
oficiales del proyecto. Incluye formularios, sistemas de seguimiento y los nivel
es de
aprobacin necesarios para autorizar los cambios.
En muchos casos, la organizacin ejecutora tendr un sistema de control de cambios
que podr utilizarse tal cual para el proyecto. Sin embargo, si no tienen disponib
le un
sistema adecuado, el equipo de direccin del proyecto necesitar desarrollar uno com
o
parte del proyecto.
Un proceso de cambio comienza con un requerimiento de cambio, conocido en
ocasiones como una Propuesta de Cambio de Ingeniera (PCI, Engineering Change
Proposal, ECP), que identifica la necesidad de cambio, la naturaleza del cambio
y el
impacto del cambio. Este cambio se remite al ncleo de gestin del cambio para que s
ea
revisado y se disponga su aprobacin o no (figura 5.18).
Figura 5.18: Proceso de control de cambios.
Los poderes y responsabilidades de dicho grupo deben estar bien definidos y acor
dados
por las principales entidades involucradas en el proyecto. El ncleo, usualmente b
ajo
responsabilidad del gestor del proyecto o su designado se compone de representan
tes
de cada rea afectada por el desarrollo. Este equipo se disea para que todas las pa
rtes
comprendan las consecuencias del cambio antes de hacerlas. En proyectos grandes
y
complejos puede haber mltiples grupos de control de cambios con diferentes
responsabilidades.
Despus de una revisin, el ncleo asegura que slo los cambios aprobados sean
realizados de manera controlada y notificados a todas las partes involucradas.
El sistema de control de cambios debe incluir tambin procedimientos para realizar

cambios que pueden ser aprobados sin una revisin previa, por ejemplo, como result
ado
de emergencias. Generalmente, un sistema de control de cambios permitir la
aceptacin automtica de determinados tipos de cambios. Estos cambios deben ser
documentados y organizados de forma que no causen posteriormente problemas en el

proyecto.
c. Evaluacin del proyecto
La evaluacin del proyecto es el proceso de valorizar peridicamente del estado del
proyecto con relacin a sus objetivos. Esto difiere del control del proyecto en do
s
aspectos:
El control del proyecto es responsabilidad del gestor del proyecto, la evaluacin
es
tarea de la direccin.
El control del proyecto es un proceso continuo, mientras la evaluacin es peridica.

Las evaluaciones tpicamente son realizadas en hitos importantes para determinar
cuando cambios mayores han surgido. Estos cambios pueden incluir re-valorizacin d
e
metas y objetivos, re-estructuracin del plan o, an mas, cancelacin del proyecto.
Por ltimo, la evaluacin del proyecto juega un rol importante en la complexin del
proyecto. En este caso, evala experiencia pasada y desarrolla las lecciones apren
didas
para beneficio de futuros proyectos.
5.3.3.4. Recursos humanos
a. Motivacin y construccin del equipo
El desarrollo y construccin del equipo es una labor cubierta por literatura de ci
encias y
gestin del comportamiento (comportamiento organizacional, psicologa social) pero a

menudo es muy ignorada en ambientes de desarrollo informtico.
Muchos gestores de proyectos tienden a enfocar su atencin en los detalles tcnicos,

ignorando que son personas las que programan y son personas las que usarn una
aplicacin computacional.
Pensar as hoy en da es un gran riesgo, pues muchos proyectos fallan por mal
funcionamiento del equipo y no por problemas tcnicos. Las personas saben su traba
jo,
lo que saben es compartir con otros, especialmente por prestar poca atencin a las

personas y los grupos.
La construccin del equipo es el proceso de transformar un grupo de individuos de
diferentes orgenes y formaciones en un grupo cohesivo de alto desempeo, con una
alta motivacin y enfocados al logro de objetivos.
Es un proceso que requiere habilidades de liderazgo y una comprensin de los diver
sos
factores organizacionales que influyen en el trabajo en equipo y en las relacion
es
humanas.
As es necesario:

Compartir la visin y el objetivo. Una visin compartida es esencial para el xito del

proyecto, de hecho se le considera un factor de xito. Estar de acuerdo en la visin

y en los objetivos ayuda a mantener el equipo centrado y productivo. En estos
casos, la toma de decisiones es ms efectiva y se evitan debates efmeros y que
slo consumen tiempo.

Compromiso con el proyecto. El compromiso puede definirse como el sentido de
lealtad y dedicacin al proyecto. Miembros comprometidos desean dedicar su
tiempo y energa y hacer sacrificios personales por el proyecto. La visin
compartida es la base del compromiso. Slo cuando las personas comprenden y
comparten una visin del proyecto, desean comprometerse con el proyecto.
Gestores efectivos, trabajan duro para construir y afianzar el compromiso. Busca
n
vas de crear posibilidades excitantes de conseguir un proyecto exitoso. Crean
ambientes de trabajo estimulantes, generando retos de trabajo interesantes con
oportunidades de crecimiento personal. Involucran a las personas en la toma de
decisiones. Hacen visible el esfuerzo de cada persona informando del progreso a
cada miembro. Convierten a cada miembro en un activo del proyecto.

Fuerte sentido de identidad. Miembro de equipos efectivos sienten que son
especiales, diferentes de otros. Esta sentimiento de identidad el gestor de
proyectos debe reforzarlo por todos sus medios a mano. Una prctica comn es
usar smbolos visibles para mostrar la identidad (distintivos en la ropa, las taza
s de
caf, etc.) Probablemente la mejor manera es crear un sitio donde los miembros
compartan su trabajo. Hitos de celebracin, o la pizza con cerveza, son momentos
de reforzar el espritu. Gestores exitosos crear y definen culturas en sus proyect
os,
distintas del resto de la organizacin.

Confianza mutua. Un equipo efectivo requiere colaboracin entre los miembros. La
colaboracin existe en climas de confianza. A mayor confianza, el equipo
compartir mayor informacin, informar problemas y tomar decisiones efectivas.
Buenos gestores de proyecto crear y nutren una atmsfera de confianza que a su
vez construye y refuerza la confidencialidad y el compromiso. La confianza
solamente existe en equipos hay valores de honestidad y franqueza, donde las
personas son tratadas con imparcialidad, respecto y dignidad.

Miembros competentes. Gestores de proyecto efectivos reclutan personas
competentes, segn las competencias que requiera el proyecto. En este sentido no
deben olvidarse que las habilidades de colaboracin para el trabajo efectivo con
otras personas son tan importantes que las habilidades y destrezas tcnicas.
Un gestor efectivo continuamente evala a su equipo y siempre est dispuesto a
cambiar o reasignar personas con un desempeo inadecuado. Los gestores de
proyecto gestionan relaciones con el resto de la organizacin y remueven
obstculos. Los miembros se motivan cuando ellos saben que la direccin est
comprometida con el proyecto y busca y provee los recursos necesarios. Todo esto

requiere habilidades de gestin superiores a las tcnicas, que incluso pueden
carecer y/o desarrollar con el tiempo.
Entre las habilidades para construir un equipo, se cuenta:
-
Evitar comprometer los objetivos del equipo con intereses polticos.
-
Exhibir un compromiso personal a los objetivos del equipo.
-
No diluir el esfuerzo del equipo con muchas prioridades.
-
Ser equitativo e imparcial con todos los miembros.
-Estar predispuesto a enfrentar y resolver problemas asociados con el desempeo
inadecuado de miembros del equipo.
-Estar abierto a nuevas ideas e informacin proveniente de los miembros del
equipo.
b. Resolucin de conflictos
Los conflictos son parte de la vida diaria del proyecto. Ellos surgen desde cual
quier
involucrado en el proyecto, tanto puede ser de un miembro del equipo como de un
cliente o promotor. De hecho, la fuente de conflictos es abundante. La fuente ms
comn es la competencia por los recursos escasos, las diferencias respecto de los
objetivos y los medios para conseguirlos, y desacuerdos en costes, programacin y
tecnicismos. Por supuesto deben aadirse los conflictos que surgen de la relacione
s
interpersonales. Independiente de las causas, todo conflicto debe tratarse, iden
tificando
sus motivos y orgenes, comprender sus causas y resolverlos de manera rpida. Fallar
al
hacer esto puede seriamente alterar el proyecto y generar atrasos y gastos exces
ivos.
5.3.4. Cierre
El cierre comprende dos procesos y, segn el tamao del proyecto, el volumen de
informacin manejado y/o el grado de desorden sostenido, el cierre puede ser tan
complejo y extensivo que puede considerarse un proyecto. Adems, en un proyecto e-
business cobra importancia el hecho que el cierre es una etapa de recomendacin y
evaluacin de lo aprendido.
5.3.4.1. Cierre administrativo
El proyecto o fase, despus de lograr sus objetivos o estar terminado por otras ra
zones,
requiere su cierre. El cierre administrativo consiste en la verificacin y documen
tacin
de los resultados del proyecto para formalizar la aceptacin del producto del proy
ecto
por parte de los patrocinadores o clientes.
El cierre incluye la recopilacin de todos los registros del proyecto, asegurando
que
reflejan las especificaciones finales, as como el anlisis del xito y la efectividad
del
proyecto y el archivo de esta informacin para su uso futuro. De hecho es importan
te
aprovechar esta informacin para promover un aprendizaje. Esto ltimo no puede
hacerse sin hacer una reflexin del trabajo realizado para ver cunto se ha aprendid
o,
qu se pudo haber aprendido, el porqu de lo errores, etc. Adems es importante
conseguir las aprobaciones finales del trabajo realizado y del producto entregad
o.
Es importante hacer notar que las actividades de cierre administrativo no deben
retrasarse hasta la terminacin del proyecto. Cada fase del proyecto debe ser
apropiadamente cerrada para asegurar que no se pierde informacin til e importante.

5.3.4.2. Cierre de contratos
Es similar al cierre administrativo. Comprende la verificacin del producto (estaba
todo
el trabajo realizado de forma completa, correcta y satisfactoria?) y el cierre
administrativo (actualizacin de registros para reflejar los resultados finales y
el archivo
de dicha informacin para su disponibilidad futura).
Los trminos y condiciones del contrato pueden establecer unos procedimientos
especficos para el cierre del contrato. Una terminacin temprana del contrato es un

caso especial de cierre del contrato.
5.4. MODELOS DE MADUREZ DE GESTIN DE PROYECTOS
La gestin de proyectos habitualmente se espera sea aplicada a cabalidad luego de
leer
un manual o sencillamente asistir a un curso. No obstante, en este sentido, desd
e el
rea de gestin de proyectos, se ha planteado que las prcticas de gestin han de
usarse segn las competencias que requiera un proyectista conforme madura en su
experiencia en gestin de proyectos. En este sentido se han presentado en la liter
atura
modelos llamados modelos de madurez de gestin de proyectos, cuyo fin es proveer u
n
marco que permita reconocer qu tipo de competencia se requiere en diferentes esta
dos
de madurez en gestin de proyectos.
Un modelo de madurez de gestin de proyectos, en el rea de Proyectos, aglutina y
organiza en niveles de madurez un conjunto de criterios de gestin con el fin de o
rientar
las actuaciones de los proyectistas. Estos niveles, segn Ward, aparte de regular
las
competencias necesarias conforme el gestor de proyectos aprende y asimila, actan
en
s mismos como metas a conseguir por las organizaciones desde el punto de vista de
la
calidad de su gestin de proyectos.
La literatura muestra que todos estos modelos de madurez han surgido o se basan
directamente en el Capability Maturity Model del Software Engineering Institute
(SEI) en
Estados Unidos.
A continuacin se presentar el CMM para luego pasar a revisar algunos modelos de
madurez en gestin de proyectos.
5.4.1. Capability Maturity Model
Para Paulk et al., el CMM es un marco que representa recomendaciones para
organizaciones de software que desean mejorar la calidad y capacidad de sus proc
esos
de software. En este sentido, el CMM describe las prcticas de ingeniera de softwar
e y
de gestin que caracterizan a las organizaciones conforme mejora (madura) su proce
so
para desarrollar y mantener software.
Se aade en particular que un proceso de software se puede definir como un conjunt
o
de actividades, mtodos, prcticas, y transformaciones que las personas usan para
desarrollar y mantener software y los productos asociados.
5.4.1.1. Niveles de madurez
La mencionada madurez se valoriza en funcin de cinco niveles de madurez.
Un nivel de madurez es una plataforma en el camino de conseguir una mejora en un

proceso de software. Cada nivel de madurez considera un conjunto de objetivos de

procesos que una vez satisfechos estabilizan una componente del proceso de softw
are.
A continuacin se describe cada uno de los niveles de madurez del CMM.

Inicial. En este nivel el proceso de software es ad-hoc y ocasionalmente catico.
Pocos procesos son definidos y el xito depende del esfuerzo y heroicidad de los
individuos.

Repetible. En este nivel se establecen procesos de gestin de proyectos bsicos
para hacer seguimiento del coste, la programacin y la funcionalidad.

Definido. En este nivel las actividades de gestin e ingeniera del proceso de
software son estandarizadas y documentadas en uno o varios procesos de
software estndar para la organizacin.

Gestionado. Mediciones detalladas del proceso de software y calidad del producto

son registradas. En este nivel, el proceso y el producto de software son
cuantitativamente comprendidos y controlados.

Optimizante. En este nivel se habilita la mejora continua del proceso.
5.4.1.2. Arquitectura por niveles
A su vez, los niveles de madurez se componen de reas de proceso claves (Key Proce
ss
Areas), que contienen prcticas clave (Key Practices) organizadas a su vez en rasg
os
comunes (Common Features).
Las Key Practices Areas (KPA) indican las reas en que una organizacin debera
concentrarse para mejorar su proceso de software.
Las Common Features (CF) son un conjunto de prcticas agrupadas dentro de un
rea clave o necesidad.
Las
Key Practices (KP) son las actividades e infraestructura que contribuye de
manera ms efectiva a la implementacin e institucionalizacin de cada rea clave.
5.4.1.3. La madurez por temas
El carcter organizador del CMM ha lugar a toda una serie de variaciones ligadas a
l
desarrollo de software como un producto. Por ejemplo, la versin de CMM para la
adquisicin de software5, o aplicaciones ms concretas acerca de cmo mejorar la
capacidad de gestin del conocimiento que sugieren Baskerville y Pries-Heje.
No obstante el CMM presenta una peculiaridad que requiere ser mejorada segn el
contexto de este trabajo. El CMM describe la madurez por niveles y plantea un ca
mino
para conseguirlas. Sin embargo, como modelo es un patrn que plantea lo que hay qu
e
medir por nivel, no distinguiendo si existen mejoras parciales. Como instrumento
de
medicin posee un carcter excesivamente evaluativo ms que formativo y, adems,
deja a las organizaciones sin capacidad de mejoras parciales por temas, por proc
esos
crticos o ms robustos.
SPICE es un modelo de madurez de origen europeo similar al CMM, pero con la
diferencia que las mejoras de capacidad del proceso se pueden conseguir por tema
s o
reas. Por ejemplo, se puede alcanzar un nivel dos en documentacin y un nivel tres
en
el uso de mtricas. Esta ltima cualidad es considerada en muchos de los modelos de
madurez de proyectos que a continuacin se presentan.
5.4.2. Modelos de madurez
Del rea de gestin de proyectos se han considerado en este estudio los siguientes
modelos de madurez de proyectos, por su relevancia, impacto y presencia:
Trillium model,
Project Management Assessment,
Management Maturity Model, y
Innovation Maturity Model.
5.4.2.1. Trillium model
El modelo Trillium es un producto usado por Bell Canad para dar valor al desarrol
lo de
un producto y apoyar las capacidades de proveedores de telecomunicaciones o
productos basados en tecnologas de la informacin existentes o futuros. El modelo h
a
5.
Fuente: Software Acquisition Capability Maturity Model. Enlace web: http://www.s
ei.cmu.edu/arm/SA-CMM.html
[Ledo: 12 de abril del 2001].
sido diseado para ser aplicado a sistemas de software empotrados tales como
sistemas de telecomunicaciones, no obstante buena parte del modelo puede ser
aplicado a otros segmentos de la industria del software como sera el rea de
Management Information Systems. Con respecto al CMM, el modelo Trillium, se
distingue en que:
-Define roadmaps en lugar de reas clave.
-Tiene una perspectiva orientada al producto, hacindolo ms general y de amplio
uso;
-Da amplia cobertura a los aspectos que inciden o impactan en la capacidad del
proceso; y,
-Se enfoca al cliente en lugar del desarrollo mismo.
Esto consigue que se definan prcticas que guan al proyectista sobre cmo conseguir l
o
que desea un usuario/cliente donde, en lugar de sealar determinadas metas que se
deben alcanzar con ciertas prcticas de diseo, se buscan aquellas prcticas que
habiliten la consecucin de lo que desea el usuario.
a. Niveles de madurez
A semejanza del modelo CMM, el modelo Trillium presenta una escala de cinco nive
les
de madurez:
1.
Nivel 1 Desestructurado. En este nivel el proceso de desarrollo es ad-hoc. Los
proyectos frecuentemente no pueden satisfacer objetivos de calidad o de
programacin. El xito posible se basa ms en el trabajo de los individuos que
en la propia estructura e infraestructura organizacional.
2.
Nivel 2 Repetible y orientado al proyecto. El xito individual del proyecto se
consigue a travs de una frrea planificacin y control de gestin del proyecto,
dando especial nfasis a los requerimientos de gestin, tcnicas de estimacin
y configuracin del cambio.
3.
Nivel 3 Definido y orientado al proceso. Aqu los procesos son definidos y
utilizados al nivel organizacional, no obstante se acepta que el proyecto sea
adaptado a las circunstancias. Los procesos son controlados y mejorados. Se
incorporan requerimientos ISO 9001, como procesos de entrenamiento y
auditora interna.
4.
Nivel 4 Gestionado e integrado. La monitorizacin y anlisis del proceso son
usados como mecanismos clave en la mejora. Procesos de gestin del cambio y
programas de prevencin de defectos son integrados. Las herramientas CASE
se integran dentro del proceso.
5.
Nivel 5 Completamente integrado. Metodologas formales son extensivamente
usadas. Repositorios organizacionales son usados para soportar y mantener la
historia del proceso de desarrollo.
b. Arquitectura del modelo
La arquitectura de Trillium igualmente plantea una descomposicin pero con una
diferencia sustancial con el CMM: no se comienza la descomposicin desde los nivel
es
de madurez, sino desde ocho reas de capacidad (Capability reas), cada una de las
cuales contiene varias roadmaps y estos ltimos a su vez contienen prcticas
(Practices), usados paulatinamente por niveles de madurez (figura 5.19)6.
Figura 5.19: Arquitectura del modelo Trillium.
De esta forma, la arquitectura de Trillium se caracteriza por poseer:
6.
Fuente: Recurso pblico de Trillium, Model Description. Enlace web:http://www.sqi.
gu.edu.au/trillium/t3modc3.html

Capability Areas: ocho reas centrales de preocupacin o prioritarias para el modelo

Trillium, cada una de las cuales se encuentra contenida por prcticas;

Roadmaps: conjunto de prcticas relacionadas, enfocadas sobre un rea o
necesidad organizacional, o un elemento especfico, dentro del proceso de
desarrollo del producto; y,

Practices: acciones a desarrollar para conseguir una mejor capacidad del proceso
,
cada una de las cuales se vincula a un nivel de madurez.
La tabla 5.7 detalla la relacin entre los elementos de la arquitectura7 .
TRILLIUM CAPABILITY AREAS ROADMAPS
# OF PRACTICES BY
LEVEL TOTAL
2 3 4 5
Organizational Process Quality
Quality Management
Business Process Engineering
10 20 5 0 35
Human Resource Development and
Management
Human Resource Development and
Management
9 42 1 0 52
Process
Process Definition
Technology Management
Process Improvement & Engineering
Measurements
16 55 24 4 99
Management
Project Management
Subcontractor Management
Customer-Supplier Relationship
Requirements Management
Estimation
74 29 4 0 107
Quality Systems Quality System 14 15 2 2 33
Development practices
Development Process
Development Techniques
Internal Documentation
Verification & Validation
Configuration Management
Re-Use
Reliability Management
41 49 15 5 110
Development Environment Development Environment 4 6 1 1 12
Customer Support
Problem Response System
Usability Engineering
Life-Cycle Cost Modelling
User Documentation
Customer Engineering
User Training
25 30 5 0 60
Total 193 246 57 12 508
Tabla 5.7. Arquitectura del modelo Trillium.
7.
Fuente: Recurso pblico de Trillium, Model Description. Enlace web: http://www.sqi
.gu.edu.au/trillium/t3modc3.html
[Ledo: el 12 de abril del 2001].
5.4.2.2. Project Management Assessment
El Project Management Assessment 2000 (PMA) es una metodologa holstica y una
herramienta de software para la mejora de procesos de gestin en un medio ambiente

de gestin de proyectos. Se ofrece para dar soluciones a problemas de inflexibilid
ad, de
tiempo, de no saber hacer y, de falta de una mejora incremental.
Para Lubianiker, es un modelo donde deben integrarse prcticas genricas
(herramientas, procedimientos y estndares comunes al mbito de gestin de proyectos
tomados del PMBOK) y especficas de la propia organizacin, para lo cual se cuenta c
on
un software.
El software es un producto orientado a definir y especificar prcticas genricas tom
adas
del PMBOK y otras especficas de cada problema y unirlas siguiendo el esquema de
prcticas que ofrece el mismo PMBOK.
5.4.2.3. Project Management Maturity Model
El Management Maturity Model (PM3) se orienta a mejorar prcticas de gestin de
proyectos. Es un esfuerzo derivado de considerar la gestin de proyectos un proces
o
crtico de la misin organizacional y de competencia vital a la organizacin.
El modelo se ha construido a partir de encuestas a organizaciones que han llevad
o,
obviamente, proyectos, buscando definir las prcticas de gestin que aplicaban. Segn
la ltima informacin disponible, el modelo se ha modificado hasta alcanzar unas 300

lecciones sobre gestin de proyectos en el mbito corporativo.
Estas prcticas se han organizado en niveles de madurez. De estos niveles: ad-hoc,

abreviado, organizado, gestionado y adaptativo; se conocen 51 preguntas que perm
iten
saber el nivel de una organizacin.
5.4.2.4. Innovation Maturity Model
El Innovation Maturity Model (IMM) no es un modelo como tal, sino una propuesta
para
el desarrollo de productos. Es una visin sobre cinco niveles de innovacin: superfi
cial
(Superficial), mejoras en rasgos (Feature Enhancements), mejoras en soluciones
(Solution Enhancements), soluciones impactantes (Breakthrough Solutions) y
'rompedora' (disruptive).
5.4.3. Implantacin de la madurez
Todos los modelos previos de una u otra manera buscan medir o alcanzar un
determinado nivel de competencia en gestin de proyectos. Conseguir esta
competencia requiere algunas precisiones de mayor detalle.
Niveles de madurez
En cuanto a detalle, Peterson propone un modelo de madurez basado directamente e
n el
PMBOK de ocho niveles de madurez, cuya cantidad solamente se justifica en la med
ida
de conseguir una competencia paulatina incremental y ms gradual.
A grandes rasgos, tales niveles se caracterizan por lo siguiente:

Nivel I No conocedor (non-awareness). No existe conocimiento alguno sobre
gestin de proyectos.

Nivel II Inicial. Se comienzan a introducir prcticas de gestin de proyectos.

Nivel III Bsico. Comienzan algunas tareas de gestin como asignacin de
responsabilidades, documentacin, hitos y manejo formal de informacin.

Nivel IV Repetible. Se establecen algunos procesos de gestin y se formaliza el us
o
de determinadas herramientas. Ya existe algn plan de entrenamiento en gestin de
proyectos y se llevan algunas auditoras.

Nivel V Avanzado. El entrenamiento y, las auditoras o seguimientos, son totales,
igualmente algunos procesos y herramientas son incorporados en su totalidad.

Nivel VI Bien-definido. Los niveles de autoridad y experiencia son completos, el

entrenamiento es avanzado, los procesos se integran introducindola
documentacin y el uso de mtricas.

Nivel VII Gestionado. Se promueven los incentivos, se introduce la certificacin e
n
gestin de proyectos. Se persigue un buen desempeo y mejorar la eficiencia y
efectividad.

Nivel VIII Optimizante. La mejora es continuada y sostenible.
Lo importante de esta propuesta es el Nivel VIII, al dejar explcito que alcanzar
los
niveles de madurez no es un fin en s mismo, sino un medio para garantizar una mej
ora
adaptativa y sostenida a lo largo del tiempo.
Implantacin
Respecto de la consecucin de la competencia, White seala que una manera de
introducir tcnicas de gestin que satisfagan los niveles de madurez del CMM es
siguiendo ciclos iterativos.
En este sentido, White propone un mecanismo para sensibilizar a los proyectistas
en la
conveniencia de aprender a mejorar.
Para ello White seala que se deben seguir ciclos de mejora de forma paulatina, po
r
ejemplo, comenzar con un ciclo As-Is donde se presentan las primeras prcticas de
gestin, pasando luego a un ciclo de actualizacin de procesos e infraestructura par
a
alcanzar un nivel 2 y as, ejecutar un tercer ciclo orientado a conseguir el nivel
3 del
CMM (figura 5.20).
Figura 5.20: Implantacin gradual.
6. CONCLUSIONES
Despus de leer este captulo se pretende que el proyectista tenga los suficientes
conocimientos para aventurarse en la realizacin de un proyecto como director de st
e,
no sin tener por ello dificultades en este difcil compromiso, aunque, eso s, esta
lectura
le facilitar su trabajo, podr estructurar el proyecto de la mejor manera posible,
siempre
teniendo en cuenta las diferentes fases que se suceden hasta completar el proyec
to,
con la mayor exactitud posible en el cumpliendo de todos los objetivos y con un
control
peridico sobre los aspectos ms relevantes, as como una buena gestin de recursos.
Esperemos que esta gua sea til y de agradable lectura, y no slo queremos animar a
los futuros directores de proyectos sino tambin a aquellos que ya tienen experien
cia y
quieren complementarla para desenvolverse mejor en su nuevo reto. nimo!.
Puntos a destacar
1.
La nocin de gestin de proyectos depende de la nocin de proyecto que se tenga.
2.
El PMBOK permite conocer y comprender los elementos relevantes y suficientes par
a una completa
gestin de proyectos, con la salvedad que los procesos, tcnicas y herramientas iden
tificadas deben
usarse a conciencia y criterio de cada gestor, pudiendo eliminarles, modificarle
s o aadir nuevas.
3.
El PMBOK describe los procesos de gestin de proyectos segn un rea de conocimiento y
un grupo
de procesos.
4.
El esquema organizativo de procesos de gestin de proyectos ofrecido por el PMBOK
es un marco de
referencia bsico sobre el cual construir una gestin de proyectos adecuada a un pro
yecto
informtico.
5.
La gestin de proyectos permite una actuacin predictiva para evitar y resolver pote
nciales
problemas y recuperar el proyecto en tiempo de ejecucin.
6.
Las tcnicas y herramientas de gestin no son privativas de un proceso, sino que son
instrumentos a
usar a criterio del gestor.
7.
La gestin de proyectos es un proceso de aprendizaje. Los modelos de madurez de ge
stin de
proyectos constituyen un medio para aplicar prcticas de gestin de proyectos de man
era paulatina y
gradual, conforme se adquiera mayor competencia y habilidad en su uso gracias a
la propia
experiencia.
8.
Un modelo de madurez es un medio vlido para mejorar la calidad de la gestin en pro
yectos.
Resumen
ANEXO
ANEXO
1. SISTEMA DE LA CALIDAD (ISO 9000-9004)
La competitividad de cualquier empresa en el mercado internacional est ntimamente
relacionada con la calidad de su oferta y debido a una oferta cada vez ms excesiv
a en
el mercado el cliente es ms exigente y selectivo en todo lo relativo a la calidad
de
productos y servicios. Por otro lado los requisitos legales de los distintos pase
s son
cada vez ms estrictos, tratando de proteger a sus ciudadanos, usuarios y
consumidores finales de dichos productos y servicios.
Por ello, la normativa de la calidad se ha desarrollado muy rpidamente en los ltim
os
aos, a nivel internacional, a la vez que se ha difundido muy rpidamente. Se ha
convertido en un elemento de uso habitual. En 1987 la International Standards
Organization (ISO) public un paquete de normas, conocidas coloquialmente como ISO
9000,
integradas por las siguientes:
ISO-9000: Normas para la gestin de la calidad y el aseguramiento de la
calidad. Directrices para su seleccin y utilizacin.
ISO-9001: Sistemas de la calidad. Modelo para el aseguramiento de la calidad
en el diseo/desarrollo, la produccin, la instalacin y el servicio post-venta.
en la produccin y la instalacin.
en la inspeccin y los ensayos finales.
ISO-9004: Gestin de la calidad y elementos de un sistema de calidad. Reglas
generales.
ANEXO
A continuacin en la tabla 1.1 se detallan las equivalencias entre estas normas
internacionales, las europeas del Comit Europeo de Normalizacin (CEN) y las
espaolas UNE editadas por la Asociacin Espaola de Normalizacin y Certificacin
(AENOR).
ISO CEN UNE
8402-1986 -66-001-0
9000 29.000 66-900
9001 29.001 66-901
9002 29.002 66-902
9003 29.003 66-903
9004 29.004 66-904
Tabla 1.1. Equivalencia entre normas de calidad.
La obtencin de la correspondiente certificacin, que acredita que una empresa dispo
ne
de un sistema que garantice y asegure la calidad de sus productos, supone una cl
ara
ventaja frente a otras empresas del mismo sector que no disponen de esta acredit
acin.
En 1994 se ha efectuado la primera revisin de la ISO-9000 incorporando
modificaciones y especialmente ampliaciones de las normas anteriores, as como nue
vas
normas-gua referentes a mejoras de la calidad, planes de la calidad y aseguramien
to de
la calidad en la direccin de proyectos.
La ISO 9000 ha originado cuatro normas diferentes: ISO 9000-1, ISO 9000-2, ISO
9000-3 e ISO 9000-4.
La ISO 9001 mantiene su estructura pero incorpora importantes ampliaciones. Igua
l
sucede con la ISO 9002 y la ISO 9003. Por su parte, la ISO 9004 ha originado sie
te
nuevas normas, numeradas ISO 9004-1 a ISO 9004-7.
La aplicacin de la serie ISO 9000 a empresas e industrias que no son estrictament
e de
fabricacin, sino ms exactamente de fabricacin en serie, presenta dificultades.
Est prevista una nueva revisin de toda esta serie, incluyendo la clarificacin de la
s
presentes dificultades para una correcta aplicacin a cualquier tipo de empresa u
organizacin sin las actuales ambigedades.
ANEXO
Otro avance de la nueva revisin es la eliminacin de equivalencias con normas
nacionales, como la UNE, o supranacionales como las CEN, utilizando un nmero
idntico para que la misma norma sea publicada por AENOR en Espaa (norma UNE),
por el CEN (Comit Europeo de Normalizacin) en Europa (normas EN) o por ISO
(International Standard Organization) a nivel mundial, con lo que desaparecen la
s tablas
de equivalencia del cuadro anterior.
El sistema de calidad afecta a todas las fases desde la identificacin inicial del
producto
o servicio hasta la satisfaccin final de los requisitos y expectativas del client
e. Estas
fases y actividades pueden incluir, en los casos ms complejos:
-Estudio e investigacin del mercado.
-Diseo/especificaciones de ingeniera y desarrollo del producto.
-Aprovisionamientos.
-Planificacin y desarrollo del proceso de produccin.
-Produccin.
-Inspeccin, ensayo y examen.
-Embalaje y almacenamiento.
-Venta y distribucin.
-Instalacin y funcionamiento.
-Asistencia tcnica y mantenimiento.
-Destino despus de la vida til.
Las personas responsables del aseguramiento de la calidad, tanto interna como
externamente, debern ser nombradas por la alta direccin, permanecer en dependencia

directa con ella y actuar por delegacin de la misma.
Si en la empresa se implanta un sistema de calidad se deber dotar, claro est, a to
dos
los restantes elementos de la empresa de los medios, tanto humanos como material
es,
compatibles con la calidad exigida.
Es importante establecer un plan de auditoras, para que verifique peridicamente el

buen funcionamiento del sistema de calidad y si encuentra deficiencias deber acom
eter
acciones correctoras para eliminarlas.
Con independencia de estas auditoras internas de la calidad, la direccin de la emp
resa
deber establecer revisiones y evaluaciones peridicas llevadas a cabo por miembros
de
la direccin o personal designado por ella.
ANEXO
1.1. EL PLAN DE CALIDAD DEL PROYECTO
De acuerdo textualmente con la ISO 9004, cualquier empresa que disponga de un pl
an
de calidad y acometa un nuevo proyecto definir:
1.
Los objetivos de la calidad que deben alcanzarse.
2.
La designacin especfica de autoridad y responsabilidad en las diferentes fases
del proyecto.
3.
Los mtodos, procedimientos e instrucciones de trabajo que deben aplicarse.
4.
Los programas de inspeccin, ensayo, examen y auditoras que deben aplicarse
en las etapas apropiadas.
5.
La metodologa para los cambios y modificaciones al propio plan de la calidad
segn lo requiera el proyecto.
6.
Otras medidas para alcanzar los objetivos previstos.
El plan de calidad no debe ser algo independiente o separado del propio proyecto
.
1.2. OBJETIVOS DE LA CALIDAD
Como mnimo se deber incluir:
-Anlisis del contenido: alcance y suficiencia de los datos precisos para realizar
el
proyecto.
-Control de la calidad de suministradores y subcontratistas.
-Anlisis de la normativa tcnica que se va a aplicar.
-Coordinacin del proyecto y sus documentos.
-Seguimiento y comprobacin de la programacin.
-Seguimiento y comprobacin del presupuesto.
1.3. AUTORIDAD Y RESPONSABILIDAD
La designacin de autoridad y responsabilidad, en las distintas fases del proyecto
, debe
ser coherente con la organizacin de la calidad dentro de la empresa y debe
establecerse en funcin de los niveles de calidad existentes, que como mnimo los qu
e
intervienen son los presentados a continuacin.
ANEXO

Nivel 1: secciones, departamentos y servicios: Los responsables asignados al
proyecto, en cada uno de los grupos de este nivel, son los encargados de:
-Verificar y aprobar los documentos generados.
-Verificar y aprobar los documentos de suministradores y subcontratistas.
-Verificar y aprobar la correcta aplicacin de la normativa tcnica.

Nivel 2: direccin del proyecto: el director del proyecto prestar especial atencin
a:
-El manual de coordinacin.
-El programa de desarrollo de los trabajos.
-La distribucin de la documentacin.
-El archivo de documentos.

Nivel 3: alta direccin de la empresa: es la mxima responsable del cumplimiento
del plan de calidad, a travs del jefe de garanta de calidad. El departamento de
garanta de calidad realiza auditoras para controlar el cumplimiento del plan y la
eficacia del sistema de garanta de calidad. Antes de iniciar la auditora es necesa
rio
establecer qu actividades van a ser auditables, de stas las ms frecuentes son la
toma de datos, normativa tcnica, verificacin de documentos y coordinacin
global. Las funciones del departamento de garanta de calidad son:
-
Establecer un programa de auditoras.
-
Ejecutar las auditoras.
Existen diversos tipos de auditoras: de evaluacin, de funcionamiento y de cierre:

Auditoras de evaluacin. Se realizan antes del comienzo de la actividad a fin de
comprobar su correcto planteamiento, la existencia de los controles precisos y e
l
cumplimiento de los requisitos necesarios para su desarrollo y ejecucin.

Auditoras de funcionamiento. A fin de comprobar, durante el desarrollo del
proyecto, la conformidad con los procedimientos, normas y controles aplicables.

Auditoras de cierre. Se realizan despus de terminar la actividad a fin de verifica
r la
adecuacin de los registros generados a los requerimientos exigidos por los
documentos contractuales y la normativa aplicable en lo que se refiere a la cali
dad.
ANEXO
1.4. MTODOS DE TRABAJO Y PROGRAMAS DE INSPECCIN
En el plan de calidad especfico de cada nuevo proyecto acometido se deber designar

qu mtodos de trabajo y programas de inspeccin para ese caso concreto se van a
utilizar.
1.5. METODOLOGA PARA CAMBIOS Y OTRAS MEDIDAS
No se puede presentar una metodologa comn para todos los tipos de proyectos. Se
deber hacer un seguimiento de todas las fases del plan de calidad y si se hacen
cambios en ste deber ser con una metodologa predeterminada porque si se hace de
forma arbitraria ya no se podrn ofrecer las garantas que en un principio tena este
plan.
1.6. DOCUMENTACIN DEL PLAN DE CALIDAD
Identificacin. Todos los documentos del proyecto deben estar identificados de for
ma
inequvoca, normalmente mediante un sistema de numeracin codificado, que debe
estar incluido en el manual de coordinacin del proyecto.

Clasificacin. Los documentos se deben clasificar en diferentes categoras
atendiendo a su importancia desde el punto de vista de la calidad:
-Grado 1: Documentos que contienen descripciones de sistemas o procesos
cuyos errores pueden afectar al concepto global del proyecto.
-Grado 2: Documentos tcnicos que contiene descripciones de elementos en los
que los errores pueden tener consecuencias limitadas y en ningn caso sobre el
concepto global del proyecto.
-Grado 3: Documentos de contenido bien definido y delimitado, en los que los
posibles errores tienen pocas consecuencias sobre los sistemas y procesos que
configuran el proyecto.

Verificacin. Todos los documentos tcnicos, tales como clculos, planos,
especificaciones, etc., deben disponer de un mnimo de tres firmas que aseguren la

verificacin de las instrucciones siguientes:
-Realizado: la persona que firma el realizado normalmente corresponde al tcnico
responsable de cada trabajo y es responsable del contenido formal del
documento y de que tcnicamente es correcto.
ANEXO
-Verificado: la persona que firma el verificado es responsable de la comprobacin
del documento en relacin con las especificaciones.
-Aprobado: la persona que firma el aprobado suele ser el jefe del departamento o

servicio correspondiente y en documentos generales el director del proyecto.
Esta persona es la responsable del respeto de las especificaciones.
-Revisado: las personas que firman el revisado son los responsables de garanta
de calidad.
Las personas que firman las distintas situaciones pueden ser las mismas o distin
tas.
Habitualmente los documentos de grado 1 deben ir firmados por cuatro personas
diferentes, por tres los de grado 2 y los de grado 1 slo por dos.
Cuando sea necesario modificar cualquier documento es imprescindible realizar el

mismo ciclo anterior. En estos casos la persona autorizada a firmar el aprobado
es
responsable de que la modificacin realizada sea realmente necesaria y est
debidamente documentada.

Distribucin. Es conveniente realizar una tabla especfica donde aparezcan los
principales documentos del proyecto y los departamentos/servicios y personas que

deben recibirlos. Debe estar incluida en el manual de coordinacin.

Archivo. Las normas de archivo tambin deben estar incluidas en el manual de
coordinacin. En el caso de que no se incluyan debern formar parte del plan de
calidad.
2. EL ESTUDIO DE VIABILIDAD
Los estudios de viabilidad deben proporcionar la base-tcnica, econmica y comercial

para la decisin de invertir en un proyecto industrial. En estos estudios se deben
definir
y analizar los elementos crticos relacionados con la fabricacin de un producto dad
o,
junto con otros enfoques posibles, a tal produccin. Un estudio de este tipo debe
dar
por resultado un proyecto con capacidad de produccin definida en un emplazamiento

seleccionado, utilizando una o varias tecnologas determinadas en relacin con
materiales e insumos especficos con costos de inversin y produccin identificados, e

ingresos por concepto de ventas que produzcan un rendimiento determinado respect
o
de la inversin.
ANEXO
2.1. CMO ALCANZAR EL OBJETIVO?
Iniciando un proceso interactivo, a travs de redes de informacin y vinculaciones q
ue
abarcan una variedad de reas tales como: programas de produccin, ubicacin,
emplazamiento, tecnologas, plantas, ingeniera mecnica, elctrica y civil y estructura

orgnica, organizada a fin de minimizar los costos de produccin e inversin.
2.2. PARMETROS DE UN PROYECTO VIABLE
Programa de Produccin.
Insumos.
Materiales.
Tecnologa.
2.3. CONTENIDO DE UN ESTUDIO DE VIABILIDAD
Una descripcin del proceso de optimizacin.
Una Justificacin de las Hiptesis y Soluciones escogidas.
Definicin del alcance del proyecto.
2.4. FACTORES QUE PUEDEN DIFERENCIAR LOS ESTUDIOS DE VIABILIDAD
Naturaleza de la Industria.
La Magnitud y Complejidad de la Planta de Produccin prevista.
Costos de Inversin.
Mercado.
Condiciones de Produccin del Entorno.
2.5. FASES QUE DEBE CONTENER UN ESTUDIO DE VIABILIDAD
Resumen Operativo.
ANEXO
Antecedentes e Historial del Proyecto.
Estudio de Mercado.
Estudio Tcnico.
Marco Legal y Social.
Estudio Econmico.
Evaluacin Econmica.
2.5.1. Resumen operativo
Una vez elaborado el estudio de viabilidad, se presentan las conclusiones y
recomendaciones definitivas tomando en consideracin los aspectos ms relevantes y
fundamentales que arroj el estudio. La idea de este resumen es dar al lector faci
lidades
antes de mostrar conclusiones y recomendaciones, se sugiere comenzar.
ANEXO
2.5.2. Antecedentes e historial del Proyecto
Es importante suministrar una idea clara del proyecto, y el impacto que este ten
dr en la
economa y desarrollo industrial del rea o entorno. Se debe describir el producto e

identificar los patrocinantes unido a las circunstancias que justifican su inters
en el
proyecto.
Esta fase comprende y entregada documentado lo siguiente:
Antecedentes del proyecto.
Promotor y/o Iniciador del proyecto.
Historial del Proyecto.
Estudio de Viabilidad.
Estudio de Preinversin.
Investigaciones Preparatorias.
2.5.3. Estudio de mercado
Como paso previo a la formulacin del proyecto es fundamental determinar el tamao y

la composicin de la demanda efectiva actual del mercado, dividido por sectores, a
fin
de estimar el grado de penetracin en el mercado.
Conjuntamente se deben proyectar los ingresos provenientes de las ventas teniend
o en
consideracin la tecnologa, la capacidad de la planta, el programa de produccin y la

estrategia de comercializacin, esta ltima se debe establecer durante el estudio de

viabilidad, prestando la debida atencin a la determinacin del precio del producto,
las
medidas de promocin, los sistemas de distribucin y los costos.
Teniendo disponible las proyecciones sobre las ventas, se debe formular un progr
ama de
produccin detallado en el que se indiquen las diversas actividades de produccin y
su
calendario. Como paso final en el estudio de viabilidad es determinar la capacid
ad de la
planta teniendo en cuenta los niveles de produccin, inversiones e ingresos por
concepto de ventas.
La investigacin que se realice debe tener las siguientes caractersticas:
-La recopilacin de la informacin debe ser sistemtica.
-El mtodo de recopilacin debe ser objetivo y no tendencioso.
ANEXO
-Los datos recopilados siempre deben constituir informacin til.
-El objeto final del estudio siempre debe tener como objetivo final servir de ba
se
para tomar decisiones.
El Estudio de mercado de un proyecto es uno de los ms importantes y complejos que

debe realizar el investigador. Mas que centrar la atencin sobre el consumidor y l
a
cantidad de productos que ste demandar, se tendrn que analizar los mercados,
proveedores, competidores y distribuidores, e incluso cuando as se requiera, se
analizarn las condiciones de mercados externos. El Estudio del mercado, mas que
describir y proyectar los mercados relevantes para el proyecto, deber ser la base
slida
sobre la que contine el estudio completo, y adems proporcionara datos bsicos para
las dems partes del estudio.
Mtodos utilizados para analizar la demanda
Mtodo de Proyeccin.
Regresin con dos variables.
Regresin y Correlacin con dos y tres variables.
Correlacin Simple.
Correlacin Parcial.
Mtodos de Series de Tiempo.
Mtodo de suavizacin exponencial.
Mercadeo: Se entiende por mercadeo el rea en la cual confluyen las fuerzas de la
oferta y la demanda para realizar las transacciones de bienes y servicios a prec
ios
determinados.
Demanda: Se entiende por demanda la cantidad de bienes y servicios que el mercad
o
requiere o solicita para buscar la satisfaccin de una necesidad especifica a un p
recio
determinado.
Demanda = Produccin Nacional + Importaciones - Exportaciones
Tipos de Demanda:
Demanda insatisfecha: (lo producido u ofrecido no alcanza a cubrir los
requerimientos del mercado),
Demanda satisfecha: (lo ofrecido al mercado es exactamente lo que este
requiere).
ANEXO
Oferta: Es la cantidad de bienes y servicios que un cierto nmero de oferentes
(productores) estn dispuestos a poner a disposicin del mercado a un precio
determinado.
Tipos de oferta:
-Oferta competitiva: (los productores se encuentran en circunstancias de
libre competencia)
-Oferta oligoplica: (el mercado se encuentra liderado y dominado por slo
unos cuantos productores).
Precios: Es la cantidad monetaria que los productores estn dispuestos a vender, y
los
consumidores a comprar, un bien o servicio, cuando la oferta y la demanda estn en

equilibrio.
Tipos de Precio:
-Internacional
-Regional externo
-Regional Interno
-Local
-Nacional.
Comercializacin: La comercializacin es la actividad que permite al productor hacer

llegar un bien o un servicio al consumidor con los beneficios de tiempo y lugar.

2.5.4. Estudio tcnico
En esta fase se pretende resolver las preguntas referentes a dnde, cunto, cundo,
cmo y con qu producir lo que se desea, por lo que el aspecto tcnico - operativo de
un proyecto comprende todo aquello que tenga relacin con el funcionamiento y la
operatividad del propio proyecto.
El estudio Tcnico se realiza al cubrir los siguientes aspectos que a su vez son l
as partes
que la conforman:
Localizacin ptima del Proyecto
La localizacin ptima de un proyecto es la que contribuye en mayor medida a que se
logre la mayor tasa de rentabilidad sobre el capital (criterio privado) u obtene
r el costo
unitario mnimo (criterio social).
ANEXO
El objetivo general es determinar el sitio donde se instalar la planta. Factores
relevantes para determinar la localidad:
Materia Prima disponible.
Mano de Obra disponible.
Costo de los Insumos.
Costo de la Vida.
Cercana del Mercado.
Suelo.
Geografa.
Leyes e Impuestos.
Materia Prima: La localizacin de la materia prima constituye un factor relevante
por su
alta incidencia en los costos de explotacin de muchos procesos industriales. A
continuacin se citan algunas causas que inciden en la localizacin de la materia pr
ima:
-El Transporte, el cual constituye un costo.
-Movilidad de la materia (tuberas).
-Ubicacin de la planta, a fin de garantizar el abastecimiento.
Mano de Obra: Este recurso se clasifica en tres factores que dependern del tipo d
e
industria que se est analizando:
Costo de los Insumos: De acuerdo a los procesos industriales que se desarrollan
en las
plantas habr consumos de energa, de agua, papelera, entre otros, que estarn
influenciados por su ubicacin. La proximidad a un ro, al mar o a una fuente de ene
rga,
como puede ser una central o sub-estacin de distribucin elctrica, una refinera de
petrleo o una mina de carbn, en muchas oportunidades es determinante.
ANEXO
Sin embargo, a la hora de ubicar una planta en una zona especfica hay que conside
rar
si tiene la infraestructura necesaria como red elctrica, gas natural, facilidad d
e
transporte de fuel o derivados del petrleo o las canalizaciones de agua requerida
s.
Suelo: El precio del suelo depende de sus usos. Las administraciones pblicas regu
lan
los usos de los suelos mediante una compleja legislacin, de forma que se establez
ca un
equilibrio entre las zonas destinadas a usos urbanos y residenciales agrcolas, fo
restales
o de inters medioambiental e industriales.
Dentro del factor suelo es preciso analizar los siguientes subfactores:
Disponibilidad.
Costo.
Calidad.
Dotaciones.
Normativa Urbanstica.
Geografa y Clima: La geografa y el clima en muchos casos condicionan el tipo de
instalaciones o edificios que hay que construir y por ende la inversin que hay qu
e
realizar.
Las facilidades de acceso, las cimentaciones de los edificios, el tipo de materi
ales que
hay que almacenar y sus caractersticas, los servicios bsicos, estn muchas veces
condicionados por la geografa y el clima.
Leyes e Impuestos: Las distintas administraciones pblicas tratan de fomentar la
inversin industrial mediante leyes que facilitan o entorpecen, en su caso, la
implantacin de ciertas industrias en reas determinadas. Esto se puede realizar par
a
elevar el nivel de vida de ciertas zonas deprimidas o para atraer inversiones en
zonas
que han padecido una fuerte reconversin industrial y por lo tanto, tienen un nive
l de
desempleo. La exencin en el pago de los impuestos es uno de los instrumentos que
se
utiliza para atraer estas inversiones.
La accin de las administraciones se centra en dotar a las reas industriales de las

infraestructuras necesarias para favorecer su instalacin con unos costos de inver
sin
mas bajo, dotando a estas reas de todos los servicios bsicos que requiere una
industria.
ANEXO
Determinacin del tamao ptimo de la planta
El tamao de un proyecto es su capacidad instalada, y se expresa en unidades de
produccin por ao, es decir el monto de su inversin, el monto de ocupacin efectiva
de mano de obra o algn otro de sus efectos sobre la economa.
Factores que condicionan el tamao de una planta:
Relaciones recprocas entre el tamao y la demanda.
Disponibilidad de la materia prima.
Tecnologa.
Equipos.
Financiamiento.
Organizacin.
Ingeniera del proyecto
La ingeniera de proyectos presenta como objetivo general resolver todo lo concern
iente
a la instalacin y el funcionamiento de la planta. Desde la descripcin del proceso,

adquisicin de equipos y maquinaria se determina, distribucin ptima en planta, hasta

definir la estructura organizacional y jurdica que habr de tener la planta product
iva.
Estado inicial + Proceso transformador = producto final
Insumo
Son aquellos elementos sobre los
cuales se efectuar el proceso de
transformacin para obtener el
producto final.
Suministros
Son los recursos necesarios para
realizar el proceso de
transformacin.
Proceso
Conjunto de operaciones que
realiza, la maquinaria para
elaborar el producto final.
Equipo productivo
Conjunto de maquinarias e
instalaciones para realizar la
transformacin.
Organizacin
Elemento humano necesario para
realizar el proceso productivo.
Productos
Bienes finales resultado del
proceso de transformacin.
Subproducto
Bienes contenidos como valor
econmico y no como objetivo
principal del proceso de
transformacin.
Residuos o desechos
Consecuencia del proceso con o
sin valor.
Tcnicas utilizadas para el anlisis del proceso de produccin
-Diagrama de Bloques.
-Diagrama de Flujo de Procesos.
-Cursograma Analtico.
ANEXO
Cul es la utilidad de este anlisis?
-Facilita la distribucin de la planta aprovechando el espacio disponible en forma

ptima.
-Optimiza la operacin de la planta.
-Mejora los tiempos y movimientos de los hombres y las mquinas.
De que depende la tecnologa que se requiere?
-Naturaleza y Complejidad de las tcnicas involucradas.
-Capacitacin del personal en el funcionamiento, el empleo y el mantenimiento
del equipo cuando se trate del funcionamiento de una conglomeracin
determinada de maquinarias y equipos.
-En caso de tecnologas no patentadas es fundamental la suma de
conocimientos, experiencia y calificaciones para fabricar un producto o
productos determinados.
Cules son los factores que influyen en la seleccin de la tecnologa?
-Materia Prima.
-El grado de Capital.
-El grado de mecanizacin de proyectos u operaciones especiales de produccin.
La adquisicin de tecnologa se clasifica de la siguiente manera
-Licencia de tecnologa.
-Compra directa de la tecnologa.
-Formacin de una empresa mixta en la que participe el proveedor de la
tecnologa.
Consideraciones generales que deben tomar en cuenta en la eleccin de
las maquinarias y equipos
-Tecnologa de produccin seleccionada.
-Capacidad de Produccin especfica.
-Definicin de las diversas etapas operacionales.
-Identificar las diversas etapas del proceso.
-Costos de los Equipos.
ANEXO
Clasificacin de los equipos segn los diferentes tipos de proyectos
-Maquinarias de planta (procesos).
-Equipos Mecnicos.
-Equipos Elctricos.
-Instrumentacin y Control.
-Equipo de Transporte en cinta o de otro tipo.
-Otras mquinas y piezas.
Equipos Auxiliares
-Transporte.
-Equipos de Generacin de Energa elctrica, abastecimiento de agua, gas, etc.
-Plantas Generadoras de: electricidad, vapor, agua caliente y fra, aire
comprimido.
-Equipos de emergencia: bateras.
Equipos para Servicios
-Equipos de oficina.
-Servicios mdicos.
-Seguridad de la planta.
Es importante prever el montaje y la instalacin de las maquinarias que pueden req
uerir
cimientos especiales, estructuras de carga, paredes, vigas y techos.
Mano de obra
Los propsitos que cumple la estimacin de la mano de obra son:
-Generar una plantilla detallada para el clculo del costo de la mano de obra
como parte de los costos.
-Realizar una comparacin del personal requerido con la estructura de la fuerza
de trabajo disponible en la regin del proyecto.
ANEXO
La planificacin de la mano de obra debe iniciarse en el mbito de departamentos,
definindose las necesidades de operarios y de personal tcnico y de gestin por
funciones y categoras.
Factores que condicionan las necesidades de mano de obra:
Evaluacin general de la oferta y la demanda de mano de obra y especialmente de
operarios en la regin.
Evaluacin de la mano de obra y la experiencia disponible en el plano nacional y
regional, en funcin a la experiencia y necesidades tecnolgicas del proyecto.
Principales disposiciones de las leyes laborales (individuales y colectivas),
procedimientos de contratacin y despido.
Niveles de sueldos y salarios, los beneficios marginales y el aumento anual.
Nmero de das de trabajo por ao.
Evaluacin de la disponibilidad de capacidad de gestin nacional y extranjera (en
caso de que se requiera).
Definicin y anlisis de las necesidades de capacitacin y entrenamiento del
personal de diversas categoras.
Planificar los gastos generales por concepto de mano de obra.
2.5.5. Marco legal y social en la evaluacin de proyectos
Legal
El primer paso que todo proyecto debe tener en cuenta es la constitucin legal de
la
empresa. La ley dicta los estatutos permitidos en la sociedad, su funcionamiento
, sus
restricciones, dentro de los cuales la ms importante es la forma y el monto en
participacin extranjera en la empresa. Por ello, la primera decisin jurdica que se
adopta es el tipo de sociedad que va a operar la empresa y la forma de su
administracin, para luego determinar la forma de participacin extranjera en caso d
e
que existiera.
Entre los factores que intervienen en el conocimiento de la legislacin figuran lo
s
siguientes:
Restricciones y decretos en materia de importaciones y exportaciones de materia
prima y productos terminados.
ANEXO
Control de precio del producto.
Contaminacin del ambiente.
Estmulos Fiscales sobre localizacin.
Produccin de ciertos artculos e inversin en maquinarias de produccin nacional.
Condiciones generales de seguridad, higiene y prestaciones para el trabajador.
Pago de impuestos sobre productos del trabajo y actividades mercantiles.
Legislacin bancaria.
Es indiscutible que se deben conocer las leyes vigentes en el momento de la prep
aracin
de un proyecto.
Social
El aspecto social concierne con la adaptacin del proyecto al ambiente y la comuni
dad.
Estos factores son poco atendidos pero no menos importantes. Especficamente, se
refieren al nivel general de los servicios sociales con que cuenta la comunidad,
tales
como escuelas, hospitales, centros recreativo facilidades culturales y de capaci
tacin
de empleados, entre otros.
2.5.6. Estudio econmico
Su objetivo es ordenar y sistematizar la informacin de carcter monetario que
proporcionan las etapas anteriores y elaborar los cuadros analticos que sirven de
base
para la evaluacin econmica.
Comienza con la determinacin de los costos totales y de la inversin inicial. La
inversin inicial tiene como base los estudios de ingeniera, ya que tanto los costo
s
como la inversin inicial dependen de la tecnologa seleccionada.
El clculo continuo con la determinacin de la depreciacin y amortizacin de toda la
inversin inicial.
2.5.7. Evaluacin econmica
Propone describir los actuales mtodos de evaluacin que toman en cuenta el valor de
l
dinero a travs del tiempo, como son la tasa interna de rendimiento y el valor pre
sente
neto: se anotan sus limitaciones de aplicacin y son comparados con mtodos
ANEXO
contables de evaluacin que no toman en cuenta el valor del dinero a travs del tiem
po,
y en ambos se muestra su aplicacin prctica.
Las variables que se toman en cuenta en la evaluacin econmica bsicamente son:
VPN y TIR. El VPN (Valor presente neto) consiste en descontar o trasladar al
presente todos los flujos futuros del proyecto, a una tasa de descuento igual a
la TMAR1 (Tasa Mnima Aceptable de Rendimiento), sumar todas las ganancias
y restarlas a la inversin inicial en tiempo cero.
Si el VPN es mayor que cero se aceptar la inversin, dado que un valor
positivo de VPN significa ganar la TMAR mas el valor positivo del resultado, en
trminos del valor del dinero en tiempo cero.
Si el VPN es menor que cero significa que las ganancias del proyecto no son
suficientes siquiera para ganar la TMAR, y por tanto, la inversin debe
rechazarse.
Para calcular el TIR, el VPN=0. Para aceptar la inversin, el valor que se obtenga
de la
TIR debe ser mayor a la TMAR. Por el contrario, s la TIR es menor que la TMAR, la

inversin se rechazar. El clculo de la TIR se lleva a cabo igualando la suma de los
flujos descontados a la inversin.
Pasos que se deben seguir para la elaboracin de la evaluacin econmica.
1. Clculo del VPN con flujos constantes y con flujos inflados sin financiamiento.

2. Clculo de la TIR con flujos constantes y con flujos inflados sin financiamient
o.
3. Clculo del VPN y TIR con financiamiento.
4. Clculo de las razones financieras del proyecto.
5. Anlisis de sensibilidad con variaciones en el volumen de ventas.
6. Anlisis de sensibilidad con variaciones en el nivel de financiamiento.
7. Conclusiones y recomendaciones generales del estudio.
1.
TMAR = ndice Inflacionario + Premio al Riesgo. El TMAR significa lo que un invers
ionista pedira a una inversin,
para lo cual debe calcularla sumando dos factores: primero, debe ser tal su gana
ncia, que compense los efectos
inflacionarios, y en segundo trmino, debe ser un premio o sobretasa por arriesgar
su dinero en determinada
inversin. Se considera que un premio al riesgo, considerado ahora como la tasa de
crecimiento real del dinero
invertido, habiendo compensado los efectos inflacionarios, debe ser entre un 10
y 15%. Esto no es totalmente
satisfactorio, ya que su valor debe depender del riesgo en que se incurra al hac
er esa inversin, y de hecho, cada
inversin es distinta.
Bibliografa
[1]
BARCEL, M."La gesti dun projecte informtic". UOC. pp. 15-16.
[2]
BECA URBIA, G. Evaluacin de Proyectos. Anlisis y administracin
del riesgo. Editorial Mc-Graw-Hill.
[3]
LEWIS, J. P. Planificacin, programacin y control de proyectos.
Ediciones S.
[4]
PEREA BRAND, J. Direccin y gestin de proyectos. Ediciones
Daz de Santos, S.A.
[5]
DE COS CASTILLO, M. "Teora General del Proyecto. Editorial
Sntesis.
[6]
GMEZ-SENENT MARTNEZ, E. Introduccin al proyecto. Editado
por Servicio de Publicaciones.
[7]
MORRIS ASIMOV. Introduccin al proyecto. Herreros Hnos. Sucs.
S.A. Editores Mxico.
[8]
DOMINGO AJENJO, A. Direccin y gestin de proyectos. Editorial
RA-MA.
[9]
DRUDIS, A. Planificacin, organizacin y gestin de proyectos.
Ediciones Gestin 2000 S.A.
[10]
DAVIDSON FRAME, J. La direccin de proyectos en las
organizaciones. Ediciones Granica, S.A.
[11]
OCHOA LABURU, C. Economa y organizacin de empresas.
Editorial Donostiarra.
[12]
SALGUEIRO, A. Planificacin: el arte de establecer objetivos.
Editorial Aenor N. A.
[13]
BLANCHARD BENJAMIN S. 1993. "Administracin e Ingeniera de
Sistemas". Primera edicin, Editorial Limusa S.A. de C.V., Mxico
D.F., p.p. (235-300).
[14]
COMPANYS PASCUAL R. & COROMINAS A. 1988. "Planificacin
restabilidad de Proyectos Industriales" , Primera edicin, Marcombo
S. A., Barcelona, Espaa.
[15]
DAVIDSON FRAME J. 1995. "La Direccin de Proyectos en las
Organizaciones", Primera edicin, Editorial Granica S.A. , Barcelona
Espaa.
[16]
SERER FIGUEROA M. 2001. "Gestin Integrada de Proyectos", Primera
Edicin, Editorial de la Universidad Politcnica de Catalua. Barcelona ,
Espaa.
[17]
MACCONNELL S. 1997. "Desarrollo y Gestin de Proyectos
Informticos", Primera edicin, Editorial Mac Graw Hill/Interamericana de
Espaa. Madrid, Espaa.
[18]
TRUEBA I.; CAZORLA A. y DE GARCA J. 1995. "Proyectos
Empresariales". Primera edicin, Ediciones Mundi-Prensa. Madrid.
PGINAS WEB
[1]
"Project Managament Institute".
Enlace web: http://www.pmi.org/info/default.asp
[Ledo: 26 de mayo del 2006].
[2]
"Recurso pblico de Trillium, Model Description".
Enlace web: http://www.sqi.gu.edu.au/trillium/t3modc3.html
[3]
"Software Acquisition Capability Maturity Model".
Enlace web: http://www.sei.cmu.edu/arm/SA-CMM.html

Introduccion Gestion Proyectos

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

Introduccion Gestion Proyectos

Cargado por

Copyright:

Formatos disponibles

MSTER EN DISEO,

También podría gustarte