Documentos de Académico
Documentos de Profesional
Documentos de Cultura
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
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.
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
Además, este documento también puede ser útil para las personas involucradas en funciones de
apoyo:
— 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
3. TÉRMINOS Y DEFINICIONES
ISO e IEC mantienen bases de datos terminológicas para su uso en estandarización en las
siguientes direcciones:
3.2 Beneficio
Beneficio creado, valor u otro efecto positivo.
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.
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.12 Portafolio
Grupo de componentes de portafolio (0) agrupados para facilitar su gestión y alcanzar objetivos
estratégicos.
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]
Nota 1 a la entrada:
Se toman acciones preventivas para prevenir la ocurrencia, mientras se toman acciones
correctivas para evitar la recurrencia.
3.15 Programa
Grupo de componentes del programa (0) gestionados de forma coordinada para obtener
beneficios (0)
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".]
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.
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.
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.
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
— recursos utilizados
— complejidad
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.1 General
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.
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.
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:
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.
— cómo debe funcionar la gobernanza de los proyectos a ambos lados y a través de un límite
contractual
— 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.
Los resultados y resultados del proyecto deberían lograrse dentro de un conjunto identificado de
restricciones, como, (pero no limitado a):
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
f) seguridad
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.
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)
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
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
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.
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:
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.
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).
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.
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.
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.
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.
a) Portafolio: la autoridad de nivel superior podría ser el gerente o director del portafolio, y
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.
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.
− 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.
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.
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
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.
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.
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:
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)
h) gestionar el desempeño de los proveedores tal como se define en los contratos pertinentes, y
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.
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.
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
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
NOTA 2: Para las prácticas integradas de gestión de proyectos asociadas con un líder de paquete
de trabajo, consulte 6.7.
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.
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
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.
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
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.
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) 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
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.
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):
− 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
d) gestión de riesgos
Al alinear las prácticas y sistemas de gestión de proyectos, también debe tenerse en cuenta lo
siguiente:
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
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:
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
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.
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
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.
− identificar al patrocinador del proyecto y al director del proyecto y definir sus responsabilidades
iniciales y autoridades;
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.
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.
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
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".
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).
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:
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.
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.
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.
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).
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).
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.
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:
− gestión del cronograma y de los costos (véanse los puntos 7.6 y 7.7)
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.
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:
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):
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
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
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)
f) mantener informado al director del proyecto del progreso del paquete de trabajo (véase 7.15)
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.
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):
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:
El propósito de las actividades posteriores al proyecto es verificar que los resultados son
sostenibles y los beneficios se están realizando.
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
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.
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
b) alcance: productos y resultados a entregar (véase 7.4), teniendo en cuenta la calidad (véase
7.11)
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.
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.
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).
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).
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
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.
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.
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).
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).
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
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
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.
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).
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.
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.
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.
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 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.
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).
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 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 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.
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:
b) comparar el progreso con la línea base de programación para determinar cualquier desviación
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.
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.
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
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.
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.
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.
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.
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.
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).
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.
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.
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 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).
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.
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.
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).
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.
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.
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.
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
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
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.
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
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;
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
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.
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):
c) socios y proveedores
e) organismos reguladores
f) proveedores financieros
g) accionistas, y
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).
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.
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.
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.
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
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.
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.
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.
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
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.
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.
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.
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).
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
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.17. Adquisiciones
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.
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.
b) permitir que el desempeño de las partes contratadas cumpla con los requisitos del proyecto,
según los términos del acuerdo legal
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.
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.
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.
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.
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
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