Cómo crear un plan de trabajo para implementaciones de TI?

Transcripción

1 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 herramienta. Introducción En este contexto, un plan de trabajo es un mini 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 tiempo 1, 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 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. 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. Por qué más documentación? 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 meticulosamente, lo cual puede incluir a terceros que no integran el equipo del proyecto. Centro de Conocimiento del PMI Shannon Gaw 1

2 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. 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 Centro de Conocimiento del PMI Shannon Gaw 2

3 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, , 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 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 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. Centro de Conocimiento del PMI Shannon Gaw 3

4 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 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 Centro de Conocimiento del PMI Shannon Gaw 4

5 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 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. Centro de Conocimiento del PMI Shannon Gaw 5

6 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 y se lo puede contactar vía 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 Si tiene alguna sugerencia de mejora de esta traducción al español compártala a LASpanishNews@pmi.org Centro de Conocimiento del PMI Shannon Gaw 6