PROJECT MANAGEMENT PROFESSIONAL

ENTORNO DE NEGOCIO
 Project Management Professional – Personas. Entorno de negocio

© Structuralia 2
 Project Management Professional – Personas. Entorno de negocio

ÍNDICE

ÍNDICE........................................................................................................................................................................... 3

1. GESTIÓN DE COMPLIANCE DEL PROYECTO ...................................................................................................... 5

1.1 Registro de riesgos ................................................................................................................................................ 5

1.2 Sistema de gestión de la configuración ................................................................................................................. 6
1.3 Respuestas al riesgo ............................................................................................................................................. 6
1.4 Clasificación de categorías de cumplimiento ......................................................................................................... 7
1.5 Informes de ejecución............................................................................................................................................ 7
1.6 Posibles amenazas al cumplimiento...................................................................................................................... 7
1.7 Requisitos no funcionales ...................................................................................................................................... 8
1.8 Visto bueno y aprobaciones .................................................................................................................................. 9

2. EVALUAR Y ENTREGAR LOS BENEFICIOS Y VALOR DEL PROYECTO .......................................................... 10

2.1 Valor del negocio ................................................................................................................................................. 10

2.2 Plan de gestión de los beneficios ........................................................................................................................ 10
2.3 Revisiones y demostraciones de sprints ............................................................................................................. 11
2.4 Gestión del lanzamiento ...................................................................................................................................... 11
2.5 Análisis de coste-beneficio .................................................................................................................................. 12

3. EVALUAR Y DIRIGIR LOS CAMBIOS EN EL CONTEXTO DEL NEGOCIO QUE IMPACTEN EN EL ALCANCE
..................................................................................................................................................................................... 16

3.1 Entorno empresarial interno ................................................................................................................................ 16

3.2 Entorno empresarial externo ............................................................................................................................... 16
3.3 Actualizar las líneas base .................................................................................................................................... 17
3.4 Comité de control de cambios ............................................................................................................................. 17
3.5 Sistema de gestión de la configuración ............................................................................................................... 18
3.6 Volver a priorizar el trabajo pendiente (backlog) ................................................................................................. 18
3.7 Obligaciones del dueño del producto .................................................................................................................. 19
3.8 Opciones recomendadas para cambios .............................................................................................................. 20
3.9 Hojas de rutas actualizadas................................................................................................................................. 20
3.10 Pautas para evaluar el impacto en el trabajo pendiente (backlog) del proyecto según los cambios en el
entorno empresarial................................................................................................................................................... 21

4. APOYAR EL CAMBIO ORGANIZACIONAL........................................................................................................... 22

4.1 Culturas y estilos organizacionales ..................................................................................................................... 22

4.2 Estructuras organizacionales............................................................................................................................... 23
4.3 Oficina de Dirección de Proyectos (PMO) ........................................................................................................... 23
4.4 Activos de los procesos de la organización (OPA) .............................................................................................. 24
4.5 Factores ambientales de la empresa (EEF) ........................................................................................................ 26

3 © Structuralia
 Project Management Professional – Personas. Entorno de negocio

5. GUÍA PARA INSCRIPCIÓN AL EXAMEN .............................................................................................................. 27

© Structuralia 4
 Project Management Professional – Personas. Entorno de negocio

1. GESTIÓN DE COMPLIANCE DEL PROYECTO

Como parte de la dirección de un proyecto, será necesario mantener la visibilidad de los
requisitos de cumplimiento y garantizar que se gestionen eficazmente a través de todo el
proyecto.

La mayoría de los proyectos tienen aspectos de sus soluciones que están sujetos a
restricciones legales o reglamentarias y, como tales, los requisitos de cumplimiento se
deberán identificar, seguir y gestionar a lo largo del proyecto. Estos pueden incluir
requisitos para prácticas específicas, leyes de privacidad, manejo de información confidencial y
muchas otras áreas.

1.1 Registro de riesgos

Durante el proyecto, se hizo un seguimiento y se gestionaron los riesgos mediante un registro

de riesgos. Algunos de los riesgos a los que se debe hacer seguimiento se relacionan con
requisitos legales y regulatorios, y deben incluir:

▪ El riesgo identificado.
▪ El dueño del riesgo.
▪ El impacto, si ocurre el riesgo.
▪ Las respuestas al riesgo (que podrían contemplar la evasión, transferencia, mitigación y
aceptación del riesgo residual).

Se deben crear planes de prueba y validación adecuados para garantizar que los entregables
del proyecto cumplan con los requisitos de cumplimiento. A medida que se crean los
entregables de un proyecto, se debe garantizar la validación del cumplimiento. Si bien muchos
proyectos realizan una comprobación resumida del cumplimiento al final del proyecto, se
recomienda no esperar hasta entonces, ya que cualquier disparidad identificada puede causar
excesos en el tiempo y en el costo del proyecto. Cuando sea posible, el cumplimiento legal y
regulatorio de todos entregables se debe validar de forma continua a través de todo el
proyecto.

5 © Structuralia
 Project Management Professional – Personas. Entorno de negocio

1.2 Sistema de gestión de la configuración

Se debe dar seguimiento de todos los componentes entregables del proyecto a través de en un
sistema de gestión de la configuración, el cual describe el entregable, los atributos
claves definidos del entregable, y permite el seguimiento, el control de versiones y el
control general. Esta información de la configuración debe someterse junto a los entregables
del proyecto, y el seguimiento continuará en el sistema de gestión de la configuración del
cliente. Uno de los atributos claves a ser monitoreado es la información de cumplimiento,
incluyendo la prueba de validación de cada entregable indicando que cumple con los requisitos
de cumplimiento identificados.

1.3 Respuestas al riesgo

Después de identificar los riesgos y sus posibles impactos, el director del proyecto junto con
otros interesados debe determinar una respuesta adecuada. Las respuestas al riesgo pueden
determinarse de varias maneras, pero en general se pueden agrupar de la siguiente forma:

▪ Evasión: el cliente determina que el nivel de riesgo asociado al entregable es

demasiado alto en relación con el nivel de valor que entregará, por lo que decide
dejarlo fuera del alcance.
▪ Transferencia o intercambio: si el riesgo es un riesgo financiero, el cliente puede
considerar comprar un bono o un seguro a un tercero que asumirá el riesgo
financiero. Como alternativa, los interesados pueden compartir parte del riesgo
financiero.
▪ Mitigación: se pueden adoptar respuestas para reducir su probabilidad, reducir el
impacto que tendría si se cumpliera el riesgo o reducir una posible vulnerabilidad. Si
el riesgo es positivo, también podemos tomar medidas para mejorar potencialmente
nuestra probabilidad de lograr el riesgo positivo y obtener sus beneficios.
▪ Aceptación: una vez que se implementan las respuestas al riesgo, el riesgo
restante se denomina riesgo residual. Este riesgo es el que se acepta y gestiona. Se
deben tomar medidas continuas para seguir gestionando estos riesgos e identificar
respuestas adicionales según sea necesario.

© Structuralia 6
 Project Management Professional – Personas. Entorno de negocio

1.4 Clasificación de categorías de cumplimiento

En relación con las restricciones legales y reglamentarias que una organización o solución en
particular deben cumplir, pueden ser apropiadas diferentes categorías de cumplimiento. Se
pueden necesitar diferentes tipos de categorías de cumplimiento en función del alcance para
una industria y solución particulares. Algunas áreas pueden incluir:

▪ Riesgo para el medioambiente

▪ Salud y seguridad en el lugar de trabajo
▪ Prácticas de corrupción
▪ Responsabilidad social
▪ Calidad
▪ Riesgos del proceso

Las categorías adecuadas para su proyecto podrían ser diferentes según su exposición legal y
regulatoria única.

1.5 Informes de ejecución

Los directores de proyecto entregan regularmente un informe de ejecución relacionado con las
actividades del proyecto, el estado de los entregables y el progreso general. Su informe de
ejecución debe incluir el estado de los riesgos y la gestión de los mismos, incluidos los riesgos
relacionados con el cumplimiento y las medidas adopta1das para gestionarlos. Estos podrían
incluir actividades de prueba y validación, auditorías u otra; acciones para verificar el
cumplimiento de los entregables con cualquier restricción legal o reglamentaria.

1.6 Posibles amenazas al cumplimiento

Existen muchas amenazas potenciales al cumplimiento. Estas podrían incluir:

▪ Identificación de nuevas vulnerabilidades.
▪ Cambios en los requisitos legales o regulatorios.
▪ Errores en las pruebas y la validación para confirmar el cumplimiento.
▪ Errores o fallas en los entregables.
▪ Falta de conocimiento de los requisitos de cumplimiento.

7 © Structuralia
 Project Management Professional – Personas. Entorno de negocio

Los directores de proyecto exitosos deben garantizar que los requisitos de cumplimiento del
proyecto se identifiquen, comuniquen y gestionen continuamente, y que, a medida que se
identifiquen cambios en los requisitos de cumplimiento, se evalúe su impacto y se actualice la
planificación del proyecto para reflejar los cambios.

1.7 Requisitos no funcionales

Las soluciones de negocio tienden a centrarse en los requisitos funcionales, es decir, lo que las
personas necesitan hacer para realizar trabajos utilizando los entregables del proyecto. Sin
embargo, también hay otras consideraciones. Los requisitos no funcionales se usan para
ayudar a estipular el nivel de garantía de servicio de los entregables; en otras palabras, ¿puede
contar con que este producto o servicio será utilizable? Existen muchos tipos de requisitos no
funcionales; algunos pueden incluir:
▪ Disponibilidad: ¿cómo y cuándo está disponible el servicio? Si el servicio no
estuviera disponible, ¿qué tan rápido se puede volver a poner en funcionamiento?
▪ Capacidad: ¿qué nivel de desempeño, velocidad y rendimiento del servicio se
requiere? Dada la cantidad de interesados que utilizan el servicio, ¿hay suficiente
suministro para satisfacer la demanda?
▪ Continuidad: si se produjera algún tipo de desastre, ¿cuán rápido podría
recuperarse el servicio para respaldar las operaciones?
▪ Seguridad: ¿qué grado de protección tienen el servicio y su información contra
riesgos y amenazas de seguridad, y cómo puede garantizar la confidencialidad,
integridad y disponibilidad de la información?
El director del proyecto puede encontrar que ciertos requisitos de cumplimiento se documentan
como no funcionales y por lo tanto, se deben seguir y gestionar para garantizar que la solución
no solo proporcione la funcionalidad esperada, sino también el nivel de garantía necesario.

© Structuralia 8
 Project Management Professional – Personas. Entorno de negocio

1.8 Visto bueno y aprobaciones

Para cada uno de los requisitos de cumplimiento, se deberán identificar a los

interesados necesarios que aprueben que la solución, y los diferentes entregables
dentro de ella, cumplen con los requisitos de cumplimiento. Esta puede ser una lista muy
larga, según el tipo de proyecto y el alcance de las aprobaciones necesarias.
Mientras que muchas de estas aprobaciones pueden no ser posibles hasta poco antes de la
finalización del proyecto, muchas otras pueden estar sujetas a pruebas y validación continuas
durante el proyecto. Esto puede ser muy útil, ya que proporcionará una advertencia temprana
de posibles amenazas al cumplimiento, permitirá capturar las variaciones y determinará un
curso de acción adecuado para solucionar el incidente antes de que afecte el plazo del
proyecto, cause excesos de costos o cree riesgos importantes para el proyecto.

9 © Structuralia
 Project Management Professional – Personas. Entorno de negocio

2. EVALUAR Y ENTREGAR LOS BENEFICIOS Y VALOR DEL

PROYECTO
Se realiza un proyecto para cumplir con los objetivos y requisitos de los interesados y el
director del proyecto es responsable de entregar lo que los interesados esperan. Hay una serie
de herramientas disponibles para ayudar al director del proyecto y a su equipo.

2.1 Valor del negocio

El valor del negocio es un término informal que va más allá del valor económico. Los
componentes del valor del negocio incluyen:

▪ Valor para los accionistas: en una empresa que cotiza en la bolsa, la parte de la
capitalización que es capital frente a la deuda; por ejemplo, la cantidad de acciones
pendientes multiplicada por el precio actual de las acciones.

▪ Valor para el cliente: el valor que recibe el cliente de un producto o servicio.

▪ Conocimiento de los empleados: un activo del negocio, un componente que suele

pasarse por alto en el valor del negocio.

▪ Valor para los socios de canal: el valor para los socios de un negocio.

El análisis de valor es el proceso de examinar cada uno de los componentes del valor del
negocio y comprender el costo de cada uno. El objetivo es mejorar de manera rentable los
componentes para aumentar el valor del negocio general.

2.2 Plan de gestión de los beneficios

Un plan de gestión de beneficios es un documento que describe cómo y cuándo se derivarán y

medirán los beneficios de un proyecto. Comúnmente, incluye los siguientes componentes:

▪ Beneficios objetivo: el valor del negocio tangible e intangible esperado que se

obtendrá del proyecto.

▪ Alineación estratégica: cómo se alinean los beneficios con las estrategias de

negocio de la organización.

© Structuralia 10
 Project Management Professional – Personas. Entorno de negocio

▪ Plazo: cuándo se obtendrán los beneficios (a corto y largo plazo), generalmente, por
fase del proyecto.

▪ Propietario de los beneficios: la persona o el grupo que monitoriza, registra e

informa los beneficios.

▪ Métricas: las mediciones directas e indirectas de los beneficios obtenidos.

▪ Riesgos: los riesgos asociados al logro de los beneficios objetivo.

Este plan se prepara antes de que se inicie el proyecto y se consulta una vez que se haya
completado el proyecto. No es un componente complementario del plan para la dirección del
proyecto, sino un documento del negocio.

2.3 Revisiones y demostraciones de sprints

En un proyecto ágil, al final de cada iteración o sprint, el equipo recibirá a otros interesados y
realizará una revisión o demostración de sprint. Parte del propósito de los enfoques ágiles es
que el equipo se enfoque en completar historias completas de usuarios en cada sprint; en otras
palabras, está todo hecho y la capacidad es "potencialmente listo para enviar".

En una etapa anterior, el equipo desea obtener la aceptación de la historia por parte del dueño
del producto, ya que debe cumplir con todos los criterios de aceptación definidos y recibir
retroalimentación en forma temprana de otros interesados, que pueden comenzar a encontrar
cambios o requisitos adicionales no definidos. Entonces, la revisión de sprint se utiliza para
revisar el progreso del producto en general, y para obtener retroalimentación en forma
temprana mientras aún es pertinente si ciertos aspectos de la solución necesitan cambiarse o
mejorarse de determinadas maneras para optimizar el valor del negocio.

2.4 Gestión del lanzamiento

Uno de los beneficios fundamentales de los proyectos ágiles es la capacidad de

convertir las capacidades de alto valor en soluciones que se entregan en forma
temprana. Parte del trabajo del dueño del producto en un proyecto ágil es definir las
capacidades iniciales que componen un producto mínimo viable; en resumen, suficientes
soluciones para empezar a usarlo, y comenzar a generar valor real para el negocio y
retroalimentación real para los equipos.

11 © Structuralia
 Project Management Professional – Personas. Entorno de negocio

En un proyecto tradicional, el lanzamiento ocurre al final, cuando está todo hecho. En términos
prácticos, casi todas las soluciones tienen un ciclo de vida continuo, por lo que la idea de que
una solución esté terminada para siempre es, en gran medida, un espejismo. Los enfoques
ágiles reconocen esto y, en cambio, lo sustituyen por la noción de incremento mínimo de
negocios (i\1BI). Este MBI ofrece suficientes aspectos de alto valor de la solución para
comenzar a utilizarla y obtener beneficios de ella. Luego, se puede definir un enfoque para los
lanzamientos posteriores de la solución, lo que puede ser impulsado por lo siguiente:

▪ Disponibilidad de un determinado conjunto de características o capacidades.

▪ Tolerancia de la organización a los cambios.

▪ Una cadencia de tiempo que especifica que los lanzamientos posteriores se

planifican siguiendo un cronograma sistemático, por ejemplo, uno por mes.

2.5 Análisis de coste-beneficio

El análisis coste-beneficio es un enfoque sistemático para estimar las fortalezas y debilidades

de las alternativas utilizadas para determinar las opciones que proporcionan el mejor enfoque
para lograr beneficios, a la vez que preservan ahorros. Con frecuencia, se utiliza para comparar
posibles proyectos con el fin de determinar cuál autorizar y para comparar enfoques
alternativos para el alcance.

El objetivo en un análisis costo-beneficio es seleccionar la alternativa cuyos beneficios

superan los costos en mayor cantidad. Nunca se debe elegir una alternativa cuyo costo
exceda el beneficio. El valor de un análisis costo-beneficio depende de la exactitud de las
estimaciones de costo y beneficio.

2.5.1. Retorno sobre la inversión (RSI)

El Retorno sobre la inversión (RSI) es una métrica financiera de rentabilidad que mide la
ganancia o pérdida de una inversión en relación con la cantidad de dinero invertido. A
veces, se denomina tasa de retomo y, comúnmente, se expresa como un porcentaje. Un RSI
positivo se interpreta como una buena inversión y un RSI negativo es una mala inversión.

© Structuralia 12
 Project Management Professional – Personas. Entorno de negocio

2.5.2. Valor actual (PV)

El valor actual (PV) es el valor actual de una suma de dinero de flujos de caja futuros con
una tasa de retorno específica determinada. Otra manera de pensarlo es el valor de algo al
día de hoy que se necesita para crear una cierta cantidad de dinero en el futuro a una tasa de
interés específica.

2.5.3. Valor actual neto (NPV)

El valor actual neto (NPV) es una herramienta financiera que se usa en la presupuestación de
capital. Es el valor en el presente de todos los flujos de efectivo salientes menos el valor
en el presente de todos los flujos de efectivo entrantes. El valor presente neto compara el
valor de un dólar hoy con el valor del mismo dólar en el futuro, después de considerar la
inflación y la tasa de descuento.

2.5.4. Tasa interna de retorno (IRR)

La tasa interna de retorno (IRR) también es una herramienta financiera que se utiliza a menudo
en la presupuestación de capital. Es la tasa de interés que hace que el valor presente neto
de todos los flujos de efectivo sea igual a cero.

2.5.5. Pruebas AB

Muchas veces, hay disponibles enfoques diferentes para resolver un problema y el equipo del
proyecto puede querer recibir retroalimentación de usuarios reales. Esto podría significar
preguntar por las preferencias de los usuarios sobre cómo hacer ciertas cosas o qué enfoque
prefieren. Por ejemplo, distintos enfoques podrían generar diferentes resultados, como
proporción de clics o conversiones de ventas.

Una forma de hacer esto, tomado del universo de marketing, se denomina pruebas AB. En las
pruebas AB, se muestran servicios similares a diferentes conjuntos de usuarios con una
diferencia conocida como variable independiente.

13 © Structuralia
 Project Management Professional – Personas. Entorno de negocio

Por ejemplo, puede cambiar el color o la posición de un botón en un sitio web para ver si las
personas se comportan de manera diferente según las opciones. Como resultado de las
pruebas AB, puede optimizar la solución para utilizar el enfoque más eficaz según los
resultados del experimento.

2.5.6. Simulación Monte Carlo

La simulación Monte Carlo es una técnica de análisis en la que un modelo informático se

itera muchas veces y los valores de entrada se seleccionan aleatoriamente para cada
iteración accionada por los datos de entrada, que incluyen distribuciones de
probabilidades y ramas probabilísticas. Se generan salidas para representar la gama de
posibles resultados del proyecto.

En términos más generales de negocios, Monte Carlo no se refiere a un único método de

análisis, sino a una amplia clase de técnicas que utilizan principalmente computadoras
sofisticadas y entradas de números, probabilidades y algoritmos aleatorios. Tiene una amplia
gama de aplicaciones en muchos campos, incluidas las áreas de finanzas e ingeniería, ya que
funciona eficazmente con grandes entradas de números. Se adapta bien a problemas de
dirección de proyectos complejos en los que se desconocen algunas entradas tales como
costos, actividad y duración.

2.5.7. Análisis mediante árbol de decisiones

El análisis mediante árbol de decisiones es una técnica de cálculo y diagramación que

sirve para evaluar las consecuencias de una cadena de varias opciones en presencia de
dudas. Los árboles de decisiones les permiten a los encargados de tomar decisiones evaluar
la probabilidad y el impacto de cada rama de todas las decisiones que se deben considerar, lo
que los convierte en una herramienta útil para el análisis de riesgos. Cuando se resuelve el
árbol de decisiones se indica la decisión que proporcionará el mayor valor esperado en el
momento de cuantificar todas las implicaciones, las recompensas, las decisiones subsecuentes
y los costos inciertos.

© Structuralia 14
 Project Management Professional – Personas. Entorno de negocio

2.5.8. Valor monetario esperado

El valor monetario esperado (EMV) es un método para calcular el resultado promedio cuando el
futuro es incierto. Las oportunidades tendrán valores positivos y las amenazas valores
negativos. El EMV se puede encontrar multiplicando el valor monetario de un posible
resultado por la probabilidad de que ocurra. Esto se debe hacer con todos los resultados
posibles y sus cifras se suman. El resultado de la suma es el EMV para esa situación.

Esta técnica se utiliza en el análisis mediante árbol de decisiones; el EMV se debe calcular
para que el análisis tenga el mejor resultado. El mejor resultado es el que tiene como resultado
la mayor cantidad de ganancia neta o la menor cantidad de pérdida neta.

15 © Structuralia
 Project Management Professional – Personas. Entorno de negocio

3. EVALUAR Y DIRIGIR LOS CAMBIOS EN EL CONTEXTO DEL

NEGOCIO QUE IMPACTEN EN EL ALCANCE
Los proyectos no existen en el vacío. A medida que el proyecto comienza y avanza, se
producen cambios en el entorno de negocio interno y externo que pueden afectar el valor del
proyecto y el alcance o el trabajo pendiente deseados.

3.1 Entorno empresarial interno

Los cambios en la organización pueden afectar drásticamente el alcance de un proyecto.

Pueden cambiar las estructuras, los roles, las responsabilidades y los flujos de trabajo de la
organización, y la forma en que ciertos aspectos de los entregables del proyecto todavía tienen
sentido en el contexto empresarial. A medida que el proyecto avanza, el director de proyecto y
otros interesados clave del proyecto, como el patrocinador del proyecto, deben tener visibilidad
de los planes de negocio, las reorganizaciones, los cambios en los procesos y otras actividades
empresariales internas que puedan afectar el caso de negocio del proyecto. Estos cambios
empresariales internos pueden crear la necesidad de nuevos entregables, la redefinición de las
prioridades existentes o la eliminación de aquello que ya no es necesario.

3.2 Entorno empresarial externo

De la misma manera en que los posibles cambios internos en el entorno de negocio pueden
afectar el valor del proyecto, los factores externos también pueden afectar su valor y los
resultados deseados. Muchos marcos de referencia de mejores prácticas se refieren a estos
como factores PESTLE. Es fundamental que los directores de proyectos tengan en cuenta los
factores PESTLE que pueden afectar el caso de negocio de su proyecto y que estén
preparados para adaptarse a las circunstancias.

Los factores PESTLE se describen a continuación:

▪ Político: Los cambios en el panorama político pueden afectar las políticas

gubernamentales, los modelos financieros y la viabilidad de ciertas estrategias de
negocios.

© Structuralia 16
 Project Management Professional – Personas. Entorno de negocio

▪ Económico: Los cambios en las condiciones económicas pueden afectar el modelo

de ROI de un proyecto, la conveniencia de ciertas soluciones e incluso los
supuestos más básicos de la viabilidad del proyecto.

▪ Social: Los cambios en los comportamientos sociales, las normas y las acciones
pueden afectar la percepción y la conveniencia del proyecto.

▪ Tecnológico: Los cambios en las capacidades técnicas pueden facilitar nuevos

enfoques para solucionar los problemas empresariales, y pueden alterar tanto la
viabilidad de los proyectos como el enfoque que la organización puede utilizar para
habilitar soluciones.

▪ Legal: Los cambios en los requisitos legales y regulatorios pueden alterar

fundamentalmente lo que se necesita para que los productos del proyecto satisfagan
los requisitos de cumplimiento y pueden aumentar los costos, reducir los beneficios,
o ambos.

▪ Ambiental: Cada vez más, se está pidiendo a las empresas que, como parte de sus
prácticas de responsabilidad social, consideren el impacto ambiental de sus
soluciones y, en muchos casos, que alteren sus enfoques de una manera que
mejore la sostenibilidad del medioambiente.

3.3 Actualizar las líneas base

En un plan de proyecto tradicional, una vez finalizado el plan inicial, este se usa como
línea base. Esto anticipa que se necesitarán varios cambios durante el ciclo de vida del
proyecto y que la línea base se deberá actualizar a medida que se produzcan los
cambios. Mientras el director del proyecto realiza un seguimiento de los cambios; en los
entornos empresariales interno y externo, es probable que se identifiquen cambios necesarios
en el proyecto y que se establezca una nueva línea base.

3.4 Comité de control de cambios

El proyecto debe utilizar un plan de gestión de cambios para realizar un seguimiento y

gestionar los cambios solicitados.
Cuando se solicita un cambio en el proyecto, el enfoque habitual es formar un comité de
control de cambios (CCB).

17 © Structuralia
 Project Management Professional – Personas. Entorno de negocio

El propósito de la herramienta CCB es representar a los principales interesados y evaluar el

cambio en términos de costo, riesgo e impacto en el valor y luego hacer recomendaciones
sobre si se debe aprobar el cambio. Basado en el alcance del cambio propuesto, el aprobador
puede ser el director del proyecto si el alcance del cambio se encuentra dentro de las
tolerancias acordadas, o podría ser escalado al comité del proyecto o al patrocinador si
estuviese fuera de los umbrales de tolerancia.

3.5 Sistema de gestión de la configuración

El sistema de gestión de la configuración es una colección de procedimientos que se utilizan

para hacer un seguimiento de los artefactos del proyecto y para monitorear y controlar los
cambios en estos artefactos. En general, los cambios en un proyecto dan como resultado
actualizaciones en el sistema de gestión de la configuración. El sistema de gestión de la
configuración tiene por objeto mantener un historial de cambios de todos los componentes de
los que se realiza el seguimiento.
Esto permite mantener el control de las versiones de todos los componentes.

3.6 Volver a priorizar el trabajo pendiente (backlog)

En un proyecto ágil, la introducción de cambios o la repriorización de los entregables

existentes se puede gestionar con mayor facilidad mediante el uso del trabajo pendiente
asociado al producto. Los nuevos cambios se escriben como nuevas historias de usuarios y
el dueño del producto tiene la tarea de identificar y priorizar las nuevas historias junto con las
existentes en el registro de trabajos pendientes. Si los cambios tienen un valor del negocio lo
suficientemente alto, pueden pasar directamente al tope de la lista o integrarse más abajo si el
valor o riesgo relativos son menores.

© Structuralia 18
 Project Management Professional – Personas. Entorno de negocio

3.7 Obligaciones del dueño del producto

En un proyecto ágil, el rol del dueño del producto es ayudar al equipo del proyecto a
priorizar el trabajo en función del valor que la capacidad proporcionará al negocio. El
dueño del producto es responsable del valor del negocio final de la solución que produce el
equipo del proyecto. El dueño del producto crea y socializa la visión del producto y sirve para
coordinar las diferentes necesidades del negocio de distintos interesados en un registro de
trabajos pendientes priorizado asociado al producto.
El dueño del producto es responsable de definir y priorizar las historias de usuarios en el
registro de trabajos pendientes asociado al producto. Esto debe reflejar el mayor valor (y
riesgo) del negocio primero, con las historias de menor valor al final. A medida que el proyecto
avanza, el dueño del producto continúa proporcionando orientación al equipo sobre la
priorización de las historias, define los criterios de aceptación (a menudo con la ayuda de los
equipos) y acepta historias a medida que se completan y se entregan.
Los otros roles clave para el dueño del producto son responder preguntas del equipo acerca de
la solución necesaria y proporcionar retroalimentación oportuna al equipo sobre posibles
enfoques de solución.

19 © Structuralia
 Project Management Professional – Personas. Entorno de negocio

3.8 Opciones recomendadas para cambios

Cuando se propone un cambio, el enfoque del dueño del producto debe centrarse en el valor
del negocio previsto del cambio. Sujetas a modificación, las historias de usuarios (ya sea para
requisitos iniciales o para cambios) utilizan el siguiente patrón: "Como nombre del rol, quiero
hacer algo para obtener el resultado que quiero".
Observe que el enfoque de la historia del usuario se centra en el interesado, la necesidad y el
resultado deseado, y no en un enfoque en la solución particular. En general, es una buena
práctica darle discreción al equipo del proyecto para considerar el cambio e identificar
posibles opciones de solución. Luego, el equipo puede examinar las opciones con el
dueño del producto para crear un enfoque acordado.

3.9 Hojas de rutas actualizadas

Los mapas de rutas se utilizan para proporcionar visibilidad de alto nivel del proyecto en
general, los entregables principales, las fechas inmutables del proyecto y cómo y
cuándo podrían estar disponibles ciertas capacidades, al menos en un producto mínimo
viable. Hay que tener en cuenta que el objetivo de una hoja de ruta no es ser tan detallada
como un plan de proyecto tradicional, que incluye cronogramas detallados, paquetes de trabajo
y plazos que se extienden por un año o más.
En cambio, una hoja de ruta eficaz es de alto nivel, garantiza que todos los interesados
conozcan claramente las necesidades clave de alto nivel y las fechas de los hitos, pero no
proporciona el nivel de detalles granular sobre cuándo exactamente se llevarán a cabo ciertas
funciones, ya que, probablemente, esto cambiará a medida que el dueño del producto agregue
y vuelva a priorizar las necesidades durante el ciclo de vida del proyecto.
A medida que el proyecto avanza, la hoja de ruta se debe actualizar, por lo general, todos los
meses. La hoja de ruta reflejará los cambios realizados al registro de trabajos pendientes, ya
sea agregando nuevas capacidades deseadas o volviendo a priorizar las existentes según las
necesidades cambiantes del negocio. Este proceso iterativo continuo garantiza que el equipo
del proyecto trabaje siempre con los elementos de mayor valor, entregue los componentes de
mayor valor de la solución primero, permite entregar los elementos de alto valor de forma
temprana y genera retroalimentación que ayudará al equipo y al dueño del producto a descubrir
necesidades adicionales.

© Structuralia 20
 Project Management Professional – Personas. Entorno de negocio

3.10 Pautas para evaluar el impacto en el trabajo pendiente (backlog) del

proyecto según los cambios en el entorno empresarial

Normalmente, los proyectos se ven afectados por grandes cambios en el entorno empresarial,
ya sea de manera interna o externa. El director del proyecto debe contar con un amplio
conocimiento de los posibles impactos de estos cambios comerciales y la manera en que
afectan el valor y el caso general del negocio de los proyectos que se están gestionando. A
continuación, aparecen algunas pautas básicas.
▪ Comprender el contexto organizacional del proyecto. ¿Qué organizaciones utilizarán
la solución?
▪ ¿Cómo funciona el flujo de trabajo general? ¿Qué roles y responsabilidades
definidas existen para apoyar el flujo de trabajo? ¿Cómo podrían afectarlos las
actividades comerciales internas, como una reorganización?
▪ Comprender los factores externos que pueden afectar su proyecto. ¿Existen riesgos
o problemas políticos? ¿Cuál sería el impacto económico de una recesión en la
propuesta de valor del proyecto? ¿Qué innovaciones técnicas podrían afectar el
enfoque de la solución? ¿Qué tipos de cambios reglamentarios o legales se están
considerando en la ciudad, estado o país que podrían afectar la solución?
▪ ¿Cómo se prioriza el trabajo del proyecto? Si se está ejecutando un proyecto ágil,
¿los trabajos pendientes (backlogs) se revisan y perfeccionan regularmente para
reflejar las prioridades comerciales actuales? ¿Se cuenta con un dueño del producto
involucrado que se asegure de que el trabajo pendiente (backlog) sea correcto y que
esté disponible para responder las preguntas del equipo a fin de ayudar a los
miembros a mantenerse en el camino correcto?
▪ ¿Cuál es el modelo de gobernanza del proyecto? ¿Cuáles son los niveles de
tolerancia que se delegan al director del proyecto y qué incidentes se deben escalar
al comité de dirección o gobernanza?

21 © Structuralia
 Project Management Professional – Personas. Entorno de negocio

4. APOYAR EL CAMBIO ORGANIZACIONAL

Los proyectos y la dirección de proyectos se llevan a cabo en un entorno más amplio que el del
proyecto en sí, y la cultura, el estilo y la estructura de una organización influyen en la manera
en que se realizan los proyectos. Comprender este contexto más amplio ayuda a garantizar
que el trabajo se realice de acuerdo con las metas de la. organización y se gestione de acuerdo
con las prácticas establecidas de la organización.

4.1 Culturas y estilos organizacionales

Las organizaciones son empresas o departamentos gubernamentales que se establecen para

cumplir un propósito, como brindar atención médica a los pacientes. Cada organización
desarrolla una cultura y un estilo único que representan su norma cultural y afectan la
manera en que se realizan los proyectos. Por ejemplo, un horario flexible en comparación
con una jornada laboral 8x5 puede afectar directamente la manera en que un director de
proyecto planifica los recursos y la manera en que el equipo interactúa. La cultura está
modelada por las experiencias comunes de las personas, tales como:

▪ Visiones, misiones, valores, creencias y expectativas compartidos.

▪ Regulaciones, políticas, métodos y procedimientos.

▪ Sistemas de motivación y recompensa.

▪ Tolerancia al riesgo.

▪ Visión de las relaciones de liderazgo, jerarquía y autoridad.

▪ Código de conducta, ética laboral y horas de trabajo.

▪ Entornos operativos.

Un director de proyecto debe comprender que las culturas tienen una fuerte influencia en la
capacidad de un proyecto de cumplir sus objetivos. También necesita saber qué personas de la
organización son los encargados de la toma de decisiones o son las personas influyentes, y
trabajar con ellos para aumentar la probabilidad de éxito del proyecto.

© Structuralia 22
 Project Management Professional – Personas. Entorno de negocio

4.2 Estructuras organizacionales

Una estructura organizacional determina cómo se interrelacionan los diversos grupos y

personas dentro de la organización. La estructura organizacional también afecta cuánta
autoridad tiene el director del proyecto, así como la disponibilidad de recursos y cómo
se realizan los proyectos.

Las organizaciones generalmente se configuran en una de las implementaciones

estructurales principales: funcionales, de matriz, por proyectos o compuestas. El modelo
estructural que utiliza una organización tendrá un gran impacto en la forma en que los
directores de proyectos interactúan con los miembros del equipo y con los interesados. En
muchos casos, un director de proyecto interactuará con varios niveles en una organización,
como los niveles gerenciales medios, operaciones, funciones estratégicas y la alta gerencia.

La autoridad relativa se refiere a la autoridad del director del proyecto en relación con la
autoridad del director funcional sobre el proyecto y el equipo del proyecto. En una estructura
organizacional totalmente funcional, la autoridad del director del proyecto es baja en
relación con la del director funcional. Por el contrario, en la estructura organizacional
basada en proyectos, ocurre lo opuesto.

4.3 Oficina de Dirección de Proyectos (PMO)

Como se establece en la Guía PMBOK®: Sexta edición, una Oficina de Dirección de Proyectos
PMO es una estructura de gestión que estandariza los procesos de gobernanza
relacionados con el proyecto y facilita el intercambio de recursos, metodologías,
herramientas y técnicas. Las PMO son más comunes en organizaciones grandes debido a la
cantidad de proyectos que pueden estar en curso al mismo tiempo. Una PMO puede ofrecer
asistencia y orientación para todos los proyectos en curso. PMBOK ® no proporciona pautas o
estándares oficiales para las PMO, por lo que las organizaciones grandes deben utilizar los
principios y las mejores prácticas de PMBOK para implementar en sus PMO. Existen varios
tipos de estructuras de PMO y cada una varía en el grado de control e influencia que tienen en
los proyectos dentro de la organización:
Las PMO de apoyo tienen un rol de asesoramiento para proyectos mediante el suministro de
plantillas, mejores prácticas, acceso a capacitación sobre la información y lecciones aprendidas
de otros proyectos.

23 © Structuralia
 Project Management Professional – Personas. Entorno de negocio

Las PMO de control brindan asistencia y exigen el cumplimiento a través de diversos medios.
El cumplimiento puede implicar la adopción de marcos o metodologías de dirección de
proyectos, el uso de plantillas, formularios y herramientas específicos, o la conformidad con la
gobernanza. Las PMO de dirección toman el control de los proyectos y los gestionan
directamente. Una cantidad relativamente pequeña de PMO pertenece a esta categoría.

4.4 Activos de los procesos de la organización (OPA)

Los activos de los procesos de la organización (OPA son planes, procesos, políticas,
procedimientos y bases de conocimiento que utiliza la organización que realiza el
proyecto y que son específicos para ésta. Los activos se pueden dividir en dos tipos:
procesos y procedimientos, y base de conocimientos corporativos.
Los activos de los procesos pueden incluir las lecciones que una organización ha aprendido de
los proyectos y las actividades anteriores y la información histórica general que ha conservado
la organización.

4.4.1. Procesos y procedimientos de la organización

Los procesos y procedimientos de la organización para realizar el trabajo del proyecto están
destinados a facilitar su desarrollo. Los activos pueden ser recursos, planes, procesos,
políticas, procedimientos y bases de conocimiento que utiliza la organización que realiza el
proyecto y que son específicos para esta. Las organizaciones deben cumplir con muchas de
estas condiciones establecidas.

4.4.2. Pautas y criterios para alinear los procesos y procedimientos estándares de una
organización para satisfacer las necesidades de cada proyecto iniciado.
Estándares organizacionales específicos. Esto puede incluir cualquier cantidad de políticas y
procedimientos a los que se deba hacer referencia para un proyecto específico. Las
organizaciones pueden desarrollar y gestionar un conjunto de plantillas estándar que se le
pedirá que utilice durante todo el proyecto. Y procesos y procedimientos para los siguientes
puntos:

© Structuralia 24
 Project Management Professional – Personas. Entorno de negocio

▪ Control de cambios, control financiero, control de riesgos, adquisiciones y gestión de

problemas y defectos.
▪ Requisitos de comunicaciones organizacionales.
▪ Procedimientos para priorizar, aprobar y emitir autorizaciones de trabajo.
▪ Pautas estandarizadas, instrucciones de trabajo, criterios de evaluación de
propuestas y criterios de medición de desempeño.
▪ Procedimientos o requisitos específicos para el cierre oficial de un proyecto. Esto
puede incluir cualquier cosa, desde la documentación de las lecciones aprendidas
durante el proyecto hasta la realización de una auditoría posterior a este o una
evaluación para verificar que lo que se pretendía se llevó a cabo con éxito.

4.4.3. Base de conocimientos corporativos

La base de conocimientos corporativos es un repositorio para almacenar y recuperar
información útil. Hay una amplia variedad de información que puede estar disponible:
▪ Bases de conocimiento de la gestión de la configuración que pueden incluir líneas
base del desempeño de estándares, políticas, procedimientos y documentos de la
organización.
▪ Bases de datos financieras que incluyen información financiera histórica.
▪ Estándares gubernamentales e industriales, como regulaciones, códigos de
conducta y estándares de calidad.
▪ Archivos de proyecto, como el alcance, el costo, el cronograma y las líneas base de
calidad. Documentación de infraestructura y materiales de referencia, como
diagramas de red e información de inventario de hardware y software.
▪ Información de administración de trabajadores, como pautas para la dotación y
retención de personal.
▪ Documentación y estándares de Recursos Humanos. Condiciones del mercado o la
industria.
▪ Sistemas de autorización del trabajo de la empresa.

25 © Structuralia
 Project Management Professional – Personas. Entorno de negocio

4.5 Factores ambientales de la empresa (EEF)

Los factores ambientales de la empresa (EEF) son las condiciones, fuera del control
inmediato del equipo, que pueden influir, restringir o dirigir el proyecto, programa o
portafolio. Estos factores pueden respaldar o limitar las opciones de gestión del proyecto,
actuar como entradas para los procesos de planificación y tener una influencia negativa o
positiva en el resultado de un proyecto. Las organizaciones deben cumplir con muchas de
estas condiciones establecidas. En algunos casos, incluso se pueden considerar como gastos
generales para el proyecto. Algunos ejemplos de EEF son los siguientes:
▪ Cultura, estructura y gobernanza de la organización.
▪ Distribución geográfica de instalaciones y recursos.
▪ Estándares gubernamentales o industriales.
▪ Infraestructura de TI.
▪ Recursos humanos existentes.
▪ Administración de personal.
▪ Sistemas de autorización del trabajo de la empresa.
▪ Condiciones del mercado.
▪ Tolerancias de riesgo de los interesados.
▪ Clima y situaciones políticos.
▪ Canales de comunicación establecidos por la organización.
▪ Bases de datos comerciales.
▪ Sistemas de información para la dirección de proyectos.
▪ Idiomas, zonas horarias y otros cronogramas de festividades del país.

© Structuralia 26
 Project Management Professional – Personas. Entorno de negocio

5. GUÍA PARA INSCRIPCIÓN AL EXAMEN

Para realizar el examen de certificación PMP, se deben seguir los pasos siguientes:

1. Cumplir con los criterios de elegibilidad

Todas las certificaciones de PMI requieren que cumpla con los niveles de experiencia de
dominio, niveles educativos o ambos antes de presentar la solicitud. Deberá proporcionarnos
los detalles de esta experiencia y / o educación, por lo que es mejor recopilar y preparar esta
información antes de abrir la aplicación.

Sólo se puede optar a examinarse de PMP cumpliendo uno de estos dos grupos de
requisitos:

▪ Un título universitario de cuatro años

▪ 36 meses liderando proyectos

▪ 35 horas de educación / capacitación en gestión de proyectos o certificación CAPM®

Ó:

▪ Un diploma de escuela secundaria o un título de asociado (o equivalente global)

▪ 60 meses liderando proyectos

▪ 35 horas de educación / capacitación en gestión de proyectos o certificación CAPM®

2. Solicitud completa
Una vez que haya determinado que cumple con los criterios de elegibilidad, es el momento de
presentar la solicitud. Recopile la siguiente información y luego utilice el sistema de certificación
en línea para guiarlo a través del proceso.
▪ Información de contacto: correo electrónico, dirección, número de teléfono
▪ Educación alcanzada: escuela a la que asistió, nivel de educación alcanzado, fecha
del título
▪ Experiencia de dominio: detalles de los proyectos, programas, carteras en las que
ha trabajado, incluidas las horas de calificación, las fechas de empleo, el puesto, los
detalles de la organización, la referencia y el resumen de la experiencia.
▪ Educación de dominio: nombres de los cursos completados, instituciones a las que
asistió, fechas, horas de calificación
Una vez que abra una aplicación, permanecerá activa durante 90 días, después de lo cual se
cerrará.

27 © Structuralia
 Project Management Professional – Personas. Entorno de negocio

Consejo: para completar la solicitud rápidamente, recopile toda la información y documentación

que necesites antes de abrirla. De lo contrario, es probable que le lleve varias sesiones
completar.
3. Revisión de la solicitud
Una vez que recibamos su solicitud, verificaremos que cumpla con los criterios de elegibilidad y
que su experiencia o educación sea válida y consistente con las pautas establecidas en el
manual de certificación.
Por lo general, el período de revisión de la solicitud demorará entre 5 y 10 días, según la
certificación. Una vez que esté completo, le enviaremos un correo electrónico para que
continúe con el siguiente paso.
Si tenemos alguna pregunta o problema con su solicitud, PMI le enviará más instrucciones e
indicaciones por correo electrónico.
Para cada certificación, se selecciona aleatoriamente un porcentaje específico de aplicaciones
para su auditoría. PMI realiza auditorías de aplicaciones para confirmar la experiencia y / o
educación documentada en las aplicaciones de certificación. El propósito de la auditoría es
mejorar la credibilidad del programa de certificación y de los titulares de la certificación. Lea las
Preguntas frecuentes sobre el proceso de auditoría de la solicitud.
Una vez que hayamos completado la revisión inicial, un panel de titulares de la certificación
PMI evaluará los resúmenes de su experiencia para confirmar su calificación.
¿Por qué PMI realiza auditorías de aplicaciones?
PMI realiza auditorías de aplicaciones para confirmar la experiencia y / o educación
documentada en las aplicaciones de certificación. El propósito de la auditoría es mejorar la
credibilidad del programa de certificación y de los titulares de la certificación. Para cada
certificación, se selecciona aleatoriamente un porcentaje específico de aplicaciones para
auditoría.
¿Cuánto tiempo dura el proceso de auditoría?
El equipo de auditoría de certificación procesa los materiales de auditoría dentro de los 5 a 7
días hábiles posteriores a su llegada a PMI. Una vez que PMI revise y apruebe los materiales
de auditoría, PMI enviará un correo electrónico con sus instrucciones de pago.
4. Pago
Una vez que se le notifica que se aprobó su solicitud, es el momento de realizar el pago para
que pueda pasar a la etapa final. La forma más rápida y sencilla de pagar es a través del
sistema de certificación en línea.

© Structuralia 28
 Project Management Professional – Personas. Entorno de negocio

Una vez que se reciba el pago, le envían un correo electrónico con un número de elegibilidad
que utilizará para programar su cita para el examen. Tiene derecho a un año y puede realizar el
examen hasta tres veces durante ese año.
5. Programar una cita para el examen
Una vez que sea elegible, PMI le enviará por correo electrónico las instrucciones para
programar el examen con su código de elegibilidad, que necesitará al programar su cita para el
examen. Puede programar su cita para el examen en línea o por teléfono. Los detalles
completos se pueden encontrar en el manual de certificación y en las instrucciones de
programación del examen. Entonces todo lo que queda es hacer el examen.

29 © Structuralia