Los cinco secretos de la programación de proyectos

Este documento está dirigido a programadores de proyectos, gerentes de proyectos, miembros de

una oficina de administración de proyectos (PMO) y aquellos interesados en aprender más sobre
los factores que contribuyen a una buena programación de proyectos.

Asume un conocimiento básico de las actividades involucradas y los errores comunes de la

programación de proyectos. Si bien los programadores de proyectos con frecuencia juegan más de
un rol en un proyecto, como gerente de proyecto, líder de equipo, etc., este documento se refiere
al programador de proyectos como un papel discreto. la información presentada en este
documento se aplica a proyectos con un programador de proyectos dedicado, así como a
proyectos en los que el programador tiene responsabilidades de proyecto adicionales.

este documento no trata sobre herramientas específicas ni profundiza con respecto a la

metodología de gestión de proyectos, como la que se analiza en la Guía para el cuerpo de
conocimiento de la gestión de proyectos (Guía del PMBOK®) del Project Management Institute —
Cuarta edición (Project Management Institute [PMI]) , 2008). Tiene la intención de proporcionar
una descripción general del proceso de programación y ofrece sugerencias específicas para
mejorar la programación del proyecto y el proceso de programación del proyecto.

este documento de fi ne cinco factores, o “secretos”, que, cuando se implementan de manera

consistente de manera conjunta, dan como resultado cronogramas del proyecto que es más
probable que se utilicen y mantengan a lo largo de la vida de un proyecto. Un cronograma del
proyecto que se sigue y se mantiene durante todo el proyecto puede proporcionar una
identificación temprana de posibles retrasos en el cronograma, riesgos del proyecto y otros
problemas. La identificación temprana de problemas, riesgos y problemas aumenta
significativamente la probabilidad de completar un proyecto a tiempo y dentro del presupuesto y
alcance, lo que a menudo se define como el éxito del proyecto. en el papel de la PMO en la
programación del proyecto y sugiere formas específicas en las que la PMO puede implementar y
apoyar el uso de los "cinco secretos". Involucrar a la PMO en la de fi nición y apoyo del proceso de
programación facilita y acelera el aprendizaje organizacional, que, cuando se realiza
correctamente, beneficia a todos en la organización.
Resumen ejecutivo

El propósito del cronograma de un proyecto es proporcionar una hoja de ruta a través del
proyecto y proporcionar letreros (o hitos) para que sepamos dónde estamos en cualquier
momento.La mayoría de nosotros hemos trabajado en proyectos donde se crea el cronograma del
proyecto. durante la fase de planificación y luego se abandona en gran medida una vez que el
proyecto pasa a la fase de ejecución. A menudo, estos cronogramas de proyectos se centran en el
individuo y los grupos de tareas y actividades necesarias para completar el proyecto. tienden a
pensarse y crearse como una lista de verificación de tareas con plazos, recursos y costos asociados
que se utilizarán y controlarán durante la ejecución de un proyecto. Este enfoque en las
actividades durante la creación del cronograma pasa por alto el hecho de que los proyectos no
existen solo para realizar actividades, existen para producir productos específicos. Para proyectos
pequeños, puede ser suficiente y apropiado crear estos cronogramas de estilo de lista de
verificación basados en actividades. , pero para la mayoría de los que trabajamos en proyectos
más grandes y complejos, una simple lista de verificación es insuficiente. En un proyecto más
grande, desarrollar un cronograma enfocándose principalmente en las tareas y actividades que se
realizarán a menudo hace que sea difícil identificar los hitos clave y saber si estamos en el camino
correcto. El uso de un cronograma de este tipo puede dificultar la anticipación de problemas, y
esto a menudo da como resultado la ocurrencia de eventos inesperados y no planificados, que
eventualmente pueden conducir al fracaso del proyecto. los gerentes antes de desviarse de la
pista requieren un enfoque en los entregables y un nivel constante de detalle. Mantener dicho
cronograma requiere un proceso claramente definido y un enfoque disciplinado para mantenerlo
actualizado. Este documento está destinado a gerentes de proyecto, programadores de proyectos
y personal de PMO que crean y administran cronogramas de proyectos o apoyan a quienes lo
hacen. Describe cinco secretos de la programación de proyectos que, si se siguen, lo ayudarán a
iniciar el camino hacia el desarrollo y la gestión de programas de proyectos que permitan y
respalden las buenas prácticas de gestión de proyectos y contribuyan significativamente al éxito
del proyecto.

los cinco secretos de la programación de proyectos son:

Crea cronogramas de proyectos basados en entregables.

2Establezca y mantenga el nivel de detalle adecuado.

3 Implementar un proceso regular de informes y actualizaciones de estado

4. Revise y ajuste el programa con regularidad.

5 Crear y seguir el estándar de programación de proyectos

Como puede ver, estos secretos no son conceptos nuevos. se presentan aquí juntos para
proporcionar un contexto y una metodología para crear buenos cronogramas de proyectos. Las
siguientes secciones de este documento están diseñadas para ayudar a los programadores de
proyectos, gerentes de proyectos y personal de PMO a pensar de manera diferente sobre los
programas que crean o respaldan y sugerir algunas mejores prácticas para incorporar estos cinco
secretos en los procesos seguidos dentro de sus organizaciones. La construcción de un buen
cronograma de proyecto es establecer lo que de fi ne un buen cronograma. Una de fi nición
simple, y la que se usa a lo largo de este documento, es un cronograma que modela con precisión
el trabajo del proyecto y que mantiene un nivel de detalle consistente y apropiado. Los
cronogramas que cumplen con estos criterios tienen más probabilidades de proporcionar
información precisa sobre el estado del proyecto, los problemas y los riesgos y se mantienen
mucho más fácilmente que los cronogramas que no cumplen con estos criterios. Los proyectos
más pequeños y de corto plazo requieren un cronograma de proyecto mucho más simple y más
pequeño que el proyectos más largos y complejos. Si bien esto es muy obvio para cualquiera que
haya creado incluso unos pocos cronogramas de proyectos, no proporciona suficiente información
para decirnos qué debe contener un cronograma de proyecto simple o complejo ni qué nivel de
detalle es el más apropiado. El resto de este documento proporciona la información adicional
necesaria para ayudarlo a comprender los diversos factores o "secretos" que contribuyen a un
buen proyecto.

Secreto n. ° 1: crear cronogramas de proyectos basados en entregables

Como programadores de proyectos y gerentes de proyectos, somos muy conscientes de que los
entregables son productos tangibles producidos por un proyecto. Todos los proyectos tienen
entregables, por ejemplo, documentación, hardware informático físico instalado y operativo,
aplicaciones correctamente configuradas y accesibles por los usuarios, etc. Durante la ejecución
del proyecto, el equipo del proyecto realiza muchas actividades para producir los entregables del
proyecto. Las actividades consisten en una o más tareas, como recopilar los requisitos del sistema,
instalar hardware, instalar y configurar software, probar el acceso y la funcionalidad del sistema,
etc. Los cronogramas de proyectos se pueden dividir en dos tipos, basados en actividades y
basados en entregables. En mi experiencia, la mayoría de los cronogramas de proyectos se basan
en actividades, lo que significa que se desarrollan desde la mentalidad de "¿qué actividades y
tareas deben completarse durante el curso de este proyecto?" Si bien es importante considerar
cuidadosamente esta pregunta, no debería ser la fuerza impulsora detrás de la estructura y
organización de un horario. En cambio, se debe construir y organizar un buen cronograma del
proyecto en torno a los entregables que el proyecto debe producir.

Hay dos pasos para crear un cronograma de proyecto basado en entregables:

ere are two steps to creating a
deliverables-based project
schedule:
Identify all deliverables and their
“owners”1.
Build a deliverables-based work
breakdown structure (WBS
1. Identifique todos los entregables y sus "propietarios".

2 Construir una estructura de desglose del trabajo basada en entregables (WBS)

Identificar los entregables y los "propietarios" de los entregables

La mayoría de nosotros entendemos la importancia de identificar y documentar todos los

entregables que producirán nuestros proyectos antes de que comience el trabajo en el proyecto.
No es diferente a la hora de crear un cronograma de proyecto. Antes de que se pueda redactar un
cronograma, el alcance y los entregables requeridos para completar ese alcance, deben estar
claramente identificados y documentados. Entonces, el primer paso para crear un buen
cronograma de proyecto es sentarse y documentar todos los entregables que se producirán con el
proyecto. Esto debe ser realizado por el gerente del proyecto, ya que él o ella tiene la
responsabilidad última 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 entregables. Si el proyecto aún no se ha completado en su totalidad,
entonces se puede usar un puesto o título, como "Líder del equipo de infraestructura", en lugar
del nombre de una persona. Hacer esto al principio del ciclo de vida del proyecto puede evitar
desacuerdos sobre quién es responsable de crear o gestionar la creación de un entregable en
particular. Hay muchas formas de identificar los entregables y sus propietarios. Mi preferencia es
que el programador del proyecto facilite una sesión con el gerente del proyecto, los líderes de
equipo apropiados y las partes interesadas clave para de fi nir y documentar los entregables que
se producirán, los insumos requeridos para cada entregable y la forma que tomará cada
entregable. Incluir a las partes interesadas clave en este proceso ayuda a ganar aceptación por lo
que producirá la persona u organización que va a recibir el producto. Durante esta sesión, el rol
del programador del proyecto es facilitar una discusión en la que los entregables específicos, su las
entradas y salidas se documentan y mapean identificando claramente las salidas (es decir, los
entregables) que son entradas para otros entregables. el proceso se completa cuando todos están
de acuerdo en que todos los entregables están documentados y que los formatos de entrada y
salida requeridos de cada entregable son aceptables. Un método para capturar esta información
es crear un diagrama de red. Esto se puede hacer colgando una gran hoja de papel en la pared y
haciendo que los líderes escriban cada uno de sus entregables en notas “adhesivas” separadas y
colgando las notas en el papel. Luego, el equipo debe mover las notas y dibujar líneas / flechas
para indicar las dependencias entre los entregables. La siguiente figura muestra una forma en que
se puede capturar y documentar la información de entrega y dependencia. Como puede ver en la
figura anterior, cada entrega es listado con un solo propietario principal. Es importante tener en
cuenta que, si bien muchos equipos o personas pueden estar involucrados en la finalización del
entregable, es fundamental que se asigne una sola parte responsable que conducirá y rastreará la
(s) entrada (s) requerida (s), el estado del trabajo, asegurar que el entregable tome el formato
acordado y se complete dentro del plazo y el presupuesto programados. Para proyectos más
pequeños, el gerente de proyecto puede desempeñar este papel para todos los entregables; sin
embargo, en proyectos más grandes, el director del proyecto debe delegar esta función para
asegurarse de que haya un único punto focal para cada entregable que se produzca.

Construya una WBS basada en entregables

Ahora que tiene una lista de entregables y propietarios y sabe cómo estos entregables se
interrelacionan, es hora de definir cómo se representarán en el cronograma del proyecto. La
estructura del cronograma de un proyecto es análoga a un esquema para un libro o un artículo. Así
como un esquema documenta los temas principales y su estructura organizacional, la EDT de un
proyecto debe definir las áreas de enfoque principales y sus entregables asociados. el ejercicio
anterior produce la información necesaria para redactar una EDT inicial. la WBS debe estar
organizada de tal manera que se asegure que cada entregable se incluya en el mismo nivel en la
WBS. En algunos casos, cada entregable debe enumerarse en el Nivel 1 de la WBS, en otros casos
puede tener más sentido organizar la WBS por equipo de proyecto o área en el Nivel 1 de la WBS y
luego enumerar todos los entregables que pertenecen a cada equipo / área en el Nivel 2 de la WBS
o el nivel que sea apropiado para el proyecto). En nuestro ejemplo, la información del diagrama de
red que se muestra arriba se organizó por área del proyecto. Todos los entregables relacionados
con la creación y el soporte de la infraestructura subyacente se agrupan, los entregables
relacionados con las aplicaciones se agrupan y así sucesivamente. A medida que se completa la
EDT, las tareas detalladas se insertan debajo de su entregable asociada. La Figura 2 muestra un
ejemplo de una EDT simple basada en entregables que se creó a partir de la información
recopilada previamente. Independientemente del nivel de la EDT de los entregables, es
fundamental que todos los entregables aparecen en el mismo nivel de WBS y que todas las tareas
y actividades detalladas que se enumeran debajo de cada entregable se relacionan directamente
con la finalización de ese entregable. Si no lo hace, será difícil monitorear el progreso de todos
Secreto # 2: Determine el nivel de detalle apropiado Determine el nivel de detalle apropiado para
cada programa de proyecto

los mejores cronogramas de proyectos son aquellos que contienen toda la información requerida y
nada más. Dado que cada proyecto es único, no existe un nivel único de detalle que sea apropiado
para todos los proyectos o cronogramas de proyectos. por lo tanto, el nivel de detalle requerido
para un proyecto en particular debe definirse antes del inicio de la programación. El nivel de
detalle requerido debe definirse como un rango de duraciones de tareas aceptables y / o esfuerzo
de trabajo. Además, también debe definirse el tipo de tareas aceptables. Por ejemplo, ¿se
incluirán en el cronograma las actividades administrativas como las reuniones del equipo del
proyecto, el seguimiento del tiempo, la nivelación de recursos, la gestión de personas, etc.? Si es
así, ¿se les hará un seguimiento de cada entregable o se les llamará bajo su propia área de
proyecto? Si no es así, ¿se tomará en cuenta este tiempo reduciendo la disponibilidad de recursos
o se utilizará un proyecto administrativo? Una regla para definir un nivel estándar de detalle para
un cronograma que puede ser útil es la “Regla del 1% al 10%” desarrollada por Eric Uyttewaal,
PMP, en su libro Programación dinámica con Microsoft® Office Project. la “regla del 1% al 10%”
establece que la duración de cualquier tarea detallada debe estar entre el 1% y el 10% de la
duración total del proyecto. Por ejemplo, si se espera que la duración del proyecto sea de 100
días, todas las tareas detalladas deben tener una duración de entre 1 y 10 días. esta regla también
se puede aplicar a las estimaciones de trabajo, aunque puede ser difícil determinar el trabajo total
estimado hasta que el cronograma esté completamente desarrollado. por lo tanto, recomiendo
usar la duración como factor determinante al usar esta regla. Otra forma de definir el nivel de
detalle es poner un límite superior e inferior al número de horas de trabajo que puede tener una
tarea; en otras palabras, definir un trabajo aceptable Tamaño del paquete. el tamaño del paquete
de trabajo debe ser lo suficientemente grande como para poder medirse y, al mismo tiempo, debe
ser lo suficientemente pequeño como para administrarlo. Si el paquete de trabajo es demasiado
pequeño, el horario puede volverse innecesariamente grande y desordenado, lo que dificulta su
administración. Si el paquete de trabajo es demasiado grande, puede ser difícil rastrear con
precisión el progreso de las tareas, lo que dificulta la identificación de riesgos o problemas desde
el principio.Una buena regla para definir el tamaño del paquete de trabajo es mantener la
duración de la tarea y / o el trabajo. Esfuércese en uno o dos ciclos de informes. Si su proyecto
produce informes de estado semanalmente, entonces el paquete de trabajo debe tener una
duración de entre una y dos semanas y / o de 40 a 80 horas de esfuerzo. Independientemente de
las reglas seleccionadas para definir el nivel apropiado de detalle para el cronograma de un
proyecto. , la clave está en seguir consistentemente la (s) regla (s) seleccionada (s). Los
cronogramas de proyectos que tienen diferentes niveles de detalle tienden a ser más difíciles de
establecer y reportar porque la información clave puede pasarse por alto fácilmente cuando está
enterrada demasiado profundamente en la EDT y / o no refleja un resultado mensurable. Además,
los cronogramas de proyectos que no siguen reglas consistentes para definir el nivel apropiado de
detalle pueden volverse innecesariamente largos, asumiendo el papel de una lista de verificación
en lugar de un cronograma. esto los pone en alto riesgo de ser abandonados durante la ejecución
del proyecto.

Secreto n. ° 3: implementar un proceso regular de actualización y presentación de informes del

estado del cronograma

Como todos sabemos, crear un buen cronograma de proyecto no es suficiente para garantizar el
éxito del proyecto. el cronograma debe actualizarse, mantenerse y ajustarse en función de los
eventos a lo largo de la fase de ejecución del proyecto. Para mantener un cronograma de proyecto
realista y útil, debe actualizarse periódicamente y ajustarse según lo justifiquen los eventos. El
planificador del proyecto es responsable de determinar qué información recopilar, con qué
frecuencia se recopilará la información y el método de recopilación y validando la información. Los
métodos utilizados dependerán de los requisitos de informes, la frecuencia de los informes, la
disponibilidad de herramientas automáticas o manuales y la ubicación geográfica de los miembros
del equipo responsables de proporcionar los datos. Como mínimo, los programadores deben
recopilar el trabajo real y restante y / o duración, fecha real de inicio y finalización. Sin esta
información, el programa no se puede mantener correctamente. A menudo es tentador recopilar
el porcentaje de datos completos para cada tarea en lugar del trabajo / duración real y restante;
sin embargo, el porcentaje de información completa es subjetivo y no proporciona ninguna
información sobre cuándo se terminará la tarea ni si es posible que se requieran esfuerzos y / o
recursos adicionales para completar la tarea a tiempo.

El primer paso en el desarrollo de un proceso de informes y actualizaciones regulares es trabajar

con el director del proyecto y las partes interesadas clave para determinar los requisitos y
expectativas de los informes. la siguiente es una lista de requisitos mínimos de informes que se
aplica a la mayoría de los proyectos:

Descripción general ejecutiva •: descripción general del estado del proyecto a un alto nivel. este
informe muestra con frecuencia el estado real de los hitos clave y los entregables en comparación
con el cronograma de referencia.

Informes de variación • (Duración, inicio, finalización y / o variación del trabajo): tareas,

actividades y / o entregables específicos que se están retrasando (o adelantando) el cronograma,
están demorando significativamente más (o menos) de lo esperado y / o requieren
significativamente más (o menos) trabajo de lo previsto. el nivel de detalle de este informe lo dicta
normalmente la audiencia que lo recibe.
“Look-future” •: una lista de entregables y tareas asociadas, ya sea que estén actualmente activas
o que se estén activando en una ventana específica de “look-future” (número de días, semanas,
meses, etc.)

Utilización de recursos •: la cantidad de horas que cada recurso está programado para trabajar
durante el siguiente período (por ejemplo, semana, mes, trimestre). Esto se usa a menudo junto
con el informe de "anticipación" para garantizar que los recursos estén disponibles para completar
el trabajo. asignados en un período de tiempo dado manteniendo una carga de trabajo realista.

Problemas / riesgos del cronograma •: una lista / descripción y el estado de los problemas o
riesgos actuales o anticipados relacionados con el cronograma del proyecto. Este informe debe
incluir las tareas asociadas con cada riesgo o problema, otros según se requiera o se considere
apropiado para el proyecto.

el planificador del proyecto necesita una comprensión profunda de los requisitos de presentación
de informes antes de definir la información de estado que se recopilará y las fuentes de esta
información. Además, es importante comprender a los distintos destinatarios de la información
para poder de fi nir el nivel de detalle apropiado para cada uno de los informes. Algunos informes
pueden tener versiones de gestión con información de alto nivel y versiones de equipo que
contienen información más detallada. A medida que se genera y distribuye cada informe, el
planificador y / o director del proyecto debe analizar los informes e identificar posibles áreas
problemáticas. Para cada problema, el programador del proyecto debe revisar las áreas afectadas
del cronograma e identificar posibles soluciones o estrategias de mitigación. esta información
debe documentarse cuidadosamente y proporcionarse al director del proyecto y / o las partes
interesadas correspondientes. Dado que no todos los programadores de proyectos tienen el
mismo grado de pericia o experiencia en el análisis del cronograma, el gerente del proyecto debe
trabajar con el programador del proyecto para identificar y documentar las expectativas de
informes y análisis y luego determinar si la responsabilidad del análisis del cronograma debe
recaer en el programador. un analista de programación o una combinación de los dos

Secreto n. ° 4: revise y ajuste el horario con regularidad

No se puede subestimar la importancia de establecer y seguir un proceso de análisis, informes y

actualización de estado coherente durante toda la vida de un proyecto. Sin embargo, es
igualmente importante reconocer que incluso los proyectos mejor planificados experimentan
eventos inesperados o no planificados que podrían tener un impacto significativo en el
cronograma. Por lo tanto, para garantizar que el cronograma siga siendo relevante y preciso
durante todo el proyecto, es fundamental contar con un proceso para realizar y controlar los
cambios en el cronograma según lo requieran los eventos.Para proyectos más grandes, se debe
implementar un proceso formal de control de cambios de cronograma a fin de Mantenga un
control estricto sobre el cronograma del proyecto. Para proyectos más pequeños, este proceso de
control de cambios puede ser más informal. Todos los procesos de control de cambios de
programación deben tener lo siguiente en común:

Un conjunto claramente definido de cambios, generalmente menores, que se pueden realizar sin
pasar por el proceso de control de cambios (por ejemplo, agregar o modificar asignaciones de
recursos, nombres de tareas) Un conjunto finito de personas autorizadas para aprobar

2. cambios significativos en el cronograma del proyecto (es decir, una junta de control de cambio
de cronograma) Todos los cambios significativos en el cronograma del proyecto deben estar

3. bien documentados en cuanto a las razones y el resultado esperado de la cambio Un proceso

de captura de lecciones aprendidas y un repositorio

4. Un archivo de versiones anteriores del cronograma del proyecto para mostrar la evolución del
cronograma y para retener información histórica, el proceso de control de cambios del
cronograma debe estar estrechamente vinculado con el proceso de control de cambios general del
proyecto. Cuando los cambios del proyecto se aprueban a través del proceso de control de
cambios del proyecto, deben desencadenar el proceso de control de cambios de cronograma para
garantizar que todos los cambios en el proyecto se reflejan en el cronograma de manera oportuna
y precisa. Revisado periódicamente para asegurarse de que sigue siendo válido. el intervalo entre
la revisión del cronograma y los ciclos de actualización debe ser determinado principalmente por
la duración del proyecto. Los proyectos con duraciones más cortas deben revisarse y actualizarse
con más frecuencia que los proyectos más grandes y de mayor duración, aunque también se
deben considerar otros factores, como la criticidad del proyecto. Los proyectos que duran más de
un año pueden de fi nir el ciclo de revisión del cronograma por un intervalo de tiempo específico. y
/ o cuando se alcancen los hitos clave del proyecto. Por ejemplo, un proyecto de este tipo puede
revisarse y actualizarse trimestralmente, al final de cada fase del proyecto y / o cuando se
alcancen hitos clave. Independientemente del intervalo del ciclo de revisión, el proceso de revisión
y actualización debe involucrar al gerente del proyecto, los líderes del equipo y las partes
interesadas clave. Como se hizo en la identificación inicial de los entregables, el programador del
proyecto debe facilitar una sesión de trabajo donde se revisa y actualiza el programa para cada
entregable según sea necesario. A medida que se realizan las actualizaciones del programa, el
programador del proyecto debe identificar y anotar cualquier cambio posterior resultante. Cuando
un cambio en el cronograma de un entregable afecta negativamente el cronograma de otro
entregable, el proyecto.

Secreto n. ° 5: crear y seguir estándares de programación

Como podemos ver en los cuatro "secretos" anteriores, crear y mantener un buen cronograma de
proyectos puede ser una actividad compleja y que requiere mucho tiempo. El uso de estándares
de programación puede reducir significativamente el tiempo requerido y eliminar parte de la
complejidad involucrada en el desarrollo de un programa de proyecto realista y mantenible.
Además, los estándares de programación ayudan a garantizar la coherencia cuando los programas
son creados por múltiples programadores y / o gerentes de proyecto. Esto es particularmente
importante cuando una PMO es responsable de supervisar y / o respaldar muchos proyectos
simultáneamente, ya que ayuda a garantizar que la información reportada en los diversos
cronogramas represente información similar que se pueda comparar fácilmente. su Norma de
práctica para la programación. Este estándar se describe en el sitio web del PMI como que
proporciona “un medio cuanti fi cable para evaluar la madurez de un modelo de programación y
transforma la sección de gestión del tiempo del proyecto (Capítulo 6) de la Guía del PMBOK® (PMI,
2008) en“ un proceso de medición objetivo y procesable para la programación del proyecto ". El
estándar de práctica para la programación proporciona información completa y específica para los
gerentes de proyectos y los programadores y es un excelente recurso. Sin embargo, en el contexto
de este documento, los estándares de programación se consideran pautas específicas para crear y
mantener los programas del proyecto dentro de una Organizaciones. estos estándares pueden
incluir el uso de una WBS basada en entregables, un tamaño de paquete de trabajo estándar,
ciclos y procesos de informes específicos, un proceso de control de cambios de cronograma, etc.
Los estándares de programación son creados o adoptados por una organización que luego
defiende, apoya y monitorea su uso dentro de los programas desarrollados para proyectos dentro
de su esfera de influencia o control. Es una buena práctica basar estándares de programación
específicos en un documento aceptado por la industria, como el estándar PMI y / o las mejores
prácticas aceptadas por la industria.

Conclusión

Como se mencionó anteriormente, estos secretos no son conceptos nuevos. Como hemos visto,
cada secreto hace su propia contribución a mejores cronogramas de proyectos y mayores tasas de
éxito de proyectos en toda la organización. La mejor manera de aprovechar estos secretos es
asegurarse de que se sigan cada vez que se crea un nuevo cronograma. esto ayudará a garantizar
que sus programas contengan los componentes correctos, sean fáciles de usar y de mantener. Es
mucho más probable que los programas con estas cualidades se utilicen y actualicen a lo largo de
la vida del proyecto. Además, es más probable que los informes generados a partir de dichos
programas proporcionen la información necesaria para la identificación temprana de riesgos y
problemas. Sin embargo, puede ser difícil utilizar los secretos de la programación de proyectos al
máximo sin el apoyo y la estructura que ofrece una PMO o similar. organización centralizada.
Incluso los mejores programadores de proyectos y gerentes de proyectos no pueden construir
todo desde cero a la vez. Cuando establezca una PMO o implemente las ideas descritas aquí por
primera vez, comience con algo pequeño y concéntrese en las fortalezas de la organización.
Desarrolle un pequeño conjunto de estándares de programación y procesos, herramientas y
plantillas simples. Capture las lecciones aprendidas y cree un repositorio donde los programadores
y gerentes de proyectos puedan documentar sus experiencias, almacenar horarios que
funcionaron bien y construir y compartir nuevos procesos, herramientas y plantillas.A medida que
la organización madura y los programadores adquieren más experiencia, la PMO puede expandirse
a proyectos de capacitación gerentes sobre cómo construir y usar un buen cronograma de
proyectos. Cuando existen recursos suficientes, la PMO puede asumir la responsabilidad de
programar todos los proyectos. Centralizar los programadores y la programación ayuda a
garantizar que los estándares y procesos se sigan de manera consistente y ofrece una mejor
visibilidad de lo que funciona bien y dónde se necesitan mejoras. Por último, es importante tener
en cuenta que si bien los estándares y los procesos son de vital importancia para la coherencia de
la programación, no todos los estándares o procesos son la mejor solución en todas las
situaciones. A veces, la desviación de un proceso o estándar establecido puede ser mejor en
determinadas circunstancias. Los buenos planificadores de proyectos son conscientes de que la
planificación es tanto un arte como una ciencia y que cada situación debe evaluarse
individualmente. En los casos en que tenga sentido una desviación de los estándares, las razones
deben documentarse claramente y comunicarse a los afectados. Como programadores de
proyectos, nos corresponde a nosotros trabajar con la gerencia de la PMO para ayudarlos a
comprender la importancia de estos "cinco secretos" y tomar la iniciativa en el desarrollo de
estándares, procesos y plantillas que proporcionarán la base desde la cual la organización puede
comenzar a construir y administrar mejores cronogramas de proyectos