Lectura 2

Los cinco secretos de la programación de proyectos Este documento está destinado a

planificadores de proyectos, gerentes de proyectos, miembros de una oficina de gestió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 las dificultades comunes de la programación de proyectos. Mientras que los programadores de
proyectos con frecuencia juegan más de un papel 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 planificador de proyectos
dedicado, así como a proyectos en los que el planificador tiene responsabilidades adicionales del
proyecto. Este documento no trata herramientas específicas ni profundiza con respecto a la
metodología de gestión de proyectos como la discutida en la Guía del Instituto de Gestión de
Proyectos del Cuerpo de Conocimientos de Gestión de Proyectos (Guía PMBOK®) — Cuarta edición
(Project Management Institute [PMI], 2008). Su objetivo es proporcionar una visión general del
proceso de programación y ofrece sugerencias específicas para mejorar los cronogramas del
proyecto y el proceso de programación del proyecto. Este documento define cinco factores (o
"secretos") que, cuando se implementan juntos de manera consistente, dan como resultado
cronogramas del proyecto que son más propensos a ser utilizados y mantenidos durante la vida de
un proyecto. Un cronograma del proyecto que se sigue y se mantiene a lo largo de un proyecto
puede proporcionar una identificación temprana del posible retraso del cronograma, los riesgos
del proyecto y otros problemas. La identificación temprana de problemas, riesgos y problemas
aumenta significativamente la probabilidad de completar un proyecto Por Michelle Colodzin, PMP,
PMI-SP, MCTS, MS Project Black BeltMetaVista Consulting Groupon tiempo y dentro del
presupuesto y el alcance, que a menudo se define como éxito del proyecto. actualmente parte de
una PMO o que está considerando establecer una PMO, este documento proporciona información
sobre el papel de la PMO en la programación del proyecto y sugiere formas específicas en que la
PMO puede implementar y apoyar el uso de los "cinco secretos". Involucrar a la PMO en la
definición y respaldar el proceso de programación facilita y acelera el aprendizaje organizacional,
que, cuando se hace correctamente, beneficia a todos en la organización. Resumen ejecutivo El
propósito de un cronograma del 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 en los que el cronograma del proyecto se crea
durante la fase de planificación se 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. Suelen ser concebidos
y creados como una lista de verificación de tareas con plazos, recursos y costos asociados para ser
utilizados y rastreados 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 estas listas de verificación basadas en actividades. horarios,
pero para la mayoría de nosotros 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 un cronograma del proyecto que se sigue y se
mantiene a lo largo de un proyecto puede proporcionar una identificación temprana de posibles
retrasos en el cronograma, riesgos del proyecto y otros problemas. "

Biblioteca virtual de PMI | www.PMI.org | © 2009 Michelle Colodzin2 las actividades que se
realizan a menudo hacen que sea difícil identificar los hitos clave y saber si estamos en camino. El
uso de un cronograma de este tipo puede dificultar la anticipación de problemas, y esto a menudo
resulta en la ocurrencia de eventos inesperados y no planificados, que eventualmente pueden
conducir al fracaso del proyecto. Los gerentes antes de desviarse 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 proyectos, planificadores 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 comenzar a desarrollar y administrar
cronogramas de proyectos que permitan y respalden las buenas prácticas de administración de
proyectos y contribuyan significativamente al éxito del proyecto. Los cinco secretos de la
programación de proyectos son:

1Cree cronogramas de proyectos basados en entregables.

2 Establecer y mantener el nivel de detalle apropiado.

3. Implemente una actualización de estado regular y un proceso de informes.

4. Revise y ajuste el horario regularmente.

5.Cree y siga los estándares de programación de proyectos. Como puede ver, estos secretos no
son conceptos nuevos.

Como puede ver, estos secretos no son conceptos nuevos. Aquí se presentan 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 planificadores de
proyectos, gerentes de proyectos y personal de PMO a pensar de manera diferente sobre los
cronogramas que crean o apoyan y sugieren algunas mejores prácticas para incorporar estos cinco
secretos en los procesos seguidos dentro de sus organizaciones. El paso para construir un buen
cronograma del proyecto es establecer qué define un buen cronograma. Una definición simple, y
la utilizada en 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 proyectos mucho más simple y pequeño que proyectos más largos y
complejos. Si bien esto es muy obvio para cualquiera que haya creado incluso algunos
cronogramas de proyectos, no proporciona suficiente información para decirnos nada sobre lo que
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 requerida para
ayudarlo a comprender los diversos factores o "secretos" que contribuyen a un buen proyecto

programa, cómo aplicar estos secretos a sus horarios y cómo construir una organización que
establezca, promueva y respalde las buenas prácticas de programación a largo plazo.

Secreto # 1: Crear cronogramas de proyectos basados en entregables

Como planificadores de proyectos y gerentes de proyectos, somos conscientes de que los

entregables son productos tangibles producidos por un proyecto. Todos los proyectos tienen
entregables, por ejemplo, documentación, hardware físico de la computadora 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 las
entregas del proyecto. Las actividades consisten en una o más tareas, como reunir 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 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 debe 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:

1. Identificar todos los entregables y sus "propietarios"

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

Identificar los entregables y los "propietarios" 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 al crear un cronograma del proyecto. Antes de que se pueda redactar un
cronograma, el alcance y las entregas requeridas para completar ese alcance deben identificarse y
documentarse claramente. Entonces, el primer paso para crear un buen cronograma del proyecto
es sentarse y documentar todos los entregables que producirá el proyecto. El gerente del proyecto
debe hacer esto, 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 primario
para cada entrega en el momento en que se identifican los entregables. . Si el proyecto aún no se
ha establecido completamente, entonces se puede usar un puesto o título, como "Líder del equipo
de infraestructura", en lugar del nombre de un individuo. Hacer esto al principio del ciclo de vida
del proyecto puede evitar desacuerdos con respecto a quién es responsable de crear o administrar
la creación de un producto en particular.

PAG 3

Hay muchas maneras de identificar los entregables y sus propietarios. Prefiero que el planificador
del proyecto facilite una sesión con el gerente del proyecto, los líderes de equipo apropiados y las
partes interesadas clave para definir y documentar los entregables que se producirán, las entradas
requeridas para cada entregable y la forma que tomará cada entregable. La inclusión de las partes
interesadas clave en este proceso ayuda a obtener la aceptación de lo que producirá la persona u
organización que recibirá el producto. Durante esta sesión, el rol del planificador del proyecto es
facilitar una discusión mediante la cual los entregables específicos, sus las entradas y salidas se
documentan y mapean identificando claramente aquellas salidas (es decir, entregables) que son
entradas para otras entregas. El proceso se completa cuando todos están de acuerdo en que todos
los entregables están documentados y 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 un gran trozo de papel en una pared y haciendo que los
conductores escriban cada uno de sus entregables en notas "adhesivas" separadas y colgando las
notas en el papel. 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 se enumera con un
único propietario primario. Es importante tener en cuenta que si bien muchos equipos o
individuos pueden estar involucrados en la finalización de la entrega, es fundamental que se
asigne una única parte responsable que conducirá y rastreará las entradas requeridas, el estado
del trabajo, garantizar que el entregable toma el formato acordado y se completa dentro del plazo
y presupuesto programados. Para proyectos más pequeños, el gerente del proyecto puede
desempeñar este papel para todos los entregables; sin embargo, en proyectos más grandes el
proyecto.

El gerente debe delegar esta función para asegurarse de que haya un único punto focal para cada
entregable que se producirá.

Construir una WBS basada en entregables

Ahora que tiene una lista de entregas y propietarios y sabe cómo se entrelazan estas entregas, es
hora de definir cómo se representarán en el cronograma del proyecto. La estructura de un
cronograma del proyecto es análoga a un esquema para un libro o documento. Del mismo modo
que un esquema documenta los temas principales y su estructura organizativa, la WBS de un
proyecto debe definir las principales áreas de enfoque y sus resultados asociados. El ejercicio
anterior produce la información requerida para redactar una WBS inicial. La WBS debe organizarse
de tal manera que se garantice que cada entregable se incluya al mismo nivel en la WBS. En
algunos casos, cada entregable debe figurar en el nivel 1 de la WBS, en otros casos puede tener
más sentido organizar la WBS por equipo o área del proyecto en el nivel 1 de la WBS y luego
enumerar todos los entregables de cada equipo / área en el nivel 2 de la WBS ( o el nivel
apropiado para el proyecto). En nuestro ejemplo, la información del diagrama de red que se
muestra arriba fue organizada por área del proyecto. Todos los productos relacionados con la
creación y el soporte de la infraestructura subyacente se agrupan, los productos relacionados con
las aplicaciones se agrupan, etc. A medida que se despliega la WBS, las tareas detalladas se
insertan debajo de su entregable asociado. La Figura 2 muestra un ejemplo de una WBS simple
basada en entregables que se creó a partir de la información recopilada previamente.
Independientemente del nivel WBS de los entregables, es crítico que todos los entregables
aparecen en el mismo nivel PEP y que todas las tareas y actividades detalladas que se enumeran a
continuación de cada entregable se relacionan directamente con la finalización de esa entrega. De
lo contrario, será difícil monitorear el progreso de todos

PAG 4

Entregas y afectarán negativamente las capacidades de informes.

Tomando la WBS que acabamos de crear, el paso final para construir la base o el marco de nuestro
cronograma es ingresar la información en una herramienta de programación. La Figura 3 muestra
el marco de programación simple que resultó de la WBS y el diagrama de red que creamos en los
pasos anteriores.

Al revisar la figura, tenga en cuenta lo siguiente:

Todos los entregables están en el mismo nivel PEP (Nivel 2 en este caso)

• Cada entregable tiene asignado un único propietario • Completar todos los entregables
asociados con un proyecto

• reaarea (por ejemplo, infraestructura, aplicaciones) está marcada por un hito. Estos hitos
aparecen en el mismo nivel PEP que los entregables.

Las dependencias del diagrama de red se incluyen • como enlaces entre tareas (es decir,
predecesores / sucesores). A medida que el gerente del proyecto o los líderes del equipo agregan
tareas detalladas debajo de cada entregable, también deben agregar un hito que marque la
finalización de el entregable y asegúrese de que esté vinculado a las tareas de detalle apropiadas.
Esto se muestra en la Figura 3 en el primer entregable en cada área del proyecto: Instalar
hardware (WBS 1.1), Instalar aplicaciones (WBS 2.1) y Documentar cambios en los procesos
comerciales (WBS 3.1)
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. Como cada proyecto es único, no existe un nivel de detalle único 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, el tipo de tareas aceptables también debe definirse. Por ejemplo, ¿se
incluirán en el cronograma actividades administrativas como reuniones del equipo del proyecto,
seguimiento del tiempo, nivelación de recursos, gestión de personas, etc.? Si es así, ¿serán
rastreados para cada entregable o serán llamados bajo su propia área de proyecto? Si no es así,
¿se tendrá en cuenta este tiempo reduciendo la disponibilidad de recursos o se utilizará un
proyecto administrativo? Una regla para definir un nivel de detalle estándar para un cronograma
que puede ser útil es la “Regla del 1% –10%” desarrollada por Eric Uyttewaal, PMP, en su libro
Dynamic Scheduling with Microsoft® Office Office Project. La “Regla del 1% –10%” establece que la

Pagina 5

la duración de cualquier tarea detallada debe estar entre 1% y 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 establecer un límite superior e inferior en la cantidad
de horas de trabajo que puede tener una tarea; en otras palabras, definir un tamaño de paquete
de trabajo aceptable. El tamaño del paquete de trabajo debe ser lo suficientemente grande como
para ser medible mientras se mantiene lo suficientemente pequeño como para administrarlo. Si el
paquete de trabajo es demasiado pequeño, el cronograma puede volverse innecesariamente
grande y desordenado, lo que hace difícil administrarlo. 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 temprana de riesgos o problemas. Una buena regla general para definir el tamaño
del paquete de trabajo es mantener la duración de la tarea y / o el trabajo Trabaje dentro de uno o
dos ciclos de informes. Si su proyecto produce informes de estado semanalmente, el paquete de
trabajo debe durar entre una y dos semanas y / o entre 40 y 80 horas de esfuerzo.

Independientemente de la (s) regla (s) seleccionada (s) para definir el nivel de detalle apropiado
para un cronograma del proyecto, la clave está en siguiendo las reglas seleccionadas Los
cronogramas de proyectos que tienen niveles de detalle variables tienden a ser más difíciles de
determinar e informar porque la información clave se puede pasar por alto fácilmente cuando se
oculta demasiado en la EDT y / o no refleja un valor medible resultado. Además, los cronogramas
de proyectos que no siguen reglas consistentes para definir el nivel de detalle apropiado pueden
ser 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.

Asegúrese de que todas las tareas ingresadas en el cronograma cumplan con los criterios
establecidos

Ahora que se ha desarrollado una WBS basada en entregables y se ha definido el nivel de detalle
aceptable, el siguiente paso parece ser el más fácil: elaborar los detalles del cronograma. Sin
embargo, esta puede ser la parte más difícil de desarrollar un buen cronograma de proyectos.
Muchos programadores conocen bien el trabajo para construir la información detallada ellos
mismos o recopilan una lista de tareas y actividades del gerente del proyecto y / o los líderes del
equipo del proyecto. Es muy fácil ingresar esta información en una herramienta de programación y
decir el El horario está completo. Al seguir este patrón, los planificadores pueden perder de vista
el papel que desempeñan dentro del proyecto, para garantizar que el cronograma proporcione
información valiosa del proyecto mientras se mantiene el mantenimiento.

Pagina 6

requisitos al mínimo. Esto es particularmente cierto cuando el planificador del proyecto

desempeña más de un rol en el proyecto, como el gerente del proyecto o el líder del equipo. Para
garantizar que el cronograma construido sea realista y sostenible, el planificador debe asumir la
responsabilidad de evaluar todas las tareas que se envían o creado por ellos antes de ingresarlos
en el cronograma del proyecto. Si bien muchos de nosotros vemos esto como un trabajo extra que
consume un tiempo valioso que podríamos estar usando para hacer el trabajo "real", de hecho, es
una de las actividades más importantes en el desarrollo del cronograma del proyecto. El tiempo
dedicado a evaluar, editar y / o la combinación de tareas detalladas en el cronograma de un
proyecto no solo reducirá el tiempo requerido para administrar el cronograma, sino que puede ser
la clave para identificar rápidamente el posible deslizamiento del cronograma, problemas y / o
riesgos para que haya tiempo suficiente para evitar o mitigar Para determinar si una tarea debe
incluirse en el cronograma de un proyecto, el planificador debe hacer las siguientes preguntas:

1. ¿Esta tarea contribuye directamente a la finalización? de uno o más entregables específicos?

2. ¿La tarea tiene un nivel de detalle apropiado?

3. ¿Esta tarea tiene al menos un nombre o genérico? recurso asignado?

4. ¿Esta tarea tiene al menos un predecesor y / o. un sucesor?

Solo cuando la respuesta a todas estas preguntas es sí, la tarea debe agregarse al cronograma del
proyecto. Si el planificador no conoce la respuesta a una de estas preguntas o si falta información,
el planificador debe asumir la responsabilidad de hacer un seguimiento con el propietario del
producto al que se relaciona esta tarea para obtener la información faltante. Una vez ingresada
toda la información en el plan, los recursos deben nivelarse para garantizar que el cronograma sea
realista y que los recursos estarán disponibles cuando sea necesario. La construcción de un
cronograma del proyecto de esta manera ayudará a garantizar que el resultado sea un
cronograma que produzca:

Una ruta crítica completa e ininterrumpida

• tasksTareas detalladas que son relevantes para entregables específicos

• Una línea de tiempo realista

• schedule Un horario que es más fácil de mantener

• reports Informes de estado coherentes y relevantes

Secreto # 3:

Implementar un proceso regular de actualización de estado y de informes

Como todos sabemos, construir un buen cronograma del proyecto no es suficiente para garantizar
el éxito del proyecto. El cronograma debe actualizarse, mantenerse y ajustarse según los eventos
durante 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 se recopilará, con qué frecuencia se
recopilará la información y el método para recopilarla. y validando la información. Los métodos
utilizados dependerán de los requisitos de presentación de informes, la frecuencia de
presentación de informes, la disponibilidad de herramientas automáticas y 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, inicio real y
fechas de finalización reales. Sin esta información, el cronograma no puede mantenerse
adecuadamente. 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 información acerca de cuándo se completará la tarea ni si
es posible que se requiera un esfuerzo y / o recursos adicionales para completar la tarea a tiempo.
El primer paso para desarrollar una actualización regular y El proceso de presentación de informes
consiste en trabajar con el gerente del proyecto y las partes interesadas clave para determinar los
requisitos y expectativas de presentación de informes. La siguiente es una lista de requisitos
mínimos de informes que se aplican a la mayoría de los proyectos:
Resumen ejecutivo • : descripción general del estado del proyecto a un alto nivel. Este informe
muestra con frecuencia el estado real de hitos clave y entregables en comparación con el
cronograma de referencia.

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

actividades y / o entregables específicos que se retrasan (o adelantan) del cronograma, se
demoran mucho más (o menos) de lo esperado y / o son requiriendo significativamente más (o
menos) trabajo de lo anticipado. El nivel de detalle de este informe normalmente lo dicta la
audiencia que lo recibe.

Pag 7

“Look-ahead” • : una lista de entregables y tareas asociadas, ya sea actualmente activas o

volviéndose activas en una ventana específica de "look-ahead" (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 próximo período (p. Ej., Semana, mes, trimestre) often a menudo se usa junto con el
informe "anticipado" para garantizar que los recursos estén disponibles para completar el trabajo
asignado en un período de tiempo dado mientras se mantiene una carga de trabajo realista.

Problemas / riesgos del cronograma • : un listado / descripción y 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 sea necesario o se considere
apropiado para el proyecto. • El planificador del proyecto necesita una comprensión profunda de
los requisitos de informes antes de definir la información de estado que se recopilará y las fuentes
para esta informacion. Además, es importante comprender a los distintos destinatarios de la
información para definir 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 del proyecto y / o el gerente del proyecto deben analizar los informes e identificar
posibles áreas problemáticas. Para cada problema, el planificador del proyecto debe revisar las
áreas afectadas del cronograma e identificar posibles resoluciones o estrategias de mitigación.
Esta información debe documentarse cuidadosamente y proporcionarse al gerente del proyecto y
/ o partes interesadas apropiadas. Como no todos los planificadores de proyectos tienen el mismo
grado de experiencia o experiencia en el análisis de cronogramas, el gerente del proyecto debe
trabajar con el planificador de proyectos para identificar y documentar las expectativas de
informes y análisis y luego determinar si la responsabilidad del análisis de cronogramas debe
recaer en el planificador un analista de horarios o una combinación de los dos.

Secreto # 4

Revise y ajuste el cronograma regularmente. No se puede exagerar la importancia de establecer y

seguir un proceso de actualización, informe y análisis de estado constante durante 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 impactar
significativamente 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 a a medida que los eventos lo justifiquen. Para proyectos más grandes, se debe implementar un
proceso formal de control de cambio de cronograma para mantener un control estricto sobre el
cronograma del proyecto. Para proyectos más pequeños, este proceso de control de cambios
podría ser más informal. Todos los procesos de control de cambios de programación deben tener
lo siguiente en común:

1. Un conjunto claramente definido de cambios, usualmente menores. puede realizarse sin pasar
por el proceso de control de cambios (por ejemplo, agregar o modificar asignaciones de recursos,
nombres de tareas)

2. Un conjunto finito de personas que están autorizadas para aprobar 2. cambios significativos en
el cronograma del proyecto (es decir, una junta de control de cambio de cronograma)

3. Todos los cambios significativos en el cronograma del proyecto deben ser. bien documentado
en cuanto a la (s) razón (es) y el resultado esperado del cambio

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

5 Un archivo de versiones anteriores del cronograma del proyecto para mostrar la evolución del
cronograma y retener información histórica

El proceso de control de cambio de horario debe estar estrechamente relacionado con el proceso
general de control de cambios del proyecto. Cuando los cambios del proyecto se aprueban a
través del proceso de control de cambios del proyecto, deben activar el proceso de control de
cambios del cronograma para garantizar que todos los cambios en el proyecto se reflejen de
manera rápida y precisa en el cronograma. Incluso cuando no ocurran cambios importantes en el
proyecto, el cronograma debe ser revisado periódicamente para garantizar que siga siendo válido.
El intervalo entre la revisión del cronograma y los ciclos de actualización debe determinarse
principalmente por la duración del proyecto. Los proyectos con duraciones más cortas deben
revisarse y actualizarse con mayor frecuencia que los proyectos más grandes y de mayor duración,
aunque también deben considerarse otros factores, como la importancia crítica del proyecto. Los
proyectos que duran más de un año pueden definir el ciclo de revisión del cronograma por un
intervalo de tiempo específico. y / o cuando se alcanzan los hitos clave del proyecto. Por ejemplo,
dicho proyecto puede revisarse y actualizarse trimestralmente, al final de cada fase del proyecto y
/ o cuando se alcanzan los 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
planificador del proyecto debe facilitar una sesión de trabajo donde el cronograma para cada
entrega se revisa y actualiza según sea necesario. A medida que se realicen las actualizaciones del
cronograma, el planificador del proyecto debe identificar y anotar cualquier cambio posterior
resultante. Cuando un cambio en el cronograma de un producto entregable afecta negativamente
el programa de otro producto, el proyecto

Pag 8

el gerente y los propietarios de los entregables afectados deben determinar si hay una manera de
mitigar el impacto del cronograma agregando recursos, trasladando recursos del trabajo de menor
prioridad, realizando trabajos en paralelo, etc., a medida que los recursos se reasignan y / o el
cronograma de se modifica uno o más entregables, se debe evaluar el impacto en los entregables
relacionados. Este proceso se repite para todos los entregables hasta que el cronograma se
estabilice (es decir, no se requieren más cambios y los efectos de todos los cambios se han
analizado y acordado). De esta manera, se revisa a fondo todo el cronograma y se acuerdan todas
las actualizaciones. El director del proyecto, los líderes del equipo y las partes interesadas. Una vez
acordado, el cronograma actualizado debe basarse para que el progreso pueda rastrearse contra
el cronograma recién actualizado. La mayoría de las herramientas de programación permiten el
uso de múltiples líneas de base para que no se pierdan los datos de línea de base anteriores. Si
bien este proceso puede requerir varias horas o, en el caso de proyectos grandes, varios días, es
clave para evitar que el cronograma quede desactualizado, proporcionando información errónea o
irrelevante o siendo abandonado por completo. Secreto # 5: Crear y seguir estándares de
programación como Podemos ver en los cuatro "secretos" anteriores, construir 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 cronograma de proyecto
realista y sostenible. Además, los estándares de programación ayudan a garantizar la coherencia
cuando los planificadores son creados por múltiples planificadores y / o gerentes de proyecto. Esto
es particularmente importante cuando una PMO es responsable de supervisar y / o apoyar
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. ¿Qué
es un estándar de programación? En 2007 , PMI lanzó su Estándar de práctica para la
programación. Este estándar se describe en el sitio web de PMI como "un medio cuantificable 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 PMBOK® (PMI, 2008) en" una medición práctica y objetiva
proceso para la programación del proyecto ”. El Estándar de práctica para la programación
proporciona información integral y específica para gerentes y programadores de proyectos y es un
recurso excelente. Sin embargo, en el contexto de este documento, los estándares de
programación se consideran pautas específicas para crear y mantener el proyecto. horarios dentro
de una o varias organizaciones relacionadas. Estas normas 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 cambio de horario, 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 cronogramas desarrollados para proyectos dentro de su esfera de influencia o control. Es
una buena práctica basar los 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. Como
se discutió anteriormente en este documento, los estándares de programación son importantes
por varias razones: contribuyen el desarrollo de cronogramas de proyectos realistas y manejables
ayudan a garantizar la coherencia en la estructura y el nivel de detalle en los cronogramas del
proyecto, ayudan a garantizar que la información reportada pueda compararse y aprovecharse
más fácilmente y ayudan a garantizar la coherencia en el cronograma relacionados con procesos •
(como informes y control de cambios) ¿Por qué utilizar un estándar de programación? El
cumplimiento de los estándares de programación puede ayudar a una organización a aumentar su
tasa de éxito del proyecto y ser más eficiente de las siguientes maneras:

1Los siguientes estándares pueden reducir el tiempo requerido para hacerlo. crear y mantener
cronogramas de proyectos definiendo por adelantado la estructura y el nivel de detalle del
cronograma

2. Los procesos estándar ayudan a facilitar la captura y 2. la aplicación continua de las lecciones
aprendidas

3.los procesos definidos para garantizar el cumplimiento de las normas. contribuir en gran medida
a un entorno en el que los gerentes de proyectos, los programadores de proyectos y otras partes
interesadas reciben información consistente y confiable que se puede usar para mejorar
continuamente el proceso de programación de proyectos y la administración general de proyectos
en toda la organización

4. ayudan a garantizar el éxito del proyecto al facilitar la identificación anticipada de posibles

problemas.

Si bien los estándares son claramente una forma positiva de ayudar a las organizaciones a
aumentar su tasa de éxito general del proyecto, es importante tener en cuenta que los estándares
por sí solos no pueden garantizar un buen cronograma ni el éxito del proyecto. Además, los
estándares específicos no siempre son aplicables en todas las situaciones. Las organizaciones que
desarrollan e implementan estándares de programación deben tener cuidado de crear un entorno
en el que se aliente a los programadores de proyectos y otras partes interesadas a evaluar su
situación y determinar

Pag 9

si el cumplimiento estricto de un estándar específico es la acción más apropiada para una

situación dada. En el caso de que no se siga un estándar, el motivo de la excepción debe
documentarse claramente. Esto no significa que los planificadores de proyectos deban sentir que
pueden tomar decisiones arbitrarias sobre si quieren seguir los estándares. Significa que aquellos
con autoridad en una organización de este tipo nunca deberían perder de vista el hecho de que
han contratado a sus gerentes de proyecto y programadores de proyectos por su conocimiento y
experiencia. Estos expertos deberían ser alentados y recompensados por evaluar cada situación y
tomar la mejor decisión dada la circunstancia. De esta manera, la organización creará una base
que ofrecerá la mejor oportunidad para la coherencia en el éxito del proyecto al tiempo que
fomenta un entorno de aprendizaje, crecimiento personal y organizacional y mejora continua

Usando los cinco secretos de la programación de proyectos

La información presentada hasta ahora es valiosa incluso cuando la utiliza un planificador que
trabaja de forma independiente. Sin embargo, para darse cuenta del valor total de implementar
estos secretos, una organización necesita proporcionar un depósito central de estándares,
herramientas y plantillas disponibles para todos los programadores. De lo contrario, cada
planificador debe "reinventar la rueda" cada vez que se desarrolla un nuevo cronograma. Esto es
claramente ineficiente y no captura el valor del conocimiento y la experiencia combinados que
están presentes en las organizaciones más grandes. Durante la última década más o menos, la
PMO se ha vuelto más común y más importante en muchas organizaciones basadas en proyectos.
La mayoría de las PMO se desarrollan como el punto focal para apoyar, monitorear y, en algunos
casos, administrar muchos proyectos simultáneos que tienen lugar en una variedad de partes de la
organización. Algunas compañías tienen un único PMO con responsabilidad para todas las
actividades del proyecto, mientras que otras compañías tienen un PMO en cada una de sus
diversas unidades de negocio o áreas funcionales. En cualquier caso, la PMO es generalmente
responsable de supervisar y apoyar a los gerentes de proyectos y planificadores de proyectos y, en
algunos casos, a otros miembros del personal y partes interesadas del proyecto.

Este enfoque centralizado para la gestión y supervisión de proyectos proporciona a las

organizaciones una concentración del proyecto.

experiencia en gestión y programación de proyectos que no se encuentra fácilmente en otros

lugares. Este es el entorno perfecto para desarrollar e implementar procesos de programación de
proyectos, estándares, herramientas y programas de capacitación. También proporciona un punto
único para la recopilación y documentación de las mejores prácticas, lecciones aprendidas e
investigación continua. Para garantizar que una organización aproveche al máximo la experiencia
en programación de proyectos dentro de su PMO, un ejecutivo debe patrocinar activamente un
grupo de programación de proyectos o asignarlo a al menos un gerente de programación de
proyectos responsable de evaluar y mejorar los programas y las prácticas de programación de
proyectos en toda la organización. A este gerente de programación se le debe otorgar la autoridad
para definir / adoptar estándares de programación y hacer cumplir su uso. El objetivo principal del
administrador de programación de proyectos y el equipo de programación de la PMO debe ser
identificar e implementar estándares, herramientas, plantillas y programas de capacitación que se
realicen. disponible para todos los gerentes de proyectos y planificadores de toda la organización.
A medida que la PMO crece en madurez y recursos, también puede asumir la responsabilidad de la
función de programación del proyecto. Esto tiene varias ventajas sobre el simple hecho de
proporcionar las herramientas y la orientación a los planificadores de otros grupos: permite a la
PMO controlar las calificaciones específicas • de sus planificadores de proyectos, como la
capacitación, certificaciones, experiencia y conocimiento demostrado de los estándares
específicos de la PMO, mejores prácticas y herramientas. Permite que la PMO aumente el personal
existente en puestos de planificación • de alto nivel, obteniendo así un mayor retorno de sus
inversiones en recursos humanos. Mejora la capacidad de la PMO para fomentar un ambiente •
positivo donde se alienta a los programadores a evaluar cada situación y hacer excepciones
cuando sea apropiado (por supuesto, todas las excepciones deben documentarse
cuidadosamente) y contribuir al crecimiento de la experiencia tanto para los planificadores
individualmente como para la organización en su conjunto

. Facilita la implementación amplia de las lecciones aprendidas y acelera la mejora continua.

Mejora la retención de los empleados al ofrecer oportunidades de carrera profesional y un

ambiente de trabajo positivo.

Pag 10

Cuando una organización reconoce la relación de buenos cronogramas y prácticas de

programación con la tasa de éxito del proyecto, ha dado el primer paso para aumentar su propia
tasa de éxito. Al implementar estándares de programación, proporcionar plantillas de
programación y capacitar a los programadores de proyectos, la PMO puede actuar como un
catalizador clave para mejorar la calidad de los programas de proyectos en una organización. Esto
puede dar a una organización una ventaja estratégica en el competitivo mercado actual, donde las
tasas de éxito más altas de los proyectos a menudo diferencian a las organizaciones exitosas de
aquellas que continúan luchando.

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 una organización.
La mejor manera de aprovechar estos secretos es asegurarse de que cada uno se siga cada vez que
cree un nuevo horario. Esto ayudará a garantizar que sus programaciones contengan los
componentes correctos, sean fáciles de usar y de mantener. Los horarios con estas cualidades
tienen muchas más probabilidades de ser utilizados y actualizados a lo largo de la vida del
proyecto. Además, los informes generados a partir de dichos cronogramas tienen más
probabilidades de proporcionar la información necesaria para la identificación temprana de
riesgos y problemas.

Sin embargo, puede ser difícil utilizar al máximo los secretos de la programación de proyectos sin
el apoyo y la estructura ofrecidos por una PMO u organización centralizada similar. Incluso los
mejores planificadores de proyectos y gerentes de proyectos no pueden construir todo desde cero
al mismo tiempo. Cuando establezca una PMO o implemente las ideas descritas aquí por primera
vez, comience con poco y enfóquese 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 planificadores y los gerentes de proyecto
puedan documentar sus experiencias, almacenar cronogramas que funcionaron bien y crear y
compartir nuevos procesos, herramientas y plantillas. A medida que la organización madura y los
planificadores se vuelven más experimentados, la PMO puede expandirse al proyecto de
capacitación gerentes sobre cómo construir y usar un buen cronograma del proyecto. Cuando
existan recursos suficientes, la PMO podría 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 coherente y ofrezca 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 procesos son críticamente importantes para programar la coherencia, no Todos los estándares o
procesos son la mejor solución en todas las situaciones. En ocasiones, la desviación de un proceso
o estándar establecido puede ser mejor en ciertas circunstancias. Los buenos planificadores de
proyectos son conscientes de que la programación es tanto arte como ciencia y que cada situación
debe evaluarse individualmente. En los casos en que una desviación de los estándares tiene
sentido, los motivos deben documentarse claramente y comunicarse a los afectados. Como
planificadores de proyectos, depende de nosotros trabajar con la gerencia de PMO para ayudarlos
a comprender la importancia de estos "cinco secretos" y tomar el liderazgo 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.

Referencias Proyecto

Instituto de gestión. (2007) Estándar de práctica para la programación. Newtown Square, PA:
Project Management Institute, Project Management Institute. (2008) Una guía para el cuerpo de
conocimiento de gestión de proyectos (guía PMBOK®) (4ª ed.). Newtown Square, PA: Instituto de
Gestión de Proyectos.

Sobre el Autor

La Sra. Michelle Colodzin tiene más de dieciocho años de experiencia en programas de TI y gestión
de proyectos en los sectores público y privado. Estableció y administró el Programa global de
fusiones y adquisiciones de TI para Hewlett-Packard y Agilent Technologies, donde fue
responsable de incorporar las empresas recién adquiridas en la infraestructura de TI y los sistemas
comerciales existentes de estas empresas. Más recientemente, la Sra. Colodzin administró varios
proyectos simultáneos de consolidación y reubicación de centros de datos, y actualmente
participa en la PMO de una de las iniciativas más grandes actualmente en curso en California.

Elaborar un informe para cada lectura con los siguientes entregables:


o Reseña biográfica del autor del texto.
o Objetivo del autor del texto.
o Conceptos principales.
o Opinión frente a los propósitos del curso.
o Bibliografía complementaria consultada (opcional).

Formato: bajo normas APA. Ensayo escrito.

Políticas: Recuerde que no debe copiar los textos, y si toma parte de ellos debe
referenciarlos. Con el fin de respetar los derechos de autor.
No debe superar más de 3 hojas fuera de la de portada. Se debe relacionar la bibliografía,
se puede consultar otros libros que expliquen el tema, fuera de los obligatorios.
Tipo de letra Arial 11 a espacio 1.5