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