Monografias.com > Uncategorized
Descargar Imprimir Comentar Ver trabajos relacionados

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




Enviado por rsanchez



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

Procesos de Núcleo. Algunos procesos de
planeación tienen claras dependencias que requieren que
sean ejecutados de la misma manera en la mayoría de los
proyectos. Por ejemplo, las actividades deben ser definidas antes
de que sean programadas o costeadas. Estos procesos de
planeación de núcleo pueden ser iterados varias
veces durante una o cualquier fase de un proyecto. Estos
incluyen:

  • Planeación de Alcance (5.2) —
    desarrollar un alcance escrito como la base para decisiones
    futuras del proyecto.
  • Definición del Alcance (5.3) —
    subdividir los paquetes de entrega de un proyecto en
    componentes más pequeños y más
    manejables.
  • Definición de Actividades (6.1) —
    identificar las actividades específicas que deben de
    ser ejecutadas para producir los diferentes paquetes del
    proyecto.
  • Secuencias de Actividades (6.2) — identificar
    y documentar las dependencias entre actividades.
  • Estimación de la Duración de la
    Actividad (6.3) — estimar el número de
    períodos de trabajo que se requieren para completar
    las actividades individuales.
  • Desarrollo de la programación (6.4) —
    analizar las secuencias de actividades, duraciones de
    actividades, y requerimientos de recursos para crear la
    programación del proyecto.
  • Planeación de Recursos (7.1) —
    determinar que recursos (personas, equipos, materiales) y en que cantidades se deben usar
    para ejecutar las actividades del proyecto.
  • Estimación de Costos (7.2) —
    desarrollar una aproximación (estimación) de
    los costos de los recursos que se requieren para completar
    las actividades del proyecto.
  • Presupuestación de Costos (7.3) —
    distribuir el estimativo de costos global a los ítems
    individuales de trabajo.
  • Desarrollo de Plan de Proyecto (4.1) — tomar
    los resultados de otros procesos de planeación y
    colocarlos en un documento consistente y
    coherente.

Procesos Facilitadores. La interacciones entre
los otros procesos de planeación dependen más de la
naturaleza del proyecto. Por ejemplo, en algunos proyectos puede
haber poco o ningún riesgo identificable hasta
después que el equipo ha hecho la mayor parte de la
planeación, y este reconoce que los costos y las fechas
programadas son extremadamente agresivas y por lo tanto
involucran un riesgo considerable. Aunque estos procesos
facilitadores son ejecutados intermitentemente en la medida que
lo necesite la planeación del proyecto, no son opcionales.
Ellos incluyen:

  • Planeación de la Calidad (8.1) —
    identificar cual es el standard de la calidad que es
    relevante al proyecto y determinar como
    satisfacerlo.
  • Planeación Organizacional (9.1) —
    identificar, documentar, asignar roles de proyecto,
    responsabilidades, y relaciones para los
    reportes.
  • Adquisición del Staff (9.2) —
    conseguir los recursos
    humanos y asignarlos al trabajo del proyecto.
  • Planeación de las Comunicaciones (10.1)
    — determinar que información y comunicaciones se
    necesitan para los partidos interesados: Quien necesita que
    información, cuando la van a necesitar, y de que
    manera se les va a dar.
  • Identificación del Riesgo (11.1) —
    determinar que riesgos tendrán posibilidad de afectar
    el proyecto y documentar las características de cada
    uno.
  • Cuantificación del Riesgo (11.2) —
    evalúa el riesgo y las interacciones del riesgo para
    cuantificar el rango de posibles resultados del
    proyecto.
  • Desarrollo de Respuesta al Riesgo (11.3) —
    definir pasos constructivos para dar respuesta a
    oportunidades o respuestas a amenazas.
  • Planeación de la procuración (12.1)
    — determinar que comprar y cuanto.
  • Planeación de Solicitación (12.2)
    — documentar requerimientos de producto e identificar
    posibles proveedores.

Procesos de Ejecución

Los procesos de ejecución incluyen procesos de
núcleo y procesos facilitadores tal como se describe en la
Sección 3.3.2., Procesos de Planeación. La
Figura 3-6 ilustra como los siguientes procesos
interactúan:

  • Plan de Ejecución del Proyecto (4.2) —
    llevar a cabo el plan del proyecto al ejecutar las
    actividades incluidas.
  • Verificación del Alcance (5.4.) —
    formalizar la aceptación del alcance del
    proyecto.
  • Aseguranza de la Calidad (8.2) — evaluar la
    totalidad de la ejecución del proyecto sobre una base
    regular para proveer la confianza de que el proyecto va a
    satisfacer los standard de calidad relevantes.
  • Desarrollo del Equipo (9.3) — desarrollar
    habilidades individuales o de grupo para mejorar la
    ejecución del proyecto.
  • Distribución de la información (10.2)
    — hacer que la información solicitada sea
    disponible para los partidos interesados de manera
    oportuna.
  • Solicitación (12.3) — obtener
    cotizaciones, pliegos, ofertas, u ofertas de manera apropiada
    .
  • Selección de Fuentes
    (12.4) — el proceso de escogencia entre proveedores
    potenciales.
  • Administración del Contrato (12.5) —
    administrar la relación con el proveedor.

Procesos de Control

La ejecución del proyecto debe ser medida
regularmente para identificar varianzas significativas con el
plan. Estas varianzas son alimentadas a los procesos de control en las
diferentes áreas del conocimiento. En la medida que estas
varianzas significativas sean observadas (i.e., aquellos que
pongan en jaque los objetivos del proyecto), ajustes al plan son
hechos al repetir los procesos de planeación apropiados.
Por ejemplo, una fecha de terminación de una actividad que
no se cumpla puede requerir ajustes al plan de personal
existente, depender de horas extras, o hacer un intercambio entre
el presupuesto y los
objetivos de la programación. Controlar también
incluye tomar acción preventiva de forma anticipada a
problemas posibles.

El grupo de procesos controladores contiene procesos de
núcleo y procesos facilitadores tal como se describe en la
Sección 3.3.2. Procesos Planificadores.

La Figura 3-7 ilustra como los siguientes
procesos interactúan:

  • Control de Cambios General (4.3) — coordinar
    los cambios a través de todo el proyecto.
  • Control de Cambio del Alcance (5.5.) —
    controlar los cambios del alcance del proyecto.

  • Control de Programación (6.5) —
    controlar los cambios hechos a la programación del
    proyecto.
  • Control de Costos (7.4) — controlar los
    cambios en el presupuestos del proyecto.
  • Control de Calidad (8.3.) — monitorear
    resultados específicos del proyecto para determinar si
    estos cumplen con los standards de calidad pertinentes e
    identificar maneras para eliminar causas de ejecución
    no satisfactorias.
  • Reportes de Desempeño (10.3) —
    colectar y diseminar información de la
    ejecución. Esto incluye reportar el status,
    medición del avance, y pronósticos.
  • Control de la Respuesta al Riesgo (11.4) —
    responder a cambios en el riesgo a través del
    proyecto.

Procesos de Cierre

La Figura 3-8 ilustra como los siguientes
procesos interactúan:

  • Cierre Administrativo (10.4) — generar,
    recoger, y diseminar información para formalizar el
    cierre de una fase o de terminación de un
    proyecto.
  • Cierre del Contrato (12.6) — completar y
    negociar un contrato, incluyendo la resolución de
    cualquier ítem abierto.

Personalizar los Procesos de
Interacción

Los procesos identificados y las interacciones
ilustradas en la Sección 3.3 pasan el examen de la
aceptación general – estos se aplican a la mayoría
de los proyectos la mayoría de las veces. Sin embargo, no
todos los procesos se necesitaran en todos los proyectos, y no
todas las interacciones aplicaran a todos los proyectos. Por
ejemplo:

  • Una organización que haga uso extensivo de
    contratistas puede describir explícitamente en que
    lugar del proceso de planeación ocurren los procesos
    de procuración.
  • La ausencia de un proceso no significa que este no
    deba ser ejecutado. El equipo de administración del
    proyecto debe identificar y administrar todos los procesos
    que se requieren para asegurar un proyecto
    exitoso.
  • Los proyectos que son dependientes de recursos
    únicos (desarrollo comercial de software,
    biofarmacéuticos, etc.) pueden definir roles y
    responsabilidades previas a la definición del alcance,
    ya que lo que se puede ejecutar puede ser una función
    de quien esta disponible para hacerlo.
  • Algunas salidas de procesos pueden ser predefinidas
    como restricciones. Por ejemplo, la administración
    puede especificar una fecha meta de terminación en vez
    de dejar que sea determinada por el proceso de
    planeación.
  • Los proyectos grandes pueden necesitar
    relativamente más detalle. Por ejemplo, la
    identificación del riesgo puede ser subdividida para
    enfocarse separadamente sobre identificación de
    riesgos de costo, riesgos de programación, riesgos
    técnicos, o riesgos de calidad.
  • En subproyectos o proyectos más
    pequeños puede haber relativamente menos esfuerzo en
    procesos cuyas salidas han sido determinadas a nivel del
    proyecto (e.g., un subcontratista puede ignorar riesgos
    explícitamente asumidos por el contratista general) o
    en procesos que proveen solamente una utilidad marginal
    (puede no haber un plan formal de comunicaciones para un
    proyecto de cuatro personas).
  • Donde haya necesidad de hacer un cambio, el cambio
    debe ser claramente identificado, cuidadosamente evaluado y
    administrado de manera activa.

NOTAS

Administración de la Integración de Proyectos

La Administración de La Integración del
Proyecto incluye los procesos requeridos para asegurar que los
elementos varios del proyecto están apropiadamente
coordinados. Involucra hacer canjes entre los objetivos que
compiten entre si y alternativas de manera que se puedan cumplir
o exceder las necesidades y expectativas de los partidos
interesados. Mientras que todos los procesos
administrativos del proyecto son integrativos hasta cierto
punto, los procesos descritos en este capítulo son
primariamente integrativos. La Figura 4-1 muestra una
vista general de los principales procesos.

4.1 Desarrollo del Plan del Proyecto — es
tomar los resultados de otros procesos de planeación y
colocarlos en un solo documento consistente y
coherente.

4.2 Ejecución del Plan del Proyecto
— es desarrollar el plan del proyecto al ejecutar las
actividades incluidas.

4.3 Control de Cambios General — es
coordinar los cambios a través del proyecto.

Estos procesos interactúan entre ellos y con
otros procesos de otras áreas de conocimiento. Estos
procesos pueden involucrar el esfuerzo de uno o más
individuos o de grupos de individuos basados en las necesidades
del proyecto. Cada procesos ocurre al menos una vez en cada fase
del proyecto.

Aunque los procesos presentados aquí se muestran
como elementos discretos con interfaces bien definidas, en la
práctica se pueden traslapar e interactuar en maneras que
no se detallan aquí. Los procesos de interacción se
discuten en detalle en el Capítulo 3.

Los procesos, herramientas,
y técnicas usadas para integrar los procesos
administrativos del proyecto son el enfoque de este
capítulo. Por ejemplo, la administración de
integración del proyecto entra a jugar cuando un
estimativo de costos se necesita para un plan de contingencia o
cuando se debe identificar el riesgo asociado a varias
alternativas de asignación de personal al proyecto. Sin
embargo, para que un proyecto se pueda completar exitosamente, la
integración debe ocurrir en un número de otras
áreas también. Por ejemplo:

  • El trabajo del proyecto debe ser integrado con las
    operaciones sucesivas de la organización
    ejecutora.
  • El alcance del proyecto y alcance del producto
    deben ser integrados (la diferencia entre el alcance del
    producto y el proyecto se discute en la introducción
    del Capítulo 5).
  • Productos de diferentes especialidades funcionales
    (tales como dibujos
    civiles, eléctricos, y mecánicos que se
    necesitan para un proyecto de diseño de
    ingeniería) deben ser integrados.

Desarrollo del Plan del
Proyecto

El desarrollo del plan del proyecto usa las salidas de
otros procesos de planeación para crear un documento
único consistente y coherente que puede ser usado para
guiar tanto la ejecución del proyecto como el control de
este. Estos procesos casi siempre se iteran varias veces. Por
ejemplo, el borrador inicial puede incluir recursos
genéricos y duraciones sin fecha mientras que el plan
final refleja recursos específicos y fechas
explícitas. El plan de proyectos se usa para:

  • Ejecución guiada del proyecto
  • Cosas que se asumen del documento de
    planeación del proyecto.
  • Decisiones del documento de planeación del
    proyecto referentes a las alternativas que se
    toman.
  • Facilitar la comunicación entre partidos
    interesados.
  • Definir puntos de vista claves administrativos
    respecto al contenido, extensión, y
    tiempo.
  • Proveer una línea de base para medir el
    progreso y control del proyecto.

4.1.1 Entradas al Desarrollo del Plan del
Proyecto

  1. Otras salidas de
    planeación
    . Todas las salidas de los
    procesos de planeación de las otras área de
    conocimiento (La Sección 3.3 provee un resumen de estos
    procesos de planeación de proyectos) son entradas para
    desarrollar el plan del proyecto. Otras salidas de
    planeación incluyen tanto documentos base tales como la
    estructura de desglose del proyecto como el detalle de soporte.
    Muchos proyectos también requieren la aplicación
    de entradas de áreas específicas (e.g., la
    mayoría de los proyectos de construcción
    necesitarán una proyección del flujo de
    caja).
  2. Información histórica. La
    información histórica disponible (e.g., bases de datos
    de la estimación, récords de ejecución de
    proyectos pasados) debe ser consultada durante los otros
    procesos de planeación. Esta información debe
    estar disponible durante el desarrollo del plan del proyecto
    para que pueda asistir con la verificación de lo que se
    asume y valorar otras alternativas que se identifican como
    parte de este proceso.
  3. Políticas organizacionales. Todas o
    algunas de las organizaciones involucradas en el proyecto
    pueden tener políticas formales o informales cuyos
    efectos se deben considerar. Políticas organizacionales
    que típicamente deben ser consideradas incluyen, pero no
    se limitan a:
  • Administración de la calidad —
    procesos de auditoria y metas de mejoramiento
    continuo.
  • Administración de personal —
    guías para contratación y despidos, y métodos para la evaluación de personal.

  • Controles financieros — reportes de tiempo,
    revisiones al control de egresos y flujos de caja,
    métodos y procedimientos de contaduría,
    provisiones standard para contratos.
  1. Restricciones. Las restricciones son factores
    que van a limitar las opciones del equipo administrativo del
    proyecto. Por ejemplo, un presupuesto predefinido es una
    restricción que muy probablemente limitará las
    opciones del equipo del proyecto en lo concerniente a alcance,
    asignación de personal, y
    programación.
  2. Cuando un proyecto es ejecutado bajo un contrato,
    las provisiones contractuales generalmente serán
    restricciones a esta.

  3. Suposiciones. Las suposiciones son factores
    que para los procesos de planeación serán
    consideras como verdaderas, reales, o ciertas. Por ejemplo, si
    la fecha en que una persona clave
    estará disponible es incierta, el equipo puede asumir
    una fecha de comienzo específica. Las suposiciones
    generalmente involucran algún grado de
    riesgo.

4.1.2 Herramientas y Técnicas para el
Desarrollo del Plan del Proyecto

  1. Metodología de planeación del
    proyecto
    . Una metodología para la planeación del
    proyecto es cualquier aproximación estructurada que se
    usa para guiar al equipo de administración del proyecto
    durante el desarrollo del plan del proyecto. Puede ser tan
    simple como formas standard o preimpresas (ya sean de papel o
    electrónicas formales o informales) o tan complejas como
    una serie de simulaciones requeridas (e.g., análisis de
    Montecarlo para riesgo). La mayoría de las
    metodologías para planeación de proyectos hacen
    uso de una combinación de herramientas "duras" tales
    como software de administración de proyectos y
    herramientas "blandas" tales como comités facilitadores
    e iniciadores.
  2. Habilidades y conocimientos de los partidos
    interesados
    . Cada partido interesado tiene habilidades y
    conocimientos que pueden ser de uso en el desarrollo del plan
    del proyecto. El equipo administrador del proyecto debe crear
    un ambiente en el cual los partidos interesados puedan
    contribuir apropiadamente (véase también la
    Sección 9.3, Desarrollo del Equipo). Quien contribuye, y
    que contribuyen, y como puede variar. Por ejemplo:
  • En un proyecto en construcción bajo un
    contrato de suma global, el ingeniero de costo profesional
    hará una contribución significativa a la meta de
    rentabilidad durante la preparación de
    la licitación cuando el valor del
    contrato este siendo determinado.
  • En un proyecto donde la asignación de
    personal se define de antemano, los contribuyentes
    individuales pueden contribuir significativamente para
    alcanzar las metas de costos y programación al evaluar
    duraciones y esfuerzos para que los estimativos sean
    razonables.
  1. Sistemas de información de
    administración de proyectos (PMIS).
    Un sistema de
    información para administración de proyectos
    consiste de las herramientas y técnicas usadas para
    recoger, integrar, y diseminar las salidas de los otros
    procesos de administración de proyectos. Se usa para
    darle soporte a todos los aspectos del proyecto desde su
    iniciación hasta su finalización y generalmente
    incluye tanto sistemas automáticos como manuales.

4.1.3 Salidas del Desarrollo del Plan del
Proyecto

  1. Plan del proyecto. El plan del proyecto es un
    documento formal, aprobado, usado para administrar y controlar
    la ejecución del proyecto. Debe ser distribuido como se
    define en el plan de comunicaciones del proyecto (e.g., la
    administración de la organización ejecutora puede
    requerir una cobertura amplia con poco detalle, mientras que un
    contratista puede requerir detalles completos de un solo tema).
    En algunas áreas de aplicación, el término
    plan de proyecto integrado se usa para referirse a este
    documento.

Se debe hacer una distinción clara entre el plan
del proyecto y la línea de base para la medición de
la ejecución del proyecto. El plan del proyecto es un
documento o colección de documentos que se espera que
cambie varias veces sobre el tiempo a medida que más
información se hace disponible sobre el proyecto. La
línea de base para la medición de la
ejecución representa un control administrativo que
generalmente solo cambia intermitentemente y generalmente solo en
respuesta a un cambio aprobado del alcance del
proyecto.

Hay muchas maneras para organizar y presentar el plan
del proyecto, pero comúnmente incluye todos los siguientes
(estos ítems se describen en más detalle en otro
lugar del documento):

  • Charter del proyecto.
  • Una descripción de la aproximación o
    estrategia administrativa del proyecto (un resumen de los
    planes individuales de las otras áreas de
    conocimiento).
  • Un documento de alcance, que incluye tanto los
    productos del proyecto como los objetivos de
    este.
  • Una estructura de desglose de trabajo (WBS) hasta
    el nivel en el que el control será
    ejecutado.
  • Estimativos de costos, fechas programadas de
    comienzo, y la asignación de responsabilidades hasta
    el nivel en el que se ejecutará el control al
    WBS.
  • Líneas de base para la medición de la
    ejecución del cronograma y costos.
  • Hitos principales y las fechas metas para
    estos.
  • Personal clave o requerido.
  • Riesgos claves, incluyendo restricciones y
    suposiciones, y las respuestas planeadas para cada una de
    ellas.
  • Planes administrativos subsidiarios, incluyendo
    planes administrativos y de alcance, plan de
    administración del cronograma, etc.
  • Decisiones pendientes y otros temas
    abiertos.
  • Otras salidas de la planeación del proyecto
    deben ser incluidas en el plan formal basado en las
    necesidades individuales de cada proyecto. Por ejemplo, el
    plan de proyecto para un proyecto grande generalmente incluye
    un organigrama del proyecto.
  1. Detalle de soporte. El detalle de soporte para
    el plan de proyecto incluye:
  • Salidas de otros procesos de planeación que
    no están incluidos en el plan del
    proyecto.
  • Información adicional o documentación generada durante el
    desarrollo del plan del proyecto (e.g., restricciones y
    suposiciones que no eran previamente conocidas).
  • Documentación técnica tal como
    requerimientos, especificaciones, y
    diseños.
  • Documentación de standards
    relevantes.

Este material debe ser organizado de tal manera que se
facilite su uso durante la ejecución del plan del
proyecto.

  1. Ejecución del Plan del Proyecto

La ejecución del plan del proyecto es el proceso
primario para llevar a cabo el plan del proyecto – la gran
mayoría del presupuesto del proyecto será utilizado
al ejecutar este proceso. En este proceso, el administrador de
proyectos y el equipo de administración de proyectos deben
coordinar y dirigir las varias interfaces técnicas y
organizacionales que existan en el proyecto. Es el proceso del
proyecto que más directamente se ve afectado por el
área de aplicación del proyecto debido a que el
producto del proyecto es creado directamente
aquí.

  1. Entradas a la Ejecución del Plan del
    Proyecto
  1. Plan del proyecto. El plan del
    proyecto esta descrito en la Sección 4.1.3.1. Los planes
    subsidiarios de administración (plan de
    administración del alcance, plan de manejo de riesgo,
    plan de gestión de compras,
    etc.) y las líneas de base para la medición del
    avance son entradas claves para la ejecución del plan
    del proyecto.
  2. Detalle de soporte. El detalle de soporte esta
    descrito en la Sección 4.1.3.2.
  3. Políticas Organizacionales. Las
    políticas organizacionales están descritas en la
    Sección 4.1.1.3. Alguna o todas de las organizaciones
    involucradas en el proyecto pueden tener políticas
    formales e informales que pueden afectar al plan de
    ejecución del proyecto.
  4. Acción Correctiva. La acción
    correctiva es cualquier cosa que se haga para traer la
    ejecución futura del proyecto en línea con el
    plan del proyecto. La acción correctiva es una salida de
    varios procesos de control – como una entrada aquí,
    completa el círculo "loop" de retroalimentación
    para asegurar una administración efectiva del
    proyecto.
  1. Herramientas y Técnicas para la
    Ejecución del Plan del Proyecto
  1. Habilidades de administración general.
    Habilidades de administración general tales como
    liderazgo, comunicación, y negociación son
    esenciales para la ejecución efectiva del plan del
    proyecto. Las Habilidades de administración general
    están descritas en la Sección 2.4.
  2. Habilidades del producto y conocimiento. El
    equipo del proyecto debe tener acceso a unas habilidades y
    conocimiento del producto del proyecto que sean adecuadas.
    Las habilidades necesarias son definidas como parte de la
    planeación (especialmente en la planeación de
    recursos, Sección 7.1.) y se provee a través
    del proceso de adquisición de personal (tal como se
    describe en la Sección 9.2.)

    El diseño del sistema de autorización
    de trabajo deberá balancear el valor del control que
    provee con el costo de ese control. Por ejemplo, en proyectos
    pequeños las autorizaciones verbales serán
    adecuadas.

  3. Sistema de autorización de trabajo. Un
    sistema de autorización de trabajo es un procedimiento
    formal para sancionar el trabajo del proyecto para asegurar que
    un trabajo se hace en el momento adecuado y en una secuencia
    apropiada. El mecanismo primario es típicamente una
    autorización escrita para comenzar trabajo en una
    actividad específica o paquete de trabajo.
  4. Reuniones para evaluación del status.
    Las reuniones para evaluación del status son reuniones
    programadas regularmente las cuales se sostienen para
    intercambiar información sobre el proyecto. En la
    mayoría de los proyectos estas reuniones se
    sostendrán a diferentes frecuencias a diferentes niveles
    (e.g., el equipo administrativo del proyecto sostendrá
    reuniones internas semanalmente, y mensualmente con el
    dueño).
  5. Sistema de información de
    administración del proyecto
    . El sistema de
    información de administración del proyecto se
    describe en la Sección 4.1.2.3.
  6. Procedimientos organizacionales. Todas y
    algunas de las organizaciones involucradas en el proyecto
    pueden tener procedimientos formales o informales de utilidad
    durante la ejecución del proyecto.
  1. Salidas del Plan de Ejecución del
    Proyecto
  1. Resultados del trabajo. Los resultados del
    trabajo son los resultados de las actividades ejecutadas para
    llevar a cabo el proyecto. La información sobre los
    resultados del trabajo – que metas han sido completadas y
    cuales no, y hasta que punto se cumplen las normas de calidad,
    y en que costos se ha incurrido o comprometido, etc. – se
    recolectan como parte del plan de ejecución del proyecto
    y se alimentan al proceso de reporte de avance (vea la
    Sección 10.3. para una discusión más
    detallada de los reportes de avance).
  2. Ordenes de cambio. Las ordenes de cambio
    (e.g., para expandir o contraer el alcance del proyecto, para
    modificar costos o estimativos del cronograma, etc.) muchas
    veces se identifican mientras que se ejecuta el trabajo del
    proyecto.
  1. Control de Cambios General

El control de cambios general se preocupa con (a)
influenciar los factores que crean cambios para asegurar que los
cambios son beneficiosos, (b) determinar que un cambio a
ocurrido, y (c) administrar los cambios reales cuando y como
ocurren. El control de cambios general requiere:

  • Mantener la integridad de las líneas de base
    para la medición de avance – todos los cambios
    aprobados se deberán reflejar en el plan del proyecto,
    pero solo los cambios al alcance del proyecto deberán
    afectar la línea de base para la medición de
    avance.
  • Asegurarse que los cambios al alcance del producto
    se reflejen en la definición del alcance del proyecto
    (la diferencia entre el alcance del proyecto y del producto
    se discute en la introducción al Capítulo
    5).
  • Coordinar los cambios a través de las
    áreas del conocimiento como se ilustra en la Figura
    4-2
    . Por ejemplo, un cambio propuesto al cronograma
    muchas veces afectará al costo, riesgo, calidad y
    personal.

  1. Entradas al Control de Cambios
    General
  1. Plan del proyecto. El plan del
    proyecto provee una línea de base contra la cual los
    cambios se controlan (véase Sección
    4.1.3.1.).
  2. Reportes de desempeño. Los reportes de
    desempeño (descritos en la Sección 10.3) proveen
    información sobre la ejecución del proyecto. Los
    reportes de ejecución pueden también alertar al
    equipo del proyecto sobre temas que pueden causar problemas en
    el futuro.
  3. Propuestas de cambio. Las propuestas de cambio
    pueden ocurrir de muchas maneras – orales o escritas, directas
    o indirectas, iniciadas interna o externamente, requeridas
    legalmente u opcionales.
  1. Técnicas y Herramientas para el Control
    de Cambios General
  1. En muchos casos, la organización ejecutora
    tendrá un sistema de control de cambios que
    podrá ser adoptado "tal como esta" para uso en el
    proyecto. Sin embargo, si un sistema apropiado no esta
    disponible, el equipo de ejecución del proyecto
    tendrá necesidad de desarrollar uno como parte del
    proyecto.

    La mayoría de los sistemas de
    control de cambios incluyen un comité de control
    de cambios (CCC) responsable por aprobar o rechazar
    propuestas de cambio. Los poderes y responsabilidades de un
    CCC deberán ser bien definidos y acordados por los
    partidos interesados en el proyecto. En proyectos grandes y
    complejos, podrán haber múltiples CCC con
    diferentes responsabilidades.

    El sistema de control de cambios deberá
    incluir procedimientos para manejar cambios que podrán
    ser aprobados sin revisión previa; por ejemplo, como
    resultado de una emergencia. Típicamente, un sistema
    de control de cambios permitirá aprobaciones
    "automáticas" de categorías de cambios
    predefinidas. Estos cambios sin embargo deberán ser
    documentados y capturados de tal manera que no causen
    problemas luego en el proyecto.

  2. Sistema de control de cambios. Un sistema de
    control de cambios es una colección de procedimientos
    formales, documentados que definen los pasos por los cuales
    documentos oficiales de proyectos pueden ser modificados. Este
    incluye el papeleo, sistema de seguimiento, y niveles de
    aprobación necesarios para aprobar los
    cambios.
  3. Administración de la
    configuración
    . La administración de la
    configuración es cualquier procedimiento documentado
    usado para aplicar vigilancia y dirección técnica
    administrativa a:
  • Identificar y documentar las características
    físicas y funcionales de un ítem o
    sistema.
  • Controlar cualquier cambio a tales
    características.
  • Grabar y reportar el cambio y su status de
    implementación.
  • Auditar los ítemes y sistemas para verificar
    su adhesión a los requerimientos [1].

En muchas áreas de aplicación la
administración de la configuración es un subjuego
del sistema de control de cambios y se usa para asegurar que la
descripción del producto del proyecto está correcta
y completa. Sin embargo, en algunas áreas de
aplicación, el término administración de la
configuración se usa para describir cualquier sistema de
control de cambios riguroso.

  1. Medición de la ejecución. Las
    técnicas para la medición de la ejecución
    tales como el valor ganado (tal como se describe en la
    Sección 10.3.2.4.) ayudan a averiguar si las varianzas
    del plan original requieren acción
    correctiva.
  2. Planeación adicional. Los proyectos
    raras veces se ejecutan exactamente de acuerdo con el plan.
    Cambios posibles tal vez requieran de costos estimados nuevos o
    revisados, secuencias de actividad modificadas, análisis
    de respuesta de riesgos alternativas, u otros ajustes al plan
    del proyecto.
  3. Sistema de información de
    administración de proyectos
    . Los sistemas de
    información de administración de proyectos se
    describen en la Sección 4.1.2.3.
  1. Salidas del Control de Cambios
    General
  1. Actualizaciones al plan de proyectos. Las
    actualizaciones al plan de proyectos son cualquier
    modificación al contenido del plan de proyectos al
    detalle de soporte (tal como se describe en las Secciones
    4.1.3.1. y 4.1.3.2., respectivamente) los partidos interesados
    apropiados se notificaran en la medida que sean
    necesario.
  2. Acción correctiva. La acción
    correctiva se describe en la Sección
    4.2.1.4.
  3. Lecciones aprendidas. Las causas de las
    varianzas, el raciocinio detrás de las acciones
    correctivas escogidas, y otros tipos de lecciones aprendidas
    deberán ser documentadas para que estas se vuelvan parte
    de la base de datos
    histórica tanto para este proyecto como para otros
    proyectos de la organización ejecutora

NOTAS

Administración del Alcance del
Proyecto

La administración del alcance del proyecto
incluye los procesos requeridos para asegurar que el proyecto
incluye todo trabajo requerido, y solo el trabajo requerido, para
completar el proyecto exitosamente [1]. Se preocupa primariamente
con definir y controlar que y que no se incluye en el proyecto.
La Figura 5-1 provee una vista general de los principales
procesos de la administración del alcance del
proyecto:

5.1 Iniciación — es comprometer a
la organización para el comienzo de la siguiente fase
del proyecto.

5.2 Planeación del Alcance — es
desarrollar un documento escrito del alcance que sirva de base
para la toma de decisiones futuras del proyecto.

5.3 Definición del Alcance — es
subdividir los principales productos de entrega del proyecto en
componentes más pequeños y manejables.

5.4 Verificación del Alcance — es
formalizar la aceptación del alcance del
proyecto.

5.5 Control de
Cambio del Alcance
—es controlar los cambios al
alcance del proyecto.

Estos procesos interactuan entre ellos y con otros
procesos de otras áreas de conocimiento. 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 aquí se presentan como
elementos discretos, con interfaces bien definidas, en la
práctica ellos se pueden traslapa e interactúa de
maneras que no se detallan aquí.

Los procesos de interacción se discuten en
detalle en el Capítulo 3.

En el contexto del proyecto, el término "alcance"
se refiere a:

  • Alcance del producto – los rasgos distintivos y
    funciones que
    se deberán incluir en el producto servicio
  • Alcance del proyecto – el trabajo que se
    deberá hacer para la entrega de un producto con
    ciertas especificaciones y funciones.

Los procesos, herramientas y técnicas usados para
administrar el alcance del proyecto son del enfoque de este
capítulo. Los procesos, herramientas, y técnicas
usadas para administrar el alcance del producto varían de
acuerdo con el área de aplicación y usualmente
están definidos como parte del ciclo de vida del proyecto
(el ciclo de vida del proyecto se discute en la Sección
2.1.).

Un proyecto consiste de un solo producto, pero ese
producto puede incluir elementos subsidiarios, cada uno con su
alcance del producto por separado pero interdependiente con los
demás. Por ejemplo, un nuevo sistema telefónico
generalmente incluiría cuatro elementos subsidiarios –
Hardware,
Software, entrenamiento e
implementación del sistema.

La terminación del alcance del producto se mide
contra sus requerimientos mientras que la terminación del
alcance del proyecto se mide contra el plan. Ambos tipos de
administración de alcance deben estar bien integrados para
asegurar que el trabajo del proyecto resultará en la
entrega del producto especificado.

Iniciación

La iniciación es el proceso de reconocer
formalmente que un nuevo proyecto existe o que un proyecto
existente debe continuar a su siguiente fase (Véase la
Sección 2.1. para una discusión más
detallada de las fases de un proyecto). Esta iniciación
formal concatena el proyecto con el trabajo en marcha de la
organización ejecutora. En algunas organizaciones, un
proyecto no es formalmente iniciado hasta después de la
terminación de un estudio de factibilidad, un plan
preliminar, o algún otro tipo de análisis
equivalente que en si fue iniciado por separado. Algunos tipos de
proyectos, en especial proyectos de servicio interno y proyectos
de desarrollo de nuevos productos, son iniciados de manera
informal y una cantidad limitada de trabajo es ejecutada para
asegurar los permisos necesarios para su iniciación
formal. Los proyectos son autorizados típicamente como
resultado de una o más de las siguientes:

  • Una demanda
    del mercado (e.g., una compañía petrolera
    autoriza la construcción de una nueva refinería
    en respuesta a una escasez crónica de
    gasolina).
  • Una necesidad del negocio (e.g., una
    compañía de entrenamiento autoriza crear un
    nuevo curso para poder incrementar sus entradas).
  • Una demanda de un cliente (e.g., una empresa
    de servicios públicos autoriza construir una nueva
    subestación, para prestarle el servicio a un nuevo
    parque industrial).
  • Un avance tecnológico (e.g., una firma
    electrónica autoriza un nuevo proyecto para
    desarrollar un nuevo juego de vídeo, después de
    la introducción de una grabadora de casetes de
    vídeo).
  • Un requerimiento legal (e.g., un productor de
    pinturas autoriza un proyecto para establecer las
    guías para el manejo de sustancias
    tóxicas).

Estos estímulos también se pueden llamar
problemas, oportunidades, o requerimientos del negocio. El tema
central de todos estos términos es que la
administración debe tomar una decisión acerca de
como responder a ellos.

5.1.1 Entradas para la
Iniciación

  1. Descripción del producto.
    Los documentos de descripción del producto describen las
    características del producto o servicio que fue elegido
    para crearse. La descripción del producto generalmente
    tendrá menos detalles en sus fases tempranas y
    más detalle en las fases subsiguientes a medida que las
    características del producto son elaboradas
    progresivamente.
  2. La descripción del producto también
    documentará la relación entre el producto o
    servicio creado y la necesidad del negocio u otro estimulo
    que dio pie para la creación del proyecto
    (Véase la lista anterior). Mientras que la forma y la
    sustancia de la descripción del producto
    variará, siempre será lo suficientemente
    detallada de manera que sirva de soporte para la
    planeación del proyecto.

    Muchos proyectos involucran una sola
    organización (el vendedor) haciendo el trabajo bajo
    contrato para otro (el comprador). En tales circunstancias,
    la descripción inicial del producto la provee el
    comprador. Si el trabajo del comprador es si un proyecto,
    entonces la descripción del producto del comprador es
    una declaración de trabajo tal como se describe en la
    Sección 12.1.3.2.

  3. Plan estratégico. Todo proyecto
    deberá apoyar las metas estratégicas de la
    organización ejecutora – el plan
    estratégico de la organización ejecutora
    deberá considerarse como un factor en la toma de
    decisiones del proyecto como un factor en la toma de decisiones
    de selección de proyectos.
  4. Criterio de selección de proyectos. El
    criterio de selección de proyectos son
    típicamente definidas en términos del producto
    del proyecto y puede cubrir un rango completo de posibles
    preocupaciones administrativas (retornos financieros,
    participación del mercado, percepción del público,
    etc.).
  5. Información histórica. La
    información histórica de decisiones previas de
    selección de proyectos y de sus reportes de
    ejecución se deben considerar en la medida que esta
    información este disponible. Cuando la iniciación
    involucra la aprobación para la siguiente fase de un
    proyecto, la información de resultados de fases previas
    es muchas veces crítico.

5.1.2 Herramientas y Técnicas para la
Iniciación

  1. Métodos de selección de
    proyectos.
    Los métodos de selección de
    proyectos generalmente caen en una de dos categorías
    amplias [2]:
  • Método de medición del beneficio
    — aproximaciones comparativas, modelos de
    puntaje, contribución del beneficio, o modelos
    económicos.
  • Métodos de optimización restringidos
    — modelos matemáticos usando algoritmos
    de programación lineales, no lineales,
    dinámicos, de números enteros, y
    multiobjetivos.

Se refiere a estos métodos muchas veces como
modelos de decisión. Los modelos de decisión
incluyen técnicas generalizadas (arboles de
decisión, escogencia forzada, y otros) como también
otros especializados (Procesos Jerárquicos
Analíticos, Análisis de Estructura Lógica, y
otros) aplicar un criterio de selección de proyecto
compleja, en un modelo sofisticado es mucha veces tratado como
una fase por separado del proyecto.

  1. Opinión experta. La Opinión
    experta será requerida muchas veces para acelerar las
    entradas a este proceso. Tal experiencia puede ser
    proveída por cualquier grupo o individuo con
    conocimiento o entrenamiento especializado y esta disponible de
    muchas otras fuentes que incluyen:
  • Otras unidades dentro de la organización
    ejecutora.
  • Consultores
  • Profesionales y asociaciones
    técnicas.
  • Grupos de industria

5.1.3 Salidas de la Iniciación

  1. Charter del proyecto. Un charter del proyecto
    es un documento que reconoce formalmente la existencia de un
    proyecto. Este deberá incluir, directamente o por medio
    de referencias con otros documentos lo siguiente:
  • La necesidad del negocio para la cual en proyecto
    fue creado.
  • La descripción del producto (tal como se
    describe en la Sección 5.1.1.1.)

El charter del proyecto deberá ser generado por
un administrador externo al proyecto y a un nivel apropiado para
las necesidades del proyecto. El provee al administrador del
proyecto con la autoridad para aplicar recursos organizacionales
a las actividades del proyecto.

Cuando un proyecto es ejecutado bajo contrato, el
contrato firmado generalmente servirá como charter del
proyecto para el vendedor.

  1. La identificación/asignación del
    administrador del proyecto.
    En general, el administrador
    del proyecto deberá ser identificado y asignado tan
    tempranamente como sea posible. El administrador del proyecto
    siempre deberá ser asignado con anterioridad al
    comienzo del plan de ejecución del proyecto (tal como
    se describe en la Sección 4.2.) y preferiblemente
    mucho antes que la planeación del proyecto se haya
    hecho (los procesos de planeación del proyecto se
    describen en la Sección 3.3.2.).

    Cuando un proyecto se ejecuta bajo un contrato, las
    provisiones contractuales generalmente serán
    restricciones.

  2. Restricciones. Las restricciones son factores
    que limitaran las opciones del equipo administrativo del
    proyecto. Por ejemplo, un presupuesto predefinido es una
    restricción que muy seguramente limitará las
    opciones que tiene el equipo administrador con respecto al
    alcance, personal, y programación.
  3. Suposiciones. Las suposiciones son factores
    que, para propósitos de planeación, se
    consideraran como ciertas, reales, o seguras. Por ejemplo, si
    la fecha en que una persona clave se pueda hacer disponible es
    incierta, el equipo puede asumir una fecha específica de
    comienzo. Las suposiciones generalmente involucran un grado de
    riesgo. Estas se podrán identificar aquí o pueden
    ser el resultado de una identificación de riesgo (como
    se describe en la Sección 11.1).

Planeación del
Alcance

La planeación del alcance es el proceso de
desarrollar un documento escrito del alcance que sirva como base
para la toma futura de decisiones, en particular, el criterio
usado para determinar si el proyecto o fase ha sido completado
exitosamente. Un documento escrito del alcance es necesario tanto
para proyectos y subproyectos. Por ejemplo, una firma de
ingeniería es contratada para diseñar una planta de
procesamiento de petróleos que deberá tener un
documento de alcance que describa las fronteras de trabajo de
diseño de subproyecto. El documento de alcance forma una
base de acuerdo entre el equipo del proyecto y el cliente del
proyecto al identificar tanto los objetivos del proyecto como sus
principales productos de entrega.

Si todos los elementos del documento del alcance
están ya disponibles (e.g., un requerimiento para una
propuesta puede identificar los principales productos de entrega,
y el charter del proyecto puede definir los objetivos del
proyecto), este proceso puede involucrar poco más que
físicamente crear el documento escrito.

5.2.1 Entradas a la Planeación del
Alcance

  1. Descripción del producto.
    La descripción del producto se discute en la
    sección 5.1.1.1.
  2. Charter del proyecto. El charter del proyecto
    se describe en la Sección 5.1.3.1.
  3. Restricciones. Las restricciones se describen
    en la Sección 5.1.3.3.
  4. Suposiciones. Las suposiciones se describen en
    la Sección 5.1.3.4.

5.2.2 Herramientas y Técnicas para la
Planeación del Alcance

  1. Análisis del producto. El
    análisis del producto involucra desarrollar un mejor
    entendimiento del producto del proyecto. Este involucra
    técnicas tales como sistemas de ingeniería,
    ingeniería de valor, análisis de valor,
    análisis de función, y desarrollo de funciones de
    calidad.
  2. Análisis costo/beneficio. El
    análisis de costo beneficio involucra estimar costos
    (outlays) y beneficios (returns) tangibles e intangibles de las
    varias alternativas del proyecto, y después usar medidas
    financieras tales como el retorno de la inversión o punto de
    equilibrio para determinar la deseabilidad de las
    diferentes alternativas identificadas.
  3. Identificación de alternativas. Este es
    un término genérico para cualquier técnica
    usada para generar diferentes aproximaciones a un proyecto. Hay
    una gran variedad de técnicas generales de
    administración que se usan, las más comunes
    siendo la lluvia de ideas y pensamiento lateral.
  4. Opinión experta. La opinión
    experta se describe en la Sección 5.1.2.2.

5.2.3 Salidas de la Planeación del
Alcance

  1. Declaración del alcance. La
    declaración del alcance provee una base documentada para
    la toma futura de decisiones y para confirmar o desarrollar la
    comprensión en común del alcance del proyecto
    entre los distintos partidos interesados. A medida que el
    proyecto progresa, esta declaración del alcance puede
    ser revisada o refinada para reflejar los cambios al alcance
    del proyecto. Esta declaración del alcance debe incluir,
    ya sea directamente o por referencia de otros documentos, lo
    siguiente:
  • Justificación del proyecto— es la
    necesidad del negocio para la cual el proyecto fue
    desarrollado. La justificación de proyectos provee la
    base para evaluar cambios futuros.
  • Producto del proyecto— es un pequeño
    resumen de la descripción del producto (la
    descripción del producto se discute en la
    Sección 5.1.1.1.).
  • Entregas del proyecto— es una lista que
    resume a nivel de los subproductos de cuya entrega total y
    satisfactoria marca la
    terminación del proyecto. Por ejemplo, las principales
    entregas para un proyecto de desarrollo de software pueden
    incluir el código funcional del computador, un manual del
    usuario, y un tutorial interactivo. Cuando se conoce, las
    exclusiones se deben identificar, pero cualquier cosa que no
    sea explícitamente incluida está
    implícitamente excluida.
  • Objetivos del proyecto— el criterio
    cuantificable que se debe cumplir para que el proyecto sea
    considerado exitoso. Los objetivos del proyecto deben incluir
    al menos costo, cronograma y medidas de calidad. Los
    objetivos del proyecto deben de tener un atributo (e.g.,
    costo ), una regla de medida (e.g., dólares
    americanos) y un valor absoluta o relativo (e.g., menos de
    1.5 millones). Objetivos incuantificables (e.g.,
    "satisfacción del cliente") entrañan un alto
    riesgo.

En algunas áreas de aplicación las
entregas del proyecto se denominan objetivos del proyecto
mientras que los objetivos del proyecto se denominan factores
críticos de éxito.

  1. Detalle de soporte. El detalle de soporte para
    la declaración del alcance debe ser documentado y
    organizado en la medida que facilite su uso por otros procesos
    de administración del proyecto. El detalle de soporte
    siempre deberá incluir documentación de todas las
    suposiciones y limitaciones identificadas. El grado detalle
    varia de acuerdo con el área de
    aplicación.
  2. Plan de manejo del alcance. Este documento
    describe como el alcance del proyecto será administrado
    y como los cambios al alcance serán integrados al
    proyecto. Deberá incluir también una
    evaluación de la estabilidad esperada del alcance del
    proyecto (i.e., que tan probable es que cambie, que tan
    frecuentemente, y en que medida). Este plan de manejo del
    alcance deberá incluir una descripción clara de
    como los cambios al alcance serán identificados y
    clasificados (esto es especialmente difícil — y
    por lo tanto absolutamente esencial— cuando las
    características del producto aún están
    siendo elaboradas).

Un plan de manejo del alcance puede ser formal e
informal, detallado o con un marco amplio basado en las
necesidades del proyecto. Es un elemento subsidiario del plan
general del proyecto (tal como se describe en la Sección
4.1.3.1.)

Definición del
Alcance

La definición del alcance involucra subdividir
las principales entregas del proyecto (tal como se identifica en
la declaración del alcance) en componentes más
pequeños y manejables para poder:

  • Mejorar la precisión de los estimados de
    costo, tiempo, y recursos.
  • Definir la línea de base para la
    medición de la ejecución y su
    control.
  • Facilitar la asignación de responsabilidades
    de manera clara.

Una correcta definición del alcance es
crítica para el éxito del proyecto. "Cuando hay una
pobre definición del alcance, los costos finales del
proyecto podrán ser mayores debido a los cambios
inevitables que interrumpen el ritmo del proyecto, causan
reelaboración de trabajos, aumentan el tiempo del
proyecto, y bajan la productividad y
moral de la
fuerza de
trabajo" [3].

5.3.1 Entradas a la Definición del
Alcance

  1. Declaración del alcance.
    La declaración del alcance se describe en la
    Sección 5.2.3.1.
  2. Limitantes o restricciones. Las limitantes o
    restricciones se describen en la Sección 5.1.3.3. Cuando
    un proyecto se ejecuta bajo un contrato, las restricciones se
    definen por medio de provisiones contractuales y son muchas
    veces consideraciones importantes durante la definición
    del alcance.
  3. Suposiciones. Las suposiciones se describen en
    la Sección 5.1.3.4.
  4. Otras salidas de la planeación. Las
    salidas de procesos de otras áreas de conocimiento
    deberán ser repasadas para preveer posibles impactos en
    la definición del alcance.
  5. Información histórica. La
    información histórica de proyectos previos
    deberá ser considerada durante la definición del
    alcance. Información de errores u omisiones de proyectos
    previos deberá ser especialmente
    útil.

5.3.2 Técnicas y Herramientas Para la
Definición del Alcance

  1. Muchas áreas de aplicación tienen WBS
    standard o semistandar que pueden ser usados como patrones.
    Por ejemplo, el departamento de defensa de los
    Estados

    Unidos ha definido un WBS standard para los
    Ítems de Materiales de Defensa. Una porción de
    uno de estos patrones se muestra como la Figura
    5-2
    .

  2. Patrones para el desglose del trabajo (WBS).
    Una estructura de desglose de trabajo (El WBS, tal como se
    describe en la Sección 5.3.3.1.) de un proyecto previo
    puede ser usado como un patrón para un nuevo proyecto.
    Aunque cada proyecto es único un WBS puede ser muchas
    veces "reutilizado" ya que muchos proyectos se parecen a otro
    proyecto en algún grado. Por ejemplo, muchos proyectos
    dentro de una organización dada tendrán un ciclo
    de vida del proyecto igual o similar y por lo tanto
    tendrán entregas requeridas iguales o similares para
    cada fase.
  3. Descomposición. La
    descomposición involucra subdividir las principales
    entregas del proyecto en componentes más pequeños
    y manejables hasta que las entregas están definidas con
    suficiente detalle como para soportar las actividades futuras
    del proyecto (planear, ejecutar, controlar y cierre). La
    descomposición involucra los siguientes pasos
    principales:
  1. Identificar los principales componentes del
    proyecto. En general, los principales elementos del proyecto
    serán las entregas del proyecto y la
    administración del proyecto. Sin embargo, los
    elementos principales estarán definidos siempre en
    términos de como el proyecto será realmente
    administrado. Por ejemplo:
  • Las fases de ciclo de vida del proyecto pueden ser
    usadas como el primer nivel de descomposición con las
    entregas del proyecto repetidas como el segundo nivel, tal
    como se ilustra en la Figura 5-3.
  • El principio administrativo dentro de cada ramal
    del WBS puede variar, tal como se ilustra en la Figura
    5-4.

(2) Decidir si un estimativo adecuado de costo y
duración puede ser desarrollado a este nivel de detalle
para cada elemento. La definición de adecuado puede
cambiar sobre el curso del proyecto— la
descomposición de una entrega que se producirá muy
remotamente en el futuro podrá no ser posible. Para cada
elemento, procédase con el Paso 4 si hay detalle adecuado
y si no con el Paso 3— esto quiere decir que diferentes
elementos tienen distintos niveles de descomposición
.

(3) Identificar los elementos constitutivos de
cada entrega. Los elementos constitutivos deberán ser
descritos en términos de resultados tangibles y
verificables de manera que se facilite la evaluación del
rendimiento. Tal como se hace con los elementos principales, los
elementos constitutivos deberán ser definidos en
términos de como el trabajo del proyecto será
realmente llevado a cabo. Los resultados tangibles y verificables
pueden incluir tanto servicios como productos (e.g., el reporte
de status podría ser descrito como reporte de status
semanal; para un ítem manufacturado, los elementos
constitutivos pueden incluir varios componentes individuales
más el ensamblaje final) repita el Paso 2 con cada
elemento constitutivo.

(4) Verifique el grado de veracidad de la
descomposición:

  • ¿Son los ítems de bajo nivel tanto
    necesarios como suficientes para la terminación del
    ítem de descompuesto? Sino, los elementos
    constitutivos deberán ser modificados (se le agrega a,
    se le resta a, o se redefine).
  • ¿Esta cada ítem completa y claramente
    definido? Sino, las descripciones deberán ser
    revisadas o expandidas.
  • ¿Podrá ser cada ítem
    programado adecuadamente? ¿Presupuestado?
    ¿Asignado a una unidad organizacional
    específica (e.g., departamento, equipo, o persona) que
    aceptará la responsabilidad para la terminación
    satisfactoria del ítem? Sino, serán necesarias
    revisiones que provean un control administrativo
    adecuado.

5.3.3 Salidas de la Definición del
Alcance

  1. Estructura de desglose de trabajo (WBS). Una
    estructura desglosada de trabajo es un agrupamiento orientado a
    la entrega de los elementos del proyecto que organiza y define
    el alcance total del proyecto: Trabajo que no este incluido
    dentro del WBS está fuera de alcance del proyecto.
    Así como con la declaración del alcance, el WBS
    se usa muchas veces para desarrollar o confirmar un
    entendimiento común del alcance del proyecto. Cada nivel
    descendiente representa una descripción más
    detallada de los elementos del proyecto. La Sección
    5.3.2.2. describe la aproximación más
    común para desarrollar un WBS. Un WBS es normalmente
    presentado en forma de tabla tal como se ilustra en la
    Figura 5-2, 5-3, y 5-4; sin embargo, el
    WBS no se deberá confundir con el método de
    presentación— dibujar una lista de actividades
    desestructuradas en forma de tabla no la convierten en un
    WBS.

A cada ítem del WBS se le asigna generalmente un
identificador único; estos identificadores se conocen
colectivamente como el código de cuentas. A los
ítems a nivel más bajo del WBS se denomina paquetes
de trabajo. Estos paquetes de trabajo podrán ser
descompuestos a su vez tal como se describe en la Sección
6.1, Definición de Actividades.

La descripción de los elementos de trabajo
generalmente se recogen en un diccionario
del WBS. Un diccionario del WBS incluirá
típicamente las descripciones de los paquetes de trabajo
como también otra información de
planeación tales como fechas de cronograma, presupuestos
de costos y asignación de personal.

El WBS no deberá ser confundido con otros tipos
de estructura de "desglose" que se usan para presentar la
información del proyecto. Otras estructuras
comúnmente usadas en otras áreas de
aplicación incluyen:

  • WBS contractual (CWBS), que se usa para definir el
    nivel de reporte que el vendedor pondrá a
    disposición del comprador. El CWBS generalmente
    incluye menos detalle que el WBS usado por el vendedor para
    administrar el trabajo del vendedor.
  • Estructura de desglose organizacional (OBS), que se
    usa para mostrar que elementos de trabajo han sido asignados
    a que unidades organizativas.
  • Estructura de desglose de recursos (RBS), que es
    una variación del OBS y se usa típicamente
    cuando los elementos de trabajo han sido asignados a
    individuos).
  • Lista de Materiales (BOM), que presenta una vista
    jerárquica de los ensamblajes, subensamblajes y
    componentes físicos requeridos para fabricar un
    producto manufacturado.
  • Estructura de desglose del proyecto (PBS), que es
    fundamentalmente lo mismo que un WBS hecho correctamente. El
    término PBS es usado ampliamente en áreas de
    aplicación donde el término WBS se usa
    incorrectamente para referirse al término BOM
    .

Verificación del
Alcance

La verificación del alcance es el proceso de la
aceptación formal del alcance del proyecto por los
partidos interesados (patrocinador, cliente, dueño, etc.)
estos requieren revisar productos de trabajo y sus resultados
para asegurar que todos fueron completados correcta y
satisfactoriamente. Si el proyecto se termina de manera
anticipada el proceso de verificación del alcance
deberá establecer y documentar el nivel y grado de
terminación. La verificación del alcance difiere
del control de
calidad (tal como se describe en la Sección 8.3) en el
que este se preocupa primariamente con la aceptación de
los resultados de trabajo mientras que el control de calidad se
preocupa principalmente de la medida en que el trabajo se halla
hecho de manera correcta.

5.4.1 Entradas a la Verificación del
Alcance

  1. Resultados del trabajo. Los
    resultados de trabajo — que entregas han sido parcial o
    totalmente completadas, en que costos se a incurrido o
    comprometido, etc.— son unas salidas del plan de
    ejecución del proyecto (tal como se discutió en
    la Sección 4.2.)
  2. Documentación del producto. Los
    documentos producidos para describir el producto de un proyecto
    deberán estar disponibles para las revisiones. Los
    términos utilizados para describir esta
    documentación (planos, especificaciones,
    documentación técnica, planes, etc.)
    varían de acuerdo con el área de
    aplicación.

5.4.2 Herramientas y Técnicas para la
Verificación del Alcance

  1. Inspección. La inspección
    incluye actividades tales como mediciones, examinar, y ensayos
    implementados para determinar si los resultados se ajustan a
    los requerimientos. Las inspecciones muchas veces se llaman
    revisiones, revisiones del producto, auditorias,
    y visitas in situ; en algunas áreas de
    aplicación, estos términos tienen definiciones
    muy específicas.

5.4.3 Salidas de la Verificación del
Alcance

  1. Aceptación formal. La
    documentación que el cliente o patrocinador ha aceptado
    el producto del proyecto o fase, deberá ser preparada y
    distribuida. Tal aceptación podrá ser
    condicional, especialmente al final de una fase.
  1. Control de Cambio del Alcance

El control de cambio del alcance se preocupa con (a)
influenciar los factores que crean cambio al alcance para
asegurar que estos cambios son beneficiosos, (b) determinar que
un cambio en el alcance ha ocurrido, y que (c) administrar los
cambios reales cuando y si estos ocurren. El control de cambio al
alcance deberá estar integrado totalmente con otros
procesos de control (control de tiempo, control de costos,
control de calidad, y otros como se discute en la Sección
4.3).

5.5.1 Entradas al Control de Cambio del
Alcance

  1. Estructura de desglose de
    trabajo
    . El WBS es descrito en la
    Sección 5.3.3.1. El define la línea de base del
    alcance del proyecto.
  2. Reportes de desempeño. Los reportes de
    desempeño se discuten en la Sección 10.3.3.1. y
    proveen información sobre ejecución del alcance
    tales como que productos interinos han sido completados y
    cuales no. Los reportes de ejecución pueden alertar
    también al equipo de trabajo sobre que tópicos
    pueden causar problemas en el futuro.
  3. Requisiciones de cambio. Las requisiciones de
    cambio pueden ocurrir de muchas formas — orales o
    escritos, directas o indirectas, iniciadas interna o
    externamente, ser requisitos legales u opcionales. Los cambios
    pueden requerir expandir el alcance o pueden permitir
    reducirlo. La mayoría de las requisiciones de cambio son
    producto de:
  • Un evento externo (e.g., un cambio en una
    regulación gubernamental).
  • Un error u omisión en la definición
    del alcance de un producto (e.g., una falla al no incluir un
    diseño requerido de un sistema de telecomunicaciones).
  • Un error u omisión al definir el alcance de
    un proyecto (e.g., usar una lista de materiales en vez de una
    estructura de desglose de trabajo).
  • Un cambio de valor agregado (e.g., un proyecto de
    remediación ambiental es capaz de reducir costos al
    tomar ventaja de tecnología que no esta disponible
    cuando el alcance fue originalmente definido).
  1. Plan de manejo del alcance. El plan de manejo
    del alcance esta descrito en la Sección
    5.2.3.3.

5.5.2 Herramientas y Técnicas para Control
de Cambio del Alcance

  1. Sistema de control de cambio del alcance. Un
    sistema de control de cambio del alcance define los
    procedimientos mediante los cuales el alcance del proyecto
    puede ser cambiado. Incluye el papeleo, sistemas de
    seguimiento, y niveles de aprobación necesarios para
    autorizar los cambios. El sistema de control de cambio
    deberá estar integrado con el sistema de control de
    cambios general descrita en la Sección 4.3. y, en
    particular, con cualquier sistema o sistemas que estén
    trabajando para controlar el alcance del producto. Cuando el
    proyecto es ejecutado bajo contrato, el sistema de control de
    cambios deberá cumplir con todas las provisiones
    contractuales relevantes.
  2. Medición de ejecución. Las
    técnicas de medición de ejecución,
    descritas en la Sección 10.3.2. ayudan a evaluar la
    magnitud de variaciones que ocurren. Una parte importante del
    control de cambios al alcance es determinar que esta causando
    la varianza y decidir si esta varianza requiere acción
    correctiva.
  3. Planeación adicional. Pocos proyectos
    se ejecutan de acuerdo al plan. Posibles cambios al alcance
    pueden requerir modificaciones al WBS o análisis de
    aproximaciones alternas.

5.5.3 Salidas del Control de Cambio al
Alcance

  1. Cambios al alcance. Un cambio al alcance es
    cualquier modificación al alcance acordado del proyecto
    tal como se define por el WBS aprobado. Los controles al
    alcance muchas veces requieren ajustes al costo, tiempo y
    calidad u otros objetivos del proyecto.
  2. Los cambios al alcance se retroalimentan a
    través de los procesos de planeación, los
    documentos técnicos y de planeación se
    actualizan en la medida que sea necesario, y los partidos
    interesados se notificaran de manera apropiada.

  3. Acción correctiva. La acción
    correctiva es cualquier cosa que se haga para hacer que la
    ejecución futura esperada del proyecto este en
    línea con el plan del proyecto.
  4. Lecciones aprendidas. Las causas de las
    variaciones, el razonamiento detrás de la acción
    correctiva tomada, y otros tipos de lecciones aprendidas del
    control de cambio al alcance, deberán ser documentadas
    para que esta información se vuelva parte de la base de
    datos
    histórica para este y otros proyectos de la
    organización ejecutora.

NOTAS

Administración de Tiempo del
Proyecto

La Administración de Tiempo del Proyecto incluye
los procesos requeridos para asegurar una terminación a
tiempo del proyecto. La Figura 6-1 provee una vista
general de los siguientes procesos principales:

6.1 Definición de las actividades
Consiste en identificar las actividades
específicas que deberán ser ejecutadas para
producir las entregas principales del proyecto.

6.2 Secuencia de las actividades —
Consiste en identificar y documentar las dependencias entre
actividades.

6.3 Estimación de la duración de las
actividades —
Consiste en estimar el número de
períodos de trabajo que se requieren para terminar las
actividades individuales.

6.4 Desarrollo de la programación
Consiste en analizar las secuencias de las
actividades, las duraciones de las actividades, y los
requerimientos de recursos para crear la programación
del proyecto.

  1. Control de la programación —
    Consiste en controlar los cambios a la programación
    del proyecto.

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

Aunque los procesos aquí presentados se muestran
como elementos discretos con interfaces bien definidas, en la
práctica estas se pueden traslapar e interactuar en
maneras que aquí no se describen. Las interaciones de
procesos se discuten en detalle en el Capítulo
3.

En algunos proyectos, especialmente los más
pequeños, las secuencias de las actividades, la
estimación de sus duraciones, y el desarrollo de la
programación están tan estrechamente unidas que se
ven como un sólo proceso (e.g., estas pueden ser
desarrolladas por un solo individuo sobre un período
relativamente corto de tiempo). Se presentan aquí como
procesos distintos porque las herramientas y técnicas para
cada una son diferentes.

Al presente, no hay un consenso en la profesión
de administración de proyectos sobre la relación
entre actividades y tareas:

  • En muchas áreas de aplicación, las
    actividades se ven como compuestas de tareas. Este es el uso
    más cómodo y preferido.
  • En otros, las tareas se ven como compuestas de
    actividades.

Sin embargo, la consideración importante no es el
término usado, sino si el trabajo a realizar es descrito y
entendido de manera precisa por aquellos que tienen que ejecutar
el trabajo.

Definición de
Actividades

La definición de actividades involucra el
identificar y documentar las actividades específicas que
tienen que ser ejecutadas de manera que se puedan producir las
entregas y subentregas identificadas en la estructura de
desglose de trabajo. Esta implícito en este proceso la
necesidad de definir las actividades de tal manera que los
objetivos del proyecto se puedan cumplir.

6.1.1 Entradas a la Definición de
Actividades

  1. Estructura de desglose de trabajo.
    La estructura de desglose de trabajo es la entrada
    primaria para la definición de actividades (vea la
    Sección 5.3.3.1 para una descripción más
    detallada del WBS).
  2. Declaración del alcance. La
    justificación del proyecto y los objetivos del proyecto
    contenidos en la declaración del alcance deben ser
    considerados de manera explícita durante la
    definición de las actividades (vea la Sección
    5.2.3.1. para un discusión más detallada de la
    declaración del alcance del proyecto).
  3. Información histórica. La
    información histórica (que actividades fueron
    realmente requeridas en proyectos similares previos)
    deberá ser considerada durante la definición de
    las actividades.
  4. Restricciones. Las restricciones son factores
    que van a limitar las opciones del equipo del
    proyecto.
  5. Suposiciones. Las suposiciones son factores
    que, para los procesos de planeación, serán
    consideradas como verdaderas, reales, o ciertas. Las
    suposiciones generalmente involucran algún grado de
    riesgo y serán normalmente una salida del proceso de
    identificación de riesgos (tal como se describe en la
    Sección 11.1).

6.1.2 Herramientas y Técnicas para la
Definición de las Actividades

  1. Descomposición. La
    descomposición involucra subdividir los elementos del
    proyecto, en componentes más pequeños y
    manejables de manera que se pueda proveer un mejor control
    administrativo. La descomposición se describe en
    más detalla en la Sección 5.3.2.2. La principal
    diferencia entre la descomposición aquí y en la
    Definición del Alcance es que la salida final
    aquí se describe como actividades (pasos de
    acción) en vez de entregas (ítems tangibles). En
    algunas áreas de aplicación, el WBS y la lista de
    actividades se desarrollan simultáneamente.
  2. Patrones. Una lista de actividades (tal como
    se describe en la Sección 6.1.3.1.), o una
    porción de una lista de actividades de un proyecto
    previo (fragnets en P3), se usa muchas veces como un
    patrón para un nuevo proyecto. Adicionalmente, la lista
    de actividades para un elemento del WBS del proyecto en
    ejecución puede ser usada como un patrón para
    otros elementos del WBS similares.

6.1.3 Salidas de la Definición de
Actividades

  1. Lista de actividades. La lista de actividades
    debe incluir todas las actividades que serán ejecutadas
    en el proyecto. Deberá ser organizada como una
    extensión del WBS para ayudar a asegurar que está
    completo y que no incluye actividades que no son requeridas
    como parte del alcance del proyecto. Así como con el
    WBS; la lista de actividades debe incluir descripciones de cada
    actividad para asegurar que los miembros del equipo del
    proyecto entenderán como se deberá de ejecutar el
    trabajo.
  2. Detalle de soporte. El detalle de soporte para
    la lista de actividades deberá ser documentado y
    organizado de manera que facilite su uso por otros procesos de
    la administración del proyecto. El detalle de soporte
    deberá siempre incluir documentación de todas las
    suposiciones y restricciones identificadas. La cantidad de
    detalle adicional varia de acuerdo con el área de
    aplicación.
  3. Actualizaciones a la estructura de desglose de
    trabajo.
    Al usar el WBS para identificar que actividades
    son necesarias, el equipo del proyecto puede identificar
    entregas faltantes o puede determinar que la descripción
    de la entrega puede necesitar clarificación o
    corrección. Tales actualizaciones deben ser reflejadas
    en el WBS y documentos relacionados tales como estimativos de
    costos. Estas actualizaciones se llaman muchas veces
    refinamientos y son muy probables cuando el proyecto involucra
    tecnología nueva o tecnología que no ha sido
    ensayada.

Secuencia de Actividades

La secuencia de las actividades involucra identificar y
documentar las dependencias entre actividades. Las actividades
deben de ser secuenciadas de manera precisa de tal manera que
soporten luego el desarrollo de una programación realista
y alcanzable. El secuenciamiento puede ser ejecutado con la ayuda
de un computador (e.g., usando software de administración
de proyectos) o con técnicas manuales. Las técnicas
manuales son muchas veces más efectivas en proyectos
pequeños o en las fases tempranas de proyectos grandes
cuando hay poco detalle disponible. Las técnicas manuales
o automatizadas también pueden ser usadas en
combinación.

6,2 Entradas a la Secuencia de
Actividades

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