Autor: Alberto Allami

Fundamentos pedagógicos y diseño instruccional: José Luis Lens

FUNDAMENTOS DE LA GESTIÓN DE
INTRODUCCIÓN
PROYECTOS

1
INTRODUCCIÓN

En los últimos 10 años, la profesionalización de la gestión de los proyectos ha tenido una ex-
pansión considerable. Las empresas nacionales e internacionales se han volcado masivamente
a la aplicación del “Project Management”, sabiendo que está ampliamente probado que su
utilización genera valor agregado a sus productos y servicios, además de aumentar la producti-
vidad de sus recursos, maximizar ganancias y mejorar la relación con los clientes.

Uno de los grandes impulsores de este crecimiento es el Project Management Institute

(PMI®) que desde hace más de 20 años se dedica a promover el marco teórico-operativo de
la administración de proyectos mediante las sucesivas versiones publicadas de su estándar:
The Project Management Book of Knowledge® (PMBOK® GUIDE).

El siguiente capítulo se desarrolló siguiendo el estándar del PMBOK® Guide Fourth

Edition®, publicado por el PMI® el 31 de diciembre de 2008.

Está organizado en once capítulos, relacionados directamente con la introducción y las áreas de
conocimiento del estándar del PMI®. Aquí el lector podrá encontrar los conceptos teóricos y
operativos del PMBOK® Guide, con el agregado de numerosos ejemplos prácticos, aclaracio-
nes y ampliaciones de conceptos, reflexiones y propuestas de actividades prácticas.

Este documento no pretende reemplazar al PMBOK® Guide Fourth Edition®, sino ampliarlo
y complementarlo desde el punto de vista práctico y de la aplicación real de los aspectos teóri-
cos y operativos presentados en el estándar.

“PMI”, “Project Management Institute”, “PMBOK® GUIDE” y “PMBOK® GUIDE Fourth Edition®” son marcas registradas de Project Manage-
ment Institute, Inc.

2
 INTRODUCCIÓN

Lo que tiene de nuevo la versión 2008 del PMBOK

La importancia de los cambios

El propósito de este apartado es enumerar y explicitar los cambios realizados al PMBOK

Tercera Edición, con el objeto de incorporarlos al PMBOK Cuarta Edición, publicada el
31 de diciembre de 2008.
Si bien en el anexo del PMBOK 2008 se describen de forma un poco escueta los cambios
realizados en esta nueva versión, éstos son realmente importantes.
Por ejemplo, los cambios en el Alcance modifican radicalmente la visión del estándar, ya
que por primera vez desde que salió el primer PMBOK a fines de los 80, el PMI habla de
“requerimientos”, algo comúnmente utilizado en la definición del alcance de cualquier
proyecto y que el PMBOK nunca reflejó hasta ahora en su estándar.
Por otro lado, en los casos de los procesos que pasaron de “control” a “ejecución”, tene-
mos otro cambio importante, ya que se pretende más proactividad por parte del Gerente
de proyectos, y no la mera recolección de información de los sucesos ocurridos.
Otro cambio fundamental es la gestión de los interesados y sus expectativas, ya que el
PMI reconoce que el éxito o fracaso de un proyecto tiene un alto grado de subjetividad,
que esta dado por la expectativa que el cliente tiene sobre el producto o servicio final que
resultará de la ejecución del proyecto, que hay que manejar de ahora en más con “mucho”
más cuidado.
De todas formas, la magnitud de los cambios sólo puede ser percibida por profesionales
que trabajan con el estándar del PMI desde hace tiempo y tienen experiencia en el impac-
to que causaría cada cambio en un proyecto real. Con esto queremos decir que, para los
estudiantes de PM, estos cambios no serán muy visibles, por lo menos hasta tanto no se
involucren de lleno en la gestión de proyectos. Nuestra experiencia en la enseñanza del
estándar nos señala que el 90% de los estudiantes prácticamente no se detiene a leer el
PMBOK en detalle y profundidad.
Por eso, desde nuestro punto de vista, los cambios entre el nuevo y viejo PMBOK comen-
zarán a cobrar importancia para los estudiantes sólo si están desempeñándose en la geren-
cia de proyectos, o en la medida en que se involucren o comiencen a adquirir experiencia
concreta en el tema.
Los cambios en los procesos
Aquí señalamos y explicamos los cambios que se realizaron en importantes áreas de co-
nocimiento del estándar.

Área de conocimiento de Integración:

-Se eliminó “desarrollar” del enunciado del alcance preliminar.

Dado que el acta de constitución del proyecto ahora contiene muchos de los objetivos
preliminares del proyecto, y que dichos objetivos forman parte del enunciado del alcance,

3
INTRODUCCIÓN

el desarrollo del alcance preliminar dejó de tener sentido concreto.

-Se cambió “cerrar el proyecto” por “cerrar el proyecto o fase”.

Mediante este cambio se aclara que el proceso de cierre del proyecto no se refiere exclu-
sivamente al trabajo a realizar al final de proyecto, sino que se debe ejecutar cada vez que
se completa una fase.
Área de conocimiento de Alcance:

-Se eliminó “planificación del alcance”.

-Se agregó “recolección de requerimientos”.

Los requerimientos forman parte del estándar del PMI. Ahora se toma como base de la de-
finición del alcance todos aquellos requisitos definidos por los interesados en el proyecto.

Área de conocimiento de Costos:

- Se agregó el cálculo del “índice de desempeño del trabajo a completar”

Además de desarrollar con más detalle la herramienta de valor ganado, se agregó este
nuevo índice.

Área de conocimiento de Recursos Humanos:

-“Gestionar el equipo del proyecto” pasó de ser un proceso de control a ser un proceso de
ejecución.

Este cambio apunta a trabajar más proactivamente en los temas referentes a los recursos
humanos asignados al proyecto. Además, se agregaron detalles referentes a las habilidades
que debe tener el personal para conformar un equipo exitoso.

Área de conocimiento de Comunicaciones:

-Se agregó “identificar a los interesados”.

-Se cambió “gestionar a los interesados” por “gestionar las expectativas de los interesa-
dos”.

-“Gestionar las expectativas de los interesados” paso de ser un proceso de control a ser un
proceso de ejecución.

Los cambios apuntan a hacer mayor hincapié en la importancia de la participación acti-

va de los interesados en el proyecto. La gestión de las expectativas ahora cobra mayor
relevancia, ya que allí reside la percepción de éxito o fracaso del proyecto. Los cambios

4
 INTRODUCCIÓN

también están orientados hacia la acción, más que a la simple recolección y registro de
información.

Área de conocimiento de Adquisiciones:

-Se unificaron los procesos de “planificar las compras y adquisiciones” y “planificar la

contratación” en un solo proceso denominado “planificar las adquisiciones”.

-Se unificaron los procesos de “solicitar respuestas a los vendedores” y “selección de ven-
dedores” en un solo proceso denominado “efectuar las adquisiciones”.

Con el fin de acercar este proceso hacia la realidad de las contrataciones en los proyectos y
hace más natural su ejecución, se consolidaron los seis procesos anteriores en sólo cuatro
procesos.

5
 INTRODUCCIÓN

Presentación
En este capítulo se desarrollan los fundamentos de la gestión de proyectos.

Cada uno de los conceptos aquí presentados enumera los fundamentos del estándar del PMI.
Palabras como “proyecto”, “administración”, “ciclo de vida”, “organización”, “interesados”
(stakeholders) y “procesos”, son necesarias para una apropiación efectiva de las áreas de cono-
cimiento del estándar.

Asimismo, los cimientos sobre los que se construye el estándar del PMI son descriptos, amplia-
dos y ejemplificados en este capítulo.

Objetivos

Describir y comprender las bases fundamentales

de la gestión de proyectos sobre la base del están-
dar del PMI .
Entender las diferencias entre proyectos, progra-
mas y portafolios.
Asimilar el rol del gerente del proyecto.
Analizar las estructuras de las organizaciones.
Comprender el concepto de interesados en el
proyecto.
Analizar el ciclo de vida del proyecto.
Conocer las áreas de conocimiento del estándar

6
INTRODUCCIÓN

TEMARIO Definición de proyecto

1. Definición de proyecto 8

2. Administración de proyectos, programas y portafolios 10

3. La oficina de gestión proyectos (PMO) 11

4. Roles del gerente de proyectos 12

5. Factores ambientales de la organización 13

6. Ciclo de vida del proyecto 17

7. Ciclo de vida del proyecto vs. ciclo de vida del producto 19

8. La influencia de las organizaciones en los proyectos 21

9. Diferencias entre el estándar de gestión el proyectos del PMI y las

metodologías de desarrollo de productos
23

10. Procesos de la administración de proyectos 24

11. Descripción básica de las áreas de conocimiento del estándar 27

12. Correspondencia entre los grupos de procesos y las áreas de conocimiento 29

7
INTRODUCCIÓN

Fundamentos de la gestión de proyectos

“Y a este respecto se debe tener en cuenta hasta qué punto no hay cosa más difícil de
tratar, ni más dudosa de conseguir, ni más peligrosa de conducir, que hacerse promotor
de la implantación de nuevas instituciones. La causa de tamaña dificultad reside en que
el promotor tiene por enemigos a todos aquellos que sacaban provecho del viejo orden y
encuentra unos defensores tímidos en todos los que se verían beneficiados por el nuevo.
Esta timidez nace en parte al temor de los adversarios, que tienen la ley de su lado, y
en parte también la incredulidad de los hombres, quienes -en realidad- nunca creen en
lo nuevo hasta que adquieren una firme experiencia en ello”.
Nicolás Maquiavelo

1
El estándar del PMI define un proyecto como el esfuerzo temporario realizado con el fin de
crear un producto, servicio o resultado único. Debemos detenernos a analizar los dos concep-
tos básicos que encierra esta definición: temporario y único.

Todo proyecto es temporario, en el sentido de que tiene un inicio y un final claros y bien
definidos.

El concepto de “temporalidad” no hace referencia directa a la duración

específica de un proyecto. La duración de un proyecto puede variar entre
pocas horas a muchos meses. Por caso, un proyecto de construcción de un
puente sobre un río puede llevar muchos meses de trabajo, mientras que
un proyecto para alambrar el perímetro de una pileta de natación puede
tomar sólo algunas horas.

Otro aspecto relacionado con la “temporalidad” es que no hay que confun-

dir proyectos con procesos repetitivos.

8
 INTRODUCCIÓN

Ejemplo

Para ilustrar lo anterior, veamos el siguiente ejemplo:

Supongamos que somos los gerentes de un proyecto de desarrollo de una nueva línea de mon-
taje de automóviles para una automotriz. El inicio formal del proyecto está dado por un docu-
mento llamado “Acta de constitución del proyecto” (Project Charter). El armado de la línea de
montaje y la salida del primer automóvil que cumple con las especificaciones del cliente (la
automotriz) son parte del proyecto. La aceptación por parte del cliente de ese primer automó-
vil da por finalizado formalmente el proyecto. Lo que sucede luego de la finalización del
proyecto (la producción masiva del automóvil en la línea de montaje) no es un proyecto, sino
un proceso repetitivo de producción.

Todo proyecto es único, esto es, no hay dos proyectos iguales.

Por ejemplo, pensemos que somos una e mpresa constructora y una pareja nos contrata para
construirles una casa. Se define el estilo de la casa, los planos, los tamaños de las habitacio-
nes, las disposiciones, el jardín, la pileta, etc. Construimos la casa de acuerdo con las espe-
cificaciones y cerramos nuestro proyecto con la entrega de la llave a los propietarios, previa
aceptación de la casa por parte de aquéllos.

Días más tarde, otra persona pasa por allí, ve cómo quedó la casa, le gusta, y nos contacta para
que le construyamos una casa idéntica. ¿Estos dos proyectos son iguales? La respuesta es no.
Si bien vamos a construir una casa idéntica a la anterior, el lote donde la construiremos no
es el mismo, el equipo de trabajo probablemente no sea el mismo, las condiciones climáticas
quizás no sean similares o el costo de los materiales probablemente haya variado. Sí es cierto
que contamos con mucho trabajo ya definido, que vamos a poder reutilizar en su mayoría en
el nuevo emprendimiento.

R e fl e x i ó n

¿Es posible sostener el concepto de “temporalidad” de los proyectos cuan-

do no existe un inicio y/o una finalización formal del proyecto?

9
INTRODUCCIÓN

2. Administración de proyectos, programas y portafolios

Estos tres conceptos fundamentales se refieren a las diferentes formas de gestionar proyectos
de acuerdo a si éstos están agrupados por afinidad o no y, de estar agrupados, con qué criterio
se ha hecho el agrupamiento.

Ejemplo

Para clarificar los conceptos de programas y portafolios podemos pensar en el siguiente

ejemplo:

Supongamos que somos una multinacional que fabrica electrodomésticos. El plan estratégico
de esta compañía es aumentar en un 10% las ventas en los próximos 3 años. Para lograrlo,
ha pensado varios proyectos de productos innovadores, alguno de ellos relacionados con su
línea de audio, otros con la línea de video, unos pocos relacionados a la línea blanca de la
compañía, y por último, un puñado de proyectos pensados para su exclusiva línea de PCs.
Este conjunto de proyectos es el portafolio de la compañía, que hará, en teoría y a largo plazo,
cumplir con aquel objetivo estratégico.

Si agrupamos estos proyectos del portafolio dentro de subgrupos afines (todos los proyectos
de audio por un lado, todos los de video por otro, y así, sucesivamente), cada uno de esos
subgrupos son lo que se denomina programas. Seguramente tendremos beneficios al manejar
proyectos “afines” dentro de un programa. Estos beneficios estarán dados por el aprendizaje,
conocimientos y experiencia obtenidos en un proyecto que podrían ser aplicables en otro
proyecto similar dentro del programa, o la reutilización de materiales, recursos, experiencias,
etc.
Una parte importante de la administración de proyectos es el balanceo de
las restricciones que pudieran afectar los objetivos del proyecto: el alcan-
ce, el cronograma y el presupuesto. Es importante tener en cuenta que
estas restricciones están estrechamente relacionadas y compiten entre sí,
por lo tanto, la modificación de alguna de ellas influirá en al menos una de
las restantes.

10
 INTRODUCCIÓN

3
Las funciones comúnmente asociadas a la oficina de gestión de proyectos están relacionadas
con la coordinación y asistencia a los proyectos.

Las responsabilidades de una oficina de gestión de proyectos pueden variar.

Éstas pueden ser desde realizar funciones de soporte para los gerentes de proyectos, facilitan-
do documentación, formularios o guías de administración de proyectos, hasta ser realmente
los responsables del gerenciamiento de uno o varios proyectos.

Más allá del tamaño y la función de una PMO, lo importante es definir cla-
ramente el rol que ésta cumplirá dentro de la organización y comunicarlo
formal y oportunamente.

11
INTRODUCCIÓN

4. Roles del gerente de proyectos

Es el recurso en el cual recae la responsabilidad de la administración del proyecto.

Fundamentalmente, debrá aplicar todos sus conocimeintos sobre la gestión de proyectos para
cumplir los objetivos del proyecto (alcance, plazos y cronograma) que le fue encomendado.
El gerente de proyecto es constantemente evaluado por los niveles directivos más altos de
la organización a través de la medición del rendimiento en el proyecto y el liderazgo y la in-
fluencia de éste sobre su equipo de trabajo.

En otras palabras, el gerente de proyectos está capacitado en la teoría de

la administración de proyectos y tiene suficiente experiencia como para
ser el responsable absoluto de todo lo bueno y lo malo que suceda en el
proyecto.

Actividad

- Piense cuáles son sus funciones reales como gerente de proyecto.

- Si Ud. aún no es gerente de proyectos, pregúntele a quien maneja los

proyectos en su empresa.

- Registre estos datos y sus conclusiones en el block de notas.

12
 INTRODUCCIÓN

5. Factores ambientales de las organizaciones

En el gráfico se señalan los principales factores ambientales de las organizaciones:

Valores Procesos Políticas

Mercado Cultura Visión Estándares

Misión Creencias Regulaciones

Estos factores tienen relación directa con la forma de manejar los proyectos dentro de cada
organización, ya que pueden ejercer influencia en el momento de la toma de decisiones.

Los interesados (Stakeholders)

Los interesados en un proyecto son aquellas entidades que tienen algún interés en el proyecto.
Estas entidades pueden ser personas, grupos de personas, áreas de la empresa, u organizacio-
nes completas.

¿Quiénes son los interesados? El gerente del proyecto, los gerentes de

área, el equipo de trabajo, el sponsor, los vendedores, el cliente, los usua-
rios, los dueños, la sociedad, el gobierno, etc.

Un proyecto puede ser percibido como algo que tendrá un resultado negativo o positivo para
los interesados. Como contrapartida, los interesados pueden ejercer su influencia en forma
positiva o negativa durante el desarrollo del proyecto.

Es muy común hoy en día que cualquier proyecto industrial que esté rela-
cionado con la modificación del medioambiente tenga interesados que se
vean afectados negativamente, ya sea por el proceso de ejecución del pro-
yecto o por su resultado.

13
INTRODUCCIÓN

El equipo del proyecto debe identificar a todos los interesados (internos y externos) con el fin
de determinar con precisión los requerimientos y las expectativas de las partes involucradas.
De hecho, el Gerente de Proyecto y su equipo debe manejar e influenciar a los interesados con
el fin de obtener un resultado satisfactorio.

¿Qué significa influenciar a los interesados? Por ejemplo, si el Gerente de

Proyecto se da cuenta que la definición del alcance del proyecto está in-
completa, debe persuadir a los responsables de este trabajo para que lo
completen.

La identificación de los interesados y la evaluación de su grado de influencia sobre los objeti-

vos del proyecto es un proceso que transcurre durante todo el ciclo de vida. Analizar incorrec-
tamente a los interesados (o directamente no realizar el análisis) puede afectar al proyecto,
causando desde un incremento fuerte de los costos hasta la cancelación del mismo.

Los pasos a seguir son los siguientes:

14
 INTRODUCCIÓN

¿Cuán lejos se debería llegar con el análisis de los interesados? No hay

una formula mágica, lo cierto es que es el gerente de proyectos quien de-
fine hasta dónde llega el análisis de los interesados, y no tiene más que su
experiencia y la de su equipo en otros proyectos y algunos datos del mer-
cado, para decidir cuál es el punto de corte.

Ejemplo

Dependiendo de la naturaleza del proyecto, los interesados pueden llegar a ser los ciudada-
nos, la sociedad o el gobierno. Imaginemos que estamos trabajando en los requerimientos
de un proyecto para la construcción de una autopista que unirá las ciudades de Córdoba y
Mendoza.

Los interesados en este proyecto, además de la empresa constructora y su equipo de trabajo

serían los intendentes de cada ciudad o pueblo por donde pasará la autopista, los habitantes
de esos pueblos, los estados provinciales, los propietarios de campos expropiados, Vialidad
Nacional, el gobierno nacional, las entidades ecologistas, etc.

Un ejemplo contemporáneo es la instalación de las plantas procesadoras de celulosa en las

costas del río Uruguay. Son muchos los grupos y personas que se vieron afectadas negativa-
mente por estos proyectos. Si analizamos la situación desde el punto de vista de la gestión de
interesados, podemos destacar que el equipo de trabajo del proyecto habría incurrido en un
grave error de análisis de interesados, pues no habría tenido en cuenta los estatutos, regula-
ciones y pactos de un río compartido por dos países, en el cual se iban a volcar los desechos
de las plantas.

R e fl e x i ó n

¿Cuánto tiempo invirtió en el análisis de interesados en su último

proyecto?

¿Cuánto tiempo estaría dispuesto a invertir en esta actividad en su próxi-

mo proyecto?

15
INTRODUCCIÓN

Actividad

- Utilizando como punto de partida el diagrama que enumera los pasos

fundamentales para el análisis de interesados, elabore una lista detallada
de las tareas puntuales a seguir para llevar adelante este proceso en su
próximo proyecto.

- Tenga en cuenta que el detalle final no deberá tener menos de 20

tareas.

- Registre sus conclusiones en el block de notas

16
 INTRODUCCIÓN

6. Ciclo de vida del proyecto

Se denomina ciclo de vida del proyecto a la serie de pasos definidos para construir el produc-
to o servicio. Comúnmente, son un conjunto de pasos predefinidos a seguir.

Por ejemplo, las fases genéricas del ciclo de vida del desarrollo de proyec-
tos de software son: análisis, diseño, desarrollo, testeo e
implementación.

Cualquiera sea el tamaño, la complejidad o la naturaleza de un proyecto, siempre se podrá

encuadrar en una estructura genérica de ciclo de vida: inicio del proyecto, preparación y
organización, ejecución del trabajo del proyecto y cierre. Este tipo de estructura nos da una
referencia de dónde estamos parados en el proyecto cuando nos comunicamos con otras per-
sonas que no están familiarizadas con los detalles del proyecto.

La estructura genérica del ciclo de vida de proyectos nos permite observar las siguientes
características:

Al iniciar un proyecto, el costo y la cantidad de recursos asignados son escasos. A medida

que se avanza, estos aumentan progresivamente mientras se llega al pico de trabajo en el
proyecto, para luego empezar a caer rápidamente a medida que se van completando las acti-
vidades.

Inicio del Organización Ejecución del Cierre del

proyecto y preparación trabajo proyecto
Nivel de costos

Tiempo
Acta de Plan de Productos Archiv o de los
constitución gestión del entregables documentos
del proyecto proyecto aceptados del proyecto

Fuente: PMBOK® Guide Fourth Edition, Página 16

17
INTRODUCCIÓN

Ejemplo

Pensemos que nuestro proyecto es la construcción del estadio municipal de fútbol. Al co-
mienzo, en las fases tempranas del ciclo de vida de nuestro proyecto, sólo trabajarán en él
algunos ingenieros y arquitectos, definiendo planos, evaluando factibilidades, planificando el
trabajo a realizar. A medida que el trabajo se va definiendo, se podrá empezar a incorporar a
los maestros mayores y los obreros que trabajarán en la obra. Promediando nuestro ciclo de
vida, tendremos mucha gente trabajando en paralelo, consumiendo recursos (tiempo, dinero,
materiales). A medida que las obras van concluyendo, ya hacia el final del ciclo de vida del
proyecto, empezará a decrecer la cantidad de obreros, arquitectos e ingenieros que están
asignados al proyecto. En la última fase, ya sólo quedarán algunas pocas personas que se
encargarán de cerrar los aspectos formales del proyecto (aceptación de los trabajos realizados
y cierre de contratos).

Existen otros factores importantes en el ciclo de vida de un proyecto:

• La influencia de los interesados: en las fases tempranas del ciclo de vida

del proyecto, la influencia de los interesados es mayor; a medida que se
avanza en el proyecto, esta influencia va desapareciendo.

• El costo de los cambios: es mayor a medida que se avanza en las fases

del ciclo de vida del proyecto.

Volviendo al ejemplo de la construcción del estadio de fútbol, las autoridades municipales,

junto a los arquitectos e ingenieros, definieron y acordaron, durante las fases tempranas (el
inicio) del proyecto, los planos que detallan cómo será el estadio, qué capacidad tendrá, cómo
estarán dispuestas las instalaciones, qué tamaño tendrá el campo de juego, etc. En estas fases
tempranas se da la mayor influencia (qué es lo que quieren) de los interesados en el proyec-
to.

Ahora bien, cualquier cambio que surja en esta etapa tiene un bajo costo de ejecución, ya
que si a una de las autoridades municipales se le ocurre duplicar la cantidad de asientos en la
platea Norte, con sólo modificar el plano es suficiente. Pero imagínense qué sucedería si a la
misma persona se le ocurre tal modificación una vez que el estadio esta terminado. El costo
del cambio sería enorme.

18
 INTRODUCCIÓN

7. Ciclo de vida del proyecto vs. ciclo de vida del producto

Hemos visto que el ciclo de vida del proyecto está dado por sus fases. El ciclo de vida del pro-
ducto empieza con la concepción del producto (o servicio) hasta su retiro final del mercado.
El ciclo de vida del proyecto suele ser parte del ciclo de vida del producto.

Ejemplo

Pensemos en el siguiente ejemplo: el gerente de nuevos productos de una empresa de fabri-

cación de hardware se contacta con el gerente de proyectos de la misma organización para
discutir el desarrollo de una nueva impresora. El equipo de nuevos productos ya ha escrito las
especificaciones técnicas, y requieren que se empiece un proyecto para el armado y testeo de
la impresora. Esta situación la podemos graficar de la siguiente forma:

Concepción del Desarrollo del Lanzamiento del Producción

producto producto producto

Ciclo de vida del proyecto

Ciclo de vida del Producto

Vemos que el proyecto “desarrollo de la impresora” forma parte de un ciclo mayor que es el
ciclo de vida del producto.

Basados en el mismo ejemplo, podemos suponer también que nos encargan el estudio de
factibilidad del desarrollo de una nueva impresora, previo a su desarrollo. Gráficamente se
representa así:

19
INTRODUCCIÓN

Concepción del Desarrollo del Lanzamiento del Producción

producto producto producto

Ciclo de vida del proyecto

Ciclo de vida del Producto

Así podemos apreciar que dentro del ciclo de vida del producto puede haber más de un pro-
yecto. El producto entregable de un proyecto anterior sirve como entrada del proyecto que
lo sucede.

Actividad

Discuta en grupo con sus compañeros de curso a partir de las siguientes

consignas:

- ¿Cuántos ciclos de vida de proyecto pueden formar parte del ciclo de

vida de un producto particular?

- Piense esta situación para un producto complejo (un nuevo modelo de

tren bala) y para uno simple (una nueva botella de bebida cola).

- Registre la síntesis de las conclusiones en el block de notas.

20
 INTRODUCCIÓN

8
Cada empresa tiene su forma particular de llevar adelante un proyecto. Las organizaciones
tienen distintos grados de conocimiento a cerca de cómo ejecutar un proyecto adecuada-
mente.

La estructura organizacional es un factor fundamental que influye en la conducción de los

proyectos. Existen varios tipos de estructuras jerárquicas. Estas estructuras abarcan un
amplio espectro, desde las funcionales hasta “proyectizadas”, pasando por diferentes tipos
de estructuras matriciales. A continuación haremos un análisis de estas estructuras desde
el punto de vista del nivel de autoridad de un gerente de proyectos en cada una de ellas.

La estructura de organización funcional (la más tradicional) muestra una escala jerárqui-
ca. Cada empleado tiene un superior definido. Los niveles jerárquicos están especializa-
dos (división del trabajo en tareas más simples y agrupadas en unidades organizativas).
La gestión de los proyectos depende del gerente funcional, ya que el gerente de proyectos
casi no tiene ningún tipo de autoridad en esta estructura. Generalmente, el gerente de pro-
yectos es un recurso de algún área que trabaja de coordinador o facilitador.

Director

Ventas Ingeniería Legales

Supervisor Supervisor Supervisor

Fuente: PMBOK® Guide Fourth Edition, Página 29

La organización proyectizada es una estructura donde la mayoría de los empleados son

parte de un repositorio de recursos para los distintos proyectos. Los gerentes de proyectos
son quienes manejan estos recursos, dado que su autoridad en este tipo de organizaciones
es alta o total.
PM

Proyecto Proyecto Proyecto

Equipo Equipo Equipo

Fuente: PMBOK® Guide Fourth Edition, Página 31

21
INTRODUCCIÓN

Como versión intermedia entre los dos extremos de estructuras organizacionales, se encuen-
tra la estructura matricial. Ésta representa un punto intermedio entre las estructuras funcio-
nales clásicas y la estructura “proyectizada”. Las estructuras matriciales débiles mantienen la
mayoría de las características de las estructuras funcionales, en las cuales el rol del gerente de
proyectos no es más que de coordinación entre las distintas especialidades. En contrapartida,
en el caso de las estructuras matriciales fuertes, éstas tienen la mayoría de las características
de las estructuras “proyectizadas”, donde el gerente de proyectos tiene un importante grado
de autoridad sobre los recursos y proyectos.

Director

Proyectos Ingeniería Legales

PM Personal Personal

Fuente: PMBOK® Guide Fourth Edition, Página 30

R e fl e x i ó n

¿Sabe cuál es su posición jerárquica en la organización en la que se

desempeña?

Actividad

Pídale a su jefe que le facilite el organigrama de su área de trabajo y, de

ser posible, intente conseguir el organigrama completo de la
organización.

22
 INTRODUCCIÓN

9. Diferencias entre el estándar de gestión el proyectos del PMI y las metodologías

de desarrollo de productos

Es importante analizar con detenimiento la diferencia que existe entre el estándar de gestión
de proyectos del PMI y las metodologías de desarrollo de productos.

Las metodologías de desarrollo de productos (o servicios) se enfocan en los pasos a seguir

para la definición y documentación de las características del producto a desarrollar (los re-
querimientos), el armado o desarrollo de esas características, las pruebas y la entrega del
producto terminado al cliente. En otras palabras, estas metodologías se enfocan en el trabajo
a realizar para construir el producto o servicio.

El estándar de gestión de proyectos es complementario a la metodología de desarrollo de

productos, ya que, si bien se superpone en algunos puntos, se encarga de administrar otros
aspectos del proyecto, como la optimización de tiempos de trabajo, la correcta asignación de
recursos a tareas, el manejo adecuado de los costos, las comunicaciones dentro y fuera del
proyecto, el desarrollo del equipo de trabajo y el manejo de riesgos, entre otras cosas. En otras
palabras, el estándar se enfoca en definir qué es lo necesario para gestionar el proyecto.

Si bien esta guía no se ocupa específicamente de analizar los procesos orientados al desarro-
llo de productos (metodologías) y sólo se encarga de describir y analizar los procesos de la
gestión de proyectos (el estándar del PMI), el gerente de proyectos no debería ignorar las me-
todologías utilizadas para el desarrollo del producto y la interacción de éstas con el estándar
de gestión de proyectos, ya que son complementarias y suelen superponerse a lo largo de la
vida del proyecto.

Los procesos orientados a la gestión de proyectos son aplicables globalmente a cualquier

industria. Existe un acuerdo general y pruebas suficientes que sostienen que la aplicación de
los procesos de gestión de proyectos aumentan las chances de éxito.
Sin embargo, esto no significa que todos los procesos, áreas de conocimiento y habilidades
descriptas en el estándar deberán ser aplicados uniformemente en todos los proyectos. Para
cada proyecto, el gerente de proyectos y su equipo de trabajo son responsables de determinar
cuáles son los procesos adecuados a utilizar y con qué rigor se utilizará cada uno de ellos.

R e fl e x i ó n

¿En su lugar de trabajo se utiliza actualmente alguna metodología de de-

sarrollo de productos o servicios?

23
INTRODUCCIÓN

10. Procesos de la administración de proyectos

Tal como se señala en el PMBOK® Guide Fourth Edition®:

“La dirección de proyectos es la aplicación de conocimientos, habilidades, herramientas y

técnicas a las actividades del proyecto para cumplir con los requisitos del mismo. La aplica-
ción de conocimientos requiere de la dirección eficaz de los procesos apropiados.

Un proceso es un conjunto de acciones y actividades interrelacionadas para obtener un pro-

ducto, resultado o servicio predefinido. Cada proceso se caracteriza por sus entradas, por las
herramientas y técnicas que pueden aplicarse y por las salidas que se obtienen. El gerente de
proyectos debe considerar los activos de los procesos de la organización y los factores am-
bientales de la empresa. Éstos proporcionan pautas y criterios para adaptar dichos procesos
a las necesidades específicas del proyecto. Los factores ambientales de la empresa pueden
restringir las opciones de la dirección de proyectos.

Para que un proyecto tenga éxito, el equipo del proyecto debe:

Seleccionar los procesos adecuados requeridos para alcanzar los objetivos del proyecto

Utilizar un enfoque definido que pueda adoptarse para cumplir con los requisitos
Cumplir con los requisitos a fin de satisfacer las necesidades y expectativos de los intere-
sados, y equilibrar las demandas contrapuestas relativas de alcance, tiempo, costo, calidad,
recursos y riesgo para producir el producto, servicio o resultado especificado.

Los procesos de dirección de proyectos se aplican globalmente a todos los grupos de indus-
tria. “Buenas prácticas” significa que existe un acuerdo general en cuanto a que se ha demos-
trado que la aplicación de los procesos de dirección de proyectos aumenta las posibilidades
de éxito de una amplia variedad de proyectos.

Esto no significa que los conocimientos, habilidades y procesos descriptos deban aplicarse
siempre de la misma manera a todos los proyectos. Para un proyecto determinado, el director
del proyecto, en colaboración con el equipo el proyecto, siempre tiene la responsabilidad de
determinar cuáles son los procesos apropiados, así como el grado de rigor adecuado para
cada caso.

Los directores del proyecto y sus equipos deben abordar cuidadosamente cada proceso, así
como las entradas y salidas que lo constituyen.

Los procesos de dirección de proyectos se agrupan en cinco categorías conocidas como Gru-
pos de Procesos de la Dirección de Proyectos:

Grupo de procesos de iniciación: Aquellos procesos realizados para definir un nuevo pro-
yecto o nueva fase de un proyecto ya existente, mediante la obtención de la autorización para
comenzar dicho proyecto o fase.

24
 INTRODUCCIÓN

Grupo de procesos de planificación: Aquellos procesos requeridos para establecer el alcan-

ce del proyecto, refinar los objetivos y definir el curso de acción necesario para alcanzar los
objetivos para cuyo logro se emprendió el proyecto.

Grupo de procesos de ejecución: Aquellos procesos realizados para completar el trabajo

definido en el plan para la dirección del proyecto a fin de cumplir con las especificaciones del
mismo.

Grupo de procesos de seguimiento y control: Aquellos procesos requeridos para dar segui-
miento, analizar y regular el progreso y el desempeño del proyecto, para identificar áreas en
las que el plan requiera cambios y para iniciar los cambios correspondientes.

Grupo de procesos de cierre: Aquellos procesos realizados para finalizar todas las activi-
dades a través de todos los grupos de procesos, a fin de cerrar formalmente el proyecto o una
fase del mismo”*.

Formato de los procesos

Todos los procesos de las áreas de conocimiento del PMI son representados con el mismo
formato: entradas, herramientas y técnicas, salidas.

Entradas: es cualquier elemento, interno o externo del proyecto que sea requerido por un
proceso antes de que dicho proceso continúe. Puede ser el resultado de un proceso predece-
sor.

Herramientas: es algo tangible, como una plantilla o un programa de software, utilizado al

realizar una actividad para producir un producto o resultado.

Técnicas: es un procedimiento sistemático definido y utilizado por una persona o grupo de

personas para realizar una actividad para producir un producto o un resultado, o prestar un
servicio, y que puede emplear una o más herramientas.

Salida: es un producto, resultado o servicio generado por un proceso. Puede ser un dato ini-
cial para un proceso sucesor.

* Fuente: PMBOK® Guide Fourth Edition® – Páginas 37-38.

25
INTRODUCCIÓN

26
 INTRODUCCIÓN

11. Descripción básica de las áreas de conocimiento del estándar

Por último, para completar este curso introductorio no podríamos dejar de describir, aun-
que sea de forma breve y sintética, las áreas de conocimiento del estándar. Estas son las
siguientes:

 Integración:

El área de conocimiento de la integración del proyecto está compuesta por una serie de
procesos que articulan a las otras áreas de conocimiento.

Incluye las actividades necesarias para identificar, definir, combinar, unificar y coordinar
los procesos y actividades de la administración de proyectos.

 Alcance:

La gestión del alcance del proyecto es el conjunto de los procesos necesarios para asegurar
que se incluya únicamente todo el trabajo requerido para completar el proyecto satisfac-
toriamente.

Las funciones primordiales de la gestión del alcance son la definición y el control de lo que
está y lo que no está incluido en el proyecto.

 Plazos:

El objetivo de la gestión de los plazos de proyecto es completar el trabajo puntualmente,

mediante la definición de las actividades a ejecutar, el establecimiento de su secuencia y
su duración con el fin de definir el cronograma del proyecto para su posterior seguimiento
y control.

 Costos:

Esta área de conocimiento tiene por objetivo presupuestar el trabajo a realizar en el pro-
yecto. Ese presupuesto se desarrolla a partir del análisis y la estimación de los costos de
las actividades y el posterior control del flujo de los fondos del proyecto.

 Calidad:

Este proceso define los objetivos de calidad del proyecto y se ocupa de que se le entregue
al cliente exactamente lo que pidió y de que éste quede satisfecho con el resultado obte-
nido.

27
INTRODUCCIÓN

La gestión de la calidad también apunta a evitar los errores en vez de corregirlos, identificar
y asignar responsabilidades sobre la calidad a los interesados y fomentar la mejora continua
de los procesos.

 Recursos Humanos:

El área de conocimiento de la gestión de los recursos humanos se ocupa de la relación que

existe entre las actividades del proyecto y las personas que las ejecutarán, la obtención de la
gente, el armado y liderazgo del equipo, el desarrollo de las capacidades de las personas, el
manejo de los factores humanos que pueden influir en el desarrollo del trabajo y el respeto
por una labor ética y profesional.

 Comunicaciones:

El grupo de procesos de la gestión de las comunicaciones establece los pasos a seguir para
obtener, elaborar y transmitir la información del proyecto a todos los interesados.

Esta información puede estar relacionada con los detalles técnicos del producto o servicio
a desarrollar o la descripción del estado del proyecto en cuanto a costos o plazos. También
ayuda a manejar las expectativas del cliente.

 Riesgos:

El objetivo de los procesos de gestión de los riesgos es encontrar, analizar y crear respuestas
para los eventos que podrían afectar los objetivos del proyecto (alcance, plazos, costo, cali-
dad, etc.).

Esos eventos pueden ser negativos (los riesgos del proyecto propiamente dicho) o positivos
(oportunidades).

 Adquisiciones:

El conjunto de procesos de adquisiciones tiene como finalidad definir, administrar y cerrar

la gestión de los contratos, desarrollados con el objetivo de obtener productos o servicios de
terceros.

28
 INTRODUCCIÓN
FUNDAMENTOS DE LA GESTIÓN DE PROYECTOS

TEMA 12 CONTENIDO Descripción básica de las

áreas de conocimiento del estándar

12 . Correspondencia entre los grupos de procesos y las áreas de conocimiento.

Grupos de Procesos de la Dirección de Proyectos
Grupo de
Áreas de Grupo de Grupo de Grupo de Grupo de
procesos de
conocimiento procesos de procesos de procesos de procesos de
seguimiento y
iniciación planificación ejecución cierre
control
•Monitorear y
controlar el
•Desarrollar el •Desarrollar el •Dirigir y trabajo del •Cerrar el
acta del proyecto plan de gestión gestionar la
Integración proyecto proyecto o fase
(Proyecto del proyecto ejecución del •Ejecutar el
Charter) proyecto control integrado
de cambios
•Recolectar los
requerimientos •Verificar el
Alcance •Definir el alcance alcance
•Crear la EDT •Controlar el
(WBS) alcance

•Definir las
actividades
•Establecer la
secuencia de las
actividades
•Estimar los
•Controlar el
Plazos recursos para las
cronograma
actividades
•Estimar la
duración de las
actividades
•Desarrollar el
cronograma
•Estimar los
costos Preparar •Controlar los
Costos
el presupuesto costos
•Planificar la •Asegurar la •Controlar la
Calidad calidad calidad calidad
•Armar el equipo
del proyecto
•Desarrollar el •Desarrollar el
plan de recursos equipo del
Recursos Humanos proyecto
humanos
•Administrar el
equipo del
proyecto
•Distribuir la
información
•Identificar a los •Planificar las •Informar el
Comunicaciones interesados •Manejar las
comunicaciones rendimiento
expectativas de
los interesados
•Planificar la
gestión de los
riesgos
•Identificar los
riesgos
•Analizar
cualitativamente
•Monitorear y
Riesgos controlar los
los riesgos
•Analizar riesgos
cuantitativamente
los riesgos
•Planificar las
respuestas a los
riesgos

•Planificar las •Conducir las •Administrar los •Cerrar los

Adquisiciones
adquisiciones contrataciones contratos contratos

29
 INTRODUCCIÓN

 A modo de cierre

En este primer capítulo se han descrito, interpretado y ejemplificado los conceptos básicos que
hacen al fundamento de la gestión de proyectos.

La base teórica y operativa aquí expuesta será utilizada ampliamente en los sucesivos capítu-
los, particularmente en el siguiente, en el que se trata la primera de las áreas de conocimiento
del estándar: “La integración”. Esta última maneja, supervisa y coordina todo el trabajo reali-
zado en el resto de las áreas de conocimiento del PMBOK® Guide.

 Bibliografía consultada

1) A guide to the Project Management Book of Knowledge (PMBOK® Guide) Forth

edition – PMI 31-12-2008

2) The Standard for Program Management®– Second Edition – PMI 31-12-2008.

3) The standard for Portfolio Management® – Second Edition – PMI 31-12-2008.

29