La gestión de proyectos

Alfons Bataller
Director de la colección: Lluís Pastor

Diseño de la colección: Editorial UOC

Diseño del libro y de la cubierta: Natàlia Serrano

Primera edición en lengua castellana: febrero 2016

Primera edición en formato digital: febrero 2016

© Alfons Bataller, del texto

© Editorial UOC (Oberta UOC Publishing, S. L.) de esta edición, 2016

Rambla del Poblenou, 156, 08018 Barcelona
http://www.editorialuoc.com

ISBN: 978-84-9064-389-1

Ninguna parte de esta publicación, incluido el diseño general y la cubierta, puede ser copiada, reproducida,
almacenada o transmitida de ninguna forma, ni por ningún medio, sea éste eléctrico, químico, mecánico,
óptico, grabación, fotocopia, o cualquier otro, sin la previa autorización escrita de los titulares del copyright.
 Autor

Alfons Bataller
QUÉ QUIERO SABER

Lectora, lector, este libro le interesará si usted

quiere saber:

• Cómo llevar a cabo proyectos con éxito.

• Qué pasos hay que seguir para planificarlos.
• Qué herramientas le permitirán gestionar un pro-
yecto.
• Cuáles son los errores habituales en la gestión de
proyectos.
• Qué prácticas permiten garantizar su éxito.
Índice

QUÉ QUIERO SABER 7

LLEVAR UN PROYECTO A BUEN

PUERTO 11

DEFINICIÓN DE PROYECTO 13
Los objetivos 14
Elementos y participantes 15
Consideraciones iniciales 18
La definición y la metodología 19
La complejidad 20
Los disparadores de coste 21
La viabilidad técnica 23
La viabilidad operativa 24
Análisis coste-beneficio 25

PLANIFICACIÓN DE PROYECTOS 27
Definición 27
Elementos del proceso de planificación 28

9
 Diferencias entre planificación y estimación 33
Errores en la planificación 33
Herramientas de seguimiento de proyectos 35
Diagramas de flujo 35
Diagramas de proceso 36
Hoja de control 37
Gráficos de control 37
Diagramas causa-efecto 37
Diagrama de Gantt 38
Diagramas PERT 40

HERRAMIENTAS DE
PLANIFICACIÓN 43
Criterios para la selección de la herramienta 44
Herramientas en el mercado 46
Microsoft Project 46
OpenProj 49

CONSEJOS Y RECOMENDACIONES 51
La concepción del proyecto 52
La planificación de lo desconocido 55
La burocracia del proyecto 57
La tecnología dentro del mundo real 60
¿Cómo se incluyen las leyes en el proyecto? 62

CLAVE DE ÉXITO PROFESIONAL 65

Bibliografía 69

10
LLEVAR UN PROYECTO A BUEN
PUERTO

La técnica de gestión y desarrollo de proyectos

tiene muchos aspectos que son, habitualmente, más
bien fruto de la gestión de las personas y de la expe-
riencia que de técnicas propias de una rama especí-
fica del conocimiento. No obstante, esto no implica
que se pueda dejar de lado todo el conocimiento teó-
rico vinculado a esta especialidad.
Para una correcta gestión de proyectos hay que
disponer de una serie de conocimientos que permi-
ten dar una opinión fundamentada de muchos ele-
mentos diferentes (tecnología, finanzas, recursos hu-
manos, etc.). Todo ello sin necesidad de ahondar en
la mayoría de ellos.
En este libro se explica la importancia de definir
correctamente los proyectos, planificarlos con cuida-
do, recurrir a distintas herramientas para controlar
su ejecución y tener en cuenta consejos y recomen-

11
daciones basados en buenas prácticas para llevarlos
«finalmente» a buen puerto.

12
DEFINICIÓN DE PROYECTO

Los principales conceptos que afectan a los esta-

dios iniciales del desarrollo de un proyecto tienen que
ver con la presentación de diferentes modos de defi-
nir el concepto proyecto; el significado y las caracte-
rísticas de los objetivos de un proyecto; los elemen-
tos y los participantes que habrá en un proyecto, y
finalmente las valoraciones iniciales para poder defi-
nir si vale la pena ejecutar un proyecto.
Definir es una tarea complicada dado que debe
abordar el conjunto de los atributos del ente definido.
Definir un proyecto representa una tarea diferente
en función del rol o la implicación que tiene en él la
persona que lo define.
Hagamos una primera aproximación. Un proyec-
to es una iniciativa singular, no repetitiva, normal-
mente dirigida a alcanzar unos objetivos prefijados
en un lapso de tiempo determinado y con un presu-
puesto también determinado.

13
 El logro de estos objetivos se consigue mediante
la realización de una actividad compleja, susceptible
de descomponerse en una serie de tareas interdepen-
dientes entre sí en cuanto a su orden de ejecución.
La definición anterior la podemos ampliar de mo-
do que incluya aspectos no considerados. Un pro-
yecto es una acción en la que los recursos humanos,
financieros y materiales se organizan de una nueva
manera para realizar una tarea diferente. En esta, te-
niendo en cuenta unas especificaciones y dentro de
unos límites de costes y tiempos, se intenta conseguir
un cambio beneficioso dirigido según unos objetivos
cualitativos y cuantitativos.
Estos elementos implican que un proyecto supo-
ne un riesgo y una incertidumbre considerables, y por
lo tanto su éxito dependerá en gran medida de una
gestión adecuada.

Los objetivos

La definición de un proyecto implica que se deter-

minen los correspondientes objetivos que se asocian
a él. Los objetivos de un proyecto deben incluir in-
formación que lo justifiquen; las razones por las que
se lleva a cabo. Estas razones deben aparecer en tér-
minos cuantificables: dinero, volumen, etc.

14
 Los objetivos también han de incluir información
de su ámbito; zona geográfica, la organización que
debe desarrollarlo, etc.
Como en cualquier otra definición de objetivos,
los objetivos de un proyecto deben cumplir las con-
diciones resumidas habitualmente en la expresión in-
glesa SMART, que hace referencia a concreto, cuanti-
ficable, alcanzable, relevante y temporal (specific, mea-
surable, achievable, relevant, trackable).

Elementos y participantes

Una vez conocido qué es un proyecto y qué que-

remos conseguir con su ejecución, profundizaremos
en dos de los aspectos principales que, además, son
inherentes a cualquier proyecto independientemente
de su tipología y otras características particulares.
En primer lugar, en los participantes del proyec-
to, es decir, en todo aquel que participa de una ma-
nera u otra en su desarrollo. Esta manera amplia de
entender el equipo del proyecto permite que se pue-
dan identificar mucho mejor sus riesgos, dado que
quedarán completamente definidos la participación,
las necesidades, los condicionantes, etc., de cada uno
de estos participantes.
De este modo, al inicio del proyecto hay que iden-
tificar y recabar los datos principales de todos los
participantes del proyecto. En general e independien-

15
temente del tipo de proyecto, podemos destacar los
participantes siguientes: cliente (director de proyecto,
control financiero, explotación, etc.); proyectista/as
(director de proyecto, diseño conceptual, instalacio-
nes, ergonomía, etc.); equipo del proyecto (encarga-
dos de la ejecución directa de las tareas del proyec-
to); suministradores (compras, gerente, etc.); gestor
de proyecto (gestor, responsable planificación, res-
ponsable de costes, etc.) y otros actores (administra-
ciones públicas, compañías de servicios, etc.).
A continuación analizaremos con más detalle la
figura del director de proyecto, que asume el grue-
so y la responsabilidad de su gestión y su desarrollo.
Entre sus tareas específicas hay que destacar las seis
siguientes:

• Interpretar la petición del cliente externo y la po-

sición relativa del proyecto en la empresa y su es-
trategia (requisitos del cliente).
• Desarrollar el plan de diseño, programación, eje-
cución, control y entrega del proyecto. En mu-
chos casos se aplican aquí algunos planteamientos
derivados del análisis de ciclo de vida (se trata de
planificar, organizar y asignar personal).
• Liderar, dirigir y controlar la comunicación entre
las personas y los equipos asignados al proyecto.
• Formalizar el seguimiento del desarrollo del pro-
yecto (controlar y, eventualmente, reprogramar).
• Informar a la dirección general, a la organización
y al exterior.

16
• Desarrollar las capacidades de las personas ads-
critas al proyecto (instruir).

El segundo aspecto principal de un proyecto des-

pués de identificar a sus participantes son sus ele-
mentos. Para garantizar su éxito, habrá que emplear
una metodología adecuada. A pesar de que el pro-
yecto puede tener diferentes rasgos específicos (rela-
tivos a la tecnología, al diseño conceptual, al diseño
físico, a la implantación, etc.), siempre habrá una se-
rie de elementos (que podemos denominar metodo-
logía) que estarán presentes. La definición y la ejecu-
ción son clave para el éxito del proyecto. Se puede
proponer una metodología de cinco fases:

1) Definición del proyecto. Se realizan fundamen-

talmente actividades destinadas a la determina-
ción de la necesidad que se debe cubrir y se es-
tudia la viabilidad del proyecto.
2) Planificación y diseño. Se define completamente
la solución que se ha de implantar y se determi-
na la concatenación de actividades que hay que
llevar a cabo.
3) Gestión de proyecto. Se llevan a cabo las tareas
de seguimiento y control de las actividades pro-
gramadas. La gestión de las desviaciones permi-
tirá determinar y controlar los impactos del día a
día de la ejecución en el resultado final.
4) Gestión de la documentación. Se define la ges-
tión documental (origen, destino y contenido de

17
 los documentos que se han de producir y gestio-
nar).
5) Gestión de la calidad. Conjunto de herramientas
que permiten establecer los procedimientos por
los que se comprobarán los resultados interme-
dios y finales del proyecto para garantizar que se
adecuan a lo que se indica en la definición del
proyecto.

Las dos últimas fases son horizontales y se llevan a

cabo durante toda la vida del proyecto, mientras que
las tres iniciales son verticales y se corresponden con
un momento concreto de su desarrollo.

Consideraciones iniciales

Cuando ya conocemos quién y cómo se pueden

hacer las cosas, es el momento de plantearse si tiene
sentido realizarlas. Por este motivo se llevan a cabo
las estimaciones.
Las estimaciones iniciales son el conjunto de va-
loraciones relativas al desarrollo de un proyecto que
permite a sus promotores evaluar si existen razones
para ejecutarlo y lograr los objetivos previstos.
Esta «razonabilidad» se fundamenta en aspectos
operativos, técnicos y económicos (con un peso ha-
bitualmente preponderante).

18
 El peso otorgado a cada uno de los ejes de análisis
dependerá en general del perfil de la persona o grupo
de personas que toman la decisión sobre la viabilidad.
Como podemos imaginar, la realización de esti-
maciones no es una tarea sencilla. Apuntamos a con-
tinuación brevemente los principales aspectos relati-
vos a las estimaciones iniciales.

La definición y la metodología

La estimación es el proceso que proporciona un

valor a un conjunto de variables para la realización
de un trabajo dentro de un rango aceptable de tole-
rancia.
También es la previsión de personal, de esfuerzo,
de los costes y de la planificación que se requerirá
para llevar a cabo todas las actividades y construir
todos los productos asociados al proyecto.
Uno de los parámetros críticos de la estimación
es determinar su exactitud. La estimación puede ha-
cerse a partir de datos históricos o con herramientas.
Curiosamente, en la actualidad, se da un hecho un
poco sorprendente: algunas herramientas existentes
proporcionan una estimación más exacta que la que
se obtiene de la empresa a partir de los datos histó-
ricos.
A pesar de que no está determinado de manera
genérica, podemos decir que una posible metodolo-
gía para hacer estas estimaciones es seguir las pautas

19
siguientes: identificar el proyecto, presentar en para-
lelo las alternativas técnicas y las operativas, hacer la
estimación económica y llevar a cabo el análisis de
viabilidad económico final.
La metodología presentada no es única y es tan
solo un posible esquema. Las diferentes estimaciones
que hay que realizar se describen más adelante y tie-
nen como objetivo lograr el máximo conocimiento
del proyecto antes de decidir ejecutarlo.

La complejidad

Como nos podemos imaginar, la estimación será

un trabajo que se materializará haciendo un elevado
número de hipótesis y, por lo tanto, tendrá un grado
de incertidumbre importante. Todo esto hace que la
realización de estimaciones sea una tarea compleja.
Entre las razones que explican esta complejidad
se encuentran las siguientes:

• No existe un modelo de estimación universal.

• Las estimaciones son particulares para cada una
de las personas implicadas.
• La utilidad de una estimación dependerá de la eta-
pa del proyecto en la que esta se lleve a cabo.
• La estimación se realiza, a veces, superficialmente.
• Las estimaciones claras, completas y precisas son
difíciles de efectuar.

20
• La tecnología y otros elementos cambian muy rá-
pidamente.
• Falta experiencia a la hora de valorar desarrollos,
especialmente de proyectos largos.
• Tendencia hacia la subestimación.
• Tendencia a basarse en el índice de productividad
de quien hace la estimación.
• Interpretaciones poco adecuadas en las relaciones
lineales entre la capacidad requerida por unidad
de tiempo y el tiempo disponible.
• Tendencia a reducir las estimaciones para dismi-
nuir el importe económico del proyecto.
• Falta de costumbre de incluir la formación nece-
saria para la capacitación del personal.
• No se consideran los «disparadores» de coste.

Los disparadores de coste

Los disparadores de coste son aquellos elementos

que forman parte del conjunto de los elementos que
hay que valorar a la hora de hacer estimaciones de
proyectos. Ahora bien, las pequeñas modificaciones
en su estimación tienen un gran efecto multiplicador
en el resultado obtenido.
Todos los disparadores influirán en la estimación
que haremos. Lo que es realmente difícil es determi-
nar cuáles son los disparadores de coste más impor-
tantes y cómo influyen en el proyecto. La resolución
de la influencia de los disparadores de coste no se

21
consigue con ninguna receta mágica. De todos mo-
dos, planteamos algunas opciones para minimizar el
margen de error:

• Definición. Determinar qué significa cuando se

dice que un desarrollador es experimentado y
cuando no.
• Cuantificación. Utilizar medidas como mucho,
moderado, poco...
• Objetividad. Decir que lo que puede ser complejo
para el desarrollador A puede no serlo para el B.
• Correlación. Tener en cuenta que un cambio en
un valor puede tener consecuencias en los valores
de otros disparadores.
• Relación entre disparador y esfuerzo. Indicar la re-
lación entre el nivel de calidad especificado y el
esfuerzo requerido, etc.
• Calibración. Tener en cuenta que una situación di-
fiere mucho de otra.

¿Cómo podemos evitar los disparadores de coste?

• Cuantificando en términos absolutos.

• Objetivizando las situaciones.
• Cuantificando lo que es cualitativo.
• Homogeneizando las opiniones de todos los «es-
timadores».

Como hemos visto hasta ahora, la técnica y la ex-

periencia que se requieren para poder hacer estima-

22
ciones de los proyectos provocan que esta tarea tenga
una dificultad importante. Un buen estimador debe-
ría cumplir los requisitos siguientes: tener una buena
formación y una experiencia profesional que lo ayu-
den a entender y solucionar los problemas de la ges-
tión de proyectos; tener una posición en la organiza-
ción que le permita adoptar un juicio independiente;
utilizar un método que pueda ser explicado, cuestio-
nado, discutido y auditado por otros expertos; si uti-
liza una herramienta de estimación, esta debe ajus-
tarse a su propósito de estimación y ha de respetar
el método que utilizaría el estimador si trabajara «a
mano»; aplicar su experiencia en cada estimación. Es
decir, describir los problemas a los que ha tenido que
enfrentarse, las soluciones, etc., y finalmente docu-
mentar su estimación, incluyendo los resultados ob-
tenidos y cualquier información necesaria para hacer
repetible y verificable el proceso de estimación.
La estimación será más ajustada a la realidad en
función de la proximidad a la finalización de la eje-
cución del proyecto, dado que la cantidad de infor-
mación de la que se dispone es más abundante. Es
decir, cuanto más nos acercamos a la finalización del
proyecto, más fiables serán las estimaciones.

La viabilidad técnica

La viabilidad técnica es la condición que posibilita

el funcionamiento del sistema, proyecto o idea que

23
califica, según sus características tecnológicas. Se eva-
lúa ante un determinado requisito o idea para deter-
minar si es posible llevarlo a cabo satisfactoriamente
y en condiciones de seguridad con la tecnología dis-
ponible. Para hacerlo, hay que verificar factores co-
mo la durabilidad, la operatividad, las implicaciones
energéticas o los mecanismos de control.
Los condicionantes técnicos representan una de
las partes que permiten hacer la estimación de la via-
bilidad del proyecto. Para poder efectuar una valora-
ción correcta de cada una de las opciones posibles
hay que identificar siempre el esfuerzo asociado con
cada tecnología; la capacidad/necesidad de aprendi-
zaje; el impacto económico y estructural de la evolu-
ción de la tecnología; la madurez de la solución, y la
posibilidad de integrarla en el resto de la compañía.
Las informaciones que se obtengan de este análi-
sis son las principales fuentes de hipótesis para todas
las estimaciones relativas al proyecto.

La viabilidad operativa

La viabilidad operativa es la capacidad que tiene

la organización de hacer frente a la definición, la eje-
cución y la operación del proyecto de acuerdo con
los condicionantes relativos a la estructura actual y
futura. En este estudio deben participar:

24
• Áreas que intervendrán directamente en su apli-
cación, por lo que tienen la obligación de conocer
el proyecto de manera detallada.
• Áreas afectadas por la implantación del proyecto,
dado que deberían cambiar o adecuarse a este.
• Área responsable del manejo de los recursos eco-
nómicos, para cuantificar el coste del proyecto de
manera más específica.

Análisis coste-beneficio

La técnica de análisis coste-beneficio tiene como

objetivo fundamental proporcionar una medida de
los costes en los que se incurre a la hora de hacer un
proyecto y compararlos con los beneficios esperados.
Esta medida o estimación servirá para lo siguiente:

• Valorar la necesidad y oportunidad de acometer

la elaboración del proyecto.
• Seleccionar la alternativa más beneficiosa para lle-
var a cabo el proyecto.
• Estimar adecuadamente los recursos económicos
necesarios en el plazo de elaboración del proyecto.

Hay que destacar la necesidad de guiarnos por cri-

terios económicos y no solo técnicos para la plani-
ficación de tareas y proyectos. Por ello, se hace una
primera introducción sobre las técnicas y métodos
de evaluación de conceptos económicos, con el fin

25
de proporcionar a los profesionales criterios que los
ayuden en la planificación de proyectos y la evalua-
ción de alternativas.
El resultado del estudio efectuado acaba con la
presentación de un estudio final de viabilidad que tie-
ne que incluir los diferentes elementos utilizados y
una lista detallada de los argumentos que deben per-
mitir tomar la decisión de llevar o no a término el
proyecto.
Los contenidos de este estudio deberían incluir lo
siguiente: objetivos generales del proyecto, plantea-
miento para la elaboración del proyecto, capacidad
organizativa para llevarlo a cabo, esquema de selec-
ción tecnológica, estimaciones económicas, estudio
de viabilidad económica y análisis DAFO relativo al
proyecto.
Los destinatarios del estudio serían el responsable
financiero, el jefe de sistemas, el jefe de recursos hu-
manos, el responsable de formación, el responsable
de mantenimiento y representantes del personal.

26
PLANIFICACIÓN DE PROYECTOS

Hasta ahora hemos analizado los conceptos ini-

ciales relativos a la definición del proyecto y las esti-
maciones iniciales que nos permiten determinar su
viabilidad.
Una vez hemos identificado que el proyecto se
puede llevar a cabo, hay que ir un paso más allá y
efectuar la planificación. La planificación sin un se-
guimiento posterior no tiene sentido y, por lo tanto,
veremos que una cosa sin la otra puede hacer fraca-
sar el proyecto.

Definición

La planificación de un proyecto determina qué

hay que hacer, quién debe hacerlo, cuándo y con qué
recursos se contará para llevar a cabo las tareas. La
planificación es la premisa del control, dado que solo

27
lo que está debidamente planificado puede contro-
larse.
A partir de los requisitos del cliente –externo o
interno–, la planificación aborda las etapas siguien-
tes: análisis de los objetivos del proyecto; desglose
de las tareas del proyecto; organización de las tareas;
programación del proyecto (y eventualmente repro-
gramaciones), y organización y puesta a punto de los
recursos necesarios.

Elementos del proceso de planificación

La planificación es una de las actividades que se

hacen una vez se dispone de ciertos datos de partida
(requisitos, necesidades, etc.) y cuyo objetivo es de-
terminar de manera clara la totalidad de las activida-
des que se deben desarrollar hasta la finalización del
proyecto.
Para llevar a cabo un proceso de planificación ha-
brá que disponer de una metodología que nos per-
mita trabajar de una manera adecuada, a pesar de que
hay que tener en cuenta que se abordarán muchos
aspectos que en general diferirán de un proyecto al
otro.
A continuación apuntamos las siete actividades
principales de la metodología que sugerimos:

28
1) Determinación de los requisitos del cliente. Es
un elemento básico para poder garantizar el éxito
del proyecto, así como también que nos hagamos
cargo completamente de lo que desea lograr el
cliente mediante el desarrollo del proyecto.
2) Determinación de necesidades y estrategias. En
esta segunda actividad es cuando hay que definir
las posibles opciones de desarrollo del proyecto.
Se realizan las diferentes estimaciones que se han
descrito en el apartado anterior.
3) Definición de los objetivos del proyecto. Una vez
se ha conseguido llevar a cabo una definición
completa del proyecto, es posible determinar los
objetivos. Hay que recordar que estos objetivos
deberán responder a las características SMART,
ya definidas previamente.
4) División por tareas. Esta es la primera parte del
proceso de planificación del proyecto que se di-
ferencia de lo que hemos visto hasta ahora a lo
largo de los apartados anteriores. En este mo-
mento es cuando el director de proyectos des-
grana el trabajo en elementos tan pequeños co-
mo se pueda e identifica para cada uno de ellos
los recursos y los esfuerzos que se requieren pa-
ra realizarlos. La elección adecuada del concepto
de actividad es el elemento clave que nos permite
efectuar correctamente esta fase de la metodolo-
gía. Se entiende como actividad aquella unidad
mínima de proyecto en la cual podemos identifi-
car claramente el elemento de partida o input, la

29
 manipulación que se debe efectuar sobre el ele-
mento de partida y el elemento resultante o out-
put.
Esta descomposición en tareas debe efectuar-
se con la máxima diligencia posible, dado que se-
rá la base de todas las actividades que se han de
realizar en el resto del proceso de planificación.
5) Elaboración del programa de trabajo o progra-
mación. La programación se basa en la división
del proyecto en fases secuenciales en las que
se agrupan las actividades identificadas anterior-
mente. Esta agrupación de tareas nos permitirá
determinar los recursos necesarios y efectuar los
presupuestos correspondientes.
Para un buen desarrollo de la programación es
importante identificar los acontecimientos más
importantes; desarrollar detalladamente la se-
cuencia en la que se deben hacer las tareas y la
red de interrelaciones entre ellas; calcular la du-
ración de cada una de las actividades, que deberá
coincidir con la del reparto de tareas; utilizar los
tiempos definidos en cada una de las actividades
para calcular la duración total del proyecto; iden-
tificar las restricciones y las disponibilidades de
tiempos en relación con los acontecimientos im-
portantes, e identificar las restricciones de recur-
sos. Otros aspectos que hay que tener en cuen-
ta son la necesidad de tiempo extra, el coste de
viajes y reuniones, la realización de pruebas, la
participación en revisiones, el tiempo dedicado

30
 a apoyo administrativo o los desarrollos iniciales
antes de empezar el proyecto.
6) Control y revisión. Esta fase consiste en el se-
guimiento del proyecto. El seguimiento es la re-
copilación y el almacenamiento de datos sobre
tiempos, recursos, costes y hechos asociados a un
proyecto para el análisis y el estudio de su evolu-
ción real, comparándola con la planificación.
La finalización del proceso de estimación de-
be ser el inicio de la planificación. Con la plani-
ficación hecha, empezaremos el seguimiento del
proyecto. Las entradas del proceso de seguimien-
to serán la estimación y planificación del proyec-
to, además de los datos reales recabados durante
su evolución.
El director de proyecto efectúa el seguimien-
to del proyecto (a partir de varias herramientas
que veremos más adelante) mediante diferentes
tareas, entre las que destacan las siguientes:

– Seguimiento de la planificación. Verifica la

evolución de las tareas previstas en la planifi-
cación para controlar que se ajustan a la previ-
sión en cuanto a plazos, esfuerzo dedicado y
consumo de recursos.

– Actualización de la planificación. Mantiene al

día los documentos de seguimiento de la pla-
nificación e incorpora los datos extraídos de la
fase anterior.

31
 – Revisión de los documentos del proyecto.
Además de entregarlos al cliente según los pla-
zos previstos, es necesario que los documen-
tos contengan todo cuanto se ha determinado
previamente y se debe efectuar la revisión de
control de calidad correspondiente.

– Gestión de la documentación administrativa

del proyecto: hay que recabar, revisar y distri-
buir correctamente la totalidad de los docu-
mentos administrativos que rodean un proyec-
to.
7) Reprogramación. Durante el proceso de segui-
miento se puede producir una replanificación si
nos apartamos del plan original. Una fuerte des-
viación durante el seguimiento puede ser la con-
secuencia, por ejemplo, de un cambio en la natu-
raleza del proyecto. En este caso, necesitaremos
una reestimación y replanificación que sea con-
secuente con los cambios.
El resultado de esta fase deberá incorporarse
a los documentos de seguimiento del proyecto
de acuerdo con lo que se ha indicado en el apar-
tado anterior. Hay que recordar que es necesa-
rio que las modificaciones en las programaciones
iniciales se incorporen a las herramientas de se-
guimiento.

32
Diferencias entre planificación y estimación

A pesar de que ahora ya podemos tener más claro

en qué consiste una cosa y la otra, resulta que a menu-
do se confunden los conceptos de estimación y pla-
nificación: la estimación la hacemos al principio del
proyecto, precisamente para pedir presupuestos, sa-
ber cuánta gente necesitaremos, otros recursos, etc., y
la planificación es la etapa en la que se asigna exacta-
mente quién hace qué y durante cuánto tiempo. Algo
así como: ¿Cuánto tiempo y cuánto dinero necesito
para conocer París?
«10 días y 3.000 euros». (Esto es una estimación).
«El primer día voy al aeropuerto a las 10 horas,
tomo el avión y llego a París a las...». (Esto es una
planificación).

Errores en la planificación

Como nos podemos imaginar, la planificación de

proyectos es una tarea complicada que, en general, no
quedará libre de errores, ya sean humanos o propios
del proceso, del producto o de la tecnología.
Como en cualquier otra situación, el control de
las fuentes de error y la determinación de las incerti-
dumbres asociadas permitirán que estos errores ten-
gan una influencia que, a pesar de que no se pueda
eliminar completamente, quede como mínimo con-
trolada.

33
 Los errores se pueden clasificar según sus oríge-
nes. A continuación os presentamos los principales:
relacionados con el factor humano, el proceso, el
producto y la tecnología.
Errores relacionados con el factor humano son
los siguientes: motivación insuficiente, trabajadores
conflictivos, heroísmos (es habitual pensar que po-
demos hacer lo imposible y que somos capaces de
cualquier cosa); añadir personal a un proyecto retra-
sado; oficinas ruidosas y con poco espacio; fricción
entre las personas que desarrollan el proyecto y los
clientes; expectativas poco realistas; ausencia de apo-
yo efectivo de la dirección; compromiso insuficiente
de los participantes en el proyecto; falta del input de
usuario; exceso de interlocutores o interlocutores in-
eficaces; intereses políticos.
Errores relacionados con el proceso son estos:
planificación excesivamente optimista; gestión de
riesgos insuficiente; errores debidos a la subcontra-
tación; abandono de la planificación ante la presión
del tiempo; pérdida de tiempo en la fase preparatoria
de un proyecto; planteamiento de demasiados obje-
tivos a la vez; recorte de actividades fundamentales
ante un retraso; diseño inadecuado, y control de ca-
lidad insuficiente.
Errores relacionados con el producto son, por
ejemplo, replanificar para recuperar retrasos de la
planificación inicial sin alterar los plazos iniciales; po-
ner un exceso de requisitos con inestabilidad; plan-
tear demasiados objetivos a la vez; desarrollar el pro-

34
yecto sin centrarse en los objetivos; negociar según
el modelo de «tira y afloja»; orientar el desarrollo en
la investigación.
Errores relacionados con la tecnología son aho-
rros sobrestimados gracias a herramientas o métodos
nuevos; cambio de herramientas en medio del pro-
yecto y falta de sistemas de control de versiones de
código fuente.

Herramientas de seguimiento de proyectos

Tanto el director del proyecto como el resto del

equipo deben utilizar herramientas de seguimiento
adecuadas para garantizar el éxito del proyecto. A
continuación presentamos las más habituales.

Diagramas de flujo

Se utilizan para estructurar proyectos y establecer

interrelaciones entre sus partes. También se denomi-
nan flujogramas y son mapas de actividades que per-
miten identificar tareas individuales, secuencias, or-
denaciones y responsabilidades. Son una herramien-
ta de primer orden para la mejora de procesos y para
la gestión de proyectos.

35
Diagramas de proceso

Buena parte de las tareas que se deben desarrollar

en la ejecución de un proyecto se pueden considerar
tareas de proceso, o asimilar a estas. La utilización de
mapas de proceso permite planificar el desarrollo de
las tareas y a menudo simplificarlas.
La gestión de los procesos supone la considera-
ción de tres niveles:

• Proceso. Se define como el grupo de actividades

interrelacionadas que añaden valor, caracterizadas
por entradas y salidas específicas.
• Actividad. Se define como el grupo de tareas in-
terrelacionadas que añaden valor, caracterizadas
por entradas y salidas específicas.
• Tarea: es el trabajo individual y aislado que añade
valor.

Así, si consideramos un proyecto como si fuera un

proceso, el proceso sería la instalación del software;
las actividades serían la instalación del sistema ope-
rativo, la instalación del paquete ofimático y la insta-
lación del software de gestión de proyectos, y las ta-
reas serían introducir el CD, ejecutar el programa de
instalación y verificar el funcionamiento correcto del
software.

36
Hoja de control

La hoja de control es una herramienta básica de

análisis que registra las características que hay que
controlar de las salidas de una tarea en un proyecto o
en un proceso. Esta puede ser manual o electrónica.
Una hoja de control tiene en cuenta los campos
siguientes: un número de identificación, la descrip-
ción, la fecha de inicio y finalización, los recursos, las
tareas de las que depende, los recursos adicionales y
cuál es el estado del proyecto en una fecha determi-
nada.

Gráficos de control

Los gráficos de control son la representación grá-

fica o mediante tabla de los valores de un determina-
do output. Su objetivo es permitir llegar a conclusio-
nes sobre la estabilidad en el comportamiento de una
tarea o actividad. En un gráfico de control encontra-
ríamos, por ejemplo, una enumeración de tareas aso-
ciadas con el valor correspondiente conseguido en
cada una de ellas

Diagramas causa-efecto

Los diagramas causa-efecto permiten ordenar por

grupos las causas que generan determinados efectos

37
sobre un output y, generalmente, se utilizan como he-
rramientas de análisis para la resolución de proble-
mas.
También reciben el nombre de sistema Sedac.
Desarrollado por Deming R. Fukuda, este sistema
responde a las siglas de la expresión structure for en-
hancing daily activities through creativity (estructura para
la mejora de las actividades diarias mediante la crea-
tividad).

Diagrama de Gantt

El diagrama de Gantt es una sencilla herramienta

de gráficos de tiempos y resulta bastante eficaz para
la planificación y la evaluación del avance de los pro-
yectos. Un gráfico de Gantt es un sencillo gráfico de
barras con las características siguientes:

38
• Cada barra simboliza una tarea del proyecto.
• El eje horizontal representa el tiempo.
• Verticalmente, y en la columna izquierda, se escri-
be una relación de las tareas.

Una ventaja importante de los gráficos de Gantt

es que ilustran claramente el encabalgamiento entre
tareas planificadas.
Una vez identificadas las tareas (diagramas de flu-
jo o un simple listado de tareas) se suele efectuar una
primera representación visual y una esquematización
del proyecto por medio de un diagrama de Gantt.
Para usar el diagrama de Gantt como herramienta
de planificación y seguimiento, el procedimiento es
el siguiente:

• Identificar las tareas que hay que planificar.

• Determinar la duración de cada tarea.
• Escribir la lista de actividades en la columna de la
izquierda del gráfico Gantt.
• Anotar las fechas de inicio y final de cada tarea del
proyecto en el eje horizontal del gráfico.
• Pintar una barra para cada tarea según las fechas
identificadas.
• Para evaluar los avances del proyecto se marcan
los porcentajes de trabajo realizado oscureciendo
sobre cada barra la parte proporcional. Si una ta-
rea ha sido completada, su barra correspondiente
aparecerá completamente oscura.

39
Diagramas PERT

PERT es la sigla de técnica de evaluación y revi-

sión de proyectos o programas (project/program evalua-
tion and rewiev technique). Permite evidenciar la interde-
pendencia de las tareas de los proyectos cuando se
realiza la planificación.
Este método fue desarrollado a finales de los años
cincuenta para planificar y controlar los grandes pro-
yectos de desarrollo armamentista del ejército nor-
teamericano. Uno de sus elementos clave fue el dia-
grama PERT, que consiste en la representación gráfi-
ca de los nodos o acontecimientos del proyecto uni-
dos entre sí por líneas que representan las actividades
desarrolladas para ir de un hecho al otro.
La principal característica es que permite visuali-
zar muy fácilmente el camino o ruta crítica, es decir,
la concatenación de actividades que en caso de retra-
sarse implican un retraso del proyecto de forma di-
recta.
En un diagrama PERT cada nodo representa un
momento puntual del tiempo, como por ejemplo te-
ner el hardware instalado en las oficinas del cliente o
tener el software ya instalado. Las líneas que unen los
nodos son actividades, como por ejemplo instalar el
software en el hardware.
Hay que prestar especial atención al camino críti-
co de un proyecto. Si se detecta que una tarea críti-
ca se retrasa, habrá que plantearse varias alternativas
de acción y aplicar medidas correctivas, como la re-

40
distribución de recursos humanos, dado que en caso
contrario el retraso global se producirá seguro.
Para dibujar un gráfico PERT, hay que seguir cin-
co pasos:

1) Hacer una lista de todas las tareas y aconteci-

mientos del proyecto.
2) Determinar las dependencias entre las tareas.
3) Realizar una estimación de la duración de ca-
da tarea. Estimar tiempo óptimo (a) –correspon-
diente a la cantidad mínima de tiempo para rea-
lizarla–, tiempo pésimo (b) –cantidad máxima de
tiempo para llevarla a cabo–, y calcular el tiempo
más probable (m) –considerado el tiempo más
realista según nuestra experiencia.
4) Calcular la duración esperada (DE), según la fór-
mula siguiente: D = a + 4 m + b ÷ 6
5) Calcular el tiempo mínimo y el tiempo máximo
de finalización (TmF y TMF) de cada tarea.
6) Dibujar el gráfico PERT.

Razones para elegir entre diagramas PERT o Gantt

Se recomienda PERT para grandes proyectos con alta dependencia
entre las tareas. Gantt se recomienda para proyectos más sencillos.

Todos los proyectos tienen algunas dependencias entre tareas y

pueden tener tareas superpuestas. Los gráficos PERT y Gantt de-
berían utilizarse como herramientas complementarias dado que
nos dan visiones diferentes de los encabalgamientos y las depen-
dencias.

41
Cabe señalar que los softwares de gestión de proyectos reúnen las
mejores características de PERT (sobre todo, el análisis del camino
crítico) incorporadas a gráficos de Gantt, hecho que vuelve inne-
cesario efectuar el diagrama de PERT.

También hay que destacar que los directores de proyectos prefie-

ren los gráficos Gantt por su sencillez y su capacidad para mostrar
el calendario de un proyecto.

42
HERRAMIENTAS DE PLANIFICACIÓN

Hasta ahora hemos aprendido las principales ca-

racterísticas de la definición y gestión de proyectos.
Ahora toca identificar las maneras de poder hacerlo
de una manera más automatizada.
Hoy en día no se puede concebir ninguna activi-
dad sin disponer de una herramienta informática que
nos ayude a automatizar su realización. La gestión de
proyectos no puede ser menos y, desde hace tiempo,
se encuentran herramientas en el mercado que nos
permiten en mayor o menor medida efectuar casi to-
das las tareas derivadas de esta actividad.
Cualquier software dedicado a la gestión de pro-
yectos debe ayudarnos a monitorizar y gestionar los
elementos siguientes: tareas, personas, perfiles de tra-
bajo, gastos y documentación del proyecto. Si, ade-
más, la herramienta nos permite disponer de un es-
pacio de trabajo colaborativo, el rendimiento que po-
demos extraer será todavía mayor.

43
 El principal elemento que hay que considerar es
que un software para la gestión de proyectos debe
permitirnos cruzar los datos anteriores para poder
disponer de una visión permanentemente actualiza-
da del avance de los proyectos y las tareas. Asimis-
mo, debe ayudarnos a determinar el impacto de la si-
tuación real sobre costes y presupuestos y evaluar el
grado de utilización de los recursos humanos y ma-
teriales.

Criterios para la selección de la herramienta

Identificar la herramienta ideal para cada situación

es un tema de difícil generalización. Como suele su-
ceder con cualquier herramienta informática, nos en-
contramos con una gran cantidad de puntos de aná-
lisis tanto técnicos como funcionales.
Para concretar, destacamos a continuación los as-
pectos que hay que tener en cuenta y las opciones
disponibles:

• Acceso a la aplicación: acceso monousuario (apli-

cación de un único puesto de trabajo); acceso mul-
tiusuario (múltiples usuarios de una única orga-
nización); acceso multiusuario (múltiples usuarios
de más de una organización con acceso web).
• Restricciones de acceso a información: acceso
monousuario (no hacen falta restricciones); acce-

44
 so multiusuario (restricciones según grupos y ca-
tegorías de usuarios).
• Funcionalidades de gestión de proyectos: ges-
tión de recursos humanos; creación y seguimien-
to de proyectos; seguimiento presupuestario; ge-
neración automática de informes.
• Funcionalidades de gestión documental (solo si es
multiusuario): control de versiones; definición de
flujo de trabajo para la validación de documentos;
herramienta de distribución de documentación y
comunicación automatizada de liberación de ver-
siones.
• Seguridad: registro de accesos; control de palabras
clave; realización de copias de seguridad; expor-
tación/importación de datos; compatibilidad con
plataformas y paquetes ofimáticos.

La elección de la alternativa ideal es una cuestión

que dependerá de cada caso concreto. Hay que tener
en cuenta que posiblemente ninguna herramienta se
ajustará a todo lo que necesitamos y que la mayoría
de ellas nos darán muchas funcionalidades que no
utilizaremos nunca. También hay que ser realistas y
evaluar si se debe disponer de una herramienta es-
pecífica o podemos encontrar otras soluciones (una
simple hoja de cálculo). Y finalmente, cuando op-
temos por una herramienta informática, como cual-
quier otra herramienta de gestión de proyectos, una
vez implantada se debe utilizar dado que en caso con-

45
trario dejará de ser (para nosotros) una herramienta
como tal.

Herramientas en el mercado

Actualmente hay infinidad de herramientas infor-

máticas para la gestión de proyectos. No es fácil ele-
gir unas que puedan realmente resultar interesantes
por encima de las otras, dado que siempre dejaremos
por el camino algunas que pueden ser muy útiles.
A continuación os damos una breve información
de dos de las más conocidas, a pesar de que os invi-
tamos a llevar a cabo una búsqueda por internet para
que conozcáis algunas más.

Microsoft Project

Es la herramienta de gestión de proyectos desa-

rrollada por la multinacional norteamericana Micro-
soft. Esta herramienta forma parte del paquete ofi-
mático Microsoft Office. Se trata de una herramienta
pensada para el trabajo individual dado que es mono-
usuario. No obstante, hay versiones superiores orien-
tadas al trabajo colaborativo.
Como herramienta de gestión de proyectos, Mi-
crosoft Project es una herramienta valiosa y potente
que permite efectuar una gestión completa de pro-

46
yectos. Entre las principales características que pode-
mos destacar encontramos las siguientes:

• Facilidad para replicar proyectos (copiar y pegar).

• Integración plena con el resto de los componen-
tes de Office.
• Muchas funcionalidades para el control económi-
co de los proyectos.
• Visualización directa de diagramas Gantt y PERT.
• Funcionalidades de simulación: creación de ma-
cros programables; capacidad de hacer/deshacer
acciones a múltiples niveles; visualización desta-
cada de cambios aplicados.
• Creación intuitiva de informes con muchas plan-
tillas incluidas ya dentro del propio software.

La principal mejora que se podría introducir en el

software sería su conexión con un servidor Exchange.
Así, se podría gestionar la asignación de tareas a dife-
rentes recursos según estados de ocupación basados
en una agenda común. Actualmente, la herramienta
incorpora un sistema para hacerlo pero no funciona
del todo correctamente.
También hay que tener presente que el mecanis-
mo habitual para deshacer las últimas acciones solo
nos permite actuar sobre una única acción y, por lo
tanto, hay que ir guardando continuamente versiones
si queremos mantener la opción de volver atrás. Y
otro elemento que también da bastantes problemas

47
es el de copiar y pegar el calendario obtenido como
imagen en otras aplicaciones.
Vistas las ventajas y las limitaciones de esta herra-
mienta, veamos cómo se realiza la definición de un
proyecto con Microsoft Project. Consta de los pasos
siguientes:

1) Definir el proyecto en cuanto a la fecha de inicio.

2) Definir los periodos laborables generales y las fe-
chas de los festivos.
3) Crear una lista de las tareas del proyecto. Se re-
llena directamente en la cuadrícula del programa.
4) Organizar tareas en fases. Nos situamos en las ta-
reas que conforman la fase y con el botón «apli-
car sangría» construimos las dependencias.
5) Programar tareas. Se trata de determinar los
vínculos entre las tareas. Para hacerlo nos situa-
mos sobre las tareas que queremos vincular y nos
ayudamos de los botones del asistente de la parte
izquierda de la pantalla.
6) Vincular o adjuntar más información sobre ta-
reas. Del mismo modo que en otros programas
del paquete Office, podemos incluir hipervíncu-
los para adjuntar datos adicionales.

Podemos añadir a las tareas columnas con infor-

mación personalizada; establecer fechas límite; asig-
nar recursos. Esta asignación se hace según una sec-
ción específica del programa que, como podemos
imaginar, está completamente integrada con otros

48
programas habituales de Microsoft. Los datos intro-
ducidos en este apartado nos permitirán generar pre-
supuestos del proyecto.
Si disponemos de Project Server, también podre-
mos identificar riesgos del proyecto, agregar docu-
mentos al proyecto y publicar información del pro-
yecto en la web.
Finalmente, destacamos un par de utilidades más:
la creación de la línea de base y la visualización del
camino crítico. La creación de la línea de base per-
mite guardar el calendario inicial como planificación
base del proyecto, de manera que en todas las actua-
lizaciones posteriores que hagamos podremos con-
trolar las desviaciones. La visualización del camino
crítico se puede hacer seleccionando la vista de dia-
grama PERT y el programa nos indica en rojo el ca-
mino crítico del proyecto.
A pesar de que puede parecer complicado, el pro-
pio programa dispone de muchos asistentes que fa-
cilitan enormemente el trabajo.

OpenProj

Como contrapartida al software privativo, desta-

camos OpenProj como solución de software libre.
Esta herramienta, desarrollada por Projity, pone de
manifiesto que hay soluciones que no representan
ningún coste de licencia y que están dotadas de nu-
merosas funcionalidades.

49
 Podemos afirmar que OpenProj es una alternativa
completa a la opción presentada anteriormente. Ade-
más, tiene una ventaja adicional: es multiplataforma,
dado que podemos encontrar versiones tanto para
Windows como para Mac y Linux.
Evidentemente no todo son aspectos positivos.
Podemos decir que su estabilidad es inferior a la de
Microsoft Project y que el calendario previsto de nue-
vas versiones, a pesar de que el desarrollador lo ha
hecho público, no se está cumpliendo del todo.
Su uso es muy parecido al de Microsoft Project y
presenta la mayoría de sus funcionalidades excepto
las de informes, que son ligeramente inferiores. El
esquema de trabajo es el mismo que el comentado
para Microsoft Project.

50
CONSEJOS Y RECOMENDACIONES

Las bases teóricas son fundamentales para poder

llevar a cabo una correcta tarea como gestores de
proyectos. Pero esta función tiene unas implicacio-
nes que hacen necesario disponer de otras habilida-
des que no tienen nada que ver con la técnica. En es-
ta, creemos que hay que aplicar dos ideas principales.
La primera es que la gestión de las personas es la cla-
ve de nuestra actividad. Podemos usar todas las me-
todologías existentes, pero la empatía y la inteligencia
emocional ayudarán mucho a que nuestro proyecto
sea un éxito. Y la segunda es que, como en cualquier
oficio, la experiencia es un valor añadido muy impor-
tante. En la gestión y el desarrollo de proyectos el
uso de la experiencia nos permitirá resolver cualquier
problema dado que siempre tendremos un referente
que, de manera directa o mediante extrapolaciones,
se pueda aplicar al caso que nos ocupa.
De acuerdo con esto, a continuación se presentan
varias situaciones en torno a la gestión de proyectos

51
que pueden ser un punto inicial para el desarrollo de
una experiencia sólida.

La concepción del proyecto

En primer lugar, hay que conocer los requisitos

del cliente. Evaluaremos atentamente estos requisi-
tos dado que el éxito de un proyecto depende en gran
medida de conseguir plasmarlos en los resultados del
proyecto. Necesitamos pues que el cliente nos diga
cuáles son los requisitos, que nosotros los plasme-
mos en un documento y que el cliente lo valide.
Un error habitual en este estadio es tender a ge-
neralizar y pensar que los problemas y las necesida-
des de nuestro interlocutor son siempre los mismos
que pueden tener empresas y organizaciones de su
mismo sector, tamaño, etc. También es muy habitual
que no se elija correctamente el interlocutor que de-
be comunicarnos los requisitos del proyecto.
Encontramos un ejemplo de error en la aprecia-
ción de las necesidades del cliente en la definición
inicial de las unidades de los trenes de alta velocidad
implantados en España. En un primer momento no
se tuvo en cuenta que el tiempo habitual de viaje su-
peraba con creces el tiempo de duración máxima de
las baterías de los ordenadores portátiles. El perfil
mayoritario de los usuarios de este servicio son pro-
fesionales en viajes de negocios y tenían problemas

52
para conseguir poder trabajar durante todo el viaje.
Las nuevas unidades ya incorporan puntos de cone-
xión a red de 220V en clase turista.
En segundo lugar, se debe aclarar si el proyecto
puede tener o no un resultado definido. La definición
de un proyecto tiene que ser lo suficientemente cla-
ra como para permitir su ejecución. En algunos ca-
sos podemos tener muy claras las expectativas de los
usuarios, podemos tener muy claros los requisitos del
proyecto, pero podemos tener ante nosotros un pro-
yecto que tiene un resultado no definido.
En un caso como este, cualquier resultado obte-
nido podrá ser válido y hacer que el proyecto sea un
éxito. Por el contrario, determinar el resultado sin sa-
ber si es lo que queremos conseguir puede hacer que
el proyecto nos deje un mal sabor de boca a pesar de
haber permitido obtener un resultado magnífico. Un
ejemplo de proyecto sin resultado definido a priori es
la transformación de la ría de Bilbao. Sin embargo,
visitar hoy las cercanías del museo Guggenheim es
claramente un resultado maravilloso.
En tercer lugar, hay que definir de manera realis-
ta la financiación. Las estimaciones de los proyectos
son la herramienta que nos permite determinar su
viabilidad. Esta viabilidad está determinada por una
financiación del proyecto. En un exceso de optimis-
mo se suele ser muy blando en el momento de definir
las partidas económicas vinculadas a los proyectos y
esto hace que el coste real del proyecto sea mucho
más elevado de lo previsto. Por este motivo, en los

53
proyectos se pueden apreciar dos resultados diferen-
tes: se reduce el alcance del proyecto para acomodar-
lo a los recursos económicos disponibles o se incre-
menta la financiación y puede ser que se incremente
el periodo de ejecución o que otros proyectos no se
ejecuten.
Las obras públicas ejemplifican bien el caso en el
que la ejecución final no se ajusta a lo previsto debido
a un incremento de costes. Uno de los casos más co-
nocidos es que en nuevas urbanizaciones, por restric-
ciones económicas, no se incluyen las canalizaciones
para los servicios de telecomunicaciones y después
no es posible dotar de servicios al vecindario.
En cuarto lugar, hay que determinar si los requi-
sitos definidos harán que el usuario obtenga los re-
sultados previstos. No podemos olvidar que el usua-
rio del resultado del proyecto no somos nosotros. La
definición de un nuevo proyecto implica que el clien-
te o usuario nos indique sus requisitos. Estos requi-
sitos serán determinantes para que podamos definir
un resultado del proyecto. Lo que hay que evaluar es
realmente si con la definición de requisitos que se ha-
ga queda completamente definido el modo como el
usuario quiere hacer uso de los resultados previstos.
Un problema muy típico en la definición de un
proyecto es que le preguntemos al usuario cuál es el
problema o situación que quiere solucionar o mejo-
rar con el proyecto pero no le preguntamos de qué
manera quiere trabajar una vez que el proyecto esté
terminado. En estos casos es cuando definimos los

54
resultados de los proyectos para solucionar su pro-
blema pero con nuestra manera de trabajar.
Un caso típico de no pensar en el usuario final del
sistema es el de los formularios web de muchas em-
presas. Para ver a qué nos referimos, elegid cualquier
buscador de internet, introducid las palabras «alqui-
ler de coches» y visitad los tres primeros enlaces. En
unos casos veréis que son páginas web para conduc-
tores que quieren alquilar un coche y en otros que
son páginas donde los profesionales del alquiler de
vehículos dan la opción a los usuarios de acceder a
sus programas informáticos de soporte.

La planificación de lo desconocido

Otra situación a la que nos enfrentamos es que los

proyectos presentan a menudo características únicas.
En principio, la unicidad es una de las características
clave del concepto proyecto. En el momento en el
que la realización y la ejecución del proyecto pierden
unicidad deja de tener sentido como tal y pasa a ser
una actividad procedimentada.
En la planificación de un proyecto único se acepta
que existan grandes errores de planificación. Se de-
bería tener en cuenta que es prácticamente seguro
identificar otros proyectos que podamos extrapolar
para definir nuestro proyecto actual de manera más
cuidadosa.

55
 Un buen ejemplo de este tipo de proyectos es la
puesta en marcha de la TDT, que tiene unas caracte-
rísticas específicas que la hacen única y, por lo tanto,
sometida a una gran incertidumbre en su definición.
Algunos proveedores de equipamiento planificaron
este proyecto siguiendo los parámetros de la puesta
en marcha de redes de telefonía móvil.
Y a pesar de que la experiencia nos lleva a buscar
referencias en proyectos parecidos, no se puede con-
fundir la réplica de proyectos de gran similitud con su
clonación total. Un error habitual que podemos co-
meter es clonar proyectos tecnológicamente idénti-
cos pero que difieren en aspectos aparentemente se-
cundarios. Es posible que estos elementos secunda-
rios representen lo que lo hacen único.
Por ejemplo, la implantación de redes de telefo-
nía móvil en diferentes países ha representado una
opción de crecimiento para las empresas operadoras
pero estas han pecado de exceso de confianza. Algu-
nos de estos operadores interpretaron que se podía
encarar del mismo modo el desarriollo de una red
GSM en España que en algunos países de África. No
contaban con el hecho de que en estos países la pene-
tración existente de la telefonía fija era prácticamente
nula y que la accesibilidad al móvil hizo que en poco
tiempo el 35% de la población accediera al servicio.
La saturación de la red fue inmediata.
El camino crítico es otro elemento que será defi-
nidor del desarrollo de nuestro proyecto. La existen-
cia de un camino crítico al proyecto es el primer ele-

56
mento que puede introducir distorsiones en la dura-
ción del proyecto. El camino crítico se determina por
aquella concatenación de actividades que en caso de
retardo lo retrasan directamente. Es habitual confun-
dir esto con la concatenación de las principales ac-
tividades del proyecto (por su significación concep-
tual). Por ejemplo, en la migración de un operador
de móvil a otro nuevo, una gran corporación consi-
deró que el camino crítico afectaba básicamente a la
gestión de la portabilidad numérica de las líneas de
telefonía móvil. La sorpresa fue que un problema en
la logística de distribución de los terminales dejó a
buena parte de los trabajadores de la empresa sin te-
léfono móvil durante una semana. El camino crítico
no era un elemento vinculado a la tecnología.

La burocracia del proyecto

La documentación del proyecto debe ser un refle-

jo fiel de la situación y la ejecución del proyecto. Un
error habitual es considerar ciertos informes o docu-
mentos como una declaración de buenas voluntades
para el desarrollo correcto del proyecto. Es habitual
redactar actas de reuniones en las que alguna de las
partes del equipo de trabajo se hace cargo de cosas
que no puede lograr. Pues bien, hay que tener pre-
sente que las actas de reuniones son promesas por
escrito.

57
 Pongamos un caso real. En la realización de un
proyecto, una empresa de servicios incluyó en un acta
de reunión una frase en la que decía al cliente: «pon-
dremos a su disposición a todo el personal que sea
necesario para lograr el éxito del proyecto y su finali-
zación según los acuerdos efectuados». Fruto de esta
afirmación la empresa tuvo que contar con un equipo
de cuatro personas a tiempo completo durante tres
meses para cumplir la promesa y sin poder facturarlo
al cliente.
El calendario es otra herramienta de la documen-
tación del proyecto. Y como tal, ha sido definido para
facilitar la tarea de todo el equipo de trabajo. Si no se
hace uso de él, no se consigue sacar un rendimiento
adecuado y al final se deja de utilizar. Un caso típico
es la creación de un calendario o diagrama de Gantt
del proyecto en su inicio que no se vuelve a actuali-
zar. El otro caso relacionado es aquel en el que solo
una parte del equipo de trabajo utiliza el calendario
como herramienta de gestión de proyectos. Esto ha-
ce que en las reuniones de seguimiento del proyecto
o en las tareas de remisión de información al cliente
no todo el mundo utilice los mismos datos. Sea cual
sea el caso, implica que no se aprovechan las herra-
mientas disponibles.
La transferencia del conocimiento es otro elemen-
to importante en la gestión del proyecto. Hay que
garantizar que el destinatario de nuestros proyectos
disponga de toda la información para que pueda ex-
plotar los resultados de manera completa. Sucede a

58
menudo que en el momento de difundir los resulta-
dos al cliente, se suele dar documentación con un ni-
vel de detalle reducido, hecho que genera en el clien-
te la sensación de poco control respecto al sistema o
solución implantada y desconfianza con el proveedor
porque se tiene la percepción de que se busca man-
tener captado al cliente.
Un ejemplo recurrente lo encontramos en la im-
plantación de sistemas informáticos en las empresas.
Es habitual que los proveedores no suministren ma-
nuales de operación con un nivel de detalle aceptable.
Por este motivo, el uso del sistema por parte de los
usuarios se realiza de modo que no se logra el nivel
de mejora en la productividad que se esperaba.
Además de nuestros clientes, la transferencia del
conocimiento implica también a nuestra organiza-
ción. No podemos limitar al equipo de trabajo la ex-
periencia asociada con el proyecto. A veces, debido
al esfuerzo invertido en la documentación del pro-
yecto en cuanto a la entrega de información al clien-
te, a menudo queda fuera del alcance del proyecto el
traspaso de cierta documentación de tipo metodoló-
gico que hace referencia a este. En este caso el cono-
cimiento no se extiende más allá de los integrantes
del equipo de trabajo.
En muchas empresas las réplicas (más o menos
idénticas) de un proyecto no se hacen de manera
inmediata y por este motivo no siempre se pueden
mantener los equipos de trabajo (a menudo algunos
de los integrantes del equipo han abandonado la em-

59
presa). En algunos casos, si la documentación del
proyecto es limitada, la situación de réplicas de pro-
yectos se convierte en una nueva ejecución, con el
esfuerzo y coste asociado que esto implica.

La tecnología dentro del mundo real

Hay que tener en cuenta que los usuarios no po-

seen siempre el conocimiento que tenemos nosotros.
En el momento de definir e implantar un sistema hay
que pensar en todos los elementos vinculados a la
situación real del destinatario del proyecto. A veces,
sobrevaloramos la capacitación del cliente en algunos
aspectos y esto hace que haya problemas en la explo-
tación de la solución implantada.
En el caso de desarrollos informáticos, es muy ha-
bitual que el equipo de programación considere que
los conocimientos básicos de usuario son en realidad
conocimientos avanzados. Este error de apreciación
provoca que la usabilidad del aplicativo diseñado sea
muy difícil para el usuario definitivo. Tomemos por
ejemplo las herramientas informáticas utilizadas por
centros de atención de llamadas (call center). En prin-
cipio, estaban preparadas para que las utilizaran ope-
rarios con un nivel informático elevado y en cambio
el personal existente tenía una baja capacitación. El
resultado era una disminución de la calidad del ser-

60
vicio porque el personal no era capaz de utilizar co-
rrectamente el software.
Sumar más recursos técnicos no siempre puede
solucionar un problema tecnológico. Hay que ser
gestor de proyectos con una visión global de todos
los aspectos que forman parte de él. Esto supone que
por mucho que se conozca más una área que otra,
hay que tener suficiente sentido común para deter-
minar que las carencias tecnológicas no hay que so-
lucionarlas siempre con investigación. Podemos im-
plantar otras soluciones simplemente pagando algo
más.
Es habitual considerar que los problemas de tec-
nología se pueden solucionar únicamente mediante
recursos técnicos cuando en general se trata «simple-
mente» de un problema presupuestario. Por ejemplo,
en el caso de algunas torres para alojar equipamiento
de televisión y telefonía móvil se produjo un proble-
ma de suministro eléctrico derivado del hecho de que
las acometidas no permitían cubrir el pico de poten-
cia necesaria en el arranque. Para solucionarlo, mien-
tras no se podía mejorar el suministro se dotó a los
vehículos que iban a realizar tareas de mantenimiento
y reparación de un equipo electrógeno que permitía
dar la potencia adicional.
Otra situación que puede causar inconvenientes
es considerar que la solución tecnológica implantada
puede aportar soluciones a todos los problemas. Es-
to en general es cierto por los problemas preexisten-
tes, pero lo que la gente olvida es que aparecerán nue-

61
vos. Sobrevalorar una tecnología cuando todavía no
ha sido suficientemente probada puede implicar un
fracaso en el proyecto. Las características de la nue-
va herramienta suelen ser validadas generalmente en
el laboratorio y no se dispone de datos procedentes
de casos reales. El resultado es que las características
reales no son siempre tan buenas como las previstas
inicialmente.
Un ejemplo de esta tendencia a considerar la nue-
va herramienta como una panacea es la transmisión
de vídeo en alta calidad por los sistemas de telefonía
móvil. Una vez instaurada no se logró el resultado
esperado dado que estas transmisiones penalizan el
ancho de banda disponible para el resto de los usua-
rios que están conectados a la misma estación base.
Como resultado no se puede comercializar el servi-
cio tal como estaba previsto dado que no se puede
garantizar su calidad.

¿Cómo se incluyen las leyes en el proyecto?

¿Es legal lo que estamos haciendo? Hay que pre-

guntárselo. Como se ha indicado anteriormente, la
polivalencia es una de las claves de éxito de un buen
director de proyectos. Un proyecto tiene significado
dentro del entorno en el que operará y por lo tanto
todas las implicaciones legales deben estar conside-
radas desde la fase de definición del proyecto. A me-

62
nudo los directores de proyectos que tienen un perfil
eminentemente técnico caen en el error de no tomar
en consideración la totalidad de las cuestiones lega-
les que pueden afectar a un proyecto. Consideran, en
general, que no forman parte de su ámbito de com-
petencias. Pero un ejemplo nos da el alcance de los
problemas que esta carencia puede generar. La im-
plantación de redes de televisión por cable promovi-
das por los vecinos de muchos pueblos de Andalucía
fue muy habitual en los años ochenta y noventa. La
implantación de los operadores de cable desde el año
1999 implicó un alud de denuncias por parte de los
titulares de las redes, dado que las redes preexistentes
no disponían del correspondiente título habilitador.
Como acabamos de ver, se deben considerar to-
das las implicaciones legales desde la fase de defini-
ción. Un proyecto tiene significado dentro del en-
torno en el que operará y por lo tanto habrá que
considerar algunas fases del proyecto técnico que im-
pliquen la realización de tareas para la consecución
de permisos y licencias. Y hay que hacer coincidir el
proyecto técnico con la tramitación de las licencias y
permisos, dado que en caso contrario nos podemos
encontrar con que se desestima la solicitud de una
licencia porque el proyecto técnico no se ajusta a lo
que es preceptivo administrativamente.
Es revelador en este sentido el caso de algunas
emisoras de FM que iniciaron la instalación de los
equipos radiantes y los radioenlaces antes de conse-
guir la licencia de emisión. Posteriormente, a pesar de

63
resultar adjudicatarios de la concesión, algunos ex-
plotadores se encontraron con que el emplazamiento
donde tenían licencia para emitir no era el lugar don-
de habían ubicado sus centros emisores y la vuelta
atrás no era directa ni en algunos casos viable.
Finalmente, hay que tener en consideración una
cuestión de responsabilidades. La profesión de inge-
niero, igual que otras profesiones liberales, está so-
metida a un régimen estricto de responsabilidades
y sanciones. Muchos profesionales desconocen sus
responsabilidades reales y el límite de su actividad,
por lo que hay que informar al colegio profesional
antes de ejecutar cualquier trabajo. Se han dado ca-
sos en los que ingenieros han firmado actas de cer-
tificación de instalaciones sin tan siquiera visitarlas.
Los problemas aparecen cuando algún usuario hace
alguna denuncia.

64
CLAVE DE ÉXITO PROFESIONAL

La gestión y el desarrollo de proyectos es una de

las claves del desarrollo profesional de los ingenieros
y otros profesionales de formación técnica.
Evidentemente esta actividad requiere una forma-
ción específica en técnicas que nos permitan adoptar
ciertas habilidades. Pero lo que no podemos olvidar
es que la gestión de proyectos tiene mucho de ges-
tión de las personas y de sentido común, lo que hace
que la experiencia sea tanto o más importante que la
formación.
A modo de conclusión, resaltamos algunos de los
principales conceptos tratados en este libro.

• Un proyecto es una acción en la que recursos hu-

manos, financieros y materiales se organizan de
una nueva manera para llevar a cabo una tarea di-
ferente, en la que, considerando unas especifica-
ciones y dentro de unos límites de costes y tiem-
pos, se intenta conseguir un cambio beneficioso

65
 dirigido por unos objetivos cualitativos y cuanti-
tativos.
• Para poder afrontar el desarrollo de un proyecto,
habrá que tener muy claro cuáles son sus objeti-
vos y habrá que efectuar una serie de valoraciones
iniciales que nos permitan determinar la razona-
bilidad de su ejecución. Las valoraciones cubrirán
los elementos técnicos, operativos y económicos
de los proyectos.
• La planificación de un proyecto determina QUÉ
hay que hacer, QUIÉN debe hacerlo, CUÁNDO
y con QUÉ RECURSOS se contará para llevar a
cabo las tareas que hay que ejecutar. La planifica-
ción es la premisa del control, dado que solo se
puede controlar lo que está adecuadamente plani-
ficado.
• La planificación se lleva a cabo mediante diferen-
tes herramientas, entre las que destacamos el dia-
grama de Gantt y el de PERT.
• La planificación pierde su sentido si después no se
realiza el seguimiento del proyecto. Las desviacio-
nes respecto a lo que se ha previsto inicialmente
implican reprogramar el proyecto y actualizar los
documentos asociados.
• La realización de todas estas tareas hay que hacer-
la con el máximo de garantías y aprovechando las
herramientas disponibles. Por este motivo se re-
comienda hacer uso de los programas informáti-
cos existentes. Hay muchos y muy variados. Po-

66
demos elegir dos de los más conocidos: Microsoft
Project y OpenProj.

67
Bibliografía

Andrés Gay, Mercedes; Yeves López, Elvira  (2007).  Project 2007

(Guías prácticas). Anaya Multimedia.
Bataller Díaz, Alfons (2007). Gestión y desarrollo de proyectos. (Materiales
para la UOC).
Brown, Mark (2005). Gestión de proyectos en una semana. Barcelona: Ges-
tión 2000.
Chatfield Carl, S. (2004). Microsoft Office Project 2003 (paso a paso). Mc-
graw-Hill / Interamericana de España.
Domingo Ajenjo, Alberto (2005). Dirección y gestión de proyectos: un en-
foque práctico. RA-MA.
Drudis, Antonio (1999). Gestión de proyectos: cómo planificarlos, organizarlos
y dirigirlos. Barcelona: Gestión 2000.
Gutiérrez de Mesa, José Antonio (2008). Planificación y gestión de pro-
yectos informáticos. Universidad de Alcalá de Henares.
Rodney Turner, J. (2005). Las personas en la gestión de proyectos. AENOR.
Asociacion Española de Normalización y Certificación.
Sacré, Regis (2004). Gestión eficaz de un equipo de proyecto. AENOR. Aso-
ciacion Española de Normalización y Certificación.

69
Serer Figueroa, Marcos (2001). Gestión integrada de proyectos. Barcelona:
Edicions UPC.

70