Descarga del libro PM, quinta edición en ruso. PMBOK, Quinta Edición, Resumen. Código de Ética y Conducta Profesional
________________________________________________________________________________________________
1. INTRODUCCIÓN
2. INFLUENCIA DE LA ORGANIZACIÓN Y CICLO DE VIDA DEL PROYECTO
3. PROCESOS DE GESTIÓN DE PROYECTOS
4. GESTIÓN DE INTEGRACIÓN DE PROYECTOS
5. GESTIÓN DEL CONTENIDO DEL PROYECTO
6. GESTIÓN DEL TIEMPO DEL PROYECTO
7. GESTIÓN DE COSTOS DEL PROYECTO
8. GESTIÓN DE CALIDAD DEL PROYECTO
9. GESTIÓN DE RECURSOS HUMANOS DEL PROYECTO
10. GESTIÓN DE COMUNICACIÓN DEL PROYECTO
11. GESTIÓN DE RIESGOS DEL PROYECTO
12. GESTIÓN DE ADQUISICIONES DEL PROYECTO
13. GESTIÓN DE LAS PARTES INTERESADAS DEL PROYECTO
1. INTRODUCCIÓN
Proyecto es una empresa temporal destinada a crear un producto, servicio o resultado único.
El proyecto puede crear:
· producto, que es un componente de otro producto, una mejora de un producto o un producto final;
· servicio o la capacidad de proporcionar un servicio (por ejemplo, una función comercial que respalde la fabricación o la distribución);
· mejora una línea existente de productos o servicios (por ejemplo, un proyecto Six Sigma emprendido para reducir defectos);
· resultado, como un resultado final o un documento (por ejemplo, un proyecto de investigación produce nuevos conocimientos que pueden utilizarse para determinar si un nuevo proceso es tendencia o útil para la sociedad).
Gestión de proyectos Es la aplicación de conocimientos, habilidades, herramientas y técnicas al trabajo del proyecto para cumplir con los requisitos del mismo. La gestión de proyectos se logra mediante la aplicación e integración adecuadas de 47 procesos de gestión de proyectos agrupados lógicamente y organizados en 5 grupos de procesos.
Estos 5 grupos de procesos son los siguientes:
· iniciación,
· planificación,
· ejecución,
· monitorear y controlar,
· clausura.
Limitaciones del proyecto:
· calidad,
· cronograma,
· presupuesto,
· recursos,
Debido a la posibilidad de cambio, el desarrollo de un plan para la dirección del proyecto es iterativo y pasa por un refinamiento secuencial en varias etapas del ciclo de vida del proyecto. El refinamiento progresivo permite al equipo de gestión del proyecto definir y gestionar el trabajo a un nivel más detallado a medida que avanza el proyecto.
Programa- una serie de proyectos, subprogramas y actividades de programas relacionados que se gestionan de manera coordinada para lograr beneficios que no estarían disponibles si se gestionaran individualmente. Los programas pueden contener elementos de trabajo relacionados con ellos, pero que quedan fuera del alcance de los proyectos individuales del programa. Un proyecto puede o no ser parte de un programa, pero un programa siempre contiene proyectos.
Gestión de programas- la aplicación de conocimientos, habilidades, herramientas y técnicas a un programa para cumplir con los requisitos del programa y obtener beneficios y control que no estarían disponibles gestionando proyectos individualmente.
Los proyectos dentro de un programa están vinculados a través de un resultado común u oportunidad compartida. Si la relación entre proyectos es sólo un cliente, proveedor, tecnología o recurso común, el esfuerzo debe gestionarse como una cartera de proyectos en lugar de un programa.
La gestión de programas se centra en las interdependencias del proyecto y ayuda a determinar el mejor enfoque para gestionarlas.
Un ejemplo de programa es un nuevo sistema de comunicaciones por satélite con proyectos para diseñar el satélite y las estaciones terrestres del satélite, construir cada uno de ellos, integrar el sistema y lanzar el satélite.
Maletín Es un conjunto de proyectos, programas, subcarteras y elementos operativos gestionados en conjunto para lograr objetivos estratégicos. Los programas se agrupan dentro de una cartera y constan de subprogramas, proyectos y otras actividades gestionadas de manera coordinada en apoyo de la cartera. Los proyectos individuales que estén dentro o fuera del programa se consideran igualmente parte del portafolio. Aunque los proyectos o programas de una cartera no son necesariamente interdependientes ni están directamente relacionados, están vinculados al plan estratégico de la organización a través de la cartera de la organización.
Gestión de la cartera- gestión centralizada de una o más carteras para lograr objetivos estratégicos. La gestión de cartera se centra en proporcionar análisis de proyectos y programas para priorizar la asignación de recursos y alinear y alinear la gestión de cartera con las estrategias organizacionales.
Oficina de Gestión de Proyectos (PMO)- una estructura organizativa que estandarice los procesos de gestión de proyectos y facilite el intercambio de recursos, metodologías, herramientas y técnicas. Las responsabilidades de la PMO pueden variar desde brindar apoyo a la gestión de proyectos hasta gestionar directamente uno o más proyectos.
Existen varios tipos de estructuras de PMO en las organizaciones, cada una de las cuales difiere en el grado de control e influencia que se ejerce sobre los proyectos dentro de la organización, a saber:
· Apoyo. Las PMO de apoyo desempeñan una función de asesoramiento al proporcionar plantillas, mejores prácticas, capacitación, acceso a la información y lecciones aprendidas de otros proyectos. Este tipo de PMO sirve como repositorio de proyectos. El grado de control por parte de la PMO es bajo.
· Controlador. Las PMO brindan apoyo y hacen cumplir el cumplimiento a través de una variedad de medios. El cumplimiento puede implicar la adaptación de marcos o metodologías de gestión de proyectos, el uso de plantillas, formularios y herramientas específicos, o el cumplimiento de requisitos de gestión. El grado de control por parte de la PMO es medio.
· Principal. Los gerentes de PMO controlan los proyectos gestionando directamente estos proyectos. El grado de control por parte de la PMO es alto.
La función principal de la PMO es apoyar a los gerentes de proyectos de diversas maneras, que pueden incluir, entre otras:
· gestión de recursos comunes de todos los proyectos administrados por la PMO;
· identificación y desarrollo de metodología, mejores prácticas y estándares de gestión de proyectos;
· coaching, tutoría, formación y supervisión;
· monitorear el cumplimiento de los estándares, políticas, procedimientos y plantillas de gestión de proyectos a través de auditorías de proyectos;
· desarrollo y gestión de políticas, procedimientos, plantillas de proyectos y otra documentación general (activos de procesos organizacionales);
· coordinación de comunicaciones entre proyectos.
Los gerentes de proyecto y las PMO tienen objetivos diferentes y, por lo tanto, requisitos diferentes. Todas sus acciones están alineadas con los intereses estratégicos de la organización. Las diferencias entre el rol de un gerente de proyecto y una PMO pueden incluir lo siguiente:
· El director de proyectos se centra en objetivos específicos del proyecto, mientras que la PMO gestiona cambios importantes en el contenido del programa y puede verlos como oportunidades potenciales para lograr mejor los objetivos comerciales.
· El director del proyecto controla los recursos asignados al proyecto para lograr con mayor precisión los objetivos del proyecto, y la PMO optimiza el uso de los recursos generales de la organización en todos los proyectos.
· El director de proyecto gestiona las limitaciones (alcance, cronograma, costo y calidad, etc.) de proyectos individuales, y la PMO gestiona las metodologías, estándares, riesgos/oportunidades generales, métricas e interdependencias de proyectos a nivel empresarial.
Actividades de explotación Es una actividad continua que produce resultados repetibles, con recursos asignados para realizar un conjunto de tareas sustancialmente similar de acuerdo con estándares incorporados en el ciclo de vida del producto. A diferencia de las actividades operativas, que son de naturaleza permanente, los proyectos son empresas temporales.
Jefe de operaciones es la supervisión, dirección y control de las operaciones comerciales. Las operaciones se utilizan para respaldar las actividades del día a día y son necesarias para lograr los objetivos estratégicos y tácticos de la organización. Los ejemplos incluyen: operaciones de fabricación, operaciones de procesos, operaciones contables, soporte de software y mantenimiento.
Valor de negocio- un concepto único para cada organización. El valor empresarial se define como el valor total de una organización, la suma total de todos los elementos tangibles e intangibles. Ejemplos de elementos tangibles son los activos monetarios, los activos fijos, el capital social y las comunicaciones. Ejemplos de elementos intangibles incluyen reputación, reconocimiento de marca, beneficio público y marcas registradas. Dependiendo de la organización, el contenido del valor empresarial puede ser de corto, mediano y largo plazo. Se puede crear valor gestionando eficazmente las actividades operativas en curso. Sin embargo, a través de la aplicación efectiva de disciplinas de gestión de proyectos, programas y carteras, las organizaciones obtienen la capacidad de aplicar procesos sólidos y reconocidos para lograr objetivos estratégicos y obtener un mayor valor comercial de sus inversiones en proyectos.
Gerente de proyecto- la persona designada por la organización ejecutante para liderar el equipo y es responsable de lograr los objetivos del proyecto.
El rol de un gerente de proyecto es diferente al de un gerente funcional u de operaciones. Por lo general, un gerente funcional se centra en brindar supervisión de una unidad funcional o comercial, mientras que los gerentes operativos son responsables de garantizar la eficiencia de las operaciones comerciales.
Competencias de PR:
· Competencias de conocimiento- lo que el gerente sabe sobre la gestión de proyectos.
· Competencias de desempeño- lo que un director de proyecto es capaz de hacer o lograr aplicando sus conocimientos de gestión de proyectos.
· Competencias personales- la forma en que se comporta el director del proyecto durante la ejecución del proyecto o actividades relacionadas. La efectividad personal cubre actitudes, características básicas de la personalidad y habilidades de liderazgo: la capacidad de liderar un equipo de proyecto para lograr las metas del proyecto y equilibrar las limitaciones del proyecto.
habilidades de rol:
· liderazgo,
· fortalecer el equipo,
· motivación,
· comunicación,
· influencia,
· tomando decisiones,
· conciencia política y cultural,
· negociación,
· construir relaciones de confianza,
· la resolución de conflictos,
· entrenamiento.
2. INFLUENCIA DE LA ORGANIZACIÓN Y CICLO DE VIDA DEL PROYECTO
Activos del proceso organizacional Son los planes, procesos, políticas, procedimientos y bases de conocimiento específicos y utilizados por la organización ejecutante. Incluyen cualquier artefacto, método y conocimiento de algunas o todas las organizaciones involucradas en el proyecto que puedan usarse para ejecutar o dirigir el proyecto. Además, los activos de proceso incluyen las bases de conocimiento de la organización, como lecciones aprendidas e información histórica. Los activos de proceso de una organización pueden incluir cronogramas completos, datos de riesgo y datos de valor ganado. Los activos de proceso de una organización son entradas para la mayoría de los procesos de planificación. A lo largo del proyecto, los miembros del equipo pueden actualizar y agregar activos de proceso de la organización según sea necesario. Los activos de proceso de una organización se pueden dividir en dos categorías:
· procesos y procedimientos
· base de conocimientos corporativos
Los factores ambientales empresariales varían ampliamente en tipo o naturaleza. Los factores ambientales empresariales incluyen, entre otros:
· cultura, estructura y liderazgo organizacional;
· distribución geográfica de equipos y recursos;
· estándares gubernamentales y de la industria (por ejemplo, regulaciones de autoridades reguladoras, códigos de conducta, estándares de productos, estándares de calidad, estándares de fabricación);
· infraestructura (por ejemplo, estructuras existentes y bienes de capital);
· recursos humanos disponibles (por ejemplo, habilidades, conocimientos, especializaciones como diseño, desarrollo, asuntos legales, contratación y adquisiciones);
· gestión de personal (por ejemplo, directrices de contratación y despido, revisiones de desempeño y eficacia y registros de capacitación del personal, políticas de compensación y horas extras, y registro de tiempos);
· situacion del mercado;
· tolerancia al riesgo de las partes interesadas;
· clima político;
· canales de comunicación aceptados en la organización;
· bases de datos comerciales (por ejemplo, datos de estimación estandarizados, datos de encuestas sobre peligros industriales y bases de datos de riesgos);
· un sistema de información de gestión de proyectos (por ejemplo, sistemas automatizados como software de gestión de cronogramas, un sistema de gestión de configuración, un sistema de recopilación y distribución de información o interfaces web con otros sistemas automatizados en línea).
Los miembros del equipo del proyecto desempeñan las siguientes funciones:
· Personal responsable de la gestión del proyecto. Miembros del equipo que realizan actividades de gestión de proyectos como programación, elaboración de presupuestos, informes y control, comunicaciones, gestión de riesgos y soporte administrativo. Esta función puede ser realizada o respaldada por una oficina de gestión de proyectos (PMO).
· El personal del proyecto. Miembros del equipo que realizan el trabajo para crear entregables del proyecto.
· Expertos de apoyo. Los expertos de apoyo realizan las actividades necesarias para desarrollar o ejecutar el plan para la dirección del proyecto. Esto puede incluir negociaciones de contratos, gestión financiera, logística, soporte legal, seguridad, desarrollo, pruebas o control de calidad. Dependiendo del tamaño del proyecto y el nivel de soporte necesario, los expertos de apoyo pueden trabajar a tiempo completo o simplemente contribuir al equipo cuando se requieren sus habilidades específicas.
· Representantes de usuarios o clientes. Los miembros de la organización que aceptarán los entregables o productos del proyecto pueden actuar como representantes o enlaces para garantizar una coordinación adecuada, asesorar sobre los requisitos o confirmar la aceptabilidad de los entregables del proyecto.
· Vendedores. Los vendedores, también llamados agentes, proveedores o contratistas, son empresas de terceros contratadas para proporcionar los componentes o servicios necesarios para un proyecto. El equipo del proyecto suele ser responsable de supervisar la ejecución y aceptación de los entregables o servicios del proveedor. Si los vendedores asumen una cantidad significativa de riesgo al entregar los entregables del proyecto, pueden desempeñar un papel importante en el equipo del proyecto.
· Miembros de organizaciones de socios comerciales. Se pueden asignar miembros de organizaciones de socios comerciales al equipo del proyecto para garantizar una coordinación adecuada.
· Compañeros de negocio. Los socios comerciales también son terceros, pero tienen una relación especial con la empresa, a veces adquirida mediante un proceso de certificación. Los socios comerciales brindan experiencia especializada o desempeñan una función designada, como instalación, personalización, capacitación o soporte.
Ciclo de vida del proyecto- un conjunto de fases por las que pasa un proyecto desde el momento de su inicio hasta el momento de su cierre.
Todos los proyectos pueden tener la siguiente estructura de ciclo de vida:
· inicio del proyecto;
· organización y preparación;
· ejecución del trabajo del proyecto;
· finalización del proyecto.
Fase del proyecto- un conjunto de operaciones de proyecto lógicamente relacionadas que culminan en el logro de uno o varios entregables.
Ciclos de vida predictivos(también conocido como totalmente basado en plan) es un tipo de ciclo de vida de proyecto en el que el alcance del proyecto y el tiempo y costo necesarios para completar ese alcance se determinan lo antes posible en el ciclo de vida.
Ciclos de vida iterativos e incrementales. Son ciclos de vida en los que las fases del proyecto (también llamadas iteraciones) repiten intencionalmente una o más actividades del proyecto a medida que el equipo del proyecto comienza a comprender mejor el producto. La iteración define el desarrollo de un producto a través de una serie de ciclos repetitivos, mientras que la incrementalidad define el aumento secuencial en la funcionalidad del producto. Durante estos ciclos de vida, el producto se desarrolla de forma iterativa e incremental.
Ciclos de vida adaptativos(también conocidos como métodos ágiles o impulsados por el cambio) tienen como objetivo responder a altos niveles de cambio y requieren un alto nivel de participación de las partes interesadas en todo momento. Los métodos adaptativos también son iterativos e incrementales, pero se diferencian en que las iteraciones ocurren muy rápidamente (la duración suele ser de 2 a 4 semanas) y son fijas en términos de tiempo y costo. En los proyectos adaptativos, normalmente se realizan múltiples procesos durante cada iteración, aunque las primeras iteraciones pueden centrarse más en la planificación de actividades. El alcance general de un proyecto se divide en un conjunto de requisitos y el trabajo que debe realizarse a veces se denomina trabajo pendiente. Al comienzo de una iteración, el equipo determina cuántos elementos de alta prioridad del trabajo pendiente se pueden recuperar durante la siguiente iteración. Al final de cada iteración, el producto debería estar listo para la revisión del cliente.
3. PROCESOS DE GESTIÓN DE PROYECTOS
Gestión de proyectos Es la aplicación de conocimientos, habilidades, herramientas y técnicas al trabajo del proyecto para cumplir con los requisitos del mismo. Esta aplicación del conocimiento requiere una gestión eficaz de los procesos de gestión de proyectos.
Proceso Es un conjunto de acciones y operaciones interrelacionadas que se llevan a cabo para crear un producto, servicio o resultado predeterminado. Cada proceso se caracteriza por sus entradas, las herramientas y técnicas que se pueden aplicar y los resultados resultantes.
Los procesos del proyecto se pueden dividir en dos categorías principales:
· Procesos de gestión de proyectos. Estos procesos aseguran la ejecución efectiva del proyecto durante todo su ciclo de vida. Estos procesos cubren las herramientas y técnicas asociadas a la aplicación de las habilidades y capacidades descritas en las áreas de conocimiento.
· Procesos orientados al producto. Estos procesos definen y crean el producto del proyecto. Los procesos orientados al producto suelen estar definidos por el ciclo de vida del proyecto y varían según el dominio de la aplicación, así como la fase del ciclo de vida del producto. El alcance de un proyecto no se puede definir sin una comprensión básica de cómo crear un producto determinado. Por ejemplo, al determinar la complejidad general de un edificio que se va a construir, se deben tener en cuenta una variedad de tecnologías y herramientas de construcción.
Los procesos de gestión de proyectos se dividen en cinco categorías, conocidas como grupos de procesos de gestión de proyectos (o grupos de procesos):
· Grupo de proceso de iniciación. Procesos realizados para definir un nuevo proyecto o una nueva fase de un proyecto existente mediante la obtención de autorización para iniciar el proyecto o fase.
· Grupo de proceso de planificación. Los procesos necesarios para establecer el alcance del trabajo, aclarar los objetivos y determinar el curso de acción necesario para lograr los objetivos del proyecto.
· Grupo de proceso de ejecución. Los procesos utilizados para completar el trabajo especificado en el plan para la dirección del proyecto para cumplir con las especificaciones del proyecto.
· Grupo de Procesos de Monitoreo y Control. Procesos necesarios para rastrear, analizar y regular la ejecución del proyecto; identificar áreas que requieren cambios en el plan; e iniciar los cambios apropiados.
· Grupo de proceso de cierre. Procesos realizados para completar todas las actividades dentro de todos los grupos de procesos para cerrar formalmente un proyecto o fase.
¡Los grupos de procesos no son fases del ciclo de vida del proyecto!
Durante el ciclo de vida del proyecto, se recopila, analiza, transforma y difunde una cantidad significativa de datos e información en varios formatos a los miembros del equipo del proyecto y otras partes interesadas. Los datos del proyecto se recopilan a través de varios procesos de ejecución y luego se ponen a disposición de los miembros del equipo del proyecto.
Las siguientes pautas minimizan los malentendidos y ayudan al equipo del proyecto a utilizar la terminología adecuada:
· Datos de desempeño laboral. Observaciones y mediciones sin procesar identificadas durante las operaciones realizadas para llevar a cabo el trabajo del proyecto. Los ejemplos incluyen porcentajes de trabajo físicamente completado, métricas de calidad y métricas de desempeño técnico, fechas de inicio y finalización de actividades programadas, cantidad de solicitudes de cambio, cantidad de defectos, costo real, duración real, etc.
· Información sobre la ejecución de la obra. Datos de desempeño recopilados de varios procesos de control, analizados en contexto y resumidos en función de las relaciones entre disciplinas. Ejemplos de información de desempeño incluyen el estado de los entregables, el estado de implementación de las solicitudes de cambio y la evaluación de los pronósticos hasta su finalización.
· Informes de desempeño laboral. Una representación física o electrónica de la información sobre el desempeño laboral recopilada en los documentos del proyecto, destinada a tomar decisiones o formular problemas, llevar a cabo acciones o crear conciencia. Los ejemplos incluyen informes de estado, memorandos, fundamentos, hojas informativas, paneles electrónicos, avisos y actualizaciones.
Los 47 procesos de gestión de proyectos descritos en la Guía del PMBOK se dividen en 10 áreas de conocimiento distintas. Un área de conocimiento es un sistema integral de conceptos, términos y actividades que conforman un campo profesional, campo de gestión de proyectos o campo de actividad. Estas 10 áreas de conocimiento se utilizan casi constantemente en la mayoría de los proyectos. Los equipos de proyecto deben utilizar estas 10 áreas de conocimiento y otras áreas de conocimiento según sea necesario para su proyecto específico. Las áreas de especialización incluyen:
· Manejo del proyecto de integración,
· gestión del contenido del proyecto,
· Gestión del tiempo del proyecto,
· gestión de costes del proyecto,
· gestión de la calidad del proyecto,
· gestión de recursos humanos del proyecto,
· gestión de comunicaciones del proyecto,
· gestión de riesgos del proyecto,
· gestión de adquisiciones de proyectos,
· gestión de los stakeholders del proyecto.
4. GESTIÓN DE INTEGRACIÓN DE PROYECTOS
La gestión de la integración de proyectos incluye los procesos y actividades necesarios para definir, perfeccionar, combinar, integrar y coordinar los diversos procesos y actividades de la gestión de proyectos dentro de los grupos de procesos de gestión de proyectos.
La carta del proyecto contiene:
· propósito o justificación del proyecto;
· objetivos medibles del proyecto y criterios de éxito correspondientes;
· requisitos de alto nivel;
· supuestos y limitaciones;
· descripción de alto nivel y límites del proyecto;
· riesgos de alto nivel;
· cronograma ampliado de eventos de control;
· presupuesto ampliado;
· lista de partes interesadas;
· requisitos para la aprobación del proyecto (es decir, qué constituye exactamente el éxito de un proyecto, quién decide que el proyecto es exitoso y quién aprueba el proyecto);
· director de proyecto asignado, área de responsabilidad y nivel de autoridad;
· NOMBRE COMPLETO. y la autoridad del patrocinador u otra persona que autorice el estatuto del proyecto.
Descripción del trabajo La declaración de trabajo (SOW) de un proyecto es una descripción verbal de los productos, servicios o resultados que se espera que produzca el proyecto.
SOW refleja:
· Necesidad de Negocios. La necesidad comercial de una organización puede basarse en la demanda del mercado, avances tecnológicos, requisitos legales, regulaciones gubernamentales o consideraciones ambientales. Normalmente, en el caso de negocio se incluyen una necesidad empresarial y un análisis comparativo de costes y beneficios para justificar el proyecto.
· Descripción del contenido del producto. La declaración del alcance del producto incluye las características del producto, servicio o resultado que el proyecto se propone crear. La descripción también debe reflejar la relación entre los productos, servicios o resultados que se crean y la necesidad comercial que el proyecto debe satisfacer.
· Plan estratégico. Un plan estratégico incluye la visión estratégica, las metas y los objetivos de la organización y una declaración de misión de alto nivel. Todos los proyectos deben ser consistentes con el plan estratégico de la organización. La alineación con el plan estratégico permite que cada proyecto contribuya a los objetivos generales de la organización.
Caso de negocio
Un caso de negocio o documento similar proporciona la información necesaria desde una perspectiva empresarial para determinar si un proyecto vale la inversión requerida. Generalmente lo utilizan los gerentes de proyectos de nivel superior para tomar decisiones. Por lo general, un caso de negocios contiene una necesidad comercial y un análisis comparativo de costo-beneficio para justificar el proyecto y definir sus límites, y normalmente dicho análisis lo realiza un analista de negocios utilizando diversa información obtenida de las partes interesadas. El patrocinador debe estar de acuerdo sobre el contenido y las limitaciones del caso de negocio. Un caso de negocio se crea como resultado de uno o más de los siguientes factores:
la demanda del mercado (por ejemplo, una empresa de automóviles autoriza un proyecto para producir automóviles más eficientes en el consumo de combustible en respuesta a la escasez de gasolina);
· la necesidad de la organización (por ejemplo, debido a los altos costos generales, la empresa puede combinar funciones de personal y optimizar procesos para reducir costos);
· requerimiento del cliente (por ejemplo, una compañía eléctrica autoriza un proyecto para construir una nueva subestación para suministrar energía a una nueva zona industrial);
· progreso tecnológico (por ejemplo, una aerolínea autoriza un nuevo proyecto para desarrollar billetes electrónicos que reemplacen los billetes impresos en papel, basándose en los avances tecnológicos);
· requisito legal (por ejemplo, un fabricante de pintura autoriza un proyecto para desarrollar directrices para el manejo de materiales tóxicos);
· impactos ambientales (por ejemplo, una empresa autoriza un proyecto para reducir su impacto en el medio ambiente);
· necesidad social (por ejemplo, una organización no gubernamental de un país en desarrollo autoriza un proyecto para proporcionar sistemas de agua potable, sanitarios y educación sanitaria a comunidades que sufren altas tasas de cólera).
Acuerdos
Los acuerdos se utilizan para definir las intenciones iniciales de un proyecto. Los acuerdos pueden tomar la forma de un contrato, memorando de entendimiento, acuerdo de nivel de servicio, carta de compromiso, carta de intención, acuerdos orales, comunicación electrónica u otros acuerdos escritos. Normalmente se utiliza un contrato si el proyecto se lleva a cabo para un cliente externo.
Factores ambientales de la empresa
Los factores ambientales empresariales que pueden influir en el proceso de desarrollo del estatuto del proyecto incluyen, entre otros:
· normas o reglamentos gubernamentales y de la industria (por ejemplo, códigos de conducta, normas de calidad o normas de protección de los trabajadores);
· cultura y estructura organizacional;
· situacion del mercado.
Activos del proceso organizacional
Los activos del proceso organizacional que pueden influir en el proceso de desarrollo del estatuto del proyecto incluyen, entre otros:
· procesos organizacionales estándar, políticas y descripciones de procesos;
· plantillas (por ejemplo, una plantilla de estatuto del proyecto);
información histórica y base de conocimientos (por ejemplo, proyectos, registros y documentos, toda la información y documentación del cierre del proyecto, información sobre los resultados de las decisiones de selección de proyectos anteriores junto con información sobre el desempeño de proyectos anteriores e información sobre actividades de gestión de riesgos).
Plan de gestión de proyectos- este es un documento que describe cómo se ejecutará el proyecto, cómo será monitoreado y controlado. Integra y consolida todos los planes de apoyo y de referencia resultantes de los procesos de planificación.
Las líneas de base del proyecto incluyen, entre otras:
· plan de contenido básico;
· horario básico;
· plan de costos básico.
Los planes de apoyo incluyen, entre otros:
· plan de gestión de contenidos;
· plan de gestión de requisitos;
· plan de gestión de horarios;
· plan de gestión de costos;
· plan de gestión de calidad;
· plan de mejora de procesos;
· plan de gestión de recursos humanos;
· plan de gestión de comunicaciones;
· plan de gestión de Riesgos;
· plan de gestión de adquisiciones;
· plan de gestión de stakeholders.
Entre otras cosas, el plan para la dirección del proyecto también puede incluir lo siguiente:
· el ciclo de vida elegido para el proyecto y los procesos que se aplicarán en cada fase;
detalles de las decisiones de adaptación tomadas por el equipo de gestión del proyecto, a saber:
o procesos de gestión de proyectos seleccionados por el equipo de gestión del proyecto;
o nivel de implementación de cada proceso seleccionado;
o descripciones de las herramientas y métodos que se utilizarán para realizar estos procesos;
o Una descripción de cómo se utilizarán los procesos seleccionados para gestionar un proyecto específico, incluidas las dependencias e interacciones entre estos procesos, así como las entradas y salidas requeridas.
· el procedimiento para realizar el trabajo para lograr los objetivos del proyecto;
· un plan de gestión de cambios que documente cómo se monitorean y controlan los cambios;
· un plan de gestión de la configuración que documente cómo se gestiona la configuración;
· una descripción del procedimiento para mantener la integridad de los planes de referencia;
· requisitos y métodos de comunicación entre las partes interesadas;
· actividades clave de revisión por la dirección con respecto al contenido, alcance y oportunidad de las cuestiones a considerar y las decisiones a tomar.
Predicciones de horarios
Los pronósticos del cronograma se realizan en función del progreso relativo al cronograma de referencia y el tiempo de pronóstico hasta la finalización (ETT). Por lo general, se expresan en términos de variación del cronograma (SDV) e índice de desempeño del cronograma (MSI). Para los proyectos que no utilizan la gestión del valor ganado, se informan las desviaciones de las fechas de finalización planificadas y proyectadas.
El pronóstico se puede utilizar para determinar si un proyecto está dentro de la tolerancia y para identificar las solicitudes de cambio necesarias.
Previsiones de costes
Los pronósticos de costos se realizan en función del progreso en relación con la línea base de costos y el pronóstico estimado hasta la finalización (EFT). Por lo general, se expresan en términos de variación de costos (CVI) e índice de desempeño de costos (CVPI). El Pronóstico hasta la finalización (FCP) se puede comparar con el Presupuesto hasta la finalización (BOC) para determinar si el proyecto está dentro de la tolerancia o si son necesarias solicitudes de cambio. Para los proyectos que no utilizan la gestión del valor ganado, se informan las variaciones de los costos planificados y reales, así como el costo final proyectado.
Las siguientes son algunas de las actividades de gestión de configuración incluidas en el proceso de control de cambios integrado:
· Definición de configuración. Defina y seleccione elementos de configuración para proporcionar una base a partir de la cual se define y valida la configuración del producto, se etiquetan los productos y documentos, se controlan los cambios y se mantiene la contabilidad.
· Informes sobre el estado de la configuración. Cuando es necesario proporcionar datos apropiados sobre un elemento de configuración, la información se documenta y reporta. Dicha información incluye una lista de elementos de configuración identificados aprobados, el estado de los cambios de configuración propuestos y el estado de implementación de los cambios aprobados.
· Confirmación y auditoría de configuración. La validación de la configuración y las auditorías garantizan que la estructura de los elementos de configuración del proyecto sea correcta y que los cambios apropiados se registren, evalúen, aprueben, realicen un seguimiento y se implementen adecuadamente. Esto garantiza que se cumplan los requisitos funcionales definidos en la documentación de configuración.
5. GESTIÓN DEL CONTENIDO DEL PROYECTO
La gestión del alcance del proyecto incluye los procesos necesarios para garantizar que el proyecto contenga todo y sólo el trabajo necesario para completarlo con éxito. La gestión del alcance del proyecto se ocupa directamente de definir y controlar lo que se incluye y lo que no se incluye en el proyecto.
En el contexto de un proyecto, el término "contenido" puede referirse a:
Clases de requisitos:
· Requisitos de negocio, que describen las necesidades de alto nivel de la organización en su conjunto, como los problemas u oportunidades de la organización, y las razones por las que se emprendió el proyecto.
· Requisitos de las partes interesadas, que describen las necesidades de una parte interesada o grupo de partes interesadas.
· Requisitos de solución que describen las características, funciones y características de un producto, servicio o resultado que satisfará los requisitos comerciales y de las partes interesadas. Los requisitos de la solución, a su vez, se agrupan en requisitos funcionales y no funcionales:
o Los requisitos funcionales describen el comportamiento de un producto. Los ejemplos incluyen procesos, datos e interacciones de productos.
o Los requisitos no funcionales complementan los requisitos funcionales y describen las condiciones o cualidades ambientales necesarias para asegurar la eficacia del producto. Los ejemplos incluyen: confiabilidad, seguridad, rendimiento, seguridad, nivel de servicio, compatibilidad, requisitos de almacenamiento/eliminación, etc.
· Los requisitos de transición describen capacidades temporales, como la transformación de datos y los requisitos de aprendizaje, necesarios para pasar del estado actual "tal cual" al estado "futuro" en el futuro.
· Los requisitos del proyecto describen las actividades, procesos u otras condiciones que el proyecto debe cumplir.
· Requisitos de calidad, que incluyen cualquier condición o criterio necesario para demostrar el logro exitoso de un resultado entregable del proyecto o el cumplimiento de otros requisitos del proyecto.
6. GESTIÓN DEL TIEMPO DEL PROYECTO
La gestión del tiempo del proyecto incluye los procesos necesarios para garantizar que un proyecto se complete a tiempo.
Tipos de dependencias de operación:
· Finalizar-empezar(final-inicio, FS). Relación lógica en la que el inicio de una operación posterior depende del final de la operación anterior. Ejemplo: La ceremonia de entrega de medallas (operación sucesora) no puede iniciarse hasta que se complete la carrera de la operación predecesora).
· Acabado-acabado(fin-fin, FF). Una relación lógica en la que el final de una operación posterior depende del final de la operación anterior. Ejemplo: se debe completar la creación de un documento (operación predecesora) antes de completar su edición (operación posterior).
· inicio-inicio(inicio-inicio, SS). Relación lógica en la que el inicio de una operación posterior depende del inicio de la operación anterior. Ejemplo: La nivelación de una superficie de hormigón (operación posterior) no puede comenzar antes de verter los cimientos (operación anterior).
· Inicio-fin(salida-finalización, SF). Relación lógica en la que el final de una operación posterior depende del inicio de la operación anterior. Ejemplo: El primer turno de seguridad (operación sucesora) no puede finalizar hasta que comience el segundo turno de seguridad (operación predecesora).
Evaluación de tres puntos
La precisión de las estimaciones de la duración de la actividad de un solo punto se puede mejorar considerando las incertidumbres y los riesgos de la estimación. Este concepto proviene de la técnica de evaluación y revisión de programas (PERT). PERT utiliza tres estimaciones para determinar el rango aproximado de duración de la operación:
· Más probable(tM). La duración de una operación se determina teniendo en cuenta la preasignación de recursos, su desempeño, una evaluación realista de su disponibilidad para completar la operación, la dependencia de otros participantes y también teniendo en cuenta las interrupciones en el trabajo.
· Optimista(a). La duración de la operación se basa en un análisis del mejor escenario para la operación.
· Pesimista(TP). La duración de la operación se basa en un análisis del peor escenario para la operación.
Dependiendo de la distribución esperada de valores en el rango de tres estimaciones, la fórmula calcula la duración esperada, tE. Las dos fórmulas más comunes son la distribución triangular y la distribución beta.
· Distribución triangular. tE = (tO + tM + tP) / 3
· Distribución beta (del método PERT tradicional). tE = (tO + 4tM + tP) / 6
Método del camino crítico
Método del camino crítico- un método utilizado para estimar la duración mínima de un proyecto y determinar el grado de flexibilidad del cronograma a lo largo de rutas lógicas en una red dentro de un modelo de cronograma. El método de análisis de la red del cronograma le permite calcular las fechas tempranas de inicio y finalización, así como las fechas tardías de inicio y finalización de todas las actividades, sin tener en cuenta las limitaciones de recursos, mediante la realización de un análisis de avance y retroceso de la red del proyecto, como mostrado en la Fig. 6-18. En este ejemplo, el camino más largo incluye las actividades A, C y D y, por lo tanto, la secuencia A-C-D es el camino crítico. La ruta crítica es una secuencia de actividades que representa el camino más largo en el cronograma del proyecto, lo que determina la duración más corta posible del proyecto. Las fechas de inicio y finalización anticipadas resultantes no son necesariamente el cronograma del proyecto; más bien, especifican períodos de tiempo dentro de los cuales se puede realizar una actividad utilizando parámetros ingresados en el modelo de cronograma relacionados con duraciones de actividades, relaciones lógicas, adelantos, retrasos y otras restricciones conocidas. método crítico
La ruta se utiliza para calcular el grado de flexibilidad de programación a lo largo de rutas lógicas en una red dentro de un modelo de programación.
Método de cadena crítica
Método de cadena crítica(CCM) es un método de desarrollo del cronograma que permite al equipo del proyecto colocar reservas a lo largo de cualquier ruta en el cronograma para tener en cuenta las limitaciones de recursos y las incertidumbres asociadas con el proyecto. Se desarrolla a partir del método de la ruta crítica y toma en cuenta los impactos de la asignación, optimización, nivelación de recursos, así como
Incertidumbre sobre la duración de una actividad en el camino crítico determinado por el método del camino crítico. El método de la cadena crítica incluye los conceptos de buffers y gestión de buffers. El método de la cadena crítica utiliza operaciones cuya duración no incluye límites de seguridad, conexiones lógicas y disponibilidad de recursos con
Amortiguadores definidos estadísticamente que incluyen márgenes de seguridad generales para operaciones en puntos específicos del proyecto a lo largo de la ruta del cronograma del proyecto para tener en cuenta los recursos limitados y la incertidumbre asociada con el proyecto. Una ruta crítica con limitaciones de recursos se conoce como "cadena crítica".
7. GESTIÓN DE COSTOS DEL PROYECTO
La gestión de costos del proyecto incluye los procesos necesarios para planificar, estimar, presupuestar, recaudar fondos, financiar, gestionar y controlar los costos para garantizar que el proyecto se ejecute dentro del presupuesto aprobado.
Gestion del valor ganado
Gestion del valor ganado(EVM) es una metodología que combina evaluaciones de alcance, cronograma y recursos para medir el progreso del proyecto y la efectividad alcanzada. Es un método ampliamente aceptado para medir el desempeño de un proyecto. Combina la línea base del alcance con la línea base de costos, así como la línea base del cronograma del proyecto para formar una línea base de ejecución que permite al equipo de gestión del proyecto evaluar y medir el desempeño y el progreso del proyecto. Es un método de gestión de proyectos que requiere el desarrollo de una línea de base integrada contra la cual se puede medir el desempeño a lo largo del proyecto. Los principios de EVM se pueden aplicar a
todos los proyectos en cualquier industria. Utilizando EVM, se desarrollan y monitorean los siguientes tres indicadores clave para cada paquete de trabajo y cuenta de control:
· Volumen planificado. El volumen planificado (PO) es el presupuesto autorizado asignado para el trabajo planificado. Es el presupuesto autorizado destinado a trabajos a realizar dentro de un componente de estructura de operación o desglose de obra, excluida la reserva de gestión. Este presupuesto se asigna a fases del ciclo de vida del proyecto, pero en cierto punto el alcance planificado determina el trabajo físico que se iba a completar. El software agregado a veces se denomina línea base de medición del desempeño (PMB). El volumen total planificado de un proyecto también se conoce como presupuesto para completar (BOC).
· Volumen masterizado. Volumen asimilado (AS) es el volumen de obra realizada, expresado en términos del presupuesto autorizado destinado a estas obras. Este es el presupuesto asociado al trabajo autorizado que se ha realizado. El TOE medido debe estar asociado con el PMB y el TOE medido no puede exceder el presupuesto de software autorizado para ese componente. TOE se utiliza a menudo para calcular el porcentaje de finalización de un proyecto. Para cada componente de la EDT, se deben establecer criterios para medir el progreso del trabajo realizado. Los gerentes de proyecto monitorean el TOE, tanto de manera incremental para determinar el estado actual como de forma acumulativa para determinar las tendencias de desempeño a largo plazo.
· Costo real. El costo real (AC) son los costos reales incurridos para realizar el trabajo como parte de una operación durante un cierto período de tiempo. Estos son los costos totales incurridos al realizar las actividades medidas por la OO. Los FS, por definición, deben corresponder a lo que se incluyó en el software y se midió por la OO (por ejemplo, solo los costos directos del tiempo de trabajo, solo los costos directos o todos los costos, incluidos los indirectos). El FS no tiene límite superior; Se mide todo lo que se gasta para lograr la OO.
También se monitorean las desviaciones del plan base aprobado:
· Desviación de tiempo. La desviación del cronograma (SDV) es un indicador de la ejecución del cronograma, expresado como la diferencia entre el volumen dominado y el volumen planificado. La cantidad de tiempo que un proyecto está retrasado o adelantado con respecto a su fecha de entrega planificada en un momento determinado. Es una medida de la ejecución del cronograma del proyecto. Su valor es igual al volumen masterizado (VR) menos el volumen planificado (VP). La variación del cronograma de EVM es una métrica útil porque muestra cuándo un proyecto está retrasado o adelantado respecto de su línea de base. La variación del cronograma en EVM finalmente será cero al final del proyecto, ya que para entonces todas las cantidades planificadas deben completarse. La variación de tiempo se utiliza mejor junto con la programación del método de ruta crítica (CPM) y la gestión de riesgos. Fórmula: OSR = OO - PO
· Variación de costo. La variación de costos (CVV) es la cantidad de déficit o superávit presupuestario en un momento determinado, expresada como la diferencia entre el valor ganado y el costo real. Es una medida del desempeño de un proyecto en términos de costo. Es igual al valor ganado (EV) menos el costo real (FC). La variación de costos al final del proyecto será igual a la diferencia entre el presupuesto al finalizar (BOC) y el monto realmente gastado. El OST es extremadamente importante porque demuestra la conexión entre el desempeño físico y los fondos gastados. Los OST negativos a menudo no son recuperables para el proyecto. Fórmula: OST = OO – FS.
Los valores de OCP y OCP se pueden convertir en indicadores de desempeño para reflejar el costo y el desempeño del cronograma de cualquier proyecto en relación con todos los demás proyectos o dentro de una cartera de proyectos. Las variaciones son útiles para determinar el estado de un proyecto.
· Índice de cumplimiento de plazos. El índice de cumplimiento de tiempo (DMI) es un indicador de la efectividad del cronograma, expresado como la relación entre el volumen dominado y el volumen planificado. Mide la eficacia con la que el equipo del proyecto utiliza su tiempo. A veces se utiliza junto con el Índice de costos de finalización (CVSI) para predecir las estimaciones finales de finalización del proyecto. Un valor de VSI inferior a 1,0 indica que se completó menos trabajo del previsto. Un valor de VSI superior a 1,0 indica que se ha completado más trabajo del previsto. Dado que el RSI mide todas las actividades del proyecto, también es necesario analizar el desempeño a lo largo de la ruta crítica para determinar si el proyecto se completará antes o después de su fecha de finalización planificada. IVSR es igual a la relación entre OO y PO. Fórmula: IVSR = OO/PO
· Índice de desempeño de costos. El índice de desempeño de costos (CVTI) es un indicador de la efectividad de los recursos incluidos en el presupuesto al costo, expresado como la relación entre el volumen ganado y el costo real. Se considera la métrica EVM más importante y mide la rentabilidad del trabajo realizado. Un valor de IVST inferior a 1,0 indica sobrecostos por el trabajo realizado. Un valor de IVST superior a 1,0 indica subutilización de fondos durante la ejecución en una fecha específica. IVSR es igual a la relación entre OO y FS. Los índices son útiles para determinar el estado de un proyecto y también proporcionan una base para estimar el plazo y el costo final de un proyecto. Fórmula: IVST = OO/FS
Los tres indicadores de volumen planificado, valor ganado y costo real pueden monitorearse e informarse periódicamente (generalmente semanal o mensualmente) o de forma acumulativa.
Previsión
A medida que avanza el proyecto, el equipo del proyecto puede desarrollar un pronóstico para completar (BCT), que puede diferir de un presupuesto para completar (BCP), según el desempeño del proyecto. Si resulta evidente que el BPF ya no es realista, el director del proyecto debe revisarlo. El desarrollo de una APP implica predecir las condiciones y eventos que ocurrirán en el futuro del proyecto, basándose en la información de desempeño actual y otros conocimientos disponibles en el momento del pronóstico. Los pronósticos se generan, actualizan y reemiten en función de
datos de desempeño del trabajo obtenidos a medida que avanza el proyecto. La información sobre el desempeño del trabajo cubre el desempeño pasado del proyecto y cualquier información que pueda afectar el proyecto en el futuro.
El PPV generalmente se calcula como el costo real registrado para el trabajo completado más el pronóstico de finalización (FTC) para el trabajo restante. El equipo del proyecto tiene la responsabilidad de predecir lo que puede encontrar durante la implementación del proyecto, basándose en la experiencia disponible actualmente. El método EVM funciona bien junto con pronósticos desarrollados manualmente del PPV requerido. El enfoque de pronóstico de PPV más utilizado es una suma manual ascendente realizada por el director del proyecto y el equipo del proyecto.
El método BPM ascendente utilizado por el director del proyecto se basa en los costos reales registrados y la experiencia obtenida del trabajo completado, y requiere la construcción de un nuevo pronóstico antes de la finalización del trabajo restante del proyecto. Fórmula: PPZ = FS + PDZ “de abajo hacia arriba”.
El KPI, desarrollado manualmente por el director del proyecto, se compara rápidamente con una serie de KPI calculados que representan una variedad de escenarios de riesgo. Al calcular los valores de PPV, por regla general, se utilizan los valores acumulativos de IVST e IVSR. Aunque los datos de EVM pueden producir rápidamente muchos PPV estadísticos, a continuación solo se describen los tres métodos más comunes:
· PPZ para trabajos de PPZ realizados a tarifas presupuestadas. Este método de APP utiliza el desempeño real del proyecto en una fecha específica (favorable o desfavorable), representada por el costo real, y predice que todo el trabajo futuro de la APP se realizará a tasas presupuestadas. Cuando el desempeño real sea desfavorable, la suposición de que el desempeño futuro mejorará sólo debe aceptarse si está respaldada por el análisis de riesgos del proyecto. Fórmula: PPZ = FS + (BPZ – OO)
· PPZ para trabajos PPZ realizados con el IVST actual. Este método supone que el proyecto continuará en el futuro de la misma manera que hasta ahora. Se supone que el trabajo de PD se realizará al mismo nivel del índice de desempeño de costos acumulados (CVPI) que se ha logrado en el proyecto hasta este momento. Fórmula: PPZ = BPZ/IVST
· PPZ para trabajo PDZ, teniendo en cuenta ambos factores IVSR e IVST. En esta previsión, el trabajo de DP se realizará con eficiencia, lo que tiene en cuenta los índices de desempeño tanto de costo como de tiempo. Este método es más útil cuando uno de los factores que influyen en el cronograma del proyecto es el cronograma del proyecto. El IVST y el IVSR consideran las variaciones de este método en diversas proporciones (por ejemplo, 80/20, 50/50 u otras proporciones), de acuerdo con la opinión del director del proyecto. Fórmula: PPZ = FS + [(BPZ – OO)/(IVST x IVSR)]
Cada uno de estos enfoques se puede aplicar a cualquier proyecto determinado y proporcionar al equipo de gestión del proyecto una señal de “alerta temprana” si las APP quedan fuera de las tolerancias aceptadas.
Índice de desempeño hasta la finalización (PTI)
Índice de desempeño hasta la finalización(IPDZ): un indicador estimado de la efectividad del proyecto en términos de costo, que debe lograrse con los recursos restantes para lograr el indicador de gestión establecido, expresado como la relación entre el costo de completar la parte restante del trabajo. al presupuesto restante. El IPD es un índice calculado de entrega de valor que debe alcanzarse con el trabajo restante para lograr un objetivo de gestión específico, como la BPZ o la PPZ. Si resulta evidente que el BPF ya no es realista, el director del proyecto debe revisarlo. Una vez aprobada, la PPZ puede sustituir a la BPZ en el cálculo del IPPD. Fórmula para IPPD basada en BPZ: (BPZ – OO)/(BPZ – FS). El IPPD se presenta conceptualmente en la siguiente figura. La fórmula para IPD se muestra en la esquina inferior izquierda: el trabajo restante (definido como BP menos OO) dividido por los fondos restantes (que se pueden calcular como BP menos FS o PP menos FS).
Si el ICSI acumulado está por debajo de la línea de base (como se muestra en la figura a continuación), todo el trabajo futuro en el proyecto debe realizarse inmediatamente de acuerdo con el BPSI (como se refleja en la línea superior de la figura a continuación) para permanecer dentro de la BPZ autorizada. . El juicio sobre si un determinado nivel de desempeño es alcanzable se basa en una serie de consideraciones, incluido el riesgo, el cronograma y el desempeño técnico. Este nivel de rendimiento se representa como una línea IPD (PPZ). Fórmula para IPPD basada en PPZ: (BPZ - OO)/(PPZ - FS). Las fórmulas de EVM se presentan en la siguiente tabla.
Análisis de rendimiento
El análisis de desempeño compara el desempeño de los costos a lo largo del tiempo, programa actividades o paquetes de trabajo que están por encima o por debajo del presupuesto y estimaciones de los fondos necesarios para completar el trabajo que se está realizando. Si se utiliza EVM, se determina la siguiente información:
· Análisis de desviación. El análisis de variaciones, cuando se utiliza en EVM, es la explicación (causa, impacto y acción correctiva) de las variaciones de costo (COV = OO - FS), cronograma (OSR = OO - PO) y variaciones de finalización (HCP = BP - PPZ). Las desviaciones analizadas con mayor frecuencia son el costo y el cronograma. Para proyectos que no utilizan la gestión del valor ganado, se puede realizar un análisis de variación similar comparando el costo de la actividad planificada con el costo de la actividad real para determinar la variación del desempeño real del proyecto con respecto a la línea base de costos. Se pueden realizar análisis adicionales para determinar la causa y el alcance de la desviación del cronograma de referencia y las acciones correctivas o preventivas necesarias. Las medidas de desempeño de costos se utilizan para estimar la cantidad de desviación de la línea base de costos original. Los aspectos importantes de la gestión de costos del proyecto incluyen determinar la causa y el alcance de la desviación de la línea base de costos y decidir si son necesarias acciones correctivas o preventivas. A medida que se completa más y más trabajo, el rango porcentual de desviaciones aceptables tenderá a disminuir.
· Análisis de tendencia. El análisis de tendencias implica examinar los datos de desempeño del proyecto a lo largo del tiempo para determinar si el desempeño del proyecto está mejorando o deteriorándose. Las técnicas de análisis gráfico son valiosas para comprender el desempeño hasta una fecha específica y para comparar con objetivos de desempeño futuros en forma de BPV versus PPV y en forma de fechas de finalización.
· Ejecución del valor ganado. La ejecución del valor ganado implica comparar el plan de ejecución básico con la implementación real de plazos y costos. Si no se utiliza EVM, se utiliza un análisis de línea base de costos en relación con el costo real del trabajo realizado para comparar el desempeño de los costos.
8. GESTIÓN DE CALIDAD DEL PROYECTO
La gestión de la calidad del proyecto incluye los procesos y actividades de la organización ejecutora que definen políticas, objetivos y responsabilidades de calidad para que el proyecto satisfaga las necesidades para las cuales fue emprendido. La gestión de la calidad del proyecto utiliza políticas y procedimientos para implementar el sistema de gestión de la calidad de la organización en el contexto del proyecto y, cuando sea necesario, apoya las actividades de mejora continua en los procesos emprendidos por la organización ejecutante. La gestión de la calidad del proyecto tiene como objetivo garantizar que se cumplan y verifiquen los requisitos del proyecto, incluidos los requisitos del producto.
Calidad y grado son conceptos conceptualmente diferentes. La calidad, como producto o resultado entregado, es “el grado en que un conjunto de características inherentes cumplen con los requisitos” (ISO 9000). Una calificación como intención de diseño es una categoría asignada a entregables que tienen el mismo propósito funcional pero diferentes características técnicas. El director del proyecto y el equipo de gestión del proyecto son responsables de hacer concesiones para lograr los niveles requeridos tanto de calidad como de grado. Un nivel de calidad que no cumple con los requisitos de calidad siempre es un problema, pero una calificación baja puede no ser un problema.
En el contexto de lograr el cumplimiento de ISO, los enfoques modernos de gestión de la calidad se esfuerzan por minimizar la variación y lograr resultados que cumplan con requisitos específicos. Estos enfoques reconocen la importancia de lo siguiente:
· La satisfacción del cliente. Comprender, evaluar, definir y gestionar los requisitos del cliente para satisfacer sus expectativas. Esto requiere una combinación de idoneidad (el proyecto debe producir aquello que se pretendía lograr) y usabilidad (el producto o servicio debe satisfacer una necesidad real).
· La prevención es más importante que la inspección. La calidad debe planificarse, diseñarse e incorporarse, en lugar de inspeccionarse, en la gestión del proyecto o en la entrega de los entregables del proyecto. El costo de prevenir errores suele ser mucho menor que el costo de corregirlos una vez descubiertos mediante inspección o durante el uso.
· Mejora continua. El ciclo planificar-hacer-verificar-actuar (PDCA), un modelo descrito por Shewhart y perfeccionado por Deming, es la base para la mejora de la calidad. Además, las iniciativas de mejora de la calidad como Total Quality Management (TQM), Six Sigma y la aplicación combinada de Six Sigma y Lean Six Sigma pueden mejorar la calidad de la gestión de proyectos y también la calidad del producto del proyecto. Los modelos de mejora de procesos incluyen el Modelo de Calidad de Malcolm Baldrige, el Modelo de Madurez de Gestión de Proyectos Organizacionales (OPM3®) y el Modelo de Madurez de Capacidad Integrada (CMMI®).
· La responsabilidad de gestión. El éxito requiere la participación de todos los miembros del equipo del proyecto. Sin embargo, la dirección conserva, como parte de su responsabilidad por la calidad, la responsabilidad adecuada de proporcionar los recursos adecuados en una cantidad adecuada.
· costo de calidad(coste de calidad, COQ). El costo de calidad es el costo total del trabajo de cumplimiento y el trabajo de no conformidad que debe realizarse como esfuerzo compensatorio porque la primera vez que se intenta el trabajo, existe la posibilidad de que una parte del trabajo requerido se haya realizado o se haya realizado incorrectamente. . Los costos de realizar actividades de aseguramiento de la calidad pueden surgir a lo largo del ciclo de vida del resultado entregado. Por ejemplo, las decisiones tomadas por el equipo del proyecto pueden afectar los costos de transacción asociados con el uso del producto finalizado. Los costos asociados con el aseguramiento de la calidad después del cierre del proyecto pueden surgir de devoluciones de productos, reclamos de garantía y campañas de retirada de productos. Por lo tanto, debido a la naturaleza temporal del proyecto y los beneficios potenciales que pueden derivarse de la reducción del costo de calidad posterior al proyecto, las organizaciones patrocinadoras pueden decidir invertir en mejorar la calidad del producto. Estas inversiones generalmente se realizan en el área de esfuerzos de cumplimiento para prevenir defectos o reducir el costo de los defectos mediante la inspección de unidades no conformes. Además, las cuestiones relacionadas con el COQ posterior al proyecto deben abordarse a través de los procesos de gestión de programas y carteras; por ejemplo, las oficinas de gestión de proyectos, programas y carteras deben aplicar métodos de análisis, plantillas y métodos adecuados para asignar fondos para este fin.
Siete herramientas de calidad esenciales
Las Siete Herramientas Esenciales de Calidad, también conocidas en la industria como herramientas 7QC, se utilizan en el contexto del ciclo PDCA para abordar problemas de calidad. Arroz. A continuación se muestra una ilustración conceptual de las siete herramientas básicas de calidad, que incluyen:
· Diagramas de causa y efecto, también llamados diagramas de espina de pescado o diagramas de Ishikawa. La descripción del problema ubicada en la cabeza de la espina de pescado se utiliza como punto de partida para rastrear el origen del problema hasta la causa raíz que requiere acción. La descripción de un problema suele ser una declaración del problema como una deficiencia que debe abordarse o una meta que debe alcanzarse. La búsqueda de causas se lleva a cabo examinando la descripción del problema y buscando respuestas a la pregunta "por qué" hasta que se identifique la causa raíz que requiere acción, o hasta que se hayan agotado todas las posibilidades razonables en cada parte del esqueleto del pez. Los diagramas de espina de pescado suelen ser útiles para vincular un efecto indeseable considerado como una variación específica con una causa identificada para la cual los equipos del proyecto deben tomar medidas correctivas para eliminar esa variación específica identificada en el gráfico de control.
· Diagramas de bloques, también llamados mapas de procesos, porque muestran la secuencia de pasos y posibilidades de ramificación de un proceso que transforma una o más entradas en una o más salidas. Los diagramas de flujo reflejan operaciones, puntos de decisión, ciclos, caminos paralelos y ordenamiento de procesos al representar como un mapa los detalles operativos de los procedimientos que existen dentro de la cadena de valor horizontal del modelo SIPOC. Los diagramas de flujo pueden resultar útiles para comprender y estimar el costo de la calidad dentro de un proceso. Esto se logra utilizando la lógica del flujo de trabajo y sus frecuencias relativas asociadas para estimar el valor monetario esperado del trabajo de cumplimiento y el trabajo de no conformidad requerido para proporcionar un resultado conforme.
· Hojas de recogida de datos, También conocidas como hojas de recuento, se pueden utilizar como listas de verificación al recopilar datos. Las hojas de recopilación de datos se utilizan para organizar hechos de una manera que facilite la recopilación eficiente de datos útiles sobre un posible problema de calidad. Son especialmente útiles para recopilar datos de parámetros durante las inspecciones para identificar defectos. Por ejemplo, los datos sobre la incidencia o el impacto de los defectos recopilados mediante hojas de recopilación de datos a menudo se muestran mediante gráficos de Pareto.
· diagramas de pareto Son gráficos de barras verticales de una forma especial y se utilizan para identificar las pocas fuentes más importantes que causan la mayoría de los efectos de un problema. Las categorías que se muestran en el eje horizontal representan la distribución de probabilidad existente que representa el 100% de las observaciones posibles. El valor de la frecuencia de ocurrencia correspondiente a cada causa identificada, mostrada en el eje horizontal, disminuye hasta llegar a la fuente predeterminada, denominada “otra”, que es responsable de causas no identificadas. Normalmente, un diagrama de Pareto se organiza en categorías que miden la frecuencia de ocurrencia o las consecuencias.
· Histogramas es un tipo especial de gráfico de barras que se utiliza para describir el centro de una distribución, la varianza y la forma de una distribución estadística. A diferencia de un gráfico de control, un histograma no tiene en cuenta el efecto del tiempo sobre la variación que existe dentro de una distribución.
· Tarjetas de control Se utilizan para determinar si un proceso es estable o no y si se desempeña de manera predecible. Los límites inferior y superior especificados en la especificación se basan en los requisitos especificados en el acuerdo. Reflejan los valores máximos y mínimos aceptables. Se pueden aplicar sanciones si los valores exceden los límites de especificación. Los límites de control superior e inferior son diferentes de los límites de especificación. Los límites de control se establecen utilizando principios y cálculos estadísticos estándar para determinar en última instancia la capacidad natural del proceso para estabilizarse. El director del proyecto y las partes interesadas relevantes pueden utilizar límites de control calculados estadísticamente para determinar los puntos en los que se tomarán acciones correctivas para evitar un desempeño antinatural. El propósito de la acción correctiva, por regla general, es mantener la estabilidad natural de un proceso estable y eficaz. Para procesos repetibles, los límites de control suelen ser ± 3 sigma de la media del proceso, que se estableció en 0. Un proceso se considera fuera de control si: (1) un punto de datos está fuera de los límites de control; (2) siete puntos consecutivos están por encima de la línea media; o (3) siete puntos consecutivos están por debajo de la línea media. Los gráficos de control se pueden utilizar para monitorear diferentes tipos de variables de salida. Aunque los gráficos de control se usan con mayor frecuencia para rastrear las actividades repetitivas requeridas para producir productos industriales, también se pueden usar para monitorear las variaciones de costos y cronogramas, el volumen y la frecuencia de los cambios de alcance u otros resultados de la gestión, lo que ayuda a determinar si los procesos de gestión de proyectos. están bajo control.
· Gráfico de dispersión Se representan pares ordenados (X, Y), a veces denominados gráficos de correlación porque se utilizan para explicar el cambio en la variable dependiente, Y, en relación con el cambio observado en la variable independiente, X. La dirección de la correlación puede ser proporcional ( correlación positiva), lo contrario (correlación negativa), o el modelo de correlación puede no existir (correlación cero). Si se puede establecer una correlación, se puede determinar una línea de regresión y usarla para estimar cómo un cambio en la variable independiente cambiará el valor de la variable dependiente.
Herramientas de Gestión y Control de Calidad
El proceso de aseguramiento de la calidad utiliza herramientas y técnicas de los procesos de planificación de la gestión de la calidad y control de calidad. Además de esto, otras herramientas disponibles incluyen:
· Diagramas de afinidad. Un diagrama de afinidad es similar al método de mapas mentales en el sentido de que se utiliza para generar ideas que pueden combinarse para formar una forma organizada de pensar sobre un problema. Durante el proceso de gestión de proyectos, la creación de una EDT se puede mejorar utilizando un diagrama de afinidad para proporcionar estructura al desglose del alcance.
· Diagramas de proceso del programa(gráficos del programa de decisión de procesos, PDPC). Se utiliza para comprender una meta en relación con las acciones tomadas para lograrla. PDPC es un método útil para la planificación basada en pérdidas porque ayuda a los equipos a anticipar pasos intermedios que pueden impedir el logro de objetivos.
· Gráficos de relaciones dirigidas. Adaptación de diagramas de relaciones. Los gráficos de relaciones dirigidas representan el proceso de resolución creativa de problemas en escenarios moderadamente complejos caracterizados por conexiones lógicas entrelazadas de hasta 50 elementos relacionados. Se puede construir un gráfico de relaciones dirigidas a partir de datos obtenidos de otras herramientas, como un diagrama de afinidad, un diagrama de árbol o un diagrama de espina de pescado.
· Diagramas de árbol. También conocidos como diagramas sistemáticos, se pueden utilizar para mostrar un desglose de jerarquías como la WBS, la estructura de desglose de riesgos (RBS) y la estructura de desglose organizacional (OBS). En el proceso de gestión de proyectos, los diagramas de árbol son útiles para visualizar las relaciones padre-hijo en cualquier jerarquía de descomposición que utilice un conjunto sistemático de reglas para definir las relaciones de subordinación. Los diagramas de árbol pueden ser horizontales (por ejemplo, jerarquía de riesgos) o verticales (por ejemplo, jerarquía de equipos u OBS). Debido a que los diagramas de árbol permiten crear ramas anidadas que terminan en un único punto de decisión, son útiles como árboles de decisión para determinar el valor esperado de un número limitado de relaciones, representadas sistemáticamente en un diagrama.
· Matrices de prioridad. Se utiliza para identificar problemas clave y alternativas adecuadas para priorizarlos en un conjunto de soluciones para su implementación. Los criterios se priorizan y ponderan antes de aplicarse a todas las alternativas disponibles para producir una puntuación matemática para clasificar todas las opciones.
· Diagramas de operación de la red. Anteriormente conocidos como gráficos de flechas. Estos incluyen formatos de diagramas de red como actividad en flecha (AOA) y el formato de actividad en nodo (AON) más utilizado. Los diagramas de redes de actividades se utilizan con técnicas de programación de proyectos como la técnica de revisión y estimación de programas (PERT), el método de ruta crítica (CPM) y el método de diagrama de precedencia (PDM).
· Diagramas matriciales. Una herramienta de gestión y control de calidad utilizada para analizar datos dentro de una estructura organizacional creada en una matriz. Utilizando un diagrama matricial, se busca mostrar la fuerza de las dependencias entre factores, causas y objetivos mostrados en la matriz en forma de filas y columnas.
9. GESTIÓN DE RECURSOS HUMANOS DEL PROYECTO
La gestión de recursos humanos de proyectos incluye los procesos de organización, gestión y dirección de un equipo de proyecto. El equipo del proyecto está formado por personas a las que se les asignan roles y responsabilidades para completar el proyecto. Los miembros del equipo del proyecto pueden tener diferentes conjuntos de habilidades, pueden ser de tiempo completo o parcial y pueden ser agregados o eliminados del equipo a medida que avanza el proyecto. Los miembros del equipo del proyecto también pueden denominarse personal del proyecto. Aunque a los miembros del equipo del proyecto se les asignan roles y responsabilidades específicas, la participación de todos los miembros del equipo en la planificación y la toma de decisiones del proyecto es valiosa para el proyecto. Involucrar a los miembros del equipo les permite utilizar su experiencia existente en la planificación de proyectos y fortalece el enfoque del equipo en el logro de los resultados del proyecto.
Organigramas y descripciones de puestos.
Existen varios formatos para documentar la distribución de roles y responsabilidades de los miembros del equipo. La mayoría de los formatos se clasifican en uno de tres tipos: jerárquico, matricial y de texto. Además, algunas asignaciones de proyectos se especifican en planes de respaldo, como planes de riesgo, calidad o comunicaciones. Independientemente del método que se utilice, el objetivo es siempre el mismo: garantizar que cada paquete de trabajo tenga asignado un propietario claro y que cada miembro del equipo comprenda claramente su función y responsabilidades. Por ejemplo, si bien se puede utilizar un formato jerárquico para representar roles de alto nivel, un formato de texto es más adecuado para la documentación detallada de áreas de responsabilidad.
El plan de gestión de recursos humanos incluye, entre otras cosas:
· Funciones y responsabilidades. Al enumerar las funciones y responsabilidades necesarias para completar un proyecto, considere lo siguiente:
o Rol. Una función aceptada o asignada a un empleado del proyecto. Ejemplos de funciones de proyectos incluyen ingeniero civil, analista de negocios y coordinador de pruebas. Se debe documentar una descripción clara del rol en términos de autoridad, responsabilidades y límites.
o Autoridad. El poder de comprometer recursos del proyecto, tomar decisiones, firmar aprobaciones, aceptar entregables e influir en otros miembros del equipo para completar el trabajo del proyecto. Ejemplos de decisiones que requieren una autoridad clara y precisa incluyen elegir cómo realizar una operación, la aceptación de la calidad y cómo responder a las desviaciones del diseño. Los miembros del equipo se desempeñan mejor cuando el nivel de autoridad de cada miembro del equipo coincide con sus áreas de responsabilidad individuales.
o Responsabilidad. Las tareas asignadas y el trabajo que un miembro del equipo del proyecto debe realizar para completar las actividades del proyecto.
o Calificación. Las habilidades y capacidades necesarias para realizar las actividades asignadas dentro de las limitaciones del proyecto. Si los miembros del equipo del proyecto no tienen las calificaciones necesarias, la finalización del proyecto puede estar en riesgo. Si se identifican tales no conformidades, se deben tomar acciones preventivas, como capacitación, contratación de personal calificado o cambios apropiados en el cronograma o alcance del proyecto.
· Organigramas del proyecto. Un organigrama de proyecto es una representación gráfica de la composición de un equipo de proyecto y las relaciones jerárquicas entre sus miembros. Dependiendo de los requerimientos del proyecto, este puede ser formal o informal, detallado o generalizado. Por ejemplo, un organigrama de proyecto para un equipo de respuesta a emergencias de 3000 personas será significativamente más detallado que un organigrama de un proyecto interno con un equipo de 20 personas.
· Plan de personal. El plan de dotación de personal es un componente del plan de gestión de recursos humanos que describe cuándo y cómo se utilizarán los miembros del equipo del proyecto y durante cuánto tiempo serán necesarios. Describe la forma en que se satisfacen los requisitos de recursos humanos. Dependiendo de los requisitos del proyecto, el plan de dotación de personal puede ser formal o informal, detallado o generalizado. Para reflejar las actividades en curso para reponer y desarrollar el equipo del proyecto, este plan se actualiza constantemente durante el proyecto. La información contenida en un plan de dotación de personal variará dependiendo del área de aplicación y del tamaño del proyecto, pero en cualquier caso deberá incluir los siguientes elementos:
o Reclutamiento. Cuando se planifica reclutar miembros para el equipo del proyecto, surgen una serie de preguntas. Por ejemplo, ¿se utilizarán los recursos humanos existentes en la organización o se contratarán externamente mediante contrato? si los miembros del equipo trabajarán en un solo lugar o si pueden trabajar de forma remota; ¿Cuál es el costo asociado con cada nivel de habilidad requerido para el proyecto? y qué nivel de apoyo al equipo del proyecto pueden proporcionar el departamento de recursos humanos y los gerentes funcionales de la organización.
o Calendarios de recursos. Calendarios que determinan la disponibilidad de un determinado recurso en determinados días laborables y turnos. El plan de dotación de personal especifica el momento de la participación de los miembros del equipo del proyecto, tanto individual como colectivamente, así como el momento en que deben comenzar las actividades de dotación de personal, como la contratación. Una herramienta para mostrar gráficamente los recursos humanos es el gráfico de barras de recursos, utilizado por el equipo de gestión del proyecto como medio para representar o asignar recursos visualmente a todas las partes interesadas. Este gráfico muestra la cantidad de horas que un individuo, departamento o equipo completo del proyecto necesita cada semana o mes durante la duración del proyecto. El gráfico puede incluir una línea horizontal que represente el número máximo de horas calculadas para un recurso en particular. Si las barras del gráfico se extienden más allá del número máximo de horas disponibles, entonces se debe aplicar una estrategia de optimización de recursos, como asignar recursos adicionales o reprogramar.
o Plan de liberación del personal. Determinar cómo y cuándo liberar a los miembros del equipo de las responsabilidades del proyecto es beneficioso tanto para el proyecto como para los miembros del equipo. Cuando los miembros del equipo son liberados de un proyecto, eliminan los pagos a los empleados que ya han completado su parte del trabajo en el proyecto, reduciendo así el costo del proyecto. El clima moral general mejora si ya se planifica de antemano una transición fluida hacia nuevos proyectos. Un plan de liberación del personal también puede reducir los riesgos de recursos humanos que puedan surgir durante o después del proyecto.
o Necesidades de formación. Si existe la preocupación de que los miembros del equipo asignados a un proyecto no estén suficientemente calificados, se debe desarrollar un plan de capacitación como parte del plan del proyecto. Este plan también puede incluir programas de capacitación para los miembros del equipo que los llevarán a obtener certificaciones que contribuirán a la finalización exitosa del proyecto.
o Reconocimiento y recompensa. Unos criterios claros y un sistema de recompensas planificado ayudan a estimular y mantener el comportamiento deseado de las personas involucradas en el proyecto. Para ser efectivo, el reconocimiento y la recompensa deben basarse en acciones y medidas de eficiencia y eficacia dentro del control del individuo. Por ejemplo, un miembro del equipo puede ser recompensado por alcanzar un determinado objetivo de costos sólo si tiene un nivel suficiente de autoridad para controlar las decisiones que afectan los costos. Crear un plan con una recompensa cronometrada garantizará que la recompensa no se olvide. El reconocimiento y la recompensa son parte del proceso de desarrollo del equipo del proyecto.
o Cumplimiento de la normativa. El plan de recursos humanos puede incluir estrategias para garantizar que el proyecto cumpla con las regulaciones gubernamentales existentes, las disposiciones de los contratos sindicales y otras políticas de recursos humanos establecidas.
o Seguridad. El plan de dotación de personal y el registro de riesgos pueden incluir políticas y procedimientos para proteger a los miembros del equipo de accidentes.
Un modelo utilizado para describir el desarrollo del equipo es la escalera de Tuckman (Tuckman, 1965; Tuckman y Jensen, 1977), que incluye cinco etapas de desarrollo por las que deben pasar los equipos. Por lo general, estas etapas ocurren en orden, pero a menudo un equipo puede quedarse estancado en una etapa determinada o regresar a una anterior. En proyectos en los que los miembros del equipo han trabajado juntos anteriormente, es posible que se salten ciertas etapas.
· Formación. En esta etapa, el equipo se reúne y aprende sobre el proyecto y sus roles y responsabilidades formales dentro del mismo. Los miembros del equipo en esta fase tienden a ser independientes entre sí y no particularmente abiertos.
· Tormenta. Durante esta etapa, el equipo comienza a estudiar el trabajo del proyecto, técnico Soluciones y enfoque para la gestión de proyectos. Si los miembros del equipo no colaboran y no están abiertos a diferentes ideas y perspectivas, el entorno puede volverse improductivo.
· Asentamiento. Durante la etapa de liquidación, los miembros del equipo comienzan a trabajar juntos y ajustan sus hábitos y comportamientos laborales para promover el trabajo en equipo. Los miembros del equipo aprenden a confiar unos en otros.
· Eficiencia. Los equipos que alcanzan la etapa de desempeño funcionan como una unidad bien organizada. Son independientes y resuelven problemas con calma y eficacia.
· Terminación. En esta etapa, el equipo completa el trabajo y pasa al siguiente proyecto. Esto suele ocurrir cuando el personal es liberado del proyecto después de que se ha completado la entrega o como parte del proceso de cierre de fase o proyecto.
La duración de cada etapa específica depende de la dinámica, tamaño y liderazgo del equipo. Los gerentes de proyecto deben tener una buena comprensión de la dinámica del equipo para ayudar a garantizar que los miembros del equipo avancen en todas las etapas de manera efectiva.
Hay cinco métodos principales utilizados para resolver conflictos.
Dado que cada uno de ellos tiene su propio propósito y aplicación, los métodos se dan sin ningún orden en particular:
· Evasión/evitación. Desviarse de una situación de conflicto real o potencial, posponer la resolución de un problema para una fecha posterior con el fin de prepararse mejor para su resolución o transferir su resolución a otros.
· Suavizado/acomodación. Enfatizar puntos de acuerdo en lugar de áreas de contradicción, renunciar a la propia posición en favor de las necesidades de los demás para mantener la armonía y las relaciones.
· Compromiso/acuerdo. Encontrar soluciones que sean algo satisfactorias para todas las partes con el fin de resolver temporal o parcialmente el conflicto.
· Coerción/direcciones. Cabildear por el propio punto de vista a expensas de los demás, ofreciendo sólo soluciones en las que uno gana y todos pierden, generalmente desde una posición de poder, para resolver una situación crítica.
· Colaboración/Resolución de Problemas. Al reunir múltiples puntos de vista y perspectivas desde diferentes perspectivas, es necesaria la voluntad de cooperar y un diálogo abierto, que generalmente conduce al consenso y al apoyo de todas las partes para una solución.
Ejemplos de habilidades de comunicación interpersonal Los más utilizados por un director de proyecto incluyen:
· Liderazgo. Se requieren habilidades de liderazgo desarrolladas para el éxito del proyecto. El liderazgo es importante en todas las fases del ciclo de vida del proyecto. Existen muchas teorías de liderazgo que definen los estilos de liderazgo que cada equipo debe utilizar cuando sea apropiado en la situación adecuada. Es especialmente importante transmitir una visión compartida del proyecto a los miembros del equipo e inspirarlos para lograr una alta eficiencia y eficacia en su trabajo.
· Influencia. Debido a que los gerentes de proyectos a menudo tienen poca o ninguna autoridad directa sobre los miembros de su equipo en entornos matriciales, su capacidad para influir en las partes interesadas del proyecto de manera oportuna es fundamental para el éxito del proyecto. Las habilidades clave para influir incluyen:
o la capacidad de expresar de manera convincente y clara un punto de vista y una posición;
o alto nivel de capacidad de escucha activa y eficaz;
o comprender y considerar diferentes perspectivas en cualquier situación;
o Recopilar información esencial y crítica para resolver problemas importantes y llegar a acuerdos manteniendo la confianza mutua.
· Toma de decisiones efectiva. Esto implica la capacidad de negociar e influir en la organización y el equipo de gestión del proyecto. A continuación se presentan algunas de las pautas para la toma de decisiones:
o es necesario centrarse en los objetivos a alcanzar;
o es necesario cumplir con el procedimiento de toma de decisiones;
o es necesario estudiar los factores ambientales;
o es necesario analizar la información disponible;
o es necesario desarrollar las cualidades personales de los miembros del equipo;
o es necesario estimular el enfoque creativo del trabajo del equipo;
o Es necesario gestionar los riesgos.
10. GESTIÓN DE COMUNICACIÓN DEL PROYECTO
La gestión de comunicaciones del proyecto incluye los procesos necesarios para garantizar la planificación, recopilación, creación, distribución, almacenamiento, recepción, gestión, control, seguimiento y, en última instancia, archivo/eliminación de la información del proyecto de forma oportuna y adecuada. Los gerentes de proyecto pasan la mayor parte de su tiempo comunicándose con los miembros del equipo y otras partes interesadas del proyecto, ya sean internos (en todos los niveles de la organización) o externos a la organización. Las comunicaciones efectivas crean un puente entre diferentes partes interesadas, que pueden tener diferentes antecedentes culturales y organizacionales, diferentes niveles de conocimiento y diferentes puntos de vista e intereses, que afectan o pueden tener un impacto en el desempeño o los resultados del proyecto.
Los factores que pueden influir en la elección de las tecnologías de comunicación incluyen:
· Urgencia de obtención de información. Se debe tener en cuenta la urgencia, frecuencia y formato de la información proporcionada, ya que pueden variar entre proyectos, así como en diferentes etapas de un mismo proyecto.
· Disponibilidad de tecnología. Es necesario garantizar que la tecnología necesaria para permitir la comunicación sea compatible y esté disponible para todas las partes interesadas durante todo el ciclo de vida del proyecto.
· Facilidad de uso. Es necesario garantizar que las tecnologías de comunicación seleccionadas sean adecuadas para los participantes del proyecto y que, en caso necesario, se planifiquen actividades de formación adecuadas.
· Entorno del proyecto. Es necesario determinar si el equipo se reunirá y actuará de manera presencial o virtual; si los miembros del equipo estarán ubicados en una o más zonas horarias; ¿Utilizarán varios idiomas para comunicarse? y, en última instancia, si existen otros factores ambientales del proyecto, como la cultura, que puedan influir en las comunicaciones.
· Secreto y confidencialidad de la información. Es necesario determinar si la información que se transmite es clasificada o confidencial y si es necesario tomar medidas adicionales para protegerla. También debe considerarse el método más apropiado para transmitir dicha información.
El modelo de comunicación básico tiene la siguiente secuencia de pasos:
· Codificación. Conversión (codificación) de pensamientos o ideas a lenguaje codificado por parte del remitente.
· Enviando un mensaje. Envío de información por parte del remitente mediante un canal de información (medio de transmisión de información). Varios factores pueden interferir con la transmisión de este mensaje (por ejemplo, distancia, tecnología desconocida, infraestructura insuficiente, diferencias culturales y falta de información adicional). Estos factores se denominan colectivamente ruido.
· Descodificación. El destinatario traduce el mensaje en pensamientos e ideas significativos.
· Confirmación. Después de recibir un mensaje, el destinatario puede enviar una señal (acuse de recibo) de que el mensaje ha sido recibido, pero esto no indica necesariamente que esté de acuerdo con el mensaje o que lo haya entendido.
· Comentarios/Respuesta. Cuando el mensaje recibido se decodifica y comprende, el destinatario convierte (codifica) pensamientos e ideas en un mensaje y lo transmite al remitente original.
Se utilizan varios métodos de comunicación para difundir información entre las partes interesadas del proyecto.
Estos métodos se pueden dividir en los siguientes grandes grupos:
· Comunicaciones interactivas. Entre dos o más partes involucradas en un intercambio multilateral de información. Este método es más eficaz para garantizar una comprensión común de determinadas cuestiones por parte de todos los participantes; incluye reuniones, conversaciones telefónicas, mensajes instantáneos, videoconferencias, etc.
· Comunicación informando sin petición. La información se envía a destinatarios específicos que necesitan recibirla. Este método asegura la difusión de información, pero no garantiza que realmente será recibida o comprendida por el público objetivo. Las comunicaciones no solicitadas incluyen cartas, notas, informes, correos electrónicos, faxes, mensajes de voz, blogs, comunicados de prensa, etc.
· Comunicaciones mediante información previa solicitud. Se utilizan para volúmenes muy grandes de información o para audiencias muy grandes y requieren que los destinatarios accedan al contenido transmitido a su propia discreción. Dichos métodos incluyen sitios de intranet, aprendizaje electrónico, bases de datos de lecciones aprendidas, depósitos de conocimientos, etc.
Las técnicas y aspectos de la gestión eficaz de las comunicaciones incluyen, entre otras:
· Modelos emisor-receptor. Implemente circuitos de retroalimentación para garantizar oportunidades positivas de interacción/participación y eliminar las barreras de comunicación.
· Selección de medios de comunicación. Las opciones que dependen de la situación incluyen cuándo comunicarse verbalmente versus por escrito, cuándo preparar notas informales versus un informe formal, y cuándo hablar en persona versus por correo electrónico.
· Estilo de escritura. Uso de voz activa o pasiva, estructura de la oración, elección de palabras.
·Técnicas de gestión de reuniones. Elaborar la agenda y afrontar los conflictos.
· Métodos de presentación. Conciencia de los efectos del lenguaje corporal y desarrollo de ayudas visuales.
· Métodos de organización del trabajo en grupo. Llegar a consensos y superar obstáculos.
· Técnicas de escucha. Escucha activa (confirmando, aclarando y comprobando la comprensión) y eliminando barreras que puedan distorsionar la comprensión.
11. GESTIÓN DE RIESGOS DEL PROYECTO
La gestión de riesgos del proyecto incluye los procesos asociados con la implementación de la planificación de la gestión de riesgos, la identificación, el análisis, la planificación de respuestas y el control de los riesgos en el proyecto. Los objetivos de la gestión de riesgos del proyecto son aumentar la probabilidad de que ocurran y mejorar el impacto de eventos favorables y reducir la probabilidad de que ocurran y debilitar el impacto de eventos desfavorables durante la implementación del proyecto.
Riesgo del proyecto Es un evento o condición incierta cuya ocurrencia tiene un efecto negativo o positivo en los objetivos del proyecto, como el alcance, el cronograma, el costo y la calidad. Un riesgo puede tener una o más causas y, si ocurre, puede tener un impacto en uno o más aspectos.
Plan de gestión de Riesgos Es un componente del plan para la dirección del proyecto que describe cómo se estructurarán y ejecutarán las actividades de gestión de riesgos. El plan de gestión de riesgos incluye los siguientes elementos:
· Metodología. Determinar los enfoques, herramientas y fuentes de datos que se utilizarán para gestionar los riesgos en un proyecto determinado.
· Funciones y responsabilidades. Identifique a los miembros del equipo de liderazgo, a los miembros del equipo de apoyo y a los miembros del equipo de gestión de riesgos para cada actividad incluida en el plan de gestión de riesgos y aclare sus responsabilidades.
· Desarrollo presupuestario. Evaluar los fondos requeridos, teniendo en cuenta los recursos asignados, para su inclusión en la línea base de costos y desarrollar procedimientos para el uso de la reserva para posibles pérdidas y la reserva de gestión.
· Determinación de plazos. Determinar el momento y la frecuencia de los procesos de gestión de riesgos a lo largo del ciclo de vida del proyecto, desarrollar procedimientos para el uso de reservas del cronograma para posibles pérdidas e identificar las actividades de gestión de riesgos que se incluirán en el cronograma del proyecto.
· Categorías de riesgo. Proporcionar un medio para categorizar las fuentes potenciales de riesgo en grupos. Se pueden utilizar varios enfoques, como una estructura basada en los objetivos del proyecto por categoría. El Marco de Jerarquía de Riesgos (RBS) ayuda al equipo del proyecto a considerar las múltiples fuentes de las que pueden surgir los riesgos del proyecto durante el proceso de identificación de riesgos. Los diferentes tipos de proyectos corresponden a diferentes estructuras de RBS. Una organización puede utilizar un esquema de categorización de riesgos desarrollado previamente, que puede tomar la forma de una lista simple de categorías o tener el formato de una EBR. RBS es una representación jerárquica de riesgos según categorías de riesgo.
· Determinar la probabilidad y el impacto de los riesgos. Un análisis de riesgos bueno y confiable implica identificar diferentes niveles de probabilidad e impacto de los riesgos en el contexto de un proyecto. Las definiciones generales de niveles de probabilidad y niveles de impacto se adaptan a un proyecto específico durante el proceso de planificación de la gestión de riesgos y luego se utilizan durante procesos posteriores. La siguiente tabla proporciona un ejemplo de definiciones de impacto negativo que se pueden utilizar para evaluar el impacto de los riesgos asociados con los cuatro objetivos del proyecto (se pueden crear tablas similares para los impactos positivos). La siguiente tabla muestra enfoques tanto relativos como numéricos (en este caso, no lineales).
· Matriz de probabilidad e impacto. Una matriz de probabilidad e impacto es una tabla que muestra la probabilidad de que ocurra cada riesgo y su impacto en los objetivos del proyecto si ocurre. Los riesgos se priorizan de acuerdo con sus probables consecuencias que pueden afectar los objetivos del proyecto. Una forma típica de priorización es utilizar una tabla de correspondencia o una matriz de probabilidad e impacto. Normalmente, la propia organización establece las combinaciones de probabilidad e impacto a partir de las cuales se determina el nivel de riesgo como “alto”, “medio” o “bajo”.
· Tolerancia clarificada de las partes interesadas. Durante el proceso de planificación de la gestión de riesgos, las tolerancias de las partes interesadas se pueden ajustar para adaptarse al proyecto específico.
· Formatos de informes. Los formatos de informes definen cómo se documentarán, analizarán y comunicarán los resultados del proceso de gestión de riesgos. Los formatos de informes describen el contenido y el formato del registro de riesgos, así como cualquier otro informe de riesgos requerido.
· Seguimiento. El seguimiento documenta cómo se registran todas las actividades relacionadas con riesgos para los fines de un proyecto determinado, y cuándo y cómo se auditarán los procesos de gestión de riesgos.
Métodos de gráficos
Los métodos de gráficos de riesgo incluyen:
· Diagramas de causa y efecto. Estos diagramas, también conocidos como diagramas de Ishikawa o diagramas de espina de pescado, se utilizan para determinar por qué ocurren los riesgos.
· Diagramas de flujo de un proceso o sistema. Este tipo de visualización gráfica demuestra el orden de interacción de varios elementos del sistema entre sí y sus relaciones de causa y efecto.
· Diagramas de influencia. Una representación gráfica de situaciones que muestra relaciones de causa y efecto, secuencias de eventos a lo largo del tiempo y otras relaciones entre variables y resultados.
Análisis FODA
Este método permite analizar el proyecto desde el punto de vista de cada uno de los aspectos: fortalezas, debilidades, oportunidades y amenazas (fortalezas, debilidades, oportunidades y amenazas, FODA), lo que hace más completa la identificación de los riesgos, teniendo en cuenta en cuenta los riesgos dentro del proyecto. Al utilizar este método, se comienza identificando las fortalezas y debilidades de la organización, centrándose ya sea en el proyecto, la organización o el área de negocio en su conjunto. Luego, el análisis FODA identifica las oportunidades de proyecto que surgen de las fortalezas de la organización, así como las amenazas que surgen de sus debilidades. Este análisis también examina cómo las fortalezas de la organización compensan las amenazas e identifica oportunidades que pueden explotarse para superar las debilidades.
Registro de riesgo
El principal resultado del proceso de identificación de riesgos es la entrada inicial en el registro de riesgos. Un registro de riesgos es un documento que contiene los resultados del análisis de riesgos y la planificación de la respuesta a los riesgos. El registro de riesgos captura los resultados de otros procesos de gestión de riesgos a medida que ocurren, lo que resulta en un aumento en el nivel y la variedad de información contenida en el registro de riesgos con el tiempo. La preparación del registro de riesgos comienza con el proceso de identificación de riesgos, durante el cual el registro se completa con la siguiente información. Esta información luego se pone a disposición de otros procesos relacionados con la gestión de proyectos y la gestión de riesgos.
· Listado de riesgos identificados. Los riesgos identificados se describen con suficiente detalle. Esta lista puede utilizar una estructura específica para describir riesgos, por ejemplo: puede ocurrir un EVENTO que tendrá un IMPACTO, o si hay una CAUSA, puede ocurrir un EVENTO que tendrá un EFECTO. Además, al crear una lista de riesgos identificados, las causas fundamentales de esos riesgos pueden volverse más evidentes. Estas son condiciones o eventos fundamentales que pueden causar que ocurran uno o más riesgos identificados. Deben registrarse y utilizarse para respaldar la identificación de riesgos futuros en este y otros proyectos.
· Lista de posibles respuestas. A veces, el proceso de identificación de riesgos puede determinar posibles respuestas a ellos. Dichas respuestas, si se identifican durante este proceso, deberían servir como insumos para el proceso de planificación de la respuesta al riesgo.
Análisis cualitativo de riesgos.- el proceso de priorizar los riesgos para su posterior análisis o acción, llevado a cabo evaluando y comparando su impacto y probabilidad de ocurrencia. El beneficio clave de este proceso es que permite a los gerentes de proyectos reducir la incertidumbre y centrarse en los riesgos de alta prioridad.
Análisis cuantitativo de riesgos.- el proceso de análisis numérico del impacto de los riesgos identificados en los objetivos del proyecto en su conjunto. El beneficio clave de este proceso es que proporciona información cuantitativa sobre el riesgo para respaldar el proceso de toma de decisiones para reducir la incertidumbre del proyecto.
Métodos de recopilación y presentación de información.
· Realización de entrevistas. Las técnicas de entrevista proporcionan experiencia y datos históricos para cuantificar la probabilidad y el impacto de los riesgos en los objetivos del proyecto. La información requerida depende del tipo de distribución de probabilidad utilizada. Por ejemplo, para algunos de los modelos de distribución más utilizados, es necesario recopilar información sobre el escenario optimista (baja probabilidad), pesimista (alta probabilidad) y más probable. Documentar la justificación de los rangos de riesgo y los supuestos asociados es un elemento importante de las entrevistas de riesgo porque estos documentos permiten inferencias sobre la confiabilidad y validez del análisis.
· Distribución de probabilidad. Las distribuciones de probabilidad continua, ampliamente utilizadas en modelado y simulación, representan valores inciertos como la duración de las actividades del cronograma y los costos de los componentes del proyecto. Se pueden utilizar distribuciones discretas para representar eventos inciertos, como resultados de pruebas o posibles escenarios de árboles de decisión. En la Fig. A continuación se muestran dos ejemplos de distribuciones continuas ampliamente utilizadas. Estas distribuciones describen patrones que se combinan con datos que normalmente se obtienen a partir de análisis de riesgos cuantitativos. Se pueden utilizar distribuciones uniformes en los casos en los que no existe un valor obvio que tenga más probabilidades que otros de caer entre los límites superior e inferior especificados, como al principio de la fase de diseño.
Métodos de análisis cuantitativo y modelado de riesgos.
Los métodos ampliamente utilizados utilizan enfoques de análisis tanto orientados a eventos como orientados a proyectos, que incluyen:
· Análisis de sensibilidad. El análisis de sensibilidad ayuda a identificar los riesgos con mayor impacto posible en el proyecto. Ayuda a comprender cómo las variaciones en los objetivos del proyecto se correlacionan con variaciones en diversas incertidumbres. Por otro lado, establece en qué medida la incertidumbre de cada elemento de diseño afecta al objetivo en estudio, mientras que todos los demás elementos inciertos se encuentran en sus valores base. Una forma típica de mostrar el análisis de sensibilidad es un diagrama de tornado (figura siguiente), que resulta útil para comparar la importancia relativa y el impacto de variables que tienen un alto grado de incertidumbre con otras variables más estables. El diagrama de tornado también es útil para analizar escenarios de toma de riesgos aplicados a riesgos específicos cuyo análisis cuantitativo indica que los beneficios potenciales son mayores que los correspondientes impactos negativos identificados. Un gráfico de tornado es un tipo especial de gráfico de barras que se utiliza en el análisis de sensibilidad para comparar la importancia relativa de las variables. En un diagrama de tornado, el eje y es cada tipo de incertidumbre en los valores subyacentes, y el eje x es la dispersión o correlación de la incertidumbre sobre el resultado que se estudia. En esta figura, cada incertidumbre contiene una barra horizontal (línea) y la vertical muestra incertidumbres con una dispersión decreciente respecto de los valores base.
· Análisis del valor monetario esperado. El análisis del valor monetario esperado (EMV) es una técnica estadística que calcula un resultado promedio cuando hay escenarios futuros que pueden suceder o no (es decir, análisis bajo incertidumbre). El VME de las oportunidades normalmente se expresa en términos positivos, mientras que el VME de las amenazas generalmente se expresa en términos negativos. EMV requiere un supuesto neutral al riesgo, ni uno que acepte el riesgo excesivo ni uno que lo rechace por completo. Para calcular el EMV de un proyecto, se multiplica el valor de cada resultado posible por la probabilidad de que ocurra y luego se suman los valores resultantes. Normalmente, este tipo de análisis se utiliza en forma de análisis de árbol de decisión.
· Modelado y simulación. La simulación de proyectos utiliza un modelo para determinar los impactos probables de incertidumbres detalladas sobre los objetivos del proyecto. Las simulaciones se suelen realizar mediante el método de Montecarlo. En la simulación, un modelo de proyecto se calcula muchas veces (iterativamente), y cada iteración tiene valores de entrada (por ejemplo, estimaciones de costos o duraciones de actividades) elegidos aleatoriamente de las distribuciones de probabilidad de estas variables. Durante las iteraciones, se calcula un histograma (por ejemplo, costo total o fecha de finalización). El análisis de riesgos de costos mediante el método de simulación utiliza estimaciones de costos. El análisis de riesgo de programación utiliza un diagrama de red de programación y estimaciones de duración. El resultado de la simulación de riesgos de valor utilizando un modelo de tres elementos y rangos de riesgo se muestra en la Fig. abajo. La figura muestra la probabilidad correspondiente de alcanzar ciertos objetivos de costos. Se pueden desarrollar curvas similares para otros propósitos de diseño.
Estrategias para responder a riesgos negativos (amenazas)
· Evasión. La aversión al riesgo es una estrategia de respuesta al riesgo en la que el equipo del proyecto actúa para eliminar la amenaza o proteger el proyecto de su impacto. Como regla general, implica cambiar el plan de gestión del proyecto de tal manera que se elimine por completo la amenaza. El director del proyecto también puede proteger los objetivos del proyecto para que no estén en riesgo o cambiar un objetivo que esté en riesgo (por ejemplo, ampliar el cronograma, cambiar la estrategia o reducir el alcance). La estrategia más drástica para evitarlo es terminar el proyecto por completo. Algunos riesgos que surgen al principio de un proyecto se pueden evitar aclarando los requisitos, obteniendo información, mejorando las comunicaciones o adquiriendo experiencia.
· Transmisión. La transferencia de riesgos es una estrategia de respuesta al riesgo mediante la cual el equipo del proyecto transfiere las consecuencias de una amenaza, junto con la responsabilidad de la respuesta, a un tercero. Cuando se transfiere el riesgo, la responsabilidad de gestionarlo pasa a otra parte; esto no elimina el riesgo. La transferencia del riesgo no significa una renuncia a la responsabilidad del mismo transfiriéndolo a un proyecto futuro o a otra persona sin informar a esta última ni celebrar un acuerdo con ella. La transferencia de riesgo casi siempre implica pagar una prima de riesgo a la parte que acepta el riesgo. Transferir la responsabilidad del riesgo es más eficaz para los riesgos financieros. Los instrumentos de transferencia pueden ser bastante variados e incluyen, entre otros: el uso de seguros, fianzas de cumplimiento, fianzas de cumplimiento, etc. Se pueden utilizar contratos o acuerdos para transferir la responsabilidad de ciertos riesgos a otra parte. Por ejemplo, cuando el comprador tiene capacidades que el vendedor no tiene, puede ser razonable contratar parte del trabajo y sus riesgos asociados con el comprador. En muchos casos, un contrato de costo reembolsable puede transferir el riesgo del costo al comprador, mientras que un contrato de precio fijo puede transferir el riesgo al vendedor.
· Rechazar. La mitigación de riesgos es una estrategia de respuesta al riesgo en la que el equipo del proyecto actúa para reducir la probabilidad de que ocurra o el impacto del riesgo. Implica reducir la probabilidad y/o el impacto de un riesgo adverso a niveles umbral aceptables. Tomar medidas tempranas para reducir la probabilidad de que ocurra un riesgo y/o su impacto durante el curso de un proyecto suele ser más efectivo que los esfuerzos de remediación emprendidos después de que el riesgo haya ocurrido. Ejemplos de acciones de mitigación de riesgos incluyen implementar procesos menos complejos, realizar más pruebas o elegir un proveedor más confiable. La reducción también puede requerir el desarrollo de prototipos para reducir el riesgo de sobreescalamiento del proceso o del producto en comparación con un modelo de banco. Si no es posible reducir la probabilidad, las acciones de reducción del riesgo deben dirigirse al impacto del riesgo, es decir, a aquellas relaciones que determinan la gravedad del impacto. Por ejemplo, diseñar un sistema redundante puede reducir la gravedad de las consecuencias del fallo del elemento original.
· Adopción. La aceptación del riesgo es una estrategia de respuesta al riesgo en la que el equipo del proyecto decide aceptar el riesgo y no tomar ninguna medida hasta que se produzca el riesgo. Esta estrategia se utiliza si cualquier otra forma de responder a un riesgo particular es imposible o rentable. Indica que el equipo del proyecto ha decidido no cambiar el plan de gestión del proyecto para abordar el riesgo o no puede identificar ninguna otra estrategia de respuesta adecuada. Esta estrategia puede ser pasiva o activa. La aceptación pasiva no requiere más acción que documentar la estrategia: el equipo del proyecto tendrá que lidiar con los riesgos a medida que ocurren y revisar periódicamente la amenaza para asegurarse de que no haya cambiado significativamente. La estrategia de aceptación activa más común es establecer una reserva para pérdidas, que incluye cantidades específicas de tiempo, dinero o recursos necesarios para gestionar los riesgos.
Estrategias para responder a riesgos positivos (oportunidades)
· Uso. Se puede elegir una estrategia de explotación para responder a los riesgos con un impacto positivo si la organización necesita garantizar que se aproveche la oportunidad. Esta estrategia está diseñada para abordar la incertidumbre asociada con un riesgo positivo particular a través de medidas que aseguren que la oportunidad se haga realidad. Las respuestas de uso directo incluyen traer el mejor talento de la organización al proyecto para reducir el tiempo requerido para completar el proyecto, o usar tecnología nueva o actualizada para reducir el costo y el tiempo necesarios para lograr los objetivos del proyecto.
· Aumentar. Una estrategia de mejora se utiliza para aumentar la probabilidad y/o el impacto positivo de una oportunidad. Identificar y maximizar los factores clave que contribuyen a la aparición de estos riesgos de impacto positivo puede aumentar la probabilidad de que ocurran. Ejemplos de mejora de oportunidades incluyen la asignación de recursos adicionales a una operación con el objetivo de completarla temprano.
· Separación. La distribución positiva del riesgo implica transferir parte o toda la responsabilidad de una oportunidad a un tercero que está mejor posicionado para aprovechar la oportunidad en beneficio del proyecto. Las actividades de intercambio incluyen la formación de asociaciones, equipos, vehículos de propósito especial o empresas conjuntas de riesgo compartido que pueden formarse con el propósito expreso de que todas las partes se beneficien de una oportunidad.
· Adopción. La aceptación de oportunidades es el deseo de aprovechar una oportunidad cuando se presenta sin perseguirla activamente.
12. GESTIÓN DE ADQUISICIONES DEL PROYECTO
La gestión de adquisiciones de proyectos implica los procesos de compra o adquisición de productos, servicios o entregables necesarios para llevar a cabo un proyecto desde fuera del equipo del proyecto. Una organización puede actuar como comprador y vendedor de productos, servicios o resultados de proyectos.
La gestión de adquisiciones del proyecto incluye los procesos de gestión de contratos y los procesos de control de cambios necesarios para crear y administrar contratos u órdenes de compra preparadas por miembros autorizados del equipo del proyecto.
Tipos de contratos
· Contratos de precio fijo. Este tipo de contrato prevé un costo fijo total del producto, servicio o resultado entregado. Los contratos de precio fijo también pueden proporcionar incentivos financieros para lograr o mejorar ciertos objetivos específicos del proyecto, como fechas de entrega planificadas, desempeño técnico y de costos u otras métricas cuantificables y posteriormente mensurables. Según los contratos de precio fijo, los vendedores están legalmente obligados a cumplir dichos contratos o sufrir posibles pérdidas financieras si no los cumplen. Los compradores, de conformidad con las disposiciones de dichos acuerdos, deben identificar con precisión el producto o servicio que están comprando. Pueden producirse cambios en el contenido, pero normalmente darán lugar a un aumento en el precio del contrato.
o Contratos de Precio Fijo en Firma (FFP). El tipo de contrato más utilizado es el FFP. La mayoría de las organizaciones de compras prefieren este tipo de contrato, ya que el precio de los bienes se fija desde el principio y no está sujeto a cambios a menos que cambie el contenido del trabajo. Cualquier aumento en el costo causado por un desempeño negativo es responsabilidad del vendedor para completar el trabajo. Según FFP, el comprador debe especificar con precisión el producto o los servicios que está comprando, y cualquier cambio en la especificación de compra puede aumentar los costos del comprador.
o Contratos de Tarifa de Incentivo de Precio Fijo (FPIF). Este acuerdo de precio fijo brinda al comprador y al vendedor cierta flexibilidad al permitir variaciones en el desempeño y brindar incentivos financieros para lograr las métricas acordadas. Normalmente, dichos incentivos financieros están vinculados al costo, el cronograma o el desempeño técnico por parte del vendedor. Los indicadores de rendimiento objetivo se establecen al principio y el precio final del contrato se determina una vez finalizados todos los trabajos, en función de su desempeño por parte del vendedor. Según el FPIF, se establece un precio máximo y la responsabilidad de todos los costos que superen el precio máximo recae en el vendedor, quien está obligado a completar el trabajo.
o Contratos con precio fijo y cláusula de posible ajuste de precio (Precio Fijo con Contratos de Ajuste de Precio Económico, FP-EPA). Este tipo de contrato se utiliza si el cumplimiento del contrato por parte del vendedor se prolonga durante un período de tiempo significativo, lo que suele ser lo que se busca en las relaciones a largo plazo. Un contrato con un precio fijo, pero con una disposición especial que permite ajustes finales predeterminados al precio del contrato debido a cambios en las condiciones, como inflación o aumentos o disminuciones en los precios de ciertos bienes. La cláusula de ajuste de precios debe estar vinculada a un índice financiero fiable que se utilice para ajustar con precisión el precio final. La FP-EPA está diseñada para proteger tanto al comprador como al vendedor de condiciones externas sobre las que no tienen control.
· Contratos de costes reembolsables. Este tipo de contrato implica el pago (reembolso) al vendedor de todos los costos reales legítimos incurridos como resultado de la ejecución del trabajo, más una tarifa que constituye su beneficio. Los contratos de costos reembolsables a menudo incluyen cláusulas que brindan incentivos para exceder o mejorar los objetivos de desempeño del proyecto (por ejemplo, costo, cronograma o desempeño técnico). Los tres tipos más comunes de contratos de reembolso de costos son: Contrato de costo más tarifa fija (CPFF), Contrato de costo más tarifa de incentivo (CPIF), Contrato de costo más tarifa fija (CPIF), Contrato de costo más tarifa fija (CPIF) y Contrato de costo más Contrato de Tarifa Fija (CPIF) de remuneración (Contrato de Tarifa de Adjudicación Cost Plus, CPAF). Un contrato de costos reembolsables brinda flexibilidad al proyecto al permitir que las instrucciones del vendedor cambien si el alcance del trabajo no se puede describir con precisión desde el principio y es necesario ajustarlo o si existen altos riesgos durante el trabajo.
o Contratos de coste más tarifa fija (CPFF). Al vendedor se le reembolsan todos los costos acordados para realizar el trabajo según el contrato y también se le paga una tarifa fija equivalente a un cierto porcentaje del costo estimado original del proyecto. La remuneración se paga únicamente por el trabajo completado y no cambia según el desempeño del vendedor. Los importes de la remuneración no cambian a menos que cambie el contenido del proyecto.
o Contratos de Costo Más Tarifa de Incentivo (CPIF). El vendedor recibe el reembolso de todos los costos acordados por la realización del trabajo en virtud del contrato, así como una tarifa de incentivo predeterminada por lograr indicadores de desempeño específicos especificados en el contrato. Los contratos CPIF estipulan que si los costos finales son mayores o menores que el costo estimado original, entonces los ahorros/gastos excesivos se distribuyen entre el vendedor y el comprador en una proporción previamente acordada, por ejemplo, en una proporción de 80/20 del diferencia entre los costos planificados y el desempeño real del vendedor.
o Contratos Cost Plus Premium Fee (CPAF). Al vendedor se le reembolsan todos los costos razonables, pero la mayor parte de la compensación se paga únicamente en función del cumplimiento de una serie de criterios subjetivos de desempeño ampliamente interpretados y definidos en el contrato. La determinación de la remuneración se basa únicamente en la evaluación subjetiva que hace el comprador de la ejecución del contrato por parte del vendedor y, por regla general, no está sujeta a recurso.
· Contratos de tiempo y materiales.(Contratos de Tiempo y Materiales, T&M). Los contratos de tiempo y materiales son un tipo mixto de acuerdo contractual que contiene disposiciones tanto para contratos de costos reembolsables como para contratos de precio fijo. A menudo se utilizan para aumentar el personal, contratar expertos y para cualquier soporte de terceros en los casos en los que es imposible crear rápidamente una descripción precisa del trabajo. Estos tipos de contratos son similares a los contratos de costos reembolsables en que permiten modificaciones y aumentos de costos para el comprador. En el momento de celebrar el contrato, el comprador no podrá indicar el precio total del contrato ni el número exacto de artículos a suministrar. Por lo tanto, el costo de los contratos de T&M puede aumentar, al igual que en los contratos de costos reembolsables. Para evitar aumentos ilimitados de costos, muchas organizaciones exigen que se incluyan límites de precio y plazo en todos los contratos de T&M. Por otro lado, los acuerdos de T&M también pueden parecerse a acuerdos de precio fijo, donde ciertos parámetros se especifican en el contrato. El comprador y el vendedor pueden acordar de antemano las tarifas por hora de mano de obra o los costos de materiales, incluidas las ganancias del vendedor, si ambas partes han llegado a un acuerdo sobre el costo de ciertas categorías de insumos, como una determinada tarifa por hora para los ingenieros jefes o un precio determinado por unidad de material.
13. GESTIÓN DE LAS PARTES INTERESADAS DEL PROYECTO
La gestión de las partes interesadas del proyecto incluye los procesos necesarios para identificar las personas, grupos y organizaciones que pueden afectar o verse afectados por el proyecto, analizar las expectativas de las partes interesadas y su impacto en el proyecto, y desarrollar estrategias de gestión apropiadas para involucrar eficazmente a las partes interesadas en la toma de decisiones y ejecución del proyecto. La gestión de partes interesadas también se centra en la comunicación continua con las partes interesadas para comprender sus necesidades y expectativas, responder a los problemas a medida que surgen, gestionar intereses en conflicto y promover la participación adecuada de las partes interesadas en la toma de decisiones y las operaciones del proyecto. La satisfacción de las partes interesadas debe gestionarse como uno de los objetivos clave del proyecto.
Al realizar el análisis de las partes interesadas, se utilizan varios modelos de clasificación, tales como:
· matriz de poder/intereses, agrupar a las partes interesadas en función de su nivel de autoridad (“poder”) y nivel de interés (“interés”) en los resultados del proyecto;
· matriz de poder/influencia, agrupando a las partes interesadas según su nivel de autoridad (“poder”) y participación activa (“influencia”) en el proyecto;
· matriz de influencia/impacto, agrupar a las partes interesadas en función de su participación activa (“influencia”) en el proyecto y su capacidad para generar cambios en la planificación o ejecución del proyecto (“impacto”);
· modelo de característica, que describe clases de partes interesadas según su nivel de poder (su capacidad para imponer su voluntad), urgencia (la necesidad de acción inmediata) y legitimidad (su participación es apropiada).
Los niveles de participación de las partes interesadas se pueden clasificar de la siguiente manera:
· No informado. La parte interesada desconoce el proyecto y sus posibles impactos.
· Resistir. La parte interesada es consciente del proyecto y de sus posibles impactos y se resiste al cambio.
· Neutral. La parte interesada es consciente del proyecto pero no apoya ni se resiste al cambio.
· Apoyo. La parte interesada es consciente del proyecto, de sus posibles impactos y apoya los cambios.
· Principal. La parte interesada es consciente del proyecto, de los impactos potenciales y participa activamente para garantizar el éxito del proyecto.
El principal resultado del proceso de identificación de partes interesadas es el registro de partes interesadas. Contiene todos los detalles relacionados con las partes interesadas que se han identificado, incluidos, entre otros:
· Información de identificación: Nombre completo, cargo en la organización, ubicación, rol en el proyecto, información de contacto.
· Información de evaluación: requisitos y expectativas básicos, impacto potencial en el proyecto, fase más interesante del ciclo de vida del proyecto.
· Clasificación de las partes interesadas: internas/externas, solidarias/neutrales/resistentes, etc.
Además de los datos del registro de partes interesadas, el plan de gestión de partes interesadas a menudo también contendrá:
· nivel deseado y actual de participación de las partes interesadas clave;
· alcance e impacto del cambio en las partes interesadas;
· relaciones identificadas y posible intersección de partes interesadas;
· requisitos de las partes interesadas para las comunicaciones en la fase actual del proyecto;
· información sobre la información difundida a las partes interesadas, incluido el idioma, el formato, el contenido y el nivel de detalle;
· el motivo de la difusión de esta información y el impacto esperado en el nivel de participación de las partes interesadas;
· tiempo y frecuencia de difusión de la información requerida a las partes interesadas;
· un método para actualizar y perfeccionar el plan de gestión de las partes interesadas a medida que el proyecto avanza y se desarrolla.
Guía de los conocimientos sobre gestión de proyectos (Guía PMBOK)
Registro bibliográfico de la Biblioteca del Congreso
Títulos: Project Management Institute (PMI), editorial.
Título: Guía del conjunto de conocimientos sobre gestión de proyectos (guía PMBOK) / Project Management Institute.
Otros títulos: Guía del PMBOK
Descripción: Sexta Edición | Newtown Square, PA: Instituto de Gestión de Proyectos, 2017. | Serie: Guía PMBOK |
Identificadores: LCCN 2017032505 (imprimir) | LCCN 2017035597 (libro electrónico) | ISBN 9781628253900 (ePUP) |
ISBN 9781628253917 (encendido) | ISBN 9781628253924 (PDF web) | ISBN 9781628251845 (rústica)
Materia: LCSH: Gestión de proyectos. | BISAC: NEGOCIOS Y ECONOMÍA / Gestión de Proyectos (NEGOCIOS Y ECONOMÍA / Gestión de Proyectos).
Clasificación: LCC HD69.P75 (libro electrónico) | LCC HD69.P75 G845 2017 (imprimir) | DDC 658.4/04-dc23
El registro LC está disponible en https://lccn.loc.gov/2017032505
Instituto de gestión de proyectos, Inc.
14 Campus Bulevar
Newtown Square, Pensilvania 19073-3299 EE. UU.
Teléfono: +1 610-356-4600
Fax: +1 610-356-4647
Correo electrónico correo: [correo electrónico protegido]
Sitio web: https://www.PMI.org
Materiales de Project Management Institute, Inc. están protegidos por derechos de autor según la ley de propiedad intelectual de los Estados Unidos, que está reconocida en la mayoría de los países. Para volver a publicar o reproducir materiales de PMI, debe obtener nuestro permiso. Para obtener más información, visite http://www.pmi.org/permissions_for_details.
Para realizar un pedido comercial u obtener información sobre precios, comuníquese con Independent Publishers Group:
Grupo de editores independientes
Departamento de pedidos
814 Norte de la calle Franklin
Chicago, IL 60610 EE. UU.
Teléfono: +1 800-888-4741
Fax: +1 312-337-5985
Correo electrónico correo: [correo electrónico protegido](solo para pedidos)
Para cualquier otra pregunta, comuníquese con el Centro de servicio de libros de PMI.
Centro de servicio de libros PMI
CORREOS. Box 932683, Atlanta, GA 31193-2683 EE. UU.
Teléfono: 1-866-276-4764 (EE. UU. o Canadá) o +1-770-280-4129 (en todo el mundo)
Fax: +1-770-280-4113
Correo electrónico correo: [correo electrónico protegido]
Impreso en los Estados Unidos de América Ninguna parte de esta publicación puede reproducirse o transmitirse de ninguna forma ni por ningún medio, electrónico, manual, fotocopia, grabación o mediante cualquier sistema de almacenamiento y recuperación de información, sin el permiso previo del editor.
PMI, logo PMI, PMBOK, OPM3, PMP, CAPM, PgMP, PfMP, PMI-RMP, PMI-SP, PMI-ACP, PMI-PBA, PROJECT MANAGEMENT JOURNAL, PM NETWORK, PMI HOY, PULSO DE LA PROFESIÓN y lema HACER GESTIÓN DE PROYECTOS INDISPENSABLE PARA LOS RESULTADOS DEL NEGOCIO.
son marcas comerciales de Project Management Institute, Inc. Para obtener una lista completa de las marcas comerciales de PMI, comuníquese con PMI Legal. Todas las demás marcas comerciales, marcas de servicio, nombres comerciales, imágenes comerciales, nombres de productos y logotipos que aparecen aquí son propiedad de sus respectivos dueños. Todos los derechos no otorgados expresamente en este documento están reservados al propietario de los derechos de autor.
Reservados todos los derechos. Queda prohibida la reproducción total o parcial del libro en cualquier forma sin el permiso escrito del editor.
© Copyright 2017 Project Management Institute, Inc. Reservados todos los derechos.
© Traducción al ruso, publicación, diseño de Olympus – Editorial empresarial, 2018
Notificación
Los estándares y pautas publicados por Project Management Institute, Inc. (abreviado como PMI), incluido este documento, se desarrollan a través de un proceso de desarrollo de estándares basado en la participación voluntaria y el consenso general. Este proceso combina los esfuerzos de voluntarios y/o reúne los comentarios y opiniones de personas interesadas en el tema tratado en la publicación. Aunque PMI administra el proceso y establece reglas para garantizar la imparcialidad a la hora de llegar a un consenso, PMI no redacta el documento ni prueba, evalúa ni verifica de forma independiente la exactitud o integridad del material contenido en las normas y directrices emitidas por PMI. Asimismo, PMI no verifica la validez de las opiniones expresadas en estos documentos.
PMI no será responsable de ninguna lesión personal, daño a la propiedad u otros daños, ya sean reales, indirectos o ejemplares, que surjan directa o indirectamente de la publicación, aplicación o uso de este documento. PMI no es responsable ni ofrece garantía, expresa o implícita, en cuanto a la exactitud o integridad de cualquier material contenido en este documento y no asume responsabilidad ni garantía de que la información contenida en este documento satisfará cualquiera de sus propósitos o necesidades. PMI no ofrece ninguna garantía con respecto a la calidad de los productos o servicios de ningún fabricante o proveedor individual que resulten del uso de esta norma o guía.
Al emitir y distribuir este documento, PMI no presta servicios profesionales ni de otro tipo a ninguna persona o entidad o en nombre de ella; PMI tampoco cumple con ninguna obligación de ninguna persona o entidad hacia ningún tercero. Al utilizar este documento, la persona que lo utiliza debe tomar su propia determinación de la acción necesaria en sus circunstancias particulares, confiando únicamente en su propio criterio o, en su caso, en el asesoramiento de un profesional competente. La información sobre el tema cubierto por este documento o las normas relacionadas se puede obtener de otras fuentes, que el usuario puede consultar según sea necesario para obtener información adicional no contenida en este documento.
PMI no tiene autoridad y no asume ninguna obligación de monitorear la conformidad de las prácticas existentes con el contenido de este documento o de poner esas prácticas en conformidad con este documento. PMI no certifica, prueba ni inspecciona de forma rutinaria productos, diseños o diseños para determinar la seguridad de uso o la salud del consumidor. Cualquier certificación u otra declaración de conformidad de cualquier información relacionada con la seguridad operativa o la seguridad de la salud contenida en este documento no puede atribuirse a PMI; en tal caso, la responsabilidad recae enteramente en la persona que emitió el certificado o hizo tal declaración.
Parte 1: Una guía para los conocimientos sobre gestión de proyectos (Guía PMBOK®)
1. Introducción
1.1 Descripción general y propósito de este manual
La gestión de proyectos no es nada nuevo. La gente lo ha estado usando durante muchos siglos. Ejemplos de proyectos completados incluyen:
Pirámides de Giza,
Juegos olímpicos,
La Gran Muralla de China,
Taj Mahal,
Publicando un libro para niños,
Canal de Panama,
Desarrollo de aviones a reacción comerciales,
Vacuna contra la polio,
Aterrizando al hombre en la luna
Aplicaciones informáticas comerciales,
Dispositivos portátiles para utilizar el Sistema de Posicionamiento Global (GPS),
Lanzamiento de la Estación Espacial Internacional a la órbita terrestre baja.
Los logros prácticos de estos proyectos fueron el resultado de la aplicación por parte de directivos y directivos de prácticas, principios, procesos, herramientas y métodos de gestión de proyectos en su trabajo. Los gerentes de estos proyectos utilizaron una serie de habilidades clave y aplicaron el conocimiento necesario para satisfacer a sus clientes y otras personas involucradas o afectadas por el proyecto. A mediados del siglo XX, los directores de proyectos comenzaron a trabajar para lograr el reconocimiento de la gestión de proyectos como profesión. Un aspecto de este trabajo fue llegar a un acuerdo sobre el contenido de un cuerpo de conocimientos (BOK) llamado gestión de proyectos. La EQA pasa a denominarse Cuerpo de conocimientos para la gestión de proyectos (PMBOK). El Project Management Institute (PMI) ha creado esquemas básicos y glosarios para el PMBOK. Los directores de proyecto pronto se dieron cuenta de que el PMBOK no podía estar contenido completamente en un solo libro. Por lo tanto, PMI desarrolló y publicó "Guía de los conocimientos sobre gestión de proyectos" (Guía PMBOK®).
Según lo define el PMI, el Cuerpo de conocimientos sobre gestión de proyectos (PMBOK) es un concepto que describe el conocimiento en la profesión de gestión de proyectos. El conjunto de conocimientos sobre gestión de proyectos incluye prácticas tradicionales establecidas y ampliamente utilizadas, así como prácticas innovadoras de reciente aparición.
El Cuerpo de Conocimientos (BKK) incluye material publicado e inédito. Este conjunto de conocimientos está en constante evolución. El presente Guía PMBOK® destaca esa parte de los conocimientos sobre gestión de proyectos que generalmente se acepta como buena práctica.
? Generalmente reconocido significa que los conocimientos y prácticas descritos son aplicables a la mayoría de los proyectos en la mayoría de los casos, y existe consenso sobre su valor y beneficio.
? Buena práctica significa que existe un acuerdo general en que la aplicación correcta de estos conocimientos, habilidades, herramientas y técnicas a los procesos de gestión de proyectos puede aumentar la probabilidad de éxito en una amplia gama de proyectos diferentes para entregar el valor y los resultados comerciales esperados.
El director del proyecto trabaja con el equipo del proyecto y otras partes interesadas para identificar y utilizar buenas prácticas generalmente aceptadas para cada proyecto. Determinar la combinación adecuada de procesos, insumos, herramientas, métodos, resultados y fases del ciclo de vida para gestionar un proyecto se denomina “adaptación” del conocimiento descrito en esta Guía.
El presente Guía PMBOK® No es una metodología. La metodología es un sistema de prácticas, métodos, procedimientos y reglas utilizados en un determinado campo de actividad. El presente Guía PMBOK® Es la base sobre la cual una organización puede desarrollar sus metodologías, políticas, procedimientos, reglas, herramientas y técnicas, y las fases del ciclo de vida requeridas en las prácticas de gestión de proyectos.
Esta Guía se basa en Estándar de gestión de proyectos. Una norma es un documento establecido por un organismo autorizado, costumbre o de común acuerdo como modelo o muestra. Estándar de gestión de proyectos fue desarrollado como estándar del Instituto Nacional Estadounidense de Estándares (ANSI) utilizando un proceso basado en los principios de consenso, apertura, debido proceso y equilibrio. Estándar de gestión de proyectos es el material de referencia fundamental para los programas de desarrollo profesional y la práctica de gestión de proyectos de PMI. Debido a que existe la necesidad de adaptar la gestión de proyectos para satisfacer las necesidades de un proyecto específico, tanto la Norma como la Guía se basan en descriptivo, pero no directiva prácticas. Como tal, esta Norma define procesos que son buenas prácticas para la mayoría de los proyectos en la mayoría de circunstancias. Esta Norma también define las entradas y salidas que típicamente están asociadas con estos procesos. La norma no contiene requisitos para la implementación obligatoria de ciertos procesos o prácticas específicas. Estándar de gestión de proyectos incluido en la parte II Guías para los conocimientos sobre gestión de proyectos (Guía PMBOK®).
EN Guía PMBOK® Proporciona más detalles sobre conceptos clave, tendencias emergentes, consideraciones para adaptar los procesos de gestión de proyectos e información sobre cómo aplicar herramientas y técnicas a los proyectos. Los gerentes de proyectos pueden utilizar una o más metodologías al implementar los procesos de gestión de proyectos descritos en este Estándar.
? Estándar de gestión de cartera, Y
? Estándar de gestión de programas .
El vocabulario general es un elemento esencial de cualquier disciplina profesional. Léxico de términos de gestión de proyectos del PMI proporciona un diccionario básico de terminología profesional que pueden utilizar de manera consistente organizaciones, gerentes de proyectos, programas y carteras, y otras partes interesadas del proyecto. Léxico se desarrollará con el tiempo. El glosario de este manual incluye un glosario de los contenidos incluidos. Léxico términos, así como definiciones adicionales. Los proyectos pueden utilizar otros términos específicos de la industria que se definen en la literatura de la industria.
PMI publica con el objetivo de generar confianza en la profesión de gestión de proyectos y ayudar al individuo a tomar decisiones acertadas, especialmente en situaciones difíciles en las que se le puede pedir que actúe de manera deshonesta o comprometa sus valores. Los valores que la comunidad global de gestión de proyectos ha identificado como los más importantes son la responsabilidad, el respeto, la justicia y la honestidad. El Código de Ética y Conducta Profesional se basa en estos cuatro valores.
Código de Ética y Conducta Profesional incluye tanto incentivos como normas obligatorias. Los estándares de incentivos describen el comportamiento que los profesionales que también son miembros del PMI, titulares de certificados o voluntarios deben esforzarse por lograr como resultado de sus creencias internas. Si bien el cumplimiento de los estándares de incentivos no es fácil de evaluar, se espera un comportamiento acorde con ellos de aquellos profesionales que se consideran profesionales, es decir, estos estándares no pueden considerarse opcionales. Las normas obligatorias son requisitos obligatorios y en algunos casos restringen o prohíben ciertos comportamientos de los profesionales. Los profesionales que sean miembros de PMI, titulares de certificados o voluntarios que participen en actividades que violen estos estándares están sujetos a los procedimientos disciplinarios del Comité de Ética de PMI.
1.2 Elementos fundamentales
Esta sección describe los elementos fundamentales necesarios para trabajar en el campo y comprender la disciplina de la gestión de proyectos.
Un proyecto es una empresa temporal destinada a crear un producto, servicio o resultado único.
? Producto, servicio o resultado único. Los proyectos se implementan para lograr objetivos mediante la creación de resultados entregables. Una meta es el resultado final al que se debe dirigir el trabajo; la posición estratégica a adoptar; el problema a resolver; el resultado a obtener; el producto a producir; o servicio a prestar. Un entregable es cualquier producto, resultado o capacidad de servicio único y verificable que se requiere para completar un proceso, fase o proyecto. Los resultados obtenidos pueden ser tangibles o intangibles.
El logro de los objetivos del proyecto puede producir uno o más de los siguientes entregables:
Un producto único, que puede ser un componente de otro producto, una mejora o solución a algún producto, o un nuevo producto final en sí mismo (por ejemplo, eliminar un defecto en el producto final);
Un servicio único o capacidad para proporcionar un servicio (por ejemplo, una unidad de negocio que respalda la fabricación o distribución);
Un resultado único, como un entregable o un documento (por ejemplo, un proyecto de investigación produce nuevos conocimientos que pueden usarse para determinar si un nuevo proceso es una tendencia o es beneficioso para la sociedad);
Una combinación única de uno o más productos, servicios o entregables (por ejemplo, una aplicación de software, documentación asociada y servicios de soporte técnico).
Ciertos elementos pueden repetirse en algunos de los entregables y actividades del proyecto. Esta repetición no cambia las características fundamentales y únicas del trabajo del proyecto. Por ejemplo, los edificios de oficinas pueden construirse con los mismos materiales o por el mismo equipo de construcción. Sin embargo, cada proyecto de construcción sigue siendo único en sus características principales (por ejemplo, ubicación, diseño, entorno, entorno, personas involucradas).
Los proyectos se llevan a cabo en todos los niveles de la organización. En un proyecto pueden participar una o más personas. Un proyecto puede involucrar una unidad estructural de una organización o varias unidades estructurales de diferentes organizaciones.
Los ejemplos de proyectos incluyen, entre otros:
Desarrollo de nuevos productos farmacéuticos para el mercado;
Ampliación de los servicios de turismo de excursiones;
Fusión de dos organizaciones;
Mejorar el proceso de negocio en la organización;
Comprar e instalar nuevo hardware informático para su uso dentro de la organización;
Exploración de campos petroleros en la región;
Modificación de un programa informático utilizado en una organización;
Realizar investigaciones para desarrollar un nuevo proceso de producción;
Construcción de un edificio.
? Empresa temporal. La naturaleza temporal de los proyectos indica que hay un comienzo y un final definidos. El término "temporal" no significa necesariamente que el proyecto esté destinado a durar poco tiempo. El final del proyecto se produce cuando una o más de las siguientes afirmaciones son verdaderas:
Objetivos del proyecto alcanzados;
Los objetivos no se alcanzarán o no se podrán alcanzar;
Los fondos para el proyecto se han agotado o ya no pueden asignarse;
La necesidad del proyecto ha cesado (por ejemplo, el cliente ya no quiere que el proyecto se complete, un cambio en la estrategia o las prioridades requiere que se termine el proyecto, la dirección de la organización ordena que se termine el proyecto);
Los recursos humanos o materiales están agotados;
El proyecto se termina por razones legales o de conveniencia.
Los proyectos son temporales, pero sus entregables pueden existir más allá del final del proyecto. Los proyectos pueden producir resultados de naturaleza social, económica, material o ambiental. Por ejemplo, un proyecto de monumento nacional produce un resultado que se espera que dure siglos.
? Los proyectos impulsan el cambio. Los proyectos sirven como impulsores del cambio en las organizaciones. Desde una perspectiva empresarial, el objetivo de un proyecto es mover una organización de un estado a otro para lograr un objetivo específico (consulte la Figura 1-1). Generalmente se supone que la organización se encuentra en su estado original antes de que comience el proyecto. Y el resultado deseado del cambio durante el proyecto se describe como un estado futuro.
Algunos proyectos pueden implicar la creación de un estado de transición, donde varios pasos se suceden para lograr un estado futuro. El resultado de la finalización exitosa del proyecto es la transición de la organización a un estado futuro y el logro de un objetivo específico. Para más información sobre gestión de proyectos y cambios, consulte el documento Gobernanza de carteras, programas y proyectos: una guía práctica.
Arroz. 1–1. Transición de una organización a un nuevo estado con la ayuda de un proyecto.
? Los proyectos crean valor empresarial. PMI define el valor empresarial como el beneficio neto y cuantificable derivado de una empresa comercial. El beneficio puede ser tangible, intangible o ambos. En el análisis empresarial, el valor empresarial es el beneficio recibido en formas como tiempo, dinero, bienes o activos intangibles a cambio de algún tipo de inversión. Cm. Análisis empresarial para profesionales: una guía práctica, pág..
El valor comercial de los proyectos se refiere a los beneficios que reciben las partes interesadas como resultado de la implementación de un proyecto específico. Los beneficios de un proyecto pueden ser tangibles, intangibles o ambos.
Ejemplos de elementos materiales incluyen:
Dinero en efectivo,
Capital social,
Ingeniería en Redes,
Activos fijos,
El 31 de diciembre de 2012, PMI publicó una nueva edición de la Guía de los fundamentos para la dirección de proyectos (Guía PMBOK® - 5ª edición).
Los especialistas de PMI en la publicación de la traducción de PMBoK al ruso prometen que antes de fin de año este trabajo estará terminado y la comunidad profesional rusa podrá conocer plenamente todas las novedades y sutilezas de la nueva edición de PMBoK. Teniendo en cuenta las quejas sobre la traducción de PMBoK v.4, es mejor dejar que la versión rusa se publique más tarde, pero lo harán. su calidad.
Según los expertos, el largo período de trabajo está justificado: es necesario explicar muchos términos nuevos, describir nuevos procesos, aclarar las traducciones de términos y procesos antiguos y las traducciones deben ser coherentes con otros estándares emitidos por PMI. .
¿Qué hay de nuevo en el nuevo PMBOK 5?
La sección X1 “Cambios en la quinta edición” nos habla precisamente de esto. Entre toda la información general (como "todo el texto y los gráficos del documento se han revisado para que la información sea más precisa, clara, completa y actualizada" o "el capítulo del Grupo de Procesos se ha trasladado al Apéndice A1") , también es útil:
1. Terminología y armonización
Los autores afirman con orgullo que toda la terminología está alineada con el Léxico de términos de gestión de proyectos del PMI. Al mismo tiempo, se da prioridad a la terminología del PMI Lexicon. Si la traducción del PMBOK 5 al ruso comienza con la creación de la terminología correcta, entonces hay esperanzas de obtener un conjunto de conocimientos traducido de manera competente.
Además, el PMBOK 5 cumple con la norma ISO 21500:2012 “Guía para la gestión de proyectos” y armoniza los nombres, procesos, entradas, salidas, herramientas y métodos con otros estándares del PMI (como el “Estándar para la gestión de carteras”, etc.) está garantizado.
Finalmente, dejaron de confundir a la gente con su “riesgo positivo”. Después de todo, ¿qué es el riesgo? ¡Esta es la posibilidad de peligro o fracaso! El término proviene del griego risikon, es decir. "acantilado" o "roca". Durante los tiempos de grandeza y poder de la Antigua Grecia, “correr riesgos” significaba “maniobrar un barco entre las rocas”, es decir, peligro potencial de fracaso.
En el PMBOK 5, se realizaron cambios en la descripción de la gestión de riesgos del proyecto y se desplazó el énfasis del término "riesgo positivo" al término "oportunidad". También se agregaron al texto conceptos como actitud ante el riesgo, apetito por el riesgo, tolerancia al riesgo y umbrales de riesgo.
2. Éxito del proyecto
Debido a que los proyectos son de naturaleza temporal, el éxito del proyecto debe medirse en términos de completarlo dentro de las limitaciones de alcance, tiempo, costo, calidad, recursos y riesgos.
Pero la dinámica de los requisitos cambiantes en los proyectos modernos es tan intensa que, al final, el proyecto supera todas las restricciones imaginables e inconcebibles. Por lo tanto, gestionar los requisitos cambiantes y registrarlos en los documentos del proyecto. y re-coordinación La planificación básica es una habilidad cada vez más buscada por los directores de proyectos. Esto se refleja en el PMBOK 5 en la frase “El éxito del proyecto debe atribuirse a la implementación de los últimos planes de referencia aprobados por las partes interesadas autorizadas”. En mi opinión, no hay mejor manera de decirlo. Si logró acordar con el cliente un aumento en los plazos y el presupuesto del proyecto dos días antes del final del proyecto, entonces el proyecto es exitoso, a pesar de exceder el doble de los plazos y el aumento de 3 veces en el presupuesto.
3. Enfoques de gestión de la planificación
En PMBOK 4, algunos de los planos auxiliares aparecieron como surgidos de la nada. Por ejemplo, la descripción del Plan de Gestión del Alcance se dio directamente en la descripción del área de conocimiento “Gestión del Alcance del Proyecto”, pero no se indicó en qué proceso se creó. Ahora se han agregado cuatro nuevos procesos de planificación: planificación de la gestión del alcance, planificación de la gestión del cronograma, planificación de la gestión de costos y planificación de la gestión de las partes interesadas. Esto proporciona Orientación clara para el equipo del proyecto para pensar y planificar activamente enfoques para gestionar todas las áreas del conocimiento.
Aunque aquí hubo algunas deficiencias. Por lo tanto, dos planes quedaron “desatendidos”: el Plan de gestión de cambios y el Plan de gestión de configuración. Lógicamente, está claro que el Plan de Gestión de la Configuración debe aparecer junto con el Plan de Gestión del Alcance y el Plan de Gestión de Cambios durante el desarrollo del Plan de Gestión del Proyecto general, pero en PMBOK 5 esto sólo está implícito.
4. Requisitos
El proceso de recopilación de requisitos se ha ampliado para enfatizar la obtención de todos los requisitos necesarios para el éxito del proyecto.
El proceso Verificar alcance ha sido completamente rediseñado. En primer lugar, pasó a llamarse Validar alcance. En segundo lugar, se añadió el énfasis en que el proceso no se trata sólo de aceptar los resultados, sino también de que los resultados proporcionen valor al negocio y satisfagan los objetivos del proyecto.
Es curioso, pero en PMBOK 4 había una traducción no muy correcta de "Verificar alcance" como "Confirmación de contenido". Ahora bien, esto conducirá al hecho de que en el PMBOK 5 ruso este proceso no cambiará de nombre. ¿Me pregunto cómo evitarán los traductores traducir la sección sobre cambios?
5. Gutapercha
En todos los PMBOK anteriores combinados, la palabra "ágil" nunca se usó no utilizado. En el PMBOK actual aparece hasta 10 veces.
PMI nunca ha ocultado el hecho de que el objetivo principal de la Guía del PMBOK es resaltar esa parte de los conocimientos sobre gestión de proyectos que generalmente se considera una buena práctica. Aquellos. Los conocimientos y prácticas descritos son aplicables a la mayoría de los proyectos en la mayoría de situaciones, y la aplicación correcta de estas habilidades, herramientas y técnicas puede aumentar la probabilidad de éxito para una amplia gama de proyectos diferentes.
Por lo tanto, el concepto de gestión flexible de proyectos "ágil" se incluyó en el proceso de desarrollo del cronograma del proyecto.
Así es, ¡debes mantener la nariz contra el viento! es moderno tambien tanto de moda como comercialmente demandados.
6. Comunicaciones del proyecto
La racionalización de la información y los conocimientos generados durante la ejecución del proyecto era necesaria desde hacía mucho tiempo. Uno de los cambios más revolucionarios en PMBOK 5 es el uso del modelo DIKW (datos, información, conocimiento, sabiduría), una jerarquía de información, donde cada nivel agrega ciertas propiedades al nivel anterior:
En la parte inferior están los datos.
La información agrega contexto.
El conocimiento añade una respuesta a la pregunta "¿cómo?" (mecanismo de uso).
La sabiduría añade una respuesta a la pregunta "¿cuándo?" (Condiciones de uso).
Esto se expresó en una secuencia clara de recopilación, agregación y procesamiento de datos de los campos en forma de los siguientes documentos:
1. Datos sobre la ejecución de la obra. Observaciones y mediciones “brutas” identificadas durante la implementación del trabajo de diseño.
2. Información sobre la ejecución de la obra. Los datos de desempeño laboral se analizan e integran en función de las relaciones entre las diferentes áreas/fases del proyecto.
3. Informes de ejecución de obra. Una representación física o electrónica de información sobre el desempeño laboral destinada a ayudar a tomar decisiones, resaltar cuestiones y problemas, desarrollar acciones o comprender una situación.
Si además sumamos aquí las Lecciones de la Experiencia, el ciclo se cierra y todo el conocimiento generado en los procesos de implementación del proyecto será recopilado y procesado. y ser usado en los procesos de gestión de todos los proyectos de la organización.
Bueno, los procesos que confundieron a muchos con la confusión de sus límites y una secuencia incomprensible: "Difusión de información" y "Preparación de informes de desempeño" pasaron a llamarse, respectivamente, "Gestión de la comunicación" y "Control de la comunicación" con entradas y salidas lógicas. .
7. Gestión de los “propietarios de acciones”
PMBOK 5 pone gran énfasis en la gestión de partes interesadas. Casi todas las secciones están cubiertas para iluminar mejor quiénes son las partes interesadas del proyecto y su impacto en el mismo. Se ha agregado una nueva (décima) área de conocimiento: “Gestión de partes interesadas del proyecto”, que incluye dos procesos de “Gestión de comunicación del proyecto”, y también se han agregado dos nuevos procesos.
Las principales razones de este surgimiento del campo del conocimiento de la comunicación son las siguientes:
1. Se requería un enfoque más claro de la gestión de comunicaciones del proyecto en la planificación de las necesidades de comunicación del proyecto, en la recopilación y el almacenamiento. y difusión información en el proyecto, así como en el seguimiento de las relaciones generales del proyecto para garantizar su eficacia.
2. La gestión real de los stakeholders incluye no sólo el análisis de sus expectativas, su impacto en el proyecto y el desarrollo de estrategias adecuadas para gestionarlas, sino también el diálogo constante. con interesados partes para satisfacer sus necesidades y expectativas, resolviendo problemas como su ocurrencia, e involucrar a las partes interesadas en la toma de decisiones y las actividades del proyecto.
3. Planificar y gestionar las necesidades de comunicación del proyecto, por un lado, y las necesidades de las partes interesadas, por el otro, son dos claves diferentes para el éxito del proyecto.
Separar la gestión de las partes interesadas del proyecto de la gestión de las comunicaciones del proyecto, además de resolver los 3 problemas descritos anteriormente, garantiza que el PMBOK 5 satisfaga las nuevas tendencias crecientes en la gestión de proyectos y el gran interés de los investigadores y directores de proyectos en ejercicio. a la interacción con las partes interesadas, como una de las claves del éxito global del proyecto. Estas tendencias ya se reflejan en el “Estándar para la gestión de programas” y en la “Guía para la gestión de proyectos” ISO 21500:2012. Así que el PMBOK se ha puesto al día.
Así, la nueva área de conocimiento incluye los procesos:
Identificación de partes interesadas.
Desarrollo de un Plan de Gestión de Grupos de Interés.
Gestionar la participación de las partes interesadas.
Seguimiento de la implicación de los interesados.
8.Habilidades blandas
Se agregaron habilidades interpersonales: creación de confianza, gestión de conflictos. y Mentoría. Además, se ha agregado una nueva sección al Capítulo 1, Introducción, que destaca la importancia de las habilidades interpersonales del gerente de proyecto y remite al lector al Apéndice X3 para obtener una descripción detallada de estas habilidades.
9. Documentación
Bueno, lo más importante para documentar el proyecto es la organización general de los documentos, que comenzó en el PMBOK 4 y continuó en el PMBOK 5. Ahora, las entradas del proceso son sólo documentos que juegan un papel clave en la ejecución del proceso. Los documentos y su composición se han vuelto más claros y específicos. Aunque los nombres de los documentos en el texto están escritos en letras minúsculas en todas partes, lo que dificulta la búsqueda visual de documentos en el texto y, para trabajar con documentos, es necesario tener un buen conocimiento de la terminología del PMBOK o utilizar un paquete de plantillas.
En general, el PMBOK 5 se ha vuelto mejor estructurado, consistente, con relaciones normales entre procesos y terminología verificada.
La Guía PMBOK-5 ® representa buenas prácticas generalmente reconocidas en la profesión de gestión de proyectos.
¿Cómo descargar PMBOK?
La nueva Guía del PMBOK, quinta edición, se publicó el 31 de diciembre de 2008. Ahora está disponible para todos los miembros del PMI en la siguiente página:
Encontrarás un enlace con el título. Guía de los conocimientos sobre gestión de proyectos (Guía PMBOK), quinta edición que se utilizará para comprar esta versión de PMBOK. Simplemente haga clic en este enlace que le dará la opción de agregar una copia del estándar a su carrito de compras. Actualmente su precio es de $65,95 para no socios y de $49,50 para socios de PMI. Finalmente, realice la compra y descargue su versión PDF. Se debe seguir el siguiente procedimiento al descargar su copia del PMBOK 5.
Usuarios de Windows:
Cuando hace clic en la versión en inglés para descargar la Guía PMBOK® 5.ª edición, este mensaje aparecerá como "El sistema FileOpen asocia sus permisos de miembro a la publicación" y le solicitará que descargue e instale el complemento FileOpen Adobe Reader.
Este paso es necesario únicamente para el primer uso. Haga clic en Sí para comenzar la instalación del complemento Adobe Reader". Luego, después de instalar correctamente el complemento Fileopen, cierre la ventana y regrese y descargue, pero debe ser miembro de PMI para acceder.
Usuarios de Mac:
Mac usa Safari, que abre archivos PDF en el navegador. Eso no puede funcionar si la seguridad y otras funciones avanzadas están integradas en el PDF. Eso requiere tener instalada una versión completa de PDF Reader o Adobe Acrobat.
Aquí está el comentario de soporte de APPLE sobre la lectura de archivos PDF con Safari. Adobe PDFViewer para Mac OS X no se ejecutará correctamente en un sistema que no cumpla con los siguientes requisitos.
Global Estándar
Instituto de manejo proyectos
GUÍA DEL CUERPO DE CONOCIMIENTOS DE GESTIÓN
PROYECTOS
(Guía PMBOK®) - Quinta Edición
ISBN 978-1-62825-008-4
Editor:
Instituto de gestión de proyectos, Inc.
14 Campus Bulevar
Newtown Square, Pensilvania 19073-3299 EE. UU.
Teléfono: +610-356-4600
Fax: +610-356-4647
Dirección de correo electrónico: [correo electrónico protegido]
Internet: www.PMI.org
©2013 Instituto de Gestión de Proyectos, Inc. Reservados todos los derechos.
"PMI", el logotipo de PMI, "PMP", el logotipo de PMP, "PMBOK", "PgMP", "Project Management Journal", "PM Network" y el logotipo de PMI Today son marcas comerciales registradas de Project Management Institute, Inc. "Quarter Globe Design" es una marca registrada de Project
Instituto de Gestión, Inc. Una lista completa de las marcas comerciales de PMI está disponible en PMI Legal.
El Departamento de Publicaciones del PMI agradece cualquier corrección o comentario sobre las publicaciones del PMI. No dude en informar errores tipográficos, de formato o cualquier otro error. Para hacer esto, simplemente haga una copia de la página requerida, marque el error que notó y envíe esta copia a la siguiente dirección:
Editor de libros, Publicaciones PMI, 14 Campus Boulevard, Newtown Square, PA 19073-3299 EE. UU.
Para obtener información sobre descuentos para reventa o uso educativo, comuníquese con el Centro de servicio de libros de PMI.
Centro de servicio de libros PMI
CORREOS. Box 932683, Atlanta, GA 31193-2683 EE. UU.
Teléfono: 1-866-276-4764 (EE.UU. y Canadá) o +1-770-280-4129 (resto del mundo)
Fax: +1-770-280-4113
Dirección de correo electrónico: [correo electrónico protegido]
Impreso en los Estados Unidos de América. Ninguna parte de este trabajo puede reproducirse ni transmitirse de ninguna forma ni por ningún medio, ya sea electrónicamente, por escrito, mediante fotografías o grabaciones de audio, ni mediante ningún sistema de almacenamiento y recuperación de información, sin el permiso previo por escrito del editor.
Este documento cumple con el Estándar de papel permanente de EE. UU. publicado por la Organización Nacional de Estándares de Información, No. Z39.48-1984.
10 9 8 7 6 5 4 3 2 1
Registro bibliográfico de la Biblioteca del Congreso
Una guía para los conocimientos sobre gestión de proyectos (Guía PMBOK®). -- Quinta edición.
páginas cm
Incluye referencias bibliográficas e índice alfabético.
ISBN 978-1-62825-008-4 (tapa blanda)
1. Gestión de proyectos. I. Instituto de Gestión de Proyectos. II. Título: Guía del PMBOK.
HD69.P75G845 2013 658.4’04--dc23 2012046112
ETIQUETA FSC.pdf 1 18/12/12 13:16
NOTIFICACIÓN
Los estándares y pautas publicados por Project Management Institute, Inc. (abreviado como PMI), incluido este documento, se desarrollan a través de un proceso de desarrollo de estándares basado en la participación voluntaria y el consenso general. Este proceso combina los esfuerzos de voluntarios y/o reúne los comentarios y opiniones de personas interesadas en el tema tratado en la publicación. Aunque PMI administra el proceso y establece reglas para garantizar que se alcance un consenso sin prejuicios, PMI no redacta el documento ni prueba, evalúa ni verifica de forma independiente la exactitud o integridad del material contenido en las normas y directrices emitidas por PMI. Asimismo, PMI no verifica la validez de las opiniones expresadas en estos documentos.
PMI no será responsable de ninguna lesión personal, daño a la propiedad u otros daños, ya sean reales, consecuentes o ejemplares, que surjan directa o indirectamente de la publicación, aplicación o uso de este documento. PMI no es responsable ni ofrece garantía, expresa o implícita, en cuanto a la exactitud o integridad de cualquier material contenido en este documento y no asume responsabilidad ni garantía de que la información contenida en este documento satisfará cualquiera de sus propósitos o necesidades. PMI no ofrece ninguna garantía con respecto a la calidad de los productos o servicios de ningún fabricante o proveedor individual que resulten del uso de esta norma o guía.
Al emitir y distribuir este documento, PMI no presta servicios profesionales ni de otro tipo a ninguna persona o entidad o en nombre de ella; PMI tampoco cumple con ninguna obligación de ninguna persona o entidad hacia ningún tercero. Al utilizar este documento, la persona que lo utiliza debe tomar su propia determinación de la acción necesaria en sus circunstancias particulares, confiando únicamente en su propio criterio o, en su caso, en el asesoramiento de un profesional competente. La información sobre el tema cubierto por este documento o las normas relacionadas se puede obtener de otras fuentes que pueden consultarse para obtener información adicional no contenida en este documento.
PMI no tiene autoridad y no asume ninguna obligación de monitorear la conformidad de las prácticas existentes con el contenido de este documento o de poner esas prácticas en conformidad con este documento. PMI no certifica, prueba ni inspecciona de forma rutinaria productos, diseños o diseños para determinar la seguridad de uso o la salud del consumidor. Cualquier certificación u otra declaración de conformidad de cualquier información relacionada con la seguridad operativa o la seguridad de la salud contenida en este documento no puede atribuirse a PMI; en tal caso, la responsabilidad recae enteramente en la persona que emitió el certificado o hizo tal declaración.
TABLA DE CONTENIDO
I
TABLA DE CONTENIDO
1. INTRODUCCIÓN............................................... ................................................. ...... .................................1
1.1 Propósito de la Guía PMBOK®
................................................................................................... 2
1.2 ¿Qué es un proyecto? ................................................. ............................................................ ............ ..........3
1.2.1. Vínculos entre portafolios, programas y proyectos................................................. ........4
1.3 ¿Qué es la gestión de proyectos? ................................................. ........................................5
1.4 Vínculos entre gestión de cartera, gestión de programas y gobernanza
Gestión de proyectos y proyectos organizacionales................................................. .................... .....7
1.4.1 Gestión del programa................................................ ....... ........................................9
1.4.2 Gestión de cartera................................................ ....................................................... .9
1.4.3 Proyectos y planificación estratégica................................................. ........................ 10
1.4.4 Oficina de Gestión de Proyectos................................................ ........ .................................. once
1.5 Relación entre gestión de proyectos y gestión de operaciones
y estrategia organizacional................................................. .... ........................................ 12
1.5.1 Gestión de operaciones
y gestión de proyectos................................................. ........................................................ 12
1.5.2 Organizaciones y gestión de proyectos.................................... ......... ................... 14
1.6 Valor empresarial................................................ ..... ................................................. ........... ............. 15
1.7 Papel del director del proyecto................................................ ........................................................ .... dieciséis
1.7.1 Áreas de responsabilidad y competencias del director del proyecto................................. ........ 17
1.7.2 Habilidades interpersonales del director de proyecto.................................... ......... 17
1.8 Cuerpo de conocimientos para la gestión de proyectos.................................... ........................................ 18
2. INFLUENCIA DE LA ORGANIZACIÓN Y EL CICLO DE VIDA DEL PROYECTO................................. ............. ................. 19
2.1 Influencia de la organización en la gestión de proyectos................................. .......................... 20
2.1.1 Culturas y estilos organizacionales................................................ ......... ........................ 20
2.1.2 Comunicaciones organizacionales................................................ ........................................ 21
2.1.3 Estructuras organizativas................................................ ........................................ 21
2.1.4 Activos del proceso organizacional ................................. ........................................ 27
2.1.5 Factores ambientales empresariales................................... ........................................ 29
2.2 Partes interesadas y gestión del proyecto................................................. ..... ......... treinta
2.2.1 Actores del proyecto................................................ ............... ...................... treinta
TABLA DE CONTENIDO
II
©2013 Instituto de Gestión de Proyectos. Guía de los conocimientos sobre gestión de proyectos (Guía PMBOK®) - Quinta edición
2.2.2 Gestión de proyectos................................................ ....................................................... 34
2.2.3 Éxito del proyecto................................................ ....................................................... ............. ....... 35
2.3 Equipo del proyecto................................................ .................... ................................ .......................... ............ 35
2.3.1 Composición de los equipos de proyecto.................................... ......... ........................................ .. 37
2.4 Ciclo de vida del proyecto................................................ ............................................................ ............ 38
2.4.1 Características del ciclo de vida del proyecto.................................... ......... ............ 38
2.4.2 Fases del proyecto................................................ ....................................................... ............. ...... 41
3. PROCESOS DE GESTIÓN DE PROYECTOS.................................... ....................................................... .... 47
3.1 Interacciones generales de los procesos de gestión de proyectos.................................... ......... 50
3.2 Grupos de procesos de gestión de proyectos................................. .................................................. 52
3.3 Grupo de proceso de iniciación................................................ ............................................................ ... 54
3.4 Grupo de proceso de planificación.................................... ............................ ................................ ......... 55
3.5 Grupo de procesos de ejecución................................................ ........................................................ 56
3.6 Grupo de procesos de seguimiento y control.................................. ........................................ 57
3.7 Grupo de proceso de cierre................................................ ............................ ................................ ................. 57
3.8 Información del proyecto................................................ ......... ........................................ ................. .. 58
3.9 El papel de las áreas de conocimiento................................... ........................................................ ............ 60
4. GESTIÓN DE LA INTEGRACIÓN DE PROYECTOS.................................... ....................................................... .... 63
4.1 Elaboración de una carta de proyecto................................................. ........................................................ ......... 66
4.1.1 Desarrollar una carta del proyecto: insumos................................. ........................................... 68
4.1.2 Desarrollar una Carta del Proyecto: Herramientas y Técnicas.................... ............. ... 71
4.1.3 Desarrollo de una carta de proyecto: resultados................................. ............................................ 71
4.2 Desarrollar un plan para la dirección del proyecto.................................... ........................................ 72
4.2.1 Desarrollo de un plan para la dirección del proyecto: insumos................................. ............ ....... 74
4.2.2 Desarrollo de un plan para la dirección del proyecto: herramientas y técnicas................................. 76
4.2.3 Desarrollar un plan para la dirección del proyecto: resultados................................. ............ .... 76
4.3 Dirección y dirección del trabajo del proyecto.................................... ......... ................... 79
4.3.1 Dirigir y gestionar el trabajo del proyecto: insumos................................. ............ 82
4.3.2 Dirigir y gestionar el trabajo de proyectos: herramientas y técnicas................................ 83
4.3.3 Dirección y gestión del trabajo del proyecto: resultados................................. ................. 84
4.4 Seguimiento y control del trabajo del proyecto.................................. ........................................ 86
TABLA DE CONTENIDO
III
©2013 Instituto de Gestión de Proyectos. Guía de los conocimientos sobre gestión de proyectos (Guía PMBOK®) - Quinta edición
4.4.1 Seguimiento y control del trabajo del proyecto: insumos................................. ............. ............ 88
4.4.2 Seguimiento y control del trabajo del proyecto: herramientas y métodos................................. 91
4.4.3 Seguimiento y control del trabajo del proyecto: resultados................................. ............. ......... 92
4.5 Control de cambios integrado................................................ ........................................ 94
4.5.1 Control de cambios integrado: entradas................................... .......... ....... 97
4.5.2 Control Integrado de Cambios: Herramientas y Técnicas................................... 98
4.5.3 Control Integrado de Cambios: Salidas................................... .......... ..... 99
4.6 Cerrar un proyecto o fase................................................ ........................................................ ... 100
4.6.1 Cierre de un proyecto o fase: insumos................................. ............ ........................ 102
4.6.2 Cerrar un proyecto o fase: herramientas y técnicas................................. ................ 102
4.6.3 Cierre de un proyecto o fase: resultados................................. ............................................ 103
5. GESTIÓN DEL CONTENIDO DEL PROYECTO.................................... ........................................................ 105
5.1 Planificación de la gestión de contenidos................................................ ........................................ 107
5.1.1 Planificación de la gestión de contenidos: entradas................................. .......... ... 108
5.1.2 Planificación de la gestión del alcance: herramientas y técnicas................................ 109
5.1.3 Planificación de la gestión de contenidos: resultados................................. .......... 109
5.2 Requisitos de recopilación................................................ .... ................................................. .......................... 110
5.2.1 Recopilación de requisitos: insumos.................................... ......... ........................................ 113
5.2.2 Recogida de requisitos: herramientas y técnicas.................................... ................. ................. 114
5.2.3 Recopilación de requisitos: salidas.................................. ........................................................ 117
5.3 Definición de contenido................................................ ..... ................................................. .. 120
5.3.1 Definición de contenido: entradas................................... .......................................... 121
5.3.2 Definición de contenido: herramientas y técnicas................................. ........... .122
5.3.3 Definición de contenido: resultados................................... .......................................... 123
5.4 Creación de la EDT................................................ ................................. ................................. .......................... ................ 125
5.4.1 Creando una WBS: Entradas................................... ......................................... ...... 127
5.4.2 Creación de una EDT: herramientas y métodos................................. ............................. 128
5.4.3 Creación de una EDT: salidas................................... ......................................... ... 131
5.5 Confirmación de Contenidos................................................ ........................................................ 133
5.5.1 Confirmación de contenidos: entradas................................... .......................................... 134
5.5.2 Validación de contenido: herramientas y técnicas................................. .......... 135
TABLA DE CONTENIDO
IV
©2013 Instituto de Gestión de Proyectos. Guía de los conocimientos sobre gestión de proyectos (Guía PMBOK®) - Quinta edición
5.5.3 Confirmación de contenidos: salidas................................... .......................... 135
5.6 Control de contenidos................................................ .... ................................................. ........... 136
5.6.1 Control de contenido: entradas.................................... ........................................ 138
5.6.2 Control de contenido: herramientas y técnicas.................................... ....... 139
