01 - Pm-Fundamentos

Capítulo 1
Fundamentos de la gestión de
proyectos
Como PM experto en el estándar el PMI siempre me preocupó tener muy claros los
fundamentos de la gestión de proyectos. Ahora quiero ayudarlos a que los incorpo-
ren eficazmente en sus aspectos teórico y operativo. Para ello, voy a desarrollar, con
la cooperación activa de ustedes, los siguientes temas:
1. Definición de proyecto
2. Administración de proyectos, programas y portafolios
3. La oficina de gestión proyectos (PMO)
4. El gerente de proyectos
5. PM vs. PMO
6. La influencia de las organizaciones en los proyectos
7. Factores del entorno organizacional
8. Los interesados (Stakeholders)
9. El equipo del proyecto
10. Ciclo de vida del proyecto
11. La gestión de proyectos vs. metodologías de desarrollo de
productos
12. Grupos de procesos de la administración de proyectos
13. Descripción básica de las áreas de conocimiento del estándar
14. Formato de los procesos
CAPITULO 01 // Fundamentos de la Gestión de Proyectos
Presentación
En este capítulo se desarrollan los fundamentos de la gestión de los 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 conocimiento del estándar. Asimismo, los cimientos sobre los que se construye el estándar del
PMI son descriptos, ampliados y ejemplificados en este capítulo.
Los objetivos son:
• Describir y comprender las bases fundamentales de la gestión de proyectos sobre la base del
estándar del PMI.
• Entender las diferencias entre proyectos, programas 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.
Los fundamentos de la gestión de proyectos

y su entorno
“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 prove-
cho 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 ex-
periencia en ello”.
Nicolás Maquiavelo
Extraje este párrafo de un texto de Maquiavelo para darle sentido a lo que van a comenzar a leer. A medida que
recorran los distintos capítulos de este libro se darán cuenta que lo que se propone es un cambio profundo en la
manera que se gestionan los proyectos en su empresa, y ese cambio debe ser liderado por ustedes. El cambio
propuesto mediante el estándar del PMI es complejo, profundo y se debe basar en dos pilares fundamentales:
el conocimiento teórico-práctico del estándar y el valor asumir nuestro rol para enfrentarse a los detractores que
sostendrán qué, si siempre se hicieron las cosas de una manera, por qué cambiarlas.
Centro de Estudios de Project Management - SCEU UTN BA 5

Veamos el primero de los temas:
1.Definición de proyecto
Cuando a un grupo de personas se le pregunta si alguna vez dirigió un proyecto, rápidamente la mayoría
contesta que nunca, y unos pocos, generalmente especialistas en proyectos, afirman haberlo hecho. Sin
embargo, cuando se les explica qué es un proyecto, entienden que todos, alguna vez, han gerenciado
uno. Lo que probablemente no hayan hecho es utilizar una metodología o un estándar para dirigirlo, lo
cual seguramente les facilitaría la tarea.
El estándar del PMI define un proyecto como el esfuerzo temporario realizado con el fin de crear un pro-
ducto, servicio o resultado único. Pero debemos
detenernos a analizar los dos conceptos básicos
que encierra esta definición: temporario y único. TOMEN NOTA:
Todo proyecto es temporario, en el sentido de que El concepto de temporalidad no hace
tiene un inicio y un final claros y bien definidos. referencia directa a la duración de un
Todo proyecto es único, porque no hay dos pro- proyecto, sino a que tiene asociado una fecha de
yectos idénticos, más allá que compartan mucho inicio y de fin específicas. La duración de un pro-
del resultado final esperado. yecto 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.
REFLEXIONEMOS:
¿Qué opinan? ¿Es posible sostener el concepto de “temporalidad” de los proyectos cuando no existe un inicio
y/o una finalización formal del proyecto?
La “temporalidad” de un proyecto es un factor distintivo de los proyectos al compararlos con los procesos re-
petitivos de las empresas, denominados comúnmente operaciones.
La gestión de operaciones se centra en la administración de la producción continua de productos y/o servicios

para asegurar la continuidad del negocio.
Si bien el análisis de las operaciones de las organizaciones está fuera del alcance de este libro, es necesario
tenerlas en cuenta ya que existe un punto de intersección entre la gestión de proyectos y la gestión de las
operaciones.
Las operaciones son alimentadas por los productos y/o servicios producidos por proyectos, ya sea generando
una capacidad completamente nueva (producto o servicio nuevo) o modificando una existente (reemplazo de
personal por robots en la línea de ensamblaje de automóviles).
Por último, los recursos afectados a las operaciones pueden ser claves en el desarrollo del proyecto. El cono-
cimiento y la información que se puede obtener de capataces, operadores, vendedores, personal de soporte
técnico o mantenimiento deben ser considerados.
6 Centro de Estudios de Project Management - SCEU UTN BA

VEAN ESTE EJEMPLO:
Supongamos que somos los gerentes de un proyecto de desarrollo de una nueva línea de montaje de
automóviles para una automotriz. El inicio formal del proyecto está dado por un documento 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.
Pensemos que somos una empresa constructora y una pareja nos contrata para construirles una casa. Se define el
estilo de la casa, los planos, los tamaños de las habitaciones, las disposiciones, el jardín, la pileta, etc. Construimos
la casa de acuerdo con las especificaciones y cerramos nuestro proyecto con la entrega de la llave a los propieta-
rios, 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. Aunque sí, es cierto, que contamos con mucho trabajo ya
definido y que vamos a poder reutilizar en su mayoría en el nuevo emprendimiento.
Les comento que los ESTIMULO EJEMPLO

proyectos surgen a partir Demanda del mercado Mejoras en el suministro de gas industrial
de estímulos determina-
dos, que podemos clasifi- Necesidades de la sociedad Tendido de una red cloacal
car de la siguiente manera: Necesidad del negocio Nuevo producto para aumentar las ventas
Medioambiente Construcción de una planta de reciclado
Pedido de clientes Construcción de oficinas
Avance tecnológico Cámaras con mayor definición de imagen
Requisitos legales Modificación de las leyes de facturación
REFLEXIONEMOS:
¿Cómo surgen los proyectos en el medio en el que ustedes se desempeñan? También es importante preguntarnos:
¿Qué pueden crear los proyectos?
Los proyectos pueden crear, entre otras cosas
• Un producto
• Un servicio
• Un componente de un producto
• Un resultado
• Un proceso

Ya tenemos una buena definición de proyecto, ahora veamos cómo se administran los proyectos, los programas
y los portafolios.
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.
La administración La administración La administración

de proyectos de programas de portafolios
Es la aplicación sistemática de Es la gestión de un grupo de Es la agrupación de proyectos,

conocimientos, habilidades, proyectos en forma conjunta y programas y operaciones de
capacidades, herramientas y coordinada para obtener manera de facilitar su manejo
técnicas para lograr satisfacer beneficios no alcanzables si para lograr los objetivos
los requerimientos del proyecto éstos se manejaran en forma estratégicos del negocio
separada.
VEAN ESTE 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
la 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. Estas ideas, más el conjunto de sus
operaciones, conforman el portafolio de la compañía, que hará en el largo plazo que se cumpla con
aquel objetivo estratégico.
Si agrupamos los 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.
La administración de proyectos -objetivo TOMEN NOTA:

principal de análisis de este libro- se reali-
za a través de la correcta utilización de los Una parte importante de la administración de proyectos
procesos de gestión de proyectos, deta- es el balanceo de las restricciones que pudieran afectar
llados más adelante. Esos procesos inclu- los objetivos del proyecto: el alcance, el cronograma, el presupues-
yen, entre otras cosas: Identificar requeri- to, la calidad, los recursos son alguna de esas variables. Es impor-
mientos, manejar las expectativas de los tante tener en cuenta que estas restricciones están estrechamente
interesados, manejar las comunicaciones relacionadas y compiten entre sí, por lo tanto, la modificación de
y balancear las restricciones del proyecto. alguna de ellas influirá en al menos una de las restantes.

¿Cuál es nuestro objetivo como PM?
El trabajo del gerente de proyecto es lograr el objetivo (cumplir con el alcance), con el presupuesto asignado
(cumplir con los costos) en el tiempo planificado (cumplir con el cronograma) y con la calidad esperada (cumplir
con las expectativas).
El balanceo de las restricciones del proyecto es una fuente importante de potenciales cambios. Es justamente
esa potencialidad lo que hace que el desarrollo del plan de gestión del proyecto se realice en forma progresiva,
basándose en el hecho de que debe ser mejorada cíclica y continuamente, a medida que se tiene mayor infor-
mación sobre el proyecto y sus objetivos.
En mi experiencia, un hecho fundamental es analizar el proyecto y sus restricciones y definir qué factor es lo más
importante. ¿Es el costo, el alcance, o el plazo de entrega? Si sabemos en líneas generales qué le importa más
a la mayoría de los interesados, podré guiar mis esfuerzos más eficientemente. Con esto no estoy diciendo que
hay que dejar al azar los otros factores, sino que aquellos que no sean fundamentales se podrán negociar más
fácilmente.
El estándar del PMI también establece la posibilidad de contar con una oficina de gestión de proyectos (PMO):
3. La oficina de gestión de proyectos (PMO)
Las funciones comúnmente asociadas a la oficina de gestión de proyectos están relacionadas con la coordina-
ción y asistencia de proyectos. Existen muchos tipos de PMO, y la diferencia entre ellas está dada por el grado
de control que ejerce sobre los proyectos.
TIPO DESCRIPCIÓN
PMO de soporte Provee apoyo para la adaptación de metodologías,
estándares y procesos y la utilización de herramientas
específicas, aplicación de políticas y entrenamientos. Nivel
medio de control sobre proyectos.
PMO de control Provee a los gerentes de proyectos con templates,

procedimientos, mejores prácticas e información histórica.
Actúa como un repositorio centralizado de información. Bajo
nivel de control sobre el proyecto.
PMO de dirección Toma el control formal del proyecto y lo administra. Nivel

alto de control.
TOMEN NOTA:
En la organización en la que empecé a trabajar por pri- Más allá del tamaño y la función de una
mera vez como gerente de proyectos, yo era la PMO. Me PMO, lo importante es definir claramen-
encargaba de generar y distribuir los templates para las te su rol y sus responsabilidades dentro de la or-
distintas etapas de los proyectos y daba entrenamiento ganización, documentarlo y comunicarlo formal y
a los equipos de trabajo que usaban esas plantillas. oportunamente.

Ahondemos ahora en las definiciones del estándar respecto de nuestro rol como gerentes de proyectos.
4. El gerente de proyectos
El gerente de proyectos es el recurso asignado por la compañía en el cual recae la responsabilidad de la adminis-
tración del proyecto. Fundamentalmente, deberá aplicar todos sus conocimientos para cumplir los objetivos que le
fueron encomendados.
El PM debe atender y satisfacer las necesidades de las actividades, del equipo y de los individuos. Es también el
nexo entre la estrategia de la compañía y el equipo de trabajo.
Tengamos en cuenta que, como PM, seremos constantemente evaluados por los niveles directivos más altos de
la organización, a través de la medición del rendimiento en el equipo del proyecto y el liderazgo y la influencia que
ejerzamos éste sobre los interesados.
Si bien el conocimiento técnico de las herramientas y técnicas aplicables a

cualquier proyecto es una capacidad fundamental en cualquier gerente de
proyectos, no es suficiente. El PM debe adquirir y desarrollar otras habili-
dades y competencias para ser eficiente haciendo su trabajo, tales como:
Liderazgo, motivación, comunicación, negociación, toma de decisiones y
desarrollo de equipos de trabajo, entre otras.
REALICEMOS LA SIGUIENTE ACTIVIDAD:
Piense cuáles son sus funciones reales como gerente de proyecto. (Si Ud. aún no es gerente de pro-
yectos, pregúntele a quien maneja los proyectos en su empresa).
TOMEN NOTA:
En otras palabras, el PM está capacitado en la teoría de la

administración de proyectos y tiene suficiente experiencia
en manejo de grupos como para ser el responsable absoluto de todo
lo bueno y lo malo que suceda en el proyecto.
No hay mucho más que decir aquí. Los PM debemos asumir esta
responsabilidad y ser muy conscientes de la importancia de obtener
competencias de excelencia.

Les voy a mostrar ahora, mediante un gráfico, unas diferencias que conviene comprender bien:
5. PMO vs. PM
En el siguiente gráfico se pueden ver con claridad los roles y sus diferencias entre el PM y la PMO:
PM PMO
Trabaja sobre los objetivos específicos del Maneja cambios de alcance en los progra-
proyecto mas bajo su órbita. Al tener una visón más
generalista, busca generar oportunidades a
través de los programas
Controla los recursos asignados al proyecto
Optimiza la utilización deecursos
r del programa
Maneja las restricciones del proyecto
(alcance, plazo, costos, calidad, inetersados, Maneja las metodologías y estándares, las
etc) interdependencias entre los proyectos, las
métricas y los procesos
REFLEXIONEMOS:
¿En qué medida es importante obtener una visión más generalista en la administración de proyectos?
Ahora bien, vayamos a una cuestión que siempre me dio que pensar como PM: ¿cuál es la influencia de las or-
ganizaciones en los proyectos?
6.La influencia de las organizaciones en los proyectos
Es evidente que los proyectos son llevados adelante por organizaciones. Dentro de esas organizaciones pode-
mos destacar dos elementos fundamentales: La cultura y la estructura.
La cultura está conformada por las personas que son parte de la organización y se va desarrollando y modifican-
do con el tiempo. Se manifiesta mediante su misión, visión y valores; sus creencias y expectativas; sus procedi-
mientos y políticas; su liderazgo y motivación; su forma de trabajo, autoridad y jerarquía.
La estructura organizacional es un factor fundamental que influye en la conducción de los proyectos. Existen va-
rios tipos de estructuras jerárquicas. Estas estructuras abarcan un amplio espectro, desde las funcionales hasta
las denominadas “proyectizadas”, pasando por diferentes tipos de estructuras matriciales intermedias.
Por eso, es importante realizar un análisis de estas estructuras desde el punto de vista del gerente de proyectos
y su autoridad relativa en cada una de ellas, sencillamente porque es necesario disponer de recursos y controlar
el presupuesto.

Veamos las particularidades de cada una de ellas:
La estructura de organización funcional (la más tradicional) muestra una escala jerárquica. Cada emplea-
do tiene un superior definido. Los niveles jerárquicos están especializados (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. Ge-
neralmente, el gerente de proyectos es un recurso de algún área que trabaja de coordinador o facilitador.
Director
Ventas Ingeniería Legales
Supervisor Supervisor Supervisor
Fuente: PMBOK Fifth Edition
En el otro extremo encontramos 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
En medio de estas dos estructuras organizacionales se encuentra la matricial. Ésta representa

una mezcla entre las estructuras funcionales 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 PM no es más que de coordinación entre las distintas especialidades. En con-
trapartida, en el caso de las estructuras matriciales fuertes, éstas tienen la mayoría de las caracte-
rí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 Supervisor Supervisor

REFLEXIONEMOS:
¿Sabe cuál es el tipo de estructura de organización de su empresa? ¿Sabe cuál es su posición jerárquica en la
organización en la que se desempeña?
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.
Otra cuestión a la que como PM hay que prestarle atención son los factores del contexto organizacional. Veamos
cuáles son:
7. Factores del entorno organizacional
Los proyectos son influenciados por elementos o condiciones externas que no pueden ser controlados por el
equipo de trabajo.
Estos elementos pueden restringir o cambiar al proyecto, limitando o potenciando diferentes alternativas. Los
factores del entorno organizacional pueden ser muy variados y generalmente incluyen:
• La estructura organizacional
• Misión, visión, cultura y valores
• Condiciones del mercado
• Leyes, estándares y regulaciones
• Políticas y procedimientos
• Acceso a recursos y financiamiento
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.
Durante mi carrera profesional, he pasado por distintos tipos de estructuras jerárquicas en las cuales tuve que
liderar proyectos. Sin lugar a duda, las organizaciones de estructura funcional son las menos propicias a gestio-
nar proyectos eficientemente por su apego cultural a respetar la línea de mando sobro cualquier otra forma de
comunicación. Por el contrario, las organizaciones matriciales fuertes me han brindado un espacio más propenso
a la ejecución de proyectos en forma eficaz.

Pasemos ahora a un tema que, como PM, debe darnos lugar a una análisis profundo: los interesados en el proyecto.
8. Los interesados (Stakeholders)
Los interesados son aquellas entidades que tienen algún interés en el proyecto. Pueden ser personas, grupos,
áreas de la empresa u organizaciones completas.
VEAN ESTE EJEMPLO:
¿Quiénes son los interesados? El gerente del proyecto, los gerentes de área, el equi-
po de trabajo, el sponsor, los vendedores, el cliente, los usuarios. La sociedad o el
gobierno pueden ser, en última instancia, identificados como interesados indirecta-
mente afectados por un proyecto.
Los interesados son un factor condicionante muy importante en todo proyecto. Un proyecto puede ser percibido
como algo que tendrá un resultado negativo o positivo para los interesados. En la misma línea, los interesados
pueden ejercer su influencia en forma positiva o negativa durante el desarrollo del proyecto.
Por eso, el equipo debe identificar a todos los inte- TOMEN NOTA:
resados que serán afectados directa o indirectamente
por el resultado del proyecto, con el fin de determinar Es muy común hoy en día que cualquier
con precisión los requerimientos y las expectativas de proyecto industrial que potencialmente
las partes involucradas. De hecho, el gerente de pro- pueda causar la modificación del medioambiente ten-
yectos y su equipo deben manejar e influenciar a los ga interesados que se vean afectados negativamente,
interesados con el fin de cumplir con los objetivos y ya sea por el proceso de ejecución del proyecto o por
obtener un resultado satisfactorio. su resultado.
POR EJEMPLO:
¿Qué significa influenciar a los interesados? Si el gerente de proyecto se da cuenta

de que la definición del alcance del proyecto está incompleta, debe persuadir a los
responsables de este trabajo para que lo completen.
La identificación de los interesados es un proceso cíclico y continuo. Los interesados relevados inicialmente
pueden cambiar sus expectativas a medida que el proyecto avanza y, eventualmente, pueden desaparecer o
aparecer nuevos actores.
La evaluación del grado de influencia sobre los objetivos es un proceso

que transcurre durante todo el ciclo de vida del proyecto. Por esa razón, anali-
zar incorrectamente a los interesados (o directamente no realizar el análisis)
puede afectar al proyecto, causando incremento de los costos o demoras, o
provocando la cancelación del mismo.

Les señalo los pasos que frecuentemente se siguen para la identificación y el análisis de los interesados del proyecto:
Identificar a los Analizar sus Involucrarlos a Satisfacer sus Obetener la

interesados expectativas lo largo de todo necesidades a aceptación del
el ciclo de vida través del producto o
(Quiénes son) (Qué quieren) del proyecto proyecto servicio
generado
Bajo ningún concepto se debe dejar TOMEN NOTA:

de lado el análisis de los interesados
¿Cuán lejos se debería llegar con el análisis de los inte-
del proyecto y sus expectativas.
resados? No hay una fórmula mágica, lo cierto es que es
el gerente de proyectos quien define hasta dónde llega el análisis de
los interesados. No tiene para esto más que su experiencia y la de
su equipo y algunos datos del mercado para decidir cuál es el punto
de corte, o sea, el momento en el cual hay cierta certeza de tener lo
necesario.
VEAN ESTE EJEMPLO:
Dependiendo de la naturaleza del proyecto, los interesados pueden llegar a ser los
habitantes de un pueblo, la sociedad o el gobierno. Imaginemos que estamos traba-
jando 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 expropiables, Vialidad Nacional, el
gobierno nacional y las entidades ecologistas.
REFLEXIONEMOS:
¿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óximo proyecto?
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ía tener menos de 20 tareas.

La administración de proyectos es un trabajo grupal, veamos ahora lo que debemos saber como PM del equipo
del proyecto.
9. El equipo del proyecto
El estándar del PMI define al equipo del proyecto como el grupo de personas que ejecuta el trabajo necesario
para cumplir con los objetivos del proyecto. Los actores principales de un equipo son los siguientes:
• El equipo de dirección del proyecto: conformado por aquellas personas que

realizan tareas relacionadas con la gestión del proyecto (análisis de riesgos, ad-
ministración de las comunicaciones, construcción del cronograma)
• Expertos: Son los individuos que ejecutan las tareas necesarias para desarrollar
el producto del proyecto (ingenieros, obreros, capataces, desarrolladores, espe-
cialistas)
• Usuarios o clientes: Son quienes se encargarán de proveer información sobre

los requerimientos, aceptar el producto desarrollado o validar los resultados ob-
tenidos.
• Personal tercerizado y proveedores de servicios: son aquellos individuos u or-

ganizaciones externas que prestan servicios en un proyecto en particular. El PM
tiene la responsabilidad de supervisar la performance del personal tercerizado
y otros proveedores, además de aceptar los entregables producidos por éstos.
Esta es una clasificación propuesta por el estándar relacionado con la composición de los equipos de trabajo:

Durante más de la mitad de mi vida profesional he tenido que trabajar con equipos distribuidos geográficamente.
Por razones presupuestarias el contacto cotidiano con esas personas de daba vía correo electrónico y chat, y
algunas veces mediante el teléfono y contadas veces mediante videoconferencias. Mi consejo es que es funda-
mental poder asociar una cara con el nombre de quien me envía un e-mail o inicia un chat, por lo que sugiero
hacer el esfuerzo necesario para que una de las primeras comunicaciones en el proyecto se haga mediante
videoconferencia para que el equipo se conozca. Por supuesto que lo óptimo sería poder reunirse todos bajo el
mismo techo, aunque esta forma de conocerse suele ser demasiado cara para la empresa.
Los proyectos no son eternos, sino que tienen ciclos de vida, analicemos esta cuestión.
10. Ciclo de vida del proyecto
Se denomina ciclo de vida del proyecto a la serie de fases por las que se pasan para construir el producto o ser-
vicio. Son un conjunto de pasos predefinidos y secuenciales que se deben seguir.
POR EJEMPLO:
Las fases clásicas del ciclo de vida del desarrollo de proyectos de software son: análi-
sis, diseño, desarrollo, testeo e implementación. Las etapas clásicas del ciclo de vida
de un producto cualquiera en el mercado son: Introducción, crecimiento, madurez,
declinación, retiro del mercado.
Les comento que cualquiera sea el tamaño, la complejidad o la naturaleza de un proyecto, siempre se podrá en-
cuadrar 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 cuando nos comunicamos con otras
personas que no están familiarizadas con los detalles del proyecto. El ciclo de vida puede ser documentado como
una parte de una metodología utilizada.
La estructura genérica del ciclo de vida de proyectos es interesante porque 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 actividades.
VEAN ESTE EJEMPLO:
Pensemos que nuestro proyecto es la construcción del estadio municipal de fútbol. Al comienzo, en las
fases tempranas del ciclo de vida de nuestro proyecto, sólo trabajarán en él algunos ingenieros y arquitec-
tos, definiendo planos, evaluando factibilidades, planificando el trabajo a realizar. A medida que el trabajo
se va definiendo y aprobando, se podrá empezar a incorporar a los obreros que trabajarán en la obra. Pro-
mediando nuestro ciclo de vida, tendremos mucha gente trabajando en paralelo y 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 trabajando.
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).

Inicio del Organización Ejecución del Cierre del

proyecto y programación trabajo proyecto
Nivel de Costos
Acta de Plan de Productos Archivo de los

constitución
Tiempo
gestión del entregables documentos
del proyecto proyecto aceptados del proyecto
Pero existen otros dos 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 disminuyendo progresivamente.
• 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 proyecto. Ahora bien, cualquier cambio
que surja en esta etapa tiene un bajo costo de ejecución, ya que si a una de las autoridades muni-
cipales se le ocurre duplicar la cantidad de asientos en la platea Norte, con sólo modificar el plano
sería suficiente. Pero imagínense qué sucedería si a la misma persona se le ocurre tal modificación
una vez que el estadio está terminado. El costo del cambio sería enorme.
Sepan también que todo proyecto puede ser dividido en varias fases. Cada fase es un conjunto de actividades
lógicamente agrupadas que entregan un resultado específico (entregable). Las fases se van completando en
forma secuencial, aunque es común que se solapen en ciertas circunstancias. Cada fase tiene una duración
determinada y suelen variar entre ellas.
Estructurar un proyecto en fases permite que se segmente en partes más manejables y controlables. La cantidad,
duración y complejidad de las fases depende de la naturaleza del proyecto.
En mi trabajo siempre es fundamental comunicar correctamente en qué fase del el ciclo de vida estamos posicio-
nados. Cualquier interesado que reciba información de parte del equipo de proyecto y que sepa en qué fase nos
encontramos, podrá asignarle un valor relativo a la información que le estamos entregando. En otras palabras, si
estamos en una fase temprana del proyecto, llamémosle análisis preliminar, quienes reciban informes relacio-

nados con fechas de entrega o costos sabrán que es información preliminar, sujeta a cambios y con un margen
de error importante.
Pasemos a otra diferencia que debemos conocer muy bien como PM:
11. La gestión de proyectos vs. 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 requerimientos), el armado o desarrollo de
esas características, las pruebas y la entrega del producto terminado al cliente. En otras palabras, estas metodo-
logí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 desarrollo 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 metodologías utilizadas para el desarrollo del pro-
ducto y la interacción de éstas con el estándar de gestión de proyectos ya que suelen superponerse.
Los procesos orientados a la gestión de proyectos son aplicables 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
PM 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.
Como PM, cada vez que doy inicio a un nuevo proyecto, siempre me ocupo de realizar una pasada mental rápida
por los procesos del estándar para pensar cuáles iban a ser necesarios aplicar y cuáles no, y escribí la decisión en
la documentación para dejar constancia de lo decidido. Si no podía poner en palabras el porqué no iba a utilizar
un proceso particular, quería decir que probablemente para algo lo necesitaba usar.
REFLEXIONEMOS
¿En su empresa se utiliza actualmente alguna metodología de desarrollo de productos o servicios?

El estándar del PMI le da mucha importancia a los procesos y grupos de proceso, veamos cómo entiende y
desarrolla este tema:
12. Grupo de procesos de la administración de

proyectos
Un proceso es un conjunto de acciones y actividades interrelacionadas que se ejecutan con el fin de obtener un
producto, 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. Para que un proyecto tenga éxito, el equipo del proyecto debe seleccionar los procesos
adecuados requeridos para alcanzar los objetivos del proyecto.
Los procesos de dirección de proyectos pueden ser utilizados en cualquier proyecto, cualquiera sea su naturale-
za, mercado o industria. Para un proyecto determinado, el PM en colaboración con el equipo el proyecto, tiene la
responsabilidad de determinar cuáles son los procesos
apropiados, así como el grado de rigor en cuanto a la
utilización adecuada para cada caso. TOMEN NOTA:
Los procesos de dirección de proyectos se agrupan en Los grupos de procesos no son las fa-
cinco categorías conocidas como Grupos de Proce- ses del proyecto.
sos de la Dirección de Proyectos:
Aquellos procesos realizados para definir un nuevo proyecto o nueva fase de un

Grupo de proyecto ya existente, mediante la obtención de la autorización para comenzar
dicho proyecto o fase. Aquí se realiza la definición inicial del alcance, los costos
procesos de
y los recursos necesarios. Se identifican los primeros interesados y se asigna al
iniciación PM. Se crea el acta del proyecto y se alinean las expectativas de los interesados
a carca de lo que se necesita hacer.
Aquellos procesos requeridos para establecer el alcance del proyecto, refinarlos

Grupo de objetivos y definir el curso de acción necesario para alcanzar los objetivos para
procesos de cuyo logro se emprendió el proyecto. En este grupo se desarrolla el plan de
planificación gestión del proyecto que luego se utilizará para llevar a cabo el trabajo
Aquellos procesos realizados para completar el trabajo definido en el plan para

Grupo de la dirección del proyecto a fin de cumplir con las especificaciones del mismo.
procesos de Incluye la coordinación de la gente y los recursos y la integración y ejecución de
ejecución las tareas
Aquellos procesos requeridos para dar seguimiento, analizar y regular el progre-

Grupo de so y el desempeño del proyecto, para identificar áreas en las que el plan requiera
procesos de cambios y para iniciar los cambios correspondientes.
seguimiento y
control
Aquellos procesos realizados para finalizar todas las actividades a través de

todos los grupos de procesos, a fin de cerrar formalmente el proyecto o una fase
Grupo de del mismo. Aquí se obtiene la aceptación formal por parte de los clientes y usua-
procesos de rios, se realizan las revisiones post-mortem, se documentan las lecciones apren-
cierre didas y se actualiza la documentación, que luego se archivará y pasará a formar
parte de la información histórica de los proyectos ejecutados.

POR EJEMPLO
Para las siguientes fases básicas definidas para un proyecto de construcción (estudio
de factibilidad, diseño, construcción, entrega) nótese que los cinco grupos de proce-
sos definidos por el estándar se ejecutan íntegramente por cada una de esas fases.
Estudio de Entrega
Diseño
Diseño Construcción
factibilidad
Iniciación Iniciación Iniciación Iniciación

Planificación Planificación Planificación Planificación
Ejecución Ejecución Ejecución Ejecución
Control Control Control Control
Cierre Cierre Cierre Cierre
Les aseguro que para operar eficientemente con el estándar del PMI es necesario conocer muy bien sus áreas
de conocimiento. Veamos las características básicas de cada una de ellas:
13. Descripción básica de las áreas de conocimiento

del estándar
Existen 47 procesos para la dirección de proyectos identificados en este estándar. Están organizados dentro de
10 áreas de conocimiento. Cada área de conocimiento representa un conjunto de conceptos, términos y activi-
dades comunes que conforman un dominio profesional o área de especialización.
Las áreas de conocimiento 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 administra-
ció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 dura-
ció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
proyecto. 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 entre-
gue al cliente exactamente lo que pidió y de que éste quede satisfecho con el resultado obtenido.
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 res-
puestas para los eventos que podrían afectar los objetivos del proyecto (alcance, plazos, costo,
calidad, 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.
Gestión de los Interesados: Esta área de conocimiento tiene como fin identificar, analizar y
manejar las expectativas de todas las personas u organizaciones que serán impactadas por el
proyecto.
No es menos importante, conocer el formato de los procesos:
14. 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 pueda continuar. Puede ser el resultado de un proceso predecesor.
Herramientas: es algo tangible, como una plantilla (template) o un programa de software. Es uti-
lizada al realizar una actividad para producir un producto o resultado.
Técnicas: es un procedimiento sistemático definido y utilizado por una persona 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 o resultado generado por un proceso. Puede ser un dato inicial para un
proceso sucesor.

A modo de cierre
En este primer capítulo he intentado describir, interpretar y ejemplificar los conceptos básicos que
hacen a los fundamentos de la gestión de proyectos. La base teórica y operativa aquí expuesta
es la que utilizaré ampliamente en los sucesivos capítulos, particularmente en el siguiente, en el
que desarrollo la primera de las áreas de conocimiento del estándar, Integración, cuya importancia
radica en que maneja, supervisa y coordina todo el trabajo realizado en el resto de las áreas de
conocimiento del PMBOK Guide.
Bibliografía consultada
• A guide to the Project Management Book of Knowledge (PMBOK® Guide) Fifth

Edition – PMI 31-12-2012
• The Standard for Program Management® – Second Edition – PMI 31-12-2008.
• The standard for Portfolio Management® – Second Edition – PMI 31-12-2008.

01 - Pm-Fundamentos

Cargado por

Información del documento

Título original

Derechos de autor

Formatos disponibles

Compartir este documento

Compartir o incrustar documentos

Opciones para compartir

¿Le pareció útil este documento?

¿Este contenido es inapropiado?

Copyright:

Formatos disponibles

01 - Pm-Fundamentos

Cargado por

Copyright:

Formatos disponibles

Capítulo 1

Los objetivos son:

Los fundamentos de la gestión de proyectos

Centro de Estudios de Project Management - SCEU UTN BA 5

Veamos el primero de los temas:

La gestión de operaciones se centra en la administración de la producción continua de productos y/o servicios

6 Centro de Estudios de Project Management - SCEU UTN BA

VEAN ESTE EJEMPLO:

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

Les comento que los ESTIMULO EJEMPLO

Los proyectos pueden crear, entre otras cosas

Centro de Estudios de Project Management - SCEU UTN BA 7

2. Administración de proyectos, programas y

La administración La administración La administración

Es la aplicación sistemática de Es la gestión de un grupo de Es la agrupación de proyectos,

VEAN ESTE EJEMPLO:

La administración de proyectos -objetivo TOMEN NOTA:

8 Centro de Estudios de Project Management - SCEU UTN BA

¿Cuál es nuestro objetivo como PM?

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

PMO de control Provee a los gerentes de proyectos con templates,

PMO de dirección Toma el control formal del proyecto y lo administra. Nivel

Centro de Estudios de Project Management - SCEU UTN BA 9

Si bien el conocimiento técnico de las herramientas y técnicas aplicables a

REALICEMOS LA SIGUIENTE ACTIVIDAD:

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

10 Centro de Estudios de Project Management - SCEU UTN BA

6.La influencia de las organizaciones en los proyectos

Centro de Estudios de Project Management - SCEU UTN BA 11

Veamos las particularidades de cada una de ellas:

Ventas Ingeniería Legales

Supervisor Supervisor Supervisor

Fuente: PMBOK Fifth Edition

Proyecto Proyecto Proyecto

Equipo Equipo Equipo

Fuente: PMBOK Fifth Edition

En medio de estas dos estructuras organizacionales se encuentra la matricial. Ésta representa

Proyectos Ingeniería Legales

Fuente: PMBOK Fifth Edition

12 Centro de Estudios de Project Management - SCEU UTN BA

REALICEMOS LA SIGUIENTE ACTIVIDAD:

7. Factores del entorno organizacional

Centro de Estudios de Project Management - SCEU UTN BA 13

8. Los interesados (Stakeholders)

VEAN ESTE EJEMPLO:

¿Qué significa influenciar a los interesados? Si el gerente de proyecto se da cuenta

La evaluación del grado de influencia sobre los objetivos es un proceso

14 Centro de Estudios de Project Management - SCEU UTN BA

Identificar a los Analizar sus Involucrarlos a Satisfacer sus Obetener la

Bajo ningún concepto se debe dejar TOMEN NOTA:

VEAN ESTE EJEMPLO:

REALICEMOS LA SIGUIENTE ACTIVIDAD:

Centro de Estudios de Project Management - SCEU UTN BA 15

9. El equipo del proyecto

• El equipo de dirección del proyecto: conformado por aquellas personas que

• Usuarios o clientes: Son quienes se encargarán de proveer información sobre

• Personal tercerizado y proveedores de servicios: son aquellos individuos u or-

16 Centro de Estudios de Project Management - SCEU UTN BA

10. Ciclo de vida del proyecto

VEAN ESTE EJEMPLO:

Centro de Estudios de Project Management - SCEU UTN BA 17

Inicio del Organización Ejecución del Cierre del

Acta de Plan de Productos Archivo de los