Está en la página 1de 65

ISO 21502: 2020

Directrices sobre la gestión de proyectos


ISO 21502:2020
GESTIÓN DE PROYECTOS, PROGRAMAS Y PORTAFOLIOS
DIRECTRICES SOBRE LA GESTIÓN DE PROYECTOS

TABLA DE CONTENIDO
INTRODUCCIÓN ................................................................................................................................................7
1. ALCANCE ..................................................................................................................................................8
2. REFERENCIAS NORMATIVAS ................................................................................................................8
3. TÉRMINOS Y DEFINICIONES ..................................................................................................................8
4. CONCEPTOS DE GESTIÓN DE PROYECTOS .................................................................................... 11
4.1. Visión general ......................................................................................................................................... 11
4.1.1. General ............................................................................................................................................... 11
4.1.2. Proyectos ............................................................................................................................................ 12
4.1.3. Gestión de Proyectos ......................................................................................................................... 13
4.2. Contexto .................................................................................................................................................. 13
4.2.1. Impacto del contexto de un proyecto .................................................................................................. 13
4.2.2. Estrategia organizacional y proyectos ................................................................................................ 14
4.2.3. Perspectiva del cliente y del proveedor .............................................................................................. 15
4.2.4. Restricciones del proyecto .................................................................................................................. 15
4.2.5. Proyectos independientes, parte de un programa o parte de un portafolio ....................................... 16
4.3. Gobernanza de proyectos ...................................................................................................................... 17
4.3.1. Marco de gobernanza ......................................................................................................................... 17
4.3.2. Caso de negocio ................................................................................................................................. 17
4.4. Ciclo de vida del proyecto ....................................................................................................................... 18
4.5. Organización y funciones del proyecto ................................................................................................... 19
4.5.1. Organización del proyecto .................................................................................................................. 19
4.5.2. Organización patrocinadora ................................................................................................................ 20
4.5.3. Junta o Comité de dirección de Proyecto ........................................................................................... 21
4.5.4. Patrocinador del proyecto ................................................................................................................... 21
4.5.5. Asegurador del proyecto ..................................................................................................................... 22
4.5.6. Director de proyecto............................................................................................................................ 22
4.5.7. Oficina de proyectos ........................................................................................................................... 23
4.5.8. Líder de paquete de trabajo ................................................................................................................ 23
4.5.9. Miembros del equipo del proyecto ...................................................................................................... 24
4.5.10. Partes interesadas del proyecto ....................................................................................................... 24

Este documento es una traducción propia y de uso exclusivo de SGS Academy Colombia con fines académicos
No pretende superar al estándar original.
AC-GA-I-F-01-01
V2 – Septiembre 2018
2
4.5.11. Otros roles ........................................................................................................................................ 25
4.6. Competencias del personal del proyecto................................................................................................ 25
5. REQUISITOS PREVIOS PARA FORMALIZAR LA GESTIÓN DE PROYECTOS ................................. 26
5.1. Visión general ......................................................................................................................................... 26
5.2. Consideraciones para la implementación de la gestión de proyectos ................................................... 26
5.3. Mejora Continua del entorno de gestión de proyectos ........................................................................... 27
5.4. Alineamiento con los procesos y sistemas organizacionales ................................................................. 28
6. PRÁCTICAS INTEGRADAS DE GESTIÓN DE PROYECTOS .............................................................. 29
6.1. Visión general ......................................................................................................................................... 29
6.2. Actividades previas al proyecto .............................................................................................................. 30
6.3. Supervisión del proyecto ........................................................................................................................ 31
6.4. Dirección o patrocinio del proyecto ......................................................................................................... 32
6.5. Inicio del proyecto ................................................................................................................................... 32
6.5.1. Visión general ..................................................................................................................................... 32
6.5.2. Movilización del equipo del proyecto .................................................................................................. 32
6.5.3. Enfoque de gobernanza y de gestión de proyectos ........................................................................... 33
6.5.4. Justificación inicial del proyecto .......................................................................................................... 33
6.5.5. Planificación inicial del proyecto ......................................................................................................... 34
6.6. Control de un proyecto............................................................................................................................ 34
6.6.1. Visión general ..................................................................................................................................... 34
6.6.2. Justificación progresiva ...................................................................................................................... 34
6.6.3. Gestión del desempeño del proyecto ................................................................................................. 34
6.6.4. Gestión del inicio y cierre de cada fase del proyecto ......................................................................... 35
6.6.5. Gestión del inicio, progreso y cierre de cada paquete de trabajo ...................................................... 36
6.7. Gestión de la entrega.............................................................................................................................. 37
6.8. Cierre o terminación del proyecto ........................................................................................................... 37
6.9. Actividades posteriores al proyecto ........................................................................................................ 39
7. PRÁCTICAS DE GESTIÓN PARA UN PROYECTO .............................................................................. 40
7.1. Visión general ......................................................................................................................................... 40
7.2. Planificación ............................................................................................................................................ 41
7.2.1. Visión general ..................................................................................................................................... 41
7.2.2. Desarrollo del plan .............................................................................................................................. 41
7.2.3. Seguimiento del plan .......................................................................................................................... 41
7.3. Gestión de beneficios ............................................................................................................................. 42

Este documento es una traducción propia y de uso exclusivo de SGS Academy Colombia con fines académicos
No pretende superar al estándar original.
AC-GA-I-F-01-01
V2 – Septiembre 2018
3
7.3.1. Visión general ..................................................................................................................................... 42
7.3.2. Identificación y análisis de beneficios ................................................................................................. 42
7.3.3. Monitoreo de los beneficios ................................................................................................................ 43
7.3.4. Mantenimiento de beneficios .............................................................................................................. 43
7.4. Gestión del alcance ................................................................................................................................ 43
7.4.1. Visión general ..................................................................................................................................... 43
7.4.2. Definición del alcance ......................................................................................................................... 44
7.4.3. Control del Alcance ............................................................................................................................. 44
7.4.4. Confirmación de la entrega del alcance ............................................................................................. 44
7.5. Gestión de los recursos .......................................................................................................................... 45
7.5.1. Visión general ..................................................................................................................................... 45
7.5.2. Planificación de la organización del proyecto ..................................................................................... 45
7.5.3. Establecimiento del equipo ................................................................................................................. 45
7.5.4. Desarrollo al equipo ............................................................................................................................ 46
7.5.5. Gestión del equipo .............................................................................................................................. 46
7.5.6. Planificación, gestión y control de recursos físicos y materiales ........................................................ 47
7.6. Gestión del cronograma.......................................................................................................................... 47
7.6.1. Visión general ..................................................................................................................................... 47
7.6.2. Estimación de la duración de las actividades ..................................................................................... 48
7.6.3. Desarrollo del cronograma ................................................................................................................. 48
7.6.4. Control del cronograma ...................................................................................................................... 48
7.7. Gestión de los Costos ............................................................................................................................. 49
7.7.1. Visión general ..................................................................................................................................... 49
7.7.2. Estimación del costo ........................................................................................................................... 49
7.7.3. Desarrollo del presupuesto ................................................................................................................. 50
7.7.4. Control de costos ................................................................................................................................ 50
7.8. Gestión de los riesgos ............................................................................................................................ 50
7.8.1. Visión general ..................................................................................................................................... 50
7.8.2. Identificación de riesgos ..................................................................................................................... 51
7.8.3. Evaluación de riesgos ......................................................................................................................... 51
7.8.4. Tratamiento de riesgos ....................................................................................................................... 51
7.8.5. Control de riesgos ............................................................................................................................... 52
7.9. Gestión de los incidentes ........................................................................................................................ 52
7.9.1. Visión general ..................................................................................................................................... 52

Este documento es una traducción propia y de uso exclusivo de SGS Academy Colombia con fines académicos
No pretende superar al estándar original.
AC-GA-I-F-01-01
V2 – Septiembre 2018
4
7.9.2. Identificación de incidentes ................................................................................................................. 52
7.9.3. Resolución de incidentes .................................................................................................................... 52
7.10. Control de Cambios ................................................................................................................................ 53
7.10.1. Visión general ................................................................................................................................... 53
7.10.2. Establecimiento de un marco de control de cambios ....................................................................... 53
7.10.3. Identificación y evaluación de solicitudes de cambio ....................................................................... 53
7.10.4. Planificación de solicitudes de cambio ............................................................................................. 54
7.10.5. Implementación y cierre de solicitudes de cambio ........................................................................... 54
7.11. Gestión de calidad .................................................................................................................................. 54
7.11.1. Visión general ................................................................................................................................... 54
7.11.2. Planificación de la calidad ................................................................................................................ 55
7.11.3. Aseguramiento de la calidad ............................................................................................................ 55
7.11.4. Control de la calidad ......................................................................................................................... 56
7.12. Involucramiento de las partes interesadas ............................................................................................. 56
7.12.1. Visión general ................................................................................................................................... 56
7.12.2. Identificación de las partes interesadas ........................................................................................... 57
7.12.3. Involucramiento de las partes interesadas ....................................................................................... 57
7.13. Gestión de las comunicaciones .............................................................................................................. 58
7.13.1. Visión general ................................................................................................................................... 58
7.13.2. Planificación de las comunicaciones ................................................................................................ 58
7.13.3. Distribución de la información ........................................................................................................... 58
7.13.4. Monitoreo del impacto de las comunicaciones ................................................................................. 59
7.14. Gestión del cambio organizacional ......................................................................................................... 59
7.14.1. Visión general ................................................................................................................................... 59
7.14.2. Identificación de la necesidad del cambio organizacional ................................................................ 59
7.14.3. Transferencia a la organización patrocinadora ................................................................................ 60
7.14.4. Implementación del cambio organizacional ...................................................................................... 60
7.15. Presentación de informes ....................................................................................................................... 60
7.15.1. Visión general ................................................................................................................................... 60
7.15.2. Planificación de informes .................................................................................................................. 61
7.15.3. Desarrollo de informes ...................................................................................................................... 61
7.15.4. Presentación de informes ................................................................................................................. 61
7.16. Gestión de la información y documentación ........................................................................................... 61
7.16.1. Visión general ................................................................................................................................... 61

Este documento es una traducción propia y de uso exclusivo de SGS Academy Colombia con fines académicos
No pretende superar al estándar original.
AC-GA-I-F-01-01
V2 – Septiembre 2018
5
7.16.2. Identificación de la información que debe gestionarse .................................................................... 62
7.16.3. Almacenamiento y recuperación de información y documentación ................................................. 62
7.17. Adquisiciones .......................................................................................................................................... 62
7.17.1. Visión general ................................................................................................................................... 62
7.17.2. Planificación de la adquisición .......................................................................................................... 63
7.17.3. Evaluación y selección de proveedores ........................................................................................... 63
7.17.4. Administración de contratos ............................................................................................................. 63
7.17.5. Cierre de contratos ........................................................................................................................... 63
7.18. Lecciones aprendidas ............................................................................................................................. 64
7.18.1. Visión general ................................................................................................................................... 64
7.18.2. Identificación de lecciones aprendidas ............................................................................................. 64
7.18.3. Difusión de lecciones aprendidas ..................................................................................................... 64

TABLA DE FIGURAS

Ilustración 1 ⎯ Ejemplo de gestión de proyectos en el contexto de la gobernanza y de la gestión de


programas y portafolios ................................................................................................................................. 12
Ilustración 2 Ejemplo de creación de valor a través de proyectos y programas ........................................... 14
Ilustración 3 Ejemplo de relaciones entre portafolios, programas y proyectos ............................................. 16
Ilustración 4 Relación entre el ciclo de vida del proyecto, prácticas integradas de gestión de proyectos ... 18
Ilustración 5 Ejemplo de una estructura de organización de proyecto ......................................................... 19
Ilustración 6 Un ejemplo de las posibles partes interesadas del proyecto ................................................... 25
Ilustración 7 Vista de las prácticas integradas de gestión de proyectos, las relaciones y roles asociados . 30
Ilustración 8 Prácticas de gestión de proyectos en relación con la gestión integrada de proyectos ............ 40

Este documento es una traducción propia y de uso exclusivo de SGS Academy Colombia con fines académicos
No pretende superar al estándar original.
AC-GA-I-F-01-01
V2 – Septiembre 2018
6
INTRODUCCIÓN

Este documento proporciona orientación sobre conceptos y prácticas para la gestión de proyectos
que son importantes y tienen un impacto en la entrega exitosa de un proyecto.

Los lectores de destino de este documento incluyen, (pero no se limitan a):

a) la dirección ejecutiva y senior, para proporcionar una mejor comprensión de la gestión de


proyectos y ayudarles a dar el apoyo y la orientación adecuados a los gerentes de proyecto
y a las personas que trabajan en proyectos

b) los directores de proyecto y los miembros del equipo del proyecto para que tengan una base
común sobre la cual entender, realizar, comparar, evaluar y comunicar sus prácticas de
proyecto

c) las personas involucradas en la gobernanza, dirección, aseguramiento, auditoría y gestión de


proyecto como patrocinadores de proyectos, juntas de proyectos, auditores y gerentes de
proyectos, y

d) Desarrolladores de estándares, procesos y métodos de gestión de proyectos nacionales u


organizacionales.

Además, este documento también puede ser útil para las personas involucradas en funciones de
apoyo:

— la gobernanza, la dirección y la gestión de portafolios y de programas;

— equipos de proyectos, oficinas de programas y de proyectos o estructuras organizativas


similares;

— estudio académico de la gestión de proyectos, programas y portafolios, y

— funciones relacionadas con la gestión de proyectos, tales como finanzas, contabilidad, gestión
de recursos humanos, contratación y asuntos legales.

Este documento es una traducción propia y de uso exclusivo de SGS Academy Colombia con fines académicos
No pretende superar al estándar original.
AC-GA-I-F-01-01
V2 – Septiembre 2018
7
1. ALCANCE

Este documento proporciona orientación sobre la gestión de proyectos y puede ser utilizado por
cualquier organización de orden público, privado y/o benéfico, así como cualquier tipo de
proyecto, independientemente de su propósito, métodos de entrega, modelo de ciclo utilizado,
complejidad, tamaño, costo o duración.

NOTA El método de entrega puede ser cualquier método adecuado para el tipo de resultados,
como predictivo, incremental, iterativo, incluyendo enfoques ágiles.

Este documento proporciona descripciones de alto nivel de las actividades que se consideran
para formar buenas prácticas en gestión de proyectos. Además, no proporciona orientación sobre
la gestión de programas o portafolios. Los temas relacionados con la gestión general se abordan
únicamente en el contexto de gestión de proyectos.

2. REFERENCIAS NORMATIVAS

No hay referencias normativas en este documento.

3. TÉRMINOS Y DEFINICIONES

A los efectos de este documento, se aplican los siguientes términos y definiciones.

ISO e IEC mantienen bases de datos terminológicas para su uso en estandarización en las
siguientes direcciones:

— ISO Plataforma de navegación en línea: disponible en https://www.iso.org/obp

— Electropedia IEC: disponible en http://www.electropedia.org/

3.1 Línea de base


Base de referencia para la comparación con la que se supervisa y controla el desempeño.

[FUENTE: ISO/TR 21506:2018, 3.5]

3.2 Beneficio
Beneficio creado, valor u otro efecto positivo.

[FUENTE: ISO/TR 21506:2018, 3.6]

3.3 Solicitud de cambio


Documentación que define una modificación propuesta para un proyecto (0).

[FUENTE: ISO/TR 21506:2018, 3.10]

Este documento es una traducción propia y de uso exclusivo de SGS Academy Colombia con fines académicos
No pretende superar al estándar original.
AC-GA-I-F-01-01
V2 – Septiembre 2018
8
3.4 Gestión de la configuración
Procedimientos de control, correlación y mantenimiento de documentación, especificaciones y
atributos.
[FUENTE: ISO/TR 21506:2018, 3.12]

3.5 Control
Comparación del desempeño real con el desempeño planificado, analizando las desviaciones y
tomando la acción correctiva o preventiva apropiada, según sea necesario.

[FUENTE: ISO/TR 21506:2018, 3.13]

3.6 Acción correctiva


Dirección y actividad para modificar el desempeño del trabajo, a fin de poner el desempeño en
línea con un plan.

[FUENTE: ISO/TR 21506:2018, 3.15]

3.7 Camino crítico


Secuencia de actividades que determinan la fecha de finalización más temprana posible, para un
proyecto (0) o fase.

[FUENTE: ISO/TR 21506:2018, 3.18]

3.8 Entregable
Elemento único y verificable que debe ser producido por un proyecto (0).
[FUENTE: ISO/TR 21506:2018, 3.19, modificado — "elemento que debe ser producido por un
proyecto" ha sustituido a "resultados tangibles o intangibles de una actividad planificada".]

3.9 Incidente
Cualquier evento que surja durante un proyecto (0), que requiera resolución para que el proyecto
(0) continúe.

3.10 Resultado
Cambio resultante del uso de un producto (0) de un proyecto (0).

3.11 Producto (salida)


Entregas tangibles o intangibles agregadas que forman el resultado del proyecto (0).

3.12 Portafolio
Grupo de componentes de portafolio (0) agrupados para facilitar su gestión y alcanzar objetivos
estratégicos.

[FUENTE: ISO/TR 21506:2018, 3.42]

3.13 Componente de portafolio


Proyecto (0), programa (0), portafolio (0) u otro trabajo relacionado.

Este documento es una traducción propia y de uso exclusivo de SGS Academy Colombia con fines académicos
No pretende superar al estándar original.
AC-GA-I-F-01-01
V2 – Septiembre 2018
9
[FUENTE: ISO/TR 21506:2018, 3.43]

3.14 Acción preventiva


Actividad para eliminar la causa de una posible inconformidad u otra situación posible, indeseable.

Nota 1 a la entrada:
Se toman acciones preventivas para prevenir la ocurrencia, mientras se toman acciones
correctivas para evitar la recurrencia.

[FUENTE: ISO 9000:2015, 3.12.1, modificado — Se ha eliminado la Nota 1 original a la entrada.]

3.15 Programa
Grupo de componentes del programa (0) gestionados de forma coordinada para obtener
beneficios (0)

[FUENTE: ISO/TR 21506:2018, 3.50]

3.16 Componente de programa


Proyecto (0), programa (0) u otro trabajo relacionado

[FUENTE: ISO/TR 21506:2018, 3.52]

3.17 Proyecto
Esfuerzo temporal para lograr uno o más objetivos definidos.

[FUENTE: ISO/TR 21506:2018, 3.59, modificado — "para lograr uno o más objetivos definidos"
ha sustituido "creado para producir de entregables acordados".]

3.18 Gobernanza de proyectos


Principios, políticas y procedimientos mediante los cuales un proyecto (0) es autorizado y dirigido
a cumplir entregables acordados (0).

[FUENTE: ISO/TR 21506:2018, 3.60]

3.19 Ciclo de vida del proyecto


Conjunto definido de fases desde el inicio hasta el final de un proyecto (0).

3.20 Gestión de proyectos


Actividades coordinadas para dirigir y controlar el logro de los objetivos acordados.

[FUENTE: ISO/TR 21506:2018, 3.61, modificado - "objetivos" ha sustituido a entregables”]

3.21 Alcance del proyecto


Trabajo autorizado para realizar entregas acordadas.

[FUENTE: ISO/TR 21506:2018, 3.65]

Este documento es una traducción propia y de uso exclusivo de SGS Academy Colombia con fines académicos
No pretende superar al estándar original.
AC-GA-I-F-01-01
V2 – Septiembre 2018
10
3.22 Patrocinador
Persona responsable de obtener los recursos y tomar las decisiones ejecutivas, para facilitar el
éxito del proyecto.

[FUENTE: ISO/TR 21506:2018, 3.78]

3.23 Partes interesadas


Persona, grupo u organización que tiene intereses o puede afectar, verse afectado, o percibirse
a sí mismo como afectado por cualquier aspecto de un proyecto (0), programa (0) o portafolio (0).

[FUENTE: ISO/TR 21506:2018, 3.79]

3.24 Estructura de desglose del trabajo


Descomposición del alcance definido del proyecto (0) o programa (0), en niveles progresivamente
inferiores que consisten en elementos de trabajo.

[FUENTE: ISO/TR 21506:2018, 3.87]

3.25 Paquete de trabajo


Grupo de actividades que tienen un alcance definido, entregable (0), programación y costo.

4. CONCEPTOS DE GESTIÓN DE PROYECTOS

4.1. Visión general

4.1.1. General

La cláusula 4 describe los conceptos relativos a la gestión de proyectos que se basan en las
prácticas descritas en las Cláusulas 6 y 7.

La Figura 1 muestra el contexto y el entorno dentro del cual un proyecto existe. Un proyecto puede
ser independiente o parte de un programa o portafolio dentro de una organización (véase 4.2.5),
cualquiera de los cuales puede cruzar los límites de la organización.

La estrategia organizativa se puede utilizar para identificar oportunidades y amenazas con la


consideración de debilidades y fortalezas que deberían ser documentados y evaluados. Las
oportunidades y amenazas seleccionadas pueden desarrollarse y justificarse en un caso de
negocio u otro documento similar, que puede dar lugar a uno o más proyectos que se inician.

Se espera que los resultados de los proyectos, adecuadamente manejados, ofrezcan resultados,
en beneficio para las organizaciones patrocinadoras o partes interesadas.

Este documento es una traducción propia y de uso exclusivo de SGS Academy Colombia con fines académicos
No pretende superar al estándar original.
AC-GA-I-F-01-01
V2 – Septiembre 2018
11
Ilustración 1 ⎯ Ejemplo de gestión de proyectos en el contexto de la gobernanza y de la gestión de programas y
portafolios

NOTA Las líneas discontinuas del cuadro “Operaciones” indican que las operaciones se
extienden a proyectos, programas y portafolios (consulte "otro trabajo").

4.1.2. Proyectos

Las organizaciones realizan trabajos para alcanzar objetivos específicos. Generalmente, este
trabajo se puede clasificar como operaciones o proyectos. Las operaciones y los proyectos
difieren en que:

a) los proyectos son realizados por equipos, que pueden incluir contratistas y se centran en
mantener o agregar valor o capacidad, ya sea dentro de la organización patrocinadora o para
un cliente.

b) las operaciones se realizan a través de actividades continuas y pueden estar enfocadas en


mantener la organización, por ejemplo, a través de la entrega de productos y servicios
repetibles.

El objetivo de un proyecto puede ser cumplido por cualquier combinación de productos,


entregables, resultados y beneficios, en función del contexto del proyecto (véase 4.2) y de la
dirección proporcionada a través de la gobernanza (véase 4.3). Un objetivo del proyecto debe

Este documento es una traducción propia y de uso exclusivo de SGS Academy Colombia con fines académicos
No pretende superar al estándar original.
AC-GA-I-F-01-01
V2 – Septiembre 2018
12
contribuir a los resultados y la realización de beneficios para las partes interesadas, la
organización patrocinadora, otras partes interesadas de la organización interna y externa, los
clientes y sus participantes. Aunque muchos proyectos tienen características similares, cada
proyecto es único. Las diferencias entre proyectos pueden ocurrir en factores tales como, (pero
no limitado a):

— objetivos

— contexto

— los resultados deseados

— partes interesadas afectadas

— recursos utilizados

— complejidad

— restricciones (véase 4.2.4)

— procesos o métodos utilizados.

4.1.3. Gestión de Proyectos

La gestión de proyectos integra las prácticas incluidas en este estándar para planificar, dirigir,
monitorear y controlar el proyecto, gestionar los recursos asignados al proyecto y motivar a las
personas involucradas en el proyecto para alcanzar los objetivos del proyecto. La gestión de
proyectos debería realizarse a través de un conjunto de procesos y métodos que deberían
diseñarse como un sistema y deberían incluir las prácticas necesarias para cada proyecto
específico, como se describe en esta norma.

4.2. Contexto

4.2.1. Impacto del contexto de un proyecto

4.2.1.1 General

El contexto de un proyecto puede afectar el desempeño de un proyecto y la probabilidad de éxito.


El equipo del proyecto debería tener en cuenta los factores, tanto dentro como fuera de los límites
de la organización.

4.2.1.2 Factores dentro del límite organizacional

Factores dentro del límite organizacional, como la estrategia, la tecnología, la madurez en la


administración general y de proyectos, disponibilidad de recursos y cultura y estructura
organizacional, pueden tener un impacto sobre el éxito de un proyecto. Existe una relación entre
un proyecto y su contexto que debe considerarse al adaptar el enfoque de gestión de proyectos,

Este documento es una traducción propia y de uso exclusivo de SGS Academy Colombia con fines académicos
No pretende superar al estándar original.
AC-GA-I-F-01-01
V2 – Septiembre 2018
13
desarrollar el caso de negocio, llevar a cabo los estudios de viabilidad y diseño para la transición
a las operaciones.

4.2.1.3 Factores fuera del límite organizacional

Los factores fuera del límite organizacional pueden incluir, pero no se limitan a factores
socioeconómicos, geográficos, políticos, regulatorios, tecnológicos y ecológicos. Estos factores
pueden tener un impacto en el proyecto mediante la imposición de requisitos o restricciones, o
mediante la introducción de riesgos que afectan al proyecto.

Aunque estos factores a menudo están más allá del poder o capacidad del patrocinador del
proyecto o del director del proyecto para controlar o influir, estos factores aún deberían ser
considerados y previstos al justificar, iniciar, planificar, controlar y cerrar el proyecto.

4.2.2. Estrategia organizacional y proyectos

Las organizaciones a menudo establecen su estrategia general basada en su misión, visión,


políticas y factores internos y externos al límite organizativo. Los proyectos pueden ser un medio
para lograr objetivos. Los entregables, productos y resultados deberían tenerse en cuenta al
identificar las necesidades y oportunidades. La creación de valor a partir de la realización de
proyectos se ilustra en la Figura 2. El valor positivo es creado cuando los beneficios permitidos
por el proyecto superan la inversión de recursos. El valor creado puede ser tangible o intangible

Ilustración 2 Ejemplo de creación de valor a través de proyectos y programas

Este documento es una traducción propia y de uso exclusivo de SGS Academy Colombia con fines académicos
No pretende superar al estándar original.
AC-GA-I-F-01-01
V2 – Septiembre 2018
14
4.2.3. Perspectiva del cliente y del proveedor
Los proyectos se pueden llevar a cabo desde dos perspectivas:

a) la organización del cliente, propietario o patrocinador: La organización posee los requisitos


y puede llevar a cabo el trabajo o el contrato parcial o total del trabajo a una organización
proveedora, y
b) la organización del proveedor o contratista: La organización proporciona como base o parte
de su negocio, un servicio o producto a otra organización.

EJEMPLO 1: Ejemplos de un servicio o producto entregado por un proveedor o contratista, como


proyecto para generar ingresos, podría incluir la construcción de carreteras, aeropuertos,
ferrocarriles y sistemas de tecnología de la información.

En la mayoría de los casos, el alcance del proyecto del proveedor es una parte del alcance del
proyecto del cliente. Cada parte de un contrato debe velar por sus intereses organizativos en el
proyecto y tener su justificación para emprender el proyecto.

La relación cliente-proveedor puede confundirse, ya que para algunos proyectos, la relación


puede ser tanto extra-organizacional como intra-organizacional. En tales casos, el papel del
proveedor es llevado a cabo en parte por un contratista externo o proveedor para un cliente que
es de otro departamento o sección, dentro de la misma organización.

EJEMPLO 2: El departamento de tecnología de la información de una organización puede llevar


a cabo una actualización de software, utilizando recursos contratados o socios para el
departamento de la cadena de suministro. En estas situaciones, los roles de proveedor-cliente
pueden ser multidimensionales.

La organización debería determinar:

— cómo debe funcionar la gobernanza de los proyectos a ambos lados y a través de un límite
contractual

— las personas apropiadas para participar en el proyecto, y

— las prácticas de trabajo que deban adoptarse en relación con el ciclo de vida del proyecto,
según sea necesario para la entrega.

4.2.4. Restricciones del proyecto

Los resultados y resultados del proyecto deberían lograrse dentro de un conjunto identificado de
restricciones, como, (pero no limitado a):

a) duración o fecha objetivo para completar el proyecto

b) disponibilidad de financiación de la organización

c) el presupuesto del proyecto aprobado y asignado

Este documento es una traducción propia y de uso exclusivo de SGS Academy Colombia con fines académicos
No pretende superar al estándar original.
AC-GA-I-F-01-01
V2 – Septiembre 2018
15
d) disponibilidad de los recursos del proyecto, como personas con las aptitudes, instalaciones,
materiales, infraestructura, herramientas y otros recursos necesarios para llevar a cabo las
actividades del proyecto relacionados con los requisitos del proyecto

e) factores relacionados con la salud y la seguridad del personal

f) seguridad

g) nivel de exposición aceptable al riesgo

h) posible impacto social, ambiental y ecológico del proyecto y sus resultados, y

i) leyes, regulaciones y otros requisitos gubernamentales.

Las restricciones a menudo están interrelacionadas, de tal manera que un cambio en una
restricción puede afectar a uno o más de las restricciones. Por esta razón, el efecto de estas
restricciones debe entenderse y equilibrarse. Se debe buscar un acuerdo entre las principales
partes interesadas del proyecto, especialmente entre los responsables de la toma de decisiones,
sobre las restricciones del proyecto y su prioridad relativa para formar una base sólida para el
éxito.

4.2.5. Proyectos independientes, parte de un programa o parte de un portafolio

Los proyectos se pueden organizar como componentes de programas, de portafolios o pueden


ser independientes, (ver ISO 21503 e ISO 21504). Vea en la figura 3, ejemplos de cómo se
relacionan los proyectos con otros componentes. Los proyectos independientes son aquellos que
no se gestionan como un componente dentro de un programa o portafolio.

Los fundamentos de la gestión de proyectos son los mismos en todas las situaciones, pero lo que
normalmente cambia es cómo la gobernanza del proyecto opera y, en particular, el nivel de
presentación de informes y el nivel para la toma de decisiones. Si un proyecto forma parte de un
programa o portafolio, sus objetivos y gobernanza deberían estar integrados con los objetivos y
gobernanza de ese programa o portafolio (véase 4.3)

Ilustración 3 Ejemplo de relaciones entre portafolios, programas y proyectos

Este documento es una traducción propia y de uso exclusivo de SGS Academy Colombia con fines académicos
No pretende superar al estándar original.
AC-GA-I-F-01-01
V2 – Septiembre 2018
16
4.3. Gobernanza de proyectos

4.3.1. Marco de gobernanza

La gobernanza de los proyectos debería incluir los principios, las políticas y el marco por el cual
una organización dirige, controla y autoriza el proyecto con base en un caso de negocio acordado.
La gobernanza debería proporcionar la supervisión de temas, tales como:

a) las políticas, procesos y métodos que se utilizarán para llevar a cabo las actividades y
prácticas definidas en este documento

b) marcos de gestión, incluido el ciclo de vida del proyecto (véase 4.4), y

c) roles y responsabilidades, incluidos los límites de autoridad y toma de decisiones (véase 4.5).

La responsabilidad de mantener la gobernanza del proyecto suele ser asignada por organismo
de gobierno de la organización patrocinadora al patrocinador del proyecto, a la Junta o Comité de
Dirección de Proyectos, o a un comité directivo del proyecto.

La gobernanza de los proyectos, debe ser una parte integrada del marco de referencia de la
gobernanza general de la organización patrocinadora.

4.3.2. Caso de negocio

El caso de negocio proporciona una base para la gobernanza de proyectos. Un caso de negocio
u otro documento debería utilizarse para justificar la realización y continuación de un proyecto y
debería incluir como mínimo o como referencia:

a) los beneficios potenciales que se deberían realizar

b) métricas definidas para evaluar el valor generado

c) visibilidad del riesgo y actitud frente al riesgo de la dirección

d) requisitos de presupuesto, programación y calidad

e) programación requerida, negocio potencial y disrupción hacia otras operaciones de la


organización

f) involucramiento de las partes interesadas y gestión de las relaciones

g) comunicaciones internas y externas

h) uso de recursos humanos y materiales

i) habilidades, conocimientos y capacidades requeridas

j) gestión de la complejidad

Este documento es una traducción propia y de uso exclusivo de SGS Academy Colombia con fines académicos
No pretende superar al estándar original.
AC-GA-I-F-01-01
V2 – Septiembre 2018
17
k) definición de proyecto propuesta y alineación organizacional, y

l) capacidad para sostener el negocio y las actividades organizacionales a través del cambio.

4.4. Ciclo de vida del proyecto

Al definir el ciclo de vida del proyecto, deberían ser consideradas la gobernanza organizacional y
del proyecto, los riesgos, los factores de control, la naturaleza o características del proyecto y
otros factores organizacionales y ambientales.

El número y los nombres de las fases, dependen del tipo de proyecto que se lleve a cabo y del
riesgo previsto. Las fases pueden reflejar el enfoque de desarrollo que se está adoptando, ya sea
iterativo, incremental, adaptativo o híbrido. Los métodos de gestión a menudo utilizan diferentes
palabras para denotar fases, tales como como etapa, iteración y lanzamiento. Las fases pueden
superponerse.

Las fases deben tener un inicio y un final definidos. Cada fase del ciclo de vida del proyecto debe
tener hitos que pueden relacionarse con las decisiones, entregas clave, productos o resultados.
Cada fase podría ser precedida por un punto de decisión. Estos puntos de decisión a menudo se
denominan compuertas, que son aspectos esenciales de la gobernanza del proyecto. Los criterios
que deberían cumplirse para aprobar el inicio de una fase deben definirse, pero pueden variar en
función del entorno organizacional, el ciclo de vida específico que se utiliza y el gobierno de
proyectos. En algunos casos, algunas fases pueden superponerse.

Ilustración 4 Relación entre el ciclo de vida del proyecto, prácticas integradas de gestión de proyectos

Este documento es una traducción propia y de uso exclusivo de SGS Academy Colombia con fines académicos
No pretende superar al estándar original.
AC-GA-I-F-01-01
V2 – Septiembre 2018
18
Los puntos de decisión y las fases indicadas en la Figura 4 deberían definirse y pueden variar
dependiendo del entorno organizacional y del riesgo. La Figura 4 muestra además los vínculos
entre el ciclo de vida del proyecto y las prácticas integradas de gestión de proyectos (Cláusula 6)
y las prácticas de gestión de un proyecto (Cláusula 7).

4.5. Organización y funciones del proyecto

4.5.1. Organización del proyecto

La organización del proyecto es una estructura temporal que define los roles del proyecto, las
responsabilidades, el nivel de autoridad y la rendición de cuentas con personas nombradas.
Debe quedar claro a quién debe rendir cuentas cada individuo.

La organización del proyecto debe ser aprobada por el patrocinador del proyecto o la Junta o
Comité de Dirección de Proyectos. La organización del proyecto debe comunicarse a todos los
involucrados en el proyecto. El diseño de la organización del proyecto puede depender de otros
acuerdos que existan entre las partes interesadas del proyecto.

La organización del proyecto debería definirse con suficiente detalle para que cada individuo
entienda su rol y responsabilidades, y los roles y responsabilidades de aquellas personas con las
que trabaja.

Las responsabilidades deberían ser mutuamente consistentes y trazables a lo largo del proyecto.
El diseño y la ejecución de la organización del proyecto también debería considerar los aspectos
informales del proyecto como la motivación y coordinación de los miembros del equipo del
proyecto, así como los niveles de habilidades y comportamientos interpersonales.

Un ejemplo de una estructura de organización de proyecto se muestra en la figura 5. Las


relaciones dentro de la organización del proyecto deberían definirse y administrarse como se
describe en 7.5. Las funciones y responsabilidades de la organización se detallan en las
siguientes cláusulas.

Una persona puede desempeñar más de una función, pero la persona que emprende el rol de
patrocinador del proyecto tampoco debe llevar a cabo el de director del proyecto, de líder del
paquete de trabajo o de los roles de los miembros del equipo del proyecto, debido a la posibilidad
de conflictos de intereses.

La organización del proyecto también puede incluir a los clientes o representantes de los clientes,
así como los proveedores o contratistas, como se describe en 4.2.3. La organización del proyecto
puede cambiar a lo largo del ciclo de vida del proyecto, especialmente entre fases, de acuerdo
con labores específicas a realizar y competencias necesarias.

Ilustración 5 Ejemplo de una estructura de organización de proyecto

Este documento es una traducción propia y de uso exclusivo de SGS Academy Colombia con fines académicos
No pretende superar al estándar original.
AC-GA-I-F-01-01
V2 – Septiembre 2018
19
NOTA 1: Cuando existe un Junta o Comité de Proyectos, la línea de comunicación puede cambiar
para adaptarse a los acuerdos de gobernanza.

NOTA 2: Es posible que las oficinas del proyecto no existan en todas las organizaciones.

4.5.2. Organización patrocinadora

La organización patrocinadora actúa como una autoridad de alto nivel y debe proporcionar
dirección y recursos al comité de dirección de proyectos o al patrocinador del proyecto, abordar
los riesgos e incidentes crecientes y tomar decisiones que están por encima de la autoridad
delegada al comité de dirección o al patrocinador del proyecto. El patrocinador del proyecto puede
representar a la organización patrocinadora y, por lo tanto, podría no tener una autoridad superior
para escalar riesgos e incidentes, o buscar su orientación.

El representante de la organización patrocinadora, la persona u organismo que lleva a cabo


efectivamente este papel, depende del contexto del proyecto. Por ejemplo, para un proyecto
dentro de un:

a) Portafolio: la autoridad de nivel superior podría ser el gerente o director del portafolio, y

b) Programa: la autoridad de nivel superior podría ser el director del programa.

Este documento es una traducción propia y de uso exclusivo de SGS Academy Colombia con fines académicos
No pretende superar al estándar original.
AC-GA-I-F-01-01
V2 – Septiembre 2018
20
NOTA: Para las prácticas integradas de gestión de proyectos asociadas con la organización
patrocinadora, véase 6.2, 6.3 y 6.9.

4.5.3. Junta o Comité de dirección de Proyecto

La Junta o Comité de dirección de Proyecto, si es necesario, debería contribuir al proyecto


proporcionando dirección y orientación al patrocinador del proyecto (véase NOTA 1 y NOTA 2 de
la Figura 5).

El rol de un comité o junta de dirección del proyecto puede diferir de organización a organización,
y de proyecto a proyecto, con respecto a su autoridad en relación con el patrocinador del proyecto.
Por ejemplo, un comité de dirección del proyecto podría incluir:

a) organismo superior, que representa la autoridad de más alto nivel a la que el patrocinador del
proyecto debe rendir cuentas, y

b) comité, presidido por el patrocinador del proyecto, que proporciona el patrocinio con
asesoramiento de alto nivel.

El comité o junta de dirección del proyecto debería:

− monitorear el progreso y las perspectivas del proyecto para confirmar que los intereses de la
organización están siendo atendidos, y

− proporcionar un espacio para ayudar con decisiones estratégicas, para eliminar obstáculos y
resolver incidentes.

Si un proyecto es una empresa conjunta entre dos o más organizaciones, un comité de proyecto
puede incluir representantes de cada organización (véase ISO 21505).

NOTA: Los términos comúnmente utilizados para referirse el comité o junta de dirección del
proyecto son el grupo de dirección, la junta directiva, el comité de dirección o comité de
gobernanza.

4.5.4. Patrocinador del proyecto

El patrocinador del proyecto es responsable ante una autoridad definida de alto nivel para
alcanzar los objetivos del proyecto, entregar los productos y resultados requeridos, y obtener los
beneficios requeridos.

El patrocinador del proyecto debe adueñarse o defender el caso de negocio o documentación


similar y debe rendir cuentas de la gobernanza de los proyectos, incluida el aseguramiento,
(véase ISO 21505). Además, el patrocinador del proyecto debería:

a) validar que el proyecto esté justificado a lo largo de su ciclo de vida

b) asegurar que el director y el equipo del proyecto sean hábiles y competentes para llevar a
cabo el trabajo asignado

Este documento es una traducción propia y de uso exclusivo de SGS Academy Colombia con fines académicos
No pretende superar al estándar original.
AC-GA-I-F-01-01
V2 – Septiembre 2018
21
c) proporcionar decisiones, dirección, asesoramiento y contexto al director del proyecto, para
cumplir con la necesidad del caso de negocio o documentación similar dentro del nivel
aceptable de riesgo

d) confirmar que la organización está preparada y comprometida con el cambio organizacional,


y que el cambio ocurra (véase 7.14)

e) abordar los incidentes y riesgos crecientes

f) involucrar a las principales partes interesadas, y

g) tomar decisiones dentro de su autoridad delegada.

Un patrocinador del proyecto es a menudo miembro de la junta del proyecto y representa los
intereses y posiciones de ésta, sobre las actividades de gestión de proyectos de rutina o
previamente acordadas. En algunas circunstancias, otras personas pueden apoyar al patrocinador
del proyecto o puede actuar en su nombre para un conjunto definido de responsabilidades. En
tales casos, la división de responsabilidades debe definirse en la organización del proyecto.

NOTA 1: Los términos de uso común para el patrocinador del proyecto incluyen ejecutivo del
proyecto, propietario del proyecto, representante propietario del producto y propietario responsable
principal (véase NOTA 1 y NOTA 2 de la Figura 5).

NOTA 2: Para las prácticas integradas de gestión de proyectos asociadas a un patrocinador del
proyecto, véase 6.4.

4.5.5. Asegurador del proyecto

Si bien el patrocinador del proyecto rinde cuentas por el aseguramiento (véase 4.5.4), las
actividades de aseguramiento pueden ser asignadas a una o más personas independientes del
director del proyecto y del equipo, y que actúan en nombre del patrocinador del proyecto.

4.5.6. Director de proyecto

El director del proyecto es responsable ante el patrocinador del proyecto, o el comité o junta de
dirección del proyecto, de completar el alcance definido del proyecto, y de dirigir y gestionar el
equipo del proyecto. Otras actividades del director del proyecto pueden incluir:

a) establecer el enfoque de gestión y la adhesión al enfoque de gobernanza establecido

b) motivar al equipo del proyecto

c) proporcionar supervisión y liderazgo diarios

d) definir el enfoque, las responsabilidades, el alcance del trabajo y los objetivos del equipo

e) monitorear, pronosticar y reportar el progreso general con respecto al plan del proyecto

Este documento es una traducción propia y de uso exclusivo de SGS Academy Colombia con fines académicos
No pretende superar al estándar original.
AC-GA-I-F-01-01
V2 – Septiembre 2018
22
f) gestionar los riesgos (véase 7.8) e incidentes (véase 7.9)

g) controlar y gestionar los cambios del proyecto (véase 7.10)

h) gestionar el desempeño de los proveedores tal como se define en los contratos pertinentes, y

i) garantizar que el involucramiento y la comunicación de las partes interesadas se lleve a cabo


según lo previsto.

El director del proyecto puede ser asistido por un equipo de gestión de proyectos, con miembros
que asuman roles específicos como programación, control de costos y aseguramiento de la
calidad.

NOTA: Para las prácticas de gestión de proyectos integradas asociadas con un director de
proyecto, ver 6.5, 6.6 y 6.8.

4.5.7. Oficina de proyectos

Una oficina de proyectos, si es necesario, debería tener su función, responsabilidades y línea de


presentación de informes definidas. Las oficinas de proyectos pueden realizar una amplia variedad
de actividades de apoyo al director del proyecto y al equipo, incluyendo el análisis, definición y
gestión de la gobernanza, la estandarización de los métodos y procesos del proyecto, la gestión,
planificación y seguimiento de proyectos, la gestión de la información y el soporte administrativo.

Además, una oficina de proyectos también puede apoyar varios proyectos, combinarse con una
oficina de gestión de programa o portafolio, o realizar funciones como la oficina de gestión de
programas o portafolios.

Las oficinas de proyectos pueden apoyar roles distintos al del director del proyecto, como el
patrocinador del proyecto u otros puestos dentro del equipo del proyecto. Una oficina de proyectos
puede apoyar a las organizaciones en la mejora de la madurez en la gestión de proyectos,
actuando en el rol de centro de competencias o centro de excelencia de gestión de proyectos.

NOTA: Una oficina de proyectos puede denominarse oficina de gestión de proyectos, u otro
término aprobado por la organización.

4.5.8. Líder de paquete de trabajo

Un líder de paquete de trabajo es responsable ante el director del proyecto de liderar, gestionar y
entregar los productos o resultados asignados, tal como se definen en un paquete de trabajo. El
líder del paquete de trabajo o el líder del equipo puede ser parte de la organización patrocinadora
o de una organización de terceros, como un contratista. Las responsabilidades del líder de paquete
de trabajo incluyen, (pero no se limitan a):

a) confirmar que los paquetes de trabajo se completan con la calidad requerida, según lo previsto
y según el presupuesto

Este documento es una traducción propia y de uso exclusivo de SGS Academy Colombia con fines académicos
No pretende superar al estándar original.
AC-GA-I-F-01-01
V2 – Septiembre 2018
23
b) contribuir y revisar la documentación de gestión significativa

c) planificar, supervisar, pronosticar e informar del progreso general, en relación con el plan de
paquetes de trabajo

d) gestionar la resolución de riesgos e incidentes, y escalar algunos

e) controlar los cambios en el alcance de trabajo y solicitar la aprobación de los cambios que
están fuera de su autoridad

f) gestionar el uso óptimo de los recursos para el responsable del paquete de trabajo

g) entregar los resultados finales a los propietarios.

NOTA 1: El director de proyecto puede asumir el rol de líder de paquete de trabajo.

NOTA 2: Para las prácticas integradas de gestión de proyectos asociadas con un líder de paquete
de trabajo, consulte 6.7.

4.5.9. Miembros del equipo del proyecto

Los miembros del equipo del proyecto deberían rendir cuentas ante un líder del paquete de
trabajo o al director del proyecto, por la realización de sus actividades y entregables asignados.

4.5.10. Partes interesadas del proyecto

Las partes interesadas del proyecto son personas, grupos u organizaciones que tienen intereses,
pueden afectar o percibirse afectados por cualquier aspecto del proyecto (véase la Figura 6). Las
partes interesadas del proyecto puede ser internas o externas al proyecto.

Este documento es una traducción propia y de uso exclusivo de SGS Academy Colombia con fines académicos
No pretende superar al estándar original.
AC-GA-I-F-01-01
V2 – Septiembre 2018
24
Ilustración 6 Un ejemplo de las posibles partes interesadas del proyecto

4.5.11. Otros roles

Deberían definirse otras funciones para adaptarse a las necesidades del proyecto y de las partes
interesadas, como un grupo de referencia, usuarios, organizaciones de mantenimiento.

4.6. Competencias del personal del proyecto

Las competencias de gestión de proyectos se pueden clasificar en:

a) competencias técnicas, para dirigir, gestionar, planificar y entregar un proyecto de forma


estructurada, incluyendo los conceptos y prácticas definidas en este documento

b) competencias conductuales, asociadas con relaciones personales, tales como, entre otras,
liderazgo, creación de equipos, gestión de personas, coaching, negociación y gestión de
conflictos, y

c) negocios y otras competencias relacionadas con la gestión del proyecto dentro del entorno
organizacional contractual y externo.

Los miembros del equipo del proyecto que no participen en la gestión del proyecto deben ser
competentes en sus áreas pertinentes, lo que les permite desempeñar sus funciones y
responsabilidades asignadas. Una brecha entre las competencias requeridas y disponibles debe
considerarse como una restricción o riesgo para el proyecto. Las brechas deberían revisarse y
mitigarse. Las competencias pueden mejorarse o aumentarse.

Este documento es una traducción propia y de uso exclusivo de SGS Academy Colombia con fines académicos
No pretende superar al estándar original.
AC-GA-I-F-01-01
V2 – Septiembre 2018
25
5. REQUISITOS PREVIOS PARA FORMALIZAR LA GESTIÓN DE PROYECTOS

5.1. Visión general

Todas las organizaciones llevan a cabo trabajos de proyecto formal o informalmente. Hay varios
requisitos previos que la organización debe considerar antes de establecer un entorno para la
implementación, el mantenimiento y la mejora en la gestión de proyectos. Este entorno a veces se
conoce como el entorno del proyecto o el entorno de gestión de proyectos. El entorno de gestión
de proyectos puede variar de una organización a otra.

Antes de comenzar a formalizar la gestión de proyectos en una organización, los siguientes


elementos deberían evaluarse:

a) beneficios positivos y negativos para la organización, incluidos los impactos en los objetivos
estratégicos, misión, visión y otras consideraciones organizacionales

b) preparar la organización para la implementación de la gestión de proyectos, incluidos los


requisitos de recursos humanos y la estructura organizacional necesaria, los cambios en los
sistemas y procesos, y los

c) impactos en los clientes y otras partes interesadas.

5.2. Consideraciones para la implementación de la gestión de proyectos

Dependiendo de la escala y complejidad de los cambios organizacionales que se realicen, la


implementación de la gestión formal de proyectos en una organización debe gestionarse como un
proyecto, programa o parte de un portafolio. Al considerar la implementación de un enfoque formal
de gestión de proyectos, una organización debería tener en cuenta, (pero no limitarse a), los
siguientes factores:

a) necesidades identificadas y beneficios de la gestión formal de proyectos

b) capacidad para integrar y alinear otros trabajos relacionados con objetivos estratégicos y
empresariales

c) capacidad para absorber los cambios necesarios dentro de la gobernanza, estructura y cultura
de la organización

d) capacidad de recursos de la organización para incorporar el cambio, incluyendo, pero no


limitado a, recursos y presupuesto

e) impactos potenciales en las partes interesadas internas y externas

f) capacidad para trabajar a través de los límites de la organización

g) disponibilidad de las competencias necesarias para implementar el enfoque para futuros


proyectos, y los

Este documento es una traducción propia y de uso exclusivo de SGS Academy Colombia con fines académicos
No pretende superar al estándar original.
AC-GA-I-F-01-01
V2 – Septiembre 2018
26
h) impactos en los presupuestos, riesgos identificados, cronogramas y requisitos de actividades
continuas y planificadas de la organización.

El caso de negocio u otro documento que justifique la implementación de la gestión formal de


proyectos, debe cumplir con lo señalado en 4.3.2.

5.3. Mejora Continua del entorno de gestión de proyectos

La dirección ejecutiva o superior, o la oficina del proyecto (véase 4.5.7), deberían facilitar el medio
ambiente y cultura de mejora continua que busca verificar y mantener la idoneidad, adecuación,
eficacia y eficiencia de la gestión de proyectos dentro de la organización. Esta facilitación debe
incluir factores de ajuste, según sea necesario dentro de la organización, incluyendo, (pero no
limitado a):

a) el establecimiento de un proceso de evaluación para el marco de gestión de proyectos de la


organización con énfasis en verificar la alineación de la estrategia, objetivos del negocio, el
funcionamiento de la organización y la medida en que se están aplicando las lecciones
aprendidas

b) evaluación de la eficacia del marco de gestión de proyectos y su gobernanza

c) determinación y priorización de mejoras y ajustes a aplicar

d) recopilación e implementación de las lecciones aprendidas en beneficio de proyectos actuales


y futuros, y

e) desarrollo de habilidades de gestión de proyectos de personal a través de la capacitación, la


formación y la tutoría.

Las evaluaciones de progreso de la gestión de proyectos también pueden proporcionar


información a la organización para la mejora continua del marco de gestión de proyectos, métodos
y técnicas, y se pueden utilizar en conjunto con el marco identificado en 5.4.

La dirección ejecutiva o superior, o una función de aseguramiento de la calidad o una oficina de


proyectos (véase 4.5.7) podría establecer un cronograma y un enfoque para la evaluación
periódica, que debe:

− facilitar el desarrollo continuo de procesos, métodos y técnicas de gestión de proyectos, y


prever una evaluación recurrente de la madurez de la gestión de proyectos dentro de la
organización, e

− incluir la comunicación a los afectados de cualquier cambio, en cuanto a cómo debe llevar a
cabo la gestión de proyectos en la organización.

Los patrocinadores del proyecto, los directores y sus equipos deberían ser consultados como parte
de cualquier evaluación.

Este documento es una traducción propia y de uso exclusivo de SGS Academy Colombia con fines académicos
No pretende superar al estándar original.
AC-GA-I-F-01-01
V2 – Septiembre 2018
27
5.4. Alineamiento con los procesos y sistemas organizacionales

El marco de gobernanza del proyecto debe estar alineado con otros procesos organizacionales y
sistemas, incluidos entre otros:

a) gobernanza organizacional

b) informes de desempeño

c) procedimientos aplicables y enfoques de entrega pertinentes

d) gestión de riesgos

e) gestión de portafolios y programas

f) inversión y gestión financiera

g) análisis empresarial, planificación estratégica y operativa, y

h) gestión de la información y documentación.

Al alinear las prácticas y sistemas de gestión de proyectos, también debe tenerse en cuenta lo
siguiente:

− estructuras organizativas funcionales y físicas u otras estructuras de modelo prevalecientes

− procedimientos, procesos, planes y sistemas actualmente en conflicto

− métodos y ciclos de comunicación

− disponibilidad y acceso a la tecnología

− contexto de las operaciones de la organización

− equilibrio y optimización de las características sociales, económicas y medioambientales

− sistemas administrativos y de autorización, y

− requisitos de sostenibilidad y supervisión.

Este documento es una traducción propia y de uso exclusivo de SGS Academy Colombia con fines académicos
No pretende superar al estándar original.
AC-GA-I-F-01-01
V2 – Septiembre 2018
28
6. PRÁCTICAS INTEGRADAS DE GESTIÓN DE PROYECTOS

6.1. Visión general

Las prácticas integradas de gestión de proyectos deberían abarcar las prácticas que deberían
utilizarse en las de las actividades previas al proyecto, que se llevan a cabo desde antes de la
decisión de iniciar el proyecto hasta de las actividades de planificación y control posteriores al
proyecto. Esta cláusula identifica las prácticas recomendadas de gestión de proyectos que
deberían utilizarse al emprender un proyecto, fases individuales y otras actividades del proyecto o
grupos de actividades. Las prácticas de la presente Cláusula se basan en los conceptos descritos
en la cláusula 4.

La integración y la adaptación de estas prácticas en un enfoque cohesivo para la gestión del trabajo
del proyecto, puede ser clave para el éxito del proyecto. El propósito de estas actividades es
integrar las prácticas de gestión de proyectos, identificadas en la cláusula 7 para permitir a la
organización del proyecto:

a) alcanzar los objetivos del proyecto

b) definir y gestionar el alcance del proyecto dentro de las restricciones, teniendo en cuenta los
riesgos del proyecto y las necesidades de recursos, y

c) obtener apoyo de cada organización participante y propietarios de recursos, proveedores,


clientes, usuarios y otras partes interesadas.

La gestión de un proyecto debe incluir un enfoque integrado que considere elementos como las
distintas funciones, disciplinas, competencias, factores organizativos y ambientales que influyen
en el éxito del proyecto.

Las prácticas integradas de gestión de proyectos son relevantes y apropiadas para los proyectos
de la mayoría de las organizaciones, independientemente de los procesos o métodos utilizados.
La gestión de proyectos requiere coordinación, por lo tanto, cada actividad debe alinearse y
conectarse con otras actividades, como se muestra en la Figura 4.

Algunas actividades deberían repetirse para definir y cumplir con los requisitos y objetivos del
proyecto. Para aumentar la probabilidad de éxito, el proyecto debe gestionarse de forma integrada
y definida, utilizando métodos y procesos, así como procesos y métodos desarrollados
específicamente para el proyecto.

El enfoque de gestión de proyectos debe adaptarse y aplicarse teniendo en cuenta las


necesidades de la organización, el nivel de riesgo prevaleciente, la competencia de las personas
involucradas y otros proyectos específicos considerados.

La adaptación y aplicación de las prácticas de la Cláusula 6 y la Cláusula 7 deberían llevarse a


cabo de acuerdo con las políticas organizativas pertinentes. Cualquier conflicto entre las políticas
organizativas y las prácticas de gestión de proyectos, deberían resolverse en consulta con el
patrocinador del proyecto.

Este documento es una traducción propia y de uso exclusivo de SGS Academy Colombia con fines académicos
No pretende superar al estándar original.
AC-GA-I-F-01-01
V2 – Septiembre 2018
29
Las prácticas integradas de gestión de proyectos se muestran en la Figura 7, e incluyen las
actividades, las relaciones entre las actividades y los roles asociados (véase 4.5):

Ilustración 7 Vista de las prácticas integradas de gestión de proyectos, las relaciones y roles asociados

Las cláusulas de la 6.2 a la 6.9 describen cada actividad en detalle.

6.2. Actividades previas al proyecto

El propósito de las actividades previas al proyecto es que la organización patrocinadora verifique


que el proyecto vale la pena, comenzando. Las actividades previas al proyecto son aquellas
actividades que deberían llevarse a cabo para tomar la decisión de iniciar un proyecto.

Las necesidades y oportunidades identificadas, resultantes de la estrategia o requisitos


empresariales, deberían evaluarse para permitir a la alta dirección, como a la dirección de la
organización, gestión de portafolios o gestión de programas, identificar proyectos que podrían
transformar algunas o todas estas necesidades y oportunidades en beneficios realizados. Estas
necesidades y oportunidades podrían abordar, por ejemplo, una nueva demanda de mercado, una
necesidad organizacional actual o un nuevo requisito legal. Las necesidades y oportunidades
deberían evaluarse antes de la autorización formal para iniciar un nuevo proyecto.

Los objetivos, beneficios, fundamentos e inversiones del proyecto deberían justificarse y


documentarse con suficientes detalles para permitir que se tome una decisión sobre si se debe
iniciar un proyecto. Dicha documentación podría utilizarse para permitir la priorización de
necesidades y oportunidades. Esta priorización podría estar relacionada con:

a) algún aspecto de la estrategia o plan de negocios de la organización

Este documento es una traducción propia y de uso exclusivo de SGS Academy Colombia con fines académicos
No pretende superar al estándar original.
AC-GA-I-F-01-01
V2 – Septiembre 2018
30
b) necesidades de programas o carteras de mayor nivel, y
c) las necesidades del cliente.
El propósito de dicha justificación es obtener el compromiso organizacional y la aprobación de la
inversión para el proyecto seleccionado junto con una comprensión de las restricciones, riesgos y
suposiciones.

NOTA: La justificación para iniciar el proyecto se puede definir en documentos, como el mandato,
un escrito, una propuesta o un caso de negocios preliminar.

Debe realizarse una evaluación para determinar si el proyecto debe llevarse a cabo en la
organización, a nivel de portafolio o de programa. Dicha evaluación debe basarse en múltiples
criterios, tales como cuantitativos, cualitativos, financieros, alineación con la estrategia
organizacional e impacto social y ambiental. Es probable que los criterios difieran entre diferentes
organizaciones, portafolios, programas y proyectos, dependiendo del contexto.

Antes de la aprobación para iniciar el proyecto, la organización debería:

− identificar al patrocinador del proyecto y al director del proyecto y definir sus responsabilidades
iniciales y autoridades;

− definir acuerdos iniciales de gobernanza, y

− determinar si la organización dispone de recursos y financiación para al menos la primera fase


del proyecto, si no para el proyecto completo.

6.3. Supervisión del proyecto

El propósito de supervisar un proyecto es que la organización patrocinadora esté satisfecha de


que el equipo del proyecto sigue siendo capaz de alcanzar sus objetivos, el proyecto todavía
satisface las necesidades de la organización y expectativas de los titulares, y que los riesgos están
en un nivel aceptable. Esta supervisión se puede hacer a través de:

a) participación en decisiones clave

b) presentación de informes periódicos

c) inspecciones y auditorías de aseguramiento, y

d) escalamiento e intervenciones ad hoc.

Si bien muchas decisiones de alto nivel pueden delegarse en el patrocinador del proyecto, a
menudo es más apropiado que la alta dirección, dentro de la organización patrocinadora,
mantenga algunas decisiones. Las decisiones afectadas por factores ajenos al proyecto, como el
entorno de mercado o la disponibilidad de fondos o recursos, sólo se deberían tomar a un nivel
superior, debido a su impacto en otros proyectos y el trabajo.

La organización patrocinadora debería mantener actualizado al patrocinador del proyecto sobre el

Este documento es una traducción propia y de uso exclusivo de SGS Academy Colombia con fines académicos
No pretende superar al estándar original.
AC-GA-I-F-01-01
V2 – Septiembre 2018
31
contexto más amplio del proyecto, proporcionando orientación y dirección, según sea necesario o
cuando se solicite. La organización patrocinadora debe habilitar al patrocinador del proyecto para
tener tiempo suficiente y llevar a cabo sus responsabilidades eficazmente.

NOTA: Véase 4.5.2 para el papel de la organización patrocinadora en relación con la supervisión
de un proyecto.

6.4. Dirección o patrocinio del proyecto

El objetivo de dirigir un proyecto es permitir que el proyecto siga siendo relevante y justificable en
el contexto organizacional. El patrocinador del proyecto debería confirmar que:

a) se está abordando una necesidad organizacional real, se está comunicando la visión y los
objetivos con supuestos estratégicos y se han establecido criterios para medir el éxito del
proyecto

b) la justificación continua del proyecto y la actualización del caso de negocio o documento


equivalente, si es requerido por la gobernanza organizacional

c) la solución, en términos de productos, resultados y beneficios esperados, es probable que


satisfaga las necesidades de la organización, y

d) el trabajo finaliza cuando ya no se admite la justificación organizativa.

6.5. Inicio del proyecto

6.5.1. Visión general

El propósito de iniciar un proyecto es planificarlo, definir la organización del proyecto, movilizar el


equipo del proyecto, definir la gobernanza y gestión del proyecto, identificar a las partes
interesadas y verificar que el proyecto está justificado.

Deberían tenerse en cuenta las lecciones aprendidas de proyectos anteriores y pertinentes. Las
actividades pueden ser iterativas, hasta que se desarrolle una solución y un plan aceptable y se
pueda iterar aún más en fases del proyecto.

NOTA: 'Inicio del proyecto' también puede denominarse "iniciación del proyecto" o "iniciar el
proyecto".

6.5.2. Movilización del equipo del proyecto

El director del proyecto debe movilizar el equipo, las instalaciones, el equipamiento y otros
recursos necesarios para llevar a cabo el proyecto.

El equipo debe comprender sus funciones y los requisitos del proyecto, suposiciones, restricciones
y riesgos potenciales.

Este documento es una traducción propia y de uso exclusivo de SGS Academy Colombia con fines académicos
No pretende superar al estándar original.
AC-GA-I-F-01-01
V2 – Septiembre 2018
32
Los trabajos del proyecto deberían llevarse a cabo por equipos multifuncionales y asignarse a
personas que son competentes para lograr el rol y tienen la capacidad de entregar los resultados
esperados. (Véase 7.5 para obtener más información).

6.5.3. Enfoque de gobernanza y de gestión de proyectos

El marco de gobernanza y de gestión debería definirse para proporcionar dirección y métodos a


las personas involucradas en el proyecto. Los marcos de gobernanza y gestión, así como como
controles, deberían ser proporcionados y apropiados para el trabajo a realizar y su grado esperado
de complejidad.

El director del proyecto debería definir la forma en que se va a iniciar, dirigir, controlar y cerrar el
proyecto, cumpliendo con los requisitos de gobernanza (véase 4.3). Normalmente, esto debería
incluir:

a) ciclo de vida del proyecto (véase 4.4)

b) organización del proyecto, funciones y responsabilidades (véase 4.5)

c) procesos y métodos para llevar a cabo las actividades de gestión descritas en 6 y 7, y

d) procesos y métodos para entregar los resultados y resultados del proyecto (véase 6.7).

El enfoque de gestión de proyectos se puede describir en un sólo documento general único con
un conjunto de documentos subsidiarios que abarquen prácticas específicas, como un plan de
gestión de riesgos o calidad, (véase ISO 21505).

NOTA: Los nombres de los documentos que describen el enfoque de gestión pueden diferir.
Nombres de ejemplo: incluyen plan de gestión de proyectos, documentación de iniciación de
proyectos, documento de definición de proyecto, plan de ejecución de proyecto, acta de
constitución de proyecto y mandato del proyecto. Documentos subsidiarios para las prácticas de
gestión de proyectos a veces se denominan "planes de gestión", por ejemplo, plan o estrategia de
gestión de los riesgos, plan o estrategia de gestión de la calidad, plan o estrategia de gestión del
alcance.

6.5.4. Justificación inicial del proyecto

La justificación inicial del proyecto debe basarse en la justificación preliminar de las actividades
previas al proyecto (véase el punto 6.2). Esta justificación debe documentarse en un caso de
negocios o documento equivalente (véase 4.3.2). El caso de negocio se puede desarrollar en
varias fases del proyecto a medida que avanza el trabajo y debe actualizarse para reflejar cambios
significativos en el contexto y el alcance del proyecto.

Un proyecto debe justificarse y regirse a través de un caso de negocios o documento equivalente,


que demuestre la alineación con la estrategia de la organización, viabilidad financiera, viabilidad
comercial y practicidad de entrega dentro de un nivel aceptable de riesgo. Deberían evaluarse las
alternativas y proveer el motivo de rechazo. Si un proyecto forma parte de un programa, su caso

Este documento es una traducción propia y de uso exclusivo de SGS Academy Colombia con fines académicos
No pretende superar al estándar original.
AC-GA-I-F-01-01
V2 – Septiembre 2018
33
de negocio puede incluirse dentro del caso de negocios del programa.

NOTA: Si bien el documento que justifica la realización de un proyecto, a menudo se denomina


caso de negocio, el nombre utilizado puede cambiar de un sector a otro o el método utilizado.

6.5.5. Planificación inicial del proyecto

Se debe desarrollar un plan inicial para el proyecto con hitos y compuertas o puntos de decisión,
basados en el ciclo de vida del proyecto combinado con un plan detallado, para al menos la fase
inmediata del proyecto. Se debería considerar la transición de productos a operaciones o al cliente,
si la transición se considera parte del proyecto. En esta etapa temprana del proyecto, esta
consideración podría incluir varias opciones, que podrían desarrollarse más adelante en fases
posteriores del proyecto (véase el punto 7.2).

6.6. Control de un proyecto

6.6.1. Visión general

El objetivo de controlar un proyecto, incluidas las fases y los paquetes de trabajo, es supervisar y
medir contra un plan acordado, incluidos los cambios aprobados. El director del proyecto debe
construir en el plan de proyecto inicial (véase 6.5.5), añadiendo detalles a medida que se diseñan
las actividades, entregables o productos, y desarrollado y reflejando los cambios aprobados, según
sea necesario (véase 7.2).

6.6.2. Justificación progresiva

La justificación del proyecto puede desarrollarse a lo largo de varias fases del proyecto, para
diferentes opciones, a medida que avanza el trabajo. El caso de negocio debería actualizarse para
reflejar los cambios en el contexto y alcance. El caso de negocio debe ser confirmado por el
patrocinador del proyecto antes de cada compuerta o punto de decisión para validar la
continuación del proyecto.

6.6.3. Gestión del desempeño del proyecto

El patrocinador del proyecto apoyado o supervisado por el comité o junta de dirección del proyecto,
debería revisar regularmente los productos y resultados necesarios para asegurarse de que
cumplen con los requisitos. El equipo del proyecto debe revisar periódicamente los productos y
resultados necesarios para cumplir con los requisitos.

El director del proyecto debe supervisar y verificar el desempeño del equipo del proyecto, para
llevar a cabo el trabajo asignado a ellos en el plan del proyecto para:

a) integrar el trabajo del equipo del proyecto en trabajos posteriores del proyecto, y

b) confirmar que es probable que el proyecto entregue lo que se requiere en un nivel aceptable
de riesgo y recomendar cambios controlados autorizados.

Este documento es una traducción propia y de uso exclusivo de SGS Academy Colombia con fines académicos
No pretende superar al estándar original.
AC-GA-I-F-01-01
V2 – Septiembre 2018
34
El director del proyecto debe recopilar y analizar los datos de progreso y desempeño, para evaluar
el progreso en relación con el plan de proyecto acordado, que incluye:

− trabajo completado, hitos alcanzados y costos gastados (véase el punto 7.2)

− beneficios planificados o realizados (véase el punto 7.3)

− gestión del alcance (véase 7.4)

− adquirir recursos suficientes para completar el trabajo (véase el punto 7.5)

− gestión del cronograma y de los costos (véanse los puntos 7.6 y 7.7)

− identificar y gestionar riesgos e incidentes. (véanse los puntos 7.8 y 7.9)

− controlar las solicitudes de cambio (véase 7.10)

− calidad del trabajo (véase 7.11)

− estado del involucramiento y de las comunicaciones planificadas y previstas de las partes


interesadas (véanse las 7.12 y 7.13)

− gestionar la transición de los productos a la organización o cliente patrocinador, y prepararse


para la gestión del cambio organizacional (véase 7.14)

− presentación de informes sobre el progreso (véase el punto 7.15)

− mantener la integridad y la disponibilidad de la información y la documentación (véase 7.16)

− gestión del estado de las actividades de contratación (véase 7.17), y

− nuevas lecciones aprendidas (véase 7.18).

El director del proyecto debería proporcionar al patrocinador del proyecto, al equipo del proyecto
y a las partes interesadas seleccionadas una descripción del estado actual y el desempeño del
proyecto, en consonancia con el plan de proyecto (véase 7.15). Debería incluirse una proyección
para el desempeño futuro del proyecto.

El director del proyecto debería gestionar las distintas actividades técnicas, administrativas y
organizativas, e interfaces dentro del proyecto. Las acciones preventivas y correctivas deberían
documentarse e implementarse, y las solicitudes de cambio (véase 7.10), cuando sea necesario,
para mantener el proyecto en la finalidad de seguir alcanzando los objetivos del proyecto.

6.6.4. Gestión del inicio y cierre de cada fase del proyecto

Este documento es una traducción propia y de uso exclusivo de SGS Academy Colombia con fines académicos
No pretende superar al estándar original.
AC-GA-I-F-01-01
V2 – Septiembre 2018
35
Con la asistencia de líderes de paquetes de trabajo u otros expertos en la materia, el director del
proyecto debería prepararse para iniciar cada fase del proyecto:

a) preparar o revisar un plan detallado para la fase

b) revisar los requisitos de gobernanza y de gestión

c) confirmar que el proyecto sigue estando justificado

d) revisar el enfoque de gestión para reflejar el trabajo requerido en la fase, y

e) obtener la aprobación para iniciar la siguiente fase.

Una vez aprobado el inicio de la fase, el director del proyecto debería movilizar al equipo y a otros
recursos y comenzar a trabajar. El director del proyecto debería confirmar la finalización de cada
fase del proyecto, (pero limitado a):

− confirmar las adquisiciones completadas, canceladas o suspendidas

− verificar las acciones incompletas y registrar los incidentes cerrados

− liberar o hacer la transición de recursos, si ya no son necesarios

− archivar la documentación de acuerdo con la directiva de retención de información de la


organización

− verificar los productos y resultados completados, entregados y aceptados, y

− registrar las lecciones de aprendidas.

6.6.5. Gestión del inicio, progreso y cierre de cada paquete de trabajo

El director del proyecto debe supervisar los paquetes de trabajo dentro de cada fase:

a) verificar y aprobar el plan para cada paquete de trabajo, después de asegurarse de que es
coherente y se integra con el plan general para el proyecto y la fase respectiva

b) asegurar el trabajo de integración y los resultados entre paquetes de trabajo se planifiquen y


se lleven a cabo, y cumplan los requisitos

c) asignar la responsabilidad de cada paquete de trabajo a un líder de paquete de trabajo

d) iniciar los paquetes de trabajo de acuerdo con el plan de proyecto o en respuesta a un riesgo
o incidente

e) verificar el progreso del trabajo, incluyendo abordar cualquier riesgo, incidente o solicitud de
cambio

Este documento es una traducción propia y de uso exclusivo de SGS Academy Colombia con fines académicos
No pretende superar al estándar original.
AC-GA-I-F-01-01
V2 – Septiembre 2018
36
f) verificar la calidad de los entregables, y

g) confirmar la finalización y el cierre del paquete de trabajo.

6.7. Gestión de la entrega

El propósito de gestionar la entrega es definir los productos y resultados requeridos, y planificar e


implementar su entrega permitiendo que se logren los resultados del proyecto y se realicen
beneficios.

El trabajo del proyecto se puede organizar en paquetes de trabajo para la asignación y el control
de los trabajos realizados por varios equipos. Los paquetes de trabajo deberían asignarse al líder
del paquete de trabajo (véase 4.5.8). El trabajo de debería definir, planificar, supervisar y controlar
adecuadamente, y la calidad debe gestionarse activamente.

Los métodos y procesos de trabajo deben adaptarse para su uso y maximizar la probabilidad de
éxito dentro del entorno del proyecto. El líder del paquete de trabajo debe gestionar la entrega de
sus paquetes de trabajo, (pero no limitado a):

a) movilizar al equipo

b) abordar los riesgos, los incidentes, las solicitudes de cambio y las expectativas de las partes
interesadas (véanse 7.8, 7.9, 7.10 y 7.12)

c) gestionar los proveedores, si los hubiera (véase 7.17)

d) desarrollar de los entregables requeridos, utilizando métodos y técnicas apropiadas y


proporcionadas (véase 7.11)

e) verificar y validar los resultados

f) mantener informado al director del proyecto del progreso del paquete de trabajo (véase 7.15)

g) escalar cualquier riesgo, incidente o solicitud de cambio (véase 7.15)

h) capturar y aplicar las lecciones aprendidas (véase 7.18), y

i) cerrar el paquete de trabajo una vez que haya sido confirmado como completado por el director
del proyecto (véase 6.6.4).

El líder del paquete de trabajo debe supervisar, medir y controlar el trabajo asignado en el plan del
proyecto, utilizando las prácticas definidas en la Cláusula 7. Se deberían tomar medidas
preventivas y correctivas, y ejecutar las solicitudes de cambo, cuando sea necesario, para alcanzar
los objetivos de trabajo asignados.
6.8. Cierre o terminación del proyecto

El objetivo de cerrar un proyecto es confirmar la finalización del alcance del proyecto, y señalar las

Este documento es una traducción propia y de uso exclusivo de SGS Academy Colombia con fines académicos
No pretende superar al estándar original.
AC-GA-I-F-01-01
V2 – Septiembre 2018
37
actividades no completadas en el caso de rescisión para permitir la realización de beneficios
posteriores al proyecto y para gestionar la desmovilización de los recursos e instalaciones
restantes.

Antes de que el proyecto se cierre, si no fuera debido a rescisión (terminación anticipada), la


finalización de todas las actividades debe verificarse para confirmar que el alcance del proyecto
ha sido completado, y cada paquete de trabajo se ha completado o terminado. Además, cuando
aplique, deberían acordarse y aceptarse responsabilidades operativas en curso.

Si el proyecto forma parte de un programa o portafolio, la responsabilidad del seguimiento de las


acciones, riesgos e incidentes deberían transferirse al director del programa o del portafolio. Si el
proyecto no forma parte de un programa o portafolio existente, debe determinarse si el material no
utilizado en el proyecto debe transferirse a una autoridad de gestión adecuada u otro designado
para seguimiento y gestión.

Cualquier contrato que se estableciera para lograr parte del alcance del proyecto debe revisarse,
verificarse su estado y, si aplica, cerrarse formalmente (véase 7.17).

El director del proyecto, con el patrocinador del proyecto, los miembros clave del equipo y las
partes interesadas, deberían realizar una revisión del cierre. La revisión del cierre debería evaluar
el desempeño del plan y la medida en que los objetivos se cumplieron. La revisión del cierre del
proyecto debería documentarse formalmente, y la documentación debería utilizarse como base
para aprobar el cierre del proyecto. El patrocinador del proyecto debería aceptar planes para
cualquier revisión, posterior al cierre.

Debería llevarse a cabo una revisión de las lecciones aprendidas a lo largo del proyecto, incluidas
las recomendaciones para mejoras, a tener en cuenta en la gestión de proyectos similares y otros
proyectos futuros (véase 7.18). Dicha revisión puede ser parte de cualquier revisión formal de
cierre o realizada como una actividad separada.

Las partes interesadas deberían ser informadas sobre el cierre. Deberían adoptarse medidas para
permitir la entrega de los productos, resultados si corresponde y cualquier acción de gestión de
cambios organizacionales relacionada, incluyendo la realización de beneficios habilitantes durante
la entrega. También deberían adoptarse medidas para la realización continua de beneficios y
gestión de valor.

Antes de la finalización, un proyecto podría necesitar ser rescindido por el patrocinador del
proyecto u organización patrocinadora, por las siguientes razones, incluyendo, (pero no limitado
a):

a) proyecto que ya no sea necesario ni viable

b) los riesgos asociados con él que se han vuelto inaceptablemente altos, y

c) el cliente externo que ya no requiere los productos.

A menos que existan razones especiales, la terminación anticipada de un proyecto debe

Este documento es una traducción propia y de uso exclusivo de SGS Academy Colombia con fines académicos
No pretende superar al estándar original.
AC-GA-I-F-01-01
V2 – Septiembre 2018
38
comprender actividades similares a la finalización de un proyecto, aunque es posible que no haya
un producto final para entregar. En el caso de la terminación anticipada del proyecto, se deberían
tomar las siguientes medidas:

− confirmar y documentar las actividades completadas, incluidas las actividades emprendidas


por los proveedores;

− documentar las actividades no completadas;

− confirmar los entregables que deberían transferirse al cliente;

− registrar el estado de los paquetes de trabajo;

− recopilar y archivar documentos de proyectos, de conformidad con la política organizativa


vigente;

− liberar recursos e instalaciones del proyecto;

− acordar cualquier responsabilidad operativa en curso, y

− Cerrar o rescindir órdenes de trabajo y contratos según sea necesario.

6.9. Actividades posteriores al proyecto

El propósito de las actividades posteriores al proyecto es verificar que los resultados son
sostenibles y los beneficios se están realizando.

El patrocinador del proyecto, para proyectos en el marco de programas o portafolios o con


actividades posteriores al cierre, debería garantizar que se lleve a cabo una revisión para
determinar el grado del éxito del proyecto al:

a) cumplir los objetivos definidos

b) realizar los beneficios

c) entregar cambios o resultados organizacionales, como el rendimiento operativo, y

d) lograr cambios sostenibles, incluyendo seguir cumpliendo con las expectativas establecidas
en el caso de negocio.

NOTA: Los beneficios pueden incluirse o no en el alcance del proyecto. Las lecciones aprendidas
deberían ser capturadas y comunicadas (véase 7.18).

Este documento es una traducción propia y de uso exclusivo de SGS Academy Colombia con fines académicos
No pretende superar al estándar original.
AC-GA-I-F-01-01
V2 – Septiembre 2018
39
7. PRÁCTICAS DE GESTIÓN PARA UN PROYECTO

7.1. Visión general

Esta cláusula describe las prácticas individuales de gestión de proyectos que deberían estar
presentes a lo largo de un proyecto y que se puede utilizar al realizar las prácticas integradas de
gestión de proyectos descritas en la cláusula 6. Estas prácticas se muestran en la Figura 8.

La aplicación de los conceptos y prácticas descritos aquí, puede variar en énfasis para un proyecto
determinado dependiendo del contexto del proyecto y el enfoque de entrega utilizado.

Ilustración 8 Prácticas de gestión de proyectos en relación con la gestión integrada de proyectos

Este documento es una traducción propia y de uso exclusivo de SGS Academy Colombia con fines académicos
No pretende superar al estándar original.
AC-GA-I-F-01-01
V2 – Septiembre 2018
40
7.2. Planificación

7.2.1. Visión general

El propósito de la planificación es definir los requisitos, entregables, productos, resultados y


restricciones, y determinar cómo deberían lograrse los objetivos del proyecto. Al desarrollar un
plan, deberían considerarse diferentes soluciones, enfoques de entrega y opciones de
implementación.

7.2.2. Desarrollo del plan


La planificación debe ser una actividad colaborativa, siempre que sea posible, involucrando a
miembros del equipo, asesorando en la planificación de su trabajo. Las estimaciones deberían ser
justificables. Un plan puede incluir:

a) beneficios a realizar (véase 7.3)

b) alcance: productos y resultados a entregar (véase 7.4), teniendo en cuenta la calidad (véase
7.11)

c) recursos necesarios, como personas, materiales, herramientas y equipos, y otras


organizaciones (véase 7.5)

d) cronograma: cuándo se van a realizar las actividades (véase el punto 7.6)

e) costo (véase 7.7), y

f) riesgos inherentes al plan (véase el punto 7.8), incluidos los supuestos y restricciones.

Las dependencias entre las actividades y otros componentes de trabajo (como programas y
proyectos) deberían ser definidos. El plan debe incluir y permitir actividades de aseguramiento y
toma de decisiones. El plan se puede basar en una jerarquía que muestre el lugar de cada
componente de trabajo en la jerarquía, con un sólo punto de responsabilidad asignada por cada
paquete de trabajo y actividad.

Los planes deberían ser vistos a diferentes niveles de la jerarquía y mostrar el nivel de detalle
adecuado a las necesidades de aquellos que ven el plan. La planificación puede ser iterativa y
progresiva a través del ciclo de vida de un proyecto, con más detalles para el futuro inmediato que
para un trabajo más distante. A medida que avanza el trabajo, el alcance podría ser refinado y
aclarado, desarrollando un plan que pueda ser entregado a un nivel aceptable de riesgo. Un plan
puede incluir una indicación del nivel actual de certeza mediante, por ejemplo, utilización de rangos
o indicadores de confianza.

7.2.3. Seguimiento del plan

El plan debe ser coherente e integrado. El plan debería ser suficientemente detallado para
establecer líneas de base. Dichas líneas de base pueden reflejar cualquier aspecto del plan, como
los requisitos, el alcance, la calidad, la programación, costos, recursos y riesgos. Los cambios en
un plan de referencia deberían llevarse a cabo de manera controlada (véase 7.10).

Este documento es una traducción propia y de uso exclusivo de SGS Academy Colombia con fines académicos
No pretende superar al estándar original.
AC-GA-I-F-01-01
V2 – Septiembre 2018
41
Una vez aprobada, los progresos realizados en la línea de base del plan deberían supervisarse y
analizarse periódicamente para reportar en los informes (véase 7.15). Deberían hacerse
previsiones de actividades futuras, teniendo en cuenta el progreso hasta la fecha y las
suposiciones y riesgos prevalecientes. Los planes deberían revisarse, especialmente antes de
puntos de decisión significativos, como las compuertas del proyecto.

7.3. Gestión de beneficios

7.3.1. Visión general

El propósito de la gestión de beneficios es ayudar a la organización patrocinadora y al cliente a


alcanzar los beneficios requeridos de los resultados del proyecto, como se describe en el caso de
negocios del proyecto u otra documentación similar. Los beneficios deberían ser una parte
integrada del plan del proyecto, si la realización de beneficios está dentro del alcance del proyecto
(véase 7.2).

Los beneficios requeridos deberían ser identificados, analizados, priorizados, documentados y


comunicados a las partes interesadas del proyecto. Deberían definirse las actividades previstas
para facilitar el seguimiento y el control de los beneficios deseados.

7.3.2. Identificación y análisis de beneficios

La identificación y el análisis de beneficios deberían comenzar cuando se está considerando el


proyecto potencial (véase la 6.2). Los beneficios son determinados principalmente por el
patrocinador del proyecto y deberían documentarse en un caso de negocios u otro documento
similar y se pueden detallar más en otra documentación justificativa. Los entregables se pueden
utilizar para crear productos, cambios de negocio o resultados, que a su vez pueden generar
beneficios para la organización patrocinadora o el cliente.

Una vez establecido el proyecto con un caso de negocio o documentación similar, una relación
más detallada de los beneficios a realizar deberían ser identificados, analizados, priorizados y
decididos por el patrocinador del proyecto u otro organismo autorizado, como un comité directivo
o una junta de proyectos (véase 4.5).

La identificación y el análisis de beneficios deberían incluir, (pero no se limitan a):

a) identificar y priorizar los beneficios esperados

b) identificar posibles impactos negativos de los beneficios esperados

c) identificar el alcance de cualquier cambio de negocio necesario

d) identificar a las partes interesadas para cada beneficio a realizar

e) alinear los beneficios con la estrategia y otros objetivos

f) definir métricas de desempeño e informes para cada beneficio

Este documento es una traducción propia y de uso exclusivo de SGS Academy Colombia con fines académicos
No pretende superar al estándar original.
AC-GA-I-F-01-01
V2 – Septiembre 2018
42
g) determinar plazos para la realización de beneficios, y

h) verificar que sea probable que los productos y resultados planificados permitan realizar los
beneficios requeridos.

NOTA: Los proyectos potenciales se tratan en el período previo al proyecto (véase 6.2 y la Figura
7).

7.3.3. Monitoreo de los beneficios

El seguimiento de los beneficios incluye, (pero no se limita a):

a) monitorear el progreso a lo largo del ciclo de vida del proyecto, hacia el logro de resultados y
su impacto en la realización de los beneficios previstos

b) recoger mediciones de desempeño para cada beneficio

c) informar y comunicar el estado de los beneficios esperados, e

d) identificar beneficios adicionales a lo largo del ciclo de vida del proyecto.

Los beneficios previstos pueden verse afectados por los cambios en el plan. El director del
proyecto debería informar al patrocinador del proyecto de cualquier impacto potencial, resultante
de cualquier cambio en el plan (véase 7.10).

Los beneficios se pueden realizar durante el proyecto, al final del proyecto o después de que el
proyecto se haya cerrado. Antes del final del proyecto, la responsabilidad de la futura realización
de los beneficios, si los hubiere, debe transferirse a las partes interesadas responsables de realizar
los beneficios actuales o futuros.

7.3.4. Mantenimiento de beneficios

Si dentro del alcance del proyecto hay desviaciones en relación con los beneficios planificados, se
deberían emprender acciones correctivas y cuando sea necesario, acciones preventivas.

7.4. Gestión del alcance

7.4.1. Visión general

El propósito de la gestión del alcance es facilitar la creación de los productos, los entregables y los
resultados, para alcanzar los objetivos declarados por la organización patrocinadora o cliente.

La gestión del alcance permite que sólo se incorporen al proyecto los trabajos aprobados
formalmente. El alcance debe ser una parte integrada del plan del proyecto (véase 7.2).

Debería definirse el alcance (véase 7.4.2) y deberían llevarse a cabo actividades de gestión para
permitir la gestión de desviaciones del alcance y confirmar la entrega del alcance.

Este documento es una traducción propia y de uso exclusivo de SGS Academy Colombia con fines académicos
No pretende superar al estándar original.
AC-GA-I-F-01-01
V2 – Septiembre 2018
43
7.4.2. Definición del alcance

La definición del alcance debe aclarar lo que el proyecto tiene previsto para contribuir a los
objetivos de la organización patrocinadora o cliente. Deberían acordarse criterios de aceptación
asociados. El alcance debería utilizarse como un factor a tener en cuenta en futuras decisiones,
así como al comunicar la importancia del proyecto y sus beneficios. El alcance debería reflejar los
requisitos y sus criterios de aceptación y debería perfeccionarse aún más como parte de la
planificación.

El trabajo autorizado que forma parte del alcance del proyecto puede definirse en términos de
objetivos de proyecto, mapas o en una estructura de desglose del trabajo. Según sea procedente,
el alcance debería ser elaborado y desglosado en paquetes de trabajo. El desglose identifica,
define y documenta el trabajo necesario para para la planificación, (véase Referencia [7] en la
Bibliografía).

7.4.3. Control del Alcance

El control del alcance debería implicar la maximización de los impactos positivos y minimización
de los impactos negativos del proyecto, de los cambios de alcance (véase 7.10). El estado actual
del alcance debe compararse con la línea base aprobada para determinar cualquier desviación.

El control del alcance también debería preocuparse por influir en los factores que proporcionan
cambios de alcance y controlar el impacto de esos cambios en los objetivos del proyecto.

Las solicitudes de cambios al alcance deberían gestionarse de forma controlada e integrarse con
otros controles de dominios (véase 7.10).

7.4.4. Confirmación de la entrega del alcance

Los resultados que comprenden el alcance deberían confirmarse de conformidad con los criterios
de aceptación definidos, que incluyen:

a) verificar y validar que se han cumplido los requisitos de calidad y los estándares de calidad del
proyecto (véase 7.11)

b) confirmar que la organización patrocinadora o el cliente están listos para recibir los resultados
del proyecto

c) gestionar la entrega de productos del equipo del proyecto a la organización patrocinadora o


cliente, y

d) obtener la confirmación de que se completó la entrega.

NOTA:
Consulte 7.14 para realizar la transición al cambio organizacional.

Este documento es una traducción propia y de uso exclusivo de SGS Academy Colombia con fines académicos
No pretende superar al estándar original.
AC-GA-I-F-01-01
V2 – Septiembre 2018
44
7.5. Gestión de los recursos

7.5.1. Visión general

El propósito de la gestión de recursos es determinar los recursos, la calidad, la cantidad y


optimización necesaria para entregar el alcance del proyecto. Los recursos deberían ser una parte
integrada del plan del proyecto (véase 7.2).

Los recursos del proyecto pueden incluir personas, instalaciones, equipos, materiales,
infraestructura y herramientas. Los recursos podrían considerarse en la planificación, estimación,
gestión y control de los recursos para determinar la calidad de los recursos, cantidad y optimización
necesaria para alcanzar los objetivos del proyecto.

Las personas involucradas en la gestión de los recursos deberían entender los aspectos críticos
en materia de competencia, experiencia, disponibilidad, comportamiento y cultura. Los requisitos
y atributos, como el origen, el tiempo necesario y las fechas de inicio y finalización, para los
recursos deberían definirse, registrarse y actualizarse según sea necesario.

Los conflictos en la disponibilidad de recursos pueden ocurrir debido a circunstancias inevitables,


como falla en los equipos, clima, malestar laboral, incidentes técnicos o demandas competitivas
de otros proyectos. Tales circunstancias pueden requerir actividades de reprogramación y dar
lugar a cambios en los requisitos de recursos para actividades en curso o posteriores. Los recursos
deberían planificarse, de forma que estén disponibles cuando sea necesario e incluir reservas para
cubrir la intervención oportuna de las acciones preventivas y correctivas apropiadas.

Deberían establecerse procedimientos para identificar los riesgos e incidentes que faciliten la
reasignación de los recursos y la obtención de recursos adicionales (véanse 7.8 y 7.9).

7.5.2. Planificación de la organización del proyecto

Los recursos humanos involucrados en la labor deberían justificarse y asignarse de acuerdo con
los roles y responsabilidades necesarias para completar el trabajo. Estas responsabilidades
deberían definirse de acuerdo con la organización específica del proyecto, que debería estar
alineada con los niveles adecuados del trabajo (véase 4.5).

Una organización de proyectos puede definirse e influir en varios factores, como las estructuras
permanentes, políticas, entorno del proyecto y tipo de proyecto. En la planificación de la
organización del proyecto, deberían tenerse en cuenta las necesidades, oportunidades y requisitos
de las partes interesadas del proyecto.

La planificación y selección de recursos humanos debe abordar varios factores tales como, pero
no limitado a, fuentes internas o externas, competencias, requisitos legales aplicables y relevantes,
período y tiempo de compromiso, calendarios y requisitos de desarrollo y capacitación.

7.5.3. Establecimiento del equipo

Este documento es una traducción propia y de uso exclusivo de SGS Academy Colombia con fines académicos
No pretende superar al estándar original.
AC-GA-I-F-01-01
V2 – Septiembre 2018
45
El establecimiento del equipo incluye la adquisición de los recursos necesarios y proporcionarles
instrucciones para llevar a cabo su trabajo. La ubicación de trabajo, el compromiso, los roles y
responsabilidades, así como los requisitos de informe deberían ser establecidos. El director del
proyecto debería determinar cómo y cuándo los miembros del equipo del proyecto deberían ser
adquiridos y asignados al proyecto, así como cómo y cuándo deberían ser liberados del proyecto.

Es posible que el director del proyecto no tenga un control total sobre la selección de los miembros
del equipo del proyecto. Cuando sea procedente, los líderes de paquetes de trabajo deberían
participar en la selección de los miembros del equipo del proyecto, asignados para trabajar en sus
paquetes.

Normalmente, se debe establecer un equipo al inicio de cada fase del proyecto o paquete de
trabajo. La composición del equipo debería ser reevaluada y revisada, si es necesario. Al
establecer un equipo, el proyecto debería tener en cuenta factores como las habilidades y la
experiencia, la cultura, el costo y la dinámica del grupo

Cuando los recursos humanos no están disponibles dentro de la organización, se debe considerar
la adquisición o la contratación de recursos.

7.5.4. Desarrollo al equipo

El desarrollo de un equipo tiene como objetivo ayudar a los miembros del equipo a trabajar juntos
de una manera cohesiva y colaborativa. Este desarrollo podría depender de las competencias del
equipo del proyecto, requerir mejoras en el desempeño y en la interacción de los miembros del
equipo de manera continua, para mejorar el compromiso del equipo, la motivación y el desempeño.

Las normas básicas de comportamiento aceptable deberían establecerse al principio del proyecto
para evitar malentendidos y conflictos. Las brechas de competencias deberían identificarse y
cerrarse a través de formación, coaching y otras iniciativas, implicando acciones para mejorar la
dinámica de grupo y su crecimiento.

7.5.5. Gestión del equipo

La gestión del equipo debería tener como objetivo motivar al equipo y mantener un ambiente de
trabajo positivo, donde los miembros del equipo se sientan involucrados, rindan lo mejor posible y
se centren en el trabajo asignado y los objetivos del proyecto. El director del proyecto debe tratar
de optimizar el desempeño del equipo proporcionando retroalimentación, resolviendo disputas
personales y fomentando el trabajo colaborativo.

Los conflictos deberían evitarse, y si ocurren, deberían ser manejados adecuadamente, de


acuerdo con la situación. Los estilos de liderazgo y de gestión apropiados deberían adoptarse
mediante la negociación, asertividad, empatía y decisiones basadas en la evidencia, según
corresponda.

Los requisitos de recursos deberían actualizarse o revisarse, según sea necesario, con cualquier
incidente planteado y resuelto, o escalarse si estuviera fuera de la autoridad del director del

Este documento es una traducción propia y de uso exclusivo de SGS Academy Colombia con fines académicos
No pretende superar al estándar original.
AC-GA-I-F-01-01
V2 – Septiembre 2018
46
proyecto.
La información debe recopilarse, como insumo para las evaluaciones del desempeño del personal
y para las lecciones aprendidas. Las evaluaciones del equipo y del personal y el monitoreo del
desempeño deben realizarse en consulta, según corresponda, con el líder del paquete de trabajo,
el gerente del proyecto, el patrocinador del proyecto y el gerente de línea de la persona.

7.5.6. Planificación, gestión y control de recursos físicos y materiales

La disponibilidad y el uso de los recursos físicos y materiales deberían planificarse, gestionarse y


controlarse. Con este objetivo, el director del proyecto y la organización del proyecto a menudo
deben considerar soluciones costo-beneficio, de acuerdo con las disponibilidades de recursos y
los requisitos del proyecto.

Recursos, como materiales, equipos, instalaciones, laboratorios y herramientas, deben


planificarse de acuerdo con su criticidad, disponibilidad y plazos de entrega. Esta planificación de
recursos a menudo debe coordinarse con la planificación de recursos humanos, competencias y
presupuesto.
La gestión de equipos y de recursos materiales deben coordinarse con la programación del
proyecto (véase 7.6) y tener en cuenta situaciones potencialmente conflictivas, como los riesgos
de falta de disponibilidad y fallos en la entrega. Deberían tenerse en cuenta los recursos
alternativos y las asignaciones de recursos.

El desempeño y la productividad de los recursos y la medida en que se están cumpliendo los


objetivos, deben ser revisados. Cuando sea necesario, se deberían tomar medidas preventivas y
correctivas.

7.6. Gestión del cronograma

7.6.1. Visión general

El objetivo de la gestión del cronograma es permitir que los trabajos se lleven a cabo en tiempo,
de forma que los retrasos se reduzcan a un nivel aceptable. El cronograma debe ser una parte
integrada del plan del proyecto y desarrollado bajo la dirección del director del proyecto (véase
7.2).

La gestión del cronograma debe implicar actividades de secuenciación, estimación de la duración


de las actividades y desarrollo y control del cronograma, según lo comprometido con el equipo
asignado o afectado por el trabajo. Las actividades deben secuenciarse lógicamente para apoyar
el desarrollo de un cronograma de proyecto controlable. Las actividades dentro del proyecto deben
describirse con dependencias para determinar la ruta crítica o para identificar enfoques
alternativos.

El director del proyecto debe monitorear el progreso realizado en la línea base de programación
aprobada para permitir que el alcance del proyecto entregue a tiempo, y dentro de las restricciones
y objetivos establecidos de la programación.

Controlar la programación debe incluir la supervisión del estado de las actividades relacionadas

Este documento es una traducción propia y de uso exclusivo de SGS Academy Colombia con fines académicos
No pretende superar al estándar original.
AC-GA-I-F-01-01
V2 – Septiembre 2018
47
con el proyecto. El control también debe implicar la gestión de los cambios en la programación, la
supervisión de los hitos y la introducción de otros controles, según se considere apropiado.
7.6.2. Estimación de la duración de las actividades

Las actividades futuras se pueden definir con menos detalle que las actividades inmediatas. A
medida que avanza el proyecto y más información está disponible, las actividades se pueden
definir y detallar. La duración de la actividad puede representar una compensación entre las
restricciones de programación y la disponibilidad de recursos. También podrían ser necesarias
reestimaciones periódicas de los pronósticos, con respecto a la programación de línea base.

Las estimaciones de duración de la actividad deberían reconsiderarse a lo largo de la vida del


proyecto. Una vez programadas las actividades, se podrían realizar solicitudes de cambio (véase
7.10). Al mismo tiempo, deberían identificarse nuevos riesgos y otros eventos que afecten al
proyecto.

7.6.3. Desarrollo del cronograma

Las actividades deben programarse de acuerdo con el enfoque de entrega utilizado. El nivel de
actividad debe proporcionar entendimiento suficiente para emprender los trabajos, asignar
recursos, finalizar el presupuesto y gestionar los controles. Además, se pueden adoptar otros
formatos de programación como un diagrama de red de actividades.

El cronograma debe desarrollarse para determinar:

a) si los objetivos del proyecto se pueden alcanzar a tiempo

b) la ruta crítica y sus riesgos conexos, y

c) el progreso real logrado en el cronograma con respecto a la programación de línea base


predefinida.

El desarrollo del cronograma y su verificación deben ser continuas a lo largo del proyecto. A
medida que avanza el trabajo, los planes de proyecto cambian, los eventos de riesgo anticipados
ocurren o desaparecen, y se identifican nuevos riesgos. Si es necesario, la duración y las
estimaciones de recursos deben ajustarse y revisarse para desarrollar una programación de
proyecto aprobada que puede servir como línea base revisada, con la que se pueda realizar un
seguimiento del progreso.

7.6.4. Control del cronograma

Una vez aprobado el cronograma del proyecto y la línea base, se debería controlar el trabajo,
identificar desviaciones, y tomar medidas preventivas y correctivas adecuadas, si fuera necesario.

El director del proyecto debe ser consciente de las implicaciones de los retrasos en las primeras
fases del proyecto y su impacto en los objetivos del proyecto. Las compensaciones entre las
diferentes restricciones del proyecto, como el riesgo y el costo, deberían tenerse en cuenta al
decidir sobre una respuesta a cualquier retraso en el cronograma. El control del cronograma

Este documento es una traducción propia y de uso exclusivo de SGS Academy Colombia con fines académicos
No pretende superar al estándar original.
AC-GA-I-F-01-01
V2 – Septiembre 2018
48
debería realinear el objetivo de programación a la línea base original o producir una nueva línea
de base con el menor impacto posible, teniendo en cuenta varias restricciones de proyecto.
Al controlar la programación, el enfoque debería centrarse en:

a) determinar el progreso realizado hasta la fecha

b) comparar el progreso con la línea base de programación para determinar cualquier desviación

c) pronosticar fechas de finalización, e

d) implementar medidas preventivas o correctivas adecuadas para evitar retrasos adversos en el


cronograma.

Los pronósticos de finalización del cronograma deberían desarrollarse y actualizarse


rutinariamente en función de las tendencias pasadas y el conocimiento actual. Las aceleraciones
de cronograma también pueden ser posibles, utilizando reservas de contingencia o de gestión y
otras estrategias de gestión de proyectos.

En la gestión del cronograma, el progreso general se puede revisar utilizando datos históricos y
de productividad, datos de progreso, planes de proyecto, requisitos de recursos y riesgos
identificados y registrados.

7.7. Gestión de los Costos

7.7.1. Visión general

El propósito de la gestión de costos es establecer los controles financieros que se utilizarán a lo


largo del ciclo de vida del proyecto, para facilitar la ejecución del proyecto dentro del presupuesto
aprobado. El presupuesto debería ser una parte integrada del plan del proyecto (véase 7.2).

Las actividades de gestión de costos deben identificar y utilizar técnicas de estimación de costos
que se utilizarán para desarrollar un presupuesto de proyecto. Las actividades de control deben
definirse y llevarse a cabo con el fin de controlar desviaciones al presupuesto definido. La gestión
de costos debe implicar la estimación de los costos de cada elemento de trabajo, desarrollando un
presupuesto y controlando los costos del proyecto.

7.7.2. Estimación del costo

Estimar los costos debería implicar el desarrollo de una aproximación de los costos necesarios
para completar cada actividad del proyecto. Las estimaciones de costos deben establecerse al
menos para la primera fase, así como para todo el proyecto. Las estimaciones de costos pueden
expresarse en unidades de medida, como las horas de trabajo, el número de horas de equipos o
valoraciones monetarias.

Cuando los proyectos se costean en más de una moneda, los tipos de cambio utilizados deberían
documentarse. Las reservas o los fondos de contingencia pueden utilizarse para hacer frente a las
incertidumbres y, si se utilizan, deben estar identificadas claramente en el cálculo del costo.

Este documento es una traducción propia y de uso exclusivo de SGS Academy Colombia con fines académicos
No pretende superar al estándar original.
AC-GA-I-F-01-01
V2 – Septiembre 2018
49
7.7.3. Desarrollo del presupuesto

La asignación de presupuesto a los elementos de trabajo programados debe proporcionar un


presupuesto basado en el cronograma con el cual el desempeño real se pueda comparar.

El costo total del proyecto debe estimarse y crearse un presupuesto que identifique cuándo se
espera que se incurra. Debería definirse y establecerse un método para gestionar y medir el
desempeño de los costos. Se deben establecer medidas objetivas del desempeño de costos al
presupuestar. Establecer medidas objetivas antes de las evaluaciones de desempeño de costos
mejoran la rendición de cuentas y evitan los sesgos.

Las reservas o elementos de contingencia no asignados a actividades u otros componentes del


alcance del trabajo, se pueden crear y utilizar para fines de control de gestión, o para cubrir los
costos imprevistos. Dichos elementos y cómo deben gastarse, junto con los riesgos asociados,
deberían estar claramente identificados. La asignación de los fondos presupuestados a las
actividades de trabajo establece una línea de base para la supervisión y permite volver a elaborar
la base del presupuesto cuando se aprueban solicitudes de cambio.

7.7.4. Control de costos

El control de costos debería centrarse en determinar el estado actual del costo, comparándolo con
la línea de base para determinar cualquier desviación, pronosticando los costos proyectados al
finalizar e implementando acciones preventivas o correctivas.

Una vez iniciado el trabajo, se deben acumular datos de desempeño, incluidos los costos
presupuestados, los costos reales y el costo estimado al finalizar. Para evaluar el desempeño del
proyecto, es necesario combinar los costos con los datos de programación acumulados, como el
progreso de las actividades programadas y los pronósticos de finalización de las actividades en
curso y futuras.

En el control de los costos, se pueden revisar varios recursos, incluidos el presupuesto, los costos
reales y las estimaciones de costos, costos previstos, datos de progreso, listas de actividad,
solicitudes de cambio y cambios aprobados, acciones correctivas, y planes de proyecto.

El seguimiento de los costos reales y los costos futuros previstos, así como las desviaciones de
costos relacionadas, deberían permitir al equipo del proyecto tomar las medidas apropiadas para
mantener el proyecto dentro de los objetivos o solicitar financiación adicional.

7.8. Gestión de los riesgos

7.8.1. Visión general

El objetivo de la gestión de riesgos es aumentar la probabilidad de que se alcancen los objetivos


del proyecto. El riesgo debe ser una parte integrada del plan del proyecto (véase 7.2).

Este documento es una traducción propia y de uso exclusivo de SGS Academy Colombia con fines académicos
No pretende superar al estándar original.
AC-GA-I-F-01-01
V2 – Septiembre 2018
50
La identificación de riesgos es responsabilidad de todos los miembros del equipo del proyecto y
debe implicar la determinación de posibles fuentes de riesgo y sus características que, si se
producen, podrían tener impacto positivo o negativo en el proyecto. La gestión de riesgos debe
implicar la identificación, evaluación, tratamiento y control de los riesgos y las respuestas de riesgo
a lo largo del ciclo de vida del proyecto.

7.8.2. Identificación de riesgos

Los riesgos se pueden identificar a lo largo del ciclo de vida y los riesgos previamente identificados
pueden cambiar o volver a ocurrir. Los riesgos deberían registrarse cuando se identifiquen. Los
riesgos del proyecto pueden originarse a partir de diversas fuentes, ya sea internas o externas al
proyecto. Cada riesgo debe tener un propietario asignado.

NOTA: El registro de riesgos puede denominarse expediente de riesgos, historial de riesgos o


cualquier otro término utilizado en la organización.

7.8.3. Evaluación de riesgos

Cada riesgo debe evaluarse según la probabilidad y las consecuencias, y priorizarse para futuras
medidas. Deberían evaluarse las interrelaciones y las dependencias entre los riesgos individuales.

NOTA 1: Consecuencia también se puede conocer como impacto.

NOTA 2: Probabilidad también se puede conocer como posibilidad.

7.8.4. Tratamiento de riesgos

El tratamiento de riesgos debería implicar el desarrollo de opciones y acciones para mejorar las
oportunidades y reducir las amenazas del proyecto. Las medidas de tratamiento de riesgos pueden
incluir, (pero no se limitan a):

a) aceptar

b) evitar

c) mitigar

d) transferir

e) contingencia

f) explotar, y

g) mejorar.

Las medidas adoptadas para tratar un riesgo determinado deben ser apropiadas para la amenaza
u oportunidad, rentables, oportunas, realistas dentro del contexto del proyecto, entendidas por las
partes involucradas y asignadas a un propietario apropiado.

Este documento es una traducción propia y de uso exclusivo de SGS Academy Colombia con fines académicos
No pretende superar al estándar original.
AC-GA-I-F-01-01
V2 – Septiembre 2018
51
Los riesgos residuales pueden ser el resultado de las medidas adoptadas para tratar cada riesgo.
Al tratar riesgos, una modificación al plan o un cambio en la línea base, podrían ser necesarios
(véase 7.10).

7.8.5. Control de riesgos

Controlar los riesgos debería disminuir la disrupción del proyecto, determinando si las respuestas
al riesgo se llevan a cabo y si tienen el efecto deseado. En el control del riesgo, varios recursos
pueden ser considerados para incluir riesgos priorizados, datos de progreso, planes de proyecto,
solicitudes de cambio y acciones correctivas. El seguimiento al desarrollo del riesgo, así como el
seguimiento de la eficacia del tratamiento del riesgo, debería ser parte del control de riesgos.

7.9. Gestión de los incidentes

7.9.1. Visión general

El propósito de la gestión de incidentes es resolver los incidentes del proyecto, de tal manera que
no tengan consecuencias sobre los objetivos del proyecto. Los incidentes deberían ser
identificados por los involucrados y resolverse a lo largo del proyecto. Un mecanismo para escalar
los incidentes debería establecerse a fin de determinar el nivel de gestión adecuado, para hacer
frente a los incidentes que el equipo no pueda resolver.

7.9.2. Identificación de incidentes

Los incidentes deben identificarse a medida que se producen. La mayoría de los incidentes deben
abordarse para minimizar su impacto o explotar su impacto positivo en el proyecto. Al definir cada
incidente, el equipo del proyecto debe considerar los factores pertinentes que rodean la situación.
Debería establecerse un método seguro y fiable para que las partes interesadas del proyecto
planteen incidentes.

La identificación de los incidentes que afectan al proyecto debe llevarse a cabo en todos los niveles
y gestionados por el equipo del proyecto. Los incidentes deben definirse y entenderse claramente
por las partes interesadas involucradas. Los incidentes deben registrarse tan pronto como se
identifiquen, analicen y prioricen, de modo que las cuestiones que tengan el mayor impacto en los
objetivos del proyecto se puedan tratar primero. La responsabilidad y rendición de cuentas debe
estar asignada para gestionar cada incidente hasta su resolución.

El registro de incidentes ayuda a capturar los detalles de cada situación, de modo que el equipo
del proyecto puede ver el estado del incidente y quién es responsable de resolverlo. Los detalles
de cada incidente podrían incluir un título o nombre, el tipo de incidente, la fecha en que se
identificó un incidente, la descripción del incidente, prioridad, resumen de impacto, pasos de acción
y estado actual.

Los incidentes resueltos o cerrados deben mantenerse como un registro histórico y para facilitar
las lecciones aprendidas.
7.9.3. Resolución de incidentes

Este documento es una traducción propia y de uso exclusivo de SGS Academy Colombia con fines académicos
No pretende superar al estándar original.
AC-GA-I-F-01-01
V2 – Septiembre 2018
52
La resolución de incidentes implica registrar y gestionar un evento o incidente que ha ocurrido y
amenaza el éxito del proyecto o representa una oportunidad para ser explotado. Un mecanismo
para escalar los incidentes debería establecerse a fin de determinar el nivel de gestión adecuado
para la toma de decisiones al abordar los incidentes, con base en las recomendaciones del equipo
y otras partes interesadas apropiadas.

La planificación de la gestión de los incidentes y el enfoque para resolver los incidentes debe
incorporarse en el plan general del proyecto esbozando el método utilizado para evaluar y abordar
los incidentes que se producen.

La decisión y la justificación de la resolución de un incidente debe comunicarse a los miembros


del equipo del proyecto apropiados, originadores y partes interesadas. La resolución de incidentes
debe incorporar un mecanismo de escalación que se pueda utilizar para elevar al nivel de
responsabilidad o prioridad correspondiente cuando la resolución no es cercana o la resolución
ofrecida no se considera práctica o satisfactoria para los participantes.

La resolución de incidentes incluye evaluar el impacto de los incidentes y las acciones que tengan
lugar para resolverlos. La resolución de los incidentes debería registrarse para futuras referencias
y aprendizajes. Cuando se resuelven incidentes, podría ser necesaria una modificación al plan o
un cambio en la línea base (véase 7.10).

7.10. Control de Cambios

7.10.1. Visión general

El propósito del control de cambios debería ser controlar los cambios en el proyecto y formalizar
la aceptación o rechazo de estos cambios. Los cambios pueden provenir del desempeño del
proyecto o de cualquier parte interesada, incluidos los responsables políticos, usuarios finales,
proveedores o miembros del equipo. Como alternativa, un cambio puede ser el resultado de una
respuesta a un riesgo o incidente. Por otra parte, el control de cambios debe incluir el
establecimiento de un marco para el proyecto que incluya actividades de identificación, evaluación,
implementación y cierre de solicitudes de cambio.

NOTA: La evaluación incluye determinar el impacto de los cambios en el tiempo y el costo del
proyecto.

7.10.2. Establecimiento de un marco de control de cambios

Un marco de control de cambios debería definir el proceso de control de cambios y las


herramientas que se utilizarán. Los cambios en los entregables deben controlarse mediante un
conjunto establecido de procedimientos integrados, tales como la gestión de la configuración.

7.10.3. Identificación y evaluación de solicitudes de cambio

A lo largo del proyecto es necesario registrar las solicitudes de cambio en un registro de cambios,

Este documento es una traducción propia y de uso exclusivo de SGS Academy Colombia con fines académicos
No pretende superar al estándar original.
AC-GA-I-F-01-01
V2 – Septiembre 2018
53
evaluarlas en cuanto a sus objetivos, beneficios, expectativas de las partes interesadas, alcance,
recursos, cronograma, costo, calidad y riesgo, y evaluar el impacto para obtener la aprobación
antes de la implementación. Sólo deben implementarse las solicitudes de cambio aprobadas.

7.10.4. Planificación de solicitudes de cambio

El director del proyecto debe determinar cómo se podría implementar un cambio, si se aprueba.
El enfoque de planificación enfoque esbozado en 7.2 debe seguirse tan rigurosamente para un
cambio a un plan existente como para un nuevo plan.

Cuando proceda, el director del proyecto debería verificar los requisitos contractuales actuales
como resultado del cambio o, si es necesario, incluir modificaciones a un contrato o plan acordado
(véase 7.17).

7.10.5. Implementación y cierre de solicitudes de cambio

Una solicitud de cambio debe ser aprobada, modificada, rechazada o aplazada como resultado de
la evaluación de impacto. Una vez aprobado un cambio, la decisión debe comunicarse a las partes
interesadas pertinentes. Debe actualizarse la documentación del proyecto, según corresponda, e
implementar el cambio. El estado de la solicitud de cambio debería ser registrada y rastreada,
hasta que se haya implementado y cerrado.

7.11. Gestión de calidad

7.11.1. Visión general

El propósito de la gestión de la calidad es aumentar la probabilidad de que los productos sean


adecuados para su propósito o uso. La calidad debe ser una parte integrada del plan del proyecto
(véase 7.2). La gestión de la calidad incluye la identificación de los requisitos de calidad con
criterios de aceptación y medios de verificación y validación, de las normas que se utilizarán y los
resultados del proyecto, incluidos los entregables tangibles e intangibles.

Deben documentarse los requisitos y estándares de calidad y demostrar cómo el proyecto


cumpliría con los requisitos y estándares de calidad. Debido a la naturaleza temporal de los
proyectos y sus restricciones, tales como cronograma, costo, calidad, recursos, riesgos y otros
parámetros, la mayoría de los proyectos no pueden desarrollar fácilmente nuevos estándares de
calidad para el proyecto.

El desarrollo y la aceptación organizativa de los estándares de calidad y los parámetros de calidad


del producto se pueden originar más allá del límite del proyecto. Esta aceptación es normalmente
responsabilidad del cliente o de la organización ejecutante, según lo que prevalezca
contractualmente. Además, proyectos innovadores y sin precedentes pueden requerir el
establecimiento de nuevas normas, que también pueden imponer nuevos requisitos, riesgos,
compartir responsabilidades entre el proyecto y la organización, e involucrar a otros participantes.

La gestión de la calidad del proyecto debe incluir el desarrollo de un plan de gestión de calidad y
procesos de aseguramiento y control de la calidad.

Este documento es una traducción propia y de uso exclusivo de SGS Academy Colombia con fines académicos
No pretende superar al estándar original.
AC-GA-I-F-01-01
V2 – Septiembre 2018
54
Las partes interesadas del proyecto deben comunicarse con respecto a la probabilidad de que los
objetivos del proyecto y los resultados puedan cumplir con los requisitos y estándares de calidad,
y permitan la realización de los beneficios esperados para la organización.

Deberían definirse habilitadores para la calidad, los enfoques, procesos y métodos utilizados, para
determinar los requisitos, para diseñar las salidas de la solución, para crear e integrar los
elementos de la solución, y para verificar y validar estos elementos. Es contra estos enfoques,
procesos y métodos identificados que debería llevarse a cabo el aseguramiento y el control de la
calidad.

7.11.2. Planificación de la calidad

La planificación de la calidad debería determinar los requisitos de calidad, métricas y estándares


aplicables al proyecto y sus productos, y cómo se deben cumplir esos requisitos en función de los
objetivos y restricciones del proyecto.

Los requisitos de calidad, las métricas y los criterios de aceptación son identificados por las partes
interesadas; las normas y políticas de calidad organizacional se aplican a los resultados de los
proyectos, internos, externos, interinos, finales, y a los entregables tangibles e intangibles.

La planificación de la calidad debería incluir:

a) determinar y acordar con el patrocinador del proyecto y otras partes interesadas, los objetivos
y normas de calidad pertinentes que deben alcanzarse

b) documentar métricas de calidad y criterios de aceptación para los entregables del proyecto

c) establecer los instrumentos, procedimientos, técnicas y recursos necesarios para alcanzar las
normas acordadas

d) determinar métodos, técnicas y recursos para implementar la planificación sistemática de las


actividades de calidad

e) desarrollar el enfoque definido para la gestión de la calidad, incluido el tipo de inspecciones,


los participantes y programación de acuerdo con el plan del proyecto, y

f) consolidar la información de calidad en el plan de gestión de calidad.

7.11.3. Aseguramiento de la calidad

El aseguramiento de la calidad debería facilitar y permitir la conformidad con los requisitos de


desempeño aplicables, procesos y estándares de calidad, e incluye:

a) comunicar los objetivos y las normas pertinentes que deben utilizarse y comprobar que se
utilizan

Este documento es una traducción propia y de uso exclusivo de SGS Academy Colombia con fines académicos
No pretende superar al estándar original.
AC-GA-I-F-01-01
V2 – Septiembre 2018
55
b) verificar la conformidad con el enfoque de gestión definido para la calidad

c) verificar que se están utilizando las herramientas, procedimientos, técnicas y recursos


establecidos

d) cumplir con el enfoque planificado para verificar los productos contra los requisitos y
especificaciones validados, cuando sea pertinente, y

e) auditorías que deberían ser realizadas fuera de los límites del proyecto, por otras áreas de
gestión del desempeño organizacional, o por los clientes.

Las solicitudes de cambio pueden ser el resultado de actividades de aseguramiento de la calidad.

7.11.4. Control de la calidad

El control de calidad debería utilizarse para:

a) determinar si los objetivos, los requisitos de calidad y las métricas y estándares de calidad del
proyecto se están cumpliendo, e

b) identificar las causas y formas de eliminar el desempeño insatisfactorio.

El control de calidad debería considerar los datos de progreso, los resultados y el enfoque de
gestión definido para la calidad, así como los resultados de las mediciones de control de calidad,
entregables verificadas e informes de inspección.

Los resultados deberían ayudar a identificar las causas de un desempeño deficiente o una calidad
inadecuada del producto, y pueden orientar las acciones preventivas y correctivas, y solicitudes.

El control de calidad debería aplicarse a los productos y entregables del proyecto, e incluye:

− verificar que los productos y entregables cumplan los requisitos de calidad mediante la
detección de defectos, herramientas, procedimientos y técnicas establecidos;

− analizar las posibles causas de los defectos;

− determinar las acciones preventivas y las solicitudes de cambio, y

− comunicar las acciones correctivas y las solicitudes de cambio.

El control de calidad se puede realizar fuera de los límites del proyecto por otras partes de la
organización o por los clientes.
7.12. Involucramiento de las partes interesadas

7.12.1. Visión general

El propósito del involucramiento de las partes interesadas es permitir que las necesidades,

Este documento es una traducción propia y de uso exclusivo de SGS Academy Colombia con fines académicos
No pretende superar al estándar original.
AC-GA-I-F-01-01
V2 – Septiembre 2018
56
intereses y expectativas de las partes interesadas sean atendidas suficientemente para permitir
que se cumplan los objetivos.

Las partes interesadas del proyecto deben ser identificadas, analizadas, documentadas y
comprometidas a lo largo del proyecto. El involucramiento de las partes interesadas debería incluir
las actividades de identificación y caracterización de los interesados. Deberían llevarse a cabo
actividades de involucramiento planificadas para abordar las preocupaciones de las partes
interesadas y aplicar el apoyo y la comunicación con las partes interesadas.

7.12.2. Identificación de las partes interesadas

Las partes interesadas deben identificarse junto con la información pertinente sobre sus intereses
e involucramiento. Esta información puede incluir niveles de interés, influencia, expectativas y
necesidades. Las partes interesadas deberían participar activamente en el proyecto y pueden ser
internas o externas al proyecto, en diferentes niveles de autoridad.

Las partes interesadas del proyecto pueden incluir, (pero no se limitan a):

a) la organización patrocinadora y el equipo del proyecto (véase 4.5)

b) clientes o representantes de clientes

c) socios y proveedores

d) grupos especiales de interés o de tensión

e) organismos reguladores

f) proveedores financieros

g) accionistas, y

h) terceros externos relevantes.

7.12.3. Involucramiento de las partes interesadas


El plan de involucramiento de las partes interesadas debería tener en cuenta las partes interesadas
identificadas, el plan de proyecto y otra documentación del proyecto. La participación puede incluir
actividades como identificar a las partes interesadas, la resolución de incidentes y actividades
específicas destinadas a obtener un nivel adecuado de involucramiento de las partes interesadas
clave en la toma de decisiones del proyecto, y otras actividades críticas para el éxito del proyecto.

Los incidentes relacionados con las partes interesadas deben resolverse utilizando la diplomacia,
la negociación y, si es necesario, el escalamiento a niveles de mayor autoridad, de conformidad
con los procedimientos definidos. Alternativamente, los incidentes con las partes interesadas
pueden ser resueltos solicitando ayuda a personas externas a la organización del proyecto.

Este documento es una traducción propia y de uso exclusivo de SGS Academy Colombia con fines académicos
No pretende superar al estándar original.
AC-GA-I-F-01-01
V2 – Septiembre 2018
57
La resolución de incidentes con las partes interesadas puede dar lugar a solicitudes de cambio
(véase 7.10).

7.13. Gestión de las comunicaciones

7.13.1. Visión general

El propósito de la gestión de las comunicaciones es permitir que las interacciones de las partes
interesadas sean eficaces y contribuir a la entrega exitosa de los resultados del proyecto y a la
realización exitosa de beneficios.

Los enfoques y métodos de comunicación elegidos deberían planificarse y documentarse. El éxito


o fracaso de un proyecto puede depender de la eficacia de las comunicaciones y el grado en que
las comunicaciones involucran a las partes interesadas.

Deberían llevarse a cabo actividades de comunicación planificadas para comprender las


necesidades de información de las partes interesadas, incluido el nivel de información y la
frecuencia de comunicación. Las actividades de comunicación planificada deberían ser
monitoreadas en busca de mayor eficacia.

7.13.2. Planificación de las comunicaciones

Las comunicaciones deberían planificarse para satisfacer las necesidades y expectativas de las
partes interesadas e incluir mecanismos de retroalimentación y mediciones de eficacia. Cuando
sea necesario, las comunicaciones podrían comprender una serie de campañas o eventos de
comunicación específicos dirigidos a un público determinado, con un propósito y mensaje,
utilizando medios apropiados.

Las comunicaciones deberían centrarse en apoyar los objetivos del proyecto:

a) aumentar el entendimiento y la cooperación entre las distintas partes interesadas

b) proporcionar información oportuna, precisa e imparcial

c) diseñar la comunicación para minimizar el riesgo.

Factores como la dispersión geográfica de las partes interesadas, múltiples idiomas y culturas, y
afiliación organizacional, deberían considerarse junto con los medios adecuados a utilizar. Tales
factores pueden afectar significativamente la forma en que se debe entregar la comunicación.

7.13.3. Distribución de la información

Las comunicaciones, en respuesta a las necesidades y expectativas de las partes interesadas


deben distribuirse a través de medios de comunicación, mensajes y frecuencias acordadas. La
distribución de la información debe prever niveles adecuados de confidencialidad, seguridad y
exactitud de la información, cuando proceda, y debe estar de acuerdo con el plan de
comunicaciones.

Este documento es una traducción propia y de uso exclusivo de SGS Academy Colombia con fines académicos
No pretende superar al estándar original.
AC-GA-I-F-01-01
V2 – Septiembre 2018
58
7.13.4. Monitoreo del impacto de las comunicaciones

El impacto de las comunicaciones debería ser monitoreado y evaluado y, en su caso, gestionado.


El plan de comunicaciones debería ajustarse, si es necesario, para lograr un resultado exitoso
para el proyecto.

La supervisión debe centrarse en el impacto de las comunicaciones en:

a) aumentar el entendimiento y la cooperación entre las distintas partes interesadas

b) proporcionar información oportuna, precisa e imparcial, y

c) resolver incidentes de comunicación para minimizar el riesgo.

7.14. Gestión del cambio organizacional

7.14.1. Visión general

El propósito de gestionar el cambio organizacional es permitir la entrega de los resultados


deseados. Si el alcance de un proyecto incluye la entrega de resultados, se necesita gestionar el
cambio organizacional para preparar, equipar y apoyar a organizaciones e individuos, para
cambiar la forma en que realizan actividades particulares y, cuando sea apropiado, sus
comportamientos.

El cambio puede estar en un contexto empresarial o para la sociedad en general o en un contexto


más específico, como en proyectos patrocinados por el gobierno. Los cambios pueden ser
menores, que impliquen poca intervención, o pueden ser significativos como cuando una
organización adopta un modelo operativo completamente nuevo o cuando se introduce una nueva
política social.

La gestión del cambio aborda el requisito de que el director del proyecto trabaje con el patrocinador
del proyecto y partes interesadas afectadas por el proyecto. La gestión del cambio organizacional
debería incluir la identificación de la necesidad de cambios, la identificación de los cambios
específicos necesarios, y la aplicación de las actividades necesarias para los cambios.

7.14.2. Identificación de la necesidad del cambio organizacional

Algunos proyectos pueden requerir cambios organizacionales para ofrecer los resultados
deseados. Dentro de estos proyectos, el director del proyecto debería trabajar con el patrocinador
del proyecto y las operaciones afectadas para desarrollar un plan para implementar el cambio
necesario cuando dicho cambio es fundamental para las razones que dieron inicio al proyecto.

El objetivo del plan de cambio es apoyar a organizaciones e individuos, como usuarios o


ciudadanos, para cambiar su enfoque y, si es procedente, los comportamientos, en relación con
los resultados deseados del proyecto.

Este documento es una traducción propia y de uso exclusivo de SGS Academy Colombia con fines académicos
No pretende superar al estándar original.
AC-GA-I-F-01-01
V2 – Septiembre 2018
59
El plan de cambio organizacional debería incluir una visión o un bosquejo del estado futuro
deseado. El desarrollo de este plan debería incluir la evaluación del estado actual de las partes
interesadas afectadas, identificar los cambios necesarios y aplicar las técnicas adecuadas para la
implementación de esos cambios. El plan también debe incluir un cronograma de alto nivel que
muestre cuándo es necesario lograr los resultados.

Las técnicas de cambio pueden incluir proporcionar comunicaciones para capacitación, tutoría o
suministro de equipos u otros recursos a las partes interesadas afectadas, así como el uso de
métodos especializados de gestión del cambio organizacional.

7.14.3. Transferencia a la organización patrocinadora

El director del proyecto debe gestionar la transición de los productos del proyecto a la organización
patrocinadora o cliente, para permitir la entrega de resultados y la realización de los beneficios
esperados, por medio de:

a) verificación de que se han cumplido los objetivos, los requisitos de calidad y los estándares de
calidad del proyecto (véase 7.11)

b) confirmación de que la organización patrocinadora o el cliente está listo para recibir las salidas
del proyecto

c) gestión de la transición de los entregables del equipo del proyecto a la organización


patrocinadora o cliente, y

d) obtención de la confirmación de que la transición se completó.

7.14.4. Implementación del cambio organizacional

Tras la implementación de los cambios, el patrocinador del proyecto, en coordinación con los
gerentes operativos o representantes de las organizaciones y partes interesadas afectadas,
deberían monitorear cómo y si se están logrando los resultados deseados.

7.15. Presentación de informes

7.15.1. Visión general

El propósito de la presentación de informes es proporcionar una vista del estado actual,


pronósticos y análisis del proyecto. La presentación de informes debería estar alineada con la
documentación del proyecto actual, y posiblemente actualizada, y determinada a partir de un
análisis de la información de gestión del proyecto.

El enfoque y los métodos de presentación de informes deben planificarse y documentarse al

Este documento es una traducción propia y de uso exclusivo de SGS Academy Colombia con fines académicos
No pretende superar al estándar original.
AC-GA-I-F-01-01
V2 – Septiembre 2018
60
principio del proyecto. Durante el proyecto, la presentación de informes se realiza y debería ser
monitoreada y ajustada para mantener la alineación con las necesidades y los requisitos de los
receptores de informes.

7.15.2. Planificación de informes

La presentación de informes debería basarse en varios métodos de distribución para satisfacer las
necesidades de información y expectativas de las partes interesadas internas de la organización
del proyecto, definido como una función de la gobernanza.

El plan de presentación de informes debe ser parte del plan de comunicaciones del proyecto,
teniendo en cuenta las necesidades de la organización del proyecto y los roles y responsabilidades
relacionadas.

7.15.3. Desarrollo de informes

Los informes, tal como lo definen los miembros de la organización del proyecto y las necesidades
de las partes interesadas internas, deberían ser oportunos, disponibles y distribuidos. Los informes
deben proporcionar niveles de confidencialidad y seguridad adecuados de información, cuando
proceda, y debe estar de acuerdo con la gestión definida del proyecto (véase 6.5.3).

7.15.4. Presentación de informes

La gestión de los informes debería centrarse en proporcionar:

a) información oportuna y precisa de los equipos del proyecto al director del proyecto, que
contiene reportes del progreso e incidentes de equipo

b) equipos del proyecto con información oportuna y precisa relacionada con el plan del proyecto

c) patrocinador del proyecto y comité directivo con información oportuna y precisa de la gestión
del proyecto, reflejando el estado del proyecto, incidentes del proyecto, amenazas y
oportunidades, y

d) gerente de proyecto con decisiones oportunas del patrocinador del proyecto.

7.16. Gestión de la información y documentación

7.16.1. Visión general

El objetivo de la gestión de la información y la documentación es permitir información (física y


digital) a disposición de quienes realicen trabajos y tomen decisiones. La gestión de la información
y la documentación comprende la recopilación, almacenamiento, análisis, distribución y
mantenimiento de información precisa necesaria, para actividades como la planificación, ejecución
y auditoría del trabajo, y el apoyo a las lecciones aprendidas y a la gestión del conocimiento.

Este documento es una traducción propia y de uso exclusivo de SGS Academy Colombia con fines académicos
No pretende superar al estándar original.
AC-GA-I-F-01-01
V2 – Septiembre 2018
61
La información y la documentación deberían estar disponibles y accesibles para la referencia
histórica. Las actividades deberían incluir el establecimiento de un sistema de recepción,
almacenamiento e identificación de información y documentación, que debería ser gestionada y
estar accesible.

La información relacionada con el proyecto y la gestión de documentos podría tener que llevarse
a cabo, de acuerdo con las directivas de administración y retención de información de la
organización.

7.16.2. Identificación de la información que debe gestionarse

La información y la documentación, que deben gestionarse, deberían identificarse y gestionarse


de acuerdo con los requisitos de confidencialidad, seguridad y precisión de los datos.

La información y documentación relacionada con el proyecto puede incluir planes, evaluaciones


de progreso, revisiones, auditorías, revisiones, contratos, informes, comunicaciones e información
especializada relacionada con los resultados, diseños, especificaciones y estándares.

7.16.3. Almacenamiento y recuperación de información y documentación

Debería definirse y establecerse un sistema para recibir, identificar, almacenar y mantener


información y documentación, de modo que la información y la documentación se puedan distribuir
y recuperar sólo por aquellas personas que están autorizadas a acceder a ella.

El sistema debería incluir medidas de continuidad en caso de un incidente perturbador. El sistema


debería incluir los requisitos de disposición y retención para todas las categorías de información
del proyecto. Debería establecerse un sistema para garantizar la integridad de los grupos de
información relacionada, como los sistemas utilizados para la gestión de la configuración.

7.17. Adquisiciones

7.17.1. Visión general

El propósito de la adquisición es obtener productos y servicios comprados como parte del


abastecimiento de recursos con la calidad adecuada, representando una buena relación calidad-
precio y que se pueden entregar cuando sea necesario dentro de un nivel de riesgo aceptable.

La adquisición debería considerar la calidad adecuada, la relación calidad-precio y la entrega


dentro de un nivel de riesgo. Debería planificarse la adquisición para aplicar los procesos de
contratación organizacional, si los hubiere, en consonancia con la estrategia de contratación del
proyecto. La gestión de adquisiciones debe integrarse con planificación (véase 7.2).

NOTA: La adquisición requiere conocimiento de las leyes y prácticas pertinentes y a menudo es

Este documento es una traducción propia y de uso exclusivo de SGS Academy Colombia con fines académicos
No pretende superar al estándar original.
AC-GA-I-F-01-01
V2 – Septiembre 2018
62
llevada a cabo por especialistas.

7.17.2. Planificación de la adquisición

Debería definirse una estrategia de adquisiciones, teniendo en cuenta las decisiones de prácticas
de ejecución de proyectos, el tipo de contratos jurídicamente vinculantes y el proceso de
contratación que se utilizarán.

Los miembros del equipo que compran bienes y servicios deberían identificar los criterios de
contratación y los procesos para facilitar la adquisición de los productos y servicios requeridos, de
fuentes externas.

Los requisitos de contratación deberían validarse con el director del proyecto o designar por cual
información sobre adquisiciones y especificaciones del contrato, deben desarrollarse y definirse.

7.17.3. Evaluación y selección de proveedores

Los proveedores deberían seleccionarse en función de la información obtenida durante la


identificación del proveedor, y por actividades de selección y verificación. Debería realizarse una
evaluación de la propuesta de cada proveedor, de conformidad con los criterios de evaluación. El
desempeño del proveedor debería ser reevaluado a lo largo del proyecto, según los requisitos del
contrato.

7.17.4. Administración de contratos

La administración de contratos debería:

a) contemplar la gestión de las relaciones contractuales, el seguimiento del desempeño de los


contratos, la gestión de cambios y correcciones del contrato, tratamiento de las reclamaciones
y la finalización de los contratos

b) permitir que el desempeño de las partes contratadas cumpla con los requisitos del proyecto,
según los términos del acuerdo legal

c) incluir la recopilación de datos de desempeño de los proveedores y el mantenimiento de


registros detallados (véase 7.15), y

d) realizarse a lo largo del proyecto, según sea necesario.

Las comunicaciones con el proveedor, en relación con las controversias o reclamaciones, deberían
llevarse a cabo o dar seguimiento por escrito para proporcionar pruebas de las medidas adoptadas
por las partes contratadas. Podría buscarse asesoramiento contractual y jurídico.

7.17.5. Cierre de contratos

Los contratos pueden cerrarse en dos circunstancias cuando:

Este documento es una traducción propia y de uso exclusivo de SGS Academy Colombia con fines académicos
No pretende superar al estándar original.
AC-GA-I-F-01-01
V2 – Septiembre 2018
63
a) se han cumplido las obligaciones contractuales de las partes, o

b) el contrato se cierra anticipadamente, de acuerdo con las cláusulas de rescisión del contrato.

Cuando se promulgan disposiciones de terminación, deberían considerarse medidas para


minimizar el costo y el impacto de la terminación. Al cierre del contrato, la documentación del
contrato asociado debe archivarse de acuerdo con la directiva de resguardo de información de la
organización.

7.18. Lecciones aprendidas

7.18.1. Visión general

El propósito de las lecciones aprendidas es beneficiarse de la experiencia, evitar repetir errores y


difundir mejores prácticas para beneficiar a los equipos de proyectos actuales y futuros.

Las lecciones pueden resultar de incidentes ocurridos durante el proyecto, la forma en que se
resolvió cada incidente, así como la forma en que se gestionó cada riesgo. Las lecciones también
pueden resultar de revisiones y auditorías de calidad. Las actividades deberían incluir la
identificación, documentación y difusión de lecciones a lo largo de la duración del proyecto.

7.18.2. Identificación de lecciones aprendidas

A lo largo del proyecto, el equipo y las partes interesadas clave deberían identificar aspectos
técnicos y gerenciales del proyecto. Las lecciones deberían ser capturadas, compiladas,
formalizadas y almacenadas.

7.18.3. Difusión de lecciones aprendidas

Las lecciones deberían difundirse y utilizarse a lo largo del proyecto y, cuando proceda, incluidas
en la base de conocimientos de la organización, para ser compartida y utilizada y promover la
mejora del desempeño de proyectos, en curso y futuros.

Si una organización utiliza un proceso o método definido de gestión de proyectos, las lecciones
del proyecto individual deberían ser comunicadas a los propietarios del proceso o método, por lo
que el proceso puede ser mejorado para beneficiar a otros usuarios.

NOTA: Una oficina de proyectos suele ser la propietaria de los procesos y métodos de gestión de
proyectos (véase 4.5.7).

Este documento es una traducción propia y de uso exclusivo de SGS Academy Colombia con fines académicos
No pretende superar al estándar original.
AC-GA-I-F-01-01
V2 – Septiembre 2018
64
BIBLIOGRAFÍA

[1] ISO 9000:2015, Sistemas de gestión de calidad - Fundamentos y vocabulario


[2] ISO 21500:2012, Orientación sobre gestión de proyectos
[3] ISO 21503, Orientación sobre la gestión de programas
[4] ISO 21504, Orientación sobre gestión de portafolios
[5] ISO 21505, Orientación sobre gobernanza
[6] ISO/TR 21506:2018, Vocabulario
[7] ISO 21511:2018, Estructuras de desglose del trabajo para la gestión de proyectos y programas

Este documento es una traducción propia y de uso exclusivo de SGS Academy Colombia con fines académicos
No pretende superar al estándar original.
AC-GA-I-F-01-01
V2 – Septiembre 2018
65

También podría gustarte