Los proyectos de TI fallan con más frecuencia que cualquier otro tipo; normalmente, porque el alcance no está claro, se pasan por alto dependencias o la comunicación es débil. Con Trupeer, puedes ahorrar horas en la planificación empezando con una plantilla gratuita de plan de proyecto de TI, personalizándola con tu identidad de marca y convirtiendo el plan en actualizaciones en vídeo que mantienen alineados a los responsables técnicos y del negocio.

Qué es un plan de proyecto de TI y por qué las plantillas genéricas se quedan cortas

Un plan de proyecto es el documento que indica qué se entregará, para cuándo, por quién y qué tiene que ser cierto para que eso ocurra. Cada plantilla que se posiciona para esta búsqueda te dará eso, normalmente como una lista de tareas con fechas de inicio, fechas de finalización, responsables y una barra de Gantt.

La lista de tareas no es el problema. El problema es el orden en el que la completas.

Las plantillas genéricas empiezan por tu trabajo. Enumera las tareas, estima las duraciones, ordénalas, añade responsables y la fecha de finalización queda al final. Las dependencias se añaden después, en una columna, como una nota.

Los proyectos de TI rara vez se retrasan porque esas estimaciones fueran incorrectas. Se retrasan porque llega algo que nunca estuvo en el plan y con lo que no se puede discutir: un congelamiento de cambios que cubre la semana de puesta en marcha, una revisión de seguridad con una cola de seis semanas, un proveedor cuyos consultores de implementación están reservados hasta el final del trimestre, una licencia que se renueva antes de que esté lista la sustituta, una auditoría que bloquea el entorno durante un mes.

Ninguna de esas cosas son riesgos. Un riesgo es algo que podría ocurrir. Estas ya son ciertas el día que empiezas a planificar, y cada una de ellas se puede conocer en la primera semana si alguien pregunta.

Así que esta plantilla invierte el orden. Primero dibujas las fechas que no puedes mover. Luego descubres qué tan amplio es realmente el margen restante. Después programas el trabajo dentro de ese margen. La lista de tareas sigue existiendo, solo deja de ser lo primero que escribes.

Cómo personalizar esta plantilla en Trupeer

Paso 1: Abre la sección Plantillas

Ve a la sección Plantillas desde la navegación principal.

Paso 2: Selecciona y abre una plantilla

Haz clic en cualquier plantilla con la que quieras trabajar para abrirla.

Paso 3: Amplía la vista de la plantilla

Si es necesario, amplía la vista de la plantilla para ver el diseño completo y los detalles con claridad.

Paso 4: Edita la plantilla

Haz clic en Editar para empezar a modificar la plantilla seleccionada.

Dentro del editor, puedes:

• Añadir nuevas secciones

• Definir o actualizar reglas de formato

• Añadir un logotipo y ajustar su posición y la configuración relacionada

Paso 5: Guarda tu plantilla personalizada

Después de realizar todos los cambios necesarios, haz clic en Guardar para almacenar la plantilla actualizada como tuya.

Paso 6: Previsualiza y ajusta la plantilla

Cuando quieras ver cómo se ve tu plantilla personalizada, abre la Previsualización.

Desde la pantalla de previsualización, puedes seguir haciendo ajustes directamente si es necesario, asegurando que la plantilla aparezca exactamente como la quieres.

Con una plantilla de plan de proyecto de TI puedes:

• Ahorra horas en la planificación: Omite la página en blanco con una estructura creada para iniciativas de TI.

• Gestiona la complejidad técnica: Secciones integradas para arquitectura, dependencias y riesgos.

• Mantén la coherencia con tu marca: Aplica tu logotipo, tipografías y colores usando el kit de marca de Trupeer.

• Alinea negocio y TI: Convierte los planes técnicos en actualizaciones en vídeo que los responsables del negocio pueden entender.

• Estandariza en todos los proyectos: Usa la misma plantilla para cada iniciativa de TI.

• Llega a equipos globales: Traduce planes y actualizaciones a 65+ idiomas con un solo clic.

Las inamovibles y dónde encontrarlas

Una inamovible es cualquier fecha o duración establecida por alguien que no depende del proyecto. No puedes negociarla dentro del proyecto, y descubrirla tarde la convierte de una restricción en una crisis.

Aquí tienes el inventario para ejecutar en la primera semana. Haz a cada responsable dos preguntas: ¿cuál es tu fecha y cuál es tu tiempo de entrega?

Dos de estas inamovibles merecen una atención especial porque son las que más a menudo se pasan por alto. Los periodos de preaviso en los contratos son fechas inamovibles que se sitúan antes de la fecha de renovación; eso significa que el plazo real es anterior al que aparece en la agenda. Y la calidad de los datos en el sistema de origen es la única inamovible cuyo tamaño no puedes consultar. Tienes que ir a medirla, por eso perfilar los datos de origen corresponde a la primera semana, en lugar de la fase de migración.

Dibuja estas inamovibles en un único calendario antes de estimar cualquier cosa. Lo que buscas es la forma del hueco. Muy a menudo, el hueco es mucho más estrecho que la duración del proyecto, y la conversación honesta sobre el alcance ocurre en la semana dos, en lugar del mes siete.

Qué va en el plan

Una vez dibujadas las inamovibles, el propio plan tiene doce secciones. Copia los encabezados, complétalos en este orden.

1. Resumen. Una frase: qué cambia, para quién y qué deja de ser cierto después.

2. Resultado y criterios de éxito. Medibles y con fecha. Incluye al menos un criterio sobre lo que se sustituye; por ejemplo, que el sistema heredado no tiene tráfico ni coste de licencia para una fecha determinada. Los planes que terminan en la puesta en marcha son la forma en que las empresas acaban pagando por dos sistemas.

3. Calendario de restricciones. La tabla de inamovibles de arriba, completada, con el margen de entrega resultante indicado como un rango de fechas en palabras sencillas.

4. Alcance. Tres listas: dentro, fuera y aplazado. La lista aplazada es la útil, porque es donde va el alcance cuando se recorta, y evita que la misma conversación ocurra cuatro veces.

5. Fases y hitos. Los hitos son eventos con una respuesta observable; por ejemplo, "revisión de seguridad superada" o "primer establecimiento en funcionamiento", no "fase de diseño completada".

6. Desglose del trabajo. Tareas, responsables, estimaciones, secuencia. Esta es la parte con la que empiezan todas las demás plantillas.

7. Dependencias. Separa las internas de las externas. Cada dependencia externa debe tener una persona con nombre en la otra organización y una fecha con la que se hayan comprometido, no una fecha que hayas asumido.

8. Entornos y datos. Qué entornos existen, qué datos hay en cada uno, cómo se protege la información de producción en las pruebas y el resultado del perfilado de datos de origen.

9. Cambio (cutover) y reversión (rollback). La secuencia hora por hora para el cambio, el punto de decisión en el que te detienes, quién toma esa decisión y cómo vuelves atrás. Escríbelo como un procedimiento ejecutable, que es donde encaja una plantilla de método de procedimiento.

10. Riesgos con desencadenantes. No es una matriz de probabilidad e impacto. Cada riesgo incluye un desencadenante observable y la acción que se activa cuando se detecta el desencadenante. "El consultor del proveedor no está confirmado para el 12 de mayo" es un desencadenante. "El proveedor podría llegar tarde" no lo es.

11. Comunicaciones, formación y adopción. Quién recibe qué información y cuándo, y qué se espera que los usuarios puedan hacer el día uno.

12. Gobernanza y cierre. Quién decide, quién escala, cómo se ve un registro de decisiones y las condiciones bajo las cuales el proyecto se declara finalizado y se entrega para su operación.

Un ejemplo desarrollado y lo que costó

Ashmore Retail, ochenta y cuatro tiendas y tres centros de distribución, se puso en marcha en febrero para sustituir el sistema de gestión de almacenes en los tres centros de distribución. Nueve meses de trabajo, con la puesta en marcha prevista para mediados de noviembre, descrita en el deck de arranque como una llegada cómoda antes del pico.

En el día de ese arranque existían dos inamovibles. Ambas estaban publicadas. Ninguna estaba en el plan.

La primera era el congelamiento de cambios. Las operaciones de retail lo publican cada enero y se ejecuta del 1 de noviembre al 15 de enero, cubriendo el pico de actividad comercial. No se introduce ningún cambio de producción de ningún tipo durante esas once semanas.

La segunda era el contrato heredado. Se renovó el 31 de diciembre por doce meses más, por ciento ochenta y seis mil libras, con un preaviso de noventa días, lo que situó el plazo real en el 2 de octubre.

El proyecto siguió el plan durante la primavera. La revisión de seguridad tardó cuatro semanas frente a un SLA indicado de dos. Los consultores de implementación del proveedor no estuvieron disponibles hasta octubre, porque se les había pedido en julio. Ambos retrasos se absorbieron pasando la puesta en marcha de mediados de noviembre a finales de noviembre, algo que nadie señaló porque nadie estaba mirando el calendario de congelamiento.

El congelamiento salió a la luz en una reunión del change advisory board a principios de septiembre. La puesta en marcha en noviembre no era posible y se abrió la siguiente ventana viable el 16 de enero.

Eso dejó una decisión que tomar antes del 2 de octubre. Dar preaviso en el contrato heredado y operar desde el 1 de enero sin soporte en el sistema del que dependía todo el negocio, o dejar que se renueve y pagar un año de un sistema que habían planeado apagar en noviembre.

Lo dejaron renovarse. El nuevo sistema entró en funcionamiento el 4 de marzo. El contrato heredado se utilizó durante nueve semanas de sus cincuenta y dos semanas, lo que equivale a unos treinta y dos mil libras de valor frente a una factura de ciento ochenta y seis mil libras. Aproximadamente ciento cincuenta y cuatro mil libras no compraron nada.

Lo instructivo es que el proyecto nunca se retrasó en el sentido en que la gente suele decir “tarde”. El trabajo se hizo con un estándar razonable y a un ritmo razonable. Lo que salió mal es que la ventana era seis semanas más estrecha de lo que nadie había dibujado, y las dos fechas que la definían llevaban en un calendario publicado y en un contrato firmado desde antes de que existiera el proyecto.

Si el calendario de restricciones se hubiera dibujado en febrero, la secuencia habría sido evidente. Puesta en marcha antes del 1 de noviembre, trabajando hacia atrás a través de una revisión de seguridad de cuatro semanas que en realidad eran seis, una ruta de adquisición de seis semanas y consultores que necesitaban un trimestre de preaviso, significaba que el contrato con el proveedor tenía que firmarse a mediados de abril. Se firmó en julio. El proyecto no necesitaba ir más rápido. Necesitaba empezar sus dependencias inamovibles once semanas antes.

Cinco tipos de proyecto de TI y qué secciones soportan el peso

En esta búsqueda son comunes las listas de veinte plantillas de proyectos de TI, que cubren desde la implementación de ITSM hasta mejoras de infraestructura y el establecimiento de un PMO. En la práctica, se reducen a cinco formas, y la forma te indica qué secciones de arriba merecen el detalle.

Sustitución. Cambiar un sistema en funcionamiento por otro. Incluye WMS, ERP, herramientas de ITSM, plataformas de mesa de ayuda y sistemas de RR. HH. Las secciones 3, 9 y 2 soportan el peso, porque lo difícil es la ventana, el cambio (cutover) y demostrar que lo antiguo realmente está apagado.

Implementación. Algo nuevo sin predecesor. Incluye gestión de SLA, programas de gobernanza y cumplimiento de TI, gestión de activos y gestión del conocimiento. Las secciones 11 y 2 soportan el peso, porque no se rompió nada antes, así que la adopción es lo único que lo hace real. Nuestro guía de implementación de adopción digital profundiza en esto.

Migración o actualización en el mismo lugar. Mismo sistema, nueva versión, nuevo host o nueva región. Incluye virtualización, consolidación, migración a la nube y actualizaciones de base de datos. Las secciones 8 y 9 soportan el peso, porque la reversión (rollback) es el juego completo.

Construcción. Desarrollo de software y automatización de procesos. La sección 4 soporta el peso, porque el alcance es la variable que se mueve y los criterios de aceptación son lo que impide que se mueva en silencio.

Programa y aseguramiento. Establecimiento de PMO, auditorías de TI, gestión de cartera, gestión de riesgos, cumplimiento de seguridad. La sección 12 soporta el peso, porque el entregable es evidencia y visto bueno, más que un sistema en funcionamiento, y los hitos son fechas de revisión establecidas por otra persona.

Si tu proyecto no encaja claramente en una de estas categorías, normalmente son dos proyectos a los que se les ha dado un solo nombre.

Construir el plan en un día

Por la mañana, dibuja las inamovibles. Envía las dos preguntas a cada responsable en la tabla, persigue primero las respuestas del proveedor y de seguridad porque son las que tienen colas más largas, y pon todas las fechas que te devuelvan en un solo calendario. Indica la ventana resultante en una frase.

Por la tarde, escribe las secciones 1, 2 y 4, y luego los hitos. Deja el desglose detallado del trabajo para que el equipo de entrega lo complete durante la semana. Un plan es útil en el momento en que se acuerdan la ventana y el alcance, y no es más útil por tener cuatrocientas filas.

Revísalo frente a la ventana en cada reunión de gobernanza. La única pregunta que merece la pena hacer no es “¿vamos según lo previsto?” sino “¿se ha movido alguna inamovible?”. Los congelamientos se amplían, las auditorías se reprograman y los proveedores pierden consultores. Estos cambios reconfiguran el plan de una forma que una tarea retrasada nunca logra.

Qué dejar fuera

Un diagrama de Gantt de cada tarea no pertenece en el documento del plan. Pertenece en la herramienta con la que programas, y duplicarlo en un documento crea dos versiones que no coinciden en el plazo de un par de semanas.

Un registro completo de riesgos con puntuaciones tampoco pertenece aquí. Mantén los riesgos que tienen desencadenantes y fechas, y pon el resto en el registro.

Los procedimientos detallados sobre cómo se realiza el trabajo pertenecen en un IT SOP, y la descripción de lo que has construido pertenece en IT documentation, no en el plan. La entrega al equipo de operación merece planificarse bien, para eso sirve un knowledge transfer SOP.

Cuándo dejar de usar un documento y usar software

Un documento es el contenedor adecuado mientras se debate el plan, que es la mayor parte del primer mes. Deja de ser el contenedor adecuado cuando se cumplen tres cosas a la vez: más de unas treinta tareas están en marcha, más de cuatro personas actualizan el estado y las dependencias entre tareas empiezan a cambiar semanalmente.

En ese punto, pasa el desglose del trabajo a un software de planificación y conserva el documento para las secciones 1 a 5 y 12, que son las partes que leen las personas que nunca abrirán la herramienta. El documento contiene el acuerdo. La herramienta contiene el calendario.

Convertir el plan en algo que el equipo de entrega realmente siga

El plan se lee en el arranque y en la reunión de dirección. El runbook de cambio (cutover) lo lee a las dos de la mañana alguien que no estuvo en ninguna de las dos.

Trupeer AI convierte una grabación de pantalla en un proceso documentado, de modo que los pasos de cambio en la sección 9 y las tareas del día uno en la sección 11 se convierten en recorridos de tus sistemas reales en lugar de párrafos que los describen. Registra la secuencia una vez y obtienes una guía paso a paso, un vídeo y un documento en tu base de conocimiento, con tu propia marca.

Regístralo. Ponle marca. Tradúcelo. Trupeer it.

Para el trabajo de adopción en la sección 11, change management y training videos cubren el lado del despliegue, y documentation mantiene el plan, el runbook y el material de entrega juntos. Las instrucciones de configuración están en la document template setup guide.

Preguntas frecuentes

¿Hay una plantilla gratuita de plan de proyecto de TI en Excel?

No como archivo por nuestra parte, y merece la pena ser directos con el intercambio. Excel es realmente el contenedor mejor para el desglose del trabajo en la sección 6, porque las fechas, las dependencias y los resúmenes pertenecen a las celdas. Crea esa hoja tú mismo con columnas para tarea, responsable, inicio, fin, dependencia, estado y marca de inamovible. Mantén las secciones 1 a 5, 9 y 12 como documento, porque se debaten en prosa y nadie negocia el alcance en una hoja de cálculo.

¿Hay una versión para Word o una descarga gratuita de Word?

La estructura de doce secciones de arriba está escrita para copiarse directamente en Word o Google Docs. Pega los encabezados, conserva la numeración y complétalos en el orden indicado. No hay descarga restringida, lo que también significa que no hay un formulario entre tú y la estructura.

¿Hay una versión en PDF?

Pega las secciones en tu editor y exporta a PDF cuando el plan esté acordado. Un plan merece congelarse como PDF en el punto en que se aprueba, y merece conservarse editable antes de eso, así que exportar tu propia copia en el momento adecuado es mejor que empezar desde un archivo fijo.

¿Hay una versión en PPT para el deck de arranque?

El deck es un documento diferente con un trabajo diferente. Seis diapositivas suelen ser lo correcto: el resultado, la ventana de entrega desde tu calendario de restricciones, el alcance dentro y fuera, los hitos, las dependencias externas con nombre y quién decide qué. No pongas el desglose del trabajo en el deck. Nadie lee una barra de Gantt en un proyector.

¿Puedo descargarlo gratis?

La estructura, la tabla de inamovibles y el ejemplo desarrollado son gratuitos y sin restricciones. Úsalos, edítalos y ponlos en tu propia biblioteca de plantillas con tu propio nombre.

¿Un plan de entrega de proyecto es lo mismo que un plan de proyecto?

Bastante cerca como para que la distinción rara vez merezca la pena. Cuando las organizaciones los separan, el plan de proyecto cubre toda la vida del proyecto, incluido el business case y el cierre, y el plan de entrega cubre solo la parte de construcción y lanzamiento. Si tu gobernanza pide ambos, escribe el plan de arriba y trata las secciones 5 a 9 como el plan de entrega.

¿Necesito también una plantilla de informe de gestión de proyectos por separado?

Sí, y mantenla mucho más corta de lo que esperas. Un informe de estado que repite el plan se ignora en el plazo de un mes. Informa de cuatro cosas: ¿se ha movido alguna inamovible?, ¿la ventana sigue siendo lo bastante amplia?, ¿qué decisión necesitas de este grupo hoy? y ¿qué se activó de la lista de riesgos desde la última vez?

¿Qué nivel de detalle debe tener un plan de proyecto de TI?

El suficiente para que un nuevo integrante pueda entender qué ocurre a continuación y nada más. En la práctica, el documento del plan tiene unas ocho a quince páginas para un proyecto de nueve meses, la mayor parte de las cuales son las secciones 8 y 9. Si el documento es más largo que el runbook de cambio, el equilibrio es incorrecto.

¿Con qué frecuencia se debe actualizar el plan?

Las secciones 6 y 7 cambian semanalmente y pertenecen donde ya trabaja tu equipo. Las secciones 1 a 5 deberían cambiar raramente, y cada cambio en ellas es una decisión que alguien tiene que aprobar. Si tu sección de alcance se edita en silencio cada semana, no tienes un plan: tienes un diario.