LOS SEIS (6) CONSEJOS PARA INICIAR SU NUEVO PROYECTO

    Desde el sitio ProjectManager este artículo nos propone 6 Consejos para iniciar su nuevo proyecto.

    Como se menciona en el artículo, el inicio de un proyecto nuevo es un momento que genera altas expectativas: trabajar en algo nuevo, quizá con personas nuevas, la oportunidad de integrarse a equipos e iniciativas diferentes implica que se podrán conocer todas las áreas de un negocio. 

    Sin embargo, el principio de un proyecto nuevo es también el momento para establecer el tono del proyecto y asegurar que todo el mundo está aliado a los nuevos objetivos. Es la oportunidad de empezar bien las cosas y hacer a un arranque de proyecto en forma profesional. 

Aquí hay 6 consejos para considerar cuándo inicia cualquier proyecto nuevo

1. Congregue al equipo del proyecto

    Como Administrador del Proyecto puede tener una buena idea de quien necesita estar en el equipo de proyecto, pero si no, la sugerencia es conversar con su patrocinador acerca de quién sería más conveniente convocar. 

    Usted puede necesitar involucrar a otros administradores y pedirles a ellos que sugieran a miembros de sus propios equipos disponibles (en forma parcial o permanente) a fin de aprovechar las habilidades del especialista en el nuevo proyecto. Piense acerca de todas las áreas del negocio que necesitarán estar representadas en el proyecto y busque incluir a alguien de cada una de ellas. También puede requerir recursos técnicos, así es que hable con los jefes de equipo técnicos para ver a quién se puede convocar al proyecto. 

2. Realice una reunión de arranque 

    Cuando tenga al equipo de proyecto, haga una reunión de arranque. Ésta es una gran oportunidad para que todos se conozcan. Use a la reunión para presentar a todo los miembros del equipo. Existen muchos juegos que permiten romper el hielo y que suelen animar a las personas a hablar. Por ejemplo, pedirle a cada persona encontrar 5 cosas que tenga en común con todos los demás en el cuarto. Puede ser algo tan simple como gustarle el mismo tipo de comida o tener hijos en la misma escuela, pero este ejercicio ha permitido encontrar personas que han vivido en el extranjero en el mismo país (si bien en momentos diferentes) o que juegan los mismos deportes. 

    Esta es una forma fácil de enfocar la atención en puntos de acuerdo. ¡Si logra poner a las personas a trabajar hombro a hombro durante esta reunión, quizá logre acuerdos sobre el acta del de proyecto o algunas ‘ reglas de compromiso ’ para el equipo! También puede usar el tiempo para dejar claros aclarar los roles y responsabilidades para cada individuo así como las metas y los objetivos del proyecto. 

3. Establezca el cronograma del proyecto 

   El cronograma del proyecto necesitará ser creado con el aporte del equipo, pero algunos de los temas básicos pueden ser propuestos por el Administrador. 

   Por ejemplo, establecer los recursos adecuados en la herramienta administrativa de la empresa y asegurar que todo el equipo tiene acceso al sistema en línea.  El Administrador puede registrar las tareas de proyecto relacionadas con la administración del proyecto, como la preparación de documentos cruciales, los informes de avance, la estructura global (como fases o etapas) e hitos de presupuesto. Si su la oficina de proyectos ha provisto plantillas como parte de la herramienta en línea, se pueden usar para ahorrar algo de trabajo.  Una vez que la estructura básica del cronograma del proyecto está lista, puede trabajar con otras personas del equipo para preparar una lista de tareas que podrá registrarse en la herramienta corporativa para que todo el mundo la pueda ver y actualizar. 

4. Establezca el sistema de registro de documentos 

   Muchos sistemas de administración del proyectos en línea tienen repositorios de documentos o la habilidad para almacenar documentación en en línea. Si se cuenta con esta capacidad, debe establecerse desde el principio para contar con un mecanismo adecuado de registro documental reconocido por todos. 

   También se sugiere establecer desde el principio cómo se nombraran los documentos y el mecanismo de control de versiones (es recomendable usar herramientas que ofrezcan control de versiones automático). Luego se deben crear las carpetas y subcarpetas necesarias y asegurar que todo el equipo tenga el nivel correcto de acceso. Por ejemplo, los miembros clave del equipo pueden tener autorización para leer, escribir, suprimir y editar documentos, mientras que otros interesados solo requerirán permisos de lectura. 

   ¡Si no se cuenta con una herramienta de administración del proyecto en línea, puede hacer el mismo ejercicio con carpetas compartidas de la red (o incluso folders de papel y una caja de cartón)! 

5. Escriba el documento de arranque del Proyecto - Acta constitutiva 

   Un documento de arranque del proyecto explica lo que el proyecto busca lograr y provee algún detalle de como se espera conseguirlo. Si se cuenta con una plantilla es una buena idea usarla a fin de que economizar algo de tiempo. 

   Este documento debería incluir, objetivos, criterios de éxito, una visión general de los hitos principales del cronograma del proyecto, la lista de personas involucradas y así como sus roles, una estimación de alto nivel del presupuesto y una referencia de los estándares que se pretendan usar durante el proyecto. En la practica se puede incluir cualquier cosa que ayuden a clarificar el entorno del proyecto y sus objetivos. Todo el equipo debe estar de acuerdo con el contenido y es recomendable que el patrocinador del proyecto lo firme, ya que es una forma de validar que realmente se ha comprendido el objetivo y el documento ayuda todo el mundo a entender lo que se espera. 

En un artículo previo hemos revisado consejos para la elaboración del acta del proyecto.

6. Cree un registro de eventos y riesgos 

   Finalmente, el proyecto necesita un registro de riesgos y eventos. Otra vez, si se cuenta con una plantilla hay que usarla. Si no, usted puede crear un registro simple en una hoja de cálculo o alguna otra herramienta que resulte cómoda al su equipo. El registro debería incluir información crucial acerca del riesgo y la forma de tratarlo, el nombre de la persona responsable para llevar a cabo esas acciones, así como la fecha que fue identificado. Una vez que ha establecido el formato, hay que registrar los riesgos y los asuntos que que se hayan identificado durante las reuniones iniciales del proyecto. 

    Hay que trabajar con el equipo para registrar las posibles situaciones que podrían causar problemas al proyecto a su debido momento.

LA PARADOJA DE LA GESTIÓN DE RIESGOS

     Desde la página de P3M Consulting, Fernando Santiago escribe sobre la paradoja de la gestión de riesgos.

    "El patrocinador ha perdido poder político y ya no puede apoyar el proyecto", "El  Ejecutivo X favorecerá al Vendedor Y debido a las sus relaciones familiares", "El recurso técnico clave del proyecto puede salir porque está mal pagado y sus habilidades están en alta demanda". 

    Todos estos son ejemplos de riesgos que preocupan al Administrador del Proyecto, pero que nunca llegan al registro de riesgos, ya que nadie se atrevería a documentarlos. Esta es la paradoja de la gestión de riesgos: se documenta todos los riesgos que que todo el mundo conoce, y se omiten los que potencialmente pueden descarrilar el proyecto. Debido a esto, la gestión del riesgo a veces es percibida como burocrática, ya que sólo cubre lo que es obvio, los lugares comunes, que son conocidos por todo el mundo y que probablemente ya estén siendo controlados de manera informal. 

      Es frecuente que el Administrador del Proyecto cuestione si su trabajo es documentar riesgos, causas, impactos, respuestas, etc., o en realidad hacer algo. La adecuada Administración de Riesgos debe convertirse en un "pensamiento estructurado", en donde documentar el riesgo de forma estructurada ayude al Administrador del Proyecto a entender mucho mejor cómo manejar la amenaza u oportunidad. 

     Un buen ejemplo es la definición de causas desencadenantes: ¿cómo sabemos que este evento podría pasar? Cuando se identifican correctamente las causas desencadenantes, son elementos que ayudan a calificar el riesgo y definir su probabilidad. 

    Por ejemplo: si el riesgo es que se puede sufrir un ataque al corazón, las causas desencadenantes serían: sufrir obesidad, fumar, no hacer ejercicio y, además ser Administrador de Proyectos. Determinar esto ayuda a establecer el plan de prevención: bajar de peso, dejar de fumar y hacer ejercicio.

    Luego viene el impacto: puede morir si sufre un ataque al corazón, y las causas desencadenantes pueden ser: vivir lejos del trabajo, que su cónyuge no sepa conducir, no tener cobertura de telefonía celular y que el hospital más cercano se encuentre a muchos kilómetros de distancia. Una vez más, las posibles medidas para reducir el impacto de los riesgos están ahí. Sin embargo, ¿cómo hacer frente a los riesgos no se puede documentar, porque documentarlos pone en riesgo al Administrador del Proyecto? El autor no tiene una respuesta a esto, y solo sugiere tener registros dobles, tal vez uno en la cabeza, para hacer frente a esos otros riesgos por debajo de la mesa. Y se sugiere compartir esos otros riesgos con el patrocinador, a menos que él sea el origen del riesgo. 

LA ADMINISTRACIÓN DE PROYECTOS ES UN NEGOCIO RIESGOSO, CONCLUYE.

HASTA AQUÍ EL ARTÍCULO ORIGINAL.

   Si bien comparto la idea general propuesta por el autor, creo que el Administrador tiene algunas una opciones: su línea de reporte y su bitácora personal. Es muy probable que el Administrador del Proyecto deba reportar su trabajo a alguien: la oficina de proyectos, el jefe inmediato, algún comité de pares. Este ente de reporte debe estar enterado cuando se presenta una situación como la descrita. De este modo, el Administrador cumple con su función de comunicar los riesgos en forma activa.

   En el caso más extremo, (cuando el Administrador de Proyecto solo le reporta al patrocinador que es el origen del riesgo), mi sugerencia es llevar una bitácora personal detallada en la que se detalle en qué fecha se reportó el riesgo y toda la información relevante al respecto. El objetivo es mantener la rastreabilidad y trazabilidad de las acciones emprendidas y conservar un registro de todos los detalles.

COMO ELABORAR LA MATRIZ DE RIESGOS DEL PROYECTO

      Los proyectos son esfuerzos complejos que implican un conjunto único de tareas y actividades realizadas tomando en cuenta una o más restricciones para cumplir los objetivos definidos. Una de las áreas clave que requieren una gestión pro activa en los proyectos es la gestión de riesgos, que surgen de las incertidumbres que pueden afectar el logro de los objetivos. Los riesgos pueden ser complejos, sobre todo por la amplia gama de orígenes y de posibles efectos sobre el proyecto.

     

      Sin embargo, el proceso de riesgo a menudo no produce nada más que una larga lista de riesgos, que puede ser difícil de entender o manejar. A esta lista se le puede organizar para determinar qué riesgos deben abordarse primero, pero esto no proporciona ninguna información sobre la estructura de la exposición al riesgo en un proyecto.

     

     Para organizar la información sobre la exposición al riesgo en un proyecto se usa la estructura de desglose de Riesgos (RBS).

     

    La combinación de la estructura de desglose del trabajo (WBS) y estructura de desglose riesgo (RBS), da lugar a la Matriz de Distribución de Riesgos (Risk Breakdown Matrix - RBM).

     El ejemplo anterior sirve para entender como se puede medir la concentración de riesgos dentro de la RBM usando una "puntuación de riesgo" a partir de la escala o el tamaño de los riesgos individuales. También es posible combinar diferentes niveles de la WBS y RBS en una estructura piramidal donde cada una de las capas son matrices RBM. Esto permite hacer diferentes análisis.

    Un RBS genérica puede parecer útil, pero es poco probable que incluya toda la gama de posibles riesgos para cada proyecto. Una alternativa es tener RBSs específicas para cada industria o para los tipos de proyectos llevadas a cabo por la organización. Una vez que se ha definido la RBS, esta puede ser utilizada de diferentes formas, en especial para facilitar el proceso de gestión de riesgos en un proyecto concreto.

    Para Hillson (2002b) los principales usos y beneficios de la RBS son los siguientes:

·      Ayuda en la identificación de riesgos - Los niveles superiores de la RBS se pueden utilizar como lista para garantizar la completa identificación de riesgos, mientras que los niveles más bajos puede ser usados como listas de verificación. Además, la RBS se puede utilizar para organizar listas de riesgos identificados por otros métodos.

·     Evaluación de riesgos - Los riesgos identificados se pueden mapear en el RBS categorizados por su origen. Esto ayuda a identificar las fuentes más importantes de riesgo para el proyecto, e indica las áreas de la dependencia o correlación entre los riesgos.

·   Comparación de alternativas - Los riesgos relacionados con las ofertas competidoras se pueden comparar directamente si el mismo RBS se utiliza para estructurar sus riesgos asociados. También puede ayudar a examinar opciones alternativas de desarrollo o de inversión.
·    Elaboración de informes de riesgo - Los diferentes interesados del proyecto necesitan diferentes niveles de información, y el RBS se puede usar para proveer de información sobre riesgos a la alta dirección, así como profundizar en el detalle que requiere el equipo del proyecto.

    A fin de comprender los muchos riesgos que enfrenta un proyecto, se debe hacer el análisis cualitativo y cuantitativo de los riesgos. Mientras que el análisis cuantitativo asigna un valor numérico al riesgo, el análisis cualitativo, por el contrario, indica la probabilidad y el impacto del riesgo en el proyecto en términos de gravedad y urgencia.

    La matriz de riesgo se utiliza cuando se analizan "cualitativamente" los riesgos. Se trata de un proceso de calificación de probabilidad de un riesgo en contra de su impacto. Se aplica a los riesgos individuales. Una muestra de una matriz de riesgo del proyecto se ilustra a continuación.

    La matriz de probabilidad e impacto se usa para resaltar de una sola vez el estado de los riesgos. Hay muchas maneras de expresar la relación de probabilidad y el impacto de los riesgos en un proyecto. La manera más popular, sin embargo, es la que la califica en Muy Alta, Alta, Media, Baja, y así sucesivamente.

    Los riesgos de mayor probabilidad y alto impacto requieren más atención, y por lo tanto, esta herramienta de evaluación de riesgo es más útil para los administradores de proyectos que tratan de reducir los riesgos. 

   Supongamos en el ejemplo anterior, que nueve riesgos individuales han sido identificados y están marcados con una escala de calificación de Alta, Media y Baja, tanto para la probabilidad e impacto.

Riesgo 1: Baja probabilidad y bajo impacto

Riesgo 2: Probabilidad media y bajo impacto

Riesgo 3: Alta probabilidad y bajo impacto

Riesgo 4: Baja probabilidad e impacto medio

Riesgo 5: Probabilidad media e impacto medio
Riesgo 6: Alta probabilidad e impacto medio

Riesgo 7: Baja probabilidad y alto impacto

Riesgo 8: Probabilidad media y alto impacto

Riesgo 9: Alta probabilidad y alto impacto

   Los riesgos con baja probabilidad y bajo impacto no suponen una gran amenaza para el proyecto. Pueden ser fácilmente manejados por el Administrador del Proyecto (y el equipo) y podrían requerir supervisión o monitoreo superficial. 

   A medida que el impacto del riesgo en un proyecto aumenta, se requerirán más tiempo, atención y gestión de riesgos detallada, no sólo por el equipo del proyecto, sino también por todos los involucrados. Un riesgo identificado con una alta probabilidad e impacto puede requerir fondos, tiempo y recursos adicionales para superarlo. Es un indicio de atención urgente necesaria.

   Cuando se ha asignado una puntuación de probabilidad a un riesgo, es fácil para todos los involucrados evaluar el daño podría plantear un riesgo a un proyecto, y esto se convierte en parte del informe de evaluación de riesgos. Cuanto mayor sea la puntuación de PI, más agresivo debe ser el enfoque de gestión de riesgos.

    Volviendo al artículo original, Glen nos recuerda que el cálculo de riesgo estándar es: 

    Riesgo = Probabilidad de Ocurrencia x Impacto

Pero, Glen considera que esta simple calculo no es la mejor manera de clasificar los riesgos, por varias razones: 

   Cada medida (probabilidad de ocurrencia y el impacto) es en realidad una distribución de probabilidad. El operador de multiplicación no está presente en las distribuciones de probabilidad, que son ecuaciones integrales Las mediciones deberían operarse a través de un proceso de convolución. (Glenn nos recuerda que escribir código para resolver una convolución se aprende en la mayoría de los cursos de física matemática y se puede hacer con una calculadora y se explica en este enlace).

   A partir de la bibliografía sugerida en el artículo de Glenn, podemos delinear un proceso para clasificar los riesgos:

1. A partir del conocimiento del dominio del proyecto, crear categorías de riesgos. Por ejemplo, la siguiente tabla presenta una tabla de riesgos relacionados con madurez tecnológica:

 2. Determine el grado de aceptación para cada riesgo en caso de que se presente

3. Asignar a cada celda en la matriz de riesgo de 5x5 un valor, según la clase de riesgos de la Tabla 2.

4. Ahora se debe dejar en manos de los expertos y su conocimiento del dominio del proyecto la asignación de colores ROJO,AMARILLO, VERDE y es las recomendaciones en cuanto a pruebas, y evaluaciones externas.

    Con este trabajo realizado por cada clase, que las actividades de riesgo individuales en el proyecto se pueden asignar a la matriz y descripciones específicas de los riesgos definidos.

   Con esta aproximación podríamos plantear una nueva versión de nuestra matriz de probabilidad e impacto.

    Esta nueva versión se aproxima más a las necesidades y capacidades de operación de la organización ejecutante del proyecto, comparada con la versión original que surge solo del planteamiento teórico.

5 SECRETOS DE LA GESTIÓN PROYECTOS

     Desde la página de Business 2 Community, Vanessa Fiorido  propone 5 secretos útiles de la administración de proyectos.

      Vanessa inicia recordando que la administración de proyectos es uno de los campos de los que mucha gente ha oído hablar, pero pocos están realmente familiarizados con él. De hecho, algunas personas pueden verlo como francamente intimidante  especialmente si se considera el tamaño y la complejidad de algunos de los proyectos que manejan: construcción, software, etc.

   Pero si bien es cierto que la administración de proyectos requiere conocimientos  especializados y procedimientos estrictos, también utiliza principios clave, poco conocidos, que todo el mundo puede utilizar, independientemente de su sector o industria.

1. Sin un objetivo (claro), no habrá éxito.

¿Cómo puedes saber si has alcanzado el éxito si no se ha definido qué es el éxito? 

Nota: Este es un tema recurrente en este blog. Entradas previas relacionadas se pueden leer aquí y aquí.

Mantener metas medibles y alcanzables es una gran manera de dar seguimiento al rendimiento mientras que se mejora la moral.

 2. El Administrador de Proyectos no tiene que saber todas las respuestas.

Este es uno de los mayores secretos del buen liderazgo. Los administradores de proyecto dirigir equipos de personas altamente talentosas y educadas, con conocimientos técnicos y experiencia más allá de la norma. Los administradores de proyecto no están ahí para lucirse, o ser una amenaza, o exponer su ignorancia. Están ahí para ampliar la base de conocimientos de sus clientes. Saber dónde obtener respuestas es tan importante como saber las propias respuestas.

3. Delegar, delegar, delegar.

Todo se reduce a esto: si alguien más puede hacer mejor una tarea, que la haga. No hay vergüenza en pedirle a alguien mas que se encargue del trabajo si esto se traducirá en un mejor entregable. Solo hay que dar crédito a quién se merece.

4. La comunicación resuelve la mayoría de los problemas.

No solo se debe ser capaz de resolver las diferencias, también hay que saber cómo obtener la información correcta de las personas adecuadas. Muchas tareas se ven dificultadas por la comunicación inadecuada o insuficiente, que la información no fluya correctamente a las personas que lo necesitan. 

5. No se trata de proyectos, se trata de personas.

Este es uno de los mayores secretos de la administración de proyectos. El conocimiento técnico y las certificaciones son importantes, pero también son secundarias. La administración de proyectos es la gestión de personas. Si usted ya está ayudando, empujando, y dirigiendo grupos de personas hacia un objetivo único, entonces felicitaciones: usted ya es un director de proyecto.

PMP – ¿Qué se entiende como proyecto?

       Bajo el término “proyecto”, se incluyen obras de infraestructura de diferente envergadura. Comprende una serie de definiciones y factores relacionadas con el proyecto:

1) Hay una multiplicidad de actores (positivos o negativos) en la implementación y en el resultado del proyecto: clientes, miembros del equipo, etc.

2) Hace falta una serie de actividades y tareas interrelacionadas  para cumplir con los requerimientos definidos al inicio del proyecto.

3) Un proyecto  necesita un presupuesto económico y financiero limitado que tener en cuenta.

4) La utilización de recursos humanos y materiales.

5) Un Project Manager o Gerente del Proyecto que será el líder del equipo y de las relaciones con los stakeholders y coordinará los esfuerzos a lo largo de todas las etapas.

        Teniendo estos puntos en cuenta, hay que entender como ayuda el Project Manager a llevar a cabo un proyecto. En definitiva y como ya hemos comentado en artículos anteriores, el PMP ayuda a llevar a cabo proyectos mediante la gestión del tiempo y los recursos humanos y económicos, superando una serie de objetivos con una calidad adecuada. Minimiza la cantidad de intermediarios con la existencia del Project Manager que centraliza todas las decisiones y gestiones del proyecto. El organizador de proyectos divide el proyecto en fases y coordina las capacidades de los miembros del grupo para maximizar su eficiencia, teniendo en cuenta posibles sinergias y aumentando la motivación del grupo.

El PMBOK^® GUIDE   

      

        Es un estándar en la Administración de proyectos desarrollado por el Project Management Institute (PMI). La misma comprende dos grandes secciones, la primera sobre los procesos y contextos de un proyecto, la segunda sobre las áreas de conocimiento específico para la gestión de un proyecto.

       En 1987, el PMI publicó la primera edición del PMBOK^®GUIDE es un intento por documentar y estandarizar información y prácticas generalmente aceptadas en la gestión de proyectos. La edición actual, la cuarta, provee de referencias básicas a cualquiera que esté interesado en la gestión de proyectos. Posee un léxico común y una estructura consistente para el campo de la gestión de proyectos. El PMBOK^® GUIDE se encuentra disponible en 11 idiomas: inglés, español, chino simplificado, ruso, coreano, japonés, italiano, alemán, francés, portugués de Brasil y árabe.

PMBOK® GUIDE

     El PMBOK ^®  GUIDE una colección de procesos y áreas de conocimiento generalmente aceptadas como las mejores prácticas dentro de la gestión de proyectos. El PMBOK ^®  GUIDE es un estándar reconocido internacionalmente (IEEE Std 1490-2003) que provee los fundamentos de la gestión de proyectos que son aplicables a un amplio rango de proyectos, incluyendo construcción, software, ingeniería, etc.

    El PMBOK ^®  GUIDE reconoce 5 grupos de procesos básicos y 10 áreas de conocimiento comunes a casi todos los proyectos. Los procesos se traslapan e interactúan a través de un proyecto o fase y son descritos en términos de:

• Entradas (documentos, planes, diseños, etc.)
• Herramientas y Técnicas (mecanismos aplicados a las entradas)
• Salidas (documentos, productos, etc.).

Grupos Básicos de Procesos 

     Los 5 grupos básicos de procesos son:

• Iniciación: Define y autoriza el proyecto o una fase del mismo. Está formado por dos procesos.
• Planificación: Define, refina los objetivos y planifica el curso de acción requerido para lograr los objetivos y el alcance pretendido del proyecto. Está formado por veinte procesos.
•  Ejecución: Compuesto por aquellos procesos realizados para completar el trabajo definido en el plan a fin de cumplir con las especificaciones del mismo. Implica coordinar personas y recursos, así como integrar y realizar actividades del proyecto en conformidad con el plan para la dirección del proyecto. Está formado por ocho procesos.
•  Seguimiento y Control: Mide, supervisa y regula el progreso y desempeño del proyecto, para identificar áreas en las que el plan requiera cambios. Está formado por diez procesos.
•  Cierre: Formaliza la aceptación del producto, servicio o resultado, y termina ordenadamente el proyecto o una fase del mismo. Está formado por dos procesos.

Áreas de Conocimiento

     Las 10 áreas del conocimiento mencionadas en el PMBOK ^®  GUIDE son:

1. Gestión de la Integración del Proyecto:

Incluye los procesos y actividades necesarios para identificar, definir, combinar, unificar y coordinar los diversos procesos y actividades de la dirección de proyectos dentro de los grupos de procesos de dirección de proyectos.

2. Gestión del Alcance del Proyecto:

Incluye los procesos necesarios para garantizar que el proyecto incluya todo (y únicamente todo) el trabajo requerido para completarla con éxito.

3. Gestión del Tiempo del Proyecto:

Incluye los procesos requeridos para administrar la finalización del proyecto a tiempo.

4. Gestión de los Costos del Proyecto:

Incluye los procesos involucrados en estimar, presupuestar y controlar los costos de modo que se complete el proyecto dentro del presupuesto aprobado.

5. Gestión de la Calidad del Proyecto:

Incluye los procesos y actividades de la organización ejecutante que determinan responsabilidades, objetivos y políticas de calidad a fin de que el proyecto satisfaga las necesidades por la cuales fue emprendido.

6. Gestión de los Recursos Humanos del Proyecto:

Incluye los procesos que organizan, gestionan y conducen el equipo del proyecto.

7. Gestión de las Comunicaciones del Proyecto:

Incluye los procesos requeridos para garantizar que la generación, la recopilación, la distribución, el almacenamiento, la recuperación y la disposición final de la información del proyecto sean adecuados, oportunos y entregada a quien corresponda (interesados del proyecto o stakeholders).

8. Gestión de los Riesgos del Proyecto:

Incluye los procesos relacionados con llevar a cabo la planificación de la gestión, identificación, el análisis, la planificación de respuesta a los riesgos, así como su monitoreo y control en un proyecto.

9. Gestión de las Adquisiciones del Proyecto:

Incluye los procesos de compra o adquisición de los productos, servicios o resultados que es necesario obtener fuera del equipo del proyecto.

10. Gestión de Interesados del Proyecto:

Incluye los procesos relacionados con la identificación, analisis y manejo proactivo de los interesados