Los cinco secretos de la programacin del proyecto

Este documento est dirigido a programadores de proyectos, directores de proyectos,

miembros de una oficina de gestin de proyectos (PMO) y aquellos interesados en aprender
ms acerca de los factores que contribuyen a una buena programacin de proyectos. Asume
un conocimiento bsico de las actividades involucradas y las trampas comunes de la
programacin del proyecto.

Mientras que los programadores de proyectos suelen desempear ms de una funcin en

un proyecto, como el jefe de proyecto, el jefe de equipo, etc., este documento se refiere al
programador del proyecto como un rol discreto. La informacin presentada en este
documento se aplica a proyectos con un planificador de proyectos dedicado, as como a
proyectos en los que el planificador tiene responsabilidades adicionales del proyecto.

Este documento no discute herramientas especficas ni profundiza con respecto a la

metodologa de gestin de proyectos como la que se discute en la Gua para el Manejo de
Proyectos (Gua PMBOK) del Project Management Institute - Cuarta edicin (Project
Management Institute [PMI] , 2008). Se pretende proporcionar una Una visin general del
proceso de programacin y ofrece sugerencias especficas para mejorar los calendarios de
los proyectos y el proceso De programacin del proyecto.

Este documento define cinco factores (o "secretos") que, cuando se implementan

consistentemente juntos, dan lugar a programas de proyectos que son ms probables de ser
utilizados y mantenidos a lo largo de la vida de un proyecto. Un cronograma de proyecto que
se sigue y se mantiene a lo largo de un proyecto puede proporcionar una identificacin
temprana del posible desvo del cronograma, los riesgos del proyecto y otros problemas. La
identificacin temprana de problemas, riesgos y problemas aumenta significativamente la
probabilidad de completar un proyecto a tiempo y dentro del presupuesto y el alcance, que a
menudo se define como el xito del proyecto.

Para aquellos que actualmente forman parte de un PMO o que estn considerando la
posibilidad de establecer un PMO, este documento brinda informacin sobre el papel del
PMO en la programacin del proyecto y sugiere maneras especficas que el PMO puede
implementar y apoyar el uso de los "cinco secretos". En la definicin y apoyo del proceso de
programacin facilita y acelera el aprendizaje organizacional, que, cuando se hace
correctamente, beneficia a todos en la organizacin.
Resumen ejecutivo

El propsito de un cronograma de proyecto es proporcionar una hoja de ruta a travs del

proyecto y proporcionar postes de seal (o hitos) para que sepamos dnde estamos en
cualquier momento.

La mayora de nosotros hemos trabajado en proyectos donde el cronograma del proyecto se

crea durante la fase de planificacin y luego se abandona en gran medida una vez que el
proyecto pasa a la fase de ejecucin. A menudo, estos calendarios de proyectos se centran
en el individuo y los grupos de tareas y actividades necesarias para completar el proyecto.
Tienden a ser pensados y creados como una lista de tareas con cronogramas, recursos y
costos asociados para ser usados y rastreados durante la ejecucin de un proyecto. Este
enfoque en las actividades durante la creacin del programa pasa por alto el hecho de que
los proyectos no existen slo para realizar actividades, existen para producir productos
especficos.

Para proyectos pequeos, puede ser suficiente y apropiado crear estos programas basados
en actividades, pero para la mayora de nosotros que trabajamos en proyectos ms grandes
y complejos, una lista de verificacin simple es insuficiente. En un proyecto de mayor
envergadura, el desarrollo de un calendario centrndose principalmente en las tareas y
actividades que se realizan a menudo dificulta identificar los hitos clave y saber si estamos
en camino. El uso de tal programacin puede dificultar la anticipacin de problemas, y esto a
menudo resulta en la ocurrencia de eventos inesperados y no planificados, lo que
eventualmente puede conducir al fracaso del proyecto.

Creando horarios que pueden actuar como mapas de carreteras que guan al equipo y
pueden advertir a los gerentes de proyecto antes de que se desven de la pista requiere un
enfoque en entregables y un nivel de detalle consistente. El mantenimiento de tal programa
requiere un proceso claramente definido y un enfoque disciplinado para mantenerlo
actualizado.

Este documento est dirigido a directores de proyectos, planificadores de proyectos y

personal del PMO que crean y administran planificaciones de proyectos o apoyan a aquellos
que lo hacen. Describe cinco secretos de programacin de proyectos que, si se siguen,
ayudarn a iniciar el camino hacia el desarrollo y la gestin de programas de proyectos que
permiten y apoyan buenas prcticas de gestin de proyectos y contribuyen
significativamente al xito del proyecto.

Los cinco secretos de la programacin del proyecto son:

1. Cree planificaciones de proyectos basadas en los deliverables

2.Establecer y mantener el nivel de detalle apropiado

3.Implementar un proceso de actualizacin y notificacin de estado

4.Revise y ajuste regularmente el horario

5.Cree y siga los estndares de programacin del proyecto

Como puede ver, estos secretos no son nuevos conceptos. Se presentan aqu juntos para
proporcionar un contexto y una metodologa para crear buenos calendarios de proyectos.
Las siguientes secciones de este documento estn diseadas para ayudar a los
planificadores de proyectos, gerentes de proyectos y personal de PMO a pensar de manera
diferente sobre los horarios que crean o apoyan y sugieren algunas prcticas recomendadas
para incorporar estos cinco secretos en los procesos seguidos dentro de sus
organizaciones.

El primer paso para construir un buen calendario de proyecto es establecer lo que define un
buen calendario. Una definicin simple, y la que se utiliza a lo largo de este documento, es
un calendario que modela con precisin el trabajo del proyecto y que mantiene un nivel de
detalle consistente y apropiado. Los horarios que cumplen estos criterios son ms
propensos a proporcionar informacin precisa sobre el estado del proyecto, problemas y
riesgos y son mucho ms fciles de mantener que los horarios que no cumplen con estos
criterios.

Los proyectos ms pequeos y de menor duracin requieren un calendario de proyectos

mucho ms simple y ms pequeo que proyectos ms largos y ms complejos. Si bien esto
es muy obvio para cualquiera que haya creado incluso unos pocos cronogramas de
proyectos, no proporciona suficiente informacin para decirnos nada acerca de lo que un
programa de proyecto simple o complejo debe contener ni qu nivel de detalle es el ms
apropiado. El resto de este documento proporciona la informacin adicional necesaria para
ayudarle a comprender los diversos factores o "secretos" que contribuyen a un buen
proyecto Cmo aplicar estos secretos a sus horarios y cmo construir una organizacin que
establezca, promueva y apoye buenas prcticas de programacin a largo plazo

Secreto # 1:

Crear planes de proyecto basados en los resultados

Como planificadores de proyectos y gestores de proyectos, estamos muy conscientes de

que los entregables son productos tangibles producidos por un proyecto. Todos los
proyectos tienen entregables-por ejemplo, documentacin, hardware fsico instalado y
operativo, aplicaciones correctamente configuradas y accesibles por los usuarios, etc.
Durante la ejecucin del proyecto, el equipo del proyecto realiza muchas actividades para
producir las entregas del proyecto. Las actividades consisten en una o ms tareas, como la
recopilacin de requisitos del sistema, la instalacin de hardware, la instalacin y
configuracin de software, la comprobacin del acceso y la funcionalidad del sistema, etc.

Los horarios de los proyectos pueden dividirse en dos tipos, basados en las actividades y los
entregables. En mi experiencia, la mayora de los horarios de los proyectos estn basados
en actividades, lo que significa que se desarrollan a partir de la mentalidad de "qu
actividades y tareas deben completarse durante el curso de este proyecto". Si bien es
importante considerar cuidadosamente esta cuestin, No debe ser la fuerza impulsora
detrs de la estructura y organizacin de un calendario. En su lugar, se debe construir y
organizar un buen calendario del proyecto en torno a los productos que el proyecto pretende
producir.

Hay dos pasos para crear un calendario de proyecto basado en los deliverables:

Identificar todas las entregas y sus "propietarios" 1.

Construir una estructura de desglose de trabajo basada en los resultados (WBS)

Identificar entregables y "Proveedores"

La mayora de nosotros comprendemos la importancia de identificar y documentar todas las

entregas que sern producidas por nuestros proyectos antes de comenzar el trabajo en el
proyecto. No es diferente cuando se crea un programa de proyecto. Antes de que se pueda
redactar un calendario, el alcance y las entregas necesarias para completar ese alcance
deben estar claramente identificados y documentados. As que el primer paso para crear un
buen calendario de proyecto es sentarse y documentar todos los entregables que se
producirn en el proyecto. Esto debe ser hecho por el gerente del proyecto ya que l o ella
tiene la responsabilidad final de producir los entregables.

Un paso que a veces se pasa por alto al crear la lista de entregables es identificar un
propietario principal para cada entregable en el momento en que se identifican los
productos. Si el proyecto an no cuenta con personal completo, puede utilizarse una
posicin o ttulo, como "Jefe de equipo de infraestructura", en lugar del nombre de un
individuo. Hacer esto temprano en el ciclo de vida del proyecto puede evitar desacuerdos
sobre quin es responsable de crear o administrar la creacin de un producto concreto.

Hay muchas maneras de identificar las entregas y sus propietarios. Mi preferencia es que el
programador del proyecto facilite una sesin con el gerente del proyecto, los lderes del
equipo apropiado y las partes interesadas clave para definir y documentar los entregables
que se van a producir, los insumos necesarios para cada entregable y la forma que cada
producto entregar. Incluir a las partes interesadas claves en este proceso ayuda a ganar el
buy-in para lo que ser producido por la persona u organizacin que va a recibir el producto.

Durante esta sesin, el papel del programador del proyecto es facilitar una discusin en la
que los productos concretos, sus entradas y salidas sean documentados y mapeados
identificando claramente aquellos productos (es decir, entregables) que son aportaciones a
otros entregables. El proceso se completa cuando todo el mundo est de acuerdo en que
todos los entregables estn documentados y los datos de entrada y salida de cada uno de
los entregables son aceptables.

Un mtodo para capturar esta informacin es crear un diagrama de red. Esto se puede
hacer colgando un pedazo grande de papel en una pared y tener los cables escribir cada
uno de sus entregables en notas separadas "pegajosas" y colgar las notas en el papel. El
equipo debe entonces mover las notas alrededor y dibujar lneas / flechas para significar las
dependencias entre

Las entregas.

La siguiente figura muestra una forma en que se puede captar y documentar la informacin
de entrega y dependencia.

Como se puede ver en la figura anterior, cada entregable se lista con un solo propietario
principal. Es importante sealar que aunque muchos equipos o individuos pueden estar
involucrados en la terminacin de la entrega, es fundamental que se asignen una sola parte
responsable que conduzca y rastree los insumos requeridos, el estado del trabajo, Que el
entregable adopte el formato acordado y se complete dentro del calendario y presupuesto
previstos

Para proyectos ms pequeos, el director del proyecto puede desempear este papel para
todos los productos; Sin embargo, en proyectos grandes el Proyecto El gerente debe
delegar esta funcin para asegurar que haya un nico punto focal para cada producto a
producir.
Construir una WBS basada en los productos

Ahora que tiene una lista de entregables y propietarios y sabe cmo estos productos
interrelacionados, es hora de definir cmo se representarn en el calendario del proyecto.

La estructura de un programa de proyecto es anloga a un esquema para un libro o papel.

As como un esquema documenta los principales temas y su estructura organizativa, la EDT
de un proyecto debe definir las principales reas de enfoque y sus entregables asociados. El
ejercicio anterior produce la informacin necesaria para redactar una PEP inicial. La WBS
debe organizarse de tal manera que se asegure que cada entrega se incluya al mismo nivel
en la WBS. En algunos casos, cada producto debe ser listado en el Nivel 1 de WBS, en
otros casos puede tener ms sentido organizar la EDP por equipo o rea de proyecto en el
Nivel 1 de la EDT y luego enumerar todos los entregables pertenecientes a cada equipo / O
el nivel que sea apropiado para el proyecto

En nuestro ejemplo, la informacin del diagrama de red representada arriba fue organizada
por rea del proyecto. Se agrupan todas las entregas relacionadas con la creacin y el
soporte de la infraestructura subyacente, se agrupan los entregables relacionados con las
aplicaciones, etc. A medida que se ampla la WBS, las tareas de detalle se insertan debajo
de su entrega asociada.

La Figura 2 muestra un ejemplo de una WBS simple basada en los resultados que se cre a
partir de la informacin previamente recopilada.

Independientemente del nivel de prestaciones de WBS, es fundamental que todas las

entregas aparezcan en el mismo nivel de WBS y que todas las tareas de detalle y
actividades enumeradas a continuacin de cada entregable se relacionen directamente con
la finalizacin de ese entregable.
Si no lo hace, ser difcil supervisar el progreso de todos los Resultados negativos y afectar
negativamente a las capacidades de generacin de informes.

Tomando la EDT que acabamos de crear, el paso final en la construccin de la base o el

marco de nuestro programa es introducir la informacin en una herramienta de
programacin. La Figura 3 muestra el marco de programacin simple que result de la EDT
y el diagrama de red que creamos en los pasos anteriores.

Al revisar la figura, tome nota de lo siguiente:

Todos los entregables estn en el mismo nivel de WBS (Nivel 2 en este caso).

Cada entrega tiene asignado un solo propietario

La finalizacin de todas las entregas relacionadas con un rea de proyecto (por ejemplo,
infraestructura, aplicaciones) est marcada por un hito. Estos hitos aparecen en el mismo
nivel de WBS que los entregables.

Las dependencias del diagrama de red se incluyen como vnculos entre tareas (es decir,
predecesores / sucesores).

A medida que el director del proyecto o el jefe del equipo agregan tareas detalladas debajo
de cada entregable, tambin deben agregar un hito que marque la finalizacin del
deliverable y asegurarse de que est vinculado a las tareas de detalle apropiadas. Esto se
muestra en la Figura 3 en la primera entrega en cada rea del proyecto: Instalar Hardware
(WBS 1.1), Instalar Aplicaciones (WBS 2.1) y Documentar Cambios de Proceso de Negocio
(WBS 3.1)

Secreto # 2:

Determinar el nivel de detalle apropiado

Determinar el nivel de detalle apropiado para cada

Cronograma del proyecto

Los mejores horarios de proyectos son los que contienen toda la informacin requerida y
nada ms. Dado que cada proyecto es nico, no hay un solo nivel de detalle que sea
apropiado para todos los proyectos o calendarios de proyectos. Por lo tanto, el nivel de
detalle requerido para un proyecto en particular debe definirse antes del inicio de la
programacin.

El nivel de detalle requerido debe ser definido como un rango de duraciones de tareas
aceptables y / o esfuerzo de trabajo. Adems, tambin se debe definir el tipo de tareas
aceptables. Por ejemplo, se incluirn actividades administrativas tales como reuniones del
equipo del proyecto, seguimiento del tiempo, nivelacin de recursos, administracin de
personas, etc.? Si es as, sern rastreados para cada entregable o sern llamados en su
propio rea de proyecto? Si no es as, se explicar esta vez reduciendo la disponibilidad de
recursos o se utilizar un proyecto administrativo?

Una regla para definir un nivel estndar de detalle para un programa que puede ser til es la
"Regla 1% -10%" desarrollada por Eric Uyttewaal, PMP, en su libro Dynamic Scheduling with
Microsoft Office Project. La "Regla del 1% -10%" establece que la La duracin de cualquier
tarea de detalle debe estar entre 1% y 10% de la duracin total del proyecto. Por ejemplo, si
se espera que la duracin del proyecto sea de 100 das, todas las tareas de detalle deben
tener una duracin de entre 1 y 10 das. Esta regla tambin puede aplicarse a las
estimaciones de trabajo, aunque puede ser difcil determinar el trabajo total estimado hasta
que el calendario est completamente desarrollado. Por lo tanto, recomiendo usar la
duracin como factor impulsor al usar esta regla.

Otra forma de definir el nivel de detalle es poner un lmite superior e inferior en el nmero de
horas de trabajo que una tarea puede tener, es decir, definir un tamao de paquete de
trabajo aceptable. El tamao del paquete de trabajo debe ser lo suficientemente grande
como para ser medible mientras se mantiene lo suficientemente pequeo como para
manejar. Si el paquete de trabajo es demasiado pequeo, el programa puede llegar a ser
innecesariamente grande y desordenado, por lo que es difcil de gestionar. Si el paquete de
trabajo es demasiado grande, puede ser difcil realizar un seguimiento preciso del progreso
de las tareas, lo que hace ms difcil identificar los riesgos o problemas desde el principio.

Una buena regla para definir el tamao del paquete de trabajo es mantener la duracin de la
tarea y / o el esfuerzo de trabajo dentro de uno o dos ciclos de informes. Si su proyecto
produce informes de estado semanalmente, el paquete de trabajo debe tener entre una y
dos semanas de duracin y / o de 40 a 80 horas de esfuerzo.

Independientemente de la (s) regla (s) seleccionada (s) para definir el nivel de detalle
apropiado para un programa de proyecto, la clave est en consistentemente Siguiendo la
regla seleccionada. Los calendarios de proyectos que tienen diferentes niveles de detalle
tienden a ser ms difciles de establecer e informar porque la informacin clave puede
pasarse fcilmente por alto cuando est enterrada demasiado profundamente en la EDT y /
o no refleja una medida resultado. Adems, las programaciones de proyectos que no siguen
reglas consistentes para definir el nivel apropiado de detalle pueden llegar a ser
innecesariamente largas, asumiendo el rol de una lista de verificacin en lugar de una
programacin. Esto los pone en alto riesgo de ser abandonados durante la ejecucin del
proyecto.

Mnimos. Esto es particularmente cierto cuando el programador del proyecto juega ms de

una funcin en el proyecto, como el jefe de proyecto o el jefe del equipo.

Para asegurarse de que el calendario construido sea realista y mantenible, el planificador

debe asumir la responsabilidad de evaluar todas las tareas que se envan o crean por ellos
antes de incorporarlos en el calendario del proyecto. Mientras que muchos de nosotros
vemos esto como un trabajo extra que consume un tiempo valioso que podramos usar para
obtener el trabajo "real", es de hecho una de las actividades ms importantes en el
desarrollo del cronograma del proyecto.

El tiempo dedicado a evaluar, editar y / o combinar las tareas detalladas en un calendario del
proyecto no slo reducir el tiempo necesario para gestionar el programa, sino que tambin
puede ser la clave para identificar pronsticos de posibles desvos, problemas y / o riesgos
de horarios. Es suficiente tiempo para evitarlos o mitigarlos.

Para determinar si una tarea debe incluirse en una planificacin de proyecto, el planificador
debe hacer las siguientes preguntas:

1. Esta tarea contribuye directamente a la realizacin de uno o ms productos concretos?

2. La tarea tiene un nivel de detalle apropiado?

3. Esta tarea tiene al menos un recurso nombrado o genrico asignado?

5. Tiene esta tarea al menos un predecesor y / o un sucesor?

Solamente cuando la respuesta a todas estas preguntas es s, debe la tarea ser agregada al
horario del proyecto. Si el planificador no conoce la respuesta a una de estas preguntas o si
falta informacin, el planificador debe asumir la responsabilidad de hacer el seguimiento con
el propietario de la entrega a la que esta tarea est relacionada para obtener la informacin
que falta.

Una vez que toda la informacin ingresada en el plan, los recursos deben ser nivelados para
asegurar que la lnea de tiempo es realista y que los recursos estarn disponibles cuando
sea necesario.

La construccin de un calendario de proyecto de esta manera ayudar a asegurar que el

resultado ser un programa que produce:

Una trayectoria crtica completa e ininterrumpida

Tareas detalladas que son relevantes para productos concretos

Una lnea de tiempo realista

Un horario que es ms fcil de mantener

Informes de estado consistentes y relevantes

Secreto # 3:

Implementar una actualizacin de estado de la programacin regular y

Proceso de presentacin de informes

Como todos sabemos, la construccin de un buen calendario de proyectos no es suficiente

para asegurar el xito del proyecto. El programa debe ser actualizado, mantenido y ajustado
en funcin de los eventos durante la fase de ejecucin del proyecto. Con el fin de mantener
un calendario de proyectos realista y til, debe actualizarse peridicamente y ajustarse
segn lo justifique el evento.

El planificador del proyecto es responsable de determinar qu informacin recopilar, la

frecuencia con la que se recopilar la informacin y el mtodo para recopilar y validar la
informacin. Los mtodos utilizados dependern de los requisitos de presentacin de
informes, la frecuencia de los informes, la disponibilidad de herramientas automatizadas y
manuales y la ubicacin geogrfica de los miembros del equipo encargados de proporcionar
los datos.

Como mnimo, los planificadores deben recopilar el trabajo y / o la duracin real y restante,
el inicio real y las fechas de finalizacin reales. Sin esta informacin, el programa no se
puede mantener correctamente. A menudo es tentador recolectar el porcentaje de datos
completos para cada tarea en lugar del trabajo real y el tiempo restante; Sin embargo, el
porcentaje de informacin completa es subjetivo y no proporciona ninguna informacin
acerca de cundo se terminar la tarea ni si se requiere esfuerzo adicional y / o recursos
para completar la tarea a tiempo.

El primer paso en el desarrollo de un proceso regular de actualizacin y reporte es trabajar

con el gerente del proyecto y los principales interesados para determinar los requisitos y
expectativas de los informes. La siguiente es una lista de requisitos de informes mnimos
que se aplica a la mayora de los proyectos:

Descripcin general del ejecutivo

-Vista general del estado del proyecto a un nivel alto. Este informe frecuentemente muestra
el estado actual de los hitos clave y entregables en comparacin con el cronograma de lnea
de base.

Informes de variacin (Duracin, Inicio, Finalizacin y / o Variacin de Trabajo)

-Tareas especficas, actividades y / o prestaciones que se estn ejecutando detrs (o por
adelantado) de la programacin, estn tomando mucho ms tiempo (o ms corto) de lo
esperado y / o estn requiriendo Significativamente ms (o menos) trabajo de lo previsto. El
nivel de detalle de este informe es normalmente dictado por el pblico que lo recibe.

Un listado de los entregables y las tareas asociadas, ya sea activo o activo en una
ventana especfica de "anticipacin" (nmero de das, semanas, meses, etc.)

Utilizacin de recursos -La cantidad de horas que cada recurso est programado para
funcionar durante el siguiente perodo (por ejemplo, semana, mes, trimestre) Esto se utiliza
a menudo junto con el informe de "anticipacin" para asegurar que los recursos estn
disponibles para completar el trabajo Asignado en un perodo de tiempo dado mientras que
mantiene una carga de trabajo realista.

Cuestiones / Riesgos del Programa -Un listado / descripcin y estado de los asuntos o
riesgos actuales o anticipados relacionados con el cronograma del proyecto. Este informe
debe incluir las tareas asociadas con cada riesgo o problema.

Otros requeridos o considerados apropiados para el proyecto.

El programador del proyecto necesita un conocimiento completo de los requisitos de

generacin de informes antes de definir la informacin de estado a recopilar y las fuentes de
esta informacin. Adems, es importante comprender los distintos destinatarios de la
informacin para definir el nivel de detalle apropiado para cada uno de los informes. Algunos
informes pueden tener versiones de administracin con informacin de alto nivel y versiones
de equipo que contienen informacin ms detallada

A medida que cada informe es generado y distribuido, el programador del proyecto y / o el

gerente del proyecto deben analizar los informes e identificar posibles reas problemticas.
Para cada problema, el planificador del proyecto debe revisar el rea o reas afectadas de
la planificacin e identificar posibles resoluciones o estrategias de mitigacin. Esta
informacin debe documentarse cuidadosamente y proporcionarse al director del proyecto
y / oa los interesados apropiados. Dado que no todos los planificadores de proyectos tienen
el mismo grado de experiencia o experiencia en el anlisis de programacin, el director del
proyecto debe trabajar con el planificador del proyecto para identificar y documentar las
expectativas de informes y anlisis y determinar si la responsabilidad del anlisis del
programa debe corresponder al planificador, Un analista de horario o una combinacin de
los dos.
Secreto # 4:

Revisar y ajustar regularmente el horario

No se puede exagerar la importancia de establecer y seguir un proceso consistente de

actualizacin, presentacin de informes y anlisis a lo largo de la vida de un proyecto. Sin
embargo, es igualmente importante reconocer que incluso los proyectos mejor planificados
experimentan eventos inesperados o no planificados que podran tener un impacto
significativo en el programa. Por lo tanto, para asegurar que el calendario siga siendo
pertinente y preciso durante todo el proyecto, es fundamental disponer de un proceso para
Controlando los cambios en el horario como los eventos lo justifiquen.

Para proyectos ms grandes, se debe implementar un proceso formal de control del cambio
de horario para mantener un estricto control sobre el cronograma del proyecto. Para
proyectos ms pequeos, este proceso de control de cambios podra ser ms informal.
Todos los procesos de control de cambio de horario deben tener lo siguiente en comn:

1. puede hacerse sin pasar por el proceso de control de cambios (por ejemplo, agregar o
modificar asignaciones de recursos, nombres de tarea)

2. Un conjunto finito de personas que estn autorizadas a aprobar cambios significativos en

el calendario del proyecto (es decir, un tablero de control de cambio de horario)

3. Todos los cambios significativos en el cronograma del proyecto deben estar bien
documentados en cuanto a la (s) razn (es) y el resultado esperado del cambio

4. Un proceso de captura de lecciones aprendidas y un repositorio

5. Un archivo de las versiones anteriores del programa del proyecto para mostrar la
evolucin del calendario y retener la informacin histrica

El proceso de control de cambios de horario debe estar estrechamente vinculado con el

proceso general de control de cambios del proyecto. Cuando los cambios del proyecto son
aprobados a travs del proceso de control de cambios del proyecto, deben activar el
proceso de control del cambio de horario para asegurar que todos los cambios en el
proyecto se reflejen pronta y exactamente en el programa.

Incluso cuando no se producen cambios importantes en el proyecto, el programa debe

revisarse peridicamente para asegurarse de que sigue siendo vlido. El intervalo entre la
revisin de la programacin y los ciclos de actualizacin debe determinarse principalmente
por la longitud del proyecto. Los proyectos con plazos ms cortos deberan revisarse y
actualizarse ms frecuentemente que los proyectos ms largos y de mayor duracin,
aunque tambin deberan tenerse en cuenta otros factores, como la criticidad del proyecto.
Los proyectos que duren ms de un ao pueden definir el ciclo de revisin del programa en
un intervalo de tiempo especfico y / o como hitos clave del proyecto. Por ejemplo, tal
proyecto puede ser revisado y actualizado trimestralmente, al final de cada fase del proyecto
y / o como hitos clave son alcanzados. Independientemente del intervalo del ciclo de
revisin, el proceso de revisin y actualizacin debe involucrar al gerente del proyecto, los
lderes del equipo y las partes interesadas clave. Como se hizo en la identificacin inicial de
los entregables, el planificador del proyecto debe facilitar una sesin de trabajo donde el
calendario de cada prestacin se revisa y actualiza segn sea necesario.

A medida que se realizan las actualizaciones del programa, el planificador del proyecto debe
identificar y anotar los cambios posteriores resultantes. Cuando un cambio en el calendario
de un producto afectado afecta negativamente al programa de otro producto, el proyecto
Gerente y los propietarios de los productos afectados deben determinar si hay una manera
de mitigar el impacto de la programacin agregando recursos, moviendo recursos de trabajo
de menor prioridad, realizando trabajo en paralelo, etc.

A medida que se reasignan los recursos y / o se modifique el calendario de uno o ms

entregables, se debe evaluar el impacto en los entregables relacionados. Este proceso se
repite para todas las entregas hasta que el calendario se estabilice (es decir, no se requieren
cambios adicionales y se han analizado y acordado los efectos de todos los cambios).

De esta manera, todo el cronograma es revisado a fondo y todas las actualizaciones son
acordadas por el gerente del proyecto, los lderes del equipo y las partes interesadas. Una
vez acordado, el cronograma actualizado debe estar alineado de manera que el progreso
pueda ser rastreado en funcin del calendario recin actualizado. La mayora de las
herramientas de programacin permiten el uso de mltiples lneas de base para que los
datos de lnea de base anteriores no se pierdan. Si bien este proceso puede requerir varias
horas o, en el caso de grandes proyectos, varios das, es clave para evitar que el horario se
vuelva obsoleto, proporcionando informacin errnea o irrelevante o sea abandonado en
conjunto.

Secreto # 5:

Cree y siga los estndares de programacin

Como podemos ver en los cuatro "secretos" anteriores, construir y mantener un buen
calendario de proyectos puede ser una actividad compleja y que consume mucho tiempo. El
uso de estndares de programacin puede reducir significativamente el tiempo requerido y
eliminar parte de la complejidad involucrada en el desarrollo de un calendario de proyectos
realista y mantenible. Adems, los estndares de programacin ayudan a garantizar la
coherencia cuando los planificadores son creados por mltiples planificadores y / o
administradores de proyectos. Esto es particularmente importante cuando un PMO es
responsable de supervisar y / o apoyar muchos proyectos simultneamente, ya que ayuda a
asegurar que la informacin reportada de los diferentes programas represente informacin
similar que pueda compararse fcilmente.

Qu es un estndar de programacin?

En 2007, PMI lanz su estndar de prctica para la programacin. Esta norma se describe
en el sitio web de PMI como "un medio cuantificable para evaluar la madurez de un modelo
de programacin y transforma la seccin de gestin del tiempo del proyecto (Captulo 6) de
la Gua PMBOK en un proceso de medicin accionable y objetivo Para la programacin de
proyectos ". El estndar de prctica para la programacin proporciona informacin completa
y especfica para los administradores de proyectos y planificadores y es un excelente
recurso.

En el contexto de este documento, sin embargo, las normas de programacin se consideran

directrices especficas para la creacin y mantenimiento de calendarios de proyectos dentro
de un nico o mltiples Organizaciones relacionadas. Estas normas pueden incluir el uso de
una WBS basada en los resultados, un tamao de paquete de trabajo estndar, ciclos y
procesos de informes especficos, un proceso de control de cambios de programacin, etc.

Los estndares de programacin son creados o adoptados por una organizacin que
entonces defiende, apoya y monitorea su uso dentro de los calendarios desarrollados para
proyectos dentro de su esfera de influencia o control. Es una buena prctica basar
estndares de programacin especficos en un documento aceptado por la industria, como
el estndar PMI y / o las mejores prcticas aceptadas por la industria.

Como se discuti anteriormente en este documento, los estndares de programacin son

importantes por varias razones:

Contribuyen al desarrollo de calendarios de proyectos realistas y manejables

Ayudan a asegurar la coherencia en la estructura y el nivel de detalle a travs de los

calendarios del proyecto

Ayudan a asegurar que la informacin reportada pueda ser ms fcilmente comparada y

apalancada

Ayudan a asegurar la coherencia en los procesos relacionados con el horario (tales como
la presentacin de informes y el control de cambios)

Por qu utilizar un estndar de programacin?

La adhesin a los estndares de programacin puede ayudar a una organizacin a
aumentar la tasa de xito de su proyecto ya ser ms eficiente de las siguientes maneras:

1. Las siguientes normas pueden reducir el tiempo necesario para crear y mantener los
cronogramas del proyecto definiendo de antemano la estructura y el nivel de detalle del
cronograma

2. Los procesos estndar ayudan a facilitar la captura y aplicacin de las lecciones

aprendidas

3. Los procesos definidos para asegurar la adhesin a las normas contribuyen en gran
medida a un entorno en el que los administradores de proyectos, programadores de
proyectos y otros interesados reciben informacin consistente y confiable que puede
utilizarse para mejorar continuamente el proceso de programacin del proyecto y la gestin
general del proyecto en toda la organizacin

4. Ayudan a asegurar el xito del proyecto facilitando la identificacin de posibles problemas

por adelantado

Si bien las normas son claramente una forma positiva de ayudar a las organizaciones a
aumentar la tasa general de xito de sus proyectos, es importante tener en cuenta que las
normas por s solas no pueden garantizar un buen calendario ni el xito del proyecto.
Adems, las normas especficas no siempre son aplicables en cada situacin. Las
organizaciones que desarrollan e implementan estndares de programacin deben tener
cuidado de crear un ambiente en el que se estimule a los planificadores de proyectos ya
otras partes interesadas a evaluar su situacin y determinar Si el cumplimiento estricto de
una norma especfica es la medida ms adecuada para una situacin dada. En el caso de
que no se cumpla una norma, el motivo de la excepcin debe estar claramente
documentado.

Esto no significa que los planificadores de proyectos deben sentir que pueden tomar
decisiones arbitrarias sobre si quieren seguir los estndares. Significa, sin embargo, que
aquellos que tienen autoridad en tal organizacin nunca deben perder de vista el hecho de
que han contratado a sus jefes de proyecto y planificadores de proyectos por sus
conocimientos y experiencia. Estos expertos deben ser alentados y recompensados por
evaluar cada situacin y tomar la mejor decisin dada la circunstancia. De esta manera, la
organizacin crear una fundacin que ofrecer la mejor oportunidad para la consistencia en
el xito del proyecto al tiempo que fomenta un ambiente de aprendizaje, crecimiento
personal y organizacional y mejora continua.

Uso de los cinco secretos de la programacin del proyecto

La informacin presentada hasta ahora es valiosa incluso cuando es utilizada por un
planificador que trabaja independientemente. Sin embargo, para realizar todo el valor de
implementar estos secretos, una organizacin debe proporcionar un repositorio central de
estndares, herramientas y plantillas disponibles para todos los planificadores. De no
hacerlo obliga a cada planificador a "reinventar la rueda" cada vez que se desarrolla una
nueva programacin. Esto es claramente ineficiente y no logra captar el valor del
conocimiento combinado y la experiencia que estn presentes en las organizaciones ms
grandes.

En la ltima dcada, el PMO se ha vuelto ms comn y ms importante en muchas

organizaciones basadas en proyectos. La mayora de los PMOs se desarrollan como el
punto focal para apoyar, monitorear y en algunos casos manejar muchos proyectos
simultneos que tienen lugar en una variedad de partes de la organizacin. Algunas
empresas tienen un solo PMO con responsabilidad para todas las actividades del proyecto,
mientras que otras empresas tienen un PMO en cada una de sus diversas unidades de
negocio o reas funcionales. En ambos casos, el PMO generalmente es responsable de
supervisar y apoyar a los gerentes de proyectos y planificadores de proyectos y, en algunos
casos, al personal del proyecto y otras partes interesadas.

Este enfoque centralizado de la gestin y supervisin de proyectos proporciona a las

organizaciones una Gestin y experiencia en la programacin de proyectos que no se
encuentra fcilmente en otros lugares. Este es el entorno perfecto para desarrollar e
implementar procesos de programacin de proyectos, estndares, herramientas y
programas de capacitacin. Tambin proporciona un punto nico para la recopilacin y
documentacin de las mejores prcticas, las lecciones aprendidas y la investigacin
continua.

Para asegurar que una organizacin aproveche al mximo la experiencia de planificacin de

proyectos dentro de su PMO, un ejecutivo debe patrocinar activamente un grupo de
planificacin de proyectos o asignar al menos un gestor de planificacin de proyectos que es
responsable de evaluar y mejorar los horarios del proyecto y las prcticas de planificacin de
proyectos en toda la organizacin. . Este gerente de programacin debe tener la autoridad
para definir / adoptar estndares de programacin y hacer cumplir su uso.

El objetivo primario del gerente de programacin y el equipo de programacin del PMO debe
ser identificar e implementar estndares, herramientas, plantillas y programas de
capacitacin que estn disponibles para todos los gerentes de proyecto y planificadores de
toda la organizacin.
A medida que el PMO crece en madurez y recursos, tambin puede asumir la
responsabilidad de la funcin de programacin del proyecto. Esto tiene varias ventajas sobre
simplemente proporcionar las herramientas y la gua a los planificadores de otros grupos:

Permite al PMO controlar las calificaciones especficas de sus planificadores de proyectos,

tales como la capacitacin requerida, las certificaciones, la experiencia y el conocimiento
demostrado de las normas especficas del PMO, las mejores prcticas y las herramientas.

Permite al PMO aumentar el personal existente en posiciones de programacin de nivel

superior, obteniendo as un mayor retorno de sus inversiones en recursos humanos.

Mejora la capacidad del PMO para fomentar un ambiente positivo en el que se anima a los
planificadores a evaluar cada situacin y hacer excepciones cuando sea apropiado (por
supuesto, todas las excepciones deben ser cuidadosamente documentadas) y contribuir al
crecimiento de la experiencia tanto para los planificadores individualmente como para la
organizacin como un todo.

Facilita la implementacin general de las lecciones aprendidas y acelera la mejora

continua.

Mejora la retencin de empleados ofreciendo oportunidades de ascenso profesional y un

ambiente de trabajo positivo.

Cuando una organizacin reconoce la relacin de los buenos horarios de los proyectos y las
prcticas de programacin con la tasa de xito del proyecto, ha dado el primer paso para
aumentar su propia tasa de xito del proyecto. Mediante la implementacin de estndares
de programacin, la provisin de plantillas de programacin y la programacin de los
planificadores de proyectos, el PMO puede actuar como un catalizador clave para mejorar la
calidad de los calendarios de proyectos en toda la organizacin. Esto puede dar a una
organizacin una ventaja estratgica en el mercado competitivo de hoy en da, donde las
tasas de xito del proyecto ms altas a menudo diferencian las organizaciones exitosas de
las que siguen luchando.

Conclusin

Como se mencion anteriormente, estos secretos no son nuevos conceptos. Como hemos
visto, cada secreto hace su propia contribucin a mejores horarios de proyectos ya
aumentar las tasas de xito de proyectos en toda la organizacin.

La mejor manera de aprovechar estos secretos es asegurarse de que cada uno es seguido
cada vez que crear un nuevo horario. Esto ayudar a asegurar que sus horarios contengan
los componentes adecuados, sean fciles de usar y fciles de mantener. Los horarios con
estas cualidades son mucho ms probables de ser utilizados y actualizados a lo largo de la
vida del proyecto. Adems, es ms probable que los informes generados a partir de estos
programas proporcionen la informacin necesaria para la identificacin temprana de riesgos
y problemas.

Sin embargo, puede ser difcil utilizar los secretos de la programacin de proyectos al
mximo sin el apoyo y la estructura ofrecidos por un PMO u organizacin centralizada
similar. Incluso los mejores planificadores de proyectos y gerentes de proyectos no pueden
construir todo desde cero a la vez. Cuando establezca un PMO o implemente las ideas
descritas aqu por primera vez, empiece pequeo y enfquese en las fortalezas de la
organizacin. Desarrollar un pequeo conjunto de estndares de programacin y procesos,
herramientas y plantillas simples. Capture las lecciones aprendidas y construya un
repositorio donde los planificadores y los administradores de proyectos puedan documentar
sus experiencias, almacenar los horarios que funcionaron bien y crear y compartir nuevos
procesos, herramientas y plantillas.

A medida que la organizacin madura y los planificadores se vuelven ms experimentados,

el PMO puede expandirse en los gerentes de proyectos de capacitacin sobre cmo
construir y usar un buen calendario de proyectos. Cuando haya suficientes recursos, el PMO
podra Asumir la responsabilidad de la programacin de todos los proyectos. Centralizar los
planificadores y la programacin ayuda a garantizar que los estndares y los procesos se
sigan de forma coherente y ofrece una mejor visibilidad de lo que funciona bien y de dnde
se necesitan mejoras.

Por ltimo, es importante tener en cuenta que mientras que los estndares y los procesos
son crticamente importantes para programar la coherencia, no todas las normas o procesos
son la mejor solucin en todas las situaciones. A veces, la desviacin de un proceso o
estndar establecido podra ser mejor bajo ciertas circunstancias. Los buenos planificadores
de proyectos son conscientes de que la programacin es tanto arte como ciencia y que cada
situacin debe evaluarse individualmente. En los casos en que una desviacin de las
normas tiene sentido, las razones deben ser claramente documentadas y comunicadas a los
afectados.

Como planificadores de proyectos, depende de nosotros trabajar con la gerencia de PMO

para ayudarles a entender la importancia de estos "cinco secretos" y para tomar la iniciativa
en el desarrollo de los estndares, procesos y plantillas que proporcionarn la base desde la
cual la organizacin puede comenzar Construccin y gestin de mejores horarios de
proyectos.