Post on 04-Jan-2016
description
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