Monografias.com > Uncategorized
Descargar Imprimir Comentar Ver trabajos relacionados

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

  1. Lista de actividades. La lista de
    actividades se describe en la sección
    6.1.3.1.
  2. 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.
  3. 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.
  4. 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.

  1. 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.
  2. Restricciones. Las restricciones se describen
    en la Sección 6.1.1.4.
  3. Suposiciones. Las suposiciones se describen en
    la Sección 6.1.1.5.
  1. Técnicas y Herramientas para la Secuencia
    de Actividades.
  1. 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.

  1. 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.
  2. 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.
  3. 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.
  1. Salidas de la Secuencia de
    Actividades
  1. 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.
  2. 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.

  3. 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.
  1. 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
  2. Estimación de la Duración de las
    Actividades
  1. Lista de actividades . La lista
    de actividades se describe en la Sección
    6.1.3.1.
  2. Restricciones. Las restricciones se describen
    en la Sección 6.1.1.4.
  3. Suposiciones. Las suposiciones se describen en
    la Sección 6.1.1.5.
  4. 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.
  5. 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.
  6. 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.
  1. Herramientas y Técnicas para la
    Estimación de la Duración de las
    Actividades
  1. 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.

  2. 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.)
  3. 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).
  1. Salidas de la Estimación de la
    Duración de las Actividades
  1. 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.

  1. Bases de estimación. Las suposiciones
    hechas en el desarrollo de los estimativos deberán estar
    documentados.
  2. Actualizaciones a la lista de actividades. Las
    actualizaciones a la lista de actividades se describen en la
    Sección 6.2.3.2.
  1. 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

  1. Diagrama de red del proyecto. El
    diagrama de red del proyecto se describe en la Sección
    6.2.3.1.
  2. 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.
  3. 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.

  4. 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.
  5. 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).
  6. 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.
  1. Suposiciones. Las suposiciones se describen en
    la Sección 6.1.1.5.
  2. 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

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

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

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

  1. 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.
  2. 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.
  3. 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.
  4. 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.
  1. Herramientas y Técnicas para el Control
    de la Programación
  1. 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.
  2. 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.
  3. 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.
  4. 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.
  1. Salidas del Control de la
    Programación
  1. 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.
  2. 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.

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

  1. 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.
  2. 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.
  3. Presupuestaron de Costos— es asignar
    el presupuesto general de costos a cada ítem
    individual de trabajo.
  4. 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.

  1. Herramientas y Técnicas para la
    Planeación de Recursos
  1. 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.
  1. 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

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

  1. 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.
  2. Requerimientos de recursos. Los requerimientos
    de recursos son descritos e la Sección
    7.1.3.1.
  3. 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.
  4. 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).
  5. 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.
  1. 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

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

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

  4. 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.
  5. 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.
  1. Salidas de la Estimación de
    Costos
  1. 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.
  2. 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.

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

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

  1. Estimados de costos. Los
    estimados de costos se describen en la Sección
    7.2.3.1.
  2. 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.
  3. 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

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

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

  1. Línea de base de costo. La
    línea de base de costos se describe en la Sección
    7.3.3.1.
  2. 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.
  3. 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.
  4. 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.

  1. 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.
  2. 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.
  3. 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.
  4. 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

  1. 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.
  2. 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.
  3. 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.
  4. 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.

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

  1. Planeación de la Calidad— es
    identificar que standards de calidad son relevantes al
    proyecto y determinar como satisfacerlos.
  2. 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.
  3. 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.

  1. Entradas a la Planeación de la
    Calidad
  1. 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.
  2. 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).

  3. 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.
  4. 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.
  5. 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.
  6. 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.
  1. Herramientas y Técnicas para la
    Planeación de la Calidad
  1. 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.
  2. 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.
  3. 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.

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

  1. 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].
  2. 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.

  3. 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.
  4. 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.
  5. Entradas a otros procesos. El proceso de
    planeación de la calidad puede identificar la necesidad
    de actividad adicional en otras áreas.
  1. 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 trabajoPágina siguiente 

Nota al lector: es posible que esta página no contenga todos los componentes del trabajo original (pies de página, avanzadas formulas matemáticas, esquemas o tablas complejas, etc.). Recuerde que para ver el trabajo en su versión original completa, puede descargarlo desde el menú superior.

Todos los documentos disponibles en este sitio expresan los puntos de vista de sus respectivos autores y no de Monografias.com. El objetivo de Monografias.com es poner el conocimiento a disposición de toda su comunidad. Queda bajo la responsabilidad de cada lector el eventual uso que se le de a esta información. Asimismo, es obligatoria la cita del autor del contenido y de Monografias.com como fuentes de información.

Categorias
Newsletter