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