Monografias.com > Uncategorized
Descargar Imprimir Comentar Ver trabajos relacionados

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

  1. 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.
  2. 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.
  3. Definiciones operacionales. Las definiciones
    operacionales se describen en la Sección
    8.1.3.2.
  1. Herramientas y Técnicas para la
    Aseguranza de la Calidad
  1. 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.
  2. 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

  1. 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

  1. 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.
  2. 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.
  3. Definiciones operacionales. Las definiciones
    operacionales están descritas en la Sección
    8.1.3.2.
  4. Listas de chequeo. Las listas de chequeo
    están descritas en la Sección
    8.1.3.3.
  1. Herramientas y Técnicas para el Control
    de Calidad
  1. 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.

  2. 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.

  3. 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
  4. 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.
  5. 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.
  6. 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

  1. Mejoramiento de la calidad. El mejoramiento de
    la calidad se describe en la Sección 8.2.3.1
  2. 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)
  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.

  4. 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.
  5. 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:

  1. Planeación Organizacional– es
    identificar, documentar, y asignar roles de proyecto,
    responsabilidades, y relaciones de reporte.
  2. Adquisición de Staff – es
    conseguir los recursos humanos necesarios para asignarlos y
    ponerlos a trabajar en el proyecto.
  3. 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.

  1. Entradas a la Planeación
    Organizativa
  1. 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.
  1. 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).
  2. 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.
  1. Herramientas y Técnicas para la
    Planeación Organizacional
  1. 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.
  2. 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.
  3. 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.
  4. 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.
  1. Salidas de la Plantación
    Organizacional.
  1. 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.

  2. 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
  3. 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.
  1. 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.
  2. Una Estructura de Desglose Organizacional (OBS) es
    una tabla organizacional especifica que muestra que unidades
    organizacionales son responsables por que ítems de
    trabajo.

  3. 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.
  1. 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
  2. Adquisición del Staff
  1. 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.
  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?
  1. 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.
  1. Herramientas y Técnicas para la
    Adquisición del Staff
  1. 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.

  1. 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.
  2. 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

  1. 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.
  2. 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.
  1. 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.

  1. Entradas al Desarrollo del
    Equipo
  1. 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.
  2. 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.
  3. Plan de administración del staff. El
    plan de administración del staff esta descrito en la
    Sección 9.1.3.2.
  4. 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.
  5. 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.
  1. Herramientas y Técnicas para el
    Desarrollo del Equipo
  1. 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.
  2. 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.

  3. 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.

  4. 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.
  5. 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).
  6. 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.

  1. Salidas del Desarrollo del
    Equipo
  1. 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.
  1. 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:

  1. 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.
  2. Distribución de la información
    – Es hacer que la información necesitada este
    disponible para los partidos interesados de manera
    oportuna.
  3. 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.
  4. 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

  1. 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).
  1. 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?
  1. 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.
  2. Cuando un proyecto sea ejecutado bajo contrato,
    existe muchas veces provisiones contractuales especificas que
    afectan la planeación de las
    comunicaciones.

  3. 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

  1. 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

  1. 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

  1. Resultados de trabajo. Los
    resultados de trabajo están descritos en la
    Sección 4.2.3.1.
  2. 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.
  3. 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

  1. 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).
  1. 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.
  2. 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.
  1. Salidas de la Distribución de la
    Información
  1. 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.
  1. 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.

  1. Entradas a los Reportes de
    Desempeño
  1. 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.
  2. 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.
  3. 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.
  1. Herramientas y Técnicas para los Reportes
    de Desempeño
  1. 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.
  2. 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.
  3. 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.
  4. 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.

  1. 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.
  1. Salidas de los Reportes de
    Desempeño
  1. 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.

  2. 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.
  3. 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.).
  1. 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
  2. Cierre Administrativo
  1. 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.
  2. 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.
  3. Otros archivos del proyecto. Los archivos del
    proyecto se discuten en la Sección 10.2.3.1.
  1. Herramientas y Técnicas para el Cierre
    Administrativo
  1. 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.
  1. Salidas del Cierre
    Administrativo
  1. 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.
  2. Aceptación formal. Documentación
    que el cliente o patrocinador ha aceptado el producto del
    proyecto (o fase) deberá ser preparada y
    distribuida.
  3. 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:

  1. Identificación del Riesgo –
    determinar que riesgos tienen probabilidad de afectar el
    proyecto y documentar las características de cada
    uno.
  2. Cuantificación del Riesgo –
    evaluar el riesgo y las interacciones del riesgo para
    cuantificar el rango de posibles resultados del
    proyecto.
  3. Desarrollo de Respuesta al Riesgo – es
    definir los pasos de mejoramiento para las oportunidades y
    respuestas a amenazas.
  4. 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.
  1. 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
  2. Identificación del Riesgo
  1. 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.
  2. 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.
  1. 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.
  1. Herramientas y Técnicas para la
    Identificación del Riesgo
  1. 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.
  2. n han usado esquemas de clarificación de
    manera amplia para las fuentes de riesgo.
  3. 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.
  4. 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.
  1. Salidas de la Identificación del
    Riesgo
  1. 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.

  1. 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.

  1. 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.
  2. 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

  1. 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.

  1. Fuentes de riesgo. Las fuentes de riesgo
    están descritas en la Sección
    11.1.3.1.
  2. Eventos potenciales de riesgo. Los eventos
    potenciales de riesgo están descritos en la
    Sección 11.1.3.2.
  3. Estimativos de costo. :Los estimativos de
    costo están descritos en la Sección
    7.2.3.1.
  4. 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.
  1. Herramientas y Técnicas para la
    Cuantificación del Riesgo
  1. 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.

  1. 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.

  2. 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 trabajoPágina siguiente 

Nota al lector: es posible que esta página no contenga todos los componentes del trabajo original (pies de página, avanzadas formulas matemáticas, esquemas o tablas complejas, etc.). Recuerde que para ver el trabajo en su versión original completa, puede descargarlo desde el menú superior.

Todos los documentos disponibles en este sitio expresan los puntos de vista de sus respectivos autores y no de Monografias.com. El objetivo de Monografias.com es poner el conocimiento a disposición de toda su comunidad. Queda bajo la responsabilidad de cada lector el eventual uso que se le de a esta información. Asimismo, es obligatoria la cita del autor del contenido y de Monografias.com como fuentes de información.

Categorias
Newsletter