Planificar un proyecto informático es la clave para evitar desviaciones (sobre todo en cuanto a presupuesto, plazos y calidad). Sigue estos pasos clave para empezar con buen pie.

Una planificación sólida no significa “hacer un calendario”: significa alinee interesados, defina lo que se entrega, organizar trabajo y maestro riesgos.

1. Definir los objetivos del proyecto

Objetivo

Aclare por qué hacemos el proyecto, para quiény cómo medimos el éxito.

Buenas prácticas

• Formular objetivos SMART : Específicos, mensurables, alcanzables, realistas y sujetos a plazos..
• Añadir KPI y criterios de aceptación desde el principio (de lo contrario, “acabado” se convierte en algo subjetivo).
• Distinguir :
  • Objetivos empresariales (valor) frente a objetivos técnicos (medios)
  • Imprescindible vs Bonito de tener

Cifras/parámetros

• Limítese a De 3 a 5 objetivos SMART máximo: más allá, la priorización se diluye.
• Definir De 2 a 4 KPI (demasiados KPI = ninguna gestión).

Ejemplo de objetivo SMART

“ Reducir el tiempo de tramitación de las solicitudes posventa en 48 h a 24 h por 30/06, implantando un portal de tickets y una base de conocimientos, con un índice de satisfacción de los usuarios ≥ 1,5 millones de euros. 4/5.”

Resultados previstos

• Nota de antecedentes (1-2 páginas): contexto, objetivos SMART, KPI, alcance, hitos.
• Definición de Hecho / criterios de aceptación (incluso en modo ciclo V).

2. Identificar a las partes interesadas

Objetivo

Evitar cuellos de botella: ¿quién decide, quién valida, quién ejecuta, a quién afecta?

Buenas prácticas

• Cartografía de las partes interesadas: Patrocinador / Propietario / Usuarios / TI / Seguridad / Legal / Operaciones / Soporte / Proveedores.
• Utilice un Matriz RACI para cada entregable clave (especificaciones, pruebas, lanzamiento de la producción, etc.).
• Anticipar la gestión del cambio : ¿quién pierde qué? ¿quién gana qué?

Cifras/parámetros

• 1 patrocinador claramente identificados (y disponibles): de lo contrario, el arbitraje es imposible.
• 1 decisión = 1 decisor (de lo contrario, consenso infinito).
• Visite al menos 1 representante de los usuarios por perfil principal (por ejemplo, back office + front office).

Ejemplo de RACI (extracto)

• R (Responsable): Gestor de proyectos informáticos
• A (Responsable) : Patrocinador comercial
• C CISO, DPO, Operaciones, Compras
• I Apoyo, equipos afectados

Resultados previstos

• Mapa de las partes interesadas (influencia/impacto)
• RACI + lista de comités (funciones, frecuencia, normas de arbitraje)

3. Elaboración de pliegos de condiciones

Objetivo

Definir qué está incluido / excluido, requisitos, limitaciones y criterios de validación.

Buenas prácticas

• Estructura recomendada :
  1. Antecedentes y objetivos
  2. Perímetro (IN/OUT)
  3. Requisitos funcionales (historias de usuario o especificaciones)
  4. Requisitos no funcionales (perf, seguridad, SLA, accesibilidad)
  5. Limitaciones (SI, reglamentarias, presupuestarias, de planificación)
  6. Datos e interfaces (API, flujos, formatos)
  7. Estrategia de pruebas y aceptación
  8. Despliegue y asistencia
• Formalización de supuestos y dependencias (a menudo olvidado).
• Definir ahora cómo gestionar la solicitud de cambio (de lo contrario, se desplaza).

Cifras/parámetros

• Objetivo De 10 a 25 requisitos funcionales bien escrito en lugar de 80 borrosos.
• Añadir De 5 a 10 requisitos no funcionales mínimo (seguridad, disponibilidad, copia de seguridad, RTO/RPO, rendimiento, auditoría, etc.).
• Para reducir la ambigüedad: cada requisito debe ser comprobable (criterios de receta).

Ejemplo

“El usuario puede crear un ticket ≤ 2 minutos, con accesorios de hasta 10 Mb, y recibe un correo electrónico de confirmación en menos de 60 segundos.”

Resultados previstos

• Pliego de condiciones validado
• Normas de gestión del perímetro (proceso de solicitud de cambios)

4. Planificar recursos y plazos

Objetivo

Transformar la necesidad en plan ejecutable Tareas, cargas de trabajo, dependencias, hitos.

Buenas prácticas

• Cortar en EDT (Estructura de desglose del trabajo): lotes → sublotes → tareas.
• Estimación mediante métodos sencillos :
  • 3 puntos Optimista / Probable / Pesimista
  • Programa de póquer (Ágil) o PERT (si desea afinar)
• Identificar los camino crítico (tareas que desplazan la fecha final).
• Dedique tiempo a lo que a menudo se olvida: pruebas, aceptación, corrección, documentación, asistencia, despliegue, ejecución.

Cifras útiles

• Desgloses típicos (puntos de referencia) :
  • Desarrollo/parametrización : 40-60 %
  • Pruebas + corrección : 20-35 %
  • Receta comercial : 10-20 %
  • Despliegue y gestión del cambio : 10-20 %
• Plan a búfer :
  • Proyecto conocido / bajo riesgo : 10 %
  • Proyecto multiequipo / dependencias : 15 %
  • Proyecto innovador/incierto : 20 %

Ejemplo de miniplanificación

Proyecto “Portal de entradas” - 8 semanas

• S1: encuadre + talleres (2-3 talleres de 2 h)
• S2-S4: construcción (sprints o lotes)
• S5: pruebas del sistema + correcciones
• S6: receta empresarial (escenarios + PV)
• S7: preparación para el despliegue + formación (sesiones 1 h)
• S8: puesta en marcha de la producción + hipercuidado (5 días)

Resultados previstos

• Planificación (Gantt / hoja de ruta / plan de lanzamiento)
• Plan de carga de trabajo (quién hace qué, cuándo)
• Hitos + criterios de aprobación (Go/No-Go)

5. Evaluación de riesgos

Objetivo

Anticipa los obstáculos y evita el modo bombero.

Buenas prácticas

• Mantenga un Registro RAID Riesgos, hipótesis, problemas, dependencias.
• Mediante una matriz simple Probabilidad (1-5) x Impacto (1-5) = puntuación (1-25).
• Para cada riesgo : prevención + plan B + propietario + fecha de revisión.

Cifras/parámetros

• En un proyecto estándar, el objetivo es De 10 a 20 riesgos identificado con el encuadre (sí, es normal).
• Revisión de riesgos semanal como un equipo, mensualmente en comisión.

Ejemplos de riesgos y contramedidas

• Riesgo dependencia de un PLC externo inestable
  • Prevención: pruebas de carga + SLA contractual
  • Plan B: caché / modo degradado
• Riesgo insuficiente disponibilidad comercial para la receta
  • Prevención: reserve sus franjas horarias desde la fase de planificación
  • Plan B: Receta por “usuarios clave” + escenarios prioritarios

Resultados previstos

• Registro de riesgos (puntuación, responsable, plan de acción)
• Plan de continuidad / despliegue gradual en caso necesario

6. Establecer un seguimiento regular

Objetivo

Mantenga el control y detecte a tiempo: «cuanto antes lo vea, menos le costará».

Buenas prácticas

• Establecer una rutina de dirección :
  • Actualización semanal del proyecto (30-45 min): avances, riesgos, decisiones
  • Diario (15 min) si el equipo de desarrollo está dedicado (Agile)
  • Comité de Dirección (cada 2-4 semanas): arbitraje, presupuesto, planificación
• Controla 4 indicadores sencillos:
  • Progreso (entregas completadas frente a las previstas)
  • Calidad (defectos, tasa de éxito de las pruebas)
  • Plazos (desfases y camino crítico)
  • Riesgos (puntuación total, nuevos riesgos, cuestiones pendientes)

Cifras/parámetros

• 1 informe (CR) en ≤ 24 h después de cada reunión de comisión.
• Un salpicadero 1 página (no una novela): legible por un padrino en 2 minutos.

Ejemplo concreto de “cuadro de mandos de 1 página”.”

• Estado general: 🟢/🟠/🔴
• 3 momentos destacados de la semana
• 3 grandes riesgos + planes
• Decisiones esperadas del promotor (con fecha límite)
• Próximo hito + criterios

Resultados previstos

• Informes + plan de acción (quién/qué/cuándo)
• Cuadro de mandos del proyecto
• Informe de recepción + Go/No-Go