CAPÍTULO 3

MODELOS DE BUENAS PRÁCTICAS PROGRAMA DESCRIPCIÓN GENERAL

Este capítulo está diseñado para proporcionar orientación e información sobre buenas prácticas aceptadas

generalmente relacionadas con la planificación, desarrollo, mantenimiento, comunicación y procesos de

elaboración de informes de un modelo de cronograma eficaz. Este capítulo está dividido en las siguientes

secciones:

3.1 Modelo de Programación

3.2 Modelo de creación

3.3 Modelo de mantenimiento

3.4 Análisis del modelo Calendario

3.5 Comunicación y de la información

Cada sección proporciona requisitos comunes, terminología y funciones asociadas. Estas secciones vinculan

la discusión de los procesos de programación que se describe en el Capítulo 2 para la programación de

componentes definidos en el Capítulo 4. Este capítulo ofrece una visión general, con ejemplos, de cómo

crear y mantener un modelo de cronograma eficaz.

3.1 Modelo de Programación

El Modelo de Programación de Gestión comprende la planificación de las actividades del equipo de

proyecto como parte de la elaboración de un proyecto de Plan de Gestión de conformidad con la Sección 4.2

de la Guía PMBOK ® de Cuarta edición. El Modelo de Programación de Gestión contribuye a garantizar que

todos los procesos de los Grupos de Gestión de Proyectos y áreas de conocimiento se integren

adecuadamente en el calendario general. Un programa modelo exige que la planificación y el diseño de la

misma manera que cada proyecto de entrega es planificado y diseñado. El equipo del proyecto debe

considerar una serie de factores para crear un programa modelo que puede ser una herramienta útil para el

proyecto. Esta herramienta se utiliza para supervisar el rendimiento en el proyecto, comunicar la

información relativa a la labor, y comparar el trabajo planeado con el progreso real. Estos conceptos se

desarrollan en apoyo de la elaboración de un proyecto Plan de Gestión de conformidad con el PMBOK®

Guide.

Modelo de gestión direcciona lo siguiente:

• Los procesos y procedimientos de gestión de datos de modelo, como formato de datos, el control de

versiones, la accesibilidad, el almacenamiento y la recuperación de los datos.

• Las políticas relacionadas con la metodología que se utilizará en el programa modelo de desarrollo y

mantenimiento, como los umbrales de rendimiento, el contenido y la frecuencia de presentaciones e

informes, administración de valor ganado (EVM) implementación e integración, compatibilidad con otros

planes y proyectos, el riesgo de granularidad y actividad. Al determinar el tipo de actividad granularidad,

demasiados detalles produce un confuso y demasiado grande programa modelo que es difícil y costoso de

administrar; muy poco detalle no hay información suficiente para el control permanente del proyecto.

• Consideraciones de las obligaciones contractuales y potencial de contrato pasivos (reclamaciones,

mediación, arbitraje, litigios, etc.).

• Procesos y procedimientos para la planificación, la actualización y mantenimiento de la fecha modelo

durante el ciclo de vida del proyecto, la determinación de un ciclo correspondiente para la recogida del

estado del proyecto y la actualización de la lista modelo. El tiempo de ciclo entre las actualizaciones

deberían ser suficientes para la información de la última actualización se ha publicado, analizados, y actuó

por el equipo del proyecto antes de la próxima actualización. El ciclo de actualización debe cumplir con el

contrato o activos de los procesos de la organización.

• Necesidades de Capacitación para los miembros del equipo de proyecto, como un entendimiento común

de las directivas de programación, procedimientos y tecnologías de software, por ejemplo, informes de

progreso, que le permite capturar los riesgos del proyecto , y que refleja las actividades de mitigación en la

lista modelo.

3.1.1 Plan de Gestión de Datos

Antes de añadir los datos de la lista modelo, el equipo de proyecto debe centrarse en el diseño del modelo

programa. El equipo del proyecto debe definir algunas entradas programación básica modelo y los

resultados que se esperan para asegurar que la infraestructura mínima, necesaria para apoyar necesidades

de los interesados, se coloca en su lugar. Además, el ámbito de aplicación, estructura de desglose de

trabajos (WBS), definición de recursos (cuando sea necesario), y otros componentes de la planificación debe

estar ya definido para que el equipo no tiene que definido estos elementos en la elaboración de la lista

modelo. En un mínimo, el equipo del proyecto debe considerar las siguientes en el desarrollo del programa

plan de administración de datos:

• Definir la lista de los usuarios, los derechos de acceso, y las responsabilidades que tiene cada uno. Por

ejemplo, algunos usuarios sobre los progresos realizados, mientras que otros tendrán acceso a una mayor

planificación y se encargará de las funciones administrativas.

• Determinar la frecuencia (es decir, diario, semanal, o mensual) para la copia de seguridad de datos del

programa. Las copias de seguridad son una parte importante de datos del programa gestión de la

configuración. Frecuencia de las copias de seguridad son a menudo establecidas por las expectativas de las

partes interesadas.

• Determinar cómo las versiones anteriores del programa se va a recuperar, con qué frecuencia, y verificar

que los procedimientos de recuperación de datos son exactos. Un error común es que los backups se

realizan pero no hay un procedimiento de extracción.

• Determinar los requisitos de retención de datos del programa.

• Identificar los riesgos asociados con el desarrollo del programa modelo relacionados con el programa

gestión de datos.

• Determinar la jerarquía de datos requisitos para la elaboración de informes (tal como se define en el plan

de comunicación) y cómo estos requisitos tendrá un impacto en los procesos de gestión de datos y el

modelo de datos. Por ejemplo, los tipos de actividades que se indican en el comité de dirección son

diferentes que los que se muestran al jefe de proyecto.

3.1.2 Modelo de Plan de Gestión

El programa modelo plan de gestión es un conjunto de procesos, métodos, modelos y herramientas para el

logro de los objetivos de proyecto. Una buena práctica dicta que, todos modelos de pauta deberá ser guiado

por una metodología que proporciona una lista de comprobación de los requisitos para el programa modelo

para garantizar la calidad de la programación.

El programa modelo plan de gestión permite los miembros del equipo de proyecto para realizar de una

manera coherente. Proyectos con ningún plan tienden a ser ineficientes, lo que se traduce en un mayor

costo, mayor riesgo y más duración. El programa modelo plan de gestión incluye los siguientes pasos:

.1 Selección de un método de planificación

El equipo del proyecto, con el planificador como facilitador, debe tener acceso a la documentación sobre el

programa disponible métodos aprobados por la organización con el fin de cumplir con la organización y

necesidades del proyecto. Basándose en esta información, el programador implementa el método de

planificación según lo determinado por el equipo del proyecto. (Para obtener más información acerca de

métodos de programación, consulte la sección 2.2).

.2 Selección de una herramienta de programación

La selección de la herramienta de programación se basará en el método de planificación seleccionado y que

cumplirá con la organización y los requisitos que debían cumplir los proyectos relacionados con la

herramienta.

.3 Plan de Creación de modelos

El director de proyecto, en colaboración con el equipo del proyecto y de los principales interesados,

determina el plan de programación creación de modelos. Las consideraciones clave incluyen: la planificación

y participación de los interesados directos en el proceso de desarrollo de conformidad con la Guía PMBOK ®

-Cuarta edición.

.4 Programa Modelo ID

Cada programa a las necesidades del modelo tiene un único método de identificación específica del

proyecto.

.5 Programa Versión del modelo

Cada instancia de la lista modelo tiene un único identificador de versión. La ubicación de esta identificación

puede variar en función de los activos de los procesos de la organización y las herramientas utilizadas para

su control. Un único modelo de identificador de versión es esencial para permitir que el archivo adecuado

de los documentos de los proyectos y procesos de auditoría. El programa modelo plan de gestión

proporcionará el formato de este componente de nombres redundantes para que no se produce.

.6 Los calendarios y períodos de trabajo

Un proyecto predeterminado calendario se define mediante períodos de trabajo. Períodos de Trabajo

también puede ser definido para la realización de actividades específicas o partes del proyecto, incluyendo

los recursos. Algunos de los elementos naturales incluyen:

• Definir los días de trabajo en una semana.

• Definir el número de turnos que se va a trabajar cada día.

• Definir el número de horas trabajadas cada turno o día.

• Define los períodos de "horas extraordinarias" de trabajo.

• Definir el tiempo de no trabajo (p. ej., vacaciones, paradas, fechas en que no horarios restringidos, etc.).

Estos elementos juegan un papel importante en la determinación del número y la estructura de los

calendarios de proyecto es necesaria para el programa. El uso de múltiples calendarios presenta un alto

grado de complejidad para el cálculo de la posición de flotación y la ruta crítica. Sin embargo, mientras que

programar es simplificado por el uso de un único calendario, un calendario puede ser insuficiente para la

gestión del proyecto (p. ej., un equipo de proyectos internacionales relacionados con las fiestas locales).

Práctica generalmente aceptada es utilizar un proyecto predeterminado calendario que es razonable y

adecuado para realizar el trabajo, sobre la base del proyecto de tiempos de trabajo normales. El calendario

del proyecto se utilizará como el calendario predeterminado para las actividades del proyecto. Esta práctica

permite que el equipo de proyecto para establecer y programar diferentes períodos de trabajo o

calendarios, si es necesario, para realizar determinadas actividades.

.7 Proyecto Ciclo de actualización

El ciclo de actualización es el intervalo normal en la que el estado del proyecto. La frecuencia adecuada para

realizar las actualizaciones y situación en materia de presentación de informes con el programa. Esto incluye

determinar en qué momento del ciclo se producirá la actualización y la frecuencia con la que el estado será

informado. El ciclo de actualización refleja la gestión se propone utilizar los datos generados a partir de la

programación, incluyendo la distribución de las reuniones de revisión, informes de gestión, y ciclos de pago

que a menudo están vinculados a las actualizaciones. Seleccione un ciclo de actualización de gestión con un

nivel óptimo de control de la información sin ser excesivamente oneroso para la gente que hace el informe y

análisis. El ciclo de actualización óptima variará con la industria y con la intencionalidad de actualizaciones

cada hora de interrupción planeada proyectos de instalaciones de producción y fabricación de

actualizaciones semanales o mensuales de construcción importantes o los proyectos de desarrollo de

software. El ciclo de actualización tiene una relación directa sobre la duración de las actividades contenidas

en el programa.

Profesionales con experiencia a menudo dividir el ciclo de actualización en dos partes distintas: informes de

progreso y mantenimiento. Esto sirve para reducir el tiempo dedicado a la elaboración de informes de

progreso un período de tiempo mínimo.

La elección del ciclo de actualización está influenciada por una serie de factores, tales como la tasa de

cambio en el proyecto, la duración del proyecto, etc. Para relativamente estable, a largo plazo, proyectos de

bajo riesgo, un estado mensual o bimensual ciclo puede ser apropiado. De volátiles, proyectos de alto

riesgo, las actualizaciones pueden ser necesarios para cada cambio de turno o de una hora.

El equipo del proyecto debe considerar qué escala de tiempo debe utilizarse: minutos, horas, días, semanas

o meses, la respuesta depende de la frecuencia de los procesos de control y el nivel de detalle necesario en

las actividades. La mayoría de las veces, la actividad escalas de tiempo seguirá siendo coherente a lo largo de

todo el proyecto. Sin embargo, las evoluciones específicas del proyecto pueden requerir diferentes escalas

de tiempo efectivo de esa evolución.

.8 Actividad Hito y estructura de codificación

Descripción de los tipos de informes, necesita del programa modelo para crear una presentación (vea la

Figura 2-7) del programa modelo proporciona orientación sobre la codificación de las estructuras integradas

en el programa modelo.

La estructura de codificación debe ser desarrollada de manera de seleccionar, ordenar y agrupar datos del

programa puede realizar fácilmente. Esta codificación se prestará asistencia en el desarrollo y

mantenimiento del programa modelo, así como a satisfacer los requisitos de presentación de informes

sobre proyectos. Codificación de las estructuras también son muy útiles para analizar los datos de

rendimiento proyecto de la agrupación, selección y clasificación para resaltar tendencias y anomalías.

Debe hacerse hincapié en utilizar un sólido y bien concebido una actividad de estructura de codificación que

es independiente de la actividad identificador. Las actividades se pueden codificar con más de un código

para cada actividad, con cada uno de los códigos con un valor por separado, lo que permite que productos

que se pueden personalizar para diferentes fines. Por ejemplo, los códigos se pueden utilizar para identificar

las fases de los proyectos, subfases, el lugar de trabajo, el proyecto eventos, puertas, importantes logros, las

fuentes de suministro, fuente de diseño, la persona u organización responsable de realizar la actividad, etc.

Estos códigos se pueden utilizar solos o en combinaciones múltiples. Para lograr flexibilidad y funcionalidad

mejorada, más software de programación es compatible con varios códigos para cada actividad.

UNA actividad estructurada de numeración o de identidad debe formar parte de todo el diseño de

codificación. El uso de un sistema de identificación actividad estructurada proporciona a los usuarios

programar una mejor comprensión de cómo una actividad en particular se integra en el proyecto más

grande imagen sujetándolo por la importancia de la actividad propio identificador. Por ejemplo, la identidad

puede incluso volver a unir al proyecto EXPERIENCIA Como mínimo, una actividad identificador debe ser

único y siga un plan adecuado para el proyecto.

.9 Planificación de Recursos

Si el programa es modelo para incluir recursos de cualquier tipo, el programa modelo de gestión plan

identifica los elementos necesarios para la planificación de los recursos y la gestión. Los elementos a

considerar son los recursos disponibles, los calendarios de recursos, recursos y habilidades. Aunque carga de

recursos del programa modelo no es necesario, esta práctica estándar es una buena práctica y se reconoce

que los recursos deben ser considerados por el equipo del proyecto al determinar el tipo de actividad y

duración secuencia actividad. Un recurso cargado calendario indica claramente la interdependencia e

impactos que la disponibilidad de los recursos tendrá en la duración del proyecto y su costo.

.10 Indicadores de rendimiento

Para que los interesados sepan cómo el proyecto está llevando a cabo, muchos proyectos define los

indicadores clave de rendimiento (KPI) que permitió que el equipo del proyecto para medir los progresos y

resultados predefinidos hacia metas del proyecto (por ejemplo, valoraciones de los clientes/información,

equipo de proyecto calificaciones y EVM). EVM tiene la capacidad de combinar medidas de alcance,

programación y costo en un único sistema integrado de indicadores basados en los costos. EVM puede

ampliarse para incluir el concepto de ganado, que tiene el objetivo de proporcionar indicadores basados en

el tiempo a fin de complementar los indicadores basados en los costos de ejecución de los proyectos. Para

obtener más información acerca de EVM y ganado, hacen referencia a la práctica estándar de valor

obtenido.

.11 Modelo Plan Maestro

El programa modelo puede ser diseñado y construido como un proyecto principal que contiene los

subproyectos. Los subproyectos puede ser estructurado de acuerdo a los distintos equipos que componen el

proyecto, tales como ejecución por etapas (ingeniería, producción, pruebas, e integración), distribuido en

todo el mundo equipos, o las estrategias (varios proyectos, varios jefes de proyecto). Estos subproyectos

deben estar vinculadas entre sí en determinadas entrega/aceptación o puntos de interfaz, a fin de que haya

una conexión entre los planes. El programa modelo plan de gestión, definir los pasos necesarios para crear,

gestionar y controlar el programa maestro, subproyectos e interdependencias del proyecto.

3.2 Modelo de creación

Esta sección ofrece una visión general de los elementos esenciales para el desarrollo de un buen horario

modelo. Las buenas prácticas se muestran para cada uno de los componentes contenidos en la lista de

componentes de esta práctica estándar en el Capítulo 4. La revisión del Capítulo 4 se recomienda

encarecidamente a comprender todos los aspectos relacionados con cada uno de los componentes. Es

esencial tener en cuenta toda la información, los procedimientos y las restricciones en el programa modelo

de gestión.

El propósito del programa es proporcionar un útil plan detallado que puede ser utilizado por el gerente de

proyecto y el equipo del proyecto para ayudarles a completar el proyecto con éxito. El programa modelo se

convierte en una herramienta desarrollada por el equipo del proyecto que los documentos del equipo la

visión de cómo el proyecto se llevará a cabo.

El programa incluye actividades cuando se supone que inicio y termine y se modifican apropiadamente para

reflejar los cambios en curso, el alcance, etc., a medida que se añaden al programa modelo durante el ciclo

de vida del proyecto.

Un modelo de desarrollo es un instrumento dinámico que se utiliza para proporcionar un nivel razonable de

predicción cuando el resto del proyecto se puede espera lograr. Al mismo tiempo, le permite al equipo del

proyecto a mirar los resultados del proyecto hasta la fecha, así como a utilizar esos datos para hacer

pronósticos exactos para el proyecto las evoluciones que quedan por realizar. Además, una vez que el

proyecto se ha completado, el modelo de la base de la experiencia adquirida y se convierte en la base de

proyectos similares en el futuro.

El programa modelo describe la labor que se ha de realizar (¿qué? ), los recursos necesarios para hacer el

trabajo (quién y qué), y la secuencia de actividad óptima con inclusión de la actividad comienza y termina, y

las relaciones (cuando). La forma de realizar el trabajo (cómo) es definida por otros documentos en el plan

general del proyecto. Establecer un calendario realista y alcanzable modelo es uno de los críticos acciones

iniciales. Algunos puntos importantes a tener en cuenta durante la creación de modelos de son:

• Determinar que los requerimientos del proyecto son entendidos y satisfechos. El equipo del proyecto

comentarios y entiende el alcance del proyecto documentos con especial atención a la EXPERIENCIA El

alcance del proyecto documentos proporcionar los antecedentes, información y comprensión necesarios

para desarrollar el programa modelo. El objetivo es garantizar que todos los aspectos de la ejecución del

proyecto han sido suficientemente definidos y se incluye en el programa modelo. Las actividades en el

programa modelo representan el trabajo que produce las entregas o paquetes de trabajo identificadas en el

WBS; por lo tanto, los paquetes de trabajo en la WBS debe atribuirse directamente a una actividad

programada o grupo de actividades. A menudo las actividades de programación se pueden organizar de tal

forma que reflejan la jerarquía de la EXPERIENCIA Por otro lado, en cada una de las actividades debe

acumular en un solo elemento WBS.

• Verificar disponibilidad de recursos y asignaciones. El equipo del proyecto beneficia en gran medida de un

recurso de programación. La mano de obra, materiales, equipos y la infraestructura necesaria para llevar a

cabo las actividades del proyecto se pueden planificar con antelación de las necesidades y problemas

pueden mitigarse. UNA programación básica modelo producido por un proyecto supone que obra suficiente

y el equipo estén disponibles para la realización de las actividades según lo programado. Esto no siempre es

el caso porque en un gran proyecto, puede que no resulte evidente que existe una falta de recursos. En el

caso de grandes y complejos proyectos que implican a múltiples organizaciones y tienen una larga duración,

es posible que tenga que incluir recursos en la lista modelo. Ver Guía PMBOK ® -Cuarta Edición para obtener

más información sobre los recursos. Al igual que los códigos de actividad que se utiliza para clasificar y

organizar las actividades, los códigos de recursos (atributos) se le puede asignar a los recursos para clasificar

los recursos de acuerdo a la organización, nivel de habilidad o el tipo, la estructura de los informes, etc.

Además, identificadores de recursos puede ser estructurado en un auténtico régimen, de naturaleza similar

a la de actividad ID's.

3.2.1 Desarrollar programa de Referencia Modelo

El desarrollo de un buen horario modelo se logra a través de la aplicación coherente de las prácticas. La

experiencia adquirida con el tiempo ayudará a seleccionar las respuestas adecuadas a los requerimientos de

diseño para la programación. Los pasos clave son:

.1 Definir hitos

Una vez se haya llegado a un entendimiento de la estructura global de los datos del proyecto se ha dicho

anteriormente, comenzar a diseñar las etapas del proyecto. Los hitos no tendrá ninguna duración, no

tendrá recursos asignados, se utilizará como referencia para medir los progresos realizados, y puede

también reflejar los puntos de salida y llegada para los diferentes eventos de proyectos. Por lo general,

representará un hito al inicio o finalización de una porción o entregable del proyecto y también puede

estar asociada a limitaciones externas, tales como la entrega de permisos específicos necesarios o equipo.

Cada proyecto debe tener un hito inicio y un final hito. El proyecto contendrá una lista de hitos desarrollado

inicialmente como el programa modelo es creado. Estos pueden tener su origen en el cliente, los miembros

del equipo o de otras partes interesadas. Como el programa modelo a los nuevos hitos se agregan como sea

necesario. Es un proceso iterativo (Nota: Las actividades se pueden definir hitos antes.)

.2 Diseñar las actividades del proyecto

Empezar a crear la lista de actividades que se deben realizar para completar el proyecto, que se basa en la

EDT (WBS) y elaborado por el equipo que se encargará de la ejecución de la obra. Las características de un

bien diseñado de actividad incluyen:

• La actividad es un elemento mensurable y discreto (o bloque) del trabajo, lo que es un elemento tangible

del alcance del proyecto.

• Una sola persona es responsable de la ejecución de la actividad. Esto no excluye la idea de que varios

recursos pueden ser necesarios para llevar a cabo la actividad, pero es necesario que una sola es la entidad

responsable de su desempeño. Esta persona debe ser el mismo que se informe sobre los progresos

realizados en la actividad.

• Describir la labor que debe llevarse a cabo. Como tal, la descripción de cada actividad se inicia con un

verbo y contiene un único objeto específico. A pesar de que "pour muro" puede ser descriptivo de una

tarea, la descripción de la actividad debe ser más específica. Los adjetivos pueden ser útiles para aclarar las

ambigüedades. Por ejemplo, "pour la pared este fundamento de x a y" o "consulte el Capítulo 3 sobre la

terminología." Cada descripción de la actividad debe ser único y no dejan lugar a la confusión, es decir, que

se puede identificar sin ambigüedad y debería ser independiente de la programación presentación

agrupación u organización.

• La labor representada por una actividad, una vez iniciado, debe ser capaz de continuar hasta el final sin

interrupción (excepto para no natural de períodos de trabajo en el calendario). Si el trabajo en una actividad

se ha suspendido o aplazado, a menudo resulta beneficioso para la actividad que se va a dividir en dos o más

actividades en los puntos de ruptura.

Por lo general, una actividad de duración debe ser inferior a dos veces el ciclo de actualización. Esto permite

que la presentación de la hora de inicio y de fin de una actividad dentro de uno o dos ciclos actualización,

permitiendo a la gerencia a centrarse en el rendimiento y medidas correctivas en caso necesario. Las

excepciones a esta regla general son actividades continuas (p. ej., resumen actividades como aburrido 2

millas de largo túnel o pavimentación varias millas de la autopista), las actividades de adquisición en caso de

que un único elemento de trabajo (p. ej., fabricación y transporte de un componente a un sitio remoto)

puede tardar bastante más que dos ciclos actualización, o un nivel de esfuerzo (LOE) actividad como las de

apoyo administrativo.

En estos casos, la duración de la actividad debe reflejar simplemente el momento previsto para la actividad.

Las necesidades de cuidado de LOE actividades, porque si se les dan las duraciones estática igual a la

longitud de todo el proyecto, pueden terminar o de conducción en la ruta crítica. Por su naturaleza misma,

de apoyar las actividades de trabajo, LOE no puede conducir la duración del proyecto y no puede ser crítico.

Es una buena práctica para definir LOE actividades de tal manera que se tendrá la duración de las

actividades detalladas que son compatibles.

Una vez finalizado el proceso, la lista de actividades se describirá el 100% del trabajo necesario para

completar el proyecto, aunque no necesariamente todas las actividades tienen que estar completamente

detallado si ola está utilizando los planes.

.3 Actividades Secuencia

La secuenciación de actividades e hitos fundamentales junto con la lógica es la base de cualquier

programa. El método de conexión se define como una relación. Cada una de las actividades, excepto en lo

referente a la primera etapa (con un predecesor) y el último (y que no hay sucesor) deberá estar conectado

al menos a un predecesor y un sucesor. Con la excepción del inicio hito, algo tiene que ocurrir antes de

iniciar cualquier actividad y, a su vez, la actividad tiene que ser total o parcialmente ejecutado para permitir

que otra actividad para iniciar. Velar por el cumplimiento de esta práctica se evitará que el programa

contenga de extremos abiertos, donde las actividades o hitos faltan predecesores o sucesores, con la

excepción del primero y último hitos.

Normalmente, cada actividad anterior podría terminar antes del inicio de su sucesor actividad (o

actividades) (conocido como un fin a inicio (FS) relación). A veces es necesario las actividades superpuestas,

una opción puede ser seleccionado para uso de principio (SS), fin a fin (FF) o principio a fin (SF) relaciones. La

figura 3-1 muestra ejemplos de los cuatro tipos de relaciones en el PDM, la más comúnmente utilizada

metodología CPM). Siempre que sea posible, el FS relación lógica se debe utilizar. Si otros tipos de

relaciones se utilizan, deben usarse con moderación y con pleno entendimiento de cómo las relaciones se

han llevado a cabo en el software de programación que se utiliza. Idealmente, la secuencia de todas las

actividades se define de tal modo que el inicio de cada actividad tiene una relación lógica de un predecesor y

el acabado de cada actividad tiene una relación lógica a un sucesor.

Figura 3-1. Las ilustraciones de Tipos de relación en CPM Metodología

Lag(s) también pueden ser asignadas a algunas relaciones. UN lag impone una demora entre la anterior y la

siguiente actividad. Por ejemplo, si una actividad tiene un SS dependencia con un retraso de 1 a 5 días,

retrasar el inicio de la actividad de sucesor hasta 5 días después de la actividad anterior ha comenzado. El

planificador se advirtió a utilizar los rezagos con cuidado y comprender sus impactos. Los retrasos son sólo

para ser utilizado para representar los retrasos que físicamente son necesarios y no es trabajo, y duración.

Algunos planificadores pueden verse tentados a utilizar va a representar un período de tiempo cuando el

trabajo, como la revisión de un documento antes de la siguiente fase. Se recomienda que estos tipos de

trabajo se muestra como las actividades en el programa modelo en lugar de utilizar un lag. Cuando estas

actividades se incluyen, que podrían ser codificados para mostrar que estas son las actividades realizadas

por otro parte, por ejemplo el cliente es el responsable. Esta práctica permite un mejor control del proyecto

y lo hace muy visible si comunicamos una entidad está impactando en el proyecto.

Con más de un calendario en un calendario modelo calculado puede afectar a la zaga los resultados dentro

de la lista modelo. Además, el hecho de conocer cómo los distintos paquetes de software utilizar varios

calendarios es sumamente importante.

También es posible asignar las limitaciones a las actividades y los hitos que requieren la actividad o el hito de

empezar o terminar en puntos específicos en el tiempo. Estudio de los diferentes tipos de limitaciones que

podrían ser utilizados y comprender los efectos y matices su uso sobre el programa antes de su uso. La

práctica generalmente aceptada es que las limitaciones y retrasos no se deben utilizar para sustituir la

adición de las actividades y relaciones. Sin embargo, como un ejemplo, la utilización de las restricciones es

generalmente reconocida como sea necesario para cumplir con las obligaciones contractuales.

En general, en cada una de las actividades deben tener una F-S o S-S predecesor y un F-S o F-F sucesor. Sin

estos tipos de relaciones lógicas las actividades se denominan "colgando" y de la incertidumbre de su

duración no necesariamente se transmite al resto de la lista modelo como debe ser.

.4 Determinar los recursos destinados para cada actividad

Estimar los recursos de las actividades es el proceso de determinar el tipo y la cantidad de material,

personal, equipo, o infraestructura necesaria para realizar cada actividad. Si un proyecto está limitada en

términos de recursos y la duración del proyecto podría verse afectada, los recursos deben ser incorporados

en el programa modelo. A pesar de que a veces se hacen juntas, la estimación de recursos Actividad proceso

debe realizarse antes de estimar duración de las actividades (ver guía PMBOK ® -Cuarta Edición para obtener

más información). Las horas necesarias para un diseñador jefe para llevar a cabo la actividad frente a un

diseñador junior para realizar la misma actividad puede ser muy diferente, lo que repercute en la duración y

la calidad de los resultados de la actividad y en última instancia el coste del proyecto. En algunos proyectos,

especialmente los de menor alcance, definición de las actividades, la secuencia las actividades, estimar los

recursos, estimar duración de las actividades, y el desarrollo de la programación modelo son tan

estrechamente vinculados que son considerados como un solo proceso. Los recursos pueden afectar a la

ruta crítica si no se tiene en cuenta por el equipo del proyecto.

.5 Determinar la duración de cada actividad

La duración es una estimación de cuánto tiempo se tardará en realizar el trabajo de la actividad. En muchos

casos, el número de recursos que se prevé estarán disponibles para llevar a cabo una actividad, junto con la

productividad de los recursos, podrán determinar la duración de la actividad. Un cambio en la conducción de

recursos asignados a la actividad tendrá un efecto en la duración, pero esto no es un simple "línea recta"

relación. Otros factores que influyen en la duración son del tipo o nivel de habilidad de los recursos

disponibles para llevar a cabo el trabajo, los calendarios de recursos y la naturaleza intrínseca de la obra.

Algunas de las actividades (p. ej., 24 horas prueba de esfuerzo) tendrá un periodo de tiempo determinado

para completar independientemente de la asignación de recursos.

Aunque es posible estimar una duración de una actividad en cualquier momento, buenas prácticas

generalmente aceptadas recomienda definir la actividad first, atado, lógicamente en la secuencia del

programa global, para posteriormente centrarse en los recursos de la actividad y la duración. En este

momento, la relación entre la duración de la actividad y el trabajo en el programa será más fácil de

entender, así que las corrientes de recursos, la actividad tamaños de equipos, y el como se pueden

comenzar a determinar. La relación entre la actividad de duración y costo se hizo explícita en la base de

cálculo o de las afirmaciones de tanto el coste como la programación. Este documento debe mantenerse

como el calendario actual cambiar durante las duraciones programa mantenimiento modelo.

Consulte la Sección 3.3 Modelo de mantenimiento, así como la sección 3.4 en el Programa Análisis del

modelo para obtener más información.

Es importante comprender el método que se utiliza en el programa modelo con el fin de planificar las

actividades relacionadas con la estimación de la duración de cada actividad programada. El método utilizado

puede implicar un determinista o probabilística. Calendario modelos deterministas son las redes de las

actividades relacionadas con las dependencias que describen el trabajo a realizar, duración estática, y la

fecha prevista para finalizar el proyecto si todo va según lo previsto. Modelos probabilísticos son redes

programación con todos los elementos de un programa modelo determinista, pero la duración de la

actividad de las tareas son variables aleatorias. Para obtener más información sobre la estimación duración

de la actividad, por favor referirse a la práctica estándar para estimar Proyectos. Para obtener más

información sobre las mejores prácticas de riesgo de los proyectos de análisis probabilístico de modelos, vea

la práctica estándar para la gestión de riesgos.

6. Analizar el Calendario de Salida

Una vez completado, el programa modelo contendrá un conjunto de actividades singulares, que tienen

diferentes duraciones, conectados por relaciones lógicas. Proporciona el equipo del proyecto con

información sobre lo que se debe realizar y la secuencia necesaria para realizar las entregas del proyecto.

Sin embargo, todavía no se indica si estas diversas actividades deben realizarse. Con el fin de adquirir la

información, la herramienta de programación está activada para calcular las fechas y otros valores dentro

del programa modelo de acuerdo con el método de planificación. A pesar de la rapidez de los muchos

programas de ordenador, la función de planificación requiere siempre tres procesos distintos análisis en

tiempo de un cuarto y, en su caso, en el proceso de suavizado o de nivelación de recursos está siendo

utilizada. Las medidas discretas son:

• La fecha de inicio se le asigna al hito inicio. A continuación, pasar a través de la red de una actividad a otra

(de izquierda a derecha) y en la secuencia definida por las relaciones lógicas, las fechas de inicio y

finalización se asignan a cada una de las actividades e hitos, como determinado por la duración. Esto se

conoce como el primer paso. Las fechas de inicio y de finalización de cada actividad se llama del inicio y

termine pronto las fechas, y cuando el análisis llega a la final de la red, se establece la lo antes posible

litosferica fecha para el proyecto y la menor duración del proyecto sobre la base de las actividades y las

duraciones estimadas relaciones lógicas como se define.

• A continuación, una fecha de finalización se asigna al hito final. Esta podría ser la misma fecha que el

calculado por el pase hacia delante o en una fecha diferente aplicado como una restricción. El proceso de

análisis, a continuación, funciona a través de la red de derecha a izquierda hasta que llega de vuelta al inicio

hito, y otro conjunto de fechas de inicio y de finalización se asigna a cada actividad. Este es el llamado paso

hacia atrás y establece el retraso en el inicio y las fechas de finalización tardía de cada actividad e hito.

• Valores flotantes se calcula mediante la comparación de las fechas tempranas y tardías de la siguiente

manera:

o Margen Total se calcula restando la fecha de finalización anticipada de la fecha de finalización con

retraso (o el comienzo temprano desde el inicio tardío). Total negativo medios de flotación las

fechas no son factibles sin cambiar el plan.

o Flotación libre se calcula restando la fecha de finalización anticipada de la actividad a partir de la

fecha de inicio más temprana de los primeros de sus sucesores. Flotación libre nunca es un valor

negativo.

• Una vez que la flotación se han calculado los valores de nivelación se puede llevar a cabo para reducir al

mínimo los recursos de asignaciones o reducir las fluctuaciones de demanda de recursos. Si este proceso se

realiza de forma automática, el programador debe determinar los procesos y algoritmos que se va a utilizar.

La mayoría de paquetes de software tienen varias opciones y de los valores que puede tener un impacto

significativo sobre el resultado final de recursos programa dúplex. Independientemente de los valores de

configuración del software de programación, no será más que un trade-off entre la necesidad de permitir

que la solución de nivelación para extender el proyecto duración total y permitiendo el uso de más recursos

que permite inicialmente. Los recursos nivelados en una zona de asignados en otras áreas.

Una vista completa de la distribución de recursos entre todas las actividades debe ser revisada antes de

finalizar la nivelación de recursos. Algunos pueden caer en la tentación de hacer de nivelación de recursos

manualmente mediante el ajuste de la lógica o agregar restricciones de retrasar el inicio de determinadas

actividades; esto no es una buena práctica ya que interfiere con el normal cálculo de la programación.

.7 Aprobar el Calendario

El equipo del proyecto debe participar activamente en el examen de los resultados de este primer proceso

de programación. El examen debe considerar el proyecto analizado fecha de finalización, hito fechas de

realización, rutas de acceso críticas (la más larga ruta de acceso para el proyecto o como restricción), total

valores flotantes y las necesidades de recursos (en comparación a la disponibilidad de recursos) para

determinar la aceptabilidad de la programación.

En caso de modificación se requiere, los cambios se realizan en la programación lógica, la asignación de

recursos y/o duración, y, a continuación, el programa se volvieron. La alteración más común involucra

acciones necesarias para reducir la duración total del programa. Las principales técnicas que se utilizan para

comprimir el calendario se estrellan y fast tracking. Bloquea consiste esencialmente de aumentar los

recursos de las actividades de importancia crítica para acortar su duración mientras que fast tracking

consiste en cambiar la lógica de las actividades de importancia crítica que se superponen en lugar de

trabajar estrictamente en secuencia. Bloquea sólo funciona para las actividades que son el esfuerzo por

aumentar los recursos que se reducirá la duración de la actividad."

Bloquea normalmente se incrementa los costos del proyecto por algún factor más rápido mientras que

aumenta el riesgo de la rectificación que las actividades se iniciaron antes sus primeros predecesores se han

completado. (Véase también el Capítulo 6 de la P MBOK® Guía de Cuarta Edición). Estas iteraciones hasta

que un modelo aceptable programa se ha desarrollado una solución que los principales actores del proyecto

pueden estar de acuerdo es un objetivo alcanzable. El proceso formal para la aprobación de modelo de la

línea se define en el modelo de plan de manejo.

.8 El Programa Modelo de Referencia

Una vez que se hayan acordado, la primera versión del programa que sea desarrollada para que se aprobara

para la captura o copia para referencia futura se llama la línea de base del proyecto de modelo. Este punto

de referencia se convierte en el referente con el funcionamiento del proyecto se puede medir. Es una

práctica generalmente aceptada que cada proyecto tiene un modelo de referencia en lugar antes de la

ejecución de los trabajos del proyecto. Una vez que la línea ha sido aprobada mediante procedimientos

formales, los informes se distribuyen de acuerdo con el proyecto de plan de comunicación y los cambios en

la base de referencia se supervisan y se controlan a través del proceso de control de cambios.

3.3 Modelo de mantenimiento

La mayoría de los proyecto inevitablemente experimentan cambios. Para garantizar la correcta ejecución de

los proyectos, control de cambios eficaz disciplinada y procedimientos de mantenimiento son necesarias. La

clave es determinar cómo el proyecto se apruebe y hacer un seguimiento de los cambios que se producen

en todo el ciclo de vida del proyecto. Puede producirse el cambio simplemente por el trabajo avanza más

rápido o más lento de lo previsto, así como los cambios que se producen en otros elementos del proyecto

(p. ej., cambios de alcance) y/o si el equipo del proyecto decide modificar su enfoque de los trabajos del

proyecto.

Seguimiento de los progresos comienza después de que el modelo de este proyecto es referenciado,

comienza el trabajo, y el seguimiento regular y controlar los procesos. Estos procesos son importantes para

ayudar a identificar los problemas tan pronto como sea posible, minimizando su impacto sobre la realización

satisfactoria del proyecto. Los pasos principales para el seguimiento de los progresos realizados son los

siguientes:

• Guardar una línea base programa modelo, que contiene las fechas de los progresos realizados se compara.

El calendario actual modelo pueden ser copiadas y aprobado como una línea de base, o un programa más

adecuado modelo podrá ser aprobado como una línea de base.

• El Calendario se da cuenta de los progresos realizados a partir de una determinada fecha de datos,

también conocida como fecha de estado, fecha de actualización, fecha y hora actuales ahora fecha, o de

fecha. Este progreso, como mínimo, debe incluir inicio y la finalización real fechas, duraciones restantes, y

por ciento completa.

• Asignar la nueva fecha de datos y calcular todas las fechas de la actividad son los últimos pasos para

avanzar el programa modelo.

El estado/proceso de actualización se produce de forma regular durante el proceso de la planificación del

proyecto. Los pasos involucrados en el mantenimiento del programa en cada estado/up date se describen

en el apartado 3.3.1 a 3.3.7.

3.3.1 Recopilar Datos Reales y el trabajo restante

Recoger el estado actual de los trabajos a intervalos de tiempo predeterminados para el proyecto. La

información recopilada incluye la fecha de comienzo real para todas las actividades que se han iniciado, y las

fechas de finalización reales de todas las actividades que se han terminado en la fecha de datos. En caso de

que una actividad está en curso, la cantidad de trabajo realizado y el tiempo necesario para completar el

trabajo restante se determina. Estado colección también incluye cambios en las duraciones de las

actividades futuras. Otros datos recogidos en este momento pueden incluir datos sobre la utilización de los

recursos y de los gastos realizados. Los datos se recogerán a partir de la fecha de datos designado

(fecha/hora). Esta fecha de datos es similar a "tiempo" en valor obtenido performance management

(EVPM).

3.3.2 Actualización y avances del programa modelo de acuerdo con los datos reales

Introducir información de estado en la lista modelo y analizar el trabajo restante para determinar el estado

del proyecto. Todo trabajo incompleto se volverá a programar en una fecha/hora igual o posterior a la fecha

de datos. Se debe tener cuidado, ya que muchas herramientas de software permiten que las fechas reales

que se han de aplicar para el trabajo futuro. Prácticas de control de calidad debe estar en su lugar para

identificar la entrada de fechas reales más allá de la fecha de datos completa y el porcentaje que se informó

de que los valores no son válidas en relación con las fechas.

3.3.3 Comparar y resolver cualquier desviación

Comparar el nuevo calendario actualizado con la salida de un modelo de referencia almacenado y

administrar el coste y el calendario las varianzas. Varianza los umbrales definidos en el modelo de plan de

manejo puede utilizarse para determinar qué actividades y condiciones requieren la elaboración de informes

y la adopción de medidas. Una variación de fecha comúnmente utilizado es el acabado final diferencia entre

principios y finalización de referencia, que se expresa generalmente en las unidades, tales como jornadas de

trabajo. Comparar el estado de una actividad contra más de un destino podría ser útil; por ejemplo,

calendario actual vs. :

• El plan original de la línea de referencia para ver el patinaje en comparación con el plan original.

• El último periodo de actualización para ver los cambios desde la última actualización.

3.3.4 Actualizar el programa modelo con cambios aprobados

Actualizar el programa con cualquier modelo aprobado los cambios resultantes del proceso de control de

cambios general para garantizar el programa modelo representa el 100% de los actuales de alcance del

trabajo del proyecto. La actualización y los procesos de ajuste pueden necesitar un gran número de

iteraciones para mantener un programa modelo que sigue siendo realista y alcanzable.

3.3.5 Actualizar la Línea Modelo Calendario

Actualización, el proceso de control de cambios formales, el modelo de referencia si así lo autoriza cambios

de alcance se han incorporado al calendario actualizado modelo, o si se han producido otros cambios han

incorporado que modificar de manera significativa la naturaleza de la ejecución de los proyectos. Sólo las

actividades nuevas o que están aprobados para el cambio, así como de aquellas actividades que están

directa o indirectamente vinculados a ellos, deben ser reprogramación.

3.3.6 Comunicar

Distribución de los informes (programa modelos de presentaciones (véanse las Figuras 2-1 y 2-7) de

conformidad con el calendario modelo plan de gestión y administración de las comunicaciones del proyecto

plan una vez que el calendario actual ciclo de actualización se ha completado.

3.3.7 Mantener los registros

Una adecuada gestión de los registros es parte del control de configuración. Mantener adecuadamente los

registros que detalle la lógica inicial y los principales puntos de decisión del proyecto y el proceso de

pensamiento que dieron lugar a la creación de la base lógica de flujo forrado sida en defensa de las medidas

tomadas y las lecciones aprendidas. Mantener registros que explicar todos los cambios de duración de las

actividades o la lógica como las alteraciones están siendo realizados en la lista modelo. Registro de actividad

las notas son a menudo utilizados para este fin. Estos registros proporcionan datos valiosos si se hace

necesario reconstruir lo que ocurrió y por qué.

Muchas de las buenas prácticas y los elementos descritos anteriormente se incluyen también en los detalles

de cada uno de los componentes contenidos en el modelo de lista de componentes que se presentan en el

Capítulo 4. Una completa comprensión de los distintos componentes es necesaria a fin de maximizar el

potencial de su correcta aplicación y la elaboración de una buena planificación.

3.4 Análisis del modelo Calendario

Análisis de programa utiliza herramientas y técnicas comunes durante todo el ciclo de vida del proyecto con

el fin de identificar la desviación de la línea de modelo. Análisis de programa es responsabilidad del equipo

de proyecto y el objetivo principal del análisis es la identificación temprana de las amenazas y

oportunidades para los objetivos del proyecto.

Hay varias herramientas y técnicas disponibles para realizar programación análisis del modelo. Los

procedimientos específicos y las políticas que se van a utilizar para un proyecto se describen en el proyecto

de plan de gestión. Los elementos más comunes en programación análisis están descritos en 3.4.1 a través

3.4.11 .

3.4.1 Ruta Crítica y actividades críticas

.1 Ruta Crítica

La ruta crítica es normalmente, pero no siempre, la secuencia del programa actividades que predice o define

la duración del proyecto. Generalmente, es el camino más largo a través del proyecto y, por tanto,

determina la duración del proyecto. Sin embargo, una ruta crítica puede terminar, por ejemplo, en un

programa hito que se encuentra en el medio de la lista modelo y que tiene un acabado-no-después-de

limitación de fecha. (Recuerde que las limitaciones son para usarse en forma selectiva en la lista modelos.)

Pero el riesgo(s) y presión competitiva(s) pueden alterar la ruta crítica, aumentando la importancia de las

actividades aparentemente menor y causando cambios inesperados en duración y costo. Un proyecto puede

tener varias rutas de acceso críticas.

Un proyecto que cuenta con varias rutas de acceso críticas tiene un mayor nivel de riesgo, ya que el

incumplimiento de cualquiera de estos podría resultar en el fracaso para completar todos los hitos del

proyecto.

.2 Actividades Críticas

Es importante distinguir entre actividades de ruta crítica y actividades críticas. Actividades de ruta crítica son

las actividades que figuran en la ruta crítica(s). Las actividades críticas son aquellas actividades vitales para

el éxito del proyecto, incluso si no están en la ruta crítica CPM predijo o cadena crítica. Las actividades

críticas son normalmente altos riesgos en términos de alcance, el calendario, y los costes y puede causar no

sólo un retraso en la fecha final del proyecto, pero un aumento de la probabilidad de fracaso de los

proyectos. Todas las actividades de la ruta crítica se consideran también las actividades de importancia

crítica. La ruta crítica cálculos considerar las actividades y limitaciones para determinar la ruta más larga en

el proyecto. Las actividades críticas pueden estar fuera de la ruta crítica.

3.4.2 Margen Total y libre flotación

Flotación libre representa la cantidad de tiempo que el CPM actividad fecha de finalización anticipada puede

ser aplazado sin afectar a las actividades de cualquier sucesor CPM fecha de inicio precoz. Total float

representa la cantidad de tiempo que una actividad CPM fecha de inicio anticipado o el CPM fecha de

finalización anticipada se puede retrasar sin afectar a la CPM fecha de finalización con retraso del proyecto

en su totalidad o a violar un programa modelo fecha de restricción. Revisión de cada margen total de

actividad y free float para determinar si han cambiado desde la última actualización. Cambios en total

flotación indican una amenaza de la terminación de los proyectos o metas específicas; flotación libre indica

que la falta de progresos los impactos inmediatos sucesores. Margen Total y libre flotación puede verse

reducido por las dependencias externas y otros obstáculos las fechas que aparecen en la lista modelo. Estas

dependencias externas deben ser explicadas en actividad o nodos externos vinculados a hitos.

Supervisión y administración de estos dos componentes vitales son fundamentales para completar el

proyecto a tiempo y cubriendo hitos según lo previsto. Disminuye a flote total y libre flotación indican que

los planes de recuperación deben ser desarrollados.

3.4.3 Nivel de esfuerzo las actividades (LOE).

Nivel de esfuerzo (LOE) las actividades que van a dar apoyo a otras actividades de trabajo o de todo el

esfuerzo del proyecto. Algunos ejemplos de este tipo de actividad puede ser gestión del proyecto, el

presupuesto del proyecto contabilidad, relación con el cliente, o maquinaria de rotación durante el

almacenamiento (mantenimiento preventivo), etc.

Desde la LOE actividad no es en sí misma un elemento de trabajo directamente relacionados con el

cumplimiento de los productos finales del proyecto, el servicio, o de un resultado, sino una que sea

compatible con este tipo de trabajo, su duración se basa en la duración de las actividades de trabajo

independiente que está apoyando. Por ejemplo, cuando las fuerzas de seguridad de la entrada de personal

al sitio de trabajo, que se iniciará cuando la obra comienza y termina cuando se termine el proyecto. Como

resultado de ello, la LOE actividad nunca debe estar en la ruta crítica de la lista modelo, ya que no aumenta

el tiempo necesario para el proyecto. Más bien, la maquinaria instalación sería en la ruta crítica, y el

mantenimiento preventivo actividad se convertiría en un plazo más corto o más largo sólo si la máquina de

tiempo en almacenamiento. Al insertar LOE actividades en un método de la ruta crítica, la LOE es

generalmente como un principio a principio (SS) y fin a fin (FF) sucesor de la conducción. En una lógica de

red diagrama, estas dos relaciones hacer que parezca que la LOE está colgando desde el inicio hasta el fin de

la actividad específica. Como resultado de ello, la LOE diagramado de esta manera se conoce a veces como

una hamaca. Una hamaca es una actividad puente, uso de SS y FF relaciones con las actividades de apoyo, o

en el caso de LOE, las actividades que apoya. LOE actividad actividades hamaca, a diferencia, puede tener

cualquier tipo de relación, como hamacas no se limitan a SS y FF relaciones. Pueden tener muchos tipos de

relaciones asociadas con ellos. Nivelación de recursos no pueden llevarse a cabo y las dificultades no pueden

ser aplicadas en Loes; utilizan sus calendarios asignados para resumir sus fechas.

3.4.4 Distribución probabilística de duración de las Actividades

Si duración de las actividades implican una gran incertidumbre, comúnmente es la técnica de estimación de

tres puntos estimados. Estos tres puntos se corresponden con duración de la actividad definida como

optimista, lo más probable es que las duraciones y pesimista. Además, el registro de riesgos también puede

utilizarse para estimar la incertidumbre apoyo en duración de las actividades. Con el fin de cuantificar la

incertidumbre acerca de la duración total del proyecto, a partir de las tres estimaciones de valor de cada

actividad, PERT (que utiliza una aproximación de distribución beta, y la ecuación de la Sección 2.2.3 ) se

puede utilizar. La actividad duración optimista y pesimista actividad duración representan la probable

duración, pero no todo el dominio de los valores. Los tres puntos de las estimaciones de duración debe ser

hecha por los encargados de ejecutar las actividades o alguien con experiencia realizando actividades

similares. El enfoque más común para la creación de la distribución probabilística es estimar el valor más

probable de la mejor manera posible y, a continuación, para sesgar la distribución hacia valores máximos ni

mínimos. El grado en que la distribución está sesgada es sugerido por la forma de una curva estimada

ajustando los tres períodos (tales como beta, uniforme, o triangular). La distribución de los tres cálculos de

duración (o las estimaciones de los gastos) se debe seleccionar a los mejores primeros los datos de apoyo

para actividades similares.

3.4.5 Programar Riesgo

Programar análisis de riesgo se utiliza para establecer y validar las contingencias programa, determinar las

prioridades, el riesgo de eventos, y vigilar constantemente los cambios en el proyecto de riesgos

relacionados. PERT no reconoce que las rutas paralelas de flotación puede contribuir al riesgo especialmente

en puntos de fusión también conocido como "combinar sesgo" o "ruta convergencia." es demasiado

complejo para realizar un análisis en profundidad de esta tendencia sin hacer una simulación, como la

simulación de Monte Carlo que determinar la magnitud del sesgo. El más grande y más complejo un

proyecto, mayor será el impacto acumulativo de riesgo en el proyecto. Las circunstancias dictan la

frecuencia, con el rigor y el uso del programa análisis de riesgo se documenta en el plan de gestión del

proyecto u otros documentos contractuales. Para obtener más información sobre el riesgo conceptos ver la

Práctica estándar para Proyecto Gestión del Riesgo.

3.4.6 Las Limitaciones Fecha

Fecha restringir las limitaciones naturales de un proyecto fl ujo, no tenga en cuenta los efectos de los

riesgos, así como limitar la utilidad de programar análisis de riesgo. Fecha limitaciones debería ser evitado

siempre que sea posible y sólo se utilizará cuando sea compatible con un proyecto de desarrollo. Por

ejemplo, uno de los usos de una limitación de fecha podría ser el establecimiento de un no-antes-de o no

posterior a la fecha de las actividades para las que no existe un predecesor o sucesor en el programa. Un

ejemplo ilustrativo puede ser entrega de una pieza de equipo por un proveedor que no es práctico ni

conveniente incluir las actividades del proveedor en la lista modelo. Incluso en este ejemplo, se debe tener

cuidado para no inyectar una ruptura en la ruta crítica. Las limitaciones pueden ser flexibles (p. ej., tan

pronto como sea posible), moderadamente flexible (p. ej., finalizar no antes de) o inflexible (p. ej., debe

comenzar). Las limitaciones moderadamente flexible suave a veces se los denomina "las limitaciones y

restricciones inflexibles son a veces llamadas las severas restricciones. Desde limitaciones flexibilidad de

horarios, que se debe usar sólo cuando no puede programar lógica correcta de la situación. Una limitación

de fecha cuando se hace necesario y flexible se prefieren a las limitaciones limitaciones inflexibles.

3.4.7 Actividades composición abierta

Una actividad no es una actividad o un predecesor o sucesor o ambos. Las actividades de composición

abierta puede oscurecer las relaciones lógicas entre las actividades del proyecto, crear una falsa apariencia

de flotar en un proyecto, y reducir los efectos evidentes de riesgo durante un análisis de programa. La única

abierta actividades en un proyecto debe ser el principio y al final los hitos al principio y al final del proyecto.

A menos que se los vincule con otros proyectos, un proyecto de inicio y final los hitos siempre contendrá

extremos abiertos.

3.4.8 Fuera de secuencia lógica (OOS)

OOS lógica surge cuando un proyecto está ya en marcha. Una actividad puede ser reportado como iniciado

antes de su predecesor se ha notificado como terminada, causando OOS lógica. Por ejemplo, si una actividad

tiene un acabado a inicio (FS) relación con la actividad B, pero la actividad B se ha actualizado con una fecha

de inicio real de una actividad se ha actualizado con una fecha de finalización real, el resultado es de lógica.

OOS lógica debería ser corregida (p. ej., por descomposición adicional de la actividad A) o se quita con el fin

de preservar la integridad del análisis de riesgo. Análisis de programa identificará correctamente cómo

resolver mejor OOS problemas de lógica; sin embargo, no dependen exclusivamente de la herramienta de

programación para corregir el problema, porque sólo el equipo puede determinar mejor los OOS lógica

resolución. En algunos casos, puede ser que la relación definida creada durante la etapa de planificación no

es la correcta, por lo que debe corregirse para este proyecto y para futuras referencias.

3.4.9 Cables y Lag

Riesgo puede consumir o ampliar fijo lag con consecuencias imprevistas de duración total del proyecto.

Cables y los gal pueden introducir programa riesgo y deben ser modelados como actividades independientes

con sus propios duración incertidumbre siempre que sea posible. Lleva también pueden presentar riesgo de

coste especialmente en JIT (just-in-time) gestión de inventario; esto, a su vez, puede tener un efecto cascada

sobre el programa modelo si el proyecto está siendo gestionado con un inventario limitado espacio.

Expresar cables/lag como actividades independientes si se requiere software de simulación Monte Carlo no

permite la asignación de duración incertidumbre a un adelanto/retraso. Por otra parte, en la que se fomenta

un adelanto/retraso a una plena actividad permite que se le asignara con atributos adicionales, como un

nombre, tiempo restante, etc. La falta de visibilidad de la adelanto/retraso y la distorsión de la ruta crítica de

cálculo contribuir a riesgo.

No hay riesgos específicos asociados con los clientes potenciales y los rezagos de las actividades en las que

distintos calendarios (actividad o recurso) están en uso. Por lo tanto, es importante tener una comprensión

clara de las consecuencias que lleva y lag puede tener en un programa modelo. Muchas herramientas de

software puede permitir que conduce y los rezagos que se define como una duración fija o un porcentaje de

la duración de la actividad; el juicio es necesario para utilizar el método correcto mejor la naturaleza de la

actividad y el adelanto o retraso.

3.4.10 De principio a fin Relación

De principio a fin (SF), las relaciones son rara vez utilizados deliberadamente planificación determinista

porque se refieren al hecho insólito de una tarea sucesora lógica ocurre antes de su predecesor. Revisar

cualquier SF relación para asegurar que no es el resultado de la programación los errores y modificarlos si es

necesario. El siguiente ejemplo ilustrativo de una SF relación proporciona una mejor comprensión de esta

rara relación:

Ejemplo: Suponga que el proyecto requiere la entrega de una pieza de equipo para apoyar las actividades de

construcción. Es posible que no resulte práctico para proporcionar lógica para el equipo fabricación y

ejecución de las actividades, sin embargo, el equipo desea las actividades de construcción de las fechas de la

entrega. Ya que el predecesor siempre mueve el sucesor, el SF relación proporciona la solución. A

continuación, el equipo fabricación puede concluir en el inicio de la actividad que requiere el equipo que

vaya a instalarse.

3.4.11 Enlaces a/Resumen de Actividades

En general no se recomienda para uso de enlaces en resumen las actividades porque la lógica puede ser

difícil de seguir y la práctica no puede ser admitida por todas herramientas de programación. Utilización de

los enlaces de las actividades puede producir errores de lógica circular y crear dentro de la programación.

3.5 Comunicación y de la información

Comunicaciones claras construir credibilidad con las partes interesadas. El director del proyecto junto con el

equipo de proyecto debe crear un plan de gestión de la comunicación (ver guía PMBOK ® -Cuarta Edición) al

principio del ciclo de vida del proyecto para cumplir con las expectativas de los actores clave.

El programa es un modelo estratégico y elemento importante en un director de proyecto de herramientas

para guiar un proyecto con éxito a su fecha de finalización del objetivo. Un programa modelo es una línea de

tiempo o calendario que enumera las actividades previstas con las fechas de inicio y finalización. Un

programa modelo también se pueden disponer en capas con detalles diferentes para permitir que los

administradores de proyectos a dirigir y administrar los recursos de forma más fluida, controlar el día a día

proyecto evolución, comunicarse con mayor frecuencia y eficacia con las partes interesadas, y determinar y

controlar las dependencias entre tareas y limitaciones a fin de minimizar el impacto en el proyecto para

evitar retrasos.

El modelo de instancia puede producir múltiples formatos de informe en función de la finalidad del

programa modelo, la etapa de desarrollo del proyecto, y el usuario principal de la lista modelo.

Los clientes pueden requerir varios niveles de programación modelo ejemplo presentaciones. Para obtener

más información, consulte el componente "programa nivel de modelo" en el Capítulo 4.

Tabla 3-1. Los niveles de Esquema modelo Ejemplo presentaciones