INTERPRETATION AND ANALYSIS OF THE FLOW CHART OF THE process "SEQUENCING OF THE PROJECT ACTIVITIES

 

INTRODUCTION

 

The purpose of this work is to describe in detail the Inputs, Tools and Techniques, and Outputs of the process 6.3 Sequence Project Activities, as part of the Area of Knowledge "Project Time Management" of the PMBOK, indicating in a reasoned way, the best use of all its elements and the importance of its application for the procurement of the final product of this section.

 

In the same way as with the previous process, a critical analysis of the exposed descriptions of this process and the respective conclusions on its relevance for the development of the Knowledge Area "Project Time Management" and the project in general are presented.

Process Description 6.3: Sequence Project Activities

Process definition

Sequencing Activities is the process of identifying and documenting the relationships between project activities. The sequence of activities is established through logical relationships. Each activity and milestone, except from the first and last, connects with at least one predecessor and one successor in a way that forms a network of activities. The sequence can be established using a project management software or using the classical manual techniques for PERT-CPM or other preceding diagramming method. The final product of this process is a network of related activities.

Process Flow Diagram 6.3 Sequencing Activities

Sequence Activities: Inputs

1.       List of Activities, coming out of the process 6.2 Define the Activities.             

2.       Attributes of the Activity: from the process output 6.2 Define the Activities             

3.       List of Milestones: from the process output 6.2 Define Activities.

4.       Project Scope Statement: The project scope statement comes as an output from the process 5.3 Define Scope and contains the description of the product scope, which includes the characteristics of the product, an aspect that may affect the establishment of the sequence of the activities, in addition to scope restrictions and assumptions.             

5.       Process Assets of the Organization: Among the assets of the organization processes that can influence the process 6.3 Sequencing activities, project files are located s from the base of knowledge of the company, used in the planning methodology.             

Sequence Activities: Tools and Techniques

1. Precedence Diagramming Method (PDM)             

The Precedence Diagramming Method (PDM) is one of the network programming techniques used by the Critical Path Method (CPM). To create the project schedule network, the activities are represented in boxes or rectangles, which contain the information of each activity. Each activity is contained in a rectangle and the relationships between the activities are represented by lines with arrows showing the logical relationships. To determine the sequencing of activities, there are four types of logical relationships or possible dependencies between two activities, which are listed below:

a.         Finish - Start (FS). The start of the successor activity depends on the completion of the predecessor activity.

b.         Finish - Finish (FF). The completion of the successor activity depends on the completion of the predecessor activity.

c.          Start - Start (SS). The start of the successor activity depends on the start of the predecessor activity.

d.         Start - Finish (SF). The completion of the successor activity depends on the start of the predecessor activity.

2. Determination of Dependencies             

              To define the sequence between activities, three types of dependencies are used:

a.         Mandatory dependencies. Mandatory dependencies are those required by contract conditions, or inherent to the nature of the work. The project team determines which dependencies are required during the activity sequencing process. Sometimes the term "hard logic" is used to refer to required dependencies.

b.         Discretionary dependencies. They are dependencies determined by the project team based on the knowledge of best practices within a given application area. They are known as preferred logic, preferential logic, or soft logic. It is a sequencing adapted to the needs and convenience of the project, where experience and Expert Judgment intervene.

c.          External dependencies. They are dependencies that are beyond the control of the entity or organization that executes the work.

3. Application of Advances and Delays             

Leads and Lags are periods of time that may be necessary to locate in the dependency relationship between two activities in order to adjust the condition of the network to be viable and closer to reality. The need to place an Advance or Delay in the relationship between two activities is established by the nature of the work that is carried out.

4. Network Schedule Templates             

They are standard templates of the project schedule network diagram and can cover all or part of the schedule. They are especially useful when the activities in the work packages of various project deliverables are similar. They considerably speed up the development of the network.

Sequence Activities: Outputs

1. Network Diagrams of the Project Schedule             

The project schedule network diagram is a schematic representation of the project schedule activities and their logical relationships, which is determined using the tools and techniques of this process. Developing the network diagram of the project schedule can be done manually or by using a project management software, as mentioned before. For every activity of this diagram must be determined the duration and the correspondent resources to form the final schedule of the project.

2. Updates to Project Documents             

              Project documents that can be updated include, but are not limited to:

a.               the activity lists

b.               the activity attributes

c.               the risk register

 

Critical Analysis Process 6. 3 Sequencing Project Activities

Inputs

The Flow Diagram of the process indicates that the main inputs for this process are the outputs of the process 6.2 Define Activities, to the point that it can be pointed out that process 6.3 cannot be started if process 6.2 has not been completed, which sounds obvious. The Project Scope Statement from process 5.3 Define Scope should have been developed well before process 6.2. The Environmental Factors of the Company are not mentioned among the entries, among which the information system of the project should be highlighted.

Tools and Techniques

Several aspects should be mentioned here. In the first place, the types of dependencies are those indicated in point 1, that is, Finish-Start, Finish-Finish, Start-Start and Start-Finish and not what is indicated in point 2. This seems to be confusing, because it is indicated in paragraph 2 that mandatory dependencies are discretionary and external types of dependencies, when they really are aspects that influence the establishment of the dependencies. On the other hand, in my opinion, the Expert Judgment and the database of lessons learned should be tools present in this process and yet they are not mentioned.

Outputs

The practically unique final product of this process is the Precedence Network Diagram, an essential element for the final development of the schedule. Little emphasis is placed on the use of computer tools such as the project management software, to obtain the network. Currently, it is essential, mainly in the case of very large projects, to have these tools to develop the network and the schedule. The manual procedure can be largely a time-consuming one. 

INTERPRETATION AND ANALYSIS OF THE FLOW CHART OF THE process "DEFINITION OF THE PROJECT ACTIVITIES"

 

INTRODUCTION

 

The purpose of this work is to describe in detail the Inputs, Tools and Techniques, and Outputs of the process 6.2 Define Project Activities, that corresponds to the Area of Knowledge "Project Time Management" of the PMBOK, indicating in a reasoned way, the best use of all its elements.

Likewise, a critical analysis of the exposed descriptions of the process and the respective conclusions on its relevance for the development of the Knowledge Area "Project Time Management" and the project in general are presented.

 

Process Description 6.2: Define Project activities

Process definition

Defining the Activities is the process that consists of identifying the specific actions to be carried out to prepare the project deliverables. The actions to be developed are represented as activities, meaning as activity every part of the work to be done in the course of a project. The 5.4 Create the WBS process identifies the deliverables at the lowest level of the work breakdown structure (WBS), called work packages. From the work packages originates the decomposition into smaller components called activities; The set of activities that are obtained from the decomposition of a work package, represent all the actions that must be carried out to complete the respective work package. The activities provide the basis for estimating, planning, executing, monitoring and controlling the project work in all other knowledge areas.

Process Flow Diagram 6.2 Define Activities

 

Define the Activities of the Project: Inputs

1.    Scope Baseline: The Scope Baseline comes from process 5.4 Create the WBS. It is one of the components of the Management Plan of the Project, and it is comprised of the following elements:

·         Project Scope Statement

·         The WBS (Work Breakdown Structure)

·         The EDT Dictionary

This document is very important in defining activities, since it is from the level of breakdown into work packages that activities can be identified.

2.  Environmental Factors of the Company: Among the environmental factors of the company that can influence the process 6.2 Define the Activities, is the project management information system or the project management software used by the company or organization to manage projects (e.g .: MS-Project).             

3.  Organizational Process Assets: Organizational process assets that can influence the process 6.2 Define Activities include, but are not limited to:             

·         Existing policies, procedures and guidelines, whether formal or informal, related to the planning of activities.

·         The knowledge base of lessons learned.

·    These two aspects refer, in the first place, to regulations or internal procedures of the organization commonly used in the planning of project activities. Some companies have them, others not. Secondly, the knowledge base of lessons learned relate to a historical background from previous projects developed by the organization. This information is important for process 6.2, since the historical files have detailed information on similar works successfully completed, so this experience facilitates the identification of the elements and activities of a new project.

4.    Process 6.1 Plan Schedule Management. This process included in PMBOK v.5 is considered now a previous step for the definition of activities and all subsequent processes. The key input from the schedule management plan is the prescribed level of detail needed to manage the work of the whole project.

Define Project Activities: Tools and Techniques

1.    Decomposition: The decomposition technique, as applied to define activities, consists of subdividing the project work packages into smaller and easier-to-manage components, called activities.             

2.    Gradual Planning: Gradual planning is a form of gradual elaboration planning, where work to be developed in the short term is planned in detail and future work is planned at a higher level of the WBS. It is about progressive planning.             

3. Templates: A template is a list of standard activities or part of a project listed above, which can be used as reference to develop the list of activities of a new project.             

4.    Expert Judgment: Members of the project team or other experts with experience and skills in developing detailed project scope statements, WBS, and project schedules, can contribute with their expertise to define activities.             

Define Project Activities: Outputs

1. List of Activities: It is the main output of the process and consists of an exhaustive list that includes all the activities of the schedule of the different work packages, necessary for the execution of the project. The activity list includes the activity identifier and a description of the scope of work for each activity.
2. Activity Attributes: Activity attributes expand the definition of the activity, and include: the activity identifier, the WBS identifier and the activity name, the activity codes, the activity description, predecessor activities, successor activities, logical relationships, leads and lags, resource requirements, imposed dates, constraints, and assumptions. Durations, costs and resources are determined in other processes.
3. Milestones List: A milestone is a significant point or event within the project. Unlike an activity, it does not consume resources or has no duration. Milestones can be required or optional, such as those based on historical information.

 My own analysis of the process 6.2 Define Activities

Inputs

The Process Flow Diagram indicates that the main input, without which this process cannot be developed, is the Scope Baseline, represented by the WBS obtained from 5.4 Create the WBS. The remaining input elements may or may not exist.

Tools and Techniques

With regard to Tools and Techniques, the ideal is to apply “a little bit of everything”; but both the decomposition technique and the gradual planning technique require a high component of Expert Judgment. The previous experience in projects, of people belonging to the project team or interested parties with high technical expertise, is decisive for obtaining quality outputs from this process. Finally, by way of observation, it is worth mentioning that the PMBOK v.5 indicates in paragraph 6.2.2.1 Decomposition, that the WBS and the List of Activities can be developed simultaneously. If this is the case, the WBS is subject to be modified, so there must be an exit from the 6.2 process in the form of Updating the Project Documents that represents the update / modification of the WBS.

Outputs

In my opinion, the three first outputs of the process could be included in a single list called "List of Activities and Milestones". The attributes are inherent to the activities, so that I find it unmeaningful to generate two lists, one with activities and one with attributes, which can even have repeated elements. Milestones can be presented separately in another list or included in the activity list with a special identification. In the definitive list of activities in the schedule, milestones are recognized as having zero duration “0” and the project planning software identifies them in a special way. All the outputs of this process are inputs of other processes of the same Knowledge Area (Project Time Management) 

ESQUEMA GENERAL DEL PROCESO 4.5 : REALIZAR EL CONTROL INTEGRADO DE CAMBIOS

VIDEO SOBRE LA ÉTICA EMPRESARIAL

LA ÉTICA EMPRESARIAL - CASO GOOGLE

Video demostrativo de la importancia de conservar y aplicar la ética en el ámbito de la empresa y el trabajo 

GESTIÓN DE RIESGOS - RESUMEN

Descripción del Área de Conocimiento Gestión de Riesgos (Sección 11)

El área de conocimiento identificada en la sección No. 11 del PMBOK v.4 incluye los procesos relacionados con los riesgos de un proyecto, y abarca los siguientes aspectos:

·         Identificación

·         Planificación de la gestión

·         Análisis

·         Planificación de las respuestas

·         Seguimiento y  control

El objetivo principal de esta sección es incrementar la probabilidad de ocurrencia de los impactos positivos sobre el proyecto y minimizar aquellos impactos negativos.

Los procesos que forman parte de esta área de conocimiento son los siguientes:

·         11.1 Planificar la Gestión de Riesgos

·         11.2 Identificar los Riesgos

·         11.3 Realizar el Análisis Cualitativo de Riesgos

·         11.4 Realizar el Análisis Cuantitativo de Riesgos

·         11.5 Planificar la Respuesta a los Riesgos

·         11.6 Monitorear y Controlar los Riesgos

Estos procesos, al igual que todos los procesos de las otras áreas de conocimiento tienen las siguientes características:

·         Interactúan entre sí y con los procesos de las demás áreas de conocimiento

·    Conlleva el esfuerzo  de una o más personas dependiendo de la naturaleza del proyecto.

·         Cada proceso se ejecuta  al menos una vez en cada proyecto o fase de proyecto en el caso  de que aplique la división en fases.

·         Aunque estos procesos se presentan bien diferenciados con interfaces definidas, en la práctica se superponen e interactúan.

Definición de Riesgo

Se entiende por riesgo la probabilidad de ocurrencia de un evento o situación que puede ocasionar daño o perjuicio al proyecto y afectar el logro de los objetivos del mismo. Un riesgo puede tener una o más causas y si sucede, puede tener uno o más impactos.  Una causa puede ser un requisito, un supuesto, una restricción o condición que genera la posibilidad de consecuencias positivas o negativas. Las consecuencias introducen incertidumbre, al existir siempre dos o más posibilidades de ocurrencia, algunas positivas y otras negativas. En el caso de un requisito del proyecto, este puede ser un permiso ambiental otorgado por el ente regulador en materia ambiental, sin cuyo otorgamiento una parte o la totalidad del proyecto no se pueden iniciar. La consecuencia está relacionada al tiempo de otorgamiento: si este es menor que el previsto, se traduce en beneficio para el proyecto; ahora, si se extiende por espacio de un largo período, el proyecto sale perjudicado, resultando impactado los objetivos de tiempo y costo.

Los riesgos presentan las siguientes características comunes:

·         Debe existir un evento o causa que lo genera

·         Debe existir una probabilidad de ocurrencia del evento

·         Deben existir unas consecuencias en caso de ocurrencia

·         Debe existir impacto sobre los objetivos en caso de ocurrencia

Los riesgos se ubican siempre en el futuro. El  director del proyecto y su equipo de gestión deben ser capaces de identificar y gestionar los riesgos del proyecto. No se puede dejar al libre albedrío la ocurrencia de situaciones o eventos de riesgo y amenaza que pueden impactar adversamente sobre los objetivos del proyecto y sobre la organización en general. Las soluciones o respuestas a los riesgos, una vez ocurridos estos, nunca tendrán el mismo efecto si se aplican de forma planificada que improvisada.

Los riesgos del proyecto tienen su origen en la incertidumbre que está presente en todos los proyectos. Los riesgos conocidos son aquéllos que han sido identificados y analizados, lo que hace posible planificar respuestas para tales riesgos. Los riesgos desconocidos no pueden gestionarse de manera proactiva, lo que sugiere que el equipo del proyecto debe crear un plan de contingencia. Un riesgo del proyecto, que ha ocurrido, también puede considerarse un problema.

Las organizaciones e interesados del proyecto, usualmente manejan los riesgos dentro de unos márgenes de tolerancia. Si un riesgo representa  una amenaza para el proyecto, este puede aceptarse si el mismo se mantiene dentro de un rango de tolerancia establecido por la organización, sobre todo si existe un beneficio que equilibra las consecuencias del riesgo.

La identificación y posterior gestión de los riesgos conlleva la aplicación de medidas de mitigación. Si los riesgos no son correctamente identificados, las medidas serán planificadas y aplicadas de manera errónea trayendo como consecuencia que el mismo no será mitigado con las consecuencias posteriores de sobrecostos y extensión de plazos.

Conclusión

La importancia de gestionar o gerenciar los riesgos del proyecto radica en que en todo proyecto van a existir factores que atentan contra la buena marcha del proyecto entendiendo que toda situación o circunstancia, interna o externa que afecte al proyecto y que no pueda ser prevista o controlada por el equipo del proyecto ni por la organización, es un causal de riesgo potencial y la organización debe identificar, registrar, jerarquizar, planificar y controlar todos estos factores. No hacerlo es como conducir totalmente a ciegas por un camino con obstáculos, y las consecuencias pueden llegar a ser desastrosas para el proyecto. Es responsabilidad del director del proyecto y su equipo, llevar la acción de la gestión de riesgos y hacerle seguimiento permanente a  los factores causales, a fin de minimizar los impactos negativos.

RESUMEN INDICADORES E INDICES VALOR GANADO

INDICADORES DE GESTIÓN

ANÁLISIS DEL VALOR GANADO (EVM)

RESUMEN DE INDICADORES E ÍNDICES

(Seguir el vínculo anterior para ver tabla - follow the previous link)

IDENTIFICAR LOS RIESGOS

Descripción del Proceso 11.2: Identificar los Riesgos

Definición del Proceso

El proceso 11.2 del área de conocimiento Gestión de los Riesgos del Proyecto, es el proceso mediante el cual se determinan los riesgos que pueden afectar al proyecto y se documentan sus características. Para la identificación  de los riesgos es necesario realizar reuniones frecuentes entre los miembros del equipo del proyecto, así como entrevistas con interesados claves del proyecto, de manera de disponer de un amplio espectro de opiniones para no dejar por fuera ningún riesgo potencial.

Aspectos destacados del Proceso 11.2 Identificar los Riesgos

La identificación de riesgos es un proceso iterativo debido a que permanentemente se pueden descubrir nuevos riesgos o los existentes o ya identificados, pueden evolucionar a medida que el proyecto avanza. A continuación algunos aspectos relativos al mismo:

• Los riesgos del proyecto se enfocan sobre los objetivos de alcance, tiempo y costo
• Para la identificación de riesgos es recomendable que participe el mayor número de personas involucradas con el proyecto
• La revisión y actualización del proceso debe ser permanente.
• El formato utilizado para identificar los riesgos  debe permitir visualizar comparativamente el efecto relativo de un evento de riesgo con otros eventos
• El proceso debe promover un  sentido de pertenencia y responsabilidad sobre los riesgos y sobre las acciones de respuesta asociadas 

El proceso de planificación de la gestión de riesgos hace uso o requiere como entrada el plan de gestión de proyecto, tomando del mismo el apartado de plan de gestión de alcance, tiempo y costos.

A continuación se presenta los componentes de este proceso y el flujograma de mismo.

                                                                      

   

    

Diagrama de Flujo del Proceso 11.2 Identificar los Riesgos

Identificar los Riesgos: Entradas

Las Entradas del proceso 11.2 son 11, las cuales se enumeran a continuación en la siguiente tabla:

Entrada	Origen/Procedencia	Descripción
1.     Plan de Gestión de Riesgos	Proceso 11.1 Planificar la Gestión de Riesgos	Las entradas clave del plan de gestión de riesgos al proceso Identificar los Riesgos son las asignaciones de roles y responsabilidades, la provisión para las actividades de gestión de riesgos en el presupuesto y en el cronograma, y las categorías de riesgo, que a veces se expresan como una Estructura de Desglose del Riesgo
2.     Estimación de Costos de las Actividades	Proceso 7.1 Estimar los Costos de las Actividades	Las revisiones de la estimación de los costos de las actividades son útiles para identificar los riesgos, ya que proporcionan una evaluación cuantitativa del costo probable para completar las actividades del cronograma, e idealmente están expresadas como un rango cuya amplitud indica el o los grados de riesgo. La revisión puede dar como resultado proyecciones que indiquen si la estimación es suficiente para completar la actividad, o es insuficiente, en cuyo caso podría representar un riesgo para el proyecto.
3.     Estimación de la Duración de las Actividades	Proceso 6.4 Estimar las Duraciones de las Actividades	Las revisiones de los estimados de la duración de las actividades son útiles para identificar los riesgos relacionados con los tiempos asignados para la realización de las actividades o de todo el proyecto; la amplitud de rango de dichos estimados también indica en este caso el o los grados relativos de riesgo.
4.     Línea Base del Alcance	Proceso 5.3 Crear la EDT	Los supuestos del proyecto se encuentran en el enunciado del alcance del proyecto. La incertidumbre a nivel de los supuestos del proyecto debe evaluarse como causas potenciales de riesgo. La EDT es una entrada crítica para la identificación de riesgos ya que facilita la comprensión de los riesgos potenciales tanto a nivel micro como macro. Los riesgos pueden identificarse y luego rastrearse a nivel de resumen, de cuenta de control y/o de paquete de trabajo. La EDT es una entrada crítica para la identificación de riesgos ya que facilita la comprensión de los riesgos potenciales tanto a nivel micro como macro. Los riesgos pueden identificarse y luego rastrearse a nivel de resumen, de cuenta de control y/o de paquete de trabajo.
5.     Registro de Interesados	Proceso 10.1 Identificar los Interesados	La información acerca de los interesados será útil para solicitar entradas para la identificación de riesgos, ya que esto asegurará que los interesados clave, especialmente el cliente, sean entrevistados o participen de otra manera durante el proceso Identificar los Riesgos.
6.     Plan de Gestión de Costos	AC Gestión de los Costos del Proyecto	El proceso Identificar los Riesgos requiere la comprensión del plan de gestión de costos que forma parte del plan para la dirección del proyecto (AC 7.0). Por su naturaleza o estructura, el enfoque específico de la gestión de costos del proyecto puede generar riesgos o moderarlos.
7.     Plan de Gestión del Cronograma	AC Gestión del Tiempo del Proyecto	El proceso Identificar los Riesgos también requiere la comprensión del plan de gestión del cronograma que forma parte del plan para la dirección del proyecto (AC 6.0). Por su naturaleza o estructura, el enfoque específico de la gestión del cronograma del proyecto puede generar riesgos o moderarlos.
8.     Plan de Gestión de la Calidad	Proceso 8.1 Planificar la Calidad	El proceso Identificar los Riesgos también requiere la comprensión del plan de gestión de calidad que forma parte del plan para la dirección del proyecto. Por su naturaleza o estructura, el enfoque específico de la gestión de la calidad del proyecto puede generar riesgos o moderarlos.
9.     Documentos del Proyecto	Documentos del Proyecto	Los documentos del proyecto incluyen, entre otros: ·       el registro de supuestos ·       los informes de desempeño del trabajo ·       los informes sobre el valor ganado ·       los diagramas de red ·       las líneas base ·       otra información del proyecto que resulte valiosa para la identificación de riesgos
10.   Factores Ambientales de la Empresa	Empresa/Organización	Los factores ambientales de la empresa que pueden influir en el proceso Identificar los Riesgos incluyen, entre otros: ·       la información publicada, incluidas las bases de datos comerciales ·       las investigaciones académicas ·       las listas de control publicadas ·       los estudios comparativos ·       los estudios industriales ·       las actitudes frente al riesgo
11.   Activos de los Procesos de la Organización	Empresa/Organización	Los activos de los procesos de la organización que pueden influir en el proceso Identificar los Riesgos incluyen, entre otros: ·       los archivos del proyecto, incluidos los datos reales ·       los controles de los procesos de la organización y del proyecto ·       las plantillas de declaración de riesgos ·       las lecciones aprendidas

Identificar los Riesgos: Herramientas y Técnicas

La siguiente tabla presenta de forma resumida las herramientas y técnicas que pueden ser aplicadas para el desarrollo de este proceso, solo una en este caso:

Herramienta / Técnica	Descripción
1.     Revisiones de la Documentación	Puede efectuarse una revisión estructurada de la documentación del proyecto, incluyendo los planes, los supuestos, los archivos de proyectos anteriores, los contratos y otra información. La calidad de los planes, así como la consistencia entre dichos planes y los requisitos y supuestos del proyecto, pueden ser indicadores de riesgo en el proyecto.
2.     Técnicas de Recopilación de Información	Algunos ejemplos de técnicas de recopilación de información utilizadas en la identificación de riesgos son: ·       Tormenta de ideas. La meta de la tormenta de ideas es obtener una lista completa de los riesgos del proyecto. Por lo general, el equipo del proyecto efectúa tormentas de ideas, a menudo con un grupo multidisciplinario de expertos que no forman parte del equipo. Bajo el liderazgo de un facilitador, se generan ideas acerca de los riesgos del proyecto, ya sea por medio de una sesión tradicional y abierta de tormenta de ideas, con ideas que aportan los participantes, o en una sesión estructurada donde se utilizan técnicas de entrevista masiva, tales como las técnicas de grupo nominal. Como marco de referencia, pueden utilizarse categorías de riesgo, tales como una Estructura de Desglose de Riesgos. Luego, los riesgos son identificados y categorizados según su tipo, y sus definiciones son refinadas. ·       Técnica Delphi. La técnica Delphi es una manera de lograr un consenso de expertos. Los expertos en riesgos del proyecto participan en esta técnica de forma anónima. Un facilitador utiliza un cuestionario para solicitar ideas acerca de los riesgos importantes del proyecto. Las respuestas son resumidas y luego enviadas nuevamente a los expertos para que realicen comentarios adicionales. En pocas rondas, mediante este proceso se puede lograr el consenso. La técnica Delphi ayuda a reducir la distorsión en los datos y evita que cualquier persona ejerza influencias inapropiadas en el resultado. ·       Entrevistas. La realización de entrevistas a los participantes experimentados del proyecto, a los interesados y a los expertos en la materia puede ayudar a identificar los riesgos. ·       Análisis causal. El análisis causal es una técnica específica para identificar un problema, determinar las causas subyacentes que lo ocasionan y desarrollar acciones preventivas.
3.     Análisis de la Lista de Control	Las listas de control para identificación de riesgos pueden desarrollarse basándose en la información histórica y el conocimiento acumulado a partir de proyectos similares anteriores y otras fuentes de información. También puede utilizarse como lista de control de riesgos el nivel más bajo de la estructura de desglose de riesgos. Si bien una lista de control puede ser rápida y sencilla, es imposible elaborar una lista exhaustiva. El equipo debe asegurarse de explorar elementos que no aparecen en la lista de control. La lista de control debe revisarse durante el cierre del proyecto para incorporar nuevas lecciones aprendidas y mejorarla para su utilización en proyectos futuros.
4.     Análisis de Supuestos	Cada proyecto y cada riesgo identificado se conciben y desarrollan tomando como base un grupo de hipótesis, escenarios y supuestos. Este análisis explora la validez de los supuestos según se aplican al proyecto. Identifica los riesgos del proyecto debidos al carácter inexacto, inestable, incoherente o incompleto de los supuestos.
5.     Técnicas de Diagramación	Las técnicas de diagramación de riesgos pueden incluir: ·       Diagramas de causa y efecto. Estos diagramas también se conocen como diagramas de Ishikawa o diagramas de espina de pescado y son útiles para identificar las causas de los riesgos. ·       Diagramas de flujo o de sistemas. Estos diagramas muestran cómo se interrelacionan los diferentes elementos de un sistema, y el mecanismo de causalidad. ·       Diagramas de influencias. Estos diagramas son representaciones gráficas de situaciones que muestran las influencias causales, la cronología de eventos y otras relaciones entre las variables y los resultados.
6.     Análisis DAFO	Esta técnica examina el proyecto desde cada uno de los aspectos DAFO (debilidades, amenazas, fortalezas y oportunidades) para aumentar el espectro de riesgos identificados, incluyendo los riesgos generados internamente. La técnica comienza mediante la identificación de las fortalezas y debilidades de la organización, enfocándose ya sea en la organización del proyecto o bien en aspectos comerciales en un sentido más amplio. A menudo, estos factores se identifican utilizando la tormenta de ideas. El análisis DAFO identifica entonces cualquier oportunidad y amenaza para el proyecto, procedentes respectivamente de las fortalezas y debilidades de la organización. El análisis DAFO también examina el grado en el que las fortalezas de la organización contrarrestan las amenazas, y las oportunidades que pueden servir para superar las debilidades.
7.     Juicio de Expertos	Los expertos con experiencia apropiada, adquirida en proyectos o áreas de negocio similares, pueden identificar los riesgos directamente. El director del proyecto debe identificar a dichos expertos e invitarlos a considerar todos los aspectos del proyecto, y a sugerir los posibles riesgos basándose en sus experiencias previas y en sus áreas de especialización. Deben tenerse en cuenta los prejuicios de los expertos en este proceso.

Identificar los Riesgos: Salidas

La siguiente tabla muestra la descripción de las salidas que se generan del proceso 11.2

Salida	Descripción	Entrada al Proceso
1.     Registro de Riesgos	Las salidas principales del proceso Identificar los Riesgos son las entradas iniciales al registro de riesgos. El registro de riesgos contiene al final los resultados de los demás procesos de gestión de riesgos a medida que se llevan a cabo, dando como resultado un incremento en el nivel y tipo de información contenida en el registro de riesgos conforme transcurre el tiempo. La preparación del registro de riesgos comienza en el proceso Identificar los Riesgos con la siguiente información, y luego queda a disposición para otros procesos de la dirección de proyectos y de Gestión de los Riesgos del Proyecto. ·     Lista de riesgos identificados. Los riesgos identificados se describen con un nivel de detalle razonable. Puede aplicarse una estructura sencilla para los riesgos de la lista, tal como: un EVENTO puede ocurrir, causando un IMPACTO, o Si tal CAUSA, un EVENTO puede ocurrir, provocando un EFECTO. Además de la lista de riesgos identificados, las causas de esos riesgos pueden volverse más evidentes. Se trata de condiciones o eventos fundamentales que pueden dar lugar a uno o más riesgos identificados. Deben registrarse y utilizarse para apoyar la identificación futura de riesgos tanto para el proyecto en cuestión como para otros proyectos. ·     Lista de respuestas potenciales. A veces pueden identificarse respuestas potenciales a un riesgo durante el proceso Identificar los Riesgos. Estas respuestas, si se identifican durante este proceso, pueden ser útiles como entradas para el proceso Planificar la Respuesta a los Riesgos.	Proceso 7.1 Estimar los Costos Proceso 8.1 Planificar la Calidad Proceso 12.1 Planificar la Adquisiciones Proceso 11.3 Realizar el Análisis Cualitativo de Riesgos Proceso 11.4 Realizar el Análisis Cuantitativo de Riesgos Proceso 11.5 Planificar la Respuesta a los Riesgos Proceso 11.6 Monitorear y Controlar los Riesgos