Una guía al cuerpo de conocimientos de la Administración de Proyectos (página 5)

Enviado por rsanchez

Partes: 1, 2, 3, 4, 5, 6, 7

La aseguranza puede ser proveída al equipo administrativo del proyecto y a la administración de la organización ejecutora (aseguranza interna de calidad) o puede ser proveída al cliente y a otros que no están activamente involucrados en el trabajo del proyecto (aseguranza externa de calidad).

8.2.1 Entradas a la Aseguranza de la Calidad

Plan de administración de la calidad. El plan de administración de la calidad se describe en la Sección 8.1.3.1.
Resultados de las mediciones del control de calidad. Las mediciones del control de calidad son datos de ensayos de control y mediciones en un formato para su comparación y análisis.
Definiciones operacionales. Las definiciones operacionales se describen en la Sección 8.1.3.2.

Herramientas y Técnicas para la Aseguranza de la Calidad

Herramientas y técnicas de planeación de la calidad. Las herramientas y técnicas descritas en la Sección 8.1.2 pueden ser también usadas para aseguranza de la calidad.
Auditorias de calidad. Una auditoria de calidad es una revisión estructurada de otras actividades de la administración de la calidad. El objetivo de una auditoria de calidad es identificar las lecciones aprendidas que puedan mejorar el desempeño de este y otros proyectos dentro de la organización ejecutora. Las auditorias de calidad pueden ser programadas o aleatorias, y pueden ser ejecutadas por auditores internos entrenados adecuadamente, o por terceros tales como agencias registradoras de sistemas de calidad.

8.2.3 Salidas de la Aseguranza de la Calidad

Mejoramiento de la calidad. El mejoramiento de la calidad incluye el tomar acción para incrementar la efectividad y eficiencia del proyecto para proveer beneficios adicionales a los partidos interesados del proyecto. En la mayoría de los casos, implementar las mejoras a la calidad requerirá la preparación de requisiciones de cambio o la toma de acciones correctivas y será manejado de acuerdo a los procedimientos para el control de cambios general, tal como se describe en la Sección 4.3.

8.3 Control de Calidad

El control de calidad involucra monitorear resultados específicos del proyecto para determinar si estos cumplen con los standards relevantes de calidad e identificar maneras de eliminar las causas de los resultados insatisfactorios. Se deberá ejecutar a través de todo el proyecto. Los resultados de proyecto incluyen tanto resultados del producto tales como entregas como resultados administrativos tales como desempeños de costos y programación. El control de calidad es desempeñado muchas veces por un Departamento de Control de Calidad u organización de título similar, pero esto no es indispensable.

El equipo administrativo del proyecto deberá tener un conocimiento práctico de control de calidad estadístico, en especial de muestreo y probabilidades, para ayudarlos a evaluar las salidas del control de calidad. Entre otras materias, deberán conocer la diferencia entre:

Prevención (mantener errores fuera de los procesos) e inspección (mantener errores fuera de las manos de los clientes).
Muestreo de atributos (los resultados cumplen o no cumplen) y muestreo de variables (el resultado se califica sobre una escala continua que mide el grado de cumplimiento).
Causas especiales (eventos inusuales) y causas aleatorias (procesos normales de variación).
Tolerancias (el resultado es aceptable sí cae dentro del rango especificado por la tolerancia) y límites de control (el proceso esta bajo control sí el resultado cae dentro de los límites de control).

8.3.1 Entradas al Control de Calidad

Resultados de trabajo. Los resultados de trabajo (descritos en la Sección 4.2.3.1) incluyen tanto resultados de procesos como resultados de producto. Información acerca de resultados planeados o esperados (del plan de proyecto) deben estar disponibles junto con información acerca de los resultados reales.
Plan de administración de la calidad. El plan de administración de la calidad esta descrito en la Sección 8.1.3.1.
Definiciones operacionales. Las definiciones operacionales están descritas en la Sección 8.1.3.2.
Listas de chequeo. Las listas de chequeo están descritas en la Sección 8.1.3.3.

Herramientas y Técnicas para el Control de Calidad

Inspección. La inspección incluye actividades tales como medición, examinación, y ensayos ejercidos para determinar si los resultados cumplen con los requerimientos. Las inspecciones pueden ser conducidas a cualquier nivel (e.g., los resultados de una actividad individual pueden ser inspeccionados o el producto final de un proyecto puede ser inspeccionado). Las inspecciones pueden ser llamadas repasos, repasos de producto, auditorias, e inspecciones visuales; en algunas áreas de aplicación, estos términos tienen significados precisos y específicos.
Las tablas de control pueden ser usadas para monitorear cualquier salida de variables del proyecto. Aunque son más usadas frecuentemente para el seguimiento de actividades repetitivas tales como lotes de manufactura, las tablas de control también pueden ser usadas para monitorear varianzas de programación y costos, el volumen y frecuencia de cambios al alcance, errores en los documentos del proyecto, y otros resultados administrativos para ayudar a determinar si los "procesos administrativos de proyecto" están bajo control. La Figura 8-4 es una tabla de control del desempeño de la programación de un proyecto.
Tablas de control. Las tablas de control son formas gráficas de los resultados, sobre el tiempo, de un proceso. Son usadas para determinar si los procesos están "bajo control" (e.g., ¿son las diferencias en los resultados, creadas por variaciones aleatorias o hay ocurrencia de eventos inusuales cuyas causas deben ser identificadas y corregidas?). Cuando un proceso esta bajo control, el proceso no debe ser ajustado. El proceso puede ser cambiado para poder proveer mejoras pero no debe ser ajustado mientras este bajo control.
defectos primero. Los diagramas de Pareto están conceptualmente ligados a la Ley de Pareto, que sostiene que un número relativamente pequeño de causas van a causar típicamente la gran mayoría de los problemas o defectos.
Diagramas de Pareto. Un diagrama de Pareto es un histograma, ordenado por frecuencia de ocurrencia, que muestra cuantos resultados fueron generados por tipo o categoría de causa identificada (véase la Figura 8-5). El ordenamiento por rango es usado para guiar la acción correctiva – el equipo administrativo de proyecto debe tomar acción para arreglar problemas que están causando el mayor numero de
Muestreo estadístico. El muestreo estadístico involucra el escoger parte de una población de interés para inspección (e.g., seleccionar diez muestreos de ingenieros de una lista de 75). El muestreo apropiado puede muchas veces reducir el costo del control de calidad. Existe un cuerpo substancial de conocimiento sobre el muestreo estadístico; en algunas áreas de aplicación, es necesario que el equipo administrativo del proyecto este familiarizado con una variedad de técnicas de muestreo.
Flujogramas. Los flujogramas están descritos en la Sección 8.1.2.3. Los flujogramas son utilizados en el control de calidad para ayudar analizar como ocurren los problemas.
Análisis de tendencias. El análisis de tendencia involucra usar técnicas matemáticas para pronosticar resultados futuros basado en resultados históricos. El análisis de tendencia se usa muchas veces para monitorear:

Desempeño técnico- cuantos errores o defectos han sido detectados, y cuantos permanecen sin corregir.
Desempeño de costos y programación- cuantas actividades por periodo fueron terminadas con varianzas significativas.

8.3.3 Salidas del Control de Calidad

Mejoramiento de la calidad. El mejoramiento de la calidad se describe en la Sección 8.2.3.1
Decisiones de aceptación. Los ítems inspeccionados serán aceptados o rechazados. Los ítems rechazados pueden requerir trabajo repetido (descrito en la Sección 8.3.3.3)
Trabajo repetido. El trabajo repetido es acción que se toma para llevar un ítem defectuoso o que no-conforma a cumplir con los requerimientos o especificaciones. El trabajo repetido, en especial el trabajo no anticipado, es una causa frecuente de sobrecostos en la mayoría de las áreas de aplicación. El equipo administrativo del proyecto debe hacer todo esfuerzo razonable para minimizar el trabajo repetido.
Listas de chequeo terminadas. Véase la Sección 8.1.3.3. Cuando las listas de chequeo son usadas, las listas terminadas deben convertir en parte de los archivos del proyecto.
Procesos de ajuste. Los procesos de ajuste involucran correctivos inmediatos o acción preventiva como resultado de mediciones de calidad. En algunos casos, los ajustes de proceso pueden necesitar ser manejados de acuerdo a procedimientos generados para el control de cambio general, descrito en la Sección 4.3.

NOTAS

Administración del Recurso Humano del Proyecto

La administración del recurso humano del proyecto incluye los procesos requeridos para hacer el uso más efectivo de las personas involucradas con el proyecto. Este incluye a todos los partidos interesados del proyecto – patrocinadores, clientes, contribuidores individuales, y a otros como se describe en la Sección 2.2. La Figura 9-1 una vista general de los siguientes procesos principales:

Planeación Organizacional– es identificar, documentar, y asignar roles de proyecto, responsabilidades, y relaciones de reporte.
Adquisición de Staff – es conseguir los recursos humanos necesarios para asignarlos y ponerlos a trabajar en el proyecto.
Desarrollo de Equipo – es desarrollar las habilidades individuales y de equipo para mejorar el desempeño del proyecto.

Estos procesos interactuan entre ellos y con otros procesos en otras áreas de conocimiento. Cada proceso puede involucrar esfuerzo de uno más individuos o grupos de individuos basado en las necesidades del proyecto. Aunque los procesos se presentan aquí como elementos discretos con interfaces bien definidas, en la práctica estos se pueden traslapar de maneras que no se detallan aquí. Las interacciones de los procesos se discuten en detalle en el Capitulo 3, Procesos de Administración del Proyecto.

Existe un cuerpo substancial de literatura que trata sobre como manejar a personas en un contexto operacional continuo. Alguno tópicos pueden incluir entre otros:

Liderar, comunicar, negociar, y otros que se discuten en la Sección 2.4, Habilidades Claves de la Administración General.

Delegar, motivar, entrenar, ser mentor, y otros temas relacionados con el manejo de individuos.

Construcción de equipos, manejo de conflictos, y otros temas relacionados con el manejo de grupos.

Medición de desempeño, reclutamiento, retención, relaciones laborales, regulaciones de salud e higiene laboral, y otros temas relacionados con la administración de la función del recurso humano.

La mayoría de este material es aplicable directamente al liderazgo y manejo de personas en los proyectos, y el administrador de proyecto y su equipo administrativo deberán estar familiarizado con él. Sin embargo, ellos deben ser sensibles a como se aplica este conocimiento en el proyecto. Por ejemplo:

La naturaleza temporal de los proyectos significa que las relaciones personales y organizativas serán tanto temporales como nuevas. El equipo administrativo debe tener cuidado de seleccionar técnicas que sean apropiadas para tales relaciones de carácter temporal.
La naturaleza y el número de partidos interesados muchas veces variarán a medida que el proyecto se mueve de una fase a otra en su ciclo de vida. Como resultado, técnicas que son eficientes en una fase pueden no serlo en otra. El equipo administrativo debe tener cuidado de usar técnicas que sean apropiadas para las necesidades corrientes del proyecto.

Las actividades administrativas del recurso humano suelen pocas veces ser una responsabilidad directa del equipo administrativo del proyecto. Sin embargo, el equipo administrativo debe estar lo suficientemente consciente de los requerimientos administrativos para asegurar cumplimiento.

Planeación Organizacional

La planeación organizacional involucra identificar, documentar, y asignar roles de proyecto, resposabilidades, y relaciones de reporte. Los roles, responsabilidades, y relaciones de reporte pueden ser asignadas a individuos o grupos. Los individuos o grupos pueden ser parte de la organización ejecutora del proyecto o pueden ser externas a este. Los grupos internos están muchas veces asociados a departamentos funcionales específicos tales como ingeniería, mercadeo, o contabilidad.

En la mayoría de proyectos la planeación organizacional es hecha como parte de las fases más tempranas del proyecto. Sin embargo, los resultados de este proceso deben ser revisados de manera regular durante el proyecto para asegurar su aplicabilidad continuada. Si la organización inicial ya no es efectiva, esta deberá ser revisada de manera oportuna.

La planeación organizativa esta muchas veces ligada de manera estrecha con la planeación de las comunicaciones (descrito en la Sección 10.1) ya que la estructura organizativa del proyecto va a tener un efecto importante sobre los requerimientos de comunicación del proyecto.

Entradas a la Planeación Organizativa

Interfaces del proyecto. Las interfaces del proyecto generalmente caen en una de tres categorías:

Interfaces organizacionales – las relaciones de reporte formales e informales entre las diferentes unidades organizacionales. Las interfaces organizacionales pueden ser altamente complejas o muy sencillas. Por ejemplo, el desarrollo de un sistema de telecomunicaciones complejo puede requerir coordinar a numerosos subcontratistas durante varios años, mientras que el arreglo de un error de programación en un sistema instalado en un solo sitio puede requerir poco más que notificar al usuario y al staff de operación al terminar.
Interfaces técnicas – las relaciones de reporte formales e informales entre diferentes disciplinas técnicas. Las interfaces técnicas ocurren tanto dentro de fases de proyecto (e.g., el diseño de las fundaciones realizado por el ingeniero civil debe ser compatible con el de la superestructura desarrollado por el ingeniero estructural) como entre fases de proyecto (e.g., cuando el equipo de diseño de un automóvil pasa los resultados de su trabajo al equipo de manufactura que deberá crear las capacidades de manufactura para el vehículo).
Interfaces personales – las relaciones de reporte formales e informales entre los diferentes individuos trabajando en el proyecto.
Estas interfaces muchas veces ocurren de manera simultanea, así como cuando el arquitecto empleado por la firma de diseño explica consideraciones claves de diseño a un equipo administrativo de construcción no relacionado (con el proyecto) del contratista.

Requerimientos de staffing. Los requerimientos de staffing definen que clases de habilidades son requeridas de que individuos o grupos y en que marcos de tiempo. Los requerimientos de staffing son un subjuego de los requerimientos generales de recursos identificados durante la planeación de recursos (descrito en la Sección 7.1).
Restricciones. Las restricciones son factores que limitan las opciones del equipo de proyecto. Las opciones organizacionales de un proyecto pueden estar restringidas de muchas maneras. Algunos factores comunes que pueden restringir la organización del equipo de proyecto incluyen, pero no están limitadas a, las siguientes:

La estructura organizacional de la organización ejecutora – una organización cuya estructura básica es una matriz fuerte significa un papel relativamente más fuerte para el administrador del proyecto, que aquel que tendría en una organización con estructura básica de matriz débil (véase la sección 2.3.3 para una discusión mas detallada de las estructuras organizacionales).
Los acuerdos colectivos laborales – son acuerdos contractuales con sindicatos u otros grupos de empleados que pueden requerir ciertos roles o relaciones de reporte (en esencia, el empleado es un partido interesado).

Preferencias del equipo administrativo del proyecto – si miembros del equipo administrativo del proyecto han tenido éxito con ciertas estructuras en el pasado, estos probablemente propondrán estructuras similares en el futuro.
Asignaciones esperadas de staff –la organización del proyecto esta muchas veces influenciada por las habilidades y capacidades de individuos específicos.

Herramientas y Técnicas para la Planeación Organizacional

Patrones. Aunque cada proyecto es único, la mayoría de los proyectos se parecerán a otro proyecto en algún grado. Usando las definiciones de roles y responsabilidades o las relaciones de reporte de un proyecto similar podrán ayudar a expeditar el proceso de planeación organizacional.
Prácticas de recursos humanos. Muchas organizaciones tienen una variedad de políticas, delineamientos, y procedimientos que pueden ayudar al equipo administrativo del proyecto con los aspectos varios de la planeación organizacional. Por ejemplo, una organización que mira a los administradores como "directores técnicos" es probable que tenga documentación sobre como el rol de "dirigir" se debe ejecutar.
Teoría organizacional. Existe un cuerpo de literatura substancial que describe como las organizaciones pueden y deben ser estructuradas. Aunque solo un pequeño subjuego de este cuerpo de literatura esta dirigido específicamente a las organizaciones de proyecto, el equipo administrativo del proyecto deberá estar familiarizado en general con el tema de la teoría organizacional para así poder responder mejor a los requerimientos del proyecto.
Análisis de los partidos interesados. Las necesidades de los varios partidos interesados deben ser analizadas para asegurar que sus necesidades van a ser satisfechas. La Sección 10.1.2.1 discute el análisis de los partidos interesados en mas detalle.

Salidas de la Plantación Organizacional.

mayoría de roles y responsabilidades serán asignados a partidos interesados que están activamente involucrados en el trabajo del proyecto, tal como el administrador del proyecto, otros miembros del equipo administrativo del proyecto, y los contribuidores individuales.
Los roles y responsabilidades del administrador del proyecto son generalmente criticas en la mayoría de proyectos pero pueden variar significativamente dependiendo del área de aplicación.
Los roles y responsabilidades deberán estar estrechamente ligadas a la definición del alcance. Una Matriz de Asignación de Responsabilidades (o RAM, véase la Figura 9-2) es usada a menudo para este propósito. En los grandes proyectos, las RAM’s pueden ser desarrolladas a varios niveles. Por ejemplo, una RAM de alto nivel puede definir que grupo o unidad es responsable por cada elemento de la estructura de desglose de trabajo, mientras que una RAM de bajo nivel es usada dentro del grupo para asignar roles y responsabilidades para actividades especificas a individuos específicos.
Asignación de roles y responsabilidades. Los roles de proyecto (quien hace que) y responsabilidades (quien decide que) deben ser asignadas a los partidos interesados apropiados. Los roles y responsabilidades pueden variar a través del tiempo. La
Plan de administración del staff. El plan de administración del staff describe cuando y como los recursos humanos serán traídos y retirados del equipo del proyecto. El plan de staffing puede ser formal o informal, altamente detallado o de marco amplio, basado en las necesidades del proyecto. Es un elemento subsidiario del plan general del proyecto (véase la Sección 4.1, Desarrollo del Plan de Proyecto).

El plan de administración del staff muchas veces incluye histogramas de recursos, como se ilustra en la Figura 9-3.

Se debe prestar particular cuidado a como los miembros del equipo de proyecto (individuos o grupos) serán retirados una vez no sean necesitados en el proyecto. Procedimientos adecuados de reasignación pueden:

Reducir costos al eliminar o reducir la tendencia a "fabricar trabajo" para llenar el tiempo entre esta tarea y la que sigue.
Mejor la moral al reducir o eliminar la incertidumbre sobre las oportunidades futuras de empleo.

Tabla organizacional. Una tabla organizacional (organigrama) es cualquier gráfica del proyecto que reporte relaciones. Esta puede ser formal o informal, altamente detallada o de marco amplio dependiendo de las necesidades del proyecto. Por ejemplo, la tabla organizacional para 3 o 4 personas para un proyecto de servicio interno es poco probable que tenga el rigor y detalle de la tabla organizacional para un cambio de combustible nuclear de una planta nuclear de 3,000 personas.
Una Estructura de Desglose Organizacional (OBS) es una tabla organizacional especifica que muestra que unidades organizacionales son responsables por que ítems de trabajo.
Detalle de soporte. El detalle de soporte para la plantación organizacional varia con el área de aplicación y el tamaño del proyecto. Información que se suministra con frecuencia como detalle de soporte incluye, pero no se limita a:

Impacto organizacional – que alternativas son precluidas al organizar de esta manera.
Descripción de trabajos – son descripciones escritas por categoría de trabajo de las habilidades, responsabilidades, conocimiento, autoridad, ambiente físico, y otras características que hacen parte del desempeño de un trabajo dado. También se conocen como descripciones de funciones laborales.
Necesidades de entrenamiento – si el staff que se va a asignar no se espera tenga las habilidades necesarias para el proyecto, entonces esas habilidades tendrán que ser desarrolladas como parte del proyecto.

La adquisición del staff involucra conseguir los recursos humanos necesarios (individuos o grupos) para asignar a trabajar en el proyecto. En la mayoría de ambientes, los "mejores" recursos pueden no estar disponibles, y el equipo administrativo del proyecto debe tener cuidado de asegurar que los recursos que están disponibles cumplirán con los requerimientos del proyecto.
1. Entradas a la Adquisición del Staff
Adquisición del Staff

Plan de administración del staff. El plan de administración del staff esta descrito en la Sección 9.1.3.2. Este incluye los requerimientos de staffing del proyecto tal como se describe en la Sección 9.1.1.2.
Descripción del pool del staff. Cuando el equipo administrativo del proyecto es capaz de influenciar o de dirigir las asignaciones del staff, este debe considerar las características de la potencialidad del staff disponible. Las consideraciones incluyen, pero no se limitan a:

Experiencia previa – ¿ Han los individuos o grupos tenido experiencia de trabajo similar o relacionada anteriormente? ¿Lo han hecho bien?
Intereses personales – ¿ Están los individuos o grupos interesados en trabajar en este proyecto?
Características personales – ¿ Estarán los individuos o grupos dispuestos a trabajar juntos en un equipo?
Disponibilidad –¿ Estarán los individuos o grupos más deseables diponibles para trabajar en el marco de tiempo requerido?

Practicas de reclutamiento. Una o más de las organizaciones involucradas en el proyecto pueden tener políticas, delineamientos, o procedimientos que gobiernen las asignaciones de staff. Cuando estas existen, tales practicas actúan como restricciones sobre el proceso de adquisición del staff.

Herramientas y Técnicas para la Adquisición del Staff

Negociación. Las asignaciones de staff deben ser negociadas en la mayoría de los proyectos. Por ejemplo, el equipo administrativo de proyecto tal vez tenga necesidad de negociar con:

Administradores funcionales responsables para asegurar que el proyecto recibe el staff entrenado y apropiado en el marco de tiempo necesario.
Otros equipos administrativos de proyecto dentro de la organización ejecutora para asignar recursos escasos o especializados de manera apropiada.

Las habilidades para influenciar del equipo (véase la Sección 2.4.5, Influenciando la Organización) juegan un papel importante al negociar las asignaciones de staff como así las políticas de las organizaciones involucradas. Por ejemplo, un administrador funcional puede ser recompensado basado sobre la utilización de el staff. Esto crea un incentivo para el administrador para asignar el staff disponible que puede no cumplir con todos los requerimientos del proyecto.

Pre-asignacion. En algunos casos, el staff puede estar pre-asignado a el proyecto. Este es muchas veces el caso cuando (a) el proyecto es el resultado de una propuesta competitiva y un staff especifico fue prometido como parte de la propuesta, o (b) el proyecto es un proyecto interno de servicio y las asignaciones de staff fueron definidas dentro del charter del proyecto.
Procuramiento. La administración del procuramiento (descrita en el Capitulo 12) se puede utilizar para obtener los servicios de individuos o grupos específicos para ejecutar actividades del proyecto. El procuramiento es requerido cuando la organización ejecutora carece del staff propio necesario para completar el proyecto. (e.g., como resultado de una decisión consciente de no contratar a tales individuos de tiempo completo, como el resultado de tener a todo el staff entrenado apropiado comprometido previamente a otros proyectos, o como el resultado de otras circunstancias).

9.2.3 Salidas de la Adquisición de Staff

Asignación del staff del proyecto. El proyecto tiene completo su staff cuando las personas apropiadas han sido asignadas de manera fiable para trabajar en este. El staff puede estar asignado de tiempo completo, de medio tiempo, o de forma variable, dependiendo de las necesidades del proyecto.
Directorio del equipo de proyecto. Un directorio del equipo de proyecto lista a todos los miembros del equipo de proyecto y a otros partidos interesados claves. El directorio puede ser formal o informal, altamente detallado o de contexto amplio, basado en las necesidades del proyecto.

Desarrollo del Equipo

El desarrollo del equipo incluye tanto el mejoramiento de las habilidades de los partidos interesados para contribuir como individuos así como mejorar la habilidad del equipo para funcionar como equipo. El desarrollo individual (administrativo y técnico) es la fundación necesaria para desarrollar el equipo. El desarrollo del equipo es critico para la habilidad del proyecto de lograr sus objetivos.

El desarrollo del equipo en un proyecto es muchas veces complicado cuando los miembros individuales del equipo son tenidos como responsables a tanto a un administrador funcional como al administrador del proyecto (véase la Sección 2.3.3 para una discusión de las estructuras matriciales organizacionales. Un manejo efectivo de esta relación de reporte dual es muchas veces un factor critico de éxito para el proyecto y es generalmente la responsabilidad del administrador del proyecto.

Aunque el desarrollo del equipo esta posicionado en el Capitulo 3 como uno de los procesos de ejecución, el desarrollo del equipo ocurre a través de la vida del proyecto.

Entradas al Desarrollo del Equipo

Staff del proyecto. La consecución del staff del proyecto esta descrita en la Sección 9.2.3.1. Las asignaciones de staff definen implícitamente las habilidades individuales y de equipo disponibles para trabajar sobre esta.
Plan del Proyecto. El plan del proyecto esta descrito en la Sección 4.1.3.1. El plan del proyecto describe el contexto técnico dentro del que tiene que operar el equipo.
Plan de administración del staff. El plan de administración del staff esta descrito en la Sección 9.1.3.2.
Reportes de desempeño. Los reportes de desempeño (descritos en la Sección 10.3.3.1.) proveen retroalimentación al equipo del proyecto sobre desempeño contra el plan del proyecto.
Retroalimentación externa. El equipo del proyecto debe periódicamente medirse contra las expectativas de desempeño de aquellos que están fuera del proyecto.

Herramientas y Técnicas para el Desarrollo del Equipo

Actividades constructoras de equipo. Las actividades desarrolladoras o constructoras de equipo incluyen acciones individuales o administrativas tomadas de manera especifica y primaria para el desarrollo del mejoramiento del equipo. Muchas acciones tales como involucrar a miembros del equipo que no son de nivel administrativo en el proceso de planeación, o el establecimiento de reglas bases para la localización y administración de conflictos, pueden mejorar el desempeño del equipo como un efecto secundario. Las actividades constructoras de equipo pueden variar desde un ítem de agenda de cinco minutos en una reunión regular de status o una experiencia extendida, fuera del lugar de trabajo, facilitada por profesionales y diseñada para mejorar las relaciones interpersonales entre partidos interesados claves.
Hay un cuerpo sustancial de literatura sobre el desarrollo de equipos. El equipo administrativo del proyecto deberá estar familiarizado de manera general con una variedad de actividades desarrolladoras de equipo.
Habilidades administrativas generales. Las habilidades administrativas generales (discutidas en la Sección 2.4) son de particular importancia para el desarrollo del equipo.
Los proyectos muchas veces deberán contar con su propio sistema de reconocimiento y recompensas ya que los sistemas de la organización ejecutora puede no ser apropiados. Por ejemplo, la disposición de trabajar tiempo extra para poder cumplir con una programación agresiva deberá ser recompensado o reconocido; la necesidad de trabajar tiempo extra como resultado de una pobre planeación no lo deberá ser.
Los sistemas de recompensa y reconocimiento deberán considerar también diferencias culturales. Por ejemplo, el desarrollo de un mecanismo apropiado para un equipo en una cultura que premia el individualismo puede ser muy difícil.
Sistemas de reconocimiento y recompensa. Los sistemas de reconocimiento y recompensa son acciones formales administrativas que promueven o refuerzan comportamiento deseado. Para que sean efectivas, tales sistemas deben hacer un enlace entre el desempeño y una recompensa clara, explicita, y que se pueda lograr. Por ejemplo, un administrador de proyectos que será recompensado por cumplir con los objetivos de costo del proyecto deberá tener un nivel apropiado de control sobre el staff y las decisiones de procuramiento.
Colocación. La colocación involucra la asignación de todos o de casi todos, los miembros más activos del equipo del proyecto en la misma locación física para mejorar su habilidad de desempeñarse en común equipo. La colocación es usada de manera amplia en los grandes proyectos y también puede ser efectiva para los proyectos pequeños (e.g., con un "cuarto de guerra" donde el equipo se congrega o se dejan ítemes de trabajo en proceso).
Entrenamiento. El entrenamiento incluye todas las actividades diseñadas para el mejoramiento de habilidades, conocimiento, y capacidades del equipo del proyecto. Algunos autores distinguen entre entrenamiento, educación, y desarrollo, pero estas distinciones no son ni consistentes ni ampliamente aceptadas. El entrenamiento puede ser formal (e.g., entrenamiento en el salón de clases, entrenamiento basado en computadores) o informal (e.g., retroalimentación de otros miembros del equipo) existe un cuerpo sustancial de literatura que trata de como proveer entrenamiento a adultos.

Si los miembros del equipo del proyecto carecen de las habilidades técnicas o administrativas necesarias, tales habilidades deberán ser desarrolladas como parte del proyecto, o se deberán tomar pasos para conseguir nuevo staff adecuado al proyecto. Los costos directos e indirectos para este entrenamiento generalmente son pagados por la organización ejecutora.

Salidas del Desarrollo del Equipo

Mejoramiento del desempeño. La salida primaria del desarrollo del equipo es un mejoramiento del desempeño del proyecto. Los mejoramientos pueden venir de muchas fuentes y pueden afectar muchas áreas de desempeño del proyecto, por ejemplo:

Mejoramiento de las habilidades individuales pueden permitir a una persona especifica a ejecutar sus actividades asignadas mas efectivamente.
Mejoramiento en los comportamientos del equipo (e.g., la localización y manejo de conflicto) pueden permitir a los miembros del equipo del proyecto a dedicar un mayor porcentaje de uso de esfuerzo a actividades técnicas.
Mejoramientos ya sean de actividades individuales o de capacidades del equipo pueden facilitar el identificar y desarrollar mejores maneras de hacer el trabajo del proyecto.

Entradas para evaluaciones de desempeño. Los miembros del staff del proyecto generalmente deberán proveer entradas a las evaluaciones de desempeño de cualquier miembro del staff del proyecto con el que interactuan de manera significativa.

NOTAS

Administración de las Comunicaciones del Proyecto

La administración de comunicaciones del proyecto incluyen los procesos requeridos para asegurar la generación, colección, diseminación, almacenaje y ultima disposición de la información del proyecto de manera oportuna y apropiada. Provee las relaciones criticas entre personas, ideas, e información que son necesarias para el éxito. Todas las personas involucradas en el proyecto deben estar preparadas para transmitir y recibir comunicaciones en el "lenguaje" del proyecto y deben de comprender como las comunicaciones en las que están involucradas como individuos afectan el proyecto como un todo. La Figura 10-1 provee una vista general de los siguientes procesos generales:

Planeación de las Comunicaciones – determina las necesidades de información y comunicación de los partidos interesados: quien necesita que información, cuando la van a necesitar, y como se les será entregada.
Distribución de la información – Es hacer que la información necesitada este disponible para los partidos interesados de manera oportuna.
Reportes de desempeño – Es colectar y diseminar información de desempeño. Esto incluye reporte de status, medición de avance, y pronósticos.
Cierre administrativo – Es generar, recoger, y diseminar información para formalizar la fase de terminación del proyecto.

Estos procesos interactuan entre ellos y con otros procesos de otras áreas de conocimiento también. Cada proceso puede involucrar esfuerzo de uno o más individuos o grupos de individuos basado en las necesidades del proyecto. Cada proceso ocurre por los menos una vez en cada fase del proyecto.

Aunque los procesos aquí se presentan como elementos discretos con interfases claramente definidas, en la practica estas se pueden traslapar e interactuar de maneras que no se detallan aquí.

Las interacciones de proceso se discuten en detalle en el Capítulo 3.

Las habilidades administrativas generales de las comunicaciones (discutidas en la Sección 2.4.2.) están relacionadas a, pero no son lo mismo que, la administración de las comunicaciones del proyecto. Las comunicaciones son una materia más amplia e involucran un cuerpo sustancial de conocimiento que no es único al contexto del proyecto. Por ejemplo:

Modelos de transmisor – receptor – ciclos de retroalimentación, barreras a las comunicaciones, etc.
Selección del medio – cuando comunicarse en escrito vs. cuando comunicarse de manera oral, cuando escribir un memo informal vs. cuando escribir un reporte formal, etc.
Estilo de escritura – voz pasiva vs. voz activa, estructura de la oración, preferencia de palabras, etc.
Técnicas de presentación – lenguaje corporal, diseño de ayudas visuales, etc.
Técnicas de reuniones administrativas – preparación de una agenda, manejo de conflictos, etc.

Planeación de las Comunicaciones

La planeación de las comunicaciones involucra determinar las necesidades de información y comunicaciones de los partidos interesados: quien necesita que información, cuando la van a necesitar, y como se les será entregada. Mientras que todos los proyectos comparten la necesidad de comunicar información del proyecto, las necesidades de información y los métodos de distribución pueden variar. La identificación de las necesidades de información de los partidos interesados y la determinación de un medio apropiado de cumplir con esas necesidades es un factor importante para el éxito del proyecto.

En la mayoría de los proyectos, la mayor parte de la plantación de las comunicaciones es realizada como una de las fases más tempranas del proyecto. Sin embargo, los resultados de este proceso deben ser repasados de manera periódica a través del proyecto y revisados en la medida que sea necesaria para asegurar su aplicabilidad continuada.

La planeación de la comunicación esta muchas veces íntimamente ligada con la planeación organizacional (descrita en la Sección 9.1) ya que la estructura organizacional del proyecto tendrá un efecto importante sobre los requerimientos de comunicación del proyecto.

Entradas a la Planeación de las Comunicaciones

Requerimientos de comunicación. Los requerimientos de las comunicaciones son la suma de los requerimientos de información de los partidos interesados del proyecto. Los requerimientos son definidos al combinar el tipo y formato de la información requerida con un análisis del valor de esa información. Los recursos de proyectos se deben de expender solo sobre una comunicación de información que contribuye al éxito o donde una falta de comunicación puede llevar al fracaso. La información típicamente requerida para determinar los requerimientos de comunicaciones del proyecto incluyen:

Relaciones de responsabilidad entre la organización del proyecto y los partidos interesados.
Disciplinas, departamentos, y especialidades involucradas en el proyecto.
Logística de cuantos individuos estarán involucrados en el proyecto y en que locaciones.
Necesidades de información externas (e.g., comunicaciones con los medios).

Tecnología de las comunicaciones. Las tecnologías o métodos usados para transmitir información desde y para miembros entre los elementos del proyecto pueden variar significativamente: desde conversaciones breves a reuniones extendidas, desde documentos escritos simples a cronogramas y bases de datos en línea inmediatamente accesibles. Factores de tecnología de las comunicaciones que pueden afectar el proyecto incluyen:

La inmediatez de la necesidad de información – es el éxito del proyecto dependiente de tener información frecuentemente actualizada y disponible en cualquier momento, o serán suficientes reportes escritos regulares?
La disponibilidad de tecnología – son los sistemas que ya están en funcionamiento apropiados o exigen las necesidades del proyecto cambios?
El staffing esperado del proyecto – son los sistemas de comunicación propuestos compatibles con la experiencia y habilidad de los participantes del proyecto, o será necesario entrenamiento y aprendizaje extensivo?
La duración del proyecto – es la tecnología disponible probable de cambiar antes de que el proyecto termine de una manera que obligue la adopción de tecnología más nueva?

Restricciones. Las restricciones son factores que van a limitar las opciones del equipo administrativo del proyecto. Por ejemplo, si se van a procurar recursos sustanciales del proyecto se deberá dar mas consideración a la información del manejo del contrato.
Cuando un proyecto sea ejecutado bajo contrato, existe muchas veces provisiones contractuales especificas que afectan la planeación de las comunicaciones.
Suposiciones. Las suposiciones son factores que, para procesos de planeación, serán consideradas como verdaderas, reales, o certeras. Las suposiciones generalmente involucran un grado de riesgo. Estas podrán ser identificadas acá o pueden ser una salida de la identificación de riesgo (descrito en la Sección 11.1).

Herramientas y Técnicas para la Planeación de las Comunicaciones

Análisis de los partidos interesados. Las necesidades de información de los varios partidos interesados deben ser analizadas para desarrollar una vista lógica y metodológica de sus necesidades informativas y fuentes para cumplir con esas demandas (los partidos interesados se discuten en mas detalle en la Sección 2.2 y 5.1). El análisis debe considerar métodos y tecnologías apropiadas para el proyecto que puedan proveer la información que se necesita. Se debe tener cuidado de malgastar recursos en información innecesaria o tecnología inapropiada.

Salidas de la Planeación de las Comunicaciones

Plan de administración de las comunicaciones. Un plan de administración de las comunicaciones es un documento que provee:

Una estructura de colección y que archiva que detalles, que métodos serán usados para recolectar y archivar varios tipos de información. Los procedimientos también deben de cubrir como colectar y diseminar actualizaciones y correcciones a materiales previamente distribuidos.
Una estructura de distribución que detalla a quien la información (reportes de status, datos, programaciones, documentación técnica, etc.) fluirá, y que métodos (reportes escritos, reuniones, etc.) serán usados para distribuir los varios tipos de información. Esta estructura debe ser compatible con las responsabilidades y relaciones de reporte descritas en la tabla organizacional (organigrama) del proyecto.
Una descripción de la información a ser distribuida, incluyendo formato, contenido, nivel de detalle, y convenciones/definiciones que serán usadas.
Programaciones de producción mostrando cuando cada tipo de comunicación será producida.
Métodos para accesar información entre comunicaciones programadas.
Un método para la actualización y refinación del plan de administración de las comunicaciones a medida que el proyecto progresa y se desarrolla.

El plan de administración de las comunicaciones puede ser formal o informal, altamente detallado o de contexto amplio, basado en las necesidades del proyecto. Es un elemento subsidiario del plan general del proyecto (descrito en la Sección 4.1).

Distribución de la Información

La distribución de la información involucra hacer que la información que se necesita del proyecto este disponible para los partidos interesados del proyecto de manera oportuna. Incluye implementar el plan de administración de las comunicaciones así como responder a pedidos inesperados de información.

Entradas a la Distribución de Información

Resultados de trabajo. Los resultados de trabajo están descritos en la Sección 4.2.3.1.
Plan de administración de las comunicaciones. El plan de administración de las comunicaciones esta descrito en la Sección 10.1.3.1.
Plan del proyecto. El plan del proyecto esta descrito en la Sección 4.1.3.1.

Herramientas y Técnicas para la Distribución de la Información

Habilidades de comunicación. Las habilidades de comunicación son usadas para el intercambio de información. El transmisor es responsable por hacer la información clara, no ambigua, y completa de manera que el receptor pueda recibirla de manera correcta y de confirmar que se entendió correctamente. El receptor es responsable de estar seguro que la información se recibió en su totalidad y que se entendió correctamente. Las comunicaciones tienen muchas dimensiones:

Escrita y oral, hablar y escuchar.
Interna (dentro del proyecto) y externa (al cliente, a los medios, al publico, etc.).
Formal (reportes, reuniones, etc.) e informal (memos, conversaciones ad hoc, etc.).
Vertical (hacia arriba y abajo en la organización) y horizontal (con los compañeros).

Sistemas de retorno de la información. La información puede ser compartida por miembros del equipo a través de varios métodos que incluyen sistemas manuales de archivar, bases de datos de texto electrónicas, software de administración de proyectos, y sistemas que permiten acceso a documentación técnica tales como dibujos de ingeniería.
Sistemas de distribución de la información. La información del proyecto puede ser distribuida usando una variedad de métodos que incluyen reuniones de proyecto, distribución de copias duras de documentos, acceso compartido a bases electrónicas de datos en red, fax, correo electrónico, correo de voz, y video conferencias.

Salidas de la Distribución de la Información

Archivos del proyecto. Los archivos del proyecto pueden incluir correspondencia, memos, reportes, y documentos que describen el proyecto. Esta información debe, en la medida que sea posible y apropiada, ser mantenida en una forma organizada. Los miembros del equipo del proyecto pueden mantener archivos personales en un cuaderno del proyecto.

Reportes de Desempeño

Los reportes de desempeño involucran colectar y diseminar información de desempeño de manera que se pueda proveer a los partidos interesados con información sobre como los recursos están siendo utilizados para cumplir con los objetivos del proyecto. Este proceso incluye:

Reportes de status – describiendo como se encuentra el proyecto en este momento.
Reportes de progreso – describen que es lo que el equipo del proyecto ha completado.
Pronósticos – es predecir el futuro status y progreso.

Los reportes de desempeño generalmente deberán proveer información sobre alcance, programación, costo, y calidad. Muchos proyectos también requieren información sobre riesgo y procuramiento. Los reportes pueden ser preparados de manera comprensiva o sobre una base de excepción.

Entradas a los Reportes de Desempeño

Plan del proyecto. El plan del proyecto se discute en la Sección 4.1.3.1. El plan del proyecto contiene las varias líneas de base que serán usadas para cuantificar el desempeño del proyecto.
Resultados de trabajo. Resultados de trabajo – que entregas han sido total o parcialmente completadas, en que costo se han incurrido o comprometido, etc. – son una salida de la ejecución del plan del proyecto (que se discute en la Sección 4.2.3.1). Los resultados de trabajo deberán ser reportados dentro del marco de trabajo proveido por el plan de administración de las comunicaciones. La información sobre los resultados de trabajo deben de ser precisas y uniformes, esto es esencial para unos reportes de desempeño útiles.
Otros archivos del proyecto. Los archivos del proyecto se discuten en la Sección 10.2.3.1. En adición al plan del proyecto y a los resultados de trabajo del proyecto, otros documentos de proyecto muchas veces contienen información pertinente al contexto del proyecto que debe ser considerada cuando se evalúa el desempeño del proyecto.

Herramientas y Técnicas para los Reportes de Desempeño

Comités de desempeño. Los comités de desempeño son reuniones que se sostienen para cuantificar el status del proyecto o su progreso. Los comités de desempeño son usados típicamente en conjunción con uno o más de las técnicas de reporte de desempeño descritas a continuación.
Análisis de varianza. El análisis de varianza involucra comparar los resultados actuales del proyecto con aquellos resultados planeados o esperados. Las varianzas de programación y costos son las mas frecuentemente analizadas, pero varianzas del plan en el área de alcance, calidad, y riesgo son muchas veces iguales o de mayor importancia.
Análisis de tendencia. El análisis de tendencia involucra analizar los resultados del proyecto sobre el tiempo para determinar si el desempeño esta mejorando o esta empeorando.
Análisis de valor ganado. El análisis de valor ganado en sus formas varias es el método mas comúnmente usado para la medición de desempeño. Este integra alcance, costo, y medición de la programación para ayudar al equipo administrativo del proyecto cuantificar el desempeño del proyecto. El valor ganado involucra calcular tres valores claves para cada actividad:

El presupuesto, que también se llama el costo presupuestado del trabajo programado (BCWS, budgeted cost of work scheduled), es esa porción del costo estimado aprobado que se planea se utilizara en la actividad durante un período dado.
El costo real, también llamado el costo real del trabajo realizado (ACWP, actual cost of work performed), es el total de costos directos e indirectos en que se incurrieron en realizar trabajo en la actividad en un período dado.
El valor ganado, también llamado costo presupuestado del trabajo realizado (BCWP, budgeted cost of work performed), es un porcentaje del presupuesto total igual al porcentaje de trabajo realmente terminado. Muchas implementaciones de valor ganado utilizan unos pocos porcentajes (e.g., 30 por ciento, 70 por ciento, 90 por ciento, 100 por ciento) para simplificar la colección de datos. Algunas implementaciones de valor ganado utilizan solamente 0 por ciento o 100 por ciento (hecho o no hecho) para ayudar a asegurar una medición objetiva del desempeño.

Estos tres valores son usados en combinación para proveer medición si el trabajo esta siendo terminado como planeado o no. Las mediciones mas comúnmente usadas son la varianza de costo (CV = BCWP – ACWP), la varianza de programación (SV = BCWP – BCWS), y el índice de desempeño de costos (CPI = BCWP/ ACWP). El acumulado CPI (la suma de todos los BCWP’s individuales dividido por la suma de todos los ACWP’s individuales) es usado de manera amplia para pronosticar los costos del proyecto al terminar. En algunas áreas de aplicación, el índice de desempeño de la programación (SPI = BCWP/ BCWS) es usado para pronosticar la fecha de terminación del proyecto.

Herramientas y técnicas de distribución de la información. Los reportes de desempeño son distribuidos usando las herramientas y técnicas descritas en la Sección 10.2.2.

Salidas de los Reportes de Desempeño

Formatos comunes para los formatos de desempeño incluyen gráficas de barras (también llamadas gráficas de Gantt), curvas S, histogramas, y tablas. La Figura 10-2 usa curvas S para mostrar datos acumulados de un análisis de valor ganado mientras que la Figura 10-3 nos muestra datos distintos de valor ganado en forma tabulada.
Reportes de desempeño. Los reportes de desempeño organizan y totalizan la información recogida y presentan los resultados de cualquier análisis. Los reportes deben de proveer los tipos de información y el nivel de detalle requerido por lo varios partidos interesados tal como se documenta en el plan de administración de las comunicaciones.
Solicitudes de cambio. El análisis de desempeño del proyecto muchas veces generan solicitudes para cambiar algún aspecto del proyecto. Estas solicitudes de cambio son manejadas como se describe en los procesos varios de control de cambio (e.g., administración de cambio al alcance, control de programación, etc.).

El proyecto o fase, después de conseguir sus objetivos o al ser terminado por otras razones, requiere un cierre. Los cierres administrativos consisten en verificar y documentar los resultados del proyecto para formalizar la aceptación del producto del proyecto por el patrocinador, cliente, o comprador. Esto incluye la colección de archivos del proyecto, asegurándose que estos reflejan las especificaciones finales, el análisis de éxito y efectividad del proyecto, y archivando tal información para uso futuro.
Las actividades de cierre administrativo no se deben demorar hasta la terminación del proyecto. Cada fase del proyecto deberá ser cerrada de manera apropiada para asegurar que información útil e importante no se pierda.
1. Entradas al Cierre Administrativo
Cierre Administrativo

Documentación de la medición de desempeño. Toda la documentación producida para gravar y analizar el desempeño del proyecto, incluyendo los documentos de planeación que establecieron el marco de trabajo para la medición del desempeño, deben de estar disponibles para su revisión durante el cierre administrativo.
Documentación del producto y del proyecto. La documentación producida para describir el producto del proyecto (planos, especificaciones, documentación técnica, dibujos, archivos electrónicos, etc. – la terminología varia de acuerdo con el área de aplicación) deberá estar también disponible para su revisión durante el cierre administrativo.
Otros archivos del proyecto. Los archivos del proyecto se discuten en la Sección 10.2.3.1.

Herramientas y Técnicas para el Cierre Administrativo

Herramientas y técnicas para el reporte de desempeño. Las herramientas y técnicas para el reporte de desempeño se discuten en la Sección 10.3.2.

Salidas del Cierre Administrativo

Archivos del proyecto. Un juego completo de archivos del proyecto indexados deberá ser preparado para su archivación por los partidos apropiados. Cualquier base de datos histórica pertinente al proyecto, ya sea especifica del proyecto o amplia del programa deberá ser actualizada. Cuando los proyectos son ejecutados bajo contrato o cuando involucran un procuramiento significativo, se debe prestar atención particular al archivar los datos financieros.
Aceptación formal. Documentación que el cliente o patrocinador ha aceptado el producto del proyecto (o fase) deberá ser preparada y distribuida.
Lecciones aprendidas. Las lecciones aprendidas son discutidas en la Sección 4.3.3.3.

NOTAS

Administración de Riesgo del Proyecto

El manejo del riesgo del proyecto incluye los procesos que se preocupan con identificar, analizar, y responder al riesgo del proyecto. Este incluye maximizar los resultados de eventos positivos y minimizar las consecuencias de eventos adversos. La Figura 11-1 provee una vista general de los siguientes procesos principales:

Identificación del Riesgo – determinar que riesgos tienen probabilidad de afectar el proyecto y documentar las características de cada uno.
Cuantificación del Riesgo – evaluar el riesgo y las interacciones del riesgo para cuantificar el rango de posibles resultados del proyecto.
Desarrollo de Respuesta al Riesgo – es definir los pasos de mejoramiento para las oportunidades y respuestas a amenazas.
Control de Respuesta al Riesgo – es responder a cambios en el riesgo a través de la vida del proyecto.

Estos procesos interactuan entre ellos y con otros procesos en otras áreas de conocimiento también. Cada proceso puede involucrar el esfuerzo de uno o más individuos o grupos de individuos basado en las necesidades del proyecto. Cada proceso ocurre generalmente al menos una vez en cada fase del proyecto.

Aunque los procesos se representan aquí como elementos discretos con interfases bien definidas, en la practica estas se pueden traslapar e interactuar en maneras que no se detallan aquí. Las interacciones de procesos se discuten en detalle en el Capitulo 3.

Las diferentes áreas de aplicación utilizan diferentes nombres para los procesos aquí descritos. Por ejemplo:

Identificación del riesgo y cuantificación del riesgo a veces son tratadas como un solo proceso, y el proceso combinado puede ser llamado análisis de riesgo o cuantificación del riesgo.
El desarrollo de la respuesta al riesgo es a veces llamado planeación de respuesta o mitigación de riesgo.
Desarrollo de la respuesta al riesgo y control de respuesta al riesgo son a veces tratadas como un solo proceso, y el proceso combinado puede ser llamado administración del riesgo.

La identificación del riesgo consiste en determinar que riesgos tienen probabilidad de afectar el proyecto y documentar las características de cada uno. La identificación del riesgo no es un evento que ocurra una sola vez; este deberá ser ejecutado sobre una base regular sobre la duración del proyecto.
La identificación del riesgo deberá atender tanto riesgos internos como externos. Los riesgos internos son cosas que el equipo de proyecto puede controlar o influenciar, tales como asignación de staff o estimados de costos. Los riesgos externos son cosas que estas mas halla del control o influencia del equipo del proyecto, tales como cambios en el mercado o acciones gubernamentales.
Hablando estrictamente, el riesgo involucra solo la posibilidad de sufrir daño o perdida. En el contexto del proyecto, sin embargo, la identificación del riesgo también se preocupa con oportunidades (resultados positivos) como también amenazas (resultados negativos).
La identificación del riesgo puede ser lograda al identificar las causas-y-efectos (que podría pasar y que seguiría) o efectos-y-causas (que resultados deben de ser evitados o fomentados y como puede ocurrir cada uno).
1. Entradas a la Identificación del Riesgo
Identificación del Riesgo

Descripción del producto. La naturaleza del producto del proyecto tendrá un gran efecto sobre los riesgos identificados. Productos que involucran una tecnología probada tenderán, siendo todo lo demás igual, a involucrar menos riesgo que productos que requieren innovación o inventos. El riesgo asociado con el producto del proyecto esta muchas veces descrito en términos de su costo e impacto en la programación. La Sección 5.1.1.1. tiene información adicional sobre la descripción del producto.
Otras salidas de la planeación. Las salidas de los procesos de otras áreas de aplicación deben ser revisadas para identificar posibles riesgos. Por ejemplo:

Estructura de desglose de trabajo – las aproximaciones no tradicionales para detallar entregas pueden ofrecer oportunidades que no eran aparentes desde entregas de mas alto nivel identificadas en la declaración del alcance.
Estimados de costos y estimados de duración – estimativos agresivos y estimativos desarrollados con una cantidad de información limitada pueden entrañar mas riesgo.
Plan de staffing – miembros del equipo identificados pueden tener habilidades únicas que serian difíciles de reemplazar o pueden tener otros compromisos que hacen su disponibilidad difícil.
Plan de administración del procuramiento – condiciones del mercado tales como una economía local lenta pueden ofrecer oportunidades para reducir los costos de contratos.

Información histórica. La Información histórica sobre lo que realmente ocurrió en proyectos previos puede ser especialmente útil en identificar riesgos potenciales. Información sobre resultados históricos esta disponible de las siguientes fuentes:

Archivos de proyecto – una o más de las organizaciones involucradas en el proyecto puede mantener archivos de resultados de proyectos previos que son lo suficientemente detalladas para asistir en la identificación de riesgo. En algunas áreas de aplicación, los miembros individuales del equipo pueden mantener dichos archivos.
Bases de datos comerciales – información histórica esta disponible comercialmente en muchas áreas de aplicación.
Conocimiento del equipo del proyecto – los miembros individuales del equipo del proyecto pueden recordar ocurrencias previas o suposiciones. Mientras que tales recolecciones pueden ser de utilidad, son generalmente menos fiables que los resultados documentados.

Herramientas y Técnicas para la Identificación del Riesgo

Listas de chequeo. Las listas de chequeo están organizadas tipicamente por fuente de riesgo. Las fuentes pueden incluir el contexto del proyecto (véase Capitulo 2), otras salidas de procesos (véase la Sección 11.1.1.2.), el producto del proyecto o temas tecnológicos, y fuentes internas tales como las habilidades de los miembros del equipo (o la falta de estas). Algunas áreas de aplicación.
n han usado esquemas de clarificación de manera amplia para las fuentes de riesgo.
Flujogramas. Los flujogramas (descritos en la Sección 8.1.2.3.) pueden ayudar al equipo del proyecto mejor entender las causas y efectos del riesgo.
Entrevistas. Las entrevistas orientadas al riesgo con varios partidos interesados pueden ayudar a identificar riesgos no identificados durante las actividades normales de planeación. Archivos de entrevistas de pre-proyecto (e.g., aquellas conducidas durante los estudios de prefactibilidad) también pueden estar disponibles.

Salidas de la Identificación del Riesgo

Fuentes de riesgo. Las fuentes de riesgo son categorías de posibles eventos de riesgo (e.g., acciones de los partidos interesados, estimativos irrealistas, rotación en el equipo de trabajo) que pueden afectar al proyecto para mejor o peor. La lista de fuentes debe ser comprensiva, i.e., deberá incluir de manera general todos los ítems identificados sin importar su frecuencia, probabilidad de ocurrencia, o magnitud de ganancia o perdida. Fuentes comunes de riesgo incluyen:

Cambios en los requerimientos.
Errores de diseño, omisiones, y mal entendidos.
Roles y responsabilidades pobremente definidas o entendidas.
Estimativos pobres.
Staff poco habilidoso.

Las descripciones de las fuentes de riesgo deberán incluir de manera general estimativos de (a) la probabilidad de que un evento de riesgo de esa fuente va a ocurrir, (b) el rango de posibles resultados, (c) tiempos esperados, y (d) frecuencia anticipada de los eventos del riesgo de esa fuente.

Tanto las probabilidades como los resultados pueden ser especificadas como una función continua (un costo estimado de entre $100,000 y $150,000) o como una discreta (una patente se otorga o no se otorga). Adicionalmente los estimativos de probabilidades y resultados hechos en fases tempranas del proyecto tenderán a tener un rango más amplio que aquellas hechas tarde en el proyecto.

Eventos potenciales de riesgo. Los eventos potenciales de riesgo son ocurrencias discretas tales como desastres naturales o como el retiro de un miembro especifico del equipo que puedan afectar al proyecto. Los eventos potenciales de riesgo deberán ser identificados en adición a la fuente de riesgo cuando la probabilidad de ocurrencia o la magnitud de perdida es relativamente grande ("relativamente grande" podrá variar de proyecto en proyecto). Mientras que los eventos potenciales de riesgo son rara vez específicos a un área de aplicación, una lista de riesgos comunes usualmente lo es. Por ejemplo:

El desarrollo de nuevas tecnologías que obviaran la necesidad de un proyecto es común en la electrónica y muy raro en el desarrollo de bien raíz.
Las perdidas debidas a una gran tormenta son comunes en la construcción pero raras en biotecnología.

Las descripciones de eventos potenciales de riesgo generalmente deberán incluir estimativos de (a) la probabilidad de que ese evento de riesgo ocurrirá, (b) las alternativas de posibles resultados, y (c) los tiempos esperados del evento, y (d) la frecuencia anticipada (i.e., que puede ocurrir mas de una vez).

Tanto las probabilidades como los resultados pueden ser especificadas como funciones continuas (un estimativo de costos entre $100,00 y $150,000) o como discretas (una patente se otorgará o no). Adicionalmente los estimativos de probabilidades y resultados hechos durante las fases tempranas del proyecto tenderán a tener un rango más amplio que aquellas hechas mas tarde en el proyecto.

Síntomas de Riesgo. Los síntomas de riesgo, llamados a veces también gatillos, son manifestaciones indirectas de eventos reales de riesgo. Por ejemplo, una pobre moral puede ser una señal de advertencia temprana de un retraso de programación inminente o los sobre costos en actividades tempranas pueden ser indicativas de una pobre estimación.
Entradas a otros procesos. El proceso de identificación de riesgo puede identificar la necesidad de mas actividad en otra área. Por ejemplo, la estructura de desglose de trabajo puede no tener suficiente detalle para una adecuada identificación de riesgo.

Los riesgos son muchas veces entradas a otros procesos como restricciones o suposiciones.

11.2 Cuantificación del Riesgo

La cuantificación del riesgo involucra el evaluar el riesgo y las interacciones del riesgo para evaluar el rango de posibles resultados del proyecto. Se preocupa principalmente con determinar que eventos de riesgo merecen respuesta. Este proceso es complicado por un número de factores que incluyen, pero que no están limitados a:

Las oportunidades y amenazas pueden interactuar de maneras no anticipadas (e.g., los atrasos de programación pueden forzar considerar una nueva estrategia que reduce de manera general la duración de todo el proyecto).
Un solo evento de riesgo puede causar múltiples efectos, como el causado cuando se presenta una demora en la entrega de componentes claves y esto a su vez genera sobrecostos, retrasos en la programación, pagos de multas, y la entrega de un producto de menor calidad.
Oportunidades para un solo partido interesado (costo reducido) pueden ser amenazas para otro (ganancias reducidas).
Las técnicas matemáticas usadas pueden causar una falsa impresión de precisión y seguridad.

11.2.1 Entradas a la Cuantificación del Riesgo

Tolerancia al riesgo de los partidos interesados. Diferentes organizaciones y diferentes individuos tienen diferentes tolerancia al riesgo. Por ejemplo:

Una compañía altamente rentable estará dispuesta a gastar $500,000 para la elaboración de un contrato de $ 1 billón, mientras que una compañía cerca a su punto de equilibrio no lo estará.
Una organización puede percibir que un estimado que tiene un 15% de sobrepasarse como un alto riesgo, mientras que otra lo percibe como un riesgo bajo.

Las tolerancias al riesgo de los partidos interesados proveen un filtro tanto para las entradas como salidas de la cuantificación del riesgo.

Fuentes de riesgo. Las fuentes de riesgo están descritas en la Sección 11.1.3.1.
Eventos potenciales de riesgo. Los eventos potenciales de riesgo están descritos en la Sección 11.1.3.2.
Estimativos de costo. :Los estimativos de costo están descritos en la Sección 7.2.3.1.
Estimados de duración de las actividades. Los estimativos de duración de las actividades están descritos en la Sección 6.3.3.1.

Herramientas y Técnicas para la Cuantificación del Riesgo

Valor monetario esperado. El valor monetario esperado, como una herramienta para la cuantificación del riesgo, es el producto de dos números:

Probabilidad del evento de riesgo – es un estimado de la probabilidad de que un evento dado de riesgo ocurrirá.
Valor del evento de riesgo – es un estimado de la perdida o ganancia en que se incurrirá si el evento de riesgo si ocurre.

El valor del evento de riesgo debe reflejar tanto los tangibles como intangibles. Por ejemplo, tanto el Proyecto A y el Proyecto B identifican una probabilidad igual de una perdida tangible de $100,000 como el resultado de una propuesta con precio agresivo. Si el Proyecto A predice un efecto intangible o muy pequeño, y el Proyecto B predice que una perdida tal puede poner a su organización fuera del negocio, entonces los dos riesgos no son equivalentes.

De una manera similar, una falla al no incluir intangibles en este calculo puede distorsionar de manera severa el resultado al igualar una pequeña perdida con una alta probabilidad con una gran perdida con una pequeña probabilidad de ocurrir.

El valor monetario esperado es usado generalmente como una entrada pata análisis posteriores (e.g., como en un árbol de decisión) ya que los eventos de riesgo pueden ocurrir individualmente o en grupos, en paralelo o en secuencia.

El rango de los costos totales del proyecto se puede usar para cuantificar el riesgo relativo de alternativas de presupuestales o de alternativas de precios de propuestas. La Figura 11-2 ilustra el uso de la técnica del " método de los momentos" para calculo de los estimativos de rango del proyecto.
Sumas estadísticas. Las sumas estadísticas pueden ser usadas para calcular un rango de los costos totales de proyecto desde los estimativos de costos para los ítemes individuales de trabajo. (Calcular un rango de las fechas probables de terminación del proyecto desde las estimaciones de duración de las actividades requiere el uso de simulaciones tal como se describe en las Sección 11.2.2.3).
Los resultados de una simulación de programación pueden ser usados para cuantificar el riesgo de varias alternativas de programación, de diferentes estrategias de proyecto, de diferentes caminos a través de la red, o de actividades individuales.
Partes: 1, 2, 3, 4, 5, 6, 7

Página anterior

Volver al principio del trabajo

Página siguiente