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

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

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.
Cuando un proyecto es ejecutado bajo un contrato, las provisiones contractuales generalmente serán restricciones a esta.
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

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

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

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.

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.

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

Entradas a la Ejecución del Plan del Proyecto

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.
Detalle de soporte. El detalle de soporte esta descrito en la Sección 4.1.3.2.
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.
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.

Herramientas y Técnicas para la Ejecución del Plan del Proyecto

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

Salidas del Plan de Ejecución del Proyecto

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

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.

Entradas al Control de Cambios General

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

Técnicas y Herramientas para el Control de Cambios General

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

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

Salidas del Control de Cambios General

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.
Acción correctiva. La acción correctiva se describe en la Sección 4.2.1.4.
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

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

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.

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

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.

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

Descripción del producto. La descripción del producto se discute en la sección 5.1.1.1.
Charter del proyecto. El charter del proyecto se describe en la Sección 5.1.3.1.
Restricciones. Las restricciones se describen en la Sección 5.1.3.3.
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

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

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.

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

Declaración del alcance. La declaración del alcance se describe en la Sección 5.2.3.1.
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.
Suposiciones. Las suposiciones se describen en la Sección 5.1.3.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.
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

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

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

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

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

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

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.

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

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

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

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

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

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

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).
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).
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.
Restricciones. Las restricciones son factores que van a limitar las opciones del equipo del proyecto.
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

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

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

Página siguiente