Gestión de Integración y Alcance Parte 2

Suscríbete a DeepL Pro para poder editar este d
Entra en www.DeepL.com/pro para más inform

CAPÍTULO 1 - FUNDAMENTOS 17
La estructura holística y el desglose posterior de cada secció n

del libro en capítulos que cubren un tema específico del conjunto
de actividades Gestió n del Alcance del Proyecto se representa en la
Figura 1-5. El texto en cada rectá ngulo redondeado del diagrama
representa el nombre del capítulo de este libro y también, excepto
en el capítulo Fundamentos, indica los procesos de gestió n de
proyectos relacionados, tal como se identifican en la Guía del
PMBOK®
- Quinta edició n. Para facilitar las referencias cruzadas, las
etiquetas añ adidas en la parte inferior de los rectá ngulos
identifican el Á rea de Conocimiento de gestió n de proyectos
respectiva y el Grupo de Procesos en l a G u í a d e l PMBOK®. Los iconos
se han añ adido como ayuda visual.
Actividad de gestión del alcance del proyecto

La visión holística de la gestión del alcance de los proyectos (incluye la integración)
Iniciar proyectos PDSS M&L Cierre de proyectos

[Planificación, definición, [Managing and Leading]
Fundamentos
alcance y estructuración] (Gestionar y Dirigir) El cierre de
de proyectos la ejecución un proyecto
La Carta del o de una fase
de proyectos
Proyecto PG: Cierre KA:
Planes y documentos de Integración
PG: Iniciación
KA: Integración gestión de proyectos
PG:
Planificación
KA: Integración La dirección y Sección IV
Sección I gestión del trabajo
Requisitos del proyecto realizado en los
PG: Planificación proyectos
KA: Ámbito PG: Ejecución
KA: Integración
El alcance de los proyectos
PG: Planificación
KA: Ámbito
El proyecto Seguimiento y control

Estructura de desglose del del trabajo realizado en
trabajo ( EDT) los proyectos
PG: Planificación PG: Supervisión y control KA:
KA: Ámbito Integración
Sección II
Integración y control de
los cambios que se
producen en los
proyectos
PG: Supervisión y control KA:
Integración
Control y
validación del
alcance de los
proyectos
Alcance
Sección III
Figura 1-5 Estructura de la actividad de gestión del alcance del proyecto

18 DOMINAR LA INTEGRACIÓN Y EL ALCANCE DE LA GESTIÓN DE
PROYECTOS
El punto de vista del PMBOK® sobre la integración

de proyectos y la gestión del alcance
Como se ha señ alado anteriormente en este capítulo, la Guía
del PMBOK® - Quinta Edició n distingue entre los procesos que
clasifica como pertenecientes al Á rea de Conocimiento de
Integració n (Figura 1-6) y las actividades o procesos que clasifica
como pertenecientes al Á rea de Conocimiento de Alcance (Figura
1-7).
En la Figura 1-8 se muestran las diez Á reas de Conocimiento
que implican el concepto completo de Á rea de Conocimiento tal y
como se presenta en la Guía del PMBOK® - Quinta Edició n.
El Área de Conocimiento de Integración de Proyectos del PMBOK

La Figura 1-6 muestra los Grupos de Procesos que constituyen
el Á rea de Conocimiento de gestió n de proyectos necesaria para
asegurar que los procesos de gestió n de proyectos se integran de
acuerdo con la Guía del PMBOK® - Quinta Edició n. Los rectá ngulos
nombran los procesos específicos implicados en el Á rea de
Conocimiento de Integració n de la gestió n de proyectos. El trabajo
realizado en estos seis procesos se lleva a cabo de forma
correspondiente en los pasos, o procesos, de la actividad holística de
Gestió n del Alcance del Proyecto descrita anteriormente.
Los epígrafes Secció n I, Secció n II, Secció n III y Secció n IV
hacen referencia a la secció n de este libro en la que se describen
los distintos procesos como parte de la actividad de gestió n
holística del alcance del proyecto.
La etiqueta en la parte inferior de un rectángulo identifica el
Grupo de Proceso en la Guía del PMBOK® y también el Á rea de
Conocimiento, que, en esta figura, es Integració n en todos los
casos. Como se puede ver en la figura, el Á rea de Conocimiento
Gestió n de la Integració n del Proyecto utiliza un proceso de cada
uno de los cuatro Grupos de Proceso Iniciar, Planificar, Ejecutar y
Cerrar y dos procesos del Grupo de Proceso Seguimiento y
Control.
The PMBOK®Guide-Fifth Edition
edición
Figura 1-6 Área de conocimiento de integración de la Guía del PMBOK - Quinta
Grupos de áreas de conocimiento y
procesos para la gestión de la
integración de proyectos
Grupo de Grupo del Grupo de Supervisión Grupo

Proceso de Proceso de procesos de y Grupo de Proceso de
Iniciación Planificación ejecución Procesos de Cierre
Desarrollar Desarrollar Directa y Control Cerrar
Proyecto Gestión de proyectos Gestion Supervisión y control Proyect
Carta Plan ar el Proyecto de trabajo o o fase
PG: Planificación trabajo PG: Cierre KA:
PG: Iniciación PG: Supervisión y control KA:
KA: Integración KA: Integración del Integración Integración
proyect
Realice
Control de
Sección I Sección II Sección III cambios Sección IV
integrado
Sección III
CAPÍTULO 1 - FUNDAMENTOS
®
19
PROYECTOS
El Área de Conocimiento de Gestión del Alcance del

Proyecto del PMBOK
The PMBOK®Guide - Fifth Edition

Grupos de Áreas de Conocimiento y
Procesos para la Gestión del Alcance
del Proyecto
Grupo del
Proceso de Grupo de procesos de supervisión
Planificación y control
Validar alcance
Planificar la gestión del
alcance PG: Supervisión y control
KA: Ámbito de aplicación
PG: Planificación
KA: Ámbito
Ámbito de
Recopilar requisitos control
Alcance
PG: Planificación
KA: Ámbito
Sección III
Definir el alcance
PG: Planificación
KA: Ámbito
Crear la
EDT
PG: Planificación
KA: Ámbito
Sección II
Figura 1-7 Grupos de procesos en el Área de Conocimiento de Gestión del Alcance del
Proyecto tal y como se describe en la Guía del PMBOK® - Quinta Edición
La Figura 1-7 muestra los Grupos de Procesos que constituyen

el Á rea de Conocimiento de gestió n del proyecto necesaria para
asegurar que el alcance del proyecto se gestiona de acuerdo con la
Guía del PMBOK® - Quinta Edició n. Los rectá ngulos nombran los
procesos específicos involucrados en el Á rea de Conocimiento del
Alcance de la gestió n del proyecto. Los títulos Secció n II y Secció n
III se refieren a la secció n de este libro donde se describen los
diversos procesos como parte de la actividad holística de gestió n del
alcance del proyecto.
La etiqueta en la parte inferior de un rectá ngulo identifica el
Grupo de Procesos en la Guía del PMBOK® y también el Á rea de
Conocimiento del PMBOK®, que, en esta figura, es por supuesto
Alcance en todos los casos. Como puede verse en la figura, el mayor
esfuerzo se dedica a la planificació n. Planificació n

PROYECTOS
implica cuatro procesos, frente a los dos del grupo de procesos

Seguimiento y control. En general, cuantos más procesos de un
grupo de procesos estén implicados, más recursos habrá que
dedicar a este grupo de procesos.
Sin embargo, es concebible, y ha ocurrido, que una sola
actividad de un grupo de procesos requiera más recursos (y
atenció n) que todas las actividades de otro grupo de procesos
juntas. Por ejemplo, en un proyecto pequeñ o o mediano, puede
llevar más tiempo crear un plan de gestió n del alcance y recopilar
los requisitos, ya que las partes interesadas están convencidas de
que saben exactamente lo que quieren. Definir el alcance y crear
una estructura de desglose del trabajo (EDT) podría realizarse
posteriormente en un tiempo relativamente má s corto.
La diversió n y el gasto de cantidades adicionales no planificadas
de recursos comienzan cuando se está ejecutando el proyecto. De
repente, los requisitos empiezan a transformarse poco a poco y
validar y controlar el alcance se convierte en una lucha casi diaria
para el gestor del proyecto o los miembros del equipo asignados a
estas dos tareas. Si el gestor del proyecto tiene suerte, los
interesados reconocen que sus requisitos, que inicialmente creían
firmes y bien definidos, eran en realidad só lo concepciones
aproximadas. Con partes interesadas justas y objetivas como éstas,
el director del proyecto debería ser capaz de terminar el proyecto a
tiempo, con un aumento aceptado de los costes y con la calidad
esperada o, si resulta evidente que esto no es posible, lo más
probable es que se llegue a un acuerdo mutuo sobre una pró rroga.
Si, por el contrario, las partes interesadas insisten en que las
especificaciones que proporcionaron eran y siguen siendo correctas
y precisas, la cualificació n de liderazgo y las habilidades de
comunicació n del director de proyecto se pondrán en entredicho.
El Á rea de Conocimiento de Gestió n del Alcance del PMBOK®
mostrada arriba ilustra que un Á rea de Conocimiento no implica
necesariamente los cinco Grupos de P r o c e s o del PMBOK®. De hecho, la
mayoría de las Á reas de Conocimiento, concretamente cinco,
implican só lo dos Grupos de Proceso, dos Á reas de Conocimiento
implican tres Grupos de Proceso, y otras dos á reas implican cuatro
Grupos de Proceso. La ú nica Á rea de Conocimiento del proyecto
PMBOK®
que implica a los cinco Grupos de Proceso d e l PMBOK® es la de
Integració n. En la Guía del PMBOK® - Quinta Edició n, esta Á rea de
Conocimiento se denomina Á rea de Conocimiento de Gestió n de la
Integració n del Proyecto y es distinta del Á rea de Conocimiento de
Gestió n del Alcance del Proyecto.

PROYECTOS
Esta distinció n es, como se ha descrito anteriormente, en

contraste con el punto de vista holístico de las actividades de
gestió n de proyectos, donde la Actividad de Gestió n del Alcance
incluye, en virtud de ser holística, las subtareas y pasos integradores
(o procesos PMBOK®) que son una parte fundamental de la gestió n de
proyectos.
Las diez áreas de conocimiento de la gestión de proyectos del

PMBOK
Como se indica en el título de este libro y como también se ha

mencionado anteriormente, este libro só lo aborda la actividad de
gestió n relativa a los aspectos de integració n y alcance de la gestió n
de proyectos. El punto de vista holístico adoptado en este libro
conduce a una Actividad de Gestió n del Alcance del Proyecto
holística, que incluye todos los pasos (o procesos) integradores
necesarios para la gestió n de un proyecto. Ademá s, hay otras ocho
actividades de gestió n de proyectos (véase la Figura 1-2). Este
conjunto de nueve actividades de gestió n de proyectos proporciona
las subtareas y pasos (o procesos) para gestionar un proyecto.
Como ya se ha mencionado, desde un punto de vista holístico, la
Guía del PMBOK® - Quinta Edició n describe diez Á reas de
Conocimiento y varios procesos (47 en total) para gestionar un
proyecto. Ocho de las Á reas de Conocimiento del PMBOK®
corresponden al conjunto de ocho actividades holísticas de gestió n
de proyectos, mientras que el Á rea de Conocimiento de Integració n y
el Á rea de Conocimiento de Alcance corresponden conjuntamente a
un "á rea" de actividad holística de gestió n del alcance.
Para facilitar la referencia y la comparació n, la Figura 1-8
muestra las diez Á reas de Conocimiento del PMBOK®, y para cada
Á rea de Conocimiento el nú mero de procesos utilizados en esa área
y de cuántos Grupos de Proceso se seleccionan estos procesos.
Procesos en las áreas de conocimiento del PMBOK®:

Qué se utiliza Dónde
Por las matemáticas, sabemos que las matrices o tablas son
construcciones poderosas para proporcionar claridad. Si
construimos una tabla de Á reas de Conocimiento versus Grupos de
Procesos, podemos hacer observaciones interesantes, que pueden
promover nuestra comprensió n de la conexió n entre las Á reas de

Conocimiento y los Grupos de Procesos de la Guía del PMBOK®.
PROYECTOS
I Gestión de la integración
(6 procesos de 5 PG)
II Gestión del alcance
III Gestión del tiempo
IV Gestión de costes
V Gestión de la calidad
Áreas de conocimiento
de la gestión de
proyectos
VI Gestión de recursos humanos
Guía del PMBOK® - Quinta edición
(10 KA con 47 procesos) (4 procesos de 2 PG)
VII Gestión de las comunicaciones
VIII Gestión de riesgos
IX Gestión de adquisiciones
X Gestión de las partes interesadas
Figura 1-8 Las diez áreas de conocimiento de la Guía del PMBOK® - Quinta edición
La Figura 1-9 muestra Qué nú mero de procesos de cada Grupo

de Procesos se utiliza Dónde en las Á reas de Conocimiento, es decir,
en qué Á rea de Conocimiento. La tabla sirve de ayuda visual para
responder a las preguntas qué-dónde y dónde-qué. Si la situació n
"dó nde debe realizarse el trabajo" es relevante, por ejemplo en el
á rea de Gestió n de Riesgos, la tabla muestra inmediatamente que
la respuesta a la pregunta "qué nú mero y tipo de actividades o
procesos" son necesarios para realizar el trabajo. En este ejemplo,
la respuesta es cinco procesos de planificació n y un proceso de
seguimiento y control. La respuesta a la pregunta inversa es análoga.
Aparte de profundizar en la comprensió n de la r e l a c i ó n
entre las Á reas de Conocimiento y los Grupos de Procesos, que es
uno de los problemas que los lectores noveles tienen con la Guía
del PMBOK®, el examen de la matriz tiene cierta utilidad y beneficio
prácticos. En las grandes organizaciones con varios proyectos, la
vista qué-dónde y dónde-qué podría ayudar a simplificar la
planificació n de recursos.
La columna de la derecha de la tabla de la Figura 1-9 contiene el
porcentaje del nú mero total de procesos necesarios para realizar
el trabajo en cada una de las á reas de conocimiento (o trabajo). La
fila inferior de la tabla contiene el porcentaje del nú mero total de
procesos que corresponde a cada grupo de procesos.
del PMBOK
Figura 1-9 QUÉ procesos se utilizan DÓNDE en las Áreas de Conocimiento de la Guía
PROYECTOS
Áreas de conocimiento Utilización de procesos de grupos de procesos
Proceso Gr. Seguimiento y
Iniciar Planificació Ejecutar Cerrar Total
Área K control. %
n
Gestión de la integración 1 1 1 2 1 6 12.8
Gestión del alcance 4 2 6 12.8
Gestión del tiempo 6 1 7 14.9
Gestión de costes 3 1 4 8.5
Gestión de la calidad 1 1 1 3 6.4
Gestión de RRHH 1 3 4 8.5
Gestión de la comunicación 1 1 1 3 6.4
Gestión de riesgos 5 1 6 12.8
Gestión de adquisiciones 1 1 1 1 4 8.5
CAPÍTULO 1 - FUNDAMENTOS
Gestión de las partes interesadas 1 1 1 1 4 8.5
Total 2 24 8 11 2 47 100.0
% 4.3 51.1 17.0 23.4 4.3 100.0
25
PROYECTOS
El concepto de OPI y cómo podría haber

empezado la gestión de proyectos
IPO significa Input-Process-Output (Entrada-Proceso-Salida).
La estructura fundamental de IPO se ilustra en la Figura 1-10. El
término proceso se refiere a los pasos realizados para transformar
una entrada dada en una salida deseada. El término se ha
establecido en los mundos de los sistemas y los negocios y se utiliza
en este libro para mantener la coherencia con el uso histó rico. Sin
esta reverencia a la historia, una expresió n má s general y flexible
sería el término transformación e IPO se llamaría ITO, es decir,
Entrada-Transformació n-Salida.
Estructura fundamental de la OPI
Entrada Proceso Salida
●
●
● ... ●
Figura 1-10 La estructura fundamental Entrada-Proceso-Salida
El concepto de esta estructura se basa en el sentido comú n.

Siempre que nos encontremos en una situació n determinada,
llamémosla estado original, y queramos pasar a una situació n nueva,
deseada, llamémosla estado objetivo, el sentido comú n y la
experiencia vital nos dicen que hay que realizar algú n tipo de
esfuerzo, o actividad laboral, para hacer posible este paso. El
esfuerzo o actividad laboral consiste en tomar la entrada y
transformarla ("procesarla") en la salida.
Del mismo modo, basá ndonos en el sentido comú n y en la
experiencia de la vida, entendemos que tenemos que proporcionar
alguna entrada al esfuerzo que ejecuta el movimiento desde el
estado original al estado objetivo. También sabemos que ese
movimiento tiene un principio, o punto de partida en el tiempo, y,
posteriormente, también un punto final en el tiempo. Además, dado
que ese movimiento "continú a", o en otras palabras, está "vivo"
durante el periodo de tiempo transcurrido entre el punto inicial y
el punto final, podemos llamar a este periodo la vida del
movimiento. En la Figura 1-11 se representa visualmente todo lo
anterior.
PROYECTOS
Vida
Fin
Estado ? Estado
original objetivo
Entrada ¿Qué hay detrás del? Salida
Puerta
● Verde
●
● ●
Figura 1-11 Concepto básico para pasar de un estado actual a otro nuevo
Si bien la distinció n entre entrada y salida es fácil de comprender,

la pregunta más importante es: ¿qué hay detrás de la puerta verde?
Obviamente, algú n tipo de actividad o incluso varias actividades han
tenido lugar desde que se alcanzó un nuevo estado al final de la
vida del movimiento. O, para expresarlo de un modo má s general,
las actividades que se encuentran detrá s de la puerta verde han
procesado (transformado) la informació n y, en su caso, los datos
y/o productos proporcionados por o en el estado original, para
ofrecer una salida, que constituye el estado objetivo deseado. Ahora
podemos hacer la siguiente observació n sobre lo que ocurre detrá s
de la puerta verde: Un conjunto de actividades toma la entrada
dada y, mediante la ejecució n de una o má s tareas, subtareas o
pasos de la actividad durante un periodo de tiempo, entrega una
salida.
El deseo o la necesidad de pasar de un estado actual a un
nuevo estado considerado de mayor valor surge perió dicamente
en las organizaciones. De hecho, surge con má s frecuencia cuanto
má s tiempo lleva funcionando una organizació n y, también con más
frecuencia, cuanto más grande es la organizació n. Este deseo puede
ser desencadenado por diversas fuentes, como una idea interna, una
necesidad empresarial o un contrato con un agente externo. En este
contexto, el término necesidad empresarial debe entenderse que
incluye las leyes y reglamentos gubernamentales y las fuerzas de un
mercado competitivo.
A lo largo de la historia, posiblemente desde los tiempos de
Cromañ ó n, a juzgar por los dibujos rupestres, el hombre ha
mostrado una tendencia innata a ser eficaz en el trabajo para
satisfacer una necesidad, es decir, "hacer lo correcto", y, al mismo
tiempo, a ser eficiente en ese esfuerzo, es decir
para "hacer las cosas bien". Conscientes, a través de las lecciones

aprendidas de anteriores esfuerzos laborales, de la necesidad de
tener que repetir una serie de pasos o procesos como los descritos
anteriormente, es ló gico que la gente haya tomado nota de los
pasos realizados durante las distintas actividades, que se fijara en
las similitudes y que clasificara los pasos similares en colecciones de
pasos de naturaleza afín. Dado que aú n no se habían descubierto
las bases de datos relacionales ni el almacenamiento en la nube,
estas colecciones probablemente se visualicen mejor como
contenedores (¿podría considerarse esto el origen de los
contenedores Kanban?) hechos de algú n material natural
bioló gicamente cultivado en el que nuestros antepasados colocaron
sus descripciones de los pasos, probablemente en forma de dibujos
sobre piel de animal, símbolos similares al alfabeto en tablillas de
arcilla, rollos de pergamino o papel, una vez que estuvo disponible,
dependiendo de lo atrá s que queramos viajar en la historia.
No hace falta mucha imaginació n para reconocer que la gente
descubrió muy pronto la necesidad de identificar de forma
unívoca estas papeleras si querían ser eficientes y también si querían
formar a otras personas para que fueran capaces de realizar los pasos
de las distintas actividades. El uso de nú meros o nombres
descriptivos para esa identificació n parece natural. A medida que
aumentaba el nú mero de cubos, la gente debió de darse cuenta de
que tenía sentido agrupar cubos con contenidos similares y
colocarlos en cubos aú n mayores, lo que indicaba una relació n
natural entre los cubos más pequeñ os. Por supuesto, los cubos má s
grandes también necesitaban una identificació n descriptiva. Una
vez más, es ló gico que se eligiera una identificació n descriptiva para
indicar que el contenido de cada cubo compartía alguna
característica comú n. Esta característica comú n indicaba el área de
trabajo o actividad en la que el contenido de cada gran contenedor
sería ú til o apropiado.
Ahora, con el conocimiento de qué contenedor grande era el
má s adecuado para una determinada actividad o tipo de trabajo,
las personas podían sacar fá cilmente del contenedor grande los
contenedores pequeñ os con las tareas (o pasos) o procesos de
actividad necesarios y realizar el trabajo para obtener el resultado
requerido o deseado. Así nació , posiblemente, el concepto o punto
de vista de las áreas de trabajo o áreas de actividad con sus pasos o
procesos de trabajo asociados. A su debido tiempo, nuestros
antepasados (siempre hay gente a la que le encanta analizarlo todo de
PROYECTOS
forma cruzada) seguramente se dieron cuenta de que también había

algo en comú n entre los pasos o procesos de trabajo situados en los
contenedores pequeñ os cuando se veían a través de todas las áreas de
trabajo o actividad (los contenedores grandes).
En otras palabras, descubrieron que hay pasos o procesos

relacionados que se realizan en las distintas á reas de actividad y
que pueden agruparse utilizando un punto de vista de actividades
cruzadas. Por supuesto, nuestros antepasados encontraron un
nombre descriptivo para cada uno de estos nuevos grupos de
actividades cruzadas. Y así, podríamos imaginar, se concibió el
concepto de Grupos de Procesos.
Continuando nuestro viaje en el tiempo a través de la historia del
pensamiento de la gestió n de proyectos, podríamos encontrar que,
para garantizar la finalizació n y el éxito del trabajo realizado, la
junta ancestral para la eficiencia en el trabajo elegía a una persona
para supervisar (gestionar) la ejecució n de las actividades laborales.
Con el tiempo, la duració n de las actividades laborales pasó a
denominarse proyecto, el supervisor elegido pasó a denominarse
gestor del proyecto y la duració n de la actividad laboral, vida del
proyecto.
Avancemos hasta los tiempos modernos. La Guía del PMBOK® -
Quinta Edición se refiere a las á reas de actividad laboral (los
grandes contenedores de la historia) como Áreas de Conocimiento
e identifica cinco grupos de procesos que abarcan todas las Á reas
de Conocimiento (todas las actividades laborales). Los pasos o
procesos de trabajo de estos cinco grupos de procesos son la
respuesta a la pregunta anterior: ¿qué hay detrá s de la puerta
verde? En la Figura 1-12 se muestran los cinco grupos de procesos,
junto con representaciones visuales de ejemplos de entrada y
salida.
La Guía PMBOK® - Quinta Edició n también identifica diez Á reas
de Conocimiento, que cubren el espectro de las áreas de trabajo que
surgen durante la vida de un proyecto. Las diez Á reas de
Conocimiento se muestran en la Figura 1-8. Siempre que se vaya a
trabajar en alguna de las diez Á reas de Conocimiento, los Grupos
de Procesos de la Guía del PMBOK® identifican qué pasos o procesos
deben seleccionarse para el trabajo. La selecció n del Grupo de
Procesos y, por tanto, de los pasos o procesos de trabajo viene
determinada por el propó sito particular del trabajo identificado
por el Á rea de Conocimiento. Por ejemplo, si el á rea de trabajo
elegida es la gestió n de costes y, digamos, a una persona se le
asigna la tarea de estimar los costes y a una segunda persona se le
asigna la tarea de controlar los costes, entonces la primera persona
encontrará los pasos de proceso apropiados en el Grupo de Procesos
de Planificació n, mientras que la segunda persona encontrará los
PROYECTOS
pasos de proceso para controlar los costes en el Grupo de Procesos

de Seguimiento y Control.
Proyecto Vida
Fin
Actividad de gestión
Estado Estado
de proyectos
original objetivo
Entrada Procesos Salida

Guía PMBOK® Grupos de procesos
Iniciar
Idea
Entregable
Planifica
Necesidades ción
empresariales
Servicio
Ejecutar
Producto
Supervisión
y control
Contrato
Cerrar
Figura 1-12 Los Grupos de Procesos de la Guía PMBOK® - Quinta Edición en el

concepto Entrada-Proceso-Salida
En la Guía del PMBOK®, quinta edició n, hay 47 pasos o procesos

(las casillas pequeñ as) distribuidos de forma desigual entre los
cinco grupos de procesos (la agrupació n de procesos de actividades
cruzadas). En opinió n del Project Management Institute (PMI), los
47 procesos representan las mejores prácticas actuales
generalmente aceptadas por los profesionales de la gestió n de
proyectos. Las diez Á reas de C o n o c i m i e n t o del PMBOK® se enumeran
en la Fig. 1-8. Para cada Área de Conocimiento, también se enumera
el nú mero de procesos específicos de esa Á rea de Conocimiento y de
cuántos Grupos de Proceso diferentes se han seleccionado estos
procesos.
Para cada proceso, la Guía del PMBOK enumera las entradas,
las herramientas y técnicas que se pueden utilizar, y la salida. La
estructura de entrada-herramientas y técnicas-salida, apoyada por
un breve resumen, se mantiene en la Guía del PMBOK para cada
proceso en cada Á rea de Conocimiento. Esto proporciona a los
directores de proyecto y a los miembros del equipo de proyecto una
referencia fácil de usar de lo que se necesita para trabajar con o
PROYECTOS
en un proceso, qué herramientas o técnicas utilizar y cuál debe ser el

resultado del proceso. Este ú ltimo punto es especialmente ú til para
las partes interesadas que só lo participan ocasionalmente en el
proyecto.
La Figura 1-13 ofrece una representació n visual del concepto
utilizado en la Guía del PMBOK® - Quinta Edició n para representar un
proceso de gestió n de proyectos. El 'XXX' representa cualquiera de
los seis procesos identificados en la Guía del PMBOK® como
necesarios y suficientes para la gestió n del alcance y cualquiera de
los seis procesos necesarios para la gestió n de la integració n del
proyecto, por ejemplo para el proceso Desarrollar Carta del
Proyecto. Los iconos se han añ adido como ayuda visual. Del mismo
modo, las etiquetas en la parte inferior del rectángulo redondeado
se han añ adido para identificar la respectiva Á rea de Conocimiento
de gestió n de proyectos y el Grupo de Procesos en la G u í a del
PMBOK®
.
Figura 1-13 Concepto utilizado en la Guía del PMBOK® - Quinta Edición para representar
cualquier proceso de gestión de proyectos (PMBOK®)
Similitud y diferencia entre el PMBOK® y la visión

holística
¿Difiere el punto de vista holístico de las actividades
implicadas en la gestió n de proyectos del punto de vista del PMBOK®
de las Á reas de Conocimiento y los Grupos de Procesos? El p u n t o
d e v i s t a del PMBOK®
muestra diez áreas de clasificació n en las que
puede encontrar los conocimientos sobre los procesos que le
permitirá n gestionar un proyecto. Ademá s, esta vista también le
indica que existen cinco grupos de clasificació n para estos procesos,
independientemente de dó nde se utilicen. Ciertamente, no está de
má s disponer de estos grupos de procesos, pero ¿realmente
necesita este grupo de clasificació n para gestionar un proyecto?
¿No es necesario y también suficiente saber que necesito estos x

procesos para gestionar una determinada á rea de trabajo de un
PROYECTOS
proyecto? Por ejemplo, si sé qué seis procesos (segú n el PMBOK®) son

necesarios para gestionar el riesgo en un proyecto, ¿no es eso
también suficiente (suponiendo que sepa có mo gestionar y dirigir un
equipo de proyecto)? ¿Me ayudará a gestionar mejor el riesgo del
proyecto saber que uno de los seis procesos necesarios pertenece a
la "familia" de procesos con el nombre de Seguimiento y Control y
que los otros cinco procesos necesarios pertenecen a una familia
llamada Planificació n? A modo de comparació n, si sé qué
competencias necesito que posean los miembros de mi equipo de
proyecto, ¿necesito saber a qué familia pertenecen los miembros del
equipo (sin tener en cuenta los aspectos de administració n de
Recursos Humanos)? Sin embargo, hay una situació n en la que el
conocimiento de esta clasificació n en Grupos de Procesos no só lo es
ú til, sino absolutamente necesario, y es cuando se presenta a un
examen de certificació n de gestió n de proyectos basado en el PMBOK®.
El punto de vista holístico de las actividades implicadas en la
gestió n de proyectos presenta una visió n de nueve á reas de
actividad laboral con un nú mero específico de tareas de actividad
o pasos para cada á rea necesarios y suficientes para gestionar un
proyecto. Una característica positiva del punto de vista holístico es
su objetivo de simplificar al máximo la comprensió n y la práctica de
las actividades de gestió n de proyectos sin sacrificar la profundidad y
la calidad. Se reconoce que no es necesaria una clasificació n
cruzada de las tareas de las actividades correspondiente a la
clasificació n cruzada de los procesos del Grupo de Procesos. En su
lugar, la comprensió n de la gestió n de proyectos se ve reforzada por
el conocimiento de la naturaleza de las tareas de actividad (o
pasos). Algunas tareas de actividad (o pasos) están, por naturaleza,
orientadas al inicio o cierre de un proyecto; otros pasos son de
naturaleza creativa (planificació n, definició n, alcance y
estructuració n, o PDSS); mientras que otros son tareas de
actividad (o pasos) naturales de gestió n y direcció n (M&L). La
naturaleza de las tareas de actividad (o pasos) se muestra
visualmente en la Figura 1-14.
La flecha que vuelve de la naturaleza de las tareas de actividad
de M&L a la naturaleza de las tareas de actividad de PDSS indica
que posiblemente habrá informació n de retroalimentació n
obtenida durante las tareas de actividad de M&L que sea lo
suficientemente influyente como para justificar algú n cambio en los
resultados obtenidos previamente de las tareas de actividad de
PDSS. Por supuesto, el resultado de la tarea inicial influye en las
tareas PDSS. Del mismo modo, las tareas de M&L determinan si y

cuá ndo se puede iniciar la tarea de actividad de cierre.
PROYECTOS
Proyecto Vida
Fin
Actividades de
Estado gestión de Estado
original proyectos objetivo
Entrada Naturaleza de la Salida

actividad Pasos
Iniciar
Idea
PDSS Entregable
Planificació
n
Necesidades Definición
empresariales Alcance Servicio
Estructurac
M&L
Producto
Gestión
de
Regulación y
del Liderazgo
Derecho
contractual
Cerrar
Las flechas indican la influencia
Figura 1-14 Entrada-Actividad-Salida desde el punto de vista holístico de la

gestión de proyectos
Dado que tanto la visió n del PMBOK® como el punto de vista

holístico representan las mejores prácticas actualmente entendidas,
deben ser muy similares; la diferencia es en gran medida didá ctica
y, hasta cierto punto, só lo semá ntica, pero afecta a la facilidad de
comprensió n de la gestió n de proyectos y a la eficacia de la
realizació n del arte y la ciencia de la gestió n de proyectos. Y,
puesto que la Guía del PMBOK® es prá cticamente el estándar
mundial en conocimientos de gestió n de proyectos, es ló gico que la
terminología empleada sea la misma en ambos puntos de vista.
Ademá s, dado que la Guía del PMBOK® ha sido la documentació n de
referencia para la gestió n de proyectos, cualquier texto nuevo sobre
gestió n de proyectos se basa necesariamente en ella o deriva de su
contenido.
El concepto Input-Process-Output, representado visualmente
en las pá ginas anteriores y posteriores, de ver los pasos del
proyecto
se basa en la técnica de documentació n y ayuda al diseñ o para el

análisis estructurado de sistemas HIPO de IBM, de eficacia
probada en los añ os setenta. HIPO son las siglas de Hierarchical
Input-Process-Output (entrada-proceso-salida jerárquica). El
término genérico IPO se sigue utilizando en este libro para
reconocer la herencia histó rica y dar el merecido crédito al
creador, aunque el término tarea de actividad es preferible al
término histó rico proceso en el contexto de la gestió n de proyectos.
La razó n de esta preferencia tiene que ver con la tendencia en
el reconocimiento y uso de la gestión de proyectos, la arquitectura
empresarial y el modelado de procesos de negocio en el mundo
empresarial actual. Cada vez se reconoce más la importancia de una
(buena) gestió n de proyectos y de una arquitectura empresarial
(bien diseñ ada), tanto a nivel nacional como internacional. Al mismo
tiempo, las empresas (y consultorías) se fijan cada vez más en los
procesos empresariales en su bú squeda de mayor eficacia,
eficiencia y crecimiento del volumen de negocio y los beneficios.
Esto significa que el término proceso empieza a aplicarse cada vez
má s en el contexto de los procesos empresariales a gran escala, en
lugar de en conexión con el punto de vista más limitado de un
proyecto singular. Por supuesto, si todas las partes implicadas tienen
un entendimiento comú n de los términos utilizados, probablemente
habrá poco o ningú n lugar para los malentendidos. Pero, ¿alguien se
ha encontrado alguna vez en el mundo real con una situació n en la
que todas las partes implicadas en un proyecto tengan el mismo
entendimiento? Probablemente no, a menos que la Carta del
Proyecto se haya elaborado como se describe en el Capítulo 2.
En los añ os setenta y principios de los ochenta, cuando el
desarrollo de sistemas estructurados y la ingeniería de la
informació n constituían la nueva frontera de la era de la
informació n, el uso de la técnica HIPO era de rigor. La estructura
funcional de un sistema -lo que el sistema debía hacer (entregar,
en la jerga actual)- se representaba visualmente en un organigrama,
que a primera vista parecía un organigrama, pero que en realidad
era una estructura de desglose del alcance del sistema. En él se
especificaba a los desarrolladores lo que se esperaba de sus
mó dulos. Volveremos a encontrarnos con una estructura de este
tipo en el capítulo 6.
Los componentes Input-Process-Output de la HIPO consistían en
una serie de diagramas numerados, comenzando en niveles altos y
descriptivos, que posteriormente se desglosaban mediante un
PROYECTOS
refinamiento escalonado hasta un nivel de

granularidad que permitía al desarrollador producir el có digo

adecuado. Si se mantenía la coherencia, la técnica HIPO producía
el diseñ o del sistema, los mó dulos programados que
implementaban el sistema y una documentació n concurrente. En
aquella época había pocos programas gráficos, por lo que la mayor
parte del trabajo de diseñ o y documentació n tenía que hacerse a
mano. IBM proporcionó una plantilla HIPO (IBM-Form GX20-
1971) que al menos garantizaba la coherencia de los dibujos.
Ademá s, IBM también facilitó una guía de usuario para el diseñ o
HIPO, que figura en la bibliografía.
Algunos términos y conceptos fundamentales

Existen algunos términos y conceptos fundamentales
relacionados con la integració n y el alcance de los proyectos que un
gestor de proyectos no só lo debe conocer, sino también
comprender. Para tener éxito en un entorno organizativo tan
cambiante como el actual, el gestor de proyectos debe conocer estos
términos y ser capaz de utilizarlos correctamente en un contexto
determinado. Ademá s, la experiencia demuestra que, en el mundo
de los proyectos y de la gestió n de proyectos, no es infrecuente la
incomprensió n y, en ocasiones, las concepciones erró neas de estos
términos. Esto es vá lido tanto para los miembros de un equipo de
proyecto como para otras partes interesadas. En los entornos de
proyecto en los que esto ocurre, el director de proyecto se enfrenta
al reto de proporcionar una explicació n convincente de estos
términos y conceptos.
Las explicaciones pueden ser a veces una tarea bastante
delicada, dada la propensió n de la especie humana al autoengañ o
y la negació n. El tratamiento de estas cuestiones exige una gran
capacidad de liderazgo por parte del director del proyecto, sobre
todo si se trata de partes interesadas que pertenecen a la alta
direcció n.
Liderazgo
El liderazgo puede describirse como la funció n de motivar e
inspirar a las personas para que alcancen su rendimiento ó ptimo
dentro de una organizació n y guiar las actividades realizadas por los
miembros de la organizació n para cumplir con la visió n, apoyar la
misió n, alcanzar las metas, cumplir los objetivos y seguir la
PROYECTOS
estrategia de la organizació n, al tiempo que se adhieren a los

valores fundamentales de la organizació n.
organizació n. Robbins y Judge (2007) describen el liderazgo como

"una funció n que incluye motivar a los empleados, dirigir a otros,
seleccionar los canales de comunicació n más eficaces y resolver
conflictos" (p. 5).
El aspecto del liderazgo en la gestió n de proyectos só lo ha
recibido cierta atenció n recientemente. En el pasado, la lista de
requisitos de cualificació n para un gestor de proyectos ha hecho
hincapié, e incluso ahora que estamos en la segunda década del siglo
XXI, en las habilidades en herramientas de software populares por
encima de la cualificació n de liderazgo.
Organización
Una organizació n es la síntesis de personas, conocimientos y
reglamentos -que incluyen leyes- y, como tal, está sujeta a las
fuerzas que afectan a todos los seres vivos. Es decir, una
organizació n es un sistema dinámico.
Una característica de los sistemas diná micos como una
organizació n es la complejidad de los procesos implicados en la
realizació n de las actividades relevantes para el sistema y el gran
nú mero de interacciones entre los procesos y también entre las
actividades.
Para ilustrar la complejidad, si, por ejemplo, en una actividad
intervienen simultáneamente cinco procesos, cada uno de los cuales
interactú a con cada uno de los demás procesos, hay un total de 26
interacciones posibles. En el caso de diez procesos que interactú an,
el nú mero total de interacciones simultá neas posibles asciende a
1.013.
Con el tiempo, las personas de las organizaciones se dieron
cuenta de que era necesario un enfoque organizado y bien
estructurado para hacer frente a esta complejidad a la hora de
emprender nuevas tareas. Esta toma de conciencia dio lugar en los
añ os 50 a un enfoque formalizado denominado gestió n de
proyectos. (Véase también Gestión de proyectos en el Glosario).
Robbins y Judge (2007) definen la organizació n como "una
unidad social conscientemente coordinada, compuesta por dos o
má s personas, que funciona de forma relativamente continua para
alcanzar un objetivo o conjunto de objetivos comunes" (p. 5). Las
organizaciones suelen estructurarse por funciones, por productos
o por una combinació n de ambos. Esta ú ltima forma de
PROYECTOS
organizació n se denomina estructura matricial. Los

departamentos funcionales típicos son contabilidad, ingeniería y
marketing,
etc. A veces incluso se ve una organizació n que se organiza segú n

proyectos. Es lo que se denomina organización por proyectos. Existe
otra forma de organizació n denominada organizació n compuesta.
En este caso, hay una funció n formada por gestores de proyectos
que recurren a personal de otras funciones o departamentos cuando
surge la necesidad. En este caso, el gestor de proyectos se enfrenta a
todo un reto en lo que respecta a la asignació n y disponibilidad de
recursos.
En el contexto de la gestió n de proyectos, podemos simplificar
la definició n anterior de organizació n a una alianza de dos o má s
personas diseñ ada para funcionar de forma continua con el fin de
lograr un conjunto comú n de objetivos. Este concepto de
organizació n incluye la estructura funcional, la estructura nominal
de informes, la estructura real de influencia o poder, la estructura
de comunicació n formal e informal, los activos de proceso, la
cultura, la visió n, la misió n, los objetivos, la estrategia y otros
factores adicionales que suelen formar parte de los factores
ambientales de la empresa. Esta es la forma de organizació n, ya
sea oficial o meramente fáctica, con la que más tiene que tratar un
gestor de proyectos. Y esa es una de las razones por las que un
director de proyecto también debe poseer habilidades de liderazgo,
y no só lo habilidades en herramientas y técnicas.
Proyecto
¿Qué es un proyecto? Un proyecto es cualquier esfuerzo que
sirve a un propó sito, objetivo o meta específicos bajo la restricció n
de tiempo, recursos, objetivos de calidad y alcance definido. El
Project Management Insti- tute (PMI) define un proyecto como "un
esfuerzo temporal emprendido para crear un producto, servicio o
resultado ú nico". La naturaleza temporal de los proyectos indica
que un proyecto tiene un principio y un final definidos" (Project
Management Institute, 2013).
Un proyecto se cierra cuando ha alcanzado el fin de su
propó sito, es decir, cuando ha proporcionado los entregables
especificados en la Carta del Proyecto y detallados con más detalle
en la estructura de desglose del trabajo (EDT). Otra forma de
considerar que se ha llegado al final es cuando se han cumplido los
objetivos del proyecto desde el punto de vista de los principales
interesados o cuando se ha tomado la decisió n voluntaria de poner fin
al proyecto. Esta decisió n puede basarse en el reconocimiento de
PROYECTOS
que los objetivos del proyecto no se alcanzarán o no pueden

alcanzarse, o cuando el propietario del proyecto no desea
continuar con él.
má s largo. El propietario de un proyecto es la persona que aporta

los fondos para el proyecto o la persona designada como propietario
pro forma por el proveedor de los fondos.
Gestión de proyectos
En la década de 1950 se desarrolló un enfoque formalizado de
la gestió n de proyectos (véase también Organizació n en el
Glosario). (Véase también Organización en el Glosario.) Desde
mediados del siglo XX, han aparecido muchas variaciones sobre el
tema de la gestió n de proyectos, algunas de las cuales crearon un
considerable revuelo, mientras que otras se desvanecieron
relativamente rápido y en silencio de la palestra pú blica. Algunos
ejemplos de las variaciones má s persistentes, por orden alfabético,
son la gestió n ágil de proyectos, la gestió n de proyectos en cadena
crítica, la gestió n extrema de proyectos o la gestió n ajustada de
proyectos.
Aunque estas variantes modernas de la gestió n de proyectos
son impresionantes, la popular expectativa inicial de la mayoría de
estas variantes fue, en su mayor parte, el resultado de las potentes
herramientas de software disponibles y, en parte, también se debió
a las ilusiones inherentes a la naturaleza humana. Aunque hay que
reconocer el mérito de todas las mejoras y capacidades modernas,
el nú cleo de la gestió n de proyectos sigue descansando en el
pensamiento creativo y el trabajo de Jules Henri Fayol (1841-
1925) y Henry Laurence Gantt (1861-1919).
A finales de los añ os cincuenta y principios de los sesenta, las
grandes y complejas empresas estadounidenses, tanto militares
como civiles, ampliaron y perfeccionaron la comprensió n de los
conceptos de gestió n de proyectos existentes. El éxito de estos
proyectos y, en especial, el convincente éxito del programa espacial
en la década de 1960 atrajeron la atenció n mundial y generaron la
aceptació n global de la gestió n de proyectos como una disciplina
de gestió n "que no puede prescindir".
¿Qué es la gestió n de proyectos? La definició n y delimitació n del
término gestión de proyectos es má s difícil que la definició n del
término proyecto. El Project Management Institute (PMI) define la
gestión de proyectos como "... la aplicació n de conocimientos,
habilidades, herramientas y técnicas a las actividades del proyecto
para satisfacer los requisitos del mismo" (Project Management
PROYECTOS
Institute, 2013). A continuació n, el PMI afirma que la aplicació n e

integració n adecuadas de los 47 procesos de gestió n de proyectos
descritos en la Guía del PMBOK® - Quinta Edició n
lleva a cabo la gestió n del proyecto. (Véase en la Figura 1-9 la

organizació n de los 47 procesos segú n criterios de clasificació n).
Aunque esta afirmació n especifica correctamente los aspectos
funcionales de la gestió n de las actividades del proyecto, no hace
referencia, al menos explícitamente, al aspecto del liderazgo. Los
proyectos que se gestionan exclusiva o predominantemente segú n
los aspectos funcionales de la gestió n tienen má s probabilidades
de sobrepasar sus presupuestos o plazos, y posiblemente de
experimentar una ampliación del alcance no documentada, que
los proyectos que están bajo la direcció n del liderazgo. El primer
método de gestió n de proyectos se denomina a veces, normalmente
con buen humor, "gestió n por programació n".
El desvío del alcance puede describirse como la expansió n
progresiva no documentada de la línea de base original del alcance
de un proyecto, producto o servicio sin cambios acordados en las
restricciones originales. Se ha comprobado que el desvío del
alcance contribuye en gran medida al fracaso de los proyectos, a la
superació n de costes y plazos y a la falta de objetivos o normas de
calidad. En los capítulos 2 y 10 se aborda con más detalle este tema.
El Deutsches Institut fü r Normung (DIN) define la gestió n de
proyectos como "el conjunto de funciones de liderazgo,
organizació n, técnicas y herramientas para la ejecució n de un
proyecto" (DIN 69901, 2009-1). Aunque sigue siendo bastante
general, esta definició n hace referencia a la funció n de liderazgo de
un gestor de proyectos.
Una definició n preferida de gestió n de proyectos es la
siguiente: La gestió n de proyectos es un conjunto de actividades
de gestió n realizadas en y sobre una organizació n, bajo la direcció n
de una persona designada, para pasar de un estado actual dado a un
estado objetivo definido. Esta definició n implica, en virtud de
"pasar de un estado dado", un comienzo definido (un movimiento
siempre tiene un comienzo) y un final definido, en virtud de cuá ndo
se ha alcanzado el estado objetivo. Incluye explícitamente tanto la
actividad de direcció n como la de gestió n. Se entiende que una
actividad implica una o más tareas de actividad (o pasos). Las
actividades de gestió n de proyectos generalmente aceptadas son el
alcance (que incluye, por la definició n de alcance, las actividades
integradoras), la comunicació n, el coste, los recursos humanos
(RRHH), las adquisiciones, la calidad, el riesgo, las partes
interesadas y las actividades de gestió n del tiempo.
PROYECTOS
La pirámide de las máximas empresariales

Un gestor de proyectos debe conocer y comprender la visió n,
misió n, metas, objetivos y estrategia de una organizació n, así como
sus valores fundamentales. Conocer estos términos y comprender
lo que significan para las partes interesadas ayudará al gestor del
proyecto a comunicarse con ellas.
Un punto importante a tener en cuenta es el (triste) hecho de
que incluso en la alta direcció n no existe un consenso claro sobre
lo que significan estos términos o incluso lo que son para su
organizació n. Una ilustración conmovedora de esta falta de
entendimiento comú n son las acaloradas mesas redondas de altos
directivos que tienen lugar cuando el Director General de una
empresa decide que estos términos deben definirse y publicarse.
Otro aspecto que debe tener en cuenta un director de proyecto
es que la comprensió n y aceptació n de estos términos difiere a
medida que se desciende en la cadena de mando, a pesar incluso
de la prometedora exhibició n de las definiciones escritas. Un jefe de
línea de nivel inferior o una parte interesada puede,
extraoficialmente, por supuesto, pero no por ello menos real, seguir
su propio conjunto de objetivos. A menudo, un director de proyecto
tiene que caminar por una línea muy fina para garantizar el éxito
del proyecto (y, por tanto, también su éxito personal).
La figura 1-15, la Pirá mide de Valores a Visió n, es una
representación visual de las relaciones relativas entre la visió n, la
misió n, las metas, los objetivos, la estrategia y los valores
fundamentales de una organizació n. La definició n de la visió n, la
misió n, las metas, los objetivos y la estrategia de una organizació n
requiere una intensa bú squeda del alma, un análisis detallado del
mercado y un pensamiento crítico. Por lo tanto, se considera que
estas actividades constituyen el ámbito de la planificació n. La
creació n de la estructura de una organizació n, los sistemas de
apoyo, los datos, las herramientas, la documentació n y los recursos
constituyen el ámbito de la implantació n. La base sobre la que se
construyen ambos dominios y de cuya adhesió n continua depende
el éxito a largo plazo de la organizació n son sus valores
fundamentales. La transició n del ámbito de la planificació n al
ámbito de la implementació n se produce cuando una organizació n
toma medidas para implementar su estrategia. En la Figura 1-15, esto
se indica mediante la barra que representa cada dominio y que llega
aproximadamente hasta la mitad del área de Estrategia de la
pirá mide. A continuació n se describen (en orden descendente)

cada una de las á reas de la pirá mide.
PROYECTOS
Figura 1-15 Pirámide de valores a visión
Visión
Una declaració n de visió n describe al pú blico y a sus propios
empleados la visió n que la organización tiene de sí misma, sus
aspiraciones y có mo quiere ser percibida ahora y en el futuro. No
especifica ningú n fin concreto que deba alcanzarse. Las
declaraciones de visió n pueden ir desde una filosofía empresarial
cuidadosamente diseñ ada y redactada hasta una simple
declaració n diseñ ada para proporcionar orientació n y motivació n
a las personas de la organización. La visió n se basa en los valores
fundamentales de la organización y los refleja, y constituye la base
moral y ética de todas las decisiones futuras.
Para que la declaració n de visió n de una organizació n no sea
una mera declaració n esotérica impresa en papel satinado, sino una
guía vivible para tomar decisiones sobre las actividades actuales o
futuras, debe ser comprendida por todos los miembros de la
organizació n. Muchas organizaciones incluyen en su
declaració n de visió n un eslogan altamente motivador que

represente emocionalmente la visió n de la organizació n y sea
fácilmente recordado tanto por las personas de dentro como de
fuera de la organizació n.
Una vez comprendida la visió n de la organizació n, la declaració n
de misió n proporciona los criterios para decidir si un proyecto
propuesto apoya y contribuye a la realizació n de la visió n de la
organizació n, y de qué manera.
Misión
Una declaració n de misió n explica el propó sito estratégico de una
organizació n, su razó n de ser. Describe las acciones que una
organizació n lleva a cabo para alcanzar su visió n. Esboza el "Sinn",
el propó sito psicoló gico, al que se dedican los recursos y acciones
de la organizació n; indica cuál es el enfoque de la organizació n y por
qué. La declaració n de misió n transmite a los empleados y al
pú blico "quiénes somos, qué hacemos, por qué hacemos lo que
hacemos, dó nde o para quién hacemos lo que hacemos". Las
declaraciones de misió n no describen có mo la organizació n lleva a
cabo estas acciones. En otras palabras, las declaraciones de misió n
no abordan los procesos de la organización. Idealmente, una
declaració n de misió n es atemporal.
Las declaraciones de misió n minuciosamente elaboradas
presentan el camino hacia la realizació n de la visió n de la
organizació n. Además, las declaraciones de misió n bien elaboradas
incluyen, o deberían incluir, afirmaciones sobre factores que se
consideran críticos para el cumplimiento de la misió n de la
organizació n. Estos factores suelen denominarse factores críticos
de éxito (FCE).
Al igual que la visió n, la misió n se basa en los valores
fundamentales de la organización y se guía por ellos.
Objetivos
Los objetivos de un proyecto (o de una organizació n)
[prefiguran] el estado final deseado o la capacidad que la
organizació n espera tener o poseer tras la finalizació n del proyecto
(o tras un periodo de tiempo determinado). Los objetivos son las
unidades generales de logro necesarias para cumplir con éxito la
PROYECTOS
misió n del proyecto (o de la organizació n).

A la hora de definir los objetivos de un proyecto, éstos deben

reflejar la necesidad empresarial u organizativa cuya identificació n
ha llevado a la creació n del proyecto. En otras palabras, los
objetivos son el resultado que se quiere conseguir. Como tales,
deben ser creíbles y alcanzables. En relació n con los objetivos, las
metas se establecen a largo plazo.
Al igual que en el caso de la misió n, si el equipo del proyecto o la
direcció n ven algunos problemas o tienen dudas sobre la consecució n
de los objetivos del proyecto, estos problemas o dudas deben
identificarse como factores críticos de éxito (FCE) para el proyecto.
Objetivos
Los objetivos de un proyecto (o de una organizació n) son
elementos específicos y mensurables dentro del á mbito del
proyecto (o del área de negocio de la organizació n). Los elementos
son entregables o un estado del ser, y actividades, que pueden
consistir en una o má s acciones, que apoyan y permiten alcanzar la
meta del proyecto (o las metas de la organizació n). Los objetivos son
pasos cuantificables y temporales necesarios para alcanzar una meta.
En relació n con las metas, los objetivos se establecen a corto plazo.
Con el tiempo, en el trabajo práctico con proyectos ha
cristalizado un eslogan fá cil de recordar y realmente ú til sobre los
objetivos, que puede encontrarse en la mayoría, si no en todos, los
libros sobre gestió n de proyectos. La frase es "Los objetivos deben
ser SMART", donde cada letra de SMART es la primera letra de un
adjetivo que describe una propiedad que deben poseer los objetivos
para ser buenos y ú tiles. Estos adjetivos se muestran en la Figura 1-
16.
Los objetivos deben ser
Específicos Mensurables Alcanzables Realistas Limitados en

el tiempo
Figura 1-16 Objetivos SMART
Algunas escuelas de pensamiento prefieren sustituir el adjetivo

Realista por el adjetivo Relevante para indicar la alineació n con la
visió n, la misió n y los objetivos de una organizació n. Pero se podría
PROYECTOS
argumentar que la relevancia

está implícito a priori. Otros adjetivos que suelen acompañ ar a los

objetivos y que se espera que los cumplan son los siguientes:
• Adecuado
• Aceptable
• Factible
• Flexible
• Motivació n
• Comprensible
Los objetivos deben empezar siempre con un verbo de acció n,

seguido del resultado previsto y la fecha objetivo, como indica esta
fó rmula:
"... el objetivo es [verbo de acció n] [resultado] [fecha

objetivo]".
Una vez definidos, deben presentarse a todas las partes

interesadas para comprobar su claridad y confirmar que son
realmente SMART.
Estrategia
La estrategia es la descripció n de los métodos para alcanzar
los objetivos de una organizació n (o de un proyecto). La estrategia
suele ser a largo plazo. La estrategia de una organizació n puede
influir en el nú mero y la naturaleza de sus proyectos. Por ejemplo,
la estrategia empresarial determina dó nde y có mo la organizació n
llevará a cabo sus actividades, qué capacidades necesitará, qué tipo de
sistemas de informació n necesitará, etc. A su vez, estos factores
influyen de manera significativa en el nú mero y la naturaleza de los
proyectos. A su vez, estos factores influyen notablemente en la
creació n y la gestió n de los proyectos.
Una organizació n también puede tener una estrategia específica
para la gestió n de proyectos. Por ejemplo, la estrategia puede
consistir en recurrir siempre a fuentes externas para ejecutar y
gestionar los proyectos, o recurrir siempre a recursos internos, o
utilizar una combinació n de recursos externos e internos.
Los jefes de proyecto encargados de proyectos pequeñ os y
medianos no suelen estar directamente implicados en la estrategia
de una organizació n, pero deben conocerla y asegurarse de que el
PROYECTOS
proyecto se mantiene en línea con la estrategia general durante su

ejecució n.
Valores fundamentales
Los valores esenciales son los principios y convicciones
fundamentales que constituyen la base ética de una organizació n.
Son la má xima segú n la cual actú a una organizació n. Idealmente,
dicha máxima estaría en el espíritu del imperativo categórico de
Immanuel Kant "Actú o só lo y siempre segú n aquella má xima por
la que puedo al mismo tiempo querer que se convierta en una ley
universal."
Los valores fundamentales son los principios, creencias o
doctrinas que comparten los miembros de una organizació n, los
principios de la organizació n. Los valores fundamentales son
principios atemporales que guían las acciones de los individuos
dentro de la organización. Tienen valores intrínsecos para los
miembros y no necesitan justificació n previa. En principio, son, o
má s bien deberían ser, independientes de la forma en que una
organizació n opera y lleva a cabo sus actividades. Sin embargo, ha
habido ocasiones en las que los valores fundamentales de una
organizació n han cambiado con un cambio en la alta direcció n o en
la propiedad.
Algunas organizaciones añ aden un có digo de conducta a la
descripció n de sus valores fundamentales. Este có digo de conducta
describe el modelo de comportamiento que refleja visiblemente los
valores fundamentales.
Dos elementos empresariales que influyen en

la gestión de proyectos
La Guía del PMBOK® - Quinta Edició n identifica dos elementos
empresariales que influyen en la planificació n y gestió n de
proyectos, los Factores del Entorno Empresarial y los Activos del
Proceso Organizativo. Ambos elementos se utilizan con frecuencia
como entrada a los procesos de las Á reas de Conocimiento del
PMBOK®
.
Los Activos del Proceso Organizativo se utilizan como entrada en
todos los procesos del Á rea de Conocimiento de Gestió n de la
Integració n del Proyecto y los Factores del Entorno de la Empresa se
utilizan en todos los procesos de esa á rea excepto en uno. Los
Activos del Proceso Organizativo se utilizan en cuatro procesos y
los Factores del Entorno Empresarial se utilizan en dos procesos
del Á rea de Conocimiento de Gestió n del Alcance del Proyecto.
PROYECTOS
En las diez Á reas de Conocimiento, los Activos del Proceso

Organizativo se utilizan más de 45 veces y los Factores del Entorno
Empresarial más de 20 veces.
Este uso frecuente subraya la importancia de estos dos elementos y

justifica su inclusió n en el capítulo sobre fundamentos de y para la
gestió n de proyectos. Los dos elementos se muestran en las figuras 1-
17 y 1-18.
Factores del entorno empresarial

Los Factores del Entorno Empresarial incluyen, entre otros, los
contenidos que se muestran (en orden alfabético) en la Figura 1-
17.
Bases de datos comerciales
Canales de comunicación establecidos en la organización Sistemas
de autorización de trabajo de la empresa
Recursos humanos existentes
Distribución geográfica de instalaciones y recursos Normas
gubernamentales o industriales
Empresa Administración de recursos humanos
Medioambiental Infraestructura
Factores
Condiciones del mercado
Cultura, estructura y gobernanza de la organización
Clima político
Conocimientos básicos de gestión de proyectos (Guía

PMBOK®) para el mercado vertical y/o área de interés
Sistemas de información para la gestión de
proyectos Tolerancia al riesgo de las partes
interesadas
Figura 1-17 Factores del entorno empresarial enumerados en la Guía del PMBOK® -
Quinta edición
Activos del proceso organizativo

Los Activos de Proceso Organizativo incluyen, pero no se
limitan a, los contenidos mostrados (en orden alfabético) en la
Figura 1-18. Las etiquetas debajo de los ítems se refieren a los
Grupos de Proceso del PMBOK® en los que se usan los ítems.
PROYECTOS
Cualquier cambio será aprobado y

validado Cumplir las normas de la
organización
Procedimientos de control de se modificará
cambios
Se modificarán los planes
PG: Ejecución, supervisión...
Se modificarán las
políticas
Se modificarán los
Directrices y requisitos de cierre
procedimientos o cualquier
documento del proyecto
PG: Cierre
Procedimientos de control financiero

Directrices y criterios para adaptar los

procesos estándar a las necesidades específicas
de un nuevo proyecto.
PG: Iniciar, planificar
Directrices
Procedimientos de gestión de incidencias y defectos
Procedimie
PG: Ejecución, supervisión y control
ntos
Normas Directrices de comunicación organizativa
Plantillas PG: Ejecución, supervisión y control
Procedimientos de control de riesgos

Activos del proceso PG: Ejecución, supervisión...
organizativo Políticas
Normas organizativas específicas Ciclos de vida de productos y
PG: Iniciar, planificar
proyectos Políticas y procedimientos
de calidad
Normalizado Directrices e instrucciones de

trabajo Criterios de medición de
r e s u l t a d o s Criterios de
evaluación de las propuestas
Plantillas para los distintos planes de gestión de las filiales

PG:
Procedimientos de aprobación, priorización y

autorización de trabajos
PG: Ejecución, supervisión y co...
Bases de conocimientos sobre gestión de la
configuración Bases de datos financieras
Información histórica y bases de

Base de conocimientos conocimientos sobre la
de la empresa experiencia a d q u i r i d a
Bases de datos de gestión de incidencias y
defectos Biblioteca de archivos de proyectos
anteriores
Bases de datos de mediciones de y para procesos y productos
Figura 1-18 Activos del proceso organizativo enumerados en la Guía del PMBOK® - Quinta
edición
Resumen
Los conceptos de proyecto y gestió n de proyectos se
desarrollaron para hacer frente a la cantidad y la naturaleza
repetitiva del trabajo realizado en las organizaciones. Las
organizaciones actú an y se comportan como sistemas dinámicos.
La gestió n de proyectos consiste en una serie de actividades,
que a su vez son conjuntos de tareas, subtareas y pasos. La palabra
proyecto puede entenderse como un término colectivo que designa
el trabajo realizado para pasar de un estado actual (as-is state) a
un estado futuro (to-be state) mediante la transformació n de un
input dado en un output que se ha determinado que tiene un
determinado valor para la organizació n. Por consiguiente, un
proyecto comienza cuando se inicia la transformació n y termina
cuando ésta se completa.
Existen dos visiones de la gestió n de proyectos: la visió n del
PMBOK®
y la visió n holística. La v i s i ó n d e l PMBOK® se basa en el concepto
d e diez á reas de conocimiento y cinco grupos de procesos. La
visió n holística se basa en el concepto de nueve actividades de
gestió n de proyectos que constan de tareas, subtareas y pasos. La
principal diferencia entre las dos visiones es que en la visió n
holística la gestión del alcance del proyecto abarca todo el proyecto,
mientras que la visió n del PMBOK® separa la gestió n del alcance del
proyecto en una gestió n de integració n y una gestió n del alcance
consecuentemente má s pequeñ a.
El concepto Input-Process-Output (IPO) tiene probablemente
su origen en tiempos histó ricos, cuando la gente aprendió por
experiencia a trabajar de forma má s eficiente.
La visió n, la misió n, las metas, los objetivos, la estrategia, la
estructura organizativa, los elementos de apoyo, los recursos y los
valores fundamentales de una organizació n pueden representarse
visualmente en la Pirá mide de los Má ximos Empresariales.
Dos elementos siempre presentes que influyen en los proyectos,
en su gestió n y en la propia organizació n son los factores del entorno
empresarial y los activos de los procesos organizativos.
PROYECTOS
Preguntas de repaso
1. ¿Por qué nuestros antepasados idearon conceptos como el de
gestor de proyectos?
2. ¿Cuál es el requisito previo para la ejecució n del proyecto?
3. ¿En qué consiste el trabajo para ejecutar un proyecto?
4. ¿Podrían considerarse las antiguas papeleras predecesoras
de las papeleras Kanban? En caso afirmativo, explique por
qué.
5. ¿Cuándo puede ser aconsejable clasificar un proyecto como
interrumpido e iniciar uno nuevo?
6. ¿En qué consiste la gestió n de proyectos? (Facilite una lista).
7. ¿Qué se puede hacer si al final del proyecto se percibe la
necesidad de volver atrás?
Esta página se ha dejado en blanco

intencionadamente
2
La Carta del
Proyecto
Objetivos de aprendizaje
Nota: Para apoyar el proceso de aprendizaje y reforzar la
retenció n del contenido del capítulo, los objetivos de aprendizaje no
se enumeran necesariamente en la secuencia del contenido del
capítulo.
Después de haber leído y comprendido el contenido de
este capítulo, deberías ser capaz de:
• Comprender qué aportaciones y qué herramientas y técnicas

utilizan los profesionales para redactar una Carta de
Proyecto.
• Comprender los pasos para el desarrollo de una Carta de
Proyecto.
• Indique dó nde encontrar los elementos clave que definen el
alcance de un proyecto.
• Indique lo que debe establecerse al principio y acordarse.
• Indique qué se necesita para autorizar formalmente un
proyecto.
• Enuncie algunos de los primeros trabajos sobre gestió n de
proyectos.
• Exponga la definició n de PMI de Carta de Proyecto.
• Definir la meta y los objetivos.
• Esbozar la estructura de un proyecto.
• Enumerar el contenido de una Carta de Proyecto SPOR.
• Razone el dilema de la gestió n de proyectos.
• Definir formalmente un proyecto.
• Explique qué debe abarcar el fondo del proyecto.
51

Gestión de Integración y Alcance Parte 2

Cargado por

Información del documento

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

Gestión de Integración y Alcance Parte 2

Cargado por

Copyright:

Formatos disponibles

Suscríbete a DeepL Pro para poder editar este d

Entra en www.DeepL.com/pro para más inform

La estructura holística y el desglose posterior de cada secció n

Actividad de gestión del alcance del proyecto

Iniciar proyectos PDSS M&L Cierre de proyectos

El proyecto Seguimiento y control

Figura 1-5 Estructura de la actividad de gestión del alcance del proyecto

El punto de vista del PMBOK® sobre la integración

El Área de Conocimiento de Integración de Proyectos del PMBOK

Grupo de Grupo del Grupo de Supervisión Grupo

El Área de Conocimiento de Gestión del Alcance del

The PMBOK®Guide - Fifth Edition

La Figura 1-7 muestra los Grupos de Procesos que constituyen

esfuerzo se dedica a la planificació n. Planificació n

implica cuatro procesos, frente a los dos del grupo de procesos

Gestió n del Alcance del Proyecto.

Esta distinció n es, como se ha descrito anteriormente, en

Las diez áreas de conocimiento de la gestión de proyectos del

Como se indica en el título de este libro y como también se ha

Procesos en las áreas de conocimiento del PMBOK®:

promover nuestra comprensió n de la conexió n entre las Á reas de

II Gestión del alcance

III Gestión del tiempo

(10 KA con 47 procesos) (4 procesos de 2 PG)

VII Gestión de las comunicaciones

VIII Gestión de riesgos

X Gestión de las partes interesadas

La Figura 1-9 muestra Qué nú mero de procesos de cada Grupo

Gestión del alcance 4 2 6 12.8

Gestión del tiempo 6 1 7 14.9

Gestión de costes 3 1 4 8.5

Gestión de la calidad 1 1 1 3 6.4

Gestión de RRHH 1 3 4 8.5

Gestión de la comunicación 1 1 1 3 6.4

Gestión de riesgos 5 1 6 12.8

Gestión de adquisiciones 1 1 1 1 4 8.5

% 4.3 51.1 17.0 23.4 4.3 100.0

El concepto de OPI y cómo podría haber

Estructura fundamental de la OPI

Entrada Proceso Salida

El concepto de esta estructura se basa en el sentido comú n.

Entrada ¿Qué hay detrás del? Salida

Si bien la distinció n entre entrada y salida es fácil de comprender,

para "hacer las cosas bien". Conscientes, a través de las lecciones

forma cruzada) seguramente se dieron cuenta de que también había

En otras palabras, descubrieron que hay pasos o procesos

pasos de proceso para controlar los costes en el Grupo de Procesos

Entrada Procesos Salida

Figura 1-12 Los Grupos de Procesos de la Guía PMBOK® - Quinta Edición en el

En la Guía del PMBOK®, quinta edició n, hay 47 pasos o procesos

en un proceso, qué herramientas o técnicas utilizar y cuál debe ser el

Similitud y diferencia entre el PMBOK® y la visión

¿No es necesario y también suficiente saber que necesito estos x

proyecto? Por ejemplo, si sé qué seis procesos (segú n el PMBOK®) son

tareas PDSS. Del mismo modo, las tareas de M&L determinan si y

Entrada Naturaleza de la Salida

Las flechas indican la influencia

Figura 1-14 Entrada-Actividad-Salida desde el punto de vista holístico de la

Dado que tanto la visió n del PMBOK® como el punto de vista

se basa en la técnica de documentació n y ayuda al diseñ o para el

refinamiento escalonado hasta un nivel de

granularidad que permitía al desarrollador producir el có digo

Algunos términos y conceptos fundamentales

estrategia de la organizació n, al tiempo que se adhieren a los