Módulo 1

Conceptos de la
administración de
proyectos.
1. Conceptos de la
administración de
proyectos
1.1 ¿Qué es un proyecto?
Las definiciones del concepto de Proyecto son numerosas, y muchas de
ellas están vinculadas a la tipología específica o ámbito de actuación en la
que se desarrolla una determinada actividad profesional.

La palabra PROYECTO suele ser usada por lo general en diferentes

sentidos.

Por un lado se suele hablar de proyecto en el sentido de una idea o

intención: “…tengo el proyecto de hacer un crucero el año que viene….”.

Otra acepción muy comúnmente usada es la que se da en el mundo de la

arquitectura o la ingeniería de obra, el proyecto como el plano: “…pidió
que le alcance el proyecto…” o “… el arquitecto ha preparado diferentes
proyectos para la casa….”.

Una tercera acepción tiene que ver con toda la documentación

correspondiente a los análisis previos de algo que se piensa ejecutar,
“…prepararé un proyecto y discutiremos el documento…”

En cualquiera de los casos la definición es correcta aunque aún nos queda

una cuarta acepción para esta palabra que resume el concepto que
tomaremos para abordar la materia, y es la de Proyecto como trabajo: “el
desarrollo del proyecto avanza según lo planeado….”

Tomando como referencia el diccionario de la Real Academia Española de

la Lengua encontramos las siguientes acepciones en las que se define

1
proyecto como: “designio o pensamiento de ejecutar algo” y como
“conjunto de escritos, cálculos y dibujos que se hacen para dar idea de
cómo ha de ser y lo que ha de costar una obra de arquitectura o de
ingeniería”.
Si nos centramos en la primera definición podemos observar un aspecto
creativo e intelectual del proyecto, aunque aún en el mundo de las ideas,
mientras que la segunda hace referencia a una naturaleza documental.

No obstante todo esto, en el ámbito de la Dirección y Gestión de

proyectos, las definiciones más habituales del término proyecto hacen pie
en los aspectos de utilización y control de los recursos (humanos,
materiales, intelectuales, financieros, otros.) y a las actividades que se
llevan adelante para conseguir el producto objeto del proyecto.

A continuación, introduciremos y revisaremos algunas de las definiciones

más habituales de proyecto, relacionadas con su dirección y gestión:

Una de las definiciones más completa es la que proporcionó J. Rodney

Turner en su "Handbook of Project-Based Management" ya que incorpora
los elementos que son básicos para la comprensión de lo que es un
proyecto:

“Un proyecto es una acción iniciada por la empresa en la que recursos

humanos, financieros y materiales se organizan de una nueva forma para
acometer un trabajo único, en el que, dadas unas especificaciones y
dentro de unas limitaciones en costo y tiempo, se intenta conseguir un
cambio beneficioso definido por unos objetivos cualitativos y
cuantitativos”.

El Project Management Institute (PMI) establece la siguiente definición:

"proyecto es un esfuerzo temporal encaminado a crear un producto o

servicio único" (PMBOK, 2004).

Según el PMI, todos los proyectos presentan una serie de características

comunes, como el hecho de ser desarrollados por personas, estar
condicionados por recursos limitados, y ser planificados, ejecutados y
controlados desde este punto de vista.

Una definición simple pero a la vez muy completa de proyecto y que

tomaremos como base es la siguiente:

“Un proyecto es un trabajo singular con unas fechas definidas de inicio

y finalización (calendario), una especificación clara del objetivo o
alcance de la tarea, un presupuesto preestablecido y , habitualmente,
una organización temporal que se desmantela cuando termina el
proyecto” J. Lewis.

2
 1.2 Atributos de un proyecto
A los efectos de la materia vamos a enfocar el concepto haciendo
hincapié en los siguientes atributos:
 es un trabajo
 tiene un objetivo único o singular
 tiene un tiempo limitado
 tiene un presupuesto acotado
Siempre que esas características se cumplen estamos hablando de
“proyecto”.

1.2.1 Proyectos y procesos

Los proyectos son llevados a cabo por organizaciones que generan
trabajo, este trabajo puede llevarse a cabo en la modalidad de proyecto
o de proceso.

Un proyecto se diferencia de otros tipos de trabajos fundamentalmente

es su carácter de “única vez”, es decir, por más que pueda ejecutar
muchos proyectos similares, este es único y diferente en sus
condiciones y producto final, no es repetitivo, ni rutinario.
En principio podría pensarse que un proyecto es igual que el resto de
operaciones que desarrollan las organizaciones. Sin embargo, hay
aspectos en los proyectos, puestos de manifiesto en la definición
anterior que los diferencian claramente de otros tipos de trabajo que se
desarrollan por proceso.
Para comprender mejor repasemos estas diferencias en el siguiente
cuadro:

Proyecto Proceso
Muere al finalizar No muere, no termina
Objetivo particular, ejecutados por única vez Repetitivos, secuenciales, ordinarios
El tiempo no está acotado, existe para
Tiempo determinado, acotado.
perdurar en el tiempo.
Revolucionarios (cambios importantes) Evolutivo (mejora continua)
Equipos variables Equipos relativamente estables
Los recursos entran y salen en la medida Los recursos están disponibles por más
que son requeridos tiempo
Todo está mayormente definido, menos
Mucha incertidumbre, más riesgos
riesgos
Tabla 1.1: Proyectos vs. Procesos

3
Si pensamos en actividades que puedan llevarse a cabo como proyecto
podemos mencionar: la construcción de un puente, el desarrollo e
implementación de un determinado software, en ambos casos estamos
refiriendo a actividades que tienen objetivo único y presupuesto y
tiempo acotados.

Por otra parte si queremos pensar en trabajos que naturalmente se

realizan por proceso podemos mencionar: la fabricación en serie de un
producto, un determinado modelo de auto por ejemplo, o la
administración de bases de datos.

1.2.2 Administración de proyectos

La administración de proyectos es el conjunto de actividades que
deberá llevar adelante el Gerente del Proyecto para conseguir los
objetivos planteados.

La Administración de Proyectos es una disciplina de gestión que existe y

se implementa desde tiempos milenarios, pero su consolidación como
materia de estudio proviene principalmente de los países anglosajones.
Es probablemente por esta razón por lo que el término "Project
Management" se ha convertido en el modo en que nos referimos a esta
disciplina aún traspasando las fronteras de la lengua inglesa.

A esto se suma el hecho de que la institución más difundida a nivel

mundial en esta materia es el Project Management Institute (PMI).

El PMI es una institución sin fines de lucro que ha sido fundada en 1969
en EEUU por y para profesionales de dirección de proyectos.

Desde su fundación hasta nuestros días su crecimiento ha sido tal que le

ha permitido convertirse en la principal organización profesional sin
fines de lucro en administración de proyectos.

Actualmente cuenta con más de 200.000 miembros en más de 125

países.

Entre sus principales objetivos podemos mencionar que brinda apoyo

profesional a los Project Managers mediante:

 Establecer y mantener actualizados los estándares de

administración de proyectos.
 Actualización permanente: Cursos, Seminarios y Conferencias.
 Exposiciones y Foros.
 Certificación.
 Bibliografía y Publicaciones.

4
  Grupos de interés especial.
 Bolsa de trabajo.
 Reconocimiento del gerenciamiento de proyectos como una
disciplina profesional.
 Proveer contactos interdisciplinarios

El estándar de procesos definidos por el PMI, el PMBOK (Project

Management Body Of Knowledge) ha sido adoptado como norma ANSI
y está siendo referenciado por la OSI. y adoptado por organizaciones
profesionales reconocidas mundialmente, como el IEEE.

La certificación profesional que el PMI otorga - PMP (Project

Management Profesional) cada vez es más reconocida y demandada en
la industria por empresas y profesionales como garantía de idoneidad
del profesional a nivel mundial.

El PMI define el “Project Management” como:

“la aplicación de conocimientos, habilidades, herramientas y técnicas a
las actividades del proyecto, a efectos de satisfacer o exceder las
necesidades y expectativas de los stakeholders del proyecto".

A los efectos de esta Asignatura usaremos estos términos con el mismo

significado: Gerenciamiento, Gestión o Administración de Proyectos.
La Administración de Proyectos implica balancear y a menudo negociar:

 demandas de recursos
 requerimientos de stakeholders
 necesidades y expectativas

Habrás notado en este punto que se ha introducido un nuevo concepto,

el de “stakeholder”. No traducimos este término por no encontrar una
traducción que verdaderamente refleje lo que este término significa en
todo su espectro:

Un stakeholder es cualquier individuo u organización involucrado,

afectado o con intereses en el proyecto.

1.2.3 Funciones de la dirección de proyectos.

La dirección de proyectos se logra mediante la aplicación e integración
de los procesos de dirección de proyectos de inicio, planificación,
ejecución, seguimiento y control, y cierre.
El director del proyecto es la persona responsable de alcanzar los

5
objetivos del proyecto. La dirección de un proyecto incluye:
 Identificar los requisitos
 Establecer unos objetivos claros y posibles de realizar
 Equilibrar las demandas concurrentes de calidad, alcance, tiempo
y costos
 Adaptar las especificaciones, los planes y el enfoque a las diversas
inquietudes y expectativas de los diferentes interesados.
Una buena forma de describir la tarea de un Project Manager es
plantear que él se ocupa de “hacer que las cosas ocurran”. Nótese que
no estamos hablando de hacer las cosas, sino, más bien de hacer que
ocurran, vale decir que su visión será general y no particular o de detalle
puesto que es él quien debe organizar y enlazar las partes.
Otro aspecto de relevante importancia es el hecho de que el
Administrador de Proyecto tiene la importante misión de cuidar y
balancear la “triple restricción”.
Llamamos triple restricción a las tres dimensiones básicas en torno de
las cuales gira el proyecto: Alcance, Tiempo y Costo. (Ver Figura 1.1).
Claramente una mejora en una de las tres dimensiones perjudica alguna
de las otras, por lo que será función del Director de Proyecto tomar las
decisiones apropiadas en función de las necesidades del proyecto y las
expectativas de los stakeholders. ¡Un verdadero desafío! Aún así, a
muchos nos gustan los desafíos y estamos dispuestos a afrontarlos.
La figura 1.1 ha sido creada por la autora para mostrar la triple
restricción a la vez que se destaca lo que el autor considera que es el
“verdadero objetivo del proyecto”. Comúnmente definimos el objetivo
del proyecto en términos de lo que debe lograrse a nivel de producto
final. Sin embargo, a un Administrador de Proyectos no se le paga por el
solo hecho de lograr las cosas, sino que debe lograrlas en un tiempo y
con un costo determinado.

Figura 1.1 - La triple restricción y el “verdadero” objetivo del proyecto - Ing. Iris
Gastañaga

6
Así llegamos al punto en que podemos decir que el objetivo final del
proyecto será lograr el producto del proyecto en tiempo y presupuesto, y
es particularmente este punto el que hace que la administración de
proyectos requiera tanta atención.
Un hecho a destacar es que la importancia de las funciones de dirección y
gestión varía a lo largo de las fases del proyecto.
Es evidente que la construcción de un objeto involucra más recursos
(humanos, materiales y financieros) que su definición y diseño.
Por tanto, el "Project Management" es más importante en las fases
constructivas (ejecución de una instalación, fabricación de un producto,
construcción de una obra) que en las fases creativas (diseño, estudio de
soluciones o anteproyecto), y no sólo por la mayor dificultad que supone
gestionar un mayor volumen de tareas o de recursos, sino por la implícita
repercusión económica que conlleva cada una de las decisiones
adoptadas.
En las fases creativas, las labores de dirección y gestión se limitan
fundamentalmente al entorno del equipo del proyecto o al del
departamento de diseño, mientras que en las constructivas involucran
materiales, maquinaria, operarios, proveedores, subcontratistas.
Es decir, tanto las habilidades de dirección de proyectos como las técnicas
de gestión tienen más aplicación y resultan más necesarias cuanto más
avanzado se encuentre el desarrollo del proyecto (véase 1.2). Sin
embargo, debe tenerse en cuenta que las modernas tendencias en
gestión de proyectos proponen transferir un mayor esfuerzo a las fases
de diseño conceptual o básico, con objeto de minimizar los errores de
diseño (que pueden llegar a convertirse en costosos errores
constructivos).

Figura 1.2: Nivel de recursos involucrados en el desarrollo de un proyecto

7
Así mismo, cada vez se da mayor importancia al desarrollo de trabajo en
equipo y a la colaboración entre grupos multidisciplinarios, lo que a su vez
genera que se ponga mayor énfasis en las habilidades de dirección y
motivación de recursos humanos.

Con el objeto de facilitar la gestión, los directores de proyectos o la

organización pueden dividir los proyectos en fases, con los enlaces
correspondientes a las operaciones de la organización ejecutante. El
conjunto de estas fases se conoce como ciclo de vida del proyecto.
Muchas organizaciones identifican un conjunto de ciclos de vida
específicos para usarlos en todos sus proyectos, según su tipo “Las fases
del proyecto son divisiones dentro del mismo proyecto, donde es necesario
ejercer un control adicional para gestionar la conclusión de un entregable
mayor. Las fases del proyecto suelen completarse de manera secuencial.
Pero en determinadas situaciones de un proyecto pueden superponerse.
Por su naturaleza de alto nivel, las fases del proyecto constituyen un
elemento del ciclo de vida de un proyecto. Una fase del proyecto no es un
grupo de procesos de dirección de proyectos.” (PMBoK, 4º Edición, PMI).

Cuando hablamos de la construcción de un sistema, es fundamental

entender la diferencia entre proyectos, medios que produce y producto
obtenido mediante esos medios por el proyecto:

• Productos: Son aquellos bienes o servicios que la organización

fábrica o vende conforme señala su misión. Los productos generan
ingresos y de esta manera se cumple el objetivo del proyecto.
• Medios: Se requieren para producir productos. Pueden ser
equipos, diseño de productos, hardware, software, redes de
distribución, gestión de procesos o grupos organizados de personas.
• Proyectos: Son iniciados por las organizaciones para producir,
construir, mantener o renovar medios de producción. Son el vehículo,
coherente con el alcance del trabajo y la organización del mismo,
requerido para producir medios o elementos de producción.

1.3 Factores que restringen el éxito

del proyecto
Muchos pueden ser los factores que restringen el éxito de los proyectos.
Para tratar este tema recurriremos al autor Steve Mc Connell, quien ha
desarrollado una lista con los 36 errores clásicos que se cometen en los
proyectos de sistemas. A esta lista, Mc Conell le llama “errores clásicos” y
los clasifica en 4 categorías:

8
1.3.1 Errores relacionados con las Personas:
1 - Motivación débil
2 - Personal mediocre
3 - Empleados problemáticos incontrolados
4 - Hazañas
5 - Añadir más personal a un proyecto retrasado
6 - Oficinas repletas y ruidosas
7 - Fricciones entre los clientes y los desarrolladores
8 - Expectativas poco realistas
9 - Falta de un promotor efectivo del proyecto
10 - Falta de participación de los implicados
11 - Falta de participación del usuario
12 - Política, antes que desarrollo
13 - Ilusiones

1.3.2 Errores relacionados con el Proceso:

14 - Planificación excesivamente optimista.
15 - Gestión de riesgo insuficiente.
16 - Planificación insuficiente
17 - Abandono de la planificación bajo presión
18 - Fallos de los contratados
19 - Pérdida de tiempo en el inicio difuso
20 - Escatimar en las actividades iniciales
21 - Diseño inadecuado
22 - Escatimar en el control de calidad
23 - Control insuficiente de la directiva
24 - Convergencia prematura o excesivamente frecuente
25 - Omitir tareas necesarias en la estimación
26 - Planificar ponerse al día más adelante
27 - Programación a destajo.

1.3.3 Errores relacionados con el Producto:

28 - Exceso de requerimiento.
29 - Cambio de las prestaciones.
30 - Desarrolladores meticulosos.
31 - Tiras y aflojes en la negociación.
32 - Desarrollo orientado a la investigación.

9
1.3.4 Errores relacionados con la Tecnología:
33 - Síndrome de la panacea
34 - Sobreestimación de las ventajas del empleo de nuevas
herramientas y métodos.
35 - Cambiar de herramientas a mitad del proyecto.
36 - Falta del control automático del código fuente.

1.4 Ciclo de vida de un proyecto

Podemos plantear los trabajos del Proyecto desde dos miradas; la
primera es el ciclo de vida de proyecto que se necesita hacer para hacer
el trabajo y la segunda es el ciclo gestionar el proyecto.
Los proyectos tienen comienzo, medio y fin. Este dato puede parecer
evidente, pero si se trabaja en gestión de proyectos, el momento del ciclo
vital en que se encuentra será de la mayor importancia, ya que influirá
sobre lo que deberá hacer y sobre las opciones que se le presentarán.
Para facilitar la gestión, los directores de proyectos o la organización
pueden dividir los proyectos en fases, con los enlaces correspondientes a
las operaciones de la organización ejecutante. El conjunto de estas fases
se conoce como ciclo de vida del proyecto. Muchas organizaciones
identifican un conjunto de ciclos de vida específico para usarlo en todos
sus proyectos.

1.4.1 Fases de un Proyecto

Ahora bien, es momento de pensar entonces, que etapas o fases
corresponden a un proyecto. Si bien esto depende mucho del tipo de
proceso y del tipo de proyecto que se está llevando adelante, podemos
decir que todo proyecto tendrá al menos una Fase de Inicio, una o más
Fases Intermedias y una Fase Final.

Figura 1.3: Fases del Proyecto - PMBoK PMI – 2004

10
La transición de una fase a otra dentro del ciclo de vida de un proyecto
generalmente implica y, por lo general, está definida por alguna forma de
transferencia técnica. Generalmente, los productos entregables de una
fase se revisan para verificar si están completos, si son exactos y se
aprueban antes de iniciar el trabajo de la siguiente fase. No obstante, no
es inusual que una fase comience antes de la aprobación de los productos
entregables de la fase previa, cuando los riesgos involucrados se
consideran aceptables. Esta práctica de superponer fases, que
normalmente se realiza de forma secuencial, es un ejemplo de la
aplicación de la técnica de compresión del cronograma denominada
ejecución rápida.

No existe una única manera, que sea la mejor, para definir el ciclo de vida
ideal de un proyecto. Algunas organizaciones han establecido políticas
que estandarizan todos los proyectos con un ciclo de vida único, mientras
que otras permiten al equipo de dirección del proyecto elegir el ciclo de
vida más apropiado para el proyecto del equipo. Asimismo, las prácticas
comunes de la industria a menudo conducen a usar un ciclo de vida
preferido dentro de dicha industria.

Los ciclos de vida del proyecto generalmente definen:

 Qué trabajo técnico se debe realizar en cada fase (por ejemplo, ¿en
qué fase se debe realizar el trabajo del arquitecto?).
 Cuándo se deben generar los productos entregables en cada fase y
cómo se revisa, verifica y valida cada producto entregable.
 Quién está involucrado en cada fase (por ejemplo, la ingeniería
concurrente requiere que los implementadores estén involucrados en
las fases de requisitos y de diseño).
 Cómo controlar y aprobar cada fase.
Las descripciones del ciclo de vida del proyecto pueden ser muy generales
o muy detalladas. Las descripciones muy detalladas de los ciclos de vida
pueden incluir formularios, diagramas y listas de control para
proporcionar estructura y control.
La mayoría de los ciclos de vida de proyectos comparten determinadas
características comunes:
 En términos generales, las fases son secuenciales y, normalmente,
están definidas por alguna forma de transferencia de información
técnica o transferencia de componentes técnicos.
 El nivel de costo y de personal es bajo al comienzo, alcanza su nivel
máximo en las fases intermedias y cae rápidamente cuando el
proyecto se aproxima a su conclusión. La Figura 1.4 ilustra este patrón.

11
  El nivel de incertidumbre es el más alto y, por lo tanto, el riesgo de
no cumplir con los objetivos es más elevado al inicio del proyecto. La
certeza de terminar con éxito aumenta gradualmente a medida que
avanza el proyecto.
 El poder que tienen los interesados en el proyecto para influir en las
características finales del producto del proyecto y en el costo final del
proyecto es más alto al comienzo y decrece gradualmente a medida
que avanza el proyecto. La Figura 1.4 ilustra este hecho. Una de las
principales causas de este fenómeno es que el costo de los cambios y
de la corrección de errores generalmente aumenta a medida que
avanza el proyecto.

Figura 1.4: Influencia de los Stakeholder a lo largo del tiempo - PMBoK PMI – 2004

Aun cuando muchos ciclos de vida de proyectos tienen nombres de fases

similares y requieren productos entregables similares, muy pocos ciclos
de vida son idénticos. Algunos tienen cuatro o cinco fases, pero otros
pueden tener nueve o más. En una misma área de aplicación pueden
darse variaciones significativas.
El ciclo de vida del desarrollo de software de una organización puede
tener una única fase de diseño, mientras que otro puede tener fases
separadas para el diseño arquitectónico y el detallado. Los subproyectos
también pueden tener distintos ciclos de vida de proyectos. Por ejemplo,
una empresa de arquitectura contratada para diseñar un nuevo edificio
de oficinas participa primero en la fase de definición del propietario,
mientras hace el diseño, y luego en la fase de implementación del
propietario, mientras da soporte al esfuerzo de construcción. El proyecto
de diseño del arquitecto, sin embargo, tendrá su propia serie de fases,
desde el desarrollo conceptual, pasando por la definición e
implementación, hasta llegar a la conclusión. El arquitecto puede,

12
inclusive, tratar el diseño de los edificios y el soporte a la construcción
como proyectos separados, cada uno con su propio conjunto de fases.

1.4.2 Áreas de Conocimiento de la Gestión de

Proyectos
Una vez se ha procedido a delimitar los conceptos de dirección y gestión
de proyectos, resulta interesante establecer qué funciones y aspectos
cubre esta función.
Uno de los enfoques más sistemático y estructurado sobre el “Project
Management” es el denominado “Cuerpo de conocimientos” que ha
elaborado el PMI1. Según éste, la dirección y gestión de proyectos abarca
nueve grandes áreas, que seguidamente se enumeran:

Figura 1.5: Áreas de Conocimiento del Project Management - PMBoK PMI – 2004

A efectos de su estudio, el PMI define nueve Áreas de Conocimiento que

un Project Manager debe dominar para convertirse en un buen
Administrador de Proyectos que a continuación se explican:

 Integración del proyecto: Estudia las necesidades de coordinación

entre los diferentes elementos del proyecto. Para ello resulta
fundamental la planificación global del proyecto, el seguimiento de su
desarrollo, y el control de los cambios, a lo largo del diseño,
planificación y ejecución del proyecto. Es decir, comprende todos los
procesos necesarios para asegurar que los distintos elementos del
proyecto van a ser coordinados adecuadamente.

 Alcance del proyecto: Tiene por objetivo asegurar que todos los
trabajos necesarios para terminar el proyecto con éxito sean previstos
y considerados. Debe analizarse el ciclo de vida completo del proyecto.

1
PMBoK: Project Management Body of Knowledge (PMI, 2004)

13
 Comprende los procesos de planificación, definición, verificación y
control de cambios en el alcance.

 Tiempos del proyecto: Trata de conseguir que el proyecto termine

en el plazo establecido. Incluye la definición de las actividades, su
ordenación, la estimación de la duración de las actividades, el
desarrollo de las mismas y el control del cumplimiento del programa
del proyecto.

 Costos del proyecto: Tiene como objetivo asegurar que el proyecto

se concluya dentro del presupuesto aprobado. Necesita la planificación
de recursos, estimación de costos, cálculo de costos y control de los
mismos.

 Calidad del proyecto: Incluye los procesos necesarios para asegurar

que el proyecto cubrirá las necesidades y especificaciones para las que
fue desarrollado. Consta de planificación de la calidad, aseguramiento
de la calidad y control de la misma.

 Recursos Humanos del proyecto: Su objetivo es optimizar el

aprovechamiento de la labor de las personas comprometidas en el
proyecto. Requiere estudiar la organización de dichas personas, su
selección y contratación, y la dirección del funcionamiento del equipo.

 Comunicaciones en el proyecto: Su objetivo es facilitar la adecuada

generación, recepción, difusión, almacenamiento y archivo último de
la información del proyecto. Requiere la planificación de
comunicaciones, la distribución de información, la elaboración de
informes, así como la documentación necesaria para el cierre
administrativo del proyecto.

 Riesgos del proyecto: Tiene como objetivo identificar los factores

de riesgo del proyecto, analizar sus posibles repercusiones, y preparar
la respuesta ante los mismos. Requiere definir las causas de riesgo,
cuantificar su impacto, desarrollar las respuestas ante los riesgos
existentes, y controlar la implementación de las respuestas previstas.

 Adquisiciones en el proyecto: Estudia los procesos necesarios para

adquirir bienes y servicios fuera de la organización donde se desarrolla
el proyecto. Requiere la planificación de los aprovisionamientos, la
selección de los proveedores, la elaboración y tramitación de las
ofertas y contratos, y el cierre de los mismos. Estudia las compras, los
proveedores y las contrataciones.
Basta con enumerar estas grandes áreas, para comprender el enorme
campo de conocimientos que abarca la dirección y gestión de proyectos.

14
1.5 Influencias organizacionales.
La realización de una gran mayoría de proyectos requiere de la
participación de diferentes actores, lo que se traduce en la necesidad de
crear una organización, que además deberá ser orientada a satisfacer los
objetivos del proyecto. En la medida que los participantes adquieren
experiencia en una tipología de proyectos, y en especial la adquieren sus
responsables, las formas de organización que adopta el grupo vendrán
dadas en gran parte por estas experiencias de éxitos y fracasos anteriores
y, en función de ellas se ordenarán y asignarán los recursos y tareas,
intentando reproducir las prácticas satisfactorias y descartando las
negativas.

Cuando un proyecto se inicia, se generan ciertas expectativas, referidas

no sólo a sus efectos en cuanto al logro de los objetivos técnicos, sino que
también se consideran los resultados que su realización tendrá sobre los
participantes, las organizaciones y el medio ambiente. Cada una de las
personas que trabaja y se dedica total o parcialmente al desarrollo de un
proyecto espera que de su trabajo individual o colectivo se obtengan
beneficios que cubran al menos parte de sus necesidades y aspiraciones.
Del mismo modo que las personas, las empresas que participan en un
proyecto también esperan resultados que se traduzcan en beneficios, que
no siempre serán directamente de carácter económico.

Como veremos, para la realización de un proyecto concurren distintos

elementos, factores y entidades que generan las fuerzas que impulsan las
actividades traduciéndose en resultados que tienen una cierta
aleatoriedad. Cualquier proyectista tiene claro que los resultados no se
obtienen de la mera aplicación de una ecuación o una fórmula que
garantice cierto nivel de resultados, ya que son muchas las variables
exógenas e incontrolables que afectan el transcurso del proyecto en
cualquier momento a través de sus fases.

1.5.1 Los Proyectos y la estructura organizacional

Describiremos con el nombre de estructura organizacional a la
distribución y combinación de las distintas actividades de una empresa u
organismo, con vistas a asegurar el desarrollo de los objetivos que le han
sido atribuidos y tratando de garantizar una dirección y gestión eficaces.

Así mismo, entendemos que una organización es un sistema socio-

técnico, en el cual, como vemos en el gráfico siguiente, intervienen
factores sociales y técnicos que, correctamente balanceados, optimizan
los resultados.

15
Figura 1.6: La Organización como sistema socio – técnico

La definición de la estructura organizacional supone decidir en qué

unidades y órganos principales conviene descomponer la institución a fin
de permitir la consecución de las misiones y objetivos establecidos sin
que, al mismo tiempo, se caiga en un sobredimensionamiento de
recursos.

Cada órgano o unidad de la estructura se dotará de un conjunto de

medios humanos y materiales destinados a cumplir una misión
permanente, bien definida, con fronteras razonablemente claras y de
modo que un jefe pueda tomar toda la responsabilidad por él.

Normalmente, el conjunto de los órganos que forman la estructura de

una empresa o entidad se representa gráficamente mediante
organigramas, que permiten tener una visión clara de los órganos
existentes y de las relaciones jerárquicas que existen entre ellos.

Estos conceptos son familiares a cualquier profesional de la organización

por lo que su comprensión no presenta mayor dificultad. Sin embargo,
estas definiciones nos plantean alguna dificultad cuando debemos
referirnos a “proyectos”. Si pensamos que una unidad se caracteriza por
tener una misión permanente con medios humanos adecuados para
cumplir esa misión y, por tanto, dotados también de una fuerte
estabilidad estaremos en una simple contradicción con la esencia
temporal de los proyectos y su característica de estructuras de recursos
cambiantes.

Por todo ello, es conveniente estudiar las implicaciones de los proyectos

sobre la estructura organizacional de la empresa y hasta qué punto un
determinado tipo de estructura facilita o dificulta la gestión de los
proyectos.

Desde el punto de vista de la gestión de proyectos, podemos hacer una

clara distinción en diferentes tipos de organizaciones:

16
▪ Organizaciones funcionales, en las que el personal está estructurado
atendiendo al principio de la especialización, es decir según sus
conocimientos en unidades funcionales que actúan de forma
independiente del resto, con un superior al que deben responder e
informar.

▪ Organizaciones proyectizadas, donde la empresa se estructura en

grupos multidisciplinares que tienen plena responsabilidad sobre un
proyecto concreto. Estos grupos son dirigidos por un director de proyecto
y su morfología cambia en función de la cantidad y tipología de proyectos.

▪ Organizaciones matriciales. Representan un híbrido entre las dos

estructuras anteriores ya que ambas se superponen para dar lugar a una
tercera en la que cada individuo depende de dos superiores: el director
del proyecto en el que participa y el director del departamento (área
funcional) en el que se encuentra. Si la dependencia del primero es mayor
se habla de estructura matricial fuerte y en caso contrario de estructura
matricial débil.

1.5.1.1 Organización funcional, vertical o piramidal

Es la organización más extendida en las empresas industriales y de
servicios. Su organigrama se compone de unidades funcionales
dependientes de la alta dirección y compuestas de divisiones o secciones
que se encargan de las actividades concretas que les son asignadas.

Cuando se enfrentan a un proyecto, el trabajo se reparte entre cada una

de dichas unidades que constituyen grupos autónomos con escasa
comunicación e interacción con el resto de áreas correspondiendo la
dirección del proyecto a aquel departamento que en cada fase posea una
mayor responsabilidad.

Este tipo de organizaciones funciona con eficacia en los casos en los que
haya que realizar funciones específicas y de ellas, sólo una es la principal,
por lo que no existe mezcla de muchas disciplinas.

Sin embargo serán poco adecuadas para la ejecución de proyectos, por

tratarse éstos de actividades interdisciplinares.

17
 Ventajas
√ Relaciones de autoridad y reporte más claras
√ Aprovecha mejor la especialización (genera
background especializado)
√ Grupos de personas homogéneos
√ Fuerte tendencia a la excelencia técnica
√ Mejor aprovechamiento de los medios humanos.
√ Requiere menor cantidad de personal técnico.
√ Ofrece al personal una mayor variedad de trabajo,
al involucrarse en proyectos diferentes.
√ La agrupación de especialistas permite compartir y
transferir experiencias.
Tabla 1.2: Ventajas y Desventajas de la Organización Funcional
Organización funcional
Figura 1.7: La Organización Funcional y la Gestión de Proyectos
Desventajas
√ Fronteras disciplinarias
√ Dificultad para trabajar influencia/satisfacción
cliente
√ Oportunidades de desarrollo limitadas para PM
√ El PM depende de su influencia personal
√ Barreras por procesos jerárquicos de decisión
√ Barreras por procesos jerárquicos de
comunicación
√ “fuerte foco en el entregable, antes que en el
proyecto”
√ Dilución de responsabilidades entre los
departamentos.
√ Problemas de coordinación.
√ Se presta mayor atención a los problemas técnicos
en detrimento de la coordinación y planificación
√ Respuesta lenta.
√ Los objetivos del departamento se anteponen a
los globales del proyecto
18
 1.5.1.2 Organización proyectizada
Es el tipo de organización más reciente y se encuentra más desarrollado
en el sector servicios que en el industrial. En él no existen las áreas
funcionales tradicionales sino los denominados equipos de proyecto
encargados de la realización de un proyecto concreto.

Cada equipo lleva adelante un proyecto por vez, excepto en

circunstancias especiales en que pueden desarrollar varios proyectos a la
vez siempre que se precisen técnicas similares y se encuentren en
distintas etapas de su desarrollo, para evitar los desequilibrios en la
asignación de carga de trabajo.

En proyectos de gran envergadura es frecuente la agrupación del

personal por disciplinas o especialidades con técnicos de proyecto
responsables de cada una de ellas.

Ventajas
√ El rol del PM es fuerte
√ Personal administrativo asignado full time
√ Espacios de trabajo comunes (war room)
√ Responsabilidades claras
√ Foco en el negocio y el cliente
√ Mejor relación con el cliente
√ Mayor capacidad de decisión
√ Control directo sobre todas las actividades
del proyecto.
√ Reducción de los problemas de coordinación.
√ Responsabilidades definidas y centralizadas en
el director del proyecto.
√ El director de proyecto dispone de
información actualizada en todo momento.
Desventajas
√ Menor “identidad profesional”
√ Liderazgo ejercido por no -técnicos-
especializados
√ Menor autoridad de los gerentes funcionales
√ Foco en trabajos administrativos, antes que en los
técnicos
√ “Foco en los procesos, antes que en entregables”
√ Aumento de costes debido a la duplicidad de
funciones.
√ Necesidad de personal adicional.
√ Los especialistas asignados a un proyecto muy
largo pueden quedar desfasados tecnológicamente.
√ Es difícil reemplazar un miembro del equipo ya
que posee conocimientos muy específicos.

Tabla 1.3: Ventajas y Desventajas de la Organización Proyectizada

19
Organización por proyectos

Figura 1.8: La Organización Proyectizada y la Gestión de Proyectos

1.5.1.3 Organizaciones matriciales.

Las dos formas de organización anteriores constituyen dos extremos
entre los que se establece un abanico de situaciones intermedias. En ellas
conviven dos grandes áreas: una estructurada en equipos de proyecto y
otra en unidades funcionales. El personal técnico que integra estas dos
áreas es el mismo pero la dirección no lo es.

Una característica fundamental de este tipo de organizaciones es que se

viola uno de los principios de gestión y organización considerado
inmutable desde los tiempos históricos de Taylor y Fayol: el principio de
unidad de mando, según el cual «todo subordinado debe responder a
uno y solo un jefe».

En este caso, cada individuo responde dos jefes: el gerente funcional y el

gerente de proyecto (a quien informar y de quien recibir instrucciones), lo
cual podría desembocar en una estructura conflictiva. La manera de
resolver este inconveniente es definir sin ambigüedad el campo y la

20
responsabilidad que corresponden a cada área. Por ejemplo: el gerente
funcional toma las definiciones de cómo se hacen las cosas aquí, mientras
el Gerente de Proyecto toma las definiciones de Que se hace hoy para el
proyecto.

Habitualmente el director de cada unidad funcional asigna el personal a

cada proyecto y controla la calidad técnica del trabajo efectuado por sus
subordinados, mientras que el director del proyecto como máximo
responsable del mismo fija el contenido, alcance y calidad global y
además se encarga de realizar la planificación, programación y
presupuestos.

Elementos de vital importancia para el buen funcionamiento del proyecto

son los coordinadores de cada unidad funcional asignados a cada
proyecto que son los interlocutores habituales de los directores de
proyecto. Entre sus funciones está la de establecer los procedimientos
técnicos, programaciones y presupuestos definitivos en cada una de sus
áreas.

Ahora bien, ante un conflicto de órdenes, sería lógico preguntarse: ¿a

quién responderá el subordinado? ¿Al Gerente Funcional o al Gerente de
Proyecto?

Para responder esta pregunta podemos hacer nuevas reflexiones y

cuestionamientos: ¿quién define su escala en la organización?, ¿quién
decide los permisos y las vacaciones? ¿Quién seguirá siendo su jefe
cuando el proyecto finalice? En este punto podemos imaginar la
respuesta: es el Gerente Funcional quien tiene más poder (al menos
formal) sobre el individuo.

Vemos así que el gran problema de este tipo de estructuras para la

gestión de proyectos es la falta de autoridad directa del Gerente del
proyecto que debe suplirla con el ascendiente que le proporcionan sus
cualidades de liderazgo, basado éste en su experiencia, habilidades
personales de motivación, persuasión y negociación, amplitud de visión,
entre otros.

21
 Ventajas Desventajas

√ El project manager mantiene control ( a √ Flujo multidimensional de trabajo

través de los gerentes de línea) sobre todos
los recursos, incluyendo los costos y el
personal
√ Pueden establecerse políticas y
procedimientos específicos para cada
proyecto
√ Respuesta rápida ante cambios, conflictos y
necesidades de cada proyecto
√ El costo de las personas es menor al ser
compartida en diferentes proyectos
√ Cada persona tiene un puesto cuando el
proyecto termina
√ Mejor balance entre tiempos, costos y
resultados
√ Autoridad y responsabilidad están
compartidas
√ Separación entre la dirección técnica y la
gestión administrativa del proyecto.
√ Permite disponer de una reserva de
especialistas en los grupos funcionales.
√ La existencia de una comunicación fluida
posibilita respuestas rápidas tanto a los
deseos del cliente como a las necesidades
de la organización.
√ Evita que el personal se quede desfasado
en su campo a la vez que amplía su
conocimiento de otros campos.
Tabla 1.4: Ventajas y Desventajas de la Organización Matricial
e información
√ Doble dependencia
√ Cambio continuo de prioridades
√ Dificultad inicial para establecer políticas
y procedimientos
√ Gerentes de línea pueden tener
sesgos hacia sus propios objetivos
√ Las personas desarrollan roles con
mayor grado de ambigüedad respecto a
la organización funcional
√ Requiere un nivel superior de dirección
que arbitre en los litigios que pudieran
surgir entre las dos fuentes de autoridad.
√ Necesita un sistema de información y
comunicaciones eficaz para evitar que
se adopten las soluciones de aquel jefe
que tenga un mayor peso en la
organización.
√ Hay que equilibrar los objetivos de coste
y plazo (director proyecto) con los de
calidad técnica (director funcional).

Si bien este tipo de organización “funciona” como matriz, en la práctica se

presenta con el típico organigrama.

La importancia del director de proyecto en la toma de decisiones dentro

de estas organizaciones es muy variable ya que puede ser un simple
asesor de la dirección general, puede ser un coordinador reservando el
poder de decisión al director funcional (estructura matricial débil) o tener
el control y la capacidad de decisión sirviéndose del director funcional
para asesorarse en las cuestiones estrictamente técnicas (estructura
matricial fuerte).

22
Así podemos definir 3 tipos o grados en la organización matricial:

• Fuerte
• Balanceada
• Débil

Organización matriz fuerte

Figura 1.9: La Organización Matricial Fuerte y la Gestión de Proyectos

23
Organización matricial débil

Figura 1.10: La Organización Matricial Débil y la Gestión de Proyectos

Organización matriz balanceada

Figura 1.11: La Organización Matricial Balanceada y la Gestión de Proyectos

24
Tabla 1.5: Características de las Organizaciones según su tipo según PMI

No hay estructuras organizacionales buenas o malas; sino organizaciones

apropiadas o inapropiadas para cada proyecto.

1.5.2 La gestión del proyecto y la figura del director

de proyecto.
La principal responsabilidad del director del proyecto, está en gestionar el
equipo y su trabajo es entregar los resultados prometidos. Suya es la
responsabilidad de liderazgo para crear el clima adecuado.

La importancia de la figura del director del proyecto queda claramente

expresada en un párrafo de un informe del Departamento de Defensa de
los EEUU sobre el proyecto STARS de investigación sobre la reutilización
de software que dice:

"El director del proyecto juega el papel más importante en la Ingeniería

del Software y su soporte. La diferencia entre el éxito o el fracaso -entre
un proyecto que se desarrolla en fecha y en presupuesto, o uno retrasado
y sin control de costos- es, a menudo, una función de la eficacia de ese
director".

Las funciones principales de un director de proyectos son:

1. Planificar el trabajo que debe realizarse para alcanzar los objetivos

25
 definidos.
2. Organizar el equipo de trabajo que realizará el proyecto.
3. Implantarlo asignando trabajo al personal.
4. Controlar el progreso.
5. Liderar el equipo de personas.

1.6 Procesos de la gestión de

proyectos.
1.6.1 El Problema de la Construcción de Software.
Hasta aquí hemos estado hablando de la disciplina de gestión de
proyectos, vamos a focalizar ahora en la particularidad del desarrollo de
proyectos de software.

La construcción de software requiere de dos aspectos de fundamental

importancia, por un lado debe seguirse un determinado “proceso”,
implementando un conjunto de actividades prediseñadas y con
resultados definidos, y por otro lado, se lleva adelante un “proyecto” que
pone todos estos procesos en un marco de restricciones de tiempo y
costo con vistas a la creación de un producto nuevo y singular.

•El Proceso dice “que” y “como”

•El Proyecto dice “quien” y “cuando”

1.6.2 Proceso de desarrollo de software

El proceso de construir un producto de software es a la vez una actividad
de resolución de problemas.

El proceso de desarrollo de software es el conjunto de actividades

organizadas que permite la transformación de una necesidad (problema)
en un software (solución automatizada) que satisface esa necesidad.

La solución de un problema mediante Ingeniería de Software es una

actividad de modelización que comienza con el desarrollo de modelos
conceptuales (no formales) y los convierte en modelos formales, que son
los productos implementados. Estas dos actividades de modelización
trabajan a niveles distintos: el nivel del problema o necesidad (nivel
conceptual o de dominio de aplicación), y el nivel de la solución
implementada sobre computadora (o nivel formal).

Cuando hablamos de modelo conceptual estamos trabando al nivel del

Dominio del problema, es decir el nivel en el cual se plantea el punto de
vista de quien tiene el problema o necesidad. Cuando mencionamos el

26
nivel de la solución estamos ubicados en la perspectiva de la
implementación de ese mismo problema en la computadora.

Figura 1.12: Modelo de Proceso de desarrollo de Software

Un modelo muy interesante es el que presenta Natalia Juristo Juzgado:

Figura 1.13: Proceso esencial de construcción de software (Fuente: Proceso Software,

Natalia Juristo Juzgado, UPM, 2001)

Si analizamos la figura 1.13 podremos notar algunos aspectos

importantes: con el modelo conceptual se puede determinar la validez de
la solución: ¿representa el modelo lo que implica la necesidad del
usuario?, mientras tanto el modelo formal debe ser analizado desde el
punto de vista de la corrección: ¿funciona correctamente o según lo
esperado?
Planteada la construcción de software como una resolución de
problemas, debe existir un proceso de resolución que se corresponda con
el proceso básico de resolución de problemas expuesto en el apartado
anterior.

27
En primer lugar acordaremos una definición de PROCESO:
Un proceso define un Flujo de Actividades, las Actividades en sí mismas,
los Roles que realizan dichas actividades y los Artefactos (in,out) que
manipulan dichos Roles en la realización de las actividades para producir
un resultado con agregado de valor.

En términos generales, al primer paso, o definición del qué, se le

denomina genéricamente Especificación de Requisitos y Análisis. A la
decisión de cómo hacerlo se la conoce, en Ingeniería de Software, como
Diseño del Sistema. A la realización de ese cómo se le llama Codificación.
Posteriormente, a la verificación de la corrección del software se le
denomina genéricamente Pruebas. Y, finalmente, hablaremos de las
actividades necesarias para que el sistema entre “en producción” y pueda
ser utilizado, estamos hablando de la Instalación.

Además, cuando las soluciones a los problemas no son puntuales, sino

que permanecen en el tiempo, al proceso de resolución debe añadírsele
una última etapa de Mantenimiento.

1.6.3 El Proceso Software y el Ciclo de Vida.

Se ha dicho que el problema planteado es la construcción de software, y
que para resolver dicho problema se lleva a cabo un proceso de
resolución, como cuando se trata cualquier otro problema. A dicho
proceso de resolución se le ha dado el nombre de Proceso Software.
Ahora bien, si el software obtenido tras el proceso es visto como el
producto que sale del proceso, puede considerarse que cierta materia
entra al proceso y se transforma a lo largo del mismo hasta obtener el
producto deseado. Dicho de otro modo, el proceso software puede verse
como una cadena de tareas. Estas cadenas estructuran la transformación
que van sufriendo las entidades al pasar a través de una secuencia de
acciones que forman cada actividad del proceso. Las cadenas de tareas
son planes idealizados de qué acciones deben realizarse y en qué orden
para producir qué artefactos e involucrando que roles.

Con esta perspectiva, se pueden establecer los estados por los que va
pasando el producto en el proceso: La entrada al proceso es una
necesidad que, una vez estudiada, se convierte en una especificación de
requisitos que, posteriormente, se transforma en un diseño del sistema,
para pasar más adelante a ser un código y, finalmente, un sistema
software completo e integrado. Este enfoque orientado al producto,
focalizado en la transformación del producto, en lugar de en el proceso

28
que lo transforma, es lo que se llama Ciclo de Vida. Es decir, el ciclo que
el producto software sufre a lo largo de su vida, desde que nace (o se
detecta la necesidad) hasta que muere (o se retira el sistema).

Finalmente, todo este proceso es implementado para cada producto en

particular por medio de un proyecto, que requiere por ende una
coordinación particular: “el gerenciamiento del proyecto”

La Figura 2.5 muestra las relaciones entre Proceso, Ciclo de Vida y

Gerenciamiento de Proyecto.

Figura 1.14: Relación Proceso/Ciclo de Vida/Proyecto

1.5.1 Los procesos del Gerenciamiento de

Proyectos.
Así como existe un conjunto de procesos que deben ejecutarse para
construir el producto del proyecto, siendo la gestión del proyecto una
disciplina hoy madura, también existe un conjunto de procesos que
deben seguirse para aplicarla correctamente.

Estos procesos corresponden a las diferentes áreas de conocimiento y

pueden organizarse en 5 grupos fundamentales:

• Iniciación
• Planeamiento

29
 • Ejecución
• Control
• Cierre

Figura 1.15: Grupos de Procesos del Project Management - PMBoK PMI - 2004

Nótese que hemos mencionado 5 “grupos” de procesos, lo cual no

significa que solo sea 5 procesos, sino muchos más agrupados en estos 5
grupos. También es importante destacar que estos grupos de procesos se
solapan, es decir que no se llevan adelante en forma secuencial como
sucede normalmente con las etapas o Fases.

30
Módulo 2
Dimensiones
Principales de la
Gestion de Proyectos.
Unidad 2: Gestión del
alcance del proyecto
2.1 Iniciación
La iniciación es un proceso que se lleva adelante en los proyectos a efectos
de lograr su lanzamiento temprano y efectivo.

La mayor parte del tiempo que se pierde en los proyectos se pierde por el
“síndrome de inicio difuso”. Nos referimos al tiempo que transcurre en los
inicios del proyecto cuando los objetivos aún no son claros, el equipo no
está formalmente consolidado y es más, en algunos casos no se ha definido
quien será el líder del proyecto.

La situación anteriormente descripta no es poco frecuente y debemos

pensar que todo el tiempo que perdemos en el inicio es tiempo que nos va
a faltar al final.

Por todo ello es importante que podamos “empujar” sanamente el inicio

del proyecto con medidas y definiciones muy claras. Nos proponemos:

1. Nombrar un PM formal y tempranamente.

2. Generar un Documento de Lanzamiento
3. Realizar la Reunión de Lanzamiento.

Discutamos como lograr estos objetivos:

1. Nombrar un PM formal y tempranamente.

Con el término PM referimos al Project Manager o Administrador del

proyecto. Este deberá estar nombrado tempranamente. En muchas
organizaciones suele ser frecuente que el PM se nombre cuando la mayoría
de las definiciones han sido tomadas, el presupuesto ha sido cerrado y,
frecuentemente los planes están definidos. Pedir al PM que se

1
responsabilice por todo ello sin haber sido parte de las definiciones y, más
aún, sin conocer el verdadero espíritu del proyecto puede ser poco
aceptable. Una situación como esta anticipa problemas y provoca pérdidas
de tiempo.

Por lo expuesto es natural la necesidad de lograr su nombramiento en

forma temprana, pero no solo esto hemos planteado. También decimos
que deseamos hacerlo formalmente. Con formalmente queremos decir por
escrito y comunicado.

2. Generar un Documento de Lanzamiento

El documento que cumple con este requerimiento es conocido

normalmente como: “Project Charter”.

Un Project Charter plantea el compromiso de la gerencia con el desarrollo

del proyecto dando las pautas iniciales, lanzando el proyecto formalmente
y nombrando al PM. Plantea como mínimo:

 los estímulos del proyecto.

 descripción del producto o servicio
 nombramiento del PM
 datos de clientes, reportes, restricciones
 equipo inicial de trabajo.

Todo esto emitido por autoridad de la organización y con la información de

la que se disponga al momento de lanzar, es usual que refiera a otros
documentos tales como el contrato, por ejemplo.

3. Realizar la Reunión de Lanzamiento.

La Reunión de Lanzamiento, también conocida como kick off meeting,

tiene por objeto materializar el compromiso de la dirección, el lanzamiento
formal, el compromiso de las partes involucradas, con un hecho muy
concreto que posibilite además el contacto y la llegada del mensaje inicial
que se quiera dar. Permite además dar ánimo al equipo y transmitir las
expectativas del proyecto.

2.2 Planificación del alcance

Para poder avanzar con la Planificación del Alcance, se hará necesario que
revisemos el concepto de Alcance:

2
El Alcance del Proyecto
Seguramente tú usas el concepto “Alcance” en diferentes circunstancias y
con diferentes significado. Vamos a revisar ahora el sentido en el que
usaremos el concepto Alcance en esta materia.

En el ámbito de los Sistemas, es usual utilizar el concepto de alcance con el

significado de - conjunto de funcionalidades que un sistema debe cubrir -
Por ejemplo: el sistema será capaz de: registrar los datos de la compra,
permitir la consulta de stock, entre otros.

El significado descripto para la palabra Alcance en el párrafo anterior es

correcto, aún cuando no es el sentido que le daremos en el ámbito de los
proyectos. El ejemplo anterior describe el alcance del “producto de
proyecto”, en este caso el sistema de software. En el ámbito de la gestión
de proyectos debemos definir “alcance” desde un significado más acorde a
las necesidades de la gestión.

Acudiremos para ello a la definición que nos da el PMI:

ALCANCE: son todos los trabajos, y solo los trabajos necesarios para
completar el producto del proyecto.

Esta definición se vuelve importante en la medida que nos permite una

mirada desde los trabajos necesarios y no desde las prestaciones ofrecidas
por el producto y esta será la base para la planificación del proyecto.

Mientras el grado de cumplimiento del Alcance del producto se mide

contra las especificaciones, el grado de cumplimiento de Alcance del
Proyecto se mide contra el Plan.

La Declaración del Alcance

Un Plan General del proyecto involucra actividades de planeación desde
cada una de las áreas de conocimiento de la gestión del proyecto.

El primer trabajo a realizar a la hora de efectuar el Plan del proyecto será

por ende definir y acotar adecuadamente el Alcance.

A efectos de Definir el Alcance, será necesario generar la “Declaración del

Alcance”, estamos hablando de un documento que permita declarar con
claridad lo que Si está incluido en el proyecto dejando muy claro lo que No
incluye.

Una buena declaración del Alcance (conocida también por su nombre en

inglés, Scope Statement), se escribe en términos de sus Entregables, es
decir los productos o subproductos que se generan a lo largo del proyecto.

3
Una buena definición de entregable debiera incluir los criterios de
aceptación, es decir la descripción de las condiciones que deberá cumplir la
entrega a efectos de ser aceptada por el stakeholder correspondiente. En
este punto nos daremos cuenta que otro ítem importante será la definición
del stakeholder clave para cada uno de los entregables.

Finalmente suele agregarse otro punto importante a esta declaración: Los

supuestos y restricciones.

Entendemos por restricciones todos los factores que limitan las decisiones
del equipo del proyecto, por ejemplo: “no se podrá contratar proveedores
que no tengan certificación oficial de sus procesos”… este tipo de
definiciones fija las condiciones que deberán tomarse en cuenta a la hora
de planificar y ejecutar el proyecto.

Los supuestos son todos los criterios y condiciones que se asumen como
ciertos y válidos a la hora de ejecutar el proyecto. Dado que el proyecto se
lleva adelante en un ambiente de permanente incertidumbre, es necesario
fijar ciertas condiciones de estabilidad que permitan tomar decisiones y
hacer las respectivas previsiones. Un ejemplo de supuesto sería: “se asume
que, al momento de la instalación del sistema, el cliente habrá preparado el
entorno de hardware y software según lo acordado en el punto xx del
contrato”.

“Cuando hay una pobre definición de alcance, los costos del proyecto serán
probablemente más altos, debido a los cambios inevitables, interrumpiendo
el ritmo del proyecto, aumentando los cronogramas y bajando la moral y
productividad del equipo” (PMI - PMBOK)

La Estructura de Descomposición del Trabajo

Llegados al punto en que el Alcance del Proyecto está definido en términos
de sus entregables, es momento de comenzar a pensar en los trabajos que
será necesario llevar adelante para cumplimentar estos entregables.

Para lograr este objetivo se crea una Estructura de Descomposición del

Trabajo (EDT) también conocida como WBS (por su sigla del inglés Work
Breakdown Structure).

Una EDT es un agrupamiento de elementos del proyecto, orientado a

entregables, que organiza y define el alcance total del proyecto.

Se trata de una estructura gráfica con forma de árbol invertido en la que se

detalla todos los trabajos que componen cada entregable.

Es importante entender que al crear una EDT no estamos creando una

estructura de descomposición del producto en sus partes constitutivas,

4
sino que a cada parte la descomponemos en los trabajos necesarios para
conseguirla.

El objetivo de crear una EDT es poder visualizar “todos los trabajos” sin
olvidar ninguno. En opinión de la autora la mayoría de los problemas de
tiempo y presupuesto en los proyectos tienen su origen en una pobre
definición del alcance, es decir en el hecho de haber detectado menos
trabajo que el que luego efectivamente será llevado a cabo si se quiere
completar los productos esperados.

Una EDT puede tener diferente cantidad de niveles, según la magnitud y

complejidad del proyecto y será la base de la planificación y la estimación
de costos.

Una EDT se usará también como herramienta de seguimiento del alcance

del proyecto y será el elemento de enlace con los diferentes aspectos del
proyecto así como también la base de toda negociación a futuro.

Dependiendo del proyecto podrá opcionalmente tener un primer nivel que

descompone en subproyectos o en fases para proyectos de gran
envergadura. Lo esencial es que de un modo u otro se vea en los niveles
superiores los entregables y en los inferiores los paquetes de trabajo.

Visualmente una EDT se ve como sigue:

WORK BREAKDOWN STRUCTURE

Figura 2.1 - La Estructura de descomposición del Trabajo

5
Para la creación de una EDT se puede seguir los pasos que se detallan a
continuación:

1. Identificar los principales entregables del proyecto

2. Crear un elemento por cada entregable
3. Decidir si se puede generar estimaciones de costo y duración
adecuadas para este nivel de desagregación.
4. Identificar para cada elemento sus elementos constitutivos.
5. Verificar la descomposición repitiendo paso 3.
6. Responder al interrogante: ¿los ítems de menor nivel son
necesarios para cumplir el ítem descompuesto?
7. Responder el interrogante ¿alcanza con los ítems de menor nivel
para lograr el de nivel superior?
8. Repetir pasó 3 a 7 hasta lograr una descomposición satisfactoria.

Habiendo completado la creación de la EDT tendremos una estructura

jerárquica compuesta de: entregables, sub-entregables si son necesarios, y
finalmente paquetes de trabajo.

No debe olvidarse que siempre en niveles superiores hay entregables y en

el último nivel hay paquetes de trabajo.

Algunas de las ventajas de crear una EDT son las que se detallan a
continuación:

• Permite una representación visual del alcance total del proyecto

• Permite crear una base de entendimiento entre los stakeholder del
proyecto
• Posibilita identificar todas las tareas a realizar
• Facilita la estimación sobre la duración de las tareas
• Es una base para la elaboración del presupuesto general del proyecto
• Es una base para una contabilidad general del proyecto
• Ayuda a elaborar el programa de trabajo
• Permite contrastar rendimiento contra estimaciones
• Facilita la asignación de responsabilidades
• Da una idea de magnitud y complejidad del proyecto

Una buena EDT puede acompañarse con un diccionario que describa cada
paquete de trabajo incluyendo las estimaciones de esfuerzo, tiempo y
costo.

2.3 Verificación del alcance

La Verificación del Alcance es una actividad de vital importancia para
asegurar el avance del proyecto y minimizar los conflictos por las entregas.

Vamos inicialmente a definir el concepto de Verificación del alcance

6
Verificacion del alcance
Es el proceso de obtener la aceptación formal del alcance completado del
proyecto por los stakeholders.

Resulta importante notar que estamos hablando de alcance “completado”,

es decir que no nos referimos a aceptar que este es el alcance sino, más
bien, a aceptar que estos son los productos entregables comprometidos.

Otra importante observación es que la aceptación debe hacerse por el

stakeholder correspondiente, en este punto seguramente nos
preguntamos: ¿cuál es el stakeholder correspondiente?

La respuesta a esta pregunta la tenemos en lo que planteamos al hablar de

la Definición del Alcance cuando dijimos que debía haber criterios de
aceptación y stakeholder clave, (puede rever el punto 2.2.2 La declaración
del Alcance).

2.4 Control de cambio del alcance

Es el proceso de asegurar que los cambios ocurren de manera ordenada y
beneficiosa. Prestemos atención a que no se dice que los cambios no
ocurran, sino que estén bajo control.

El proyecto es naturalmente cambio, de modo que es lógico que los

cambios ocurran. Una buena administración se ocupa de gestionarlos.

Causas de cambios en el alcance

 Un suceso externo
 Un error u omisión al definir el alcance
 Del producto
 Del proyecto

 Un cambio en el valor agregado

El control de cambios implica asegurar que:

 Se detecta el cambio
 Se decide el cambio
 Se define que cambió, cuando, porqué
 Se implementa el cambio
 Se comunica el cambio
 Se documenta el cambio

7
También el Control de cambios incluye

A) Influenciar los factores que crean cambios para asegurar que

beneficien
B) Determinar (darse cuenta) cuando se ha producido un cambio de
alcance
C) Gerenciar los cambios que ocurren

2.5 Caso para estudio

Revise la lectura complementaria de este módulo: Anexo Estructura de
Desagregación del Trabajo y analice el ejemplo simplificado de la figura 4,
en la página 8.

Tomando este ejemplo como base y los conocimientos que tiene sobre
proceso de desarrollo de software plantea una EDT para el proyecto que se
plantea a continuación:

Una universidad necesita construir un nuevo software de administración de

cursos que contemple un módulo de inscripciones, un módulo de
administración de alumnos, un módulo de administración de docentes y
uno de gestión académica. El proyecto parte de una especificación general
y finaliza con el sistema funcionando y los usuarios capacitados.

8
Unidad 3: Gestión del
tiempo del proyecto
Antes de avanzar con el desarrollo de los aspectos relacionados al tiempo
mencionaremos algunos factores que influyen en la administración del
tiempo del proyecto:

Factores de Éxito en la Administración del tiempo:

• Personal competente y experimentado

• Objetivos claramente definidos y acordados
• Gerente de Proyecto y personal dedicado
• Personal disponible a tiempo
• Plan de proyecto completo
• Cronograma interno detallado
• Responsabilidad individual por cada entregable
• Revisiones internas regulares
• Seguimiento de la Lista de Ítems de acción
• Problemas detectados tempranamente y resueltos
• Revisión regular de las áreas de riesgos
• Subcontratistas tratados como parte del equipo
• Dependencias controladas y gerenciales

Factores de Fracaso en la Administración del tiempo:

• Gerente de Proyecto y equipo part-time

• Personal en préstamo
• Proyecto con escaso personal
• Responsabilidades difusas
• Plan Incompleto o sólo a nivel general
• El Gerente de Proyecto supone progresos
• El Gerente de Proyecto cede el control al cliente o subcontratista
• El Gerente de Proyecto supone que las dependencias se están
cumpliendo
• El Gerente de Proyecto supone que los subcontratistas están
cumpliendo
• Los problemas son pospuestos o ignorados
• No se detectan y gerencian los cambios en el proyecto

La Administración de tiempos del proyecto incluirá los procesos necesarios

para lograr que el proyecto se lleve adelante en los tiempos previstos.

9
3.1 Definición de las actividades
Para poder llevar adelante una adecuada gestión de tiempos del proyecto
será necesario hacer un correcto plan de tareas. Para ello deberemos, en
primer lugar, hacer una clara y completa definición de actividades.

Este proceso consiste en identificar y documentar las actividades

específicas que deben ser efectuadas para producir los entregables
identificados en la Estructura de Descomposición del Trabajo (EDT).

El último nivel de la EDT contiene los “paquetes de trabajo”, estos serán los
indicados para trabajar la descomposición.

Un paquete de trabajo puede convertirse en una actividad del proyecto o

bien puede descomponerse para mejor administración.

Una vez definidas todas las actividades podremos comenzar a trabajar con
la secuencia entre ellas.

3.2 Secuencia de las actividades

Para poder lograr un cronograma realista y posible necesitaremos realizar
un ordenamiento de las actividades previamente definidas.

Para ordenar las actividades necesitaremos establecer secuencia. La

secuencia surge por causa de que entre algunas actividades existen
relaciones de dependencia:

Dependencia: Relación de secuencia entre 2 actividades.

Las dependencias entre actividades pueden ser de al menos dos tipos

principales:

 Hard Logic (obligatorias, mandatarias o de lógica dura).

Tienen que ver con la naturaleza del trabajo, y son relaciones
obligadas, es decir, una actividad no puede llevarse a cabo sin que la
otra haya finalizado.

 Soft Logic (discrecionales o de lógica blanda).

Están dadas por decisión del planificador. Responden a usos y
costumbres, buenas prácticas o conveniencia, para minimizar riesgos.
Tenemos relaciones de este tipo cuando las dos actividades no
necesariamente deben hacerse en secuencia.

10
Podemos agregar un tercer tipo de dependencia que es importante
detectar:

 Externas
Dependencias relacionadas a factores externos. Son dependencias
con otros sucesos o actividades externas al proyecto. No consume los
tiempos y los recursos del equipo de proyecto pero condicionan las
decisiones y el avance.

Por otra parte toda dependencia genera también una relación de

precedencia. Las precedencias plantean de qué forma son esas
dependencias.

Los tipos de Precedencias pueden clasificarse en las cuatro que siguen:

Figura 2.2 - Tipos de Precedencias

Importante: la mayoría de las dependencias son del tipo FC.

La implementación de las dependencias generará necesariamente un

diagrama de red. Los diagramas de red de actividades pueden ser de dos
tipos:

• Con actividades en los nodos, también conocidos como AON por

su sigla en inglés: Activity On Node

11
Figura 2.3 - Diagrama de Red con Actividades en los Nodos (AON)

 Con actividades en las flechas, también conocidos como AOA por

su sigla en inglés: Activity On Arrow.

Figura 2.4 - Diagrama de Red con Actividades en las Flechas (AOA)

3.3 Estimación de la duración de las

actividades
El primer desafío para lograr la estimación del tiempo total re proyecto
será estimar la duración de cada una de las actividades, es decir: lograr una
predicción de cuál será la cantidad de jornadas laborales que insumirá cada
actividad del proyecto.

Inicialmente se calculará el esfuerzo. El esfuerzo es una medida de la carga

de trabajo requerida para la actividad.

El esfuerzo será medido en horas/hombre o en horas/máquina

dependiendo de cuál sea el recurso más crítico. Lo normal en los proyectos

12
de sistemas es medir el esfuerzo en hs/hombre por ser este último el
recurso más crítico y determinante en estos proyectos.

Por ejemplo, podemos arribar a la conclusión de que una tarea puede

llevarse a cabo en aproximadamente 80 hs/hombre. Estas 80 hs/h no
estarán indicando aún cual es la duración de la actividad, sino cual es la
carga de trabajo en términos de esfuerzo que se necesita aplicar.

Esta será la primera medida necesaria para estimar ahora la duración de la

actividad.

A esta medida de esfuerzo le aplicaremos una determinada cantidad de

recursos y una indicación de la jornada que cumplirán estos recursos (full
time o ½ jornada, por ejemplo) y podremos con estos datos conocer lo que
denominamos el tiempo de trabajo (working time) o duración neta de la
actividad.

Para el ejemplo, las 80 hs/hombre se ejecutarán con 2 recursos de jornada

completa ( 8 hs. diarias) con lo que tendremos que la actividad se llevará a
cabo en 5 días.

La cantidad de recursos a aplicar a una actividad dependerá de la actividad

misma, de las disponibilidades y de la experiencia. En cualquier caso habrá
un punto de equilibrio que indique una cantidad máxima de recursos
posibles a partir de la cual cualquier recurso extra, lejos de lograr disminuir
el tiempo de la actividad, degradará la eficiencia.

Cuando no se posee métricas de experiencias anteriores, se suele utilizar el

método de la raíz cuadrada del esfuerzo, para buscar equilibrio entre
cantidad de recursos y tiempo que tardará el proyecto.

36hs/h = 6 hs * 6 hombres

Punto límite para agregar recursos a un trabajo en función de agilizarlo.

3.4 Desarrollo del programa

Para desarrollar el programa de trabajo, también conocido como
cronograma, deberemos aplicar estas duraciones a la red de actividades y
colocar las restricciones de calendario correspondientes.

Lo que estamos buscando ahora es la fecha de finalización de proyecto. En

el camino calcularemos las fechas de inicio y fin de cada actividad, lo que
determinará para cada una de ellas lo que conocemos como el tiempo
transcurrido esperado (elapsed time).

13
Cuando hablamos de restricciones de calendario nos referimos a los días de
trabajo del proyecto y de los recursos en particular. Con todos estos datos
podremos llegar a calcular el camino crítico de la red.

El desarrollo del cronograma es un proceso reiterativo en el que:

• Se determina las fechas de principio y fin de todas las actividades

del proyecto.
• Por lo tanto se determina su duración total.
• Las fechas que se definen deben ser realistas, ni pesimistas ni
optimistas.
Este trabajo se lleva a cabo normalmente ingresando los datos antes
mencionados en un software que finalmente nos dará un diagrama de
gantt del proyecto en base al análisis de la secuencia de las actividades, la
estimación de su duración y los requerimientos y disponibilidad de los
recursos.

Figura 2.5 - Diagrama de Gantt - Cronograma del proyecto

Los siguientes conceptos deberán ser tomados en cuenta durante este

proceso:
 Actividad o Tarea: trabajo que produce un entregable o resultado
medible, con comienzo, fin y duración definidos.
 Dependencia: relación lógica entre dos tareas.
 Predecesora: la tarea anterior en la relación de dependencia.
 Sucesora: la tarea siguiente en la relación de dependencia.
 Flotación total: tiempo máximo que una tarea puede ser
demorada sin que se demore el día final del proyecto.
 Flotación libre: tiempo máximo que una tarea puede ser
demorada sin que se demore el día de comienzo de la sucesora.
 Camino crítico: secuencia de tareas en la que no hay flotación.

14
  Tarea crítica: la que debe ser realizada tal como fue programada
para poder cumplir con el día final del proyecto.
 ASAP: tarea a comenzar tan pronto como sea posible.
 ALAP: tarea a comenzar tan tarde como sea posible.
En este punto se recomienda trabajar con el documento:

3.5 Control del programa

El programa de trabajo será un documento vivo que deberá llevarse
controlado durante todo el transcurso del proyecto.

Es de esperar que durante el desarrollo del proyecto algunos imprevistos

se presenten y los tiempos esperados comiencen a retrasarse.

Será función del director del proyecto mantenerse informado de estas

situaciones, conocer como impactan sobre el proyecto y
fundamentalmente tomar las decisiones pertinentes para corregir el rumbo
e informar a los stakeholder apropiados.

Una herramienta usual para llevar adelante esta tarea será el mismo
software que se utilizó para construir el cronograma:

Figura 2.6 - Diagrama de Gantt - Control de Cronograma del proyecto

3.6 Caso para estudio

Revise la lectura complementaria de este módulo: anexo Planeación y
Control del proyecto mediante CPM y Pert. Tomando la EDT que desarrolló
en el punto 2.5 desarrolle las actividades necesarias para llegar a un
programa de trabajo, enumere los pasos que llevó adelante para lograrlo.

15
 Unidad 4: Gestión de
costos del proyecto
Una de las dimensiones básicas del proyecto es el costo. Los proyectos
cuestan dinero y usan recursos que podrían usarse en otra acción; por ello
es importante para los directores de proyecto la comprensión de la Gestión
de Costos del Proyecto.
Revisemos algunos conceptos de costo:
Una definición contable podría ser “es un sacrificio o la utilización de
recursos para lograr un objetivo específico”
Una definición de diccionario “Cantidad rendida a cambio de algo”.
En cualquier caso estaremos hablando de la no disponibilidad de un
recurso por haberlo afectado a un objetivo, esto necesariamente implica la
necesidad de saber aplicar correctamente los recursos.
Una buena gestión de costos incluye los procesos requeridos para asegurar
que el proyecto sea cumplido dentro del presupuesto aprobado. Para
lograrlo podremos realizar los siguientes procesos:

4.1 Planificación de los recursos

La planificación de los recursos implica determinar qué recursos, en qué
cantidades y cuándo van a ser utilizados para ejecutar las actividades del
proyecto
Debe responderse a las siguientes preguntas:

 ¿Cuán difícil será realizar una tarea específica en el proyecto?

 ¿Existe algo único en este alcance del proyecto que puede afectar a los
recursos?
 ¿Cuál es la historia de la organización en realizar tareas similares? ¿Se han
realizado antes tareas similares? ¿Qué nivel de personal trabajó?
 ¿Tendrá la organización gente, equipamiento y materiales que estarán
disponibles y capacitados para realizar el trabajo?
 ¿Tendrá que adquirir más recursos la organización para completar el trabajo?
 ¿Tiene sentido realizar “outsourcing” de una parte del trabajo?
 ¿Existen políticas organizacionales que pueden afectar la disponibilidad de
recursos?

16
 Respondiendo a estas preguntas podremos lograr una clara determinación
y asignación de los recursos necesarios para llevar adelante el proyecto.
Esta información deberá ser documentada. Es importante que la
información sea bien declarada, esto puede hacerse con ayuda de software
de gestión de proyectos, planillas de cálculo o cualquier otro documento
que destinemos para este fin. En cualquier caso el objetivo será el mismo:
conocer que recursos, en que cantidad y para cuándo deben estar
disponibles.

Esta información es de vital importancia para las áreas de la organización

que deban encargarse de proveerlos.

4.2 Estimación de los costos

Una vez que los recursos han sido claramente determinados es necesario
estimar el costo de utilizar los recursos necesarios para completar las
actividades del proyecto.

Debe tomarse en cuenta que este proceso se puede realizar en diferentes

momentos del proyecto y que, por ende, contará con más o menos
información según el momento y finalidad.

Diferentes tipos de estimaciones pueden definirse en función del momento

en que esta se realiza:

Grado de
Tipo de estimación Cuándo se realiza Por qué se hace
aproximación

Muy temprano en el ciclo de Provee estimación

Orden de vida del proyecto, a veces 3-5 de costos para "-25%, +75%"
Magnitud años antes de la concreción decisiones de
del proyecto selección

Presupuestario Temprano, Ej. 1-2 años antes Coloca $ en el plan

"-10%, +25%"
(top down) de que se complete el Presupuestario
proyecto

Provee detalles para

Definitivo (bottom A menos de un año de
compras, costos "-5%, +10%"
up) completar el proyecto
actuales y estimados

Figura 2.7 - Tipos de estimaciones según el momento de cálculo

Debemos tomar en cuenta que una estimación es una predicción para la

planificación, por lo que es de esperarse algún grado de desvío respecto de
la realidad futura.

17
Otro aspecto a reforzar es que estamos hablando de estimar costos. El
costo es una variable del proyecto. No es lo mismo que precio, el precio es
una variable del negocio.

Podremos aplicar diversos métodos de estimación. Mencionaremos

algunos de ellos:

Estimación por analogía: Una estimación por analogía se realiza

comparando información de este proyecto con la de otro ya ejecutado y
que cumpla al menos con dos condiciones: que sea verdaderamente similar
o análogo en cuanto a su estructura y que se cuente con información de
ejecución de ese proyecto.

La estimación por analogía es un método solo aconsejable cuando estamos

en fases tempranas y disponemos de poca información ya que no se espera
con este método alta precisión.

Estimación de ingeniería: este método se aplica cuando se cuenta con

información detallada del proyecto y es de mucha precisión si es bien
aplicado.

La estimación de ingeniería requiere una EDT desagregada a bajo nivel y

consiste en estimar cada uno de los paquetes de trabajo para luego por
suma ascendente lograr la estimación de costos de los entregables finales.
El principio que sustenta la efectividad del método es la descomposición a
bajo nivel.

Estimación Paramétrica: una estimación paramétrica puede hacerse

cuando, como su nombre lo indica, contamos con parámetros y con
algunos ratios y relaciones que permiten modelar el tipo de actividad o
producto de la actividad que se está estimando. Ejemplo de ello es la
estimación por puntos de función en el desarrollo de software.

Cualquiera sea el método aplicado, se espera tener una estimación del

costo de cada una de las actividades del proyecto.

4.3-Presupuestación de los costos

Con este proceso se busca crear el “presupuesto del proyecto”. La
presupuestación implica asignar las estimaciones individuales a las
actividades cronogramadas a efectos de poder conocer cuáles serán las
previsiones de costos a incurrir en cada periodo de tiempo.

Podemos decir que lo que haremos es distribuir las estimaciones a lo largo

del tiempo, lo cual indica que trabajaremos con las estimaciones y el
cronograma.

18
 Un presupuesto, usualmente se verá como sigue:
Semana
Costo Total
1 2 3 4 5 6
Presupuestado
Diseñar 8 6 2
Construir 86 28 40 18
Instalar 54 18 36
Probar 15 15
Total 163 6 30 40 36 36 15
Acumulado 6 36 76 112 148 163
Figura 2.8 - Ejemplo de Presupuesto de costos del proyecto

Preste especial atención a la última línea del presupuesto, que refleja los
acumulados totales hasta el momento. Es de importancia prestar atención
a este aspecto que representa la cantidad de dinero o recursos que se
habrán afectado hasta ese momento, y esa es la línea base de costos del
proyecto.

La línea base de costos del proyecto se usará para efectuar el control de

avance. Usualmente se la representa con una curva S.

Figura 2.9 - Ejemplo de Presupuesto acumulado - Curva S

19
4.4 Control del costo
El control de costos del proyecto comprende:

• Influir en los factores que ocasionan cambios en la base de costos

para asegurar que los cambios son beneficiosos.
• Determinar cuándo se produce un cambio en la base de costos.
• Gestionar los cambios reales cuando y como ocurran.

A su vez, el control de costos incluye

 Controlar el desarrollo de los costos, para detectar variaciones en
el plan.
 Garantizar que los cambios apropiados son reflejados con
exactitud en la base de costos.
 Prevenir que cambios incorrectos, inapropiados o no actualizados
sean incluidos en la base de costos.
 Informar a las entidades involucradas en el proyecto los cambios
autorizados.
 Lograr costos dentro de límites aceptables.

Todo esto implica necesariamente:

 La búsqueda de los “por qué” de las variaciones, tanto positivas
como negativas.
 Tener en cuenta que una respuesta inadecuada a variaciones de
costo puede generar problemas de Cronograma, Calidad, Riesgo.
 Que esté integrado con los otros procesos de control, control de
cambios del alcance, control de cambios de cronograma, control de
calidad, etc…

La principal técnica para controlar los costos y el avance del proyecto es la

Gestión del Valor Ganado.

El valor Ganado es una técnica de control de proyectos que permite

controlar su ejecución y avance a través del presupuesto y el calendario de
ejecución.

La técnica consiste en comparar el valor del trabajo realizado con el

cronogramado hasta cierto momento del proyecto. Se diferencia de otras
técnicas de control en que el avance no se mide por el solo transcurso del
tiempo ni por la cantidad de trabajo realizada sino, más bien, por el real
avance en términos de lo logrado en el proyecto.

De este modo, se tiene una medida de cuánto trabajo se ha realizado,

cuanto queda para finalizar el proyecto y extrapolando a partir del esfuerzo
invertido en el proyecto, el director de proyecto puede estimar los recursos
que se emplearán para finalizar el proyecto y el tiempo restante para su
terminación.

20
Con esta técnica se puede hacer predicciones de cuánto tiempo tomará el
proyecto para completarse si se mantienen las condiciones actuales a la
vez que se puede proyectar cuanto terminará costando el proyecto si se
mantiene la performance de administración de costos que se lleva hasta el
momento.

Mediciones de Valor Ganado

Para poder trabajar con Valor Ganado, es necesario contar con:

• La estructura de tareas (WBS): una lista de todas las tareas y

paquetes de trabajo del proyecto estructuradas de forma jerárquica.
• Una serie de reglas para determinar objetivamente el grado de
avance de cada tarea en términos de los productos logrados.
• El cronograma de ejecución: un Diagrama de Gantt con el orden
en el que se desarrollarán las tareas.
• Una línea base del proyecto en términos de costos, o lo que es lo
mismo, el presupuesto acumulado a lo largo del tiempo o Curva S.

Las medidas centrales del Valor ganado son:

• BCWS (Budgeted Cost of Work Scheduled) o PV (Planed Value).

 Avance físico planeado a su valor presupuestado.
 Suma de los costos estimados para las actividades
cronogramadas hasta cierto momento.
• BCWP (Budgeted Cost of Work Performed) o EV (Earned Value).
 Avance físico realizado a su valor presupuestado.
 Suma de los costos estimados para las actividades completadas
hasta cierto momento.
• ACWP (Actual Cost of Work Performed) o AC (Actual Cost).
 Costo real incurrido.
 Suma de los costos reales para las actividades completadas hasta
cierto momento.
Para comprender mejor, tomaremos un caso como ejemplo, en este caso
se tiene un proyecto que está estimado en 6 meses para un total de 700
casos de uso a construir. Los casos de uso son la medida que se tomará
para el avance.

Los costos pueden verse en alguna medida monetaria, pesos por ejemplo.
En el caso se plantea inicialmente los datos de lo planificado, seguidamente
los datos de lo ocurrido realmente y finalmente los valores de las tres
medidas que estamos presentando.

Analiza el caso antes de avanzar haciendo los cálculos necesarios según lo

que has visto en los párrafos anteriores:

21
ESTIMADO (PLAN) Mes 1 Mes 2 Mes 3 Mes 4 Mes 5 Mes 6
casos de uso Planeados 50,00 100,00 200,00 200,00 100,00 50,00
Costo por casos de uso (en el mes) 5,50 5,50 5,50 5,50 5,50 5,50
Costo casos de uso Acumulado 275,00 825,00 1925,00 3025,00 3575,00 3850,00

REAL
casos de uso Reales 45,00 95,00 180,00 210,00 90,00 60,00
Costo por casos de uso (en el mes) 6,40 6,06 5,87 5,26 6,00 10,00
Costo casos de uso Acumulado 288,00 864,00 1920,00 3024,60 3564,60 4164,60

BCWS 275,00 825,00 1925,00 3025,00 3575,00 3850,00

ACWP 288,00 864,00 1920,00 3024,60 3564,60 4164,60
BCWP 247,50 770,00 1760,00 2915,00 3410,00 3740,00

Figura 2.10 - Ejemplo de Valor Ganado

En el ejemplo se pueden observar las tres medidas que se mencionaron

anteriormente, el BCWS muestra la Curva S original, es decir el
presupuesto, el ACWP muestra el costo real incurrido, o sea lo que
efectivamente se gastó independientemente del avance logrado, el BCWP,
normalmente conocido como “valor ganado” muestra lo que
efectivamente se hizo a valor de presupuesto.

La razón del BCWP es poder mostrar los costos incurridos en términos de

22
“avance” del proyecto, evitando que podamos caer en el error de pensar
que si se consumieron los recursos previstos el proyecto avanzó según lo
esperado.

A partir de esto se podrá hacer el análisis de avance real en términos de:

Índices:
 SPI (Schedule Performance Index)
 BCWP / BCWS
 Indicador de eficiencia sobre cronograma.
 Se usa para determinar en qué medida se ha realizado el
trabajo programado.
 CPI (Cost Performance Index)
 BCWP / ACWP
 Indicador de eficiencia sobre costos.

Proyecciones:
• EAC (Estimate At Completion)

 Presupuesto ajustado.
 Proyección del costo al fin del proyecto basado en la
performance real.
 BAC / CPI
 Donde BAC (Budget At Completion) es:
◦ Presupuesto original final
◦ El presupuesto original de costos, al fin del proyecto.
◦ El último y mayor valor del BCWS.

• TEAC (Time Estimate At Completion)

 tiempo estimado necesario para completar el proyecto

 SAC / SPI.
 Donde SAC (Schedule At Completion) es:
◦ Tiempo estimado originalmente en que se va a concluir el
proyecto, medido en días, meses, años, etc.

23
 En el ejemplo que estamos viendo:

ESTIMADO (PLAN) Mes 1 Mes 2 Mes 3 Mes 4 Mes 5 Mes 6

Casos de uso Planeados 50,00 100,00 200,00 200,00 100,00 50,00
Costo por casos de uso (en el mes) 5,50 5,50 5,50 5,50 5,50 5,50
Costo casos de uso Acum. 275,00 825,00 1925,00 3025,00 3575,00 3850,00

REAL
Casos de uso Reales 45,00 95,00 180,00 210,00 90,00 60,00
Costo por casos de uso (en el mes) 6,40 6,06 5,87 5,26 6,00 10,00

Costo casos de uso Acum. 288,00 864,00 1920,00 3024,60 3564,60 4164,60

BCWS 275,00 825,00 1925,00 3025,00 3575,00 3850,00

ACWP 288,00 864,00 1920,00 3024,60 3564,60 4164,60
BCWP 247,50 770,00 1760,00 2915,00 3410,00 3740,00
BAC 3850,00 3850,00 3850,00 3850,00 3850,00 3850,00
SPI 0,90 0,93 0,91 0,96 0,95 0,97
CPI 0,86 0,89 0,92 0,96 0,96 0,90
EAC 4480,00 4320,00 4200,00 3994,75 4024,55 4287,09
SAC 180,00 180,00 180,00 180,00 180,00 180,00
TEAC 200,00 192,86 196,88 186,79 188,71 185,29

Para completar esta unidad analice el anexo: Introducción al Método de

Valor Ganado

4.5 Caso para estudio

En base a la EDT que desarrolló en el punto 2.5 y el programa de trabajo
que desarrolló en el punto 3.6, realice la estimación de costos de uno de
los entregables del proyecto y elabore su línea base.

24
Módulo 3
Los enlaces del
proyecto, Recursos
Humanos y
Comunicaciones
5. Gestion de los Recursos
Humanos del Proyecto

5.1 Planificación organizacional

Uno de los problemas más importantes que encontramos en el proceso de
gestionar un proyecto radica en la falta de una definición clara de roles y
responsabilidades de las personas que forman el equipo de trabajo.

El conjunto de personas que hacen de un proyecto un éxito o un fracaso es

lo que se define como Recursos Humanos del Proyecto, ya que más que los
problemas técnicos, una de las dificultades en los proyectos es la de
comprender y administrar el comportamiento de la gente, ante lo cual se
necesita de personal capaz de proponer soluciones para cada uno de los
imprevistos que se pueden presentar.

Encontrar un equipo de trabajo con la actitud y el perfil, ya sea para ser

líderes o bien para ser proactivos en sus tareas, requiere de buena parte
del tiempo del gestor de proyectos.

Definir, comunicar y dejar claros los roles y responsabilidades del grupo de

trabajo del proyecto es lo que se denomina Planificación de los Recursos
Humanos del proyecto, siendo esta planificación la base de la formación y
definición de los integrantes del equipo de proyecto. Una vez definidos los
roles y responsabilidades se debe seleccionar de dónde se tomarán los
recursos humanos.

La planificación de los recursos humanos busca cumplir los siguientes fines:

1. Hacer uso de los recursos humanos de la empresa lo mejor

posible, considerando las políticas de costos.

2. Lograr un buen clima de trabajo, considerando el potencial

humano (individual y colectivo), y fijando políticas de promoción y de
formación para lograr el aprovechamiento máximo del potencial
disponible.

1
 3. Suministrar de personal directivo, técnico y de cualquier otro tipo,
necesario para llevar a cabo los objetivos de desarrollo planificados,
priorizando el desarrollo potencial del personal existente con la
antelación adecuada, antes de recurrir al mercado exterior salvo
necesidad comprobada.
4. Conseguir la satisfacción del personal, al saber que es
periódicamente valorado y tenido en cuenta para los puestos que se
vayan creando o que queden vacantes, de superior responsabilidad.

Las previsiones deben hacerse considerando al menos tres perspectivas: la

perspectiva optimista, la pesimista y la media entre ambas, para tener
previsto un amplio abanico de posibilidades y de acciones a tomar en todos
los casos. Amplitud y flexibilidad son, desde luego, dos características
esenciales.

5.2 Obtención de los recursos

humanos necesarios
Para obtener los recursos humanos necesarios para el proyecto será
necesario:
 Definir las necesidades
 Obtener el equipo del proyecto.

Definición de las necesidades:

El primer desafío al que nos enfrentamos es el de lograr una especificación
de los recursos humanos requeridos. Esta especificación deberá
contemplar al menos cuatro características:
 descripción del recurso.
 informe de capacidades y competencias requeridas.
 fecha cronológica en la que se requiere el recurso.
 tiempo durante el que será aplicado el recurso.
Las dos últimas características pueden verse como una ventana temporal.
La disponibilidad del recurso para una ventana específica tiene que
establecerse lo más pronto posible.
Quien planifica debe comenzar evaluando el ámbito y seleccionando las
habilidades técnicas que se requieren para llevar a cabo el desarrollo. Hay
que especificar tanto la posición dentro de la organización (por ej.: gestor,
ingeniero de software senior, programador, entre otros) como la
especialidad (por ej.: comunicaciones, bases de datos, microprocesadores,
entre otros).

2
El gestor debe estimar sus necesidades de personal a futuro, a fin de
prepararse para llevar a cabo sus estrategias operativas, evaluando las
posibles características de la oferta de trabajo, siendo este un proceso que
puede realizarse de manera formal o informal.

La demanda a futuro que experimenta una organización en el campo de los

recursos humanos es esencial para la planeación de las políticas de empleo,
sobre todo en lo referido a proyectos cuando el alcance, tiempos y costos
ya se conocen.

La demanda de recursos humanos en los proyectos se ve influida por

muchos condicionantes que son función de los cambios en el entorno, en la
organización y en la fuerza de trabajo. Estos factores aparecen durante
todo el proceso de gestión del proyecto.

El proceso de obtención del equipo de proyecto implica conseguir y asignar

recursos humanos al proyecto. El equipo de proyecto podrá provenir de
dentro de la organización para la cual se gestionará el proyecto o de fuera
de la misma, en la forma de empleados contratados especialmente para el
proyecto. En cualquier caso el trabajo del Líder de Proyecto será
asegurarse que los recursos estarán disponibles y que posean las
habilidades necesarias para la concreción de las actividades del proyecto
para las que fueron asignados. Sin embargo, en la práctica, puede que no
siempre se tenga control sobre la selección del equipo de proyecto. Aún en
estos casos es importante lograr un involucramiento lo más temprano
posible.

Obtención del Equipo de Proyecto

Asignación previa, negociación, adquisición y equipos virtuales son las
herramientas y técnicas utilizadas en la obtención del equipo de proyecto.
Como Gestor de Proyectos tendrás que focalizarte en lograr los mejores
talentos y conformar el mejor equipo, para ello deberás recurrir a la
negociación constantemente. Seguramente tendrás que negociar con los
mandos funcionales y con gerentes de diversos departamentos de la
organización y en el caso de contratar un servicio de desarrollo de terceros,
negociar para contar con las personas con mejores capacidades para las
tareas previstas. Los puntos más importantes para tener en cuenta en la
negociación son:

 Conocer las necesidades del proyecto y su prioridad dentro de la

organización
 Ser capaz de expresar para que y por qué se necesita un
determinado recurso
 Entender que el área de RRHH tiene su propio trabajo y objetivos y
que el proyecto puede no ser uno de ellos
 No requerir los mejores recursos si no se los necesita realmente

3
  Ser capaz de probar, mediante el uso de las herramientas de gestión
de proyectos, tales como diagramas de red o cronogramas, porqué
necesita los mejores recursos, si es que los necesita
 Utilizar la negociación como una oportunidad de descubrir lo que el
área de RRHH necesita en orden de manejar sus propios recursos
 Construir una relación con el experto en recursos humanos, tal que
se pueda contar con él cuando se lo necesite.

5.3 El gerente de proyectos

Gestionar el equipo y entregar los resultados prometidos es la principal
responsabilidad del gerente de proyectos. Crear el clima de trabajo
adecuado es su responsabilidad de liderazgo.

La importancia de la figura del director del proyecto queda reflejada en un

párrafo de un informe del Departamento de Defensa de los EEUU sobre el
proyecto STARS de investigación sobre la reutilización de software que
dice:

"El director del proyecto juega el papel más importante en la Ingeniería del
Software y su soporte. La diferencia entre el éxito o el fracaso -entre un
proyecto que se desarrolla en fecha y en presupuesto, o uno retrasado y sin
control de costos- es, a menudo, una función de la eficacia de ese director".

El director del proyecto tiene las siguientes cinco funciones principales:

1. Alcanzar los objetivos definidos mediante la planificación del

trabajo a realizar.
2. Definir y organizar al equipo de trabajo que realizará el proyecto.
3. Asignar trabajo al personal del equipo de proyecto.
4. Controlar el progreso.
5. Liderar el equipo de personas.

Ahora nos centraremos en el liderazgo, la más abstracta de las cinco

funciones.

El liderazgo involucra:

▪ Motivar y recompensar:
Es asegurar que todos los miembros del equipo conocen que su
trabajo es apreciado y reconocido como se describió anteriormente.

▪ Mantener la perspectiva:
Es importante mantener al equipo equilibrado. Los equipos que han
trabajado juntos durante mucho tiempo caen en la trampa de
convertirse en islas. Se manifiesta en que estos consideran a otros
grupos como inferiores, siendo resistentes al cambio o influencias

4
 externas, atribuyendo escaso rendimiento a los demás y de alguna
manera sintiéndose aparte del resto de la organización. Aún el
orgullo y espíritu de equipo fuerte puede ser contraproducente si se
convierte en vanidad y retraimiento con lo que se puede producir
una degradación del equipo. Es función del director del proyecto
estar seguro de que el equipo mantiene su perspectiva.

▪ Animar al grupo a tomar decisiones:

Significa conocer cuándo se deben tomar las decisiones en grupo y
cuándo individualmente. Se ha demostrado que las decisiones de
grupo no son necesariamente un reflejo de las opiniones individuales
del grupo. Por ejemplo, un líder fuerte puede influir en el grupo para
que este tome decisiones de alto riesgo para las cuales a nivel
individual podrá no haber acuerdo.

▪ Supervisar y mantener el comportamiento del grupo:

Es un importante papel del liderazgo. Los grupos pueden
comportarse de una manera distinta a lo que sería característico de
los individuos en el grupo. Explotar este potencial es importante para
el líder. Bien estructurados, los equipos positivos pueden conseguir
más que cualquier individuo. La inversa también es verdad. El
comportamiento del grupo puede ser destructivo para el mismo
grupo y para aquellos que dependen de su trabajo. El
comportamiento irracional del grupo puede exceder a los actos
individuales.

▪ Asegurar que todos ganan:

Esto es esencial en la negociación del contrato a través del proceso
de planificación y en la motivación del equipo.

El Estilo de los Directores de Proyecto

Los directores de proyectos pueden adoptar diferentes estilos.
Mencionaremos algunos estilos posibles, no sin antes aclarar que no hay
un mejor o peor estilo, sino más bien habrá estilos más o menos adecuados
al grupo, al proyecto y al momento particular.

 Director:
Este tipo de directores dicen al equipo qué deben hacer y cómo. Este
estilo puede ser apropiado en ocasiones durante la ejecución y cierre
del proyecto, es decir, cuando las especificaciones y diseño del
producto han sido decididos y el diseño real está siendo gestado, de
tal manera que se consiga la pronta terminación del proyecto y se
obtenga el retorno de la inversión lo antes posible.

5
  Facilitador:
Los líderes de este tipo permiten a los miembros del equipo
autogestionarse. Se comportan como los miembros del equipo y se le
consulta si se requiere. Este estilo suele ser más apropiado al
comienzo del desarrollo o etapa de viabilidad de un proyecto o en
proyectos de investigación.

 Entrenador:
Los directivos de este tipo instruyen y guían a los miembros del
equipo en aquello que se debe hacer y cómo hacerlo. Se comportan
como los miembros del equipo y se le consulta si se requiere. Este
estilo es apropiado cuando el director tiene probada experiencia en
el tema del proyecto y el equipo de trabajo respeta dicha
experiencia.

 Democrático:
Los directores democráticos consultan a sus equipos y deciden
entonces el mejor camino para actuar. Este estilo puede ser
apropiado durante la viabilidad y planificación de las etapas del
proyecto, cuando se quiere animar a las personas a contribuir con sus
ideas.

 Autocrático:
Los directores autocráticos dicen al equipo qué deben hacer y cómo,
sin tener en cuenta opiniones ni consideraciones del equipo. Este
estilo rara vez tiene una respuesta eficaz a los problemas que pueden
aparecer, ya que el equipo está aislado y no comparte las decisiones
del director. Aún así es muy necesario en momentos de crisis y
necesidad de respuestas rápidas, (cuando el barco se hunde no hay
tiempo para reuniones democráticas)

 Burocrático:
Los directores burocráticos dirigen a través de reglas y
procedimientos. Este estilo es habitualmente apropiado solamente
en proyectos de bajo riesgo, para los cuales se esperan muy pocos
cambios, ya que un a un directivo burocrático se le hace difícil
responder rápidamente a estos.

Ya mencionamos que no podemos aseverar que un estilo es mejor que

otro, aunque, en el contexto de los proyectos puede ser apropiado hablar
de algunos estilos que son “menos apropiados” que otros. Por ejemplo: un
tecnócrata es una persona para la cual la ciencia es más importante que los
resultados, los medios más importantes que los fines. Esta persona busca la
solución ideal, en lugar de buscar una solución adecuada que satisfaga los
requisitos de los clientes. Usualmente es incapaz de delegar,
argumentando su falta de fe en el equipo del proyecto para alcanzar el
resultado perfecto. El burócrata puede ser ineficaz en cuanto a su obsesión

6
por seguir los procedimientos, convencido de que el trabajo se ha realizado
correctamente, aunque no sea eficaz. El vendedor es la persona que es
muy buena promocionando el proyecto, pero no alcanzando resultados.
Las tres características de estos - habilidad técnica, aplicación del mejor
método y vendedor - son buenas si se aplican con moderación, pero se
convierten en debilidades cuando se aplican en exceso como si fueran más
importantes que el resultado del proyecto.

El Director de Proyecto Eficaz

Los rasgos más característicos del líder eficaz son:

 Habilidad para resolver problemas y orientación a los resultados:

Los directores eficaces tienen usualmente una inteligencia por
encima de la media, y son capaces de resolver problemas complejos
analizando la situación actual y reconociendo modelos.

La gestión de proyectos es una actividad de solución de problemas:

La consecución del propósito del proyecto es un problema, así como
la terminación de cada etapa de su ciclo de vida. Asimismo, los
procesos de control también lo son. Sin habilidad para resolver
problemas un director de proyectos estaría perdido.

El proyecto no es terminar el producto por amor al trabajo, sino

conseguir el fin deseado. Así, la solución a los problemas debería
permitir alcanzar los objetivos planificados y el propósito definido, no
necesariamente terminar el trabajo acordado inicialmente.

 Energía e iniciativa:
El director de proyecto debe tener también la habilidad de trabajar y
gestionar bajo una presión considerable y constantes problemas.
Todo ello requiere que el director sea enérgico y fuerte. Esta energía
debe ser complementada con iniciativa para buscar la acción y
resolver las tareas en el tiempo adecuado.

 Seguridad en sí mismo:
Los directores deben estar seguros de sí mismos respecto a que lo
que están haciendo es correcto. Esto no significa que sean
extrovertidos o impetuosos, sino que deben actuar de manera
resolutiva, confiando en sus opiniones y juicios. Algunas veces, es
mejor actuar basados en información incompleta, estando prestos a
modificar la acción cuando se disponga de nueva información, que
estar esperando por la solución perfecta, mucho más cuando de
proyectos se trata. Los directores seguros de sí mismo también
delegan en su equipo de proyecto, confían en la habilidad de sus
miembros y en su propia habilidad para motivarlos. Algunas veces y

7
 en especial en la industria de las Informática, los buenos técnicos son
promocionados a posiciones directivas, pero son muy reacios a
delegar ya que creen que pueden hacer el trabajo mejor que nadie,
desarrollando actividades técnicas mientras que los miembros del
equipo están parados y, consecuentemente, desmotivados.

 Perspectiva:
Los directivos necesitan ser capaces de mirar más allá del equipo y
ver cómo encaja dentro de la organización como un todo. Esta
necesidad de perspectiva, se extiende al trabajo del proyecto.

El director debe ser capaz de moverse libremente a través de los

niveles de la jerarquía y sobre todo, comprender sus niveles de
detalle, cómo cumplen con sus objetivos y entender cómo éstos
darán respuesta a las necesidades del proyecto.

 Capacidad de Comunicación:
Similarmente, los directores deben ser capaces de comunicarse a
todos los niveles de la organización, y en todos los canales del
proyecto (esto incluye canales formales e informales); deben ser
embajadores del proyecto y convencer a la alta dirección para
obtener su apoyo; deben ser capaces de hablar con sus
interlocutores, directores funcionales y proveedores de recursos para
obtener su cooperación; ser breves y capaces de motivar al equipo.

 Habilidad negociadora:
El plan del proyecto debe ser un contrato; es, en efecto, un contrato
entre el director del proyecto (especificando lo que el director del
proyecto y su equipo van a proporcionar a la organización) y los
patrocinadores del proyecto (especificando el soporte que facilitarán
para entregar los resultado contratados). Como todos los contratos,
el plan de proyecto debe ser negociado y conciliado entre ambas
partes. El director del proyecto debe valerse de su habilidad para
negociar ya que no tiene línea de autoridad directa sobre los recursos
como un director funcional. También, debe lograr y mantener el
compromiso y cooperación de otras personas a partir de su habilidad
para negociar y persuadir.

5.4 El equipo de proyectos

Cuando se constituye el equipo de proyectos, el director del proyecto
reúne a un grupo de personas y desarrolla en el grupo una personalidad o
identidad, de tal manera que pueden trabajar conjuntamente utilizando un
conjunto de valores comunes o normas para alcanzar los objetivos del
proyecto.

8
El concepto de identidad percibido por el grupo es crítico para la formación
del equipo: sin ella, el grupo de personas se mantendría como un conjunto
de individuos aislados. Lo importante a la hora de crear un equipo de
proyecto es el desafío de lograr que un grupo de personas que
probablemente nunca han trabajado juntas antes, se reúnan y sean
capaces de trabajar eficaz y rápidamente en algo nuevo. La novedad,
unicidad, riesgo y transitoriedad son propiedades inherentes a los
proyectos. El equipo recientemente constituido, al comienzo no ha
percibido su identidad, careciendo de un conjunto de normas y valores
para trabajar por lo que lleva tiempo el desarrollar esta personalidad y
normas, lo cual atenta contra la consecución de los objetivos en tiempo.
Los miembros de un equipo se deben identificar con dicho equipo y
desarrollar un conjunto común de valores o normas, antes de que puedan
trabajar juntos eficazmente como grupo. Este proceso de crear la identidad
de un equipo y un conjunto de valores lleva tiempo y es uno de los factores
responsables del “síndrome de inicio difuso”.

El equipo normalmente pasa por cinco etapas en su desarrollo y camino al

alto rendimiento que son:

 Formación
 Tormenta
 Normalización
 Rendimiento
 Despedida

 Formación:
Los miembros del equipo llegan con un sentido de ansiedad y
compromiso. Su motivación es alta al haber sido seleccionados para
el proyecto y su eficacia moderada ya que están poco seguros unos
de otros. Por lo general y muy a pesar de lo que normalmente se
piensa, en esta etapa del proyecto la productividad es baja a pesar
que el clima es muy bueno.

 Tormenta:
Conforme los miembros del equipo comienzan a trabajar juntos,
encuentran que tienen discrepancias acerca de la mejor manera de
alcanzar los objetivos del proyecto y diferentes modos de trabajar.
Cada integrante necesita encontrar su lugar y estas diferencias
pueden causar discusiones y conflictos en el equipo, lo cual hace que
la eficacia y la motivación decaiga. Este es un momento propicio para
que el director del proyecto pueda observar cómo se resuelven los
conflictos e interacciones entre los miembros, a sabiendas de que es
un proceso natural y hasta necesario para luego salir adelante.

9
  Normalización:
Si la dirección es la apropiada y el equipo puede superar esta etapa
es normal que los conflictos se ajusten y disminuyan. Esto se logra
sobre la base de un proceso de negociación, compromiso y búsqueda
de áreas de coincidencia. Como resultado, el equipo comienza a
desarrollar un sentido de identidad y un conjunto de normas y
valores comunes. Esto constituye una base sobre la cual los
miembros del equipo pueden trabajar conjuntamente y la eficacia y
la motivación comienzan a incrementarse.

 Rendimiento:
Una vez que el rendimiento alcanza un nivel adecuado, el equipo
trabajará eficazmente durante el resto del proyecto. El director del
proyecto tiene la responsabilidad de mantener este nivel de
rendimiento si bien después de que el equipo ha estado trabajando
mucho tiempo, sus miembros pueden comenzar a perder su eficacia.
Si esto ocurre, el director puede necesitar cambiar la estructura o la
composición del equipo.

 Despedida:
Cuando el proyecto llega al final, el equipo también se aproxima al
final de su trabajo, esta situación crea nuevas ansiedades y esto es
causa de alguna de las siguientes dos situaciones:

 la eficacia puede incrementarse ya que los miembros del

equipo hacen un último esfuerzo para terminar su trabajo.
 la eficacia puede decaer, ya que los miembros del equipo
perciben el final del trabajo y rompen las relaciones que
habían establecido a la vez que se preparan para encarar
otros desafíos perdiendo probablemente foco en este.

El Director de proyecto deberá estar atento a esta circunstancia para

alentar al equipo a estar atento a nuevas oportunidades a la vez que no
descuidan el proyecto.

Una vez constituido el grupo, el papel del director es asegurar que se

continuará trabajando al nivel de eficacia máximo. El director del proyecto
debe ser capaz de determinar la eficacia real del equipo. Esto puede ser
evaluado analizando la forma en que el equipo consigue las metas
acordadas y cómo se satisfacen las aspiraciones, necesidades y
motivaciones a nivel individual y grupal. El líder del equipo y la gestión de
línea de la organización deben asegurar que tanto los objetivos de la
corporación como los personales se alcanzan. Si solamente se logran las
metas corporativas, entonces con el tiempo se producirá una erosión de la
eficacia y la moral seguidas de un desgaste del personal.

10
A menudo, sin embargo, es posible medir el logro de los objetivos
solamente al final del proyecto con lo cual es muy tarde para tomar
acciones correctivas, de aquí que sea importante obtener medidas que
permitan juzgar la cohesión y la fortaleza de un grupo durante el proyecto.
Existen ciertos indicadores de la eficacia del equipo, entre los que cabe
destacar:

 Asistencia: Bajo ausentismo, baja tasa de accidentes, enfermedad,

interrupciones en el trabajo y rotación.
 Claridad de objetivos: Los objetivos individuales se han definido,
comprendido y alcanzado así como los objetivos del grupo. Cada
miembro del equipo tiene un conocimiento claro del papel del grupo.
 Calidad de producción: Alto compromiso con la consecución de
objetivos; búsqueda de soluciones reales; solución de problemas
críticos utilizando todos los conocimientos y capacidades.
 Fuerte cohesión del grupo: Apertura y confianza entre los miembros
del grupo, comparación de ideas y conocimiento, reuniones vivas y
constructivas.

Grupos Existentes en el Equipo de Proyecto

En cualquier contexto, pueden existir tres grupos distintos dentro de un
equipo de proyecto:

 Grupo primario: Es el conjunto de personas que trabajan codo con

codo y se conocen en el grupo. En un proyecto suele haber un equipo
permanente y otro a tiempo parcial.

 Grupo secundario: Es mayor que el anterior y son las personas que

tienen relación con las del grupo primario y contribuyen
directamente a su trabajo, pero no son parte del equipo. Sin
embargo, para que sean eficaces deben tratarse como
pertenecientes al equipo de proyecto.

 Grupo terciario: Son personas que tienen influencia sobre miembros

de los equipos primario y secundario, o se ven afectados por el
trabajo del proyecto, pero no contribuyen al mismo directamente
con su trabajo. Este grupo se puede dividir en tres subgrupos:

 los afectados por el trabajo del proyecto: comprenden a las

personas que tienen una relación con el personal del primer o
segundo grupo. Pueden ser familiares y amigos o grupos
profesionales.
 los afectados por la facilidad obtenida en un proyecto: son los
que trabajan con el medio una vez entregado o son las personas

11
 cuyas vidas cambiarán de una forma irreversible con el uso de ese
medio.
 los afectados por los productos fabricados con dicha facilidad:
son los consumidores, las personas que adquieren los productos
producidos. Algunas veces son usuarios, otras no.

Las expectativas de todas estas personas deben ser gestionadas si se quiere

verdadero éxito en el proyecto ya que tienen poder para hacerlo fracasar.

Como ejemplo, consideremos un equipo que realiza un desarrollo de

software. El equipo de desarrollo es el grupo primario. El grupo secundario
es el departamento de sistemas al que pertenece ese equipo. El tercer
grupo está constituido por asociaciones profesionales como el Colegio de
Ingenieros Especialistas, otros desarrolladores dentro de la empresa, el
comité de gestión de cambios y la administración (subgrupo l). Los usuarios
constituyen el segundo subgrupo y sus familiares el tercer subgrupo.

Factores de Motivación del Equipo de Proyecto

La mayoría de los proyectos se desarrolla dentro de organizaciones que
entran dentro del esquema de gestión de proyectos del tipo matricial, por
lo que la motivación del equipo de proyecto es fundamental para el gestor
del proyecto.

Pero ¿Cómo se puede recompensar al personal del proyecto

sin entender lo que los motiva?

En el entorno de un proyecto, sin jerarquías funcionales, títulos, rangos,

símbolos de poder y estado, no existen muchos de los factores que son
vistos tradicionalmente como útiles para motivar al personal profesional.
Los directores de proyecto deben buscar nuevos factores motivadores que
sean válidos en ese entorno. Muchas personas se motivan por el desarrollo
de su carrera, pero ya que no es posible juzgar dicho desarrollo por su
posición jerárquica, dado el tipo de entorno en el que se mueven, debe
medirse su propio progreso y aprendizaje dentro y a través de la
organización.

Muchas son las teorías de motivación pero indiscutiblemente no podemos

hablar de este tema sin citar a la más difundida, la teoría de Maslow.

12
La Pirámide o Jerarquía de Maslow
El psicólogo Abraham Maslow desarrolló dentro su la Teoría de la
Motivación, una jerarquía de las necesidades que los hombres buscan
satisfacer. Estas necesidades se representan en forma de una pirámide de
cinco niveles:

Figura 3.1: Pirámide de Necesidades de Maslow

A efectos de comprender la teoría, debemos comprender sus postulados

fundamentales:
 Un ser humano tiende a satisfacer sus necesidades primarias
 (más bajas en la pirámide), antes de buscar las de más alto nivel.
 Un tipo de necesidad debe ser sustancialmente satisfecho antes que
el siguiente aparezca.
 Los niveles superiores pueden satisfacerse de modos más diversos
que los inferiores.

Por ejemplo, una persona no busca tener satisfechas de seguridad (por

ejemplo, evitar los peligros del ambiente) si no tiene cubiertas sus
necesidades fisiológicas, como comida, bebida, aire, etc.

A continuación presentamos una breve descripción de los escalones de la

pirámide de necesidades de Maslow.1

Necesidades fisiológicas
Las necesidades fisiológicas son satisfechas mediante comida,
bebidas, sueño, refugio, aire fresco, una temperatura apropiada,
entre otras. Si todas las necesidades humanas dejan de ser
1
Extraído de http://www.webislam.com/articulos/34942-la_piramide_de_maslow.html 23-10-
2013

13
satisfechas entonces las necesidades fisiológicas se convierten en la
prioridad más alta. Si se le ofrecen a un humano soluciones para dos
necesidades como la necesidad de amor y el hambre, es más
probable que el humano escoja primero la segunda necesidad, (la de
hambre). Como resultado todos los otros deseos y capacidades pasan
a un plano secundario.

Necesidades de seguridad
Cuando las necesidades fisiológicas son satisfechas entonces el ser
humano se vuelve hacia las necesidades de seguridad. La seguridad
se convierte en el objetivo de principal prioridad sobre otros. Una
sociedad tiende a proporcionar esta seguridad a sus miembros.
Ejemplos recientes de esa pérdida de seguridad incluyen Somalia y
Afganistán. A veces, la necesidad de seguridad sobrepasa a la
necesidad de satisfacción fácil de las necesidades fisiológicas, como
pasó por ejemplo en los residentes de Kosovo, que eligieron dejar un
área insegura para buscar un área segura, contando con el riesgo de
tener mayores dificultades para obtener comida. En caso de peligro
agudo la seguridad pasa delante de las necesidades fisiológicas.

Necesidades de amor, Necesidades sociales

Debemos resaltar en este apartado que no se puede hacer
equivalente el sexo con el amor. Aunque el amor puede expresarse a
menudo sexualmente, la sexualidad puede en momentos ser
considerada sólo en su base fisiológica.

Necesidades de estima, Necesidad de Ego

Esto se refiere a la valoración de uno mismo otorgada por otras
personas.

Necesidades del ser, Necesidades de Autoestima

Es la necesidad instintiva de un ser humano de hacer lo máximo que
pueden dar de sí sus habilidades únicas. Maslow lo describe de esta
forma: "Un músico deba hacer música, un pintor, pintar, un poeta,
escribir, si quiere estar en paz consigo mismo. Un hombre, (o mujer)
debe ser lo que puede llegar a ser). Mientras las anteriores
necesidades pueden ser completamente satisfechas, ésta necesidad
es una fuerza impelente continua.

14
Muchas de estas motivaciones no son válidas en un entorno de proyectos.
Sin embargo, la jerarquía de Maslow continúa proporcionando una base
para los factores motivacionales. Muchas personas han pasado el punto en
el que la propiedad es el primer aspecto a ser satisfecho en el trabajo y
buscan satisfacer ahora la estima y la realización. Esto lleva a cinco nuevos
factores para una motivación eficaz (Fuente: Planificación de Sistemas de
Información, Adolfo Pérez García, UPM):

 Propósito
 Pro actividad
 Compartir beneficios
 Progresión
 Reconocimiento profesional

Propósito:
Las personas tienen que creer en la importancia de su trabajo, y que
contribuyen al desarrollo de la organización. Este sentido del propósito y la
conexión entre el trabajo del proyecto y la misión de la organización
corporativa, puede ayudar a vencer la incertidumbre de la dependencia
dual en las estructuras matriciales.

Proactividad:
Conforme se progresa en la carrera y ésta se hace menos clara y
predecible, y los puestos directivos se ven lejanos, las personas quieren
gestionar sus propias carreras. Haciendo énfasis en la consecución de los
resultados, más que en el papel desempeñado, delegando en ellos la
actividad profesional y evaluándolos a través de dichos resultados, da a los
subordinados la oportunidad de tomar responsabilidades para su propio
desarrollo.

Más aún, si se permite a las personas elegir su siguiente proyecto como

una recompensa por su buen rendimiento en el actual puede verse
satisfecha esta necesidad.

Compartir beneficios:
Permitir a las personas compartir la cultura de la iniciativa les animará a
valorarla. Muchas organizaciones animan a sus empleados a resolver sus
propios problemas y a tomar iniciativas para satisfacer los requisitos de sus
clientes y permitir a sus empleados compartir los beneficios. El creciente
número de trabajadores por cuenta propia también demuestra que
muchas personas están tomando esta iniciativa, pero bajo su
responsabilidad.

Conforme las personas se acercan a la cima de la jerarquía de Maslow,

comienzan a ser conscientes de la necesidad de su autorealización. Valoran
entonces las oportunidades de incrementar sus posibilidades de

15
aprendizaje. Cada nuevo proyecto es una oportunidad para adquirir nuevas
destrezas e incrementar la estima personal y auto-realizarse. Sin embargo,
como ya se comentó, en las estructuras muy planas, las personas pueden
tener menos hitos en su carrera por las que medir su progresión. La vara de
medir que aún permanece es el dinero u otros símbolos de status dentro
de la compañía.

Reconocimiento profesional:
Otra medida de la realización es el reconocimiento profesional. Los
ingenieros del software no quieren el anonimato del burócrata, quieren
acumular méritos que contribuyan a su autoestima y a su realización. Los
directores de línea son los responsables de asegurar que sus subordinados
reciben el reconocimiento debido.

Teoría de la Motivación e Higiene de Herzberg

Frederick Irving Herzberg fue un renombrado psicólogo que se convirtió en
uno de los hombres más influyentes en la gestión administrativa de
empresas. Es especialmente reconocido por su teoría del enriquecimiento
laboral y la teoría de la Motivación e Higiene.
Herzberg propone dos tipos de factores que influyen sobre la motivación
en el trabajo, los factores de higiene (previenen la No satisfacción) y los
factores de auténtica motivación (motivan).

Los factores de higiene son factores que influyen negativamente sobre el

trabajador y que, una vez corregidos, colocan a la persona en un nivel 0 de
No insatisfacción. Son factores de higiene por ejemplo la política de
empresa, la supervisión, el sueldo o el status en el trabajo. Contrariamente
a lo que se pueda creer el sueldo, por ejemplo, no es un factor motivador,
sino desmotivador, es decir, si una persona siente que está cobrando
menos de lo que debería se siente insatisfecha y su motivación decae, por
el contrario, si su sueldo es adecuado se siente conforme pero no
necesariamente se motiva en exceso.

Por ese motivo los factores de higiene, aunque no motivan propiamente,

deben ser tratados para “limpiar” el entorno de trabajo o la situación del
trabajador de forma que no se desmotive, mientras que los factores de
motivación (como pueden ser el reconocimiento, la responsabilidad o un
ascenso) son los que verdaderamente aumentan la motivación y ganas por
cumplir un objetivo.
 Factores de higiene
 Seguridad.
 Sueldo.
 Relación con el supervisor.
 Beneficios y servicios sociales.

16
  Factores de motivación
 El trabajo en sí mismo
 El Reconocimiento.
 La Responsabilidad.
 Progresión profesional.

Desarrollar el Equipo de Proyecto

El desarrollo del equipo de proyecto tiene como finalidad lograr la cohesión
del grupo de trabajo a efectos de lograr los mejores intereses del proyecto
e incrementar el rendimiento del proyecto.

Analicemos el concepto de confianza, una pregunta que deberíamos

hacernos es si existe confianza en el proyecto.

¿El equipo siente que el Líder de Proyecto está trabajando por

los mejores intereses del proyecto, de la organización y de
ellos mismos o siente que solo está trabajando por sus
intereses personales?

La confianza debe ser ganada y mantenida desde el primer minuto que se

incorpora cada miembro al equipo. Si no existe confianza en el Líder de
Proyecto difícilmente el proyecto será exitoso, ya que el equipo no seguirá
las indicaciones del Líder y el proyecto sufrirá las consecuencias. La mejor
forma de lograr la cohesión de un equipo de proyecto es logrando su
confianza y estableciendo y cumpliendo con un sistema claro de
recompensas.

Capacitación del Equipo de Proyecto

Cualquier capacitación o entrenamiento para los miembros del equipo de
proyecto, con el objetivo de mejorar el rendimiento y las posibilidades de
éxito del mismo, debería estar incluida en los costos del proyecto. El
Project Manager debe buscar tales oportunidades, no solo para la ayuda y
el buen ánimo de los miembros del equipo, sino también para lograr el
decremento global de los costos y plazos por la mejora de eficiencia en el
logro de los objetivos.

Reglas Básicas
Las reglas básicas establecen expectativas claras acerca del
comportamiento aceptable por parte de los miembros del equipo del
proyecto. El compromiso con pautas claras desde las fases tempranas

17
reduce los malos entendidos y aumenta la productividad. El proceso de
discutir las reglas básicas permite a los miembros del equipo descubrir
valores que son importantes para unos y otros. Todos los miembros del
equipo del proyecto comparten la responsabilidad de aplicar las reglas una
vez establecidas.

Equipos Virtuales o Reubicación

Los equipos de trabajo virtuales son aquellos cuyos miembros no se
encuentran trabajando habitualmente en el mismo lugar físico, por lo que
rara vez o tal vez nunca lleguen a conocerse personalmente. Es difícil para
muchos gestores de proyecto dirigir esta tipología de equipos, debido a
que es muy difícil conseguir la cohesión y el compromiso de equipo cuando
los miembros no están por lo general cara a cara, creando conflictos,
disminuyendo la productividad y otros impactos que afectan a los plazos y
al costo del proyecto.

En lo posible se debe conseguir que el equipo trabaje físicamente en el

mismo lugar, siendo lo óptimo que todo el equipo trabaje inclusive en las
mismas oficinas, logrando lo que se conoce como “war room” o la
habitación donde se da la batalla del proyecto. La relocalización del equipo
en un mismo lugar tiene efectos muy positivos ayudando a la
comunicación, disminuyendo el impacto de los conflictos y mejorando la
identidad de grupo del equipo de proyecto.

Reconocimientos y Recompensas
Es necesario que los métodos de evaluación y los consiguientes
reconocimientos y recompensas sean conocidos por todos los interesados
del proyecto.

Debería recompensarse sólo el comportamiento deseable. Por ejemplo,

debería recompensarse o reconocerse la buena disposición para trabajar
horas extra a fin de cumplir con un objetivo agresivo del cronograma, pero
no debería recompensarse la necesidad de trabajar horas extra como
consecuencia de una planificación deficiente. Las recompensas ganar-
perder (suma cero) que sólo una cantidad limitada de miembros del equipo
del proyecto pueden lograr, tales como el miembro del equipo del mes,
pueden perjudicar la cohesión del equipo.

Recompensar el comportamiento ganar-ganar que todos pueden lograr,

tales como presentar puntualmente los informes de progreso, tiende a
aumentar el respaldo entre los miembros del equipo.

18
Valoración del Rendimiento del Equipo
La valoración de rendimiento del equipo es realizada por Project Manager
para evaluar e incrementar la efectividad del equipo de proyecto como un
todo. Es necesario pensar la valoración de rendimiento del equipo como
“efectividad del equipo”. Esto puede incluir una evaluación de la mejora de
las habilidades para desarrollar las actividades del proyecto por parte de
los miembros del equipo, como interactúan y resuelven conflictos, y tasas
de productividad.

Una novedosa y sofisticada forma de evaluación para completar las

evaluaciones de desempeño es incluir los compañeros de trabajo y
subordinados, como así también de los supervisores.

Esto puede resultar en un panorama más claro utilizando los principios de

retroalimentación de 360 grados. El término “360 grados” significa que la
persona que está siendo evaluada recibe retroalimentación sobre su
rendimiento desde muchas fuentes, incluidos los superiores, colegas y
subordinados.

Gestionar el Equipo de Proyecto

Gestionar el equipo de proyecto es completamente distinto a desarrollar el
equipo de proyecto.

Con el objetivo de gestionar el equipo de proyecto el Project Manager

deberá:

 Observar
 Utilizar una agenda de temas
 Mantenerse en contacto
 Completar las evaluaciones de rendimiento del proyecto
 Involucrarse activamente en buscar y ayudar a resolver los conflictos
que el equipo no pueda resolver por cuenta propia

La gestión del equipo se realiza durante el proceso de monitoreo y control

del proyecto y fija su atención en la evaluación de desempeño del equipo
de proyecto. Esto puede ser algo que no se haga habitualmente en la
mayoría de los proyectos, ya que a nadie le gusta ser medido en su
desempeño ni medir el desempeño de los demás, pero si no se realiza el
proyecto sufrirá las consecuencias de las fallas de cualquier miembro del
equipo.

La buena gestión de proyectos precisa que el equipo de proyecto ayude en

la creación del plan de gestión del proyecto. Como resultado de esto, es
más aceptable que sean medidos por aquello que ayudaron a estimar o

19
definir como metas. Si se tienen dificultades para conseguir apoyo o
cooperación, podría suceder porque existe falta de confianza, porque
existe un sistema pobre de reconocimientos o recompensas o aún más
grave, porque el equipo de proyectos y los interesados en el proyecto no
fueron tenidos en cuenta en la creación del plan de gestión del proyecto.

Otra razón para medir el rendimiento de los miembros del equipo es para
el beneficio de cada uno de los miembros. Es necesario pensar en la
disminución de la confianza y de la motivación del equipo, más la angustia
y otros efectos que genera, que una persona no esté realizando lo que se
espera, mientras los demás cumplen con lo acordado.

Observación y Conversación
La observación y la conversación se usan para mantenerse en contacto con
el trabajo y las actitudes de los miembros del equipo del proyecto. El
Project Manager debe observar lo que pasa y mantener informado al resto
del equipo de lo que pasa.

Evaluaciones del Rendimiento del Proyecto

La evaluación de los rendimientos de los empleados para aquellos que los
supervisan es común en la práctica de negocios del mundo entero.

La necesidad de realizar evaluaciones formales o informales del

rendimiento del proyecto depende de la duración del proyecto, de la
complejidad del proyecto, de la política de la organización, de los requisitos
de los contratos de trabajo, y de la cantidad y calidad de la comunicación
regular.

El Project Manager puede ajustar el proyecto para manejar los cambios de

rendimiento basado en estas evaluaciones.

Agenda de Temas
Es común que los Directores de Proyectos mantengan una agenda de
temas a ser resueltos en el proyecto, siendo esta una herramienta para el
manejo de las necesidades de los interesados (Stakeholders) y el equipo de
proyecto. Esta agenda de temas les muestra a los interesados que sus
necesidades son tenidas en cuenta, aun cuando el tiempo para cumplir con
ellas pueda ser escaso.

20
Gestión de Conflictos
Una gestión de conflictos exitosa tiene como resultado una mayor
productividad y relaciones laborales positivas. Fuentes de conflicto
incluyen recursos escasos, prioridades del cronograma y estilos de trabajo
personales. Las reglas básicas del equipo, las normas de grupo y las
prácticas de dirección de proyectos sólidas, como la planificación de la
comunicación y la definición de roles, reducen la cantidad de conflictos. Si
se manejan apropiadamente, las diferencias de opinión son saludables y
pueden llevar a una mayor creatividad y a una mejor toma de decisiones.
Cuando las diferencias se convierten en un factor negativo, los miembros
del equipo del proyecto son inicialmente responsables de resolver sus
propios conflictos. Si el conflicto se intensifica, el director del proyecto
debería ayudar a facilitar una resolución satisfactoria. Los conflictos
deberían tratarse en las fases tempranas y por lo general en privado,
usando un enfoque directo y constructivo. Si continúan los conflictos
negativos, será necesario recurrir a procedimientos cada vez más formales,
incluida la posibilidad de adoptar acciones disciplinarias. (PMBoK, PMI).

Las preguntas que suelen surgir son: ¿Es malo el conflicto?

¿Debería invertir tiempo en prevenir los conflictos? ¿Quién
debe resolver el conflicto?

Aunque la mayoría de los conflictos pueden percibirse como malos,

generalmente presentan una oportunidad de mejora ya que el proceso de
resolución pone de manifiesto información oculta del equipo y del
proyecto.

5.5 Caso para estudio

Estudio de caso sobre delegación de autoridad, conflictos y
Gerente de proyecto.
(Adaptado de propuesta de Guido Clements)

Codeword es una empresa de tamaño medio que diseña y fabrica

sistemas electrónicos para aeronaves militares. Compite con otras
empresas para obtener contratos para suministrar esos sistemas.
Su principal clientes es el gobierno. Cuando Codeword recibe un
contrato, crea un proyecto para terminar el trabajo. La mayor
parte de los proyectos oscilan desde los 10 a los 50 millones de
dólares en costo y de 1 a 3 años de duración. Codeword puede
tener en cualquier momento de 6 a 12 proyectos en proceso, en
diversas etapas de terminación.

21
Codeword tiene un pequeño grupo de gerentes de proyectos que
depende del Gerente General; otras personas dependen de su
gerente funcional. Por ejemplo, los Ing. Electrónicos dependen del
Gerente de Ingeniería Electrónica, quien a su vez depende del
Gerente General. El Gerente. Funcional asigna personas
específicas para trabajar en diversos proyectos, algunos de tiempo
completo en un proyecto, mientras que otros dividen los tiempos
entre 2 o más proyectos.

Jack ha estado en la compañía aproximadamente 8 años, desde

que se graduó en la universidad en Ing. Electrónica. Ha ido
ascendiendo hasta ser el principal Ing. Electrónico y depende del
Gerente de Ing. Electrónica. Ha trabajado en muchos proyectos y
es muy respetado en la empresa.

Jack ha estado pidiendo la oportunidad de ser gerente de

proyectos. Cuando se le otorgó a Codeword un contrato de 15
millones de dólares para diseñar y fabricar un sistema electrónico
avanzado para una nueva aeronave, el Gerente ascendió a Jack a
Jefe de Proyectos y le pidió dirigir este proyecto.

Jack trabaja con los gerentes funcionales para lograr que se asigne
al proyecto el mejor personal disponible. La mayoría de estas
personas son amigos de Jack que han trabajado con él en proyecto
anterior. Sin embargo, al estar vacante el puesto de Jack como
principal Ing. Electrónico, el Gerente de Ingeniera Electrónica no
tiene a nadie con el nivel de conocimientos apropiados para
asignarlo al proyecto de Jack. Por lo tanto el Gerente contrata a
una nueva persona, Alfreda. Atraída de un competidor, tiene un
doctorado en Ing. Electrónica y 20 años de experiencia. Pudo
obtener un sueldo más alto (más que el que Jack inclusive) y es
asignada de tiempo completo al proyecto de Jack.

Jack está muy interesado en el trabajo de Alfreda, y pide a diario

reuniones con ella para discutir sus enfoques del diseño. Sin
embargo la mayor parte de estas reuniones se convierten en
monólogos de Jack sugiriendo como debe hacerse el diseño y
prestando poca atención a lo que ella dice.

Por último, Alfreda le pregunta a Jack por qué está dedicando más
tiempo a revisar su trabajo que el de otros Ing. del Proyecto. Él le
responde “No tengo que revisar el trabajo de ellos, ya sé cómo lo
hacen. He trabajado con ellos en otros proyectos. Usted es nueva
en el grupo y quiero estar seguro de que comprenda como
hacemos que las cosas, quizás sea diferente a como lo hacía en su
trabajo anterior.”

22
 En otra ocasión, Alfreda le muestra a Jack lo que ella piensa que es
su enfoque de diseño creativo que dará como resultado un
sistema de costos más bajo. Jack le dice “Yo ni siquiera tengo un
doctorado y puedo ver que eso no resultará. No sea tan esotérica
y apéguese a la ingeniería clásica básica.

Durante un viaje con Denis, otro ingeniero del proyecto, que ha

conocido a Jack desde hace 6 años, Alfreda le dice que se siente
frustrada por la forma en que Jack la trata. Ella le dice a Denis

“Jack está actuando más como si él fuera el Jefe de Ing. Electrónica

y no como el Gerente de Proyecto. Además yo he estudiado más
sobre diseños electrónicos de lo que Jack nunca supo en su vida. El
realmente no está actualizado en metodología de diseños
electrónicos. También le dice a Denis que está pensando discutir
este asunto con el Gerente de Ing. Electrónica y que nunca hubiera
aceptado el trabajo en Codeword si hubiera sabido que iba a ser
así.

Reflexione sobre el caso:

¿Piensas tú que Jack está listo para desempeñarse como Gerente de

Proyectos? ¿Por qué si o Porque no?
¿Cómo pudo haberse preparado Jack para su nuevo papel?
¿Cuál es el principal problema de la forma en que Jack interactúa con
Alfreda?
¿Porque piensas tú que Alfreda no ha tenido una discusión franca con Jack
sobre la forma en la cual la trata?
Si Alfreda aborda directamente a Jack ¿Cómo piensas que responderá Jack?
¿Cómo piensas tú que responderá a esta situación el Gerente de Ing.
Electrónica? ¿Por qué debe hacerlo?
¿Qué puede hacer para poner un remedio a esta situación?
¿Qué se pudo haber hecho para evitar la situación?

23
6. Gestión de Las
Comunicaciones Del Proyecto
La mayoría de los estudios realizados destacan que las comunicaciones son
el aspecto número uno que un Project Manager tiene que abordar en un
proyecto. Es necesario entender la importancia de este tema, ya que entre
el 75% y el 90% del tiempo de un Project Manager se invierte en
comunicaciones.

Un Project Manager principiante podría hacer podo en lo referente a las

comunicaciones, remitiéndose solamente a emitir reporte de estado.
Directores de Proyecto más experimentados o con más capacidad,
dedicarán tiempo a crear un plan de comunicaciones y emitirán algo más
que solo reportes de estado. Los grandes profesionales de la Gestión de
Proyectos, además de las dos acciones previas definidas, le pedirán a los
stakeholders que definan lo que ellos necesitan que les sea comunicado,
identificarán que comunicaciones necesitan de los stakeholders, y
periódicamente revisarán las comunicaciones con el equipo de trabajo.

Cualquier persona implicada en el proyecto debe estar preparada para

enviar y recibir comunicaciones en el lenguaje del proyecto y debe
comprender que estas comunicaciones afectan al proyecto.

6.1 Planificación de las

comunicaciones
La planificación de las comunicaciones implica determinar las necesidades
de información y comunicaciones de los stakeholders del proyecto. Esto
incluye determinar lo que necesita ser comunicado, a quien, cuando, con
que método y cuan frecuentemente.

Se debe entender la importancia que tienen para esto las variables de

entorno de la organización, tales como la cultura organizacional y los
estándares de trabajo. Se deben entender también los procesos y
procedimientos para conducir el trabajo y las comunicaciones, los registros
históricos de procesos previos, como así también las lecciones aprendidas y
cualquier otra información almacenada.

En una etapa temprana del proceso de gestión de proyectos, todos los

stakeholders deberán haber sido identificados así como también sus

24
requerimientos y expectativas. Los requerimientos no solo deberían
relacionarse con lo que el producto del proyecto debe hacer, sino que
también deberían incluir las necesidades y tipos de comunicación.

Con quien nos comunicamos

Es importante tomar conciencia respecto de que la comunicación no solo
unidireccional. Durante cada momento de la planificación del proyecto, el
equipo de proyecto habrá tenido alguna oportunidad de interactuar con
otros stakeholders. ¿Alguno de los stakeholders ha identificado algún
grupo de riesgos potenciales para el proyecto? ¿Por qué entonces no
reunirse con ellos en forma periódica, a través del proyecto, para ver si se
han identificado nuevos riesgos? ¿Hay algún miembro del equipo inseguro
de llegar a cumplir con las tareas que le fueron asignadas en tiempo y en
forma? ¿Porque no establecer alguna forma de capacitación o determinar
alguna lectura que pueda ayudar al miembro del equipo?

Figura 3.2: Objetivos de comunicación del proyecto

Modelo de comunicaciones
Como sistema, la comunicación es divergente, teniendo la capacidad para
expandirse centrífugamente, en función de la autonomía de sus elementos.
El gestor de proyectos, a lo máximo que puede tratar de llegar, es a
coordinar aquellas “informaciones” que, viniendo de cualquiera de los
integrantes (elementos o subsistemas), sean relevantes para el proyecto y
sea necesario poner en común, con el papel de tratar de regular todas
aquellas emisiones que sea posible regular, así como el de transformarlas
en “comunicación”, para obtener la máxima eficiencia de ellas.

25
Figura 3.3: Universo de la comunicación y la documentación
(Fuente: Gestión Integrada de Proyectos, Marcos Serer Figueroa, 2001)

La complejidad que representa el que cada uno de los actores pueda actuar
haciendo uso de su facultad de “informar” y no tanto de “comunicar”, así
como la dificultad del gestor de proyectos de hacer posible el que todos los
actores dispongan de la información precisa para hacer bien su trabajo,
puede verse reflejada en la figura 3.3.
Un modelo básico de comunicación, que aparece en la Figura 5.3,
demuestra cómo se envían y reciben las ideas o la información entre dos
partes, definidas como emisor y receptor. Los componentes clave del
modelo incluyen:
 Codificar. Traducir los pensamientos o las ideas a un lenguaje que
otras personas puedan comprender.
 Mensaje. La salida de la codificación.
 Medio. El método usado para transmitir el mensaje.
 Ruido. Todo lo que interfiere en la transmisión y comprensión del
mensaje (por ejemplo, la distancia).
 Decodificar. Traducir el mensaje nuevamente a pensamientos o ideas
con sentido.

Cada mensaje es codificado por el emisor y decodificado por el receptor.

Esta decodificación por parte del receptor estará basada en la educación,

26
experiencia, lenguaje y cultura del mismo. El acuse de recibo significa que
el receptor señala la recepción del mensaje, pero no necesariamente que
esté de acuerdo con el mismo. Otra acción es la respuesta a un mensaje, lo
que significa que el receptor decodifica, comprende y responde al mensaje
(PMBoK, PMI, 3º Edición).

Figura 3.4: Comunicación – Modelo Básico

(Fuente: PMBoK 3º Edición, PMI, 2004)

Independiente de las posibilidades múltiples de información abiertas, el

gestor del proyecto debe proceder a establecer una serie de actividades
que, en general, contemplen:

Informes para el cliente o sponsor en los que:

 Explique la situación
 Prevenga de sucesos negativos cuando es necesario
 Haga análisis previsionales de los objetivos
 Deje constancia de hechos de interés
 Sugiera caminos a seguir
 El procedimiento de trabajo adoptado probablemente sugerirá la
celebración de reuniones, de las cuales levantará acta que remitirá a
cada uno de los asistentes. Si de ella derivara alguna información
para otro actor que no hubiera asistido, preparará un informe, carta,
etc. con la información, que hará llegar al interesado.
 A partir de la información recibida de alguno de los actores, que sea
útil para los otros, redactará un documento que distribuirá a quien
corresponda.
Y, fundamentalmente respecto al equipo de proyecto, se preocupará de
que éste disponga de la información necesaria, que pueda provenir del
resto de los stakeholders.
Como el resto de elementos de un sistema, la comunicación depende
mucho de la filosofía que debe imperar en el proyecto y de la estrategia
establecida.

27
La estrategia, por ejemplo puede condicionar el tipo de comunicación que
debe implementarse con los actores externos al proceso (administraciones
públicas, prensa, etc.).
En cualquier caso, la base de la comunicación siempre es la comunicación
verbal, que permite mantener uno de los lineamientos genéricos de la
Gestión de Proyectos como es el de la “motivación”. Pero, evidentemente
la comunicación escrita es la que formaliza la gestión, dejando constancia
de lo que conviene y sirviendo de recordatorio de las actuaciones
comprometidas por cada uno de los actores.
Se puede enfocar también la comunicación en función de la dirección que
lleva. En ese sentido se puede hablar de comunicación “externa”, que va
dirigida a los actores más externos al proceso e “interna”, dirigida a los
stakeholders directamente involucrados en el proyecto.
En todos los casos, el principio básico es el de la idea de la
bidireccionalidad aludida anteriormente, que se refiere a la práctica que
lleva a que cada vez que se informa se asegure que el interlocutor ha
recibido la información y que es consciente de ello.

Figura 3.5: Tipos de comunicación

(Fuente: Gestión Integrada de Proyectos, Marcos Serer Figueroa, 2001)

28
En cuanto a la comunicación entre los miembros del equipo, se hace
fundamentalmente a través de reuniones de coordinación que suelen ser
realizadas formalmente antes de las reuniones de seguimiento con el
cliente y/o sponsor. Son reuniones en las que se intenta unificar criterios
de actuación para con el resto de los interesados y revisar el estado de los
objetivos, así como los medios que deberían utilizar el propio equipo o el
resto de los stakeholders para corregir aquellos aspectos que deban ser
corregidos. En todo caso las conclusiones de esas reuniones, así como las
tareas a realizar deben estar reflejadas por escrito, a través de
instrucciones y actas que puedan quedar registradas dentro del correo
electrónico interno.

La comunicación se realizará en muchas dimensiones tales como:

 Escrita u Oral
 Interna o Externa
 Formal o Informal
 Vertical u Horizontal

Comunicación efectiva
Lograr una comunicación efectiva implica que el emisor debe codificar el
mensaje cuidadosamente, determinar el método de comunicación a ser
utilizado para enviar el mensaje y confirmar que el mensaje es entendido.
Debe comprenderse claramente que el corazón de la comunicación no son
las palabras sino la comprensión y que se trata de una acción
multidireccional, no solo ser entendido, sino también entender.

La mitad del trabajo de hacer que una comunicación sea efectiva es

“escuchar”

Escucha efectiva
El receptor debe decodificar el mensaje cuidadosamente y verificar que ha
entendido el mensaje. Esto incluye observar al que habla, para descubrir
gestos físicos y expresiones faciales, pensando en lo que se quiere decir
antes de responder, ya sea para preguntar, pedir repetición o
retroalimentación.

Barreras comunes para escuchar con efectividad

Mucha parte de la verdadera y completa información que nos debiera
interesar puede perderse por causa de algunas barreras creadas por
nosotros mismos a la hora de escuchar:

29
  Fingir escuchar
 Distracciones
 Prejuicio y mentalidad estrecha (escucha selectiva)
 Impaciencia
 Saltar a conclusiones prematuramente

Debemos prestar mucha atención a estas barreras, puesto los mensajes

podrían llegarnos debilitados o distorsionados a causa de ellas.

Plantearemos a continuación algunas sugerencias para mejorar las

habilidades de escuchar:

 Centrar la atención en la persona que habla

 Participar en una escucha activa: El receptor confirma lo que ha
entendido, acordando o pidiendo ampliación del tema.
 Hacer preguntas
 No interrumpir
 Buscar Retroalimentación: Frases del tipo “No termino de entender,
¿podría aclararme lo que acaba de decir? Ayudan a reafirmar el
entendimiento del mensaje.

Finalmente, no debemos olvidar que:

“El escuchar debe ser un proceso ACTIVO, que aumenta la comprensión y

reduce el conflicto“

Canales de Comunicación
Cada vez que se agrega una persona al equipo, las comunicaciones crecen
exponencialmente.
Los canales de comunicación en un equipo pueden calcularse con la
siguiente formula: [N (N-1)] / 2 donde N es igual al número de personas.

Si lo vemos en un ejemplo: si se tiene 4 personas en un equipo, ¿Cuántos

canales de comunicación hay?

Utilizando la fórmula se tendrá [4(4-1)]/2 = 6

Figura 3.6: Cantidad de canales de comunicación para un equipo de 4 personas

30
Tipos de comunicación
La comunicación, en términos generales, se puede clasificar, desde el
punto de vista de la forma: oral y escrita, y desde el punto de vista de los
actores intervinientes: externa e interna.

Comunicación verbal
Se lleva a cabo de manera formal en reuniones, que pueden ser de
seguimiento o reuniones técnicas o en encuentros o contactos informales
de diversa índole.

A lo largo del ciclo del proyecto se producen innumerables reuniones de

tipo informal, que actúan de preparación para las formales, de explicación
de decisiones, y en general estos contactos son catalizadores – en algún
caso – y provocadores en otros, de temas y situaciones que se inician o se
definen.

Uno de los problemas que tiene la comunicación verbal – sobre todo la

informal – es el tiempo que consume y por ende la no disponibilidad del
mismo para otros asuntos que deben resolverse.

A pesar de ello, este tipo de comunicación consigue que se puedan sacar

conclusiones y obtener datos que es muy difícil se consigan por la vía de la
comunicación escrita.

Un gestor de proyectos, puede, a través de una comunicación verbal

estructurada llegar a saber realmente:

 Las causas de los conflictos en los equipos

 Los sentimientos de los miembros del proyecto, que en algún
momento pueden atentar contra la integridad del equipo.
 Las verdaderas causas de por qué un proveedor se está retrasando
 El grado de conformidad de un cliente con la actuado en la gestión
del proyecto
 Qué objetivos (realmente) son los que interesan
 Los motivos políticos de algunas decisiones
 Otros

La comunicación escrita es de suma importancia y por ello debe ser

concienzudamente planificada, desarrollándose constantemente; todo esto
sin dejar de ver que es fundamental poner especial énfasis en todo lo que
significa el contacto personal del equipo de gestión y preferentemente del
propio gestor con el resto de los interesados, fundamentalmente con el
sponsor y el cliente si no fueran la misma persona. Recordemos, el
contacto que genera esa “información biunívoca” sin duda va a ser la que

31
marcará las vías de entendimiento y confianza entre las partes.
Posteriormente, serán los hechos los que darán crédito a todo lo hablado;
pero una buena comunicación con entendimiento personal allana los
problemas, replantea los errores y agranda los aciertos, dando a los
resultados la justa premiación en función, también, de los esfuerzos
realizados.

Es evidente que en las relaciones humanas, la empatía fomenta el

entendimiento, haciendo que las personas se comuniquen mejor, dejando
de lado otras consideraciones más visibles: conocimientos, trabajo y
racionalidad en general.

Esta última consideración podría inhabilitar a algunos gestores de

proyecto para que tengan una buena comunicación verbal con algunos de
los interesados. En la elección de un buen director de Proyecto las
habilidades de comunicación serán decisivas.

En todo caso, siempre existe la posibilidad de encarar un aprendizaje para

desarrollar la habilidad de “comunicar” y escuchar de manera efectiva. El
“deseo” de estar motivado y de motivar es un valor importante, susceptible
de generar confianza, y por ende un buen argumento para lograr una
buena comunicación.

Reuniones de seguimiento y coordinación: son las que se realizan a lo largo

del ciclo de vida del proyecto de manera continuada y estructurada,
realizando el seguimiento de los trabajos que se van desarrollando. Los
temas que se suelen tratar son, entre otros, los siguientes:

 Lectura y aprobación, si cabe, del acta de la reunión anterior. Lectura

del orden del día y solicitud de tratamiento de otros puntos.
 Comunicación del gestor o sponsor/cliente a todos los interesados
involucrados directamente.
 Puntos críticos a debatir.
 Repaso del estado de las tareas que, de acuerdo con la planificación,
se están desarrollando. Exposición de detalles, si cabe, por parte del
especialista. Problemas que hayan surgido y que deban presentarse a
la mesa para su conocimiento o resolución.
 Estado de la planificación. Comentarios sobre medidas a adoptar en
caso de desviaciones.
 Estado del plan de costos. Comentarios sobre medidas a adoptar en
caso de desviaciones.
 Estado del cumplimiento de otros objetivos: diseño, calidad, riesgos,
licencias, etc.
 Listado de temas pendientes por resolver y plan de actuación con
responsables para cada uno de los asuntos.

32
Uno de los objetivos de las reuniones de coordinación es el de servir de
impulso a acciones que posteriormente, de manera formal o informal, se
desarrollarán a lo largo del periodo que media hasta la próxima reunión. La
cadencia de las reuniones depende del tipo de proyecto. Para proyectos de
investigación pueden establecerse mensualmente o quizás más a menudo.
Para proyectos de consultoría, depende también del tiempo total, pero
pueden hacerse cada dos o tres semanas. Para proyectos de ingeniería, es
normal que se realicen cada una o dos semanas.

Las reuniones técnicas no suelen revestir la periodicidad tan inflexible

como las de coordinación, sin embargo no por ello son menos importantes.
De hecho, en muchos proyectos, son las que auténticamente resuelven los
problemas, de modo que hay que fomentarlas.

Tanto estas reuniones como las de coordinación es conveniente que

acaben en un documento escrito que resuma el contenido de lo hablado.
Las comunicaciones exclusivamente verbales pueden desarrollarse tanto a
nivel interno (entre interesados próximos al proyecto), como a nivel
externo, con otros que, aun que tengan singular importancia, no están
directamente involucrados – con dedicación expresa – en el proyecto.

El documento de cierre de la reunión, normalmente conocido como

Minuta, deberá contener al menos: los participantes y los ausentes (puesto
que si fueron convocados deben enterarse del resultado), los temas
tratados, las resoluciones tomadas, las acciones a seguir y el responsable
de llevarlas a cabo.

Comunicación escrita
Es por naturaleza la más estructurada y clara pues en ella debe quedar
reflejado todo el ciclo con sus pasos, propuestas y decisiones. Son el diario
y el recordatorio para todos los actores y, por su propia condición, resultan
insustituibles en el seguimiento técnico, económico o legal del proceso.

La visión sistémica en la resolución de los problemas, y en general al

afrontar un conflicto, también se lleva a cabo en el sistema de
comunicación; es por ello que se utilizan diferentes vías que, de por sí,
también reflejan distintos sistemas con sus reglas de actuación y formas
concretas. Así es como aparecen los sistemas de informes, actas, cartas,
faxes, correo electrónico, libros de órdenes, libros de incidencias y notas de
órdenes en los momentos de la realización del proyecto.

Como es lógico, no sólo el gestor del proyecto genera información escrita;

también lo hacen el resto de interesados directos del proyecto.

33
Plan de Gestión de las Comunicaciones
Las comunicaciones, al igual que otros aspectos importantes deben ser
planificadas, el resultado palpable de ese proceso de planificación es el
Plan de Gestión de las Comunicaciones, que es valioso y muy necesario,
aun en los proyectos cortos. Este Plan documenta como se gestionarán y
controlarán las comunicaciones, ya que generalmente la información a ser
distribuida suele ser muy extensa.

El plan de gestión de las comunicaciones proporciona:

 Requisitos de comunicaciones de los interesados
 Información que debe ser comunicada, incluidos formato, contenido
y nivel de detalle
 Persona responsable de comunicar la información
 Persona o grupos que recibirán la información
 Métodos o tecnologías usadas para transmitir la información, como
memorandos, correo electrónico y / o comunicados de prensa
 Frecuencia de la comunicación, por ejemplo, semanal
 Proceso de escalamiento, identificando los plazos y la cadena de
mando (nombres) para el escalamiento de polémicas que no puedan
resolverse a un nivel inferior del personal
 Método para actualizar y refinar el plan de gestión de las
comunicaciones a medida que el proyecto avanza y se desarrolla
 Glosario de terminología común.

El plan de gestión de las comunicaciones también puede incluir pautas para

reuniones sobre el estado del proyecto, reuniones del equipo del proyecto,
reuniones electrónicas y correo electrónico. El plan de gestión de las
comunicaciones puede ser formal o informal, muy detallado o
ampliamente esbozado, dependiendo de las necesidades del proyecto. El
plan de gestión de las comunicaciones está incluido en el plan de gestión
del proyecto general, o es un plan subsidiario de éste. Entre los atributos
de un plan de gestión de las comunicaciones se pueden incluir:

 Elemento de comunicaciones. La información que será distribuida a

los interesados.
 Finalidad. Motivo de la distribución de dicha información.
 Emisor.
 Destinatario/s.
 Frecuencia. Cada cuánto tiempo se distribuirá la información.
 Fechas de inicio / finalización. Plazo para la distribución de la
información.
 Formato / medio. El diseño de la información y el método de
transmisión.
 Responsabilidad. El miembro del equipo encargado de la distribución
de la información.

34
La Planificación de las Comunicaciones a menudo implica la creación de
productos entregables adicionales que, a su vez, requieren tiempo y
esfuerzo adicionales. Por consiguiente, la estructura de desglose del
trabajo del proyecto, el cronograma del proyecto y el presupuesto del
proyecto deberán actualizarse según corresponda.

6.2 Distribución de la información

Ya sabemos que la comunicación es probablemente una de las actividades
más importantes que debe llevar adelante el Director de proyecto, para
ello será necesario distribuir información en sus diferentes formas:

Informes
Son el instrumento más común y estandarizado del que se sirve un gestor
de proyectos para mantener una comunicación escrita con todos los
interesados y especialmente con el cliente, o sponsor. De hecho, los
informes se suelen remitir exclusivamente al sponsor/cliente, pero según el
escrito de que se trate y la filosofía definida al principio para la relación
entre las partes, se editan copias para otros actores que interesa que
conozcan el contenido.

Las carátulas de los informes es conveniente que dispongan de una

información mínima que permita una rápida identificación y su posterior
archivo. Sobre los informes hechos por otros stakeholders, se propondrá la
inclusión del mismo tipo de identificación para favorecer un archivo
conjunto tanto por parte del cliente como por interés propio. Aunque para
el archivo propio, y en cualquier caso, si no viene con la identificación
prevista por imposibilidad de obligar a su cumplimiento (administraciones
públicas por ejemplo) se deberá incluir a mano cuando llegue a disposición
de la oficina de Gestión de Proyectos.

Los tipos más interesantes para conocer son: Informes generales y

periódicos de seguimiento del proyecto, que son informes que según el
tipo de proyecto y su duración, tienen usualmente un carácter quincenal,
mensual o bimensual.

El informe suele apoyarse en documentación gráfica (diagramas, croquis,

esquemas, etc.) que ayudan a una comprensión rápida de la situación.

El receptor del informe suele ser el interlocutor ordinario por parte del
cliente y los informes suelen ser más frecuentes durante la puesta en
marcha del sistema, ya que en las fases de requerimientos, diseño,
desarrollo y mientras se hace el proyecto, en la fase de implementación,

35
suele ser más frecuente informar y comunicar a través de las actas de
reuniones o los informes específicos.

Dos aspectos que convendrían resaltar de un informe periódico de

seguimiento son los relativos a los puntos críticos que hay que acometer y
que con frecuencia involucran al propio cliente; y otro asunto interesante
es el apartado que intenta hacer una extrapolación de lo que ocurrirá de
seguir la misma tendencia en el trabajo que se esté realizando hasta esa
fecha. Como medida práctica, además se hace una extrapolación para todo
el proyecto, se aconseja concretar lo que ocurrirá en los próximos 30 días
(cuando no, menos) a la edición del informe.

Otro tipo de informe son los informes ejecutivos, que conforman

documentos de un número escaso de hojas, dirigidos a la presidencia o
dirección general del cliente, o al sponsor, que pretende resumir en no
demasiados párrafos y de forma bastante gráfica y sintética, el estado de la
cuestión, abordando aspectos claves del proyecto.

Lo ordinario es que los aspectos clave de este tipo de informes se refieran

al presupuesto y al plazo, pero no están descartados otros objetivos que,
en todo caso, se acuerdan con el cliente y más concretamente con el
receptor final.

Lo trascendente es, en definitiva, que el gestor del proyecto sepa qué tipo
de informes resultan de utilidad, dejando aquellos aspectos que complican
la lectura o no añaden nada efectivo al análisis para la toma decisiones o
para el conocimiento de lo que existe.

Estos informes se suelen hacer a lo largo de todo el ciclo de vida del

proyecto. También a lo largo de todo el ciclo, se realizan informes
específicos sobre temas diversos que corresponden a diferentes aspectos
del proyecto que interesa que conozca el cliente, o algún otro de los
interesados. Así por ejemplo se suelen hacer informes sobre la marcha
concreta de la construcción de algún elemento específico durante el
desarrollo, sobre la evolución del costo de una parte significativa del
proyecto, sobre la revisión de las hipótesis de diseño de algún elemento,
etc.

Se hacen informes que hablan del costo, de la seguridad, de la calidad, del

alcance, del plazo, etc. Entre ellos, unos que revisten singular importancia
son los que definen bases de inicio o hipótesis de partida del trabajo de
cada miembro del equipo de proyecto que responden a deseos expresos
del sponsor/cliente o a objetivos a cumplir. Estos informes se llevan por el
gestor a las reuniones de inicio y se solicita oficialmente al cliente la
validación y al interesado que sea, su aceptación expresa. En esa reunión
se levanta el acta correspondiente para que se formalice la situación.

36
Actas de reunión
Se pueden considerar como un tipo de informe más, lo que facilita un
archivo conjunto de los documentos.

La preparación de la reunión se hace a través del orden el día que el gestor

debe emitir unos días antes del previsto para la reunión, y enviarlo a todos
los interesados. Este documento preparatorio incluirá el día, la hora de
inicio, los asuntos a tratar con el tiempo asignado para cada uno de ellos,
así como los asistentes previstos.

Las actas las redacta el gestor y deben reflejar un resumen de lo hablado

con indicación de:

 Aprobación de la lectura del acta de la reunión anterior, o en su caso

la introducción de las modificaciones a que hubiera lugar. De su
lectura pueden inducirse reflexiones que, o bien se resuelven porque
pertenecen a lo tratado el día anterior o bien se dejan para ser
tratados según el orden del día previsto para ese momento.
 Si hay temas urgentes, lo lógico es que sean los primeros en ser
tratados.
 Si hay un asunto específicamente mencionado por uno de los
actores, se indicará cuál es la fuente.
 Para cada asunto es recomendable, indicar el objeto de su
tratamiento: para información o para que algún otro actor acometa
alguna acción (en ese caso, se citará al actor).
 Se suele dejar constancia de los asuntos pendientes, si los hay, así
como la fecha de su posible tratamiento si es posible.

De las actas, una vez escritas, se ha de enviar una copia a cada uno de los
integrantes de la reunión autorizados para ello y al cliente en cualquier
situación.

Cartas, faxes y correo electrónico

Muchas de las comunicaciones que hasta hace pocos años eran verbales,
han pasado, en los últimos tiempos, a ser escritas a la luz de la facilidad
que los medios han provocado para que así sea.

Las ventajas que lo anterior comporta son dos: por un lado, son mucho
más explícitas y tratan el tema que sea sin ambivalencias y, por otro, dejan
constancia de los asuntos. De esas ventajas se liberan otras como son la
economía de los medios y recursos, y el aprovechamiento de los mismos en
otros temas.

Cuando se quiere sumar rapidez a formalidad y precisión, se suele enviar

un fax y a continuación se envía la misma documentación por carta. La

37
carta, en todo caso, sigue siendo el documento formal que se utiliza
cuando se quiere distinguir el contenido de forma especial respecto a
cómo se podría suponer en otros tipos de comunicación. De hecho lo que
termina de conferirle un grado de seriedad y validez, jurídicamente
hablando, es el poder ser enviada bajo el soporte de un escribano público.
Aunque ya se puede entender que no es una vía demasiado amistosa de
comunicarse, pero hay ocasiones en que no existe mejor procedimiento.

El correo electrónico sigue teniendo un auge extraordinario y se le augura

un crecimiento mucho mayor, ya que permite un archivo y redistribución
mucho más rápido y accesible que las cartas y faxes.

En todos los casos, en el envío de estos tipos de documentos siempre se

habría de indicar:

 Una referencia del asunto tratado: nº de proyecto, clasificación según

la WBS (EDT) o clasificación por centro de costos y el asunto en
cuestión.
 Las copias que de él se hacen y a quién se remiten.
 Persona/s que editan el documento.

Y retomamos en este punto el significado del término de gestión de la

“comunicación”, para hacer énfasis en lo que mencionamos al comenzar
este apartado en el sentido de que, cuando se utilizan esta vías para
generar la información precisa, el sistema aún está incompleto, quedando
pendiente la bidireccionalidad del intercambio. Esto es, asegurarse que el
receptor de la información la ha recibido, y que se está consiguiendo el
efecto esperado y no otro.

A este respecto conviene matizar que no siempre el escrito llega a ser lo

suficientemente afortunado en su redacción como para acertar en lo que
se quiere transmitir y con el tono requerido; por eso es conveniente
apoyarlos siempre con una comunicación verbal, o una confirmación,
también por escrito, de que se ha recibido, para testar si se está de
acuerdo o no con lo redactado; para en definitiva, estar seguro de que se
entiende lo que el redactor quiere que se entienda.

Estos aspectos, un gestor debe cuidarlos mucho, dada su condición de

“coordinador” de voluntades y esfuerzos, en pro de unos objetivos que
tienen que ser comunes para todos. Una deficiente interpretación de algún
escrito puede generar suspicacias que sin duda no ayudarán lo más mínimo
a generar la confianza necesaria en la Gestión del Proyecto que permita
hacer esa labor de “convergencia” de todos los stakeholders.

38
Libros de órdenes e incidencias
Son instrumentos utilizados en los proyectos de edificación, tanto en el
área industrial como arquitectónica, como así también en los proyectos de
desarrollo de sistemas.

El libro de órdenes, como su nombre indica, recoge los mandatos de la

dirección facultativa que son de obligado cumplimiento para el proveedor.
Este instrumento resulta extremadamente útil cuando se presentan
situaciones de conflictividad de cara a posibles repercusiones jurídicas, o
simplemente para dar más fuerza a las peticiones o indicaciones de la
dirección facultativa. El gestor del proyecto debe recomendar la utilización
de este instrumento desde el primer momento.

Figura 3.7: La comunicación escrita y su frontera con la verdad

(Fuente: Gestión Integrada de Proyectos, Marcos Serer Figueroa, 2001)

39
Notas o instrucciones técnicas de construcción
Durante la construcción del producto objeto del proyecto, corresponde al
director facultativo la emisión de las órdenes a los diferentes proveedores,
que supongan actuaciones sobre el desarrollo del producto final, ya que es
una responsabilidad no transferible.

Pero sus órdenes deben ser aprobadas por el gestor del proyecto,
(asumiendo la estructura de organización de proyectos más usual que es la
matricial, pudiendo ser función exclusiva del gestor del proyecto el manejo
de proveedores en una organización proyectizada), aun cuando modifiquen
los objetivos inicialmente aprobados y que han servido de base para la
misión del director facultativo. Así por ejemplo no puede dar órdenes sin
aprobar que modifiquen el alcance, el precio, la calidad, la seguridad, etc.
En esas y otros ocasiones el gestor del proyecto debe autorizar, como
representante de la propiedad, cualquier modificación.

La oficina de gestión del proyecto también emite instrucciones técnicas de

construcción que afectan fundamentalmente a órdenes de secuencias de
construcción que afectan al plazo, así como otras que repercuten en el
costo, así como las relativas a cualquier objetivo cuyo control esté
reservado al gestor o compartido con él.

En todos esos aspectos, suele ser normal que muchas órdenes del
ingeniero en jefe se emitan por escrito con “notas internas” que están
incluidas dentro de un procedimiento general de actuación. Pues bien, de
acuerdo con ese mismo procedimiento, que puede estar incluido dentro
del manual de procedimientos, los desarrolladores internos o externos,
tienen que comunicar alguna anomalía si consideran que ellas pueden dar
lugar a una reclamación económica por su parte, a un aumento de plazo,
etc. En todos estos casos se debe solicitar el consentimiento de la oficina
de proyectos.

En todo caso, la proximidad a los hechos por parte del gestor del proyecto
y su equipo, hace fácil la situación y hace, también poco viable que, en un
ambiente de relación razonable, se produzcan disfunciones en las
actuaciones o problemas de competencia. Sólo cuando no se han sabido
plantear desde un principio los diferentes roles de forma coherente – y
también contractualmente – o cuando el gestor no ha llegado a ganarse la
confianza de los diferentes involucrados, es cuando aparecen los
problemas de competencias y se genera el caldo de cultivo propio de un
final no deseado y en contra, al menos, de los intereses del cliente.

40
Los documentos de proyecto
Nos referimos aquí a los documentos generados por los diferentes
involucrados en el proyecto que, de forma escrita y gráfica, representan las
formas y contenidos que se deben transformar en algo material. Todos
ellos deben ser controlados y gestionados por la oficina de gestión del
proyecto, que, sin pretender asumir o soslayar la responsabilidad que
tienen sus autores, ha de tratar de asegurarse, en el mayor nivel de
confianza posible, que:
 Son suficientes
 Son correctos, técnicamente hablando
 Responden a los intereses del cliente
 Respetan los condicionantes insoslayables (medio ambiente,
seguridad, urbanismo, aspectos éticos de la gestión de proyectos)
 Cada involucrado conoce aquellos documentos que, generados por
otros, él necesita para el desarrollo de sus propias funciones, y
además en su última versión.

Registro de la documentación
Para el archivo de documentación, proponemos establecer el sistema
utilizado como modelo dentro de los programas que aseguran la calidad
tipo ISO o similar.

Uno de los sistemas que ahora recomendamos es el que confiere al

director del encargo – el gestor – la responsabilidad del archivo del
proyecto en cuestión y por lo tanto de su ordenación y de la normativa a
aplicar en función de la misión del proyecto (léase formas de actuar).
Normativa que, como es lógico, debe seguir también las directrices del
propio plan de calidad específico del trabajo.

El procedimiento que se podría establecer en líneas generales sería el

siguiente:
Documentación sobre lecciones aprendidas. La documentación incluye las
causas de las polémicas, el razonamiento subyacente a la acción correctiva
elegida y otros tipos de lecciones aprendidas sobre Distribución de la
Información. Las lecciones aprendidas se documentan a fin de que pasen a
formar parte de la base de datos histórica tanto de este proyecto como de
la organización ejecutante.

6.3 Reporte de desempeño / rendimiento

Los informes de rendimiento o Reportes de desempeño son realmente un
proceso de comunicación, ya que reúne datos e información de
rendimiento enviándolos a los interesados. Es necesario que dicho reportes
de rendimiento cumplan con los requerimientos establecidos en el proceso

41
de definición del proyecto en lo referente al contenido, nivel de detalle y
forma.

Los reportes de rendimiento pueden incluir:

 Reportes de Estado: Descripción del estado actual del proyecto en
función a lo estimado en las líneas base de Alance, Tiempo, Costo y
Calidad.
 Reportes de Progreso: Descripción de lo logrado hasta el momento.
 Reportes de Tendencias: Análisis del rendimiento del proyecto con el
paso del tiempo para determinar si dicho rendimiento está
decayendo o mejorando.
 Reportes de Pronóstico: Reporte de predicción del estado y
rendimiento del proyecto en el futuro.
 Reportes de Variación: Comparación del estado actual con las líneas
base.
 Valor Ganado: Integración del alcance, tiempo y costo para evaluar el
rendimiento del proyecto.
 Lecciones Aprendidas: Conclusiones finales sobre situaciones del
proyecto que han permitido el aprendizaje que servirá de base para
futuros proyectos.

6.4 Cierre administrativo

Un trabajo adicional relacionado con los informes y las comunicaciones del
proyecto implica verificar y documentar los resultados del proyecto para
formalizar la aceptación del producto del proyecto por el sponsor.

Se busca:
 Reunir todos los registros del proyecto y crear un reflejo de
especificaciones finales con los indicadores de éxito y eficiencia del
proyecto.
 Cerrar fase por fase, sin demorar hasta la finalización del proyecto.
 Llevar los archivos del proyecto creando al menos un juego completo
de registros del proyecto ordenado.
 Reunir los contratos importantes y los registros contables
 Documentar apropiadamente la aceptación formal
 Reflexionar y documentar las lecciones aprendidas

6.5 Caso para estudio

Sobre el caso planteado en el punto 5.5 sobre Codeword identifique
cuantos canales de comunicación intervienen y reflexione sobre cuáles son
los principales problemas de comunicación.

42
Módulo 4
Aspectos
Complementarios
de la Gestion de
Proyectos
7. Gestion de riesgos
del proyecto
En todo proyecto hay incertidumbre, por ende, todo proyecto implica
riesgos.

La experiencia muestra una pobre performance en lograr cumplir los

objetivos de alcance, calidad, tiempo y costos previstos en los Proyectos.
Algunas de las causas de ello pueden ser:

• Eventos no previstos
• Falta de anticipación
• Eventos previstos con consecuencias no medidas con anticipación

En cualquiera de los casos estamos hablando de Riesgos.

Un Riego es un evento discreto que tiene posibilidad (no certeza) de ocurrir

y tiene algún impacto sobre algún objetivo del proyecto.

Si bien estamos acostumbrados a dar a los riesgos una connotación

negativa, es importante saber que los riesgos pueden tener también
impactos positivos (estos casos son percibidos como oportunidad).

Otro aspecto importante a resaltar es la diferencia entre Riesgo y

Contingencia.

• El riesgo es un problema potencial (no ha ocurrido aún),

• La contingencia es un problema real (ya ha ocurrido).

El Gerenciamiento de Riesgos es el arte y ciencia de identificar, evaluar, y

responder a los riesgos de un proyecto a lo largo de la vida de mismo.

Comprender que deberemos gestionar en un ambiente de riesgo es

esencial para el progreso del proyecto y, a menudo los fracasos son una
parte fundamental del aprendizaje.

Aunque algunos riesgos no se puedan evitar, reconocerlos y controlarlos

debe ser una actitud permanente que desafía nuestra creatividad.

1
7.1 Planificación de la gestión de
riesgos.
En muchas ocasiones la gestión de riesgos es percibida como una tarea
burocrática que se hace al inicio del proyecto para generar un documento
que conforme a algunos intereses.

Poder enfrentar y administrar los riesgos requiere que su administración

sea considerada como parte de un proceso dinámico y competitivo, en
lugar de sólo una actividad adicional y estática de la administración de un
proyecto.

Es normal que los riesgos sean conocidos por los miembros del equipo del
proyecto, pero la mayor parte de los problemas comienzan porque no son
comunicados apropiadamente y en el momento oportuno.

En muchas ocasiones nos cuesta comunicar los riesgos a los niveles

pertinentes de la organización o a los clientes; en definitiva a los
stakeholder clave que deban interesarse.

Una buena Gestión de riesgos solo podrá realizarse si se cuenta con un

ambiente en el que las personas sientan la libertad de expresar sus puntos
de vista aún cuando estos difieran de los de sus superiores. Los riesgos son
inherentes al proyecto, por ende inevitables. Debemos aprender a convivir
con ellos si queremos gestionarlos.

Cuando los riesgos se perciben como algo negativo, los integrantes de un

equipo se muestran esquivos a informar sobre ellos. Esto es así al punto
que, en algunas organizaciones mencionar los riesgos nuevos se toma
como una queja. Una cultura como esta puede hacer que los integrantes
del proyecto tiendan a suavizar la realidad para evitar malos momentos,
todo lo cual redundará en una identificación tardía del riesgo.

Aún cuando los riesgos nos preocupan, es importante que el proyecto no

sea juzgado solo por la cantidad y naturaleza de sus riesgos.

Toda esta actividad deberá ser cuidadosamente planificada para poder

encararla con seriedad y compromiso, para ello es que se deberá, como
primer medida, crear un “Plan de Gestión de Riesgos”.

2
Plan de gestión de riesgos:
Un Plan de Gestión de Riesgos describe como se llevará adelante todos los
procesos vinculados al gerenciamiento de los riesgos desde la
identificación hasta la confección del Plan de Respuesta y el monitoreo y
control de los riesgos.

Es importante resaltar que hay una diferencia entre este plan y el Plan de
Respuesta a Riesgos ya que este último se crea una vez identificados y
analizados los riesgos para describir las acciones de mitigación y
contingencia que se implementarán.

Algunos aspectos a definir en un plan de gestión de riesgos:

 Métodos y técnicas que se usarán para identificar, analizar,

responder y controlar los riesgos
 Roles y responsabilidades para cada una de esas actividades
 Presupuestos y tiempos que se van a invertir en estos procesos
 Categorías y escalas para la descripción y análisis de los riesgos ( para
clasificar y para medir los riesgos)
 Umbrales de tolerancia de los stakeholder. Estos umbrales indican
cuales son las medidas de riesgos que requieren tratamiento
proactivo
 Informes requeridos para comunicar y gestionar los riesgos
 Procesos de seguimiento que describan como se hará el monitoreo y
auditorías de riesgos.

7.2 Identificación del riesgo

La identificación de riesgos es el proceso sistemático de descubrir
anticipadamente las amenazas sobre los objetivos del proyecto.

Se trata de identificar qué riesgos probablemente afectarán al proyecto y

documentar sus características. Este es un proceso iterativo que se lleva a
cabo fundamentalmente en la planificación del proyecto pero que debe
repetirse sistemáticamente a lo largo del mismo a efectos de descubrir
nuevas amenazas.

El objetivo final es lograr una lista de riesgos del proyecto, para ello será
necesario implementar un conjunto de herramientas y técnicas entre las
cuales podemos mencionar:

Tormenta de ideas: el equipo del proyecto y otros stakeholder pueden

reunirse con la coordinación apropiada para generar una lista inicial de
riesgos posibles.

3
Entrevistas: entrevistar a personas con experiencia en el tipo de proyecto
que se encara o conocimiento sobre la tecnología que se está por emplear
puede ser una excelente fuente de información para descubrir riesgos.

Revisión de documentación: La documentación del proyecto, del contrato,

los documentos de referencia son fuentes de información para el
descubrimiento de riesgos

Listas de comprobación: Una organización que ejecuta proyectos con

frecuencia puede sistematizar una lista de los riesgos más comunes en sus
proyectos, clasificarla por tipos de proyectos y contar así con un check list
que permita verificar que no estamos olvidando pensar en algún riesgo
común.

Finalmente terminaremos generando un Registro de Riesgos, que consiste

en una lista pormenorizada de los riesgos del proyecto que,
preferentemente debiera incluir sus causas.

7.3 Análisis cualitativo del riesgo

El análisis cualitativo de los riesgos prepara las condiciones para que los
próximos procesos puedan ejecutarse, ocupándose de caracterizar los
riesgos y describir todos sus atributos.

En este punto es importante tomar en cuenta que las dos principales

dimensiones que definen un riesgo son:

• Impacto
• Probabilidad

Cualquier análisis posterior sobre la peligrosidad de un riesgo debiera

hacerse sobre la base de estas dimensiones por lo cual los dos principales
atributos a definir en este proceso son estos.

Impacto: Puede medirse de diferentes modos: en función del tiempo que

se perderá/ ganará por su efecto; en función del costo, en una escala
cualitativa del tipo: alto, medio, bajo, entre otras posibilidades.

Probabilidad: Puede medirse la probabilidad en una escala numérica de

porcentaje o bien en una escala cualitativa del tipo: alta, media, baja, entre
otras posibilidades.

En ocasiones pueden usarse matrices de probabilidad/Impacto como la que

se presenta a continuación para definir estos ítems y a la vez conocer la
severidad de cada riesgo:

4
 Impacto 0,05 0,10 0,20 0,40 0,80

Probabilidad
Probabilid
ad
0,9 0,045 0,09 0,18 0,36 0,72

0,7 0,035 0,07 0,14 0,28 0,56

0,5 0,025 0,05 0,10 0,20 0,40

0,3 0,015 0,03 0,06 0,12 0,24

0,1 0,005 0,01 0,02 0,04 0,08

Figura 4.1 - Matriz de probabilidad/impacto

Es importante que la definición de las escalas en que los riesgos serán

cualificados haya sido previamente consensuada y documentada en el Plan
de Gerenciamiento de Riesgos.

Como resultado de este proceso podremos obtener para cada riesgo:

• Categoría
• Impacto
• Probabilidad de ocurrencia
• Otra información necesaria para su evaluación

7.4 Análisis cuantitativo del riesgo

El análisis cuantitativo de riesgos se concentra en determinar cuáles son los
riesgos que generan mayor peligrosidad para el proyecto.

Una de las técnicas más usadas para el análisis cuantitativo de riesgos es el

análisis de

Valor Monetario Esperado (EMV por sus siglas en inglés).

Con los riesgos se construye una lista indicando los valores de probabilidad
y de impacto. Ambos valores deben ser relacionados para poder tomar
decisiones sobre los riesgos.

5
La relación natural entre ambos será el producto, por lo que el producto de
probabilidad por impacto de cada riesgo nos dará como resultado lo que
conocemos como exposición al riesgo.

Cuando esta exposición está medida en unidad monetaria se llama EMV.

Ejemplo:

Riesgos Impacto Probabilidad Grado de

de ocurrencia exposición
al riesgo

A $ 100 30% 30
B $ 30 50% 15
C $ 20 80% 16
D $ 50 20% 10
E $ 70 50% 35

Con este último valor se podrá hacer la selección de los riesgos a tratar
eligiendo siempre los de mayor exposición o EMV que son los que, en
definitiva, presentan mayor peligrosidad para el proyecto.

Seguramente a esta altura nos damos cuenta que actuar de manera

proactiva generando planes de respuesta para todos los riesgos
identificados y analizados podría ser demasiado costoso e improductivo.
Un gestor maduro sabrá que algunos riesgos deberá tomar y otros deberá
mantenerlos controlados.

El grado de exposición al riesgo será el factor determinante para decidir

cuáles serán los riesgos que necesitan mayor control.

Para ello se realiza la priorización de riesgo, para lo cual el primer paso será
ordenar la lista en función de la columna de exposición.

En el ejemplo:

Riesgos Impacto Probabilidad de Grado de exposición

ocurrencia al riesgo

E $ 70 50 % 35
A $ 100 30 % 30
C $ 20 80 % 16
B $ 30 50 % 15
D $ 50 20 % 10
Figura 4 -Priorización de riesgos

6
Así tendremos los riesgos ordenados del de mayor severidad al de menor
severidad. Luego, para tomar la decisión podemos aplicar la ley de Pareto
cuya aplicación a este caso nos permitiría deducir que con el 20 % de los
riesgos podemos tener el 80% del peligro controlado.

Por lo tanto se aconseja hacer una línea de corte en aproximadamente el

20 % de los riesgos de mayor severidad y con ellos pasar al próximo paso
que será generar los correspondientes planes de respuesta a los riesgos.

7.5 Planificación de la respuesta a los

riesgos
La planificación de la Respuesta a riesgos es el proceso de generar opciones
y genera acciones para mejorar las oportunidades y reducir las amenazas a
los objetivos del Proyecto.

Todas estas acciones deberán presentarse en un plan que indique mucho

más que el enunciado de la acción.

Algunos de los aspectos que debiera incluir un buen plan de respuesta a los
riesgos se detallan a continuación:

• Riesgo
• Datos cuali - cuantitativos del riesgo
• Actividad/es a realizar para minimizar o evitar el riesgo
• Responsable
• Tiempos
• Recursos
• Indicadores de monitoreo
• Frecuencia de monitoreo
• Medidas de contingencia

Interesa destacar en este punto la diferencia entre una medida de

mitigación y una de contingencia: mientras la primera indica que se hará
para que el riesgo tenga menos posibilidad de ocurrir o menor impacto, la
segunda describe lo que se hará en caso que ocurra.

7.6 Monitoreo y control de los riesgo

El monitoreo y control de los riesgos es el proceso de identificar, analizar y
planificar nuevos riesgos a la vez que se revisa periódicamente las
probabilidades e impactos esperados de los riesgos ya identificados para

7
alertar posibles activaciones (riesgos que se convierten en problemas
reales) y estudiar nuevas fuentes de riesgos y causas.

Algunas acciones a llevar a cabo en este proceso serán:

• Reevaluación de los riesgos: Es importante que los procesos

definidos para el proyecto involucren necesariamente una revisión
periódica del estado de los riesgos identificados y el alerta de
aquellos que se vuelven más inminentes por las condiciones actuales
del proyecto.
• Auditoría de los riesgos: La auditoría inspecciona y documenta la
efectividad de los planes de respuesta y su implementación.
• Análisis de variaciones y Tendencias: deben revisarse las variaciones
de los indicadores del proyecto para poder establecer tendencias,
para ello es posible valerse de la técnica del valor ganado como
medio de análisis.
• Reuniones de Revisión de Estado de Situación: Realizar reuniones
periódicas para tratamiento de estos temas, o bien incluir en las
reuniones de avance del proyecto el tratamiento de los riesgos
facilitará el seguimiento y la internalización de los riesgos en el
equipo de proyecto.

8
8. Gestión de abastecimiento del
proyecto.
La Gestión del abastecimiento o adquisiciones del proyecto se refiere a los
procesos necesarios para lograr abastecer al proyecto de todos los
productos, servicios o resultados necesarios para llevar adelante el
proyecto.

Esto se logra:

• Determinando qué, cómo y cuándo comprar o adquirir.

• Documentando los requerimientos del producto o servicio e
identificando los proveedores potenciales.
• Obteniendo cotizaciones, ofertas y/o propuestas adecuadas.
• Revisando ofertas y seleccionando los proveedores escogidos.
• Manejando el contrato y las relaciones entre los vendedores y los
compradores.
• Completando y cerrando los contratos aplicables al proyecto.

Figura 4.2 - Procesos de la Gestión de Adquisiciones

Los proyectos requieren generalmente la implementación de numerosas

contrataciones de diversa índole.

El instrumento esencial en estos procesos es el CONTRATO

9
Un contrato es un acuerdo vinculante para las partes en virtud del cual una
de ellas se compromete a proveer productos, servicios o resultados
especificados, mientras la otra parte asume el compromiso de retribuir con
dinero u otra contraprestación válida y acordada.

Un contrato:

• Obliga legalmente a las partes.

• Describe derechos y obligaciones
• Documenta un acuerdo

Un contrato se compondrá de un conjunto de Términos y Condiciones.

Los términos forman parte integral e inseparable del acuerdo, en tanto que
las condiciones fijan reglas que dependen de la ocurrencia de algún
determinado evento o circunstancia para entrar en vigor.

Las condiciones pueden ser precedentes o subsecuentes:

• Precedente (si evento entonces obligación)

• Subsecuente (obligación a menos que ocurra evento)

Los contratos pueden ser de diferentes tipos, dependiendo de las

necesidades e intereses de las partes, del tipo de bien o servicio a contratar
y fundamentalmente de los riesgos que la contratación involucre.

TIPOS DE CONTRATOS:
Contrato de precio fijo:
Un contrato de precio fijo implica un precio único, total y fijo por la entrega
de la totalidad de lo comprometido:

Este tipo de contratos puede usarse cuando la contraprestación está

claramente definida. Supone mucho riesgo en los casos de productos o
servicios con especificaciones poco claras o incompletas y en aquellos
productos con alto grado de intangibilidad como el software por ejemplo.

Importante: El producto, bien o servicio debe estar bien definido

Riesgo:
 Bajo para el proyecto
 Alto para el proveedor

10
Contrato de costos reembolsables:
Este tipo de contrato implica el pago al proveedor de los costos incurridos
más un monto que representa la ganancia para el vendedor.

Este tipo de contratos se utiliza cuando la incertidumbre en cuanto a la

cantidad de insumos o recursos a invertir es alta.

El cliente acepta pagar al contratista todos los costos reales (Mano de

Obra, Materiales, etc.) con independencia de la cantidad, más alguna
utilidad acordada. Este tipo de contrato tiene un alto riesgo para el equipo
de proyecto, ya que los costos del contratista pueden exceder los costos
estimados para el proyecto.

Requiere un mayor control, y periódicas estimaciones de cuánto será el

costo total que va a incurrir el proveedor. Tiene poco riesgo para el
proveedor, aunque a la larga si el costo se excede generará mala
reputación para el proveedor.

Importante: - Auditorias de Costo y periódicas estimaciones

- Requiere mayor control
Riesgo:
 Alto para el proyecto
 Bajo para el proveedor

Contrato con incentivos:

Los contratos con incentivos premian la consecución o superación de
ciertos objetivos, (de alcance, plazos, costos). Generalmente son una
combinación de Precio Fijo y Costos reembolsables a los que se le agrega
un incentivo en función de indicadores de performance preestablecidos.

Importante: - Definir claramente las condiciones y cálculo del incentivo

Riesgo:
 Medio para el proyecto
 Bajo para el proveedor

Tiempo y materiales:
Los contratos de tiempo y materiales son un tipo híbrido de acuerdo
contractual en el que se fija valor unitario por las horas de trabajo y por los
materiales a consumir. En la tasa horaria se incluye costo directo, indirecto
y ganancia y luego se factura por cantidad de horas invertidas.

11
Este tipo de contratos en general no promueve la eficiencia puesto que el
proveedor tiene ventaja en la medida que más tiempo transcurre y por
ende requieren mucha auditoría por parte del comprador.

Aún así son muy usados en los casos en que es dificultoso estimar con
certeza el esfuerzo que se requerirá para completar el trabajo.

Al proveedor se le paga por una cantidad prefijada por unidad de servicio.

(Ej. $25 por hora por 7000 Horas de trabajo). El valor total será en función
de las cantidades necesarias para completar el trabajo.

• El costo incluye el costo directo e indirecto más la ganancia.

• Se pagan horas reales a la tasa horaria más el costo de los materiales.
• La ganancia del proveedor aumenta cuando el esfuerzo es mayor que
el estimado.

Importante: El acuerdo no promueve la eficiencia.

Riesgo:
 Alto para el proyecto
 Bajo para el proveedor

Son muchas las razones para subcontratar, entre ellas podemos mencionar
las que se detallan a continuación:

• Reducir y controlar los costos operativos

• Liberar recursos internos para otros propósitos
• Obtener recursos con conocimientos no disponibles internamente.
• Compartir riesgos
• Menor necesidad de inversión de capital
• Calidad Mejorada
• Acceso a experiencia especifica

Una contratación depende de muchos factores, algunos de ellos

promueven una contratación exitosa mientras otros son fuente de
problemas y conflictos.
Factores para una contratación exitosa
• Comprender las metas y objetivos de la empresa contratante
• Seleccionar al proveedor adecuado
• Un desarrollo progresivo de las relaciones
• Un contrato debidamente estructurado
• Una comunicación abierta con los individuos / grupos afectados
• Una atención especial a los problemas personales
• Respaldo y compromiso de los niveles superiores de la organización

12
Factores que llevan al fracaso en la contratación:
• Resistencia de los miembros del equipo de proyecto.
• Pérdida de control.
• Percepción del objetivo o bien subcontratado.
• Proveedores con preasignación.
• Grado del plan no acorde con la importancia o complejidad del bien o
servicio subcontratado.

Muchos son los elementos de un contrato. A continuación se detalla a

modo de ejemplo, algunas de las cláusulas principales a tomar en cuenta
en la confección de un contrato:

 Producto o servicio a contratar: Una clara descripción del bien o

servicio a contratar.
 Exposición falsa de costos: Afirma que es ilegal que el contratista
exagere las horas o costos gastados en el proyecto.
 Aviso de exceso en los costos o demoras en el programa: Indica
cómo serán las notificaciones ante estas circunstancias.
 Aprobación de los subcontratistas: Indicaciones al contratista sobre
que deberá tener aprobación antes de subcontratar a una persona o
bien para una tarea del proyecto.
 El equipo o la información a proporcionar por el contratista: Incluye
las fechas de entrega y que partidas (pieza de prueba por Ej.). Esto
nos protege ante demoras por parte del cliente en proporcionar
información, piezas o partidas.
 Patentes: La propiedad de patentes que puedan hacer de realizar el
proyecto.
 Cancelación: Presenta condiciones para dar por finalizado el
contrato.
 Divulgación de información confidencial: Prohíbe a una de las partes
a revelar a un tercero o usar con un propósito distinto al trabajo del
proyecto a información confidencial, tecnologías, o procesos
utilizados durante el proyecto.
 Consideraciones internacionales: Especifica los ajustes a realizar
cuando el proyecto y el contratista son de diferentes países.
 Condiciones de pago: Se refiere a la base sobre la cual se realizarán
los pagos. (Pagos mensuales, % del contrato, un solo pago al final del
contrato, etc.)
 Pagos de primas – penalidades: Cláusulas de premio por terminación
a tiempo o antes de lo que indique el programa, o si se exceden los
requisitos del producto o servicio. Cláusulas de penalidades mediante
la cual el cliente puede reducir el pago final si el proyecto no se
termina de acuerdo con el programa o si no se cumplen los requisitos
de desempeño. Debe permitir manejar el rendimiento deficiente.
 Cambios: EL procedimiento para proponer, aprobar y poner en
práctica los cambios al alcance o al programa del proyecto. También

13
 se deberá indicar si existieran cambios de precios, cómo se
implementarán y cómo se pagarán.
 Evaluaciones: frecuencia, intensidad, carácter de los resultados, etc.
 Interlocutores válidos: personas habilitadas para realizar recepción,
aprobación, etc.

8.1 Planificación del abastecimiento

El proceso de planificación del abastecimiento del proyecto consistirá en
definir:

• Que se compra y que se hace en el proyecto

• Que tipos de contratos se usarán para cada adquisición
• Las responsabilidades de cada participante de la organización en el
proceso de contratación
• Documentos a utilizar
• Plazos
• Informes a proveer
• Restricciones que afectarán las decisiones de compra y contratación
• Periodos de adelanto para las solicitudes
• Tipos de garantías a requerir
• Instrucciones para los proveedores
• Identificación de proveedores precalificados
• Definición de métricas para los procesos involucrados

8.2 Planificación del requerimiento

Para cada contratación se deberá llevar adelante una requisición o solicitud
a proveedores. Esta actividad debe ser planificada para respaldar el
proceso de solicitar al proveedor sus propuestas y luego efectuar la
selección.

Se deberán organizar los documentos que se utilizarán y se establecen los

criterios para la admisión y selección de proveedores y propuestas.

La complejidad y detalle de esta documentación deberá ser coherente con

el valor del bien a adquirir y los riesgos involucrados.

Entre los criterios de evaluación se puede mencionar:

 Comprensión de la necesidad
 Costo total del ciclo de vida
 Capacidad técnica
 Enfoque de gestión

14
  Enfoque técnico
 Capacidad Financiera
 Tamaño y tipo de negocio
 Referencias
 Derechos de propiedad

8.3 Requisición
Con el proceso de Requisición se solicita y se obtiene la respuesta de los
proveedores.

Podemos distinguir al menos entre dos tipos de solicitudes a proveedores:

• RFP (Request For Proposal): El requerimiento para propuesta consiste

en solicitar al proveedor el bien o servicio especificando la necesidad a
satisfacer y dejando al proveedor la posibilidad de hacer su oferta
libremente.

La evaluación se hará en este caso por calidad de la oferta y por precio.

• RFQ (Request For Quotation): El Requerimiento para Cotización implica

una especificación sumamente detallada por parte del comprador del
producto o servicio a contratar y solicita simplemente el precio de venta al
proveedor.

En este caso la selección debe hacerse solo por precio y no se aceptan

cambios ni mejoras a las calidades solicitadas.

Los resultados finales de este proceso serán:

• Lista de proveedores calificados

• Documentos de la Adquisición
• Propuestas y Cotizaciones

8.4 Selección de la fuente

La selección de la fuente es el proceso por el cual se analizan las
propuestas y las cotizaciones recibidas, se aplican los criterios de
evaluación que previamente se definieron, acordaron y comunicaron y
finalmente se decide el proveedor y propuesta a contratar.

Durante este proceso se usarán diferentes sistemas de ponderación,

negociación, sistemas de selección y ponderación y estimaciones

15
independientes para asegurar que las propuestas están dentro de los
límites aceptables.

Como resultado de este proceso se obtendrá:

 Proveedores seleccionados: Se finaliza el proceso con la definición y
comunicación de los proveedores elegidos en función de los criterios
y negociación final.
 Contratos: Los contratos son adjudicados, confeccionados y
formados. Se someten a revisión y aprobación final.
 Disponibilidad de recursos: Como resultado de este proceso se
conoce además los recursos de que se dispondrá y los momentos
acordados para su asignación y plazos.

8.5 Administración del contrato

La administración de Contratos incluye todos los trabajos necesarios para
asegurar que se cumplen los requisitos contractuales pautados, que las
entregas se reciben en tiempo y con las calidades exigidas. En definitiva se
asegura que los términos del contrato se cumplen y las condiciones se
controlan para su aplicación.

Debe tomarse en cuenta que ambas partes, solicitante y proveedor deben

hacer administración del contrato a efectos de cuidar los intereses.

Se deberá aplicar:
• Sistema de control de cambios del contrato
• Revisiones de rendimiento y entregas
• Inspecciones y auditorías
• Sistemas de pago
• Administración de reclamos
• Gestión de registros

8.6 Cierre de contrato

El cierre del contrato debe aplicarse a cada una de las contrataciones
pautadas para el proyecto.

Consistirá en:

• Verificar que todos los trabajos y productos han sido aceptados.

• Asegurar que se tiene todos los registros de las gestiones del contrato
• Generar el correcto archivo de registros y documentos para reclamos
futuros.

16