¿Cómo crear un plan de trabajo  
para implementaciones de TI? 
Por Shannon Gaw, PMP 
“ Los proyectos de Tecnologías de
Información (TI) tienden a
culminar cuando el producto o el
servicio que se crea, pasa a
producción, se reemplaza, se
actualiza, o se modifica. En general,
ello ocurre en eventos muy visibles
y de mucha presión, lo que justifica
usar un ‘plan de trabajo’ como
Introducción
herramienta.
En este contexto, un plan de trabajo es un mini
” ¿Por qué más documentación?
proyecto o un mini enunciado del trabajo (SOW);
que en lugar de enfocarse en el esfuerzo de todo el
proyecto, se enfoca solo en un componente de
éste, el cual está delimitado por el tiempo1, para
producir un entregable o cumplir con un hito. Por
ejemplo, el plan de trabajo puede describir la
transferencia de un sistema al cliente, una
implementación de un firewall, la puesta en
marcha de una nueva versión del software, o la
instalación de un nuevo servidor de bases de datos.
En estos emprendimientos, el tiempo para la
implementación es ajustado, y la naturaleza de las
actividades y su secuenciamiento no se puede
tratar a la ligera. El plan de trabajo actúa como un
guión para actuar y les da a todos los participantes
                                                            
1
 “Time‐box”: en gestión de tiempos, un time‐box le asigna un  meticulosamente, lo cual puede incluir a terceros
período de tiempo fijo a una tarea. La tarea se basa en la duración 
no en el alcance. El cronograma se divide en una serie de 
actividades con un período de tiempo asignado cada una.  
Centro de Conocimiento del PMI | www.PMI.org/latam | © 2010 Shannon Gaw
un lugar central para toda la información y
coordinación relevante. También da un
mecanismo que todos pueden usar para ensayar el
trabajo antes de la hora de inicio, y brinda una
lista de control o checklist a partir de la cual
trabajar una vez que haya comenzado el evento.
La audiencia de esta herramienta es el equipo del
proyecto, o parte del mismo que se encarga de
producir el entregable. También puede incluir a
proveedores que no se habían involucrado antes en
el proyecto y/o a aquellos que tengan un rol
menor.
Uno de los primeros obstáculos que puede
enfrentar un director de proyectos para usar un
plan de trabajo es que su equipo le cuestione (¡o se
queje!) porqué hay que usarlo cuando el proyecto
ya tiene el acta de constitución del proyecto, el
plan del proyecto, el enunciado del trabajo, la
estructura del desglose del trabajo (EDT), y, en
muchos casos, un sistema formal de gestión de
cambios operativos. Afortunadamente, estas son
preguntas que se pueden responder fácilmente.
En el caso del acta de constitución del proyecto,
del plan del proyecto, y del enunciado del trabajo,
estos documentos no brindan los detalles
necesarios y se orientan a una audiencia más
amplia. La EDT puede tener el detalle de los
requisitos pero no de la forma necesaria para
coordinar e implementar el evento
que no integran el equipo del proyecto.
1 

El plan de trabajo puede duplicar algunos de los
ítems que se identificaron y documentaron en las
solicitudes de cambio de un buen proceso de
gestión de cambios, pero a menudo, el plan de
trabajo es más detallado que la solicitud de
cambio. Si bien la solicitud de cambio pretende
dar la información necesaria para que la
organización determine si un cambio está
programado apropiadamente y si cumple con los
criterios generales de éxito, el plan de trabajo
brinda instrucciones precisas. En el caso de
necesitar cambios muy grandes, un buen proceso
de gestión de cambios puede requerir que se cree
no solo una solicitud de cambio a alto nivel sino
también un plan de trabajo. Además, quienes
remiten la solicitud de cambio deberían pensar
muy bien el plan de trabajo, ya sea que lo escriban
o no.
¿Qué es un plan de trabajo?
El documento del plan de trabajo en general se
crea usando un software como un procesador de
textos o una hoja de cálculo. Los software de
proyectos no son la mejor herramienta para esto ya
que son menos tolerantes a usar texto en forma
libre, pero pueden ser una herramienta de dónde
importar una lista de tareas. Si bien el plan se
puede crear en una página web, o dentro de otra
aplicación, idealmente debe ser fácil de modificar e
imprimir. Particularmente en proyectos de
infraestructura, las copias online puede que no
estén disponibles durante una ventana de
implementación.
El plan de trabajo en general no es demasiado
formal ya que su audiencia es el equipo del
proyecto. El autor del plan o el director del
proyecto no deberían preocuparse por su formato
(es decir, su estilo, apariencia, gramática, etc.) a
menos que el plan se dirija a una audiencia mayor.
En algunos casos, el director del proyecto puede
pasarle el plan de trabajo al cliente o al
patrocinador para mostrarles que el equipo está
bien preparado; en estos casos, puede ser necesario
pulir un poco el plan de trabajo.
Centro de Conocimiento del PMI | www.PMI.org/latam | © 2010 Shannon Gaw
Componentes del plan de trabajo
El plan de trabajo no debería contener ninguna
información sobre funciones abstractas de la
dirección de proyectos, como las que existen en el
plan del proyecto o en otros documentos del
mismo, sino que debería contener información
detallada de las tareas. Puede consistir de las
siguientes secciones: introducción, tareas
preparatorias, plan de implementación, plan de
comunicaciones, plan de pruebas, análisis de
riesgos, plan de vuelta atrás, plan de post
implementación, y lista de contactos.
Introducción
La introducción o el cabezal del plan de trabajo
debería capturar la información general como la
que se encuentra en una solicitud de cambio (por
ejemplo, número de control, nombre descriptivo,
objetivo, y líder). También debería listar la
plataforma, la aplicación, y el ambiente que se está
cambiando y afectando, y la ventana durante la
cual se estará fuera de servicio. Esta información se
debería ubicar al inicio del documento para
asegurar que se entiende claramente.
Actividades preparatorias
Las actividades preparatorias documentan todas las
tareas necesarias para lograr la implementación. El
objetivo no es volver a crear la EDT y tratar con
todas las actividades que trajeron al equipo hasta
este punto, sino tratar con las actividades críticas
que deben ocurrir antes de la implementación y
que son el tema del plan de trabajo, las que
podrían incluir por ejemplo:
 Comunicarle a los usuarios afectados cuándo
el sistema estará fuera de servicio
 Verificar los respaldos de los datos, de los
fuentes, de las configuraciones, etc.
 Crear por anticipado los tickets de gestión de
incidentes o casos con los proveedores
 Preparar el equipamiento de reemplazo
 Asegurar que el equipo de Aseguramiento de
la Calidad complete las pruebas y las apruebe
2 

 Informarle a seguridad si se realizarán
actividades fuera del horario de oficina
Cada tarea debería tener un propietario
responsable de asegurar que la tarea se complete y
de informar sobre su estado al resto del equipo del
proyecto.
Plan de implementación
Esta sección detalla las tareas para realizar la
implementación, las cuales son una parte
fundamental del plan de trabajo, y deberían incluir
el detalle suficiente para generar una revisión
crítica así como para dar un mapa de los eventos
necesarios para la implementación.
También aquí cada tarea debería tener un dueño
así como las fechas de inicio y de fin. Esta sección
debería definir la secuencia y la sincronización
entre todas las tareas de todos los participantes, las
cuales se podrían importar del software de gestión
de proyectos.
Plan de comunicaciones
Es muy importante comunicar en el momento
justo, especialmente en aquellos eventos que son
sensibles al tiempo. La sola inclusión de un plan
de comunicaciones, si bien es obvio, enfatizará la
importancia de éste para el equipo de
implementación y definirá qué tan a menudo se
comunicará el equipo y mediante cuáles
mecanismos (por ejemplo, e-mail, chat,
teleconferencia). Las porciones del plan de
comunicaciones se deben integrar apropiadamente
en las tareas de la sección del plan de
implementación. Por ejemplo, un primer paso
típico en un plan de implementación puede ser
avisarle al equipo, al centro de monitoreo, y a otras
partes interesadas, que el trabajo está por
comenzar. Luego de cada tarea importante, el
dueño puede comunicar su éxito vía e-mail o
teleconferencia.
Plan de pruebas
Luego de cualquier cambio, las pruebas son
fundamentales; el director de las aplicaciones del
proyecto sabe muy bien esto, pero a veces, los
gerentes de proyecto de infraestructura minimizan
Centro de Conocimiento del PMI | www.PMI.org/latam | © 2010 Shannon Gaw
su importancia. El plan de pruebas debería listar
las tareas exactas, los resultados esperados, y los
dueños de las pruebas.
Para la puesta en marcha de las aplicaciones, esta
sección se refiere a las pruebas de producción. Si
las pruebas del ciclo de vida del desarrollo del
sistema se detallan en otro documento según la
metodología usada, en esta sección se puede referir
al plan de pruebas de usuario que se haya
documentado en otro lado; de todos modos, las
pruebas y la comunicación de sus resultados se
deberían listar aquí como tareas. Los expertos de
las aplicaciones aprobarán las pruebas o darán sus
opiniones.
Para las implementaciones de infraestructura,
idealmente se debería probar en una máquina de
prueba que sea réplica del entorno de producción,
pero en general no se puede probar realmente la
infraestructura hasta que ésta esté en producción.
El equipo debería ser diligente en armar un plan
de pruebas efectivo y en ejecutarlo completamente.
Análisis de riesgos
Es muy raro que las implementaciones de
tecnología informática ocurran exactamente como
se planificó. Por ello, el equipo del proyecto
debería pasar algún tiempo considerando qué
puede salir mal y cómo responderían a ello si
ocurre, porque seis horas durante un período fuera
de servicio en la noche no es el momento para
formular un “plan B”.
Mediante algún tipo de análisis de riesgos, el
director del proyecto querrá documentar, en una
sección del plan de trabajo, los riesgos que tengan
mayor probabilidad de ocurrir y que tengan una
mayor exposición. En general no se necesita hacer
un análisis de riesgo completo; el autor
probablemente sólo querrá documentar aquello
que dispara los riesgos y cómo se responderá ante
ello (ejemplo, un plan de contingencia). Los
riesgos se pueden tratar en la sección del plan de
implementación o de pruebas luego de la tarea a
que ellos refieren.
El mayor riesgo, y el peor escenario sería que el
plan de implementación no tenga éxito y que por
lo tanto se requiera que el equipo de marcha atrás.
3 

Plan de vuelta atrás
Siempre hay un riesgo, o una combinación de
riesgos, que si ocurren, matarán cualquier chance
de éxito de la actividad que se describió en el plan
de trabajo; por lo tanto, el equipo deberá
considerar, prepararse, y documentar un plan para
volver atrás si las cosas no salen bien.
El objetivo es volver atrás cualquier cambio que se
haya hecho, y retornar el servicio o el producto
que estaba en producción a su estado original, y
luego tratar de realizar la implementación en otro
momento.
Los integrantes del equipo pueden estar nerviosos,
frustrados y cansados cuando pasa esto, por eso es
tan importante que tengan documentado un plan
a seguir sin importar qué tan obvio parezca. El
plan debe identificar un disparador (una métrica u
observación) que indique que se deba tomar una
decisión sobre volver atrás. También debe
identificar a la persona(s) responsable(s) de
interpretar dicho disparador y de tomar dicha
decisión. Este último rol puede asumirlo el líder
técnico, el director del proyecto, o el patrocinador.
Finalmente, si se ejecuta la vuelta atrás, se debería
probar, y el plan debería describir estas pruebas, ya
sea que use un plan de pruebas que se haya
documentado en el plan de trabajo o en otro lado.
Al crear el plan para volver atrás, el equipo necesita
haber pensado en todas las tareas para volver atrás,
y en cuánto demorará para volver al sistema a su
estado original.
Esta duración (incluyendo las pruebas) debería
tener en cuenta la ventana de fuera de servicio que
le pidió el director del proyecto al cliente o a la
autoridad de gestión de cambios. Esto requiere
que se identifique un “punto de no retorno,” o el
punto más tarde en el tiempo en el cual se debe
comenzar el plan de vuelta atrás de modo de
permanecer dentro del período permitido.
El volver atrás seguramente requerirá alguna
preparación física, la cual puede incluir el
respaldar archivos de configuración, exportar
registros de la base de datos, asegurar que el código
fuente está presente en el repositorio de fuentes, y
asegurar que cualquier cambio a las interfaces o a
Centro de Conocimiento del PMI | www.PMI.org/latam | © 2010 Shannon Gaw
otras aplicaciones se pueden volver atrás
simultáneamente. Los ítems como éstos en general
forman parte de los buenos procedimientos de
gestión de la configuración.
Plan de pos-implementación
La percepción del éxito es tan importante como el
éxito real, y los directores de proyecto son
responsables de asegurar que los triunfos técnicos
no se desvanezcan debido a un mal seguimiento y
al no dejar satisfecho al cliente.
Esta sección del plan se usa para documentar todas
las actividades que suavizarán cualquier aspereza
que se perciba de la implementación.
Más allá de cualquier trabajo estupendo que se
haya desempeñado durante la implementación, los
consumidores del servicio esperarán que se opere
de modo totalmente transparente una vez que se
haya terminado la implementación. El director del
proyecto puede definir quién es la persona que
apoyará en los aspectos de transición o que
realizará los controles ante potenciales daños. El
equipo de implementación puede sentir que
merece unas horas para dormir luego de un turno
de 36 horas, por lo que el director del proyecto
debe gestionar las expectativas apropiadamente.
Más allá del apoyo al usuario final, puede haber
otros ítems que son parte importante de este plan
para lo que ocurra luego de la implementación, tal
como monitorear cualquier elemento que pueda
haber sido afectado de forma inesperada por la
implementación, actualizar la gestión de la
configuración de la base de datos, o asegurar que el
nuevo servicio se incluyó en los planes de respaldo
y de recuperación de desastres.
Plan de recursos e información de contacto
Finalmente, el plan de trabajo debería listar todos
los jugadores, sus roles, y su información de
contacto relevante, tal como el teléfono de su
oficina y celular, su correo electrónico, y su
usuario de mensaje instantáneo. Debería también
tener la información de contacto en caso que haya
que escalar la situación, incluyendo a los
proveedores, y cualquier número de caso abierto, e
incluir la información de colaboración tal como
4 

los números de teleconferencia, de sesión de chat,
o las listas de distribución de correos.
Típicamente, el equipo necesitará contactar al
centro de monitoreo de la organización o Atención
a Usuarios para informar sobre la situación, y para
ello también necesitará su información de
contacto.
Se aconseja recopilar los datos de contacto aún si
hay un directorio online, porque, primero,
durante un proyecto de infraestructura, el
directorio online podría no estar disponible, y
segundo, porque muy probablemente, habrá
proveedores externos involucrados de los cuales se
necesitará su información de contacto y ellos
necesitarán la suya.
Plantillas
Para asegurarse de no olvidarse de ninguna sección
o variable requerida, y para hacer que el proceso de
planificación sea más agradable para los
participantes, el director del proyecto puede crear
una plantilla para el documento del plan de
trabajo. Las plantillas son de especial utilidad
cuando el director del proyecto le asigna la
responsabilidad de la planificación y coordinación
a directores de proyecto principiantes o a líderes
técnicos. En algunos casos, un director de
proyectos puede ser responsable ante la oficina de
dirección de proyectos que requiere que se use y
adhiera a ciertos estándares.
Una plantilla también brinda la oportunidad de
que el director del proyecto incluya listas de
control (checklists) y contenido específico de una
organización o que sea consistente a través de cada
proyecto o actividad de cambio. Por ejemplo, cada
implementación podría requerir una entrada en el
sistema de gestión de cambios, una notación en la
gestión de la configuración de la base de datos, un
agregado en la rutina de respaldos, o una
aprobación del gerente de cuenta.
Las plantillas deben ser documentos vivientes. A
medida que pasa el tiempo, el director del
proyecto seguramente descubrirá ítems que habría
que incluir, refinar, o eliminar para mejorar la
efectividad del plan de trabajo. A medida que
evoluciona el ambiente técnico, o que se
Centro de Conocimiento del PMI | www.PMI.org/latam | © 2010 Shannon Gaw
reestructura la organización, las plantillas
seguramente necesitarán reflejar dichos cambios.
Reuniones sobre el plan de trabajo
Dependiendo de la naturaleza del evento de
implementación, el director del proyecto podría
querer tener una o varias reuniones sobre el plan
de trabajo.
En general, el director del proyecto o el líder,
reunirá a un grupo pequeño para formular la
columna vertebral del plan, y tendrá una reunión
más grande para recabar comentarios más
detallados, y luego mantendrá una reunión final
antes del evento para asegurar que todos entienden
su responsabilidad en relación al mismo.
El equipo seguramente encontrará de mucha
utilidad tanto el esfuerzo realizado para identificar
y discutir el material incluido en el plan de trabajo
como el realizar luego una revisión grupal de la
información recabada.
A menudo, el conocimiento que se crea y que se
comparte en este emprendimiento es lo que hace
que una implementación sea exitosa.
El director del proyecto o el líder debería asistir a
una reunión de gestión de cambio para representar
la actividad y solicitar la aprobación dentro de la
organización de TI. Dependiendo de la naturaleza
de la implementación, el director del proyecto o el
líder podría reunirse con los clientes o aquellos
directamente afectados por el cambio para
prepararlos adecuadamente.
Finalmente, el director del proyecto o el líder
podrían tener una reunión de análisis luego de la
implementación. Aquí, el equipo puede revisar el
plan de trabajo para determinar si todas las tareas
se ejecutaron satisfactoriamente. También puede
documentar cualquier asunto pendiente y asignar
las responsabilidades para su resolución. Esta
reunión también puede dar retroalimentación para
la base de conocimiento de lecciones aprendidas
del proyecto.
5 
  
 

El plan de trabajo como herramienta  

crítica para dirigir el proyecto  

El plan de trabajo es una herramienta efectiva que
 
se usa para ayudar a gestionar la ejecución de
implementaciones complejas de TI dentro de un  
límite de tiempo restringido. Este artículo revisó
las razones para contar con un plan de trabajo, su  
naturaleza física, su composición, y los procesos
 
involucrados en su utilización. Si bien el plan de
trabajo puede referir solamente a un ítem del plan  
del proyecto o del enunciado del trabajo, y puede
no tener la audiencia o la visibilidad que tienen  

algunos otros documentos del proyecto, puede  

contribuir a lograr o no lograr el éxito de cumplir
con un hito del proyecto.  

Sobre el autor
Shannon Gaw, PMP, MBA, es gerente de TI en
Estados Unidos. Su blog está en http://itmgr.org y
se lo puede contactar vía e-mail en inglés a
shannon@gawsystems.com.
Artículo traducido del original en inglés titulado “Creating Work 
Plans for IT Implementations” en la Biblioteca Virtual del PMI (PMI 
Virtual Library) de www.PMI.org 
Si tiene alguna sugerencia de mejora de esta traducción al español 
compártala a LASpanishNews@pmi.org 

Centro de Conocimiento del PMI | www.PMI.org/latam | © 2010 Shannon Gaw 6