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

Enviado por rsanchez

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

Lista de actividades. La lista de
actividades se describe en la sección
6.1.3.1.
Descripción del producto. La
descripción del producto se discute en la Sección
5.1.1.1. las características del producto muchas veces
afectan la secuencia de actividades (e.g., el layout
físico de una planta a construirse, interfaces de
subsistemas en un proyecto de software). Mientras que estos
efectos son muchas veces aparentes en las listas de
actividades, la descripción del producto deberá
ser revisada para asegurar precisión.
Dependencias mandatorias. Las dependencias
mandatorias son aquellas que son inherentes a la naturaleza del
trabajo que se ejecuta. Muchas veces involucran limitaciones
físicas (en un proyecto de construcción es
imposible erigir la superestructura hasta que se haya
construido las fundaciones; en un proyecto electrónico,
un prototipo deberá ser construido antes de que se pueda
ensayar). Las dependencias mandatorias también se llaman
lógica dura.
Dependencias discrecionales. Las
dependencias discrecionales son aquellas que son definidas por
el equipo de administración del proyecto. Deberán
ser usadas con cuidado (y totalmente documentadas) ya que estas
pueden limitar opciones posteriores de programación. Las
dependencias discrecionales se definen usualmente basadas en
el
conocimiento de:

"Las mejores prácticas" dentro de un
área de aplicación
específica.
De algún aspecto inusual del proyecto donde
una secuencia específica es deseada aunque hayan otras
secuencias igualmente aceptables.

Las dependencias discrecionales también se pueden
llamar lógica preferida, lógica preferencial, o
lógica blanda.

Dependencias externas. Las dependencias
externas son aquellas que involucran una relación entre
actividades del proyecto y actividades fuera de este. Por
ejemplo, las actividades de ensayo en un
proyecto de software pueden depender de hardware de una fuente
externa, o paneles de discusión ambiental pueden ser
requeridos antes de que pueda empezar la construcción de
un proyecto.
Restricciones. Las restricciones se describen
en la Sección 6.1.1.4.
Suposiciones. Las suposiciones se describen en
la Sección 6.1.1.5.

Técnicas y Herramientas para la Secuencia
de Actividades.

Método de diagrama de
precedencia (PDM). Este es un método de construir
una red de
diagrama de proyecto usando nodos para representar las
actividades y conectándolos con flechas que muestran las
dependencias (véase la Sección 6.2.3.1.). La
Figura 6-2 muestra un diagrama de red de proyectos sencilla
usando PDM. Esta técnica también se llama
actividad – sobre – nodo (activity – on – node, AON) y es el
método usado por la mayoría de paquetes de
software de administración de proyectos. PDM puede ser
ejecutado de manera manual o en el computador.

Este incluye cuatro tipos de dependencias o de
relaciones de precedencia:

Finalización- a – comienzo – la actividad
"de" debe terminar antes de que la actividad "a" pueda
comenzar.
Finalización – a- finalización
– la actividad "de" debe terminar antes de que la actividad
"a" pueda finalizar.
Comienzo- a- comienzo- la actividad "de" debe
comenzar antes de que pueda comenzar la actividad
"a".
Comienzo- a- finalización- la actividad "de"
debe comenzar antes de que la actividad "a" pueda
finalizar.

En PDM, la relación finalización – a
– comienzo es el tipo de relación lógica más
comúnmente usada. Las relaciones comienzo – a –
final son raramente usadas, y típicamente solamente por
ingenieros programadores profesionales. Usar relaciones comienzo
a comienzo, finalización – a – finalización o
comienzo a finalización con software de
administración de proyectos, puede producir resultados
inesperados ya que este tipo de relaciones no han sido
implementadas de manera consistente.

Método de diagramación con
flechas. (Arrow diagramming method ADM). Este es un
método para construir diagramas de
red usando flechas para representar las actividades y
conectándolas con nodos para mostrar las dependencias
(véase también la Sección 6.2.3.1.). La
Figura 6-3. muestra un diagrama de red de proyecto
simple usando ADM. Esta técnica también se llama
actividad— sobre — flecha (activity – on –
arrow, AOA) y, aunque de menos uso que el PDM, es
todavía la técnica preferida en algunas
áreas de aplicación. ADM utiliza
únicamente dependencias
finalización—a—comienzo y puede requerir el
uso de actividades ficticias para poder definir todas las
relaciones lógicas de manera correcta. ADM puede ser
ejecutado de manera manual o sistematizada.
Método de diagramación
condicional. Las técnicas de
diagramación tales como: GERT (técnica de
evaluación y repaso gráfica (Graphical Evaluation
and Review Techique)) y modelos de Sistemas Dinámicos
permiten el uso de actividades no secuenciales tales como loops
(e.g., un ensayo
que se debe repetir más de una vez) o ramales
condicionales (e.g., una actualización de diseño
que solo se necesita si la inspección detecta errores).
Las técnicas de PDM y ADM no permiten el uso de loops o
de ramales condicionales o probabilísticas.
Patrones de red. Redes standarizadas pueden
ser usadas para acelerar la preparación de diagramas de
red de proyectos. Estas pueden incluir un proyecto entero o
solamente una porción de este. Estas porciones de redes
se conocen como "subnets" o "fragnets". Las subnets son
especialmente útiles cuando un proyecto incluye detalles
idénticos o casi idénticos tales como los pisos
en una rasca cielos o ensayos clínicos en un proyecto de
investigación farmacéutica, o módulos
de programación en un proyecto de software.

Salidas de la Secuencia de
Actividades

Diagrama de red del proyecto. Un diagrama de
red del proyecto es una figura esquemática de las
actividades del proyecto y sus relaciones lógicas
(dependencias). La Figura 6-2 y 6-3 ilustran dos
métodos diferentes para dibujar un diagrama de red de
proyecto. Un diagrama de red de proyecto puede ser producida
manualmente o por computador. Puede incluir los detalles
completos de un proyecto o puede tener una o más
actividades totalizadoras (hamacas). El diagrama deberá
estar acompañado de una descripción que resuma y
describa la lógica usada para las secuencias de las
actividades. Cualquier secuencia fuera de lo usual
deberá estar plenamente descrito.
El diagrama de red de proyecto muchas veces se llama
incorrectamente diagrama PERT
(técnica de evaluación y repaso de programa
(Program Evaluation and Review Technique)). Un diagrama Pert
es un tipo de diagrama de red proyectos que se usa muy poco
hoy en día.
Actualización a la lista de
actividades. De la misma manera en que el proceso de
definición de actividades puede generar actualizaciones
al WBS, la preparación de la red de diagrama de proyecto
puede revelar instancias en las que una actividad deberá
ser dividida o de otra manera redefinida de manera que se pueda
diagramar la relación de lógica
correctas.

La estimación de la duración de las
actividades involucra estimar el número de
períodos de trabajo que más probablemente se
necesitara para completar cada actividad identificada. La
persona o grupo del equipo del proyecto que este más
familiarizado con la naturaleza de una actividad
específica deberá estimar o al menos aprobar
la duración de la actividad.
Estimar el número de períodos de
trabajos requeridos para completar una actividad muchas
veces requerirá considerar el tiempo transcurrido
también. Por ejemplo, si "curado de concreto" requiere cuatro días de
tiempo, este puede requerir de dos a cuatro períodos
basado en (a) en que día de la semana comienza y en
(b) si los días del fin de semana son tratados
como períodos de trabajo o no. La mayoría de
los programas
computarizados de programación trataran el problema
automáticamente.
La duración completa del proyecto
también puede ser estimada usando herramientas y
técnicas aquí presentadas, pero es calculada
de manera apropiada como la salida del desarrollo de la
programación (como se describe en la Sección
6.4).
1. Entradas a la Estimación de la
  Duración de las Actividades
Estimación de la Duración de las
Actividades

Lista de actividades . La lista
de actividades se describe en la Sección
6.1.3.1.
Restricciones. Las restricciones se describen
en la Sección 6.1.1.4.
Suposiciones. Las suposiciones se describen en
la Sección 6.1.1.5.
Requerimientos de recursos. Los requerimientos
de recursos se describen en la Sección 7.1.3.1. La
duración de la mayoría de las actividades se
verá influenciada significativamente por los recursos
asignada a ella. Por ejemplo, dos personas trabajando juntas
serán capaces de completar una actividad de
diseño en la mitad del tiempo que le tomaría a
cada uno individualmente realizar la tarea, mientras que una
persona trabajando medio tiempo en la actividad tomará
generalmente el doble del tiempo que la misma persona
trabajando tiempo completo.
Capacidades de recursos. La evaluación
de la mayoría de las actividades se verá
influenciada significativamente por las capacidades de los
recursos humanos y materiales asignados a ella. Por ejemplo, si
dos miembros del staff son asignados tiempo completo, se
podrá esperar que el miembro senior completa la tarea en
menos tiempo, que le tomará al miembro junior terminar
la tarea.
Información histórica. La
información histórica de la duración
más probable de muchas categorías de actividades,
está muchas veces disponible de una o de más de
las siguientes fuentes:

Archivos de proyecto— una o más de las
organizaciones involucradas en el proyecto puede mantener
récords de resultados de proyectos previos que sean lo
suficientemente detallados para ayudar en el desarrollo de
los estimativos de duración. En algunas áreas
de aplicación, individuos del equipo de trabajo pueden
mantener tales records.
Bases de datos de estimación comerciales
— mucha información histórica está
disponible comercialmente. Estas bases de datos tienden a ser
especialmente útiles cuando las duraciones no son
función del contenido de trabajo real (e.g., cuando
tiempo se demora el concreto para curar; generalmente cuando
se demora un agente gubernamental para responder a ciertas
requisiciones).
Conocimiento del equipo de proyecto — los
miembros individuales del equipo del proyecto pueden recordar
estimativos actuales o previos. Mientras que tales
recolecciones puedan ser útiles, son generalmente
menos fiables que resultados documentados.

Herramientas y Técnicas para la
Estimación de la Duración de las
Actividades

Opinión experta. :La opinión
experta esta descrita en la Sección 5.1.2.2. Las
duraciones son muchas veces difíciles de estimar
porque hay un número de factores que las pueden
influenciar (e.g., niveles de recursos, productividad de los
recursos). La opinión experta guiada por
información histórica deberá ser usada
cuando sea posible. Si tal experiencia no esta disponible,
los estimativos son inherentemente inciertos y riesgosos
(véase Capítulo 11, Administración de
Riesgo del Proyecto).
La estimación análoga es más
fiable cuando (a) la actividad previa es similar de hecho y
no solo en apariencia, y (b) cuando los individuos preparando
los estimativos tienen la experiencia necesaria.
Estimación análoga. La
estimación análoga, también llamada
estimación de arriba—hacia abajo, precisa usar
duraciones reales de una actividad previa y similar como base
para la estimación de la duración futura de una
actividad. Es usada frecuentemente para estimar la
duración de proyectos cuando hay una cantidad limitada
de proyecto (e.g., como en sus fases iniciales) la
estimación análoga es una forma de opinión
experta (tal como se describe en la Sección
6.3.2.1.)
Simulación. La simulación involucra calcular
múltiples duraciones con diferentes juegos de
suposiciones. La más común es Análisis de
Monte Carlo en la que una distribución de posibles
resultados es definida para cada actividad y es a su vez usada
para calcular la distribución de posibles resultados
para todo el proyecto (véase también la
Sección 11.2.2.3., Simulación de la
Programación).

Salidas de la Estimación de la
Duración de las Actividades

Estimación de la duración de la
actividad. La estimación de la duración de la
actividad son evaluaciones cuantitativas del número de
períodos de trabajo más probable que se
requerirá para completar una actividad.

La estimación de la duración de las
actividades siempre deberá incluir alguna
indicación del rango de posibles resultados. Por
ejemplo:

2 semanas ±2 días para indicar que la
actividad tomará por lo menos 8 días pero no
más de 12.
15% de probabilidad de exceder 3 semanas para
indicar una alta probabilidad – 85% -de que la actividad
tomará 3 semanas o menos.

El capítulo 11 sobre Administración de
Riesgo del Proyecto incluye una discusión más
detallada acerca de la estimación de la
incertidumbre.

Bases de estimación. Las suposiciones
hechas en el desarrollo de los estimativos deberán estar
documentados.
Actualizaciones a la lista de actividades. Las
actualizaciones a la lista de actividades se describen en la
Sección 6.2.3.2.

Desarrollo de la Programación

El desarrollo de la programación requiere
determinar fechas de comienzo y finalización para las
actividades del proyecto. Si la fechas de comienzo y
finalización no son realistas, el proyecto tendrá
pocas probabilidades de terminar como programar. El proceso de
desarrollo de la programación, muchas veces tendrá
que ser iterante (al mismo tiempo con los procesos que proveen
entradas, especialmente la estimación de las duraciones y
de costos) antes de la determinación de la
programación del proyecto.

6.4.1 Entradas al Desarrollo de la
Programación

Diagrama de red del proyecto. El
diagrama de red del proyecto se describe en la Sección
6.2.3.1.
Estimación de la duración de las
actividades. La estimación de la duración de
las actividades se describe en la Sección
6.3.3.1.
Requerimientos de recursos. Los requerimientos
de recursos se describen en la Sección 6.3.1.4.
El grado de detalle y el nivel de especificidad en
la descripción del pool de recursos puede variar. Por
ejemplo, para el desarrollar preliminar de la
programación de un proyecto de consultoria, uno solo
necesita saber que dos consultores estarán disponibles
en un marco de tiempo específico. La
programación final del mismo proyecto sin embargo,
debe identificar que consultores específicos
estarán disponibles.
Descripción del pool de recursos. El
conocimiento de que recursos estarán disponibles en que
tiempos y en que patrones es necesario para el desarrollo de la
programación. Por ejemplo, los recursos compartidos
podrán ser especialmente difíciles de programar
ya que su disponibilidad puede ser altamente
variable.
Calendarios. Los calendarios de proyecto y de
recursos identifican períodos de tiempo donde es
permitido trabajar. Los calendarios de proyecto afectan a todos
los recursos (e.g., algunos proyectos solo trabajaran durante
horas normales de negocio, mientras que otros trabajaran tres
turnos diariamente). Los calendarios de recursos afectan a un
recurso o categoría de recurso en particular (e.g., un
miembro del equipo de proyecto puede estar de vacaciones o en
un curso de capacitación, un contrato colectivo de
trabajo puede limitar la labor de algunos empleados durante la
semana).
Restricciones. Las restricciones están
descritas en la Sección 6.1.1.4. Existen dos
categorías de importancia que deben ser consideradas
durante el desarrollo de la programación del
proyecto:

Fechas impuestas. La entrega de ciertos
productos en una fecha especifica puede ser requerida por un
patrocinador del proyecto, el cliente del proyecto, u otros
factores externos (e.g., una ventana de mercadeo en un
proyecto tecnológico, una fecha impuesta judicialmente
en un proyecto de remediaron ambiental).
Eventos claves o hitos de importancia. La entrega
de ciertos productos en una fecha especifica puede ser
solicitada por un patrocinador del proyecto, el cliente de
proyecto, u otros partidos interesados. Una vez programados,
estas fechas se vuelven formales, y muchas veces sólo
se pueden cambiar con gran dificultad.

Suposiciones. Las suposiciones se describen en
la Sección 6.1.1.5.
Holguras y tiempos de espera. Cualquiera de
las dependencias puede requerir de una holgura o tiempo de
espera (lags y leads) para poder definir de manera correcta la
relación (e.g., puede existir un retraso de dos semanas
entre la compra de un equipo y su instalación para su
uso).

6.4.2 Herramientas y Técnicas para el
Desarrollo de la Programación

Análisis matemático. El
análisis matemático requiere calcular las fechas
teóricas tempranas y tardías para todas las
actividades sin tener en cuenta cualquier limitación del
pool de recursos disponibles. Las fechas resultantes no son la
programación, sino que mas bien indican los periodos de
tiempo el los que las actividades se deberían programar
dadas las limitaciones de recursos y de otros tipos conocidas.
Las técnicas más comunes conocidas
son:

Método de la Ruta Crítica
(CPM)— calcula un solo juego determinístico de
fechas tempranas y tardías de comienzo y
finalización para cada actividad, basada en una
lógica de red secuencial y solo una duración.
El foco de CPM es calcular la flotación para poder
determinar que actividades tienen la menor flexibilidad de
programación. Los algoritmos inherentes a CPM son
muchas veces usados en otros tipos de análisis
matemáticos.
Método de Evaluación y
Revisión Gráfica (GERT)— permite el
tratamiento probabilístico de tanto la red de
lógica como de la estimación de las duraciones
de las actividades (i.e., algunas actividades pueden no ser
ejecutadas, algunas pueden ser ejecutadas algunas veces, y
otras pueden ser ejecutadas varias veces).
Técnica de Evaluación y
Revisión de Programas (PERT)— usa lógica
secuencial de red y una distribución por pesos para la
duración de las actividades para calcular la
duración del proyecto. Aunque existen algunas
diferencias superficiales, PERT se diferencia de CPM en que
PERT usa la media de la distribución (el valor
esperado) en lugar del el valor más probable usado
originalmente en CPM (véase la Figura 6-4).
PERT se usa poco hoy día aunque muchas veces se usan
estimados que se asemejan a PERT en cálculos de
CPM.

Compresión de duraciones. La
compresión de duraciones es un caso especial de
análisis matemático que busca maneras de acortar
la duración del proyecto sin cambiar el alcance de este
(e.g., cumplir fechas impuestas o metas de
programación). La compresión de duraciones
incluye técnicas tales como:

Crashing— el canje entre los costos y la
programación son analizados para determinar el mayor
grado de compresión a cambio de el menor aumento
posible en los costos. El crashing no siempre produce
alternativas viables y muchas veces resulta en costos
incrementados.
Fast Tracking— es realizar actividades en
paralelo que normalmente se ejecutarían en secuencia
(e.g., comenzar a escribir código en un proyecto de
software antes de que su diseño haya terminado, o
comenzar la construcción de los cimientos para una
planta de procesamiento de petróleos antes de que sus
ingenierías lleguen al 25%). El fast tracking muchas
veces resulta en trabajos que hay que repetir, y aumenta de
manera desproporcionada el riesgo asociado con el
proyecto.

Simulaciones. Las simulaciones son descritas en
la sección 6.3.2.3.
La programación con base en restricciones de
recursos es un caso especial de nivelación de recursos
en donde la heurística involucrada es una
limitación en la cantidad de recurso
disponible.
Heurísticas de nivelación de
recursos. El análisis matemático muchas veces
produce una programación preliminar que requiere mas
recursos durante ciertos periodos de tiempo de los que hay
disponibles, o que requiere cambios en los niveles de recursos
que no son manejables. Una heurística como "asignar
recursos críticos escasos a actividades de la ruta
critica primero" pueden ser aplicados para desarrollar una
programación que refleje tales restricciones. La
nivelación de recursos muchas veces resulta en una
programación que es mas larga en duración que la
programación preliminar. Esta técnica es a veces
llamada el "método basado en recursos", especialmente
cuando se implementa con optimización por
computador.
Software de administración de
proyectos. El software de administración de
proyectos es de uso común para asistir en el desarrollo
de la programación del proyecto. Estos productos
automatizan él calculo del análisis
matemático y de la nivelación de recursos, y por
lo tanto permiten una consideración rápida de las
muchas alternativas de programación. También son
de uso común para la impresión y
presentación del desarrollo de la programación
del proyecto.

6.4.3 Salidas del Desarrollo de la
Programación

Programación del proyecto.
La programación del proyecto incluye al menos
fechas de inicio y de terminación planeadas para cada
detalle de actividad. (Nota: El cronograma de proyecto
permanecerá preliminar hasta que las asignaciones
de

recursos hayan sido confirmadas. Esto sucederá de
manera habitual no mas tarde que a la terminación del Plan
de Desarrollo del Proyecto, Sección 4.1).

El cronograma de proyecto puede ser presentado de forma
resumida (la "programación maestra") o en forma detallada.
Aunque puede ser presentado en forma tabular, suele presentarse
generalmente de forma gráfica usando uno o más de
los formatos presentados a continuación:

Diagramas de red de proyecto, mas
información de fechas (véase la Figura
6-5). Estas gráficas muestran usualmente tanto la
lógica del proyecto como las actividades de su ruta
crítica (véase la Sección 6.2.3.1 para
mas información sobre diagramas de lógica de
proyectos).
Gráficas de barras, que también se
conocen como diagramas de Gant (véase la Figura
6-6), muestran tanto las fechas de comienzo como de
terminación de las actividades y sus duraciones
esperadas, pero no muestran sus dependencias. Son
fáciles de leer, y son de uso frecuente en
presentaciones ejecutivas.
Gráficas de hitos o mojones (véase la
Figura 6-7), son similares a las gráficas de
barras, pero identifican los comienzos o terminaciones
programadas de las principales entregas e interfaces externas
claves del proyecto.
Diagramas de red de proyectos en escalas de tiempo
(véase la Figura 6-8) son una mezcla de los
diagramas de red del proyecto y de los diagramas de barras de
una manera tal que muestran la lógica del proyecto,
las duraciones de las actividades, y la información de
la programación.

Detalle de soporte. El detalle de soporte para
la programación del proyecto incluye al menos
documentación de todas las restricciones y suposiciones
identificadas. El grado de detalle adicional requerido varia de
acuerdo al área de aplicación. Por
ejemplo:

En un proyecto de construcción,
probablemente incluirá ítems tales como
histogramas de recursos, proyecciones del flujo de caja, y
programaciones de ordenas de compra y entregas.
En un proyecto electrónico, probablemente
solo incluirá histogramas de recursos.

Información que frecuentemente se incluye como
detalle de soporte contiene, pero no se limita a:

Requerimientos de recursos por unidad de tiempo,
muchas veces en la forma de un histograma de
recursos.
Programaciones alternativas (e.g., mejor caso o
peor caso, recursos con o sin nivelar, y con o sin fechas
impuestas).
Reservas de la programación, o
cuantificaciones de riesgo (véase la Sección
11.3.3).

Plan de manejo de la programación. Un
plan de manejo de la programación define como se
manejaran los cambios a la programación. Puede ser
formal o informal, con gran grado de detalle o basado de forma
conceptual amplia dependiendo de las necesidades del proyecto.
Es un elemento subsidiario del plan general del proyecto
(véase la Sección 4.1).
Actualizaciones a los requerimientos de
recursos. Las nivelaciones de recursos y actualizaciones a
la lista de actividades pueden tener un efecto significativo
sobre las estimaciones preliminares de los requerimientos de
recursos.

Control de la Programación

El control de la programación se preocupa con (a)
influenciar los factores que crean cambios en la
programación para asegurar que tales cambios sean
beneficiosos, (b) determinar que la programación ha sido
cambiada, y (c) administrar los cambios actuales cuando y como
ocurren. El control de la programación debe estar
íntimamente ligada con los otros procesos de control, tal
como se describe en la Sección 4.3, Control de Cambios
General.

6.5.1 Entradas al Control de la
Programación

Programación del proyecto.
La programación del proyecto se describe en la
Sección 6.4.3.1. La programación de proyecto
aprobada, se conoce también como la línea de
base, y es un componente de plan general del proyecto tal como
se describe en la Sección 4.1.3.1. Provee la base para
la medición y reporte del desempeño de la
programación.
Reportes de desempeño. Los reportes de
desempeño, que se discuten en la Sección
10.3.3.1, proveen información sobre el desempeño
de la programación de manera tal que se muestra que
fechas programadas se han cumplido y cuales no. Los reportes de
desempeño pueden también alertar al equipo de
proyecto a temas que pueden causar problemas en el
futuro.
Requisiciones de cambio. Las requisiciones de
cambio pueden ocurrir de muchas maneras— de forma oral o
escrita, de manera directa o indirecta, iniciadas de manera
interna o externa, por mandato legal o por opción
propia. Estos cambios pueden requerir extender el plazo
programado o pueden permitir acelerarlo.
Plan de manejo de la programación. El
plan de manejo de la programación se describe en la
Sección 6.4.3.3.

Herramientas y Técnicas para el Control
de la Programación

Sistema de control de cambios a la
programación. Un sistema de control de cambios a la
programación define los procedimientos por medio de los
cuales la programación del proyecto puede ser cambiada.
Este incluye el papeleo, el sistema de seguimiento (tracking),
y los niveles de aprobación necesarios para autorizar
tales cambios. El sistema de control a la programación
deberá estar integrado de manera intima con el sistema
general de control de cambios que se describe en la
Sección 4.3.
Medición de desempeño. Las
técnicas de medición del desempeño tales
como las que se describen en la Sección 10.3.2 ayudan a
cuantificar la magnitud de cualquier variación que
ocurra. Una parte importante del control de la
programación es decidir si la varianza de
programación requiere acción correctiva. Por
ejemplo, una demora considerable en una actividad no
crítica puede tener poco efecto sobre el proyecto en
general, mientras que un pequeño atraso en una actividad
crítica o casi crítica puede requerir
acción inmediata.
Planeación adicional. Muy pocos
proyectos se desarrollan exactamente de acuerdo a su plan.
Cambios prospectivos pueden requerir nuevas o revisadas
duraciones de actividades, secuencias de actividades
modificadas, o análisis de programaciones
alternas.
Software de administración de
proyectos. El software de administración de
proyectos se describe en la Sección 6.4.2.5. La
habilidad del software de administración de proyectos de
hacer un seguimiento de fechas programadas versus fechas reales
y de pronosticar los efectos de los cambios de
programación, reales o potenciales, hacen de esta
herramienta un recurso útil para el control de la
programación.

Salidas del Control de la
Programación

Actualizaciones a la programación. Una
actualización de programación es cualquier cambio
en la información que se usa para administrar el
proyecto. Los partidos interesados apropiados deberán
ser notificados como sea necesario. Las actualizaciones a la
programación pueden o no requerir de ajustes en otros
aspectos en el plan general de proyecto.
Las revisiones son una categoría especial de
actualizaciones de la programación. Las revisiones son
cambios a las fechas programadas de inicio y
finalización en la programación de proyecto
aprobada. Estas fechas solo son revisadas generalmente en
respuesta a cambios en el alcance. En algunos casos, las
demoras en la programación pueden ser tan severas que
hay volver a calcular la línea de base, de manera que
se puedan proveer datos realistas para la medición de
desempeño.
Acción correctiva. La acción
correctiva es cualquier cosa que se haga para hacer que el
desempeño futuro del proyecto se ajuste a lo esperado en
la línea de base del plan del proyecto. La acción
correctiva en el campo de la administración del tiempo
muchas veces requiere expeditar: acción especial que se
toma para asegurar la terminación de una actividad a
tiempo o con el menor retraso posible.
Lecciones aprendidas. Las causas de varianza,
el razonamiento detrás de las acciones correctivas
escogidas, y otros tipos de lecciones aprendidas del control de
la programación, deberán ser documentadas para
poder que sean parte de las bases de datos históricas,
tanto para este proyecto como para otros proyectos de la
organización ejecutora.

NOTAS

Administración de Costos del
Proyecto

La Administración de Costos del Proyecto incluye
los procesos requeridos para asegurar que el proyecto se
completará dentro del presupuesto aprobado. La Figura
7-1 provee una vista general de los principales procesos
involucrados:

Planeación de Recursos— es
determinar que recursos (personas, equipos, materiales) y en
que cantidades de cada uno deberán ser usados para
ejecutar las actividades del proyecto.
Estimación de Costos— es
desarrollar una aproximación (estimado) de los costos
de los recursos que se necesitan para completar las
actividades del proyecto.
Presupuestaron de Costos— es asignar
el presupuesto general de costos a cada ítem
individual de trabajo.
Control de Costos— Es controlar los
cambios al presupuesto de l proyecto.

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

Aunque los procesos se presentan aquí como
elementos discretos con interfaces bien definidas, en la practica
estos se pueden traslapar de maneras que no se detallan
aquí. Las interacciones de los procesos se discuten en
detalle en el Capitulo 3.

La administración de los costos del proyecto se
preocupan principalmente con los costos de los recursos que se
necesitan para completar las actividades del proyecto. Sin
embargo, la administración de costos del proyecto
deberá considerar además el efecto de decisiones
del costo del uso del producto del proyecto. Por ejemplo, limitar
el numero de revisiones al diseño puede reducir el costo
del proyecto a cambio de un aumento en el costo operativo del
cliente. Esta visión más amplia de la
administración de costos del proyecto, se denomina muchas
veces como costeo del ciclo de vida.

En muchas áreas de aplicación, el predecir
y analizar el futuro desempeño financiero esperado del
proyecto, es ejercido desde afuera del proyecto. En otros (e.g.,
proyectos de bienes de
capital), la
administración de costos del proyecto también
incluye este trabajo. Cuando tales predicciones y análisis
se incluyen, la administración de costos del proyecto
incluirán procesos adicionales y numerosas técnicas
de administración general, tales como el retorno sobre la
inversión, flujos descontados de caja, análisis de
"payback" y otros.

La administración de costos del proyecto
deberá considerar las necesidades de información de
los partidos interesados del proyecto— diferentes partidos
interesados pueden medir de manera diferente y en diferente
momentos los costos del proyecto. Por ejemplo, el costo de
adquisición de un ítem de puede medir cuando se ha
acometido, pedido, entregado, causado, o registrado en la
contabilidad.

Cuando los costos del proyecto son usados como una
componente de un sistema de premios y reconocimiento (los
sistemas de premios y reconocimiento se discuten en la
Sección 9.3.2.3), los costos controlables e incontrolables
deberán ser estimados y

presupuestados por aparte, para asegurar que los premios
reflejaran el desempeño real.

En algunos proyectos, en especial los pequeños,
la planeación de recursos, la estimación de costos,
y la presupuestario de costos, están ligadas de manera tan
estrecha, que son vistos como un solo proceso (e.g., estos pueden
ser elaborados por un solo individuo, sobre un lapso de tiempo
relativamente corto). Estos procesos son presentados aquí
como procesos distintos por que las herramientas y
técnicas para cada uno son distintas.

Planeación de Recursos

La planeación de recursos involucra determinar
que recursos físicos (personas, equipo, materiales) y que
cantidades de cada uno se deberán usar para ejecutar las
actividades del proyecto. Esta se deberá coordinar de
manera estrecha con la estimación de costos (que se
describe en la Sección 7.2). Por ejemplo:

Un equipo de proyecto en un proyecto de
construcción, deberá estar familiarizado con los
códigos de construcción locales. Tal conocimiento
esta muchas veces disponible a prácticamente
ningún costo al usar mano de obra local. Sin embargo, si
la fuerza laboral local
carece de experiencia con técnicas de
construcción inusuales o especiales, el costo adicional
por un consultor, puede ser la manera más efectiva de
asegurar conocimiento de las normas locales de
construcción.
Un equipo de diseño de automóviles
deberá estar familiarizado con las últimas
técnicas de ensamblaje automatizado. Este conocimiento
requerido se puede obtener contratando un consultor, mandando
un diseñador a un seminario de
robótica, o incluyendo a alguien del
departamento de manufactura como miembro del
equipo.

Entradas a la Planeación de Recursos

Estructura de desglose de trabajo (WBS). La
estructura de desglose de trabajo (WBS, que se describe en la
Sección 5.3.3.1) identifica los elementos de trabajo que
necesitaran recursos, y por lo tanto es la entrada principal a la
planeación de recursos. Cualquier elemento de salida
relevante de los otros procesos de planeación
deberá ser proveída a través del WBS para
asegurar control adecuado.

Información histórica. La
información histórica que informe respecto
a los tipos de recursos requeridos para trabajo similar e
proyectos previos deberá ser usada sí esta
disponible.

Declaración del alcance. La
declaración del alcance (que se describe en la
Sección 5.2.3.1) contiene la justificación del
proyecto y los objetivos del proyecto, ambos que deberán
ser considerados explícitamente durante la
planeación de recursos.

Descripción de pool de recursos. El
conocimiento de que recursos (personas, equipo, materiales)
están potencialmente disponibles es necesario para la
planeación de recursos. El grado de detalle y el nivel de
especificación de la descripción del pool de
recursos puede variar. Por ejemplo, durante las fases tempranas
de un proyecto de diseño ingenieril, el pool puede incluir
a "ingenieros junior y senior" en grandes cantidades, Durante las
fases posteriores del mismo proyecto, sin embargo, el pool puede
limitarse a aquellos individuos que son conocedores del proyecto
como resultado de haber trabajado en las fases
tempranas.

Políticas organizacionales. Las
políticas de la organización ejecutora respecto al
staffing y sobre el alquiler o compra de suministros y equipos,
deberá ser considerada durante la planeación de
recursos.

Herramientas y Técnicas para la
Planeación de Recursos

Opiniones expertas. Las opiniones expertas
serán requeridas muchas veces para calificar las
entradas a este proceso. Tal experiencia puede ser
proveída por cualquier grupo o individuo con
conocimiento o entrenamiento especializado y que esta
disponible de muchas fuentes que incluyen:

Otras unidades de la organización
ejecutora.
Consultores.
Profesionales y asociaciones
técnicas.
Grupos de industria.

Identificación de alternativas. La
identificación de alternativas se discute en la
Sección 5.2.2.3.

Salidas de la Planeación de
Recursos

Requerimientos de recursos. La salida del
proceso de planeación de recursos es una
descripción de que tipos de recursos son requeridos y en
que cantidades para cada elemento de la estructura de desglose
de trabajo (WBS). Estos recursos serán obtenidos a
través de adquisición de staff (tal como se
describe en la Sección 9.2) o de una gestión de
compras (tal como se describe en el Capitulo 12).

Estimación de Costos

La estimación de costos involucra el desarrollo
de una aproximación (estimado) de los costos de los
recursos requeridos para completar las actividades del
proyecto.

Cuando un proyecto es ejecutado bajo contrato, se debe
tener cuidado de distinguir entre la estimación de costos
y el costeo (pricing). La estimación de costos involucra
el desarrollo de una cuantificaron de los resultados más
probables— cuanto le costara a la organización
ejecutora el proveer el producto o servicio requerido. El costeo
es una decisión de negocios— cuanto cobrara la
organización ejecutora por el producto o servicio—
que usa el estimativo de costos como una de tantas
consideraciones.

La estimación de costos incluye identificar y
considerar la varias alternativas de costeo. Por ejemplo, en la
mayoría de áreas de aplicación, el trabajo
adicional durante una fase de diseño, se considera de
manera amplia, de tener el potencial de reducir los costos de la
fase de producción. El proceso de estimación de
costos debe considerar si el costo del trabajo adicional de
diseño será mayor que el ahorro
esperado.

Entradas a la Estimación de
Costos

Estructura de desglose de trabajo
(WBS). El WBS es descrito en la Sección
5.3.3.1. Este será utilizado para organizar los
estimativos de costos y para asegurar que todo el trabajo
identificado ha sido estimado.
Requerimientos de recursos. Los requerimientos
de recursos son descritos e la Sección
7.1.3.1.
Tasas de recursos. El individuo o grupo
preparando los estimativos deberá conocer las tasas
unitarias (e.g., el costo por hora del staff, el costo por
metro cubico de materias primas) para cada recurso para poder
calcular los costos del proyecto. Si los costos reales no se
conocen, las tasas en si, deberán ser también
estimadas.
Estimación de las duraciones de las
actividades. Las estimaciones de las duraciones de las
actividades (tal como se describen en la Sección 6.3)
afectaran los estimativos de costos en cualquier proyecto donde
el presupuesto del proyecto incluya un renglón para el
costo de la financiación del mismo (i.e., tasas de
interés).
Información histórica.
Información sobre el costo de las muchas
categorías de recursos esta disponible de una o varias
de la siguientes fuentes:

Archivos de proyecto— una o más de las
organizaciones involucradas en el proyecto puede mantener
archivos de
los resultados de proyectos previos, que sean lo
suficientemente detalladas para asistir en el desarrollo de
los estimativos de costos. En algunas áreas de
aplicación, miembros individuales del equipo de
proyecto pueden mantener tales archivos.
Bases de datos de estimación
comerciales— muchas veces la información
histórica esta disponible comercialmente.
Conocimiento del equipo de proyecto— los
miembros individuales del equipo de proyecto pueden recordar
datos reales o estimados. Mientras que tales datos pueden ser
de algún uso, estos sin embargo serán menos
confiables que datos documentados.

Tabla de cuentas. Una tabla de cuentas
describe la estructura de códigos usada por la
organización ejecutora para reportar la
información contable a sus libros de
contabilidad. Los estimativos de costos del proyecto
deberán ser asignados a la categoría de
contabilidad correcta.

Herramientas y Técnicas para la
Estimación de Costos

Estimación análoga. La
estimación análoga, que también se conoce
como estimación arriba— abajo (top—down
estimating), significa usar el costo real de un proyecto
similar anterior, como la base de la estimación del
proyecto corriente. Se usa con frecuencia para estimar costos
totales de proyecto, en casos en los que se cuenta con una
cantidad limitada de información detallada del proyecto
(e.g., como en las fases iniciales). La estimación
análoga es una forma de opinión experta (tal como
se describe en la Sección 7.1.2.1).
La estimación análoga es generalmente
menos costosa que otras técnicas, pero es
también menos precisa. Es mas fiable cuando (a) el
proyecto previo es similar de hecho y no solo en apariencia,
y (b) cuando los individuos o grupos preparando los
estimativos del proyecto, tienen la experiencia
requerida.
Tanto el costo como la precisión de los
modelos paramétricos varían considerablemente.
Son más confiables cuando (a) la información
histórica usada para desarrollar el modelo era
precisa, y (b) cuando los parámetros usados en el
modelo son fácilmente cuantificables, y (c) cuando el
modelo se puede escalar (i.e., cuando trabaja bien tanto para
proyectos grandes y pequeños).
Modelación paramétrica. La
modelación paramétrica involucra usar
características (parámetros) del proyecto, en
un modelo matemático para predecir costos. Los modelos
pueden ser simples (la construcción de casas
residenciales costaran cierta cantidad por cada metro
cuadrado de área habitable) o complejos (un modelo de
costos de desarrollo de software usa 13 factores de ajuste
separados que contienen cada uno de a 5 a 7 puntos).
El costo y la precisión de la
estimación abajo— arriba es función del
tamaño de los ítems individuales de trabajo:
ítems de trabajo pequeñas incrementan tanto el
costo como la precisión. El equipo administrativo de
proyecto debe sopesar la precisión ganada contra el
costo adicional.
Estimación abajo – arriba. Esta
técnica involucra estimar el costo de ítems
individuales de trabajo, y luego totalizando o concatenando los
estimativos individuales para conseguir el total del
proyecto.
Herramientas computarizadas. Herramientas
computarizadas tales como software de administración de
proyectos y hojas de
cálculo son usadas ampliamente para asistir en la
estimación de costos. Tales productos pueden facilitar
el uso de las herramientas descritas anteriormente y por lo
tanto pueden facilitar la rápida consideración de
las muchas alternativas de costeo.

Salidas de la Estimación de
Costos

Estimado de costos. Los estimados de costos
son evaluaciones cuantitativas de los costos más
probables requeridos para completar las actividades del
proyecto. Se pueden presentar de forma totalizada o en
detalle.
Los costos pueden ser estimados para todos los
recursos que serán cargados al proyecto. Esto incluye,
pero no se limita a, mano de obra, materiales, suministros, y
a categorías especiales tales como reservas para la
inflación o costos.
Los estimativos de costos se expresan generalmente
en unidades monetarias (dólares, francos, yens, etc.)
de manera que se facilite la comparación entre y a
través de proyectos. Otras unidades como horas de
staff o días de staff pueden ser usadas, a no ser que
tal uso malinterprete el costo del proyecto (e.g., al no
diferenciar entre recursos con precios
unitarios muy diferentes). En algunos casos, los estimativos
se suministraran usando múltiples unidades de medida
para poder facilitar el manejo administrativo del
mismo.
Los estimativos de costos se pueden beneficiar al
ser refinados durante el curso el proyecto para poder
reflejar el detalle adicional disponible. En algunas
áreas de aplicación, existen delineamientos
respecto cuando se deben hacer dichos refinamientos y que
grado de precisión se espera. Por ejemplo, la AACE
Internacional ha identificado una progresión de cinco
tipos de estimativas de costos de construcción durante
su diseño: orden de magnitud, conceptual, preliminar,
definitivo, y control.
Detalle de soporte. El detalle de soporte para
los estimativos de costos debe incluir:

Una descripción del alcance del trabajo
estimado. Este generalmente se suministra como una referencia
al WBS.
Documentación de la base para el estimado,
i.e., como fue desarrollada.
Documentación de las suposiciones
hechas.
Una indicación del rango de posibles
resultados, por ejemplo, $10,000± $1,000 para indicar que se
espera que el ítem cueste entre $9,000 y
$11,000.

El tipo y la cantidad de detalle de soporte varia con el
área de aplicación. Retener hasta borradores puede
ser de utilidad al proveer un mejor entendimiento de como el
estimativo fue desarrollado.

Plan de administración de costos. El
plan de administración de costos describe como las
varianzas de costos serán administradas (e.g.,
diferentes respuestas a grandes problemas que a los
pequeños problemas). Un plan de administración de
costos puede ser formal o informal, con mucho o poco detalle
basado en las necesidades de los partidos interesados. Es un
elemento subsidiario del plan general del proyecto (que se
discute en la Sección 4.1.3.1).

Presupuestación de
Costos

La presupuestaron de costos involucra asignar los
estimativos generales de costo a ítems individuales de
trabajo para así establecer una línea de base para
la medición de desempeño del proyecto.

Entradas a la Presupuestación de
Costos

Estimados de costos. Los
estimados de costos se describen en la Sección
7.2.3.1.
Estructura de desglose de trabajo (WBS). La
estructura de desglose de trabajo (descrita en la
Sección 5.3.3.1) identifica los elementos de proyecto a
los que se les asignara los costos.
Programación del proyecto. La
programación del proyecto (descrito en la Sección
6.4.3.1) incluye fechas de comienzo y terminación
planeadas para los elementos de trabajo a los que se les
asignaran los costos. Esta información se necesita para
poder asignar costos al periodo de tiempo en los que se
incurrirán los costos.

Herramientas y Técnicas para la
Presupuestación de Costos

Herramientas y técnicas para la
estimación de costos. Las herramientas y
técnicas descritas en la Sección 7.2.2 para
desarrollar los estimativos de los costos del proyecto se usan
también para desarrollar presupuestos para los
ítems de trabajo.

Salidas de la Presupuestación de
Costos

Línea de base de costos. La
línea de base costos es una presupuestación en
escala de
tiempo que será usada para medir y monitorear el
desempeño de costos del proyecto. Se desarrolla al sumar
estimativos de costos por unidad de tiempo y se muestra
generalmente en forma de curva S, como se ilustra en la
Figura 7-2.

Muchos proyectos en especial los grandes, pueden tener
múltiples línea de base de costos para medir
distintos aspectos del desempeño de los costos. Por
ejemplo, un plan de gastos o flujo de
caja proyectado es una línea de base para la
medición de desembolsos.

Control de Costos

El control de costos se preocupa con (a) influenciar
los factores que crean cambios a la línea de base de
costos para asegurar que los cambios sean beneficiosos, (b)
determinar que la línea de base de costos ha cambiado, y
(c) administrar los cambios actuales cuando y como
ocurran.

El control de costos incluye:

Monitorear el desempeño de los costos para
detectar varianzas del plan.
Asegurar que todos los cambios apropiados son
grabados de manera precisa en la línea de base de
costos.
Prevenir cambios incorrectos, inapropiados, o no
autorizados se incluyan en la línea de base de
costos.
Informar a los partidos interesados de los cambios
autorizados.

El control de costos incluye buscar los "porqués"
de tanto las varianzas positivas como negativas. Deberá
estar integrado de manera completa con los otros procesos de
control (control de cambio de alcance, control de la
programación, control de calidad, y otros tal como se
discute en la Sección 4.3). Por ejemplo, respuestas
inapropiadas a varianzas de costos pueden causar problemas de
calidad o de programación o pueden producir un nivel
inaceptable de riesgo mas tarde en el proyecto.

Entradas al Control de Costos

Línea de base de costo. La
línea de base de costos se describe en la Sección
7.3.3.1.
Reportes de desempeño. Los reportes de
desempeño (se discuten en la Sección 10.3.3.1)
proveen información sobre el desempeño de costos
tales como que presupuestos se han cumplido y cuales no. Los
reportes de desempeño pueden alertar también al
equipo de proyecto sobre tópicos que pueden causar
problemas en el futuro.
Requisiciones de cambio. Las requisiciones de
cambio pueden ocurrir de muchas formas – oral o escritas,
directas o indirectas, iniciadas de manera externa o interna,
por mandato legal u opcional. Los cambios pueden requerir
aumentar el presupuesto o pueden permitir
disminuirlo.
Plan de manejo de costos. El plan de manejo de
costos se describe en la sección 7.2.3.3.

Herramientas y Técnicas para el Control de
Costos.

Sistema de control de cambios de costos. Un
sistema de control de cambio de costos define los
procedimientos por los cuales la línea de base de costos
puede ser cambiada. Este sistema incluye las formas escritas,
el sistema de seguimiento, y niveles de aprobación
necesarios para autorizar los cambios. El sistema de control de
cambio de costos deberá estar integrado con el sistema
general de control de cambios que se discute en la
Sección 4.3.
Medición de desempeño. Las
técnicas de medición de desempeño, que se
describen en la Sección 10.3.2, ayudan a medir la
magnitud de cualquier variación que ocurra. El
análisis de valor obtenido, que se describe en la
Sección 10.3.2.4, es muy útil para el control de
costos. Una parte importante del control de costos es
determinar que esta causando la varianza y decidir si la
varianza requiere acción correctiva.
Planeación adicional. Muy pocos
proyectos se ejecutan de acuerdo al plan. Los cambios
prospectivos puede requerir estimativos de costos nuevos o
revisados o análisis de aproximaciones
alternas.
Herramientas computarizadas. Las herramientas
computarizadas tales como software de administración de
proyectos y las hojas de
calculo se usan muchas veces para hacer seguimiento de los
costos planeados vs. los costos reales, y para pronosticar los
efectos de los cambios en los costos.

Salidas del Control de Costos

Estimados de costos revisados. Los estimados
de costos revisados son modificaciones a la información
de costos que se usa para administrar el proyecto. Los partidos
interesados apropiados deben ser notificados en la medida que
sea necesario. Los estimativos de costos revisados pueden o no
requerir ajustes a otros aspectos del plan general del
proyecto.
Actualizaciones al presupuesto. Las
actualizaciones al presupuesto son una categoría
especial de estimados revisados de costos. Las actualizaciones
de presupuesto son cambios a una línea de base de costos
aprobada. Estos números son revisados generalmente solo
en respuesta a cambios en el alcance. En algunos casos, las
variaciones de costos serán tan severas que hay que
modificar de manera total la línea de base de costos,
para poder proveer una medida realista de
desempeño.
Acción correctiva. La acción
correctiva es cualquier cosa que se haga para hacer que el
desempeño futuro del proyecto este acorde con el plan
del proyecto.
Estimados al terminar. Un estimado al terminar
(EAC, estimate to complete) es un pronostico de los costos
totales de proyecto basados en el desempeño actual del
proyecto. Las técnicas más comunes de pronostico
son variaciones de las siguientes:

EAC= Reales a la fecha más el presupuesto
restante modificado por un factor de desempeño, que
muchas veces es el índice de desempeño de
costos que se describe en la Sección 10.3.2.4. Esta
aproximación se usa a menudo cuando las varianzas
corrientes son vistas como típicas de varianzas
futuras.
EAC= Reales a la fecha mas un nuevo estimado para
todo el trabajo faltante. Esta aproximación es la
más usada cuando el desempeño pasado muestra
que las premisas originales de estimación están
fundamentalmente falseadas, o que ya no son relevantes debido
a un cambio de condiciones.
EAC= Reales a la fecha más el presupuesto
restante. Esta aproximación es mas usada cuando las
varianzas actuales son vistas como atípicas y las
expectativas del equipo de proyecto son que varianzas
similares no ocurrirán en el futuro.

Cada una de las aproximaciones descrita puede ser la
aproximación correcta para cualquier ítem de
trabajo dado.

Lecciones aprendidas. Las causas de las
varianzas, el razonamiento detrás de las acciones
correctivas escogidas, y otros tipos de lecciones aprendidas
del control de costos deberán ser documentadas para
así volverse parte de la base de datos histórica
para este proyecto y para otros proyectos de la
organización ejecutora.

NOTAS

Administración de la Calidad del
Proyecto

La Administración de la Calidad del Proyecto
incluye los procesos requeridos para asegurar que la calidad del
proyecto va a satisfacer las necesidades para el cual fue
acometido. Este incluye "todas las actividades de las funciones
administrativas generales que determinan la política
de calidad, objetivos, responsabilidades y las implementas por
medios tales como planeación de la calidad, control de la
calidad, aseguranza de la calidad, y mejoramiento de la calidad,
dentro del sistema de calidad" [1]. La Figura 8-1 provee
una vista general de los siguientes procesos principales de
administración de la calidad del proyecto:

Planeación de la Calidad— es
identificar que standards de calidad son relevantes al
proyecto y determinar como satisfacerlos.
Aseguranza de la Calidad— es evaluar
el desempeño general del proyecto de manera regular
para así proveer la confianza de que el proyecto va a
satisfacer los standards de calidad relevantes.
Control de Calidad— es monitorear
resultados específicos del proyecto para determinar si
cumplen con los standards de calidad relevantes e identificar
maneras de eliminar causas de desempeño no
satisfactorio.

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

Aunque los procesos están aquí presentados
como elementos discretos con interfaces bien definidas, en la
practica estos se pueden traslapar e interactuar de maneras no
detalladas aquí. Las interacciones de procesos se discuten
en detalle en el Capitulo 3, Los Procesos de la
Administración de Proyectos.

La aproximación básica a la
administración de la calidad descrita en esta
sección tiene intención de ser compatible con esa
especificada por la Organización Internacional para la
Estandarización (ISO) tal como se detalla en serie
ISO 9000 y
10000 de standards y lineamientos. Esta aproximación
generalizada deberá ser compatible también con (a)
aproximaciones propias a la administración de la calidad
tales como las recomendadas por Deming, Juran,
Crosby, y otros, y (b) con aproximaciones no propias tales como
Administración Total de la Calidad (TQM), Mejoramiento
Continuado, y otras.

La administración de la calidad del proyecto
deberá dirigirse tanto a la administración del
proyecto como al producto del proyecto. Una falla al cumplir los
requerimientos en cualquiera de estas dimensiones puede tener
serias consecuencias negativas para uno o todos de los partidos
interesados en el proyecto. Por ejemplo:

Tratar de cumplir los requerimientos del cliente al
trabajar horas extra el equipo del proyecto, puede producir
consecuencias negativas en la forma de una taza incrementada
de rotación de empleados.
Tratar de cumplir con los objetivos de
programación del proyecto al apresurar las
inspecciones planeadas de calidad puede producir
consecuencias negativas cuando los errores pasan de manera
inapercibida.

La calidad es "la totalidad de las
características de una entidad que tienen inherencia en su
capacidad de satisfacer necesidades explícitas o
implícitas" [2]. Un aspecto crítico de la
administración de la calidad en el contexto del proyecto
es la necesidad de convertir necesidades implícitas en
explícitas, a través de la administración
del alcance del proyecto, que se describe en el Capitulo
5.

El equipo administrativo del proyecto deberá
tener sumo cuidado de no confundir calidad con grado. Grado es
"una categoría o rango dado a entidades que tienen el
mismo uso funcional, pero que tienen diferentes requerimientos de
calidad" [3]. Una baja calidad es siempre u problema; un bajo
grado tal vez no lo sea. Por ejemplo, un producto de software
puede ser de alta calidad (que no contenga errores obvios, que
posea un manual legible) y de bajo grado (que contenga un
número limitado de opciones), o de baja calidad (numerosos
errores, un manual mal organizado) y de alto grado (numerosas
opciones). Determinar y entregar los niveles requeridos de tanto
calidad como grado son las responsabilidades de tanto el
administrador del proyecto como del equipo administrativo del
proyecto.

El equipo administrativo del proyecto deberá
estar al tanto también de que la administración
moderna de la calidad complementa la administración
moderna de proyectos. Por ejemplo, las dos disciplinas reconocen
la importancia de:

La satisfacción del cliente —
entender, administrar, e influenciar las necesidades de tal
manera que las expectativas del cliente son cumplidas o
excedidas. Esto requiere una combinación de
cumplimiento a las especificaciones (el proyecto tiene que
producir lo que se dijo que produciría) y de
aplicabilidad de uso (el producto o servicio producido tiene
que satisfacer necesidades reales).
Prevención sobre inspección —
el costo de evitar errores es siempre mucho menor que el
costo de corregirlos.
Responsabilidad administrativa¾ el éxito
requiere de la participación de todos los miembros del
equipo, pero permanece como la responsabilidad de la
administración de proveerlos de los recursos
necesarios para ser exitosos.
Procesos dentro de fases— el ciclo repetitivo
de planear-hacer-revisar-actuar descrito por Deming y otros
es muy similar a la combinación de fases y
procedimientos discutidas en el Capitulo 3, Procesos de
Administración de Proyectos.

Adicionalmente, las iniciativas de mejoramiento de la
calidad que emprenda la organización ejecutora (e.g., TQM,
Mejoramiento Continuo, y otras) pueden mejorar la calidad de la
administración del proyecto como también la calidad
del producto del proyecto.

Sin embargo, hay una diferencia importante que el equipo
administrativo del proyecto debe tener muy presente — la
naturaleza temporal del proyecto significa que las inversiones en
el mejoramiento de la calidad del producto, en especial aquellas
que tienen que ver con la prevención de defectos y su
evaluación, muchas veces tendrán que ser asumidas
por la organización ejecutora, ya que el proyecto no puede
durar lo suficiente para cosechar los beneficios.

Planeación de la
Calidad

La planeación de la calidad involucra identificar
que standards de calidad son relevantes al proyecto y determinar
como satisfacerlos. Es uno de los procesos facilitadores claves
durante la planeación del proyecto. (véase la
Sección 3.3.2, Procesos de Planeación) y
deberá ser ejecutada de manera regular y en forma paralela
con otros procesos de planeación del proyecto. Por
ejemplo, el grado de calidad deseado por la administración
puede requerir ajustes de costos o de programación, o la
calidad deseada de producto puede requerir de un análisis
detallado de riesgo de un problema ya identificado. Previamente
al desarrollo de la Serie ISO 9000, las actividades aquí
descritas como planeación de la calidad eran ampliamente
discutidas como parte de la aseguranza de la calidad.

Las técnicas aquí discutidas de
planeación de la calidad, son las que se usan mas
frecuentemente en proyectos. Existen muchas otras que pueden ser
de uso en ciertos proyectos o en algunas áreas de
aplicación.

El equipo administrativo de proyecto debe estar al tanto
de uno de los dogmas de la administración moderna de la
calidad—la calidad se incorpora planeando, la calidad no se
incorpora inspeccionando.

Entradas a la Planeación de la
Calidad

Política de calidad. La
política de calidad es "las intenciones generales y
dirección de una organización con respecto a la
calidad, como expresado formalmente por la alta
administración de esta"[4]. La política de
calidad de la organización ejecutora puede ser adoptada
"como esta" para su uso por el proyecto. Sin embargo, si la
organización ejecutora carece de una política de
calidad formal, o si el proyecto involucra a múltiples
organizaciones ejecutoras (como en una unión temporal)
el equipo administrativo de proyecto tendrá necesidad de
desarrollar una política de calidad para el
proyecto.
Sin importar el origen de la política de
calidad, el equipo administrativo del proyecto es responsable
de asegurar que los partidos interesados están
plenamente concientes de ella (e.g., a través de una
distribución de información apropiada, tal como
se describe en la Sección 10.2).
Declaración del alcance. La
declaración del alcance (descrito en la Sección
5.2.3.1) en una entrada clave a la planeación de la
calidad ya que documenta las entregas principales del proyecto
como también los objetivos del proyecto que sirve para
definir los requerimientos más importantes de los
partidos interesados.
Descripción del producto. Algunos
elementos de la descripción del producto (descrito en la
Sección 5.1.1.1) pueden ser introducidos en la
declaración del alcance, la descripción del
producto muchas veces contendrá detalles de asuntos
técnicos y otros temas que pueden afectar la
planeación de la calidad.
Standards y regulaciones. El equipo
administrativo del proyecto debe considerar cualquier standard
o regulación especifica en áreas de
aplicación que puedan afectar al proyecto. La
Sección 2.5.1 discute standards y
regulaciones.
Salidas de
otros procesos. Adicionalmente a las declaraciones de
alcance y a la descripción de producto, los procesos de
las otras áreas de conocimiento pueden producir salidas
que deben ser consideradas como parte de la planeación
de la calidad. Por ejemplo, la planeación de compras
(descrita en la Sección 12.1) puede identificar los
requerimientos de calidad del contratista que se deberán
reflejar en el plan general de administración de la
calidad.

Herramientas y Técnicas para la
Planeación de la Calidad

Análisis beneficio/costo. El proceso de
planeación de la calidad debe considerar los beneficios
que se ganan o se pierden con el análisis de
beneficio/costo, tal como se describe en la Sección
5.2.2.2. El principal beneficio de cumplir con los
requerimientos de calidad es una menor cantidad de trabajo para
corregir errores, lo cual implica alta productividad, costos
más bajos, y mayor satisfacción de los partidos
interesados. El costo principal de cumplir con los
requerimientos de calidad, es el gasto asociado con las
actividades de administración de calidad del proyecto.
Es una calidad axiomática de la disciplina
de la administración de la calidad que los beneficios
sopesan más que los costos.
Benchmarking. El benchmarking
involucra comparar las practicas actuales o planeadas con esas
de otros proyectos para poder generar ideas para el
mejoramiento y para proveer un standard con el cual medir el
desempeño. Los otros proyectos pueden ser del interior
de la organización ejecutora o pueden ser externos, y
pueden ser de la misma área de aplicación o de
otra.
Flujogramas. Un flujograma
es cualquier diagrama que muestra como los diferentes elementos
de un sistema se relacionan. Las técnicas para la
construcción de flujogramas
que son comúnmente usadas en la administración de
la calidad incluyen:

Diagramas cuasa-y-efecto, que se llaman
también diagramas Ishikawa o diagramas espina de
pescado, que ilustran como las causas y subcausas varias se
relacionan para crear problemas o efectos potenciales. La
Figura 8-2 es un ejemplo genérico de un
diagrama causa-y-efecto.
Flujogramas de sistemas o procesos, muestran como
los elementos varios de un sistema se interelacionan. La
Figura 8-3 es un ejemplo de un flujograma para la
revisión de diseños.

Los flujogramas pueden ayudar al equipo de proyecto a
anticipar donde y que problemas de calidad pueden ocurrir y por
lo tanto puede ayudar a desarrollar aproximaciones que traten con
ellos.

Diseño de experimentos. El diseño de
experimentos es una técnica analítica que ayuda a
identificar que variables
tienen la mayor incidencia en los resultados generales. La
técnica se aplica de manera más frecuente a los
resultados de los temas de discusión del proyecto (e.g.,
los ingenieros automotrices pueden desear conocer que
combinación de suspensión y llantas producen las
características más deseables de
conducción a un precio
razonable).

Sin embargo, también se puede aplicar a temas de
la administración de proyectos tales como las perdidas y
ganancias que se obtienen entre las distintas combinaciones
posibles de programación y costos. Por ejemplo, los
ingenieros senior costaran más que los ingenieros junior,
pero también se puede esperar que terminen su trabajo
asignado en menos tiempo. Un "experimento" apropiadamente
diseñado (en este caso, el computo de costos y tiempos de
proyecto para las distintas combinaciones de ingenieros senior y
junior) muchas veces permitirá la determinación de
una solución óptima desde un número limitado
de casos.

8.1.3 Salidas de la Planeación de la
Calidad

Plan de administración de la calidad.
El plan de administración de la calidad deberá
describir como el equipo administrativo del proyecto
implementara su política de calidad. En la
terminología de ISO 9000, este deberá describir
el sistema de calidad del proyecto: "la estructura
organizacional, responsabilidades, procedimientos, procesos, y
recursos que se necesitan para implementar la
administración de la calidad" [5].
El plan de administración de la calidad
provee entradas al plan general del proyecto (que se describe
en la Sección 4.1, Desarrollo del Plan del Proyecto) y
deberá atender el control de calidad, aseguranza de la
calidad, y mejoramiento de la calidad para el
proyecto.
El plan de administración de la calidad puede
ser formal o informal, altamente detallado, o de base amplia,
dependiendo de las necesidades del proyecto.
Definiciones operacionales. Una
definición operacional describe, en términos muy
específicos, que es algo, y como se mide por el proceso
de control de calidad. Por ejemplo, no es suficiente decir que
cumplir con las fechas planeadas es una medida de la
administración de la calidad; el equipo administrativo
del proyecto deberá indicar también si cada
actividad tiene que comenzar a tiempo, o solo terminar a
tiempo; especificar si las actividades individuales
serán medidas o solo serán medidas ciertas
entregas, y si es así, cuales serán estas. Las
definiciones operacionales también son llamadas
métricas en algunas áreas de
aplicación.
Lista de chequeo. Una lista de chequeo es una
herramienta estructurada, usualmente específica a una
industria o actividad, usada para verificar que un juego de
pasos requeridos han sido ejecutados. Las lista de chequeo
pueden ser simples o complejas. Usualmente son frases
imperativas ("¡Haga esto!") o, frases interrogantes
("¿Ha hecho esto?"). Muchas organizaciones tienen listas
de chequeo estandarizadas para asegurar la consistencia de
actividades ejecutadas de manera frecuente. En algunas
áreas de aplicación, las listas de chequeo
están disponibles por medio de organizaciones
profesionales o por proveedores de servicios
comerciales.
Entradas a otros procesos. El proceso de
planeación de la calidad puede identificar la necesidad
de actividad adicional en otras áreas.

Aseguranza de la Calidad

La aseguranza de la calidad son todas las actividades
planeadas y sistemáticas implementadas dentro del sistema
de calidad para proveer la confianza de que el proyecto va a
satisfacer los standards de calidad relevantes [6]. Esta se
deberá ejecutar a través de todo el proyecto.
Anterior al desarrollo de la Serie ISO 9000, las actividades
descritas bajo planeación de la calidad se incluían
de manera amplia como parte de la aseguranza de la
calidad.

La aseguranza de la calidad se provee muchas veces por
medio de un Departamento de Aseguranza de la Calidad u
organización de título similar, pero esto no es
indispensable.

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

Página anterior

Volver al principio del trabajo

Página siguiente