Project Management · Linux Foundation Certified IT Associate

Gestión de proyectos de TI

Resumen

La gestión de proyectos aplica conocimientos, habilidades, herramientas y técnicas para alcanzar los objetivos de un esfuerzo temporal. Un proyecto produce un resultado único; una operación es un proceso repetitivo que mantiene el negocio en marcha. En TI, los proyectos entregan sistemas, migraciones, integraciones o cambios de infraestructura con fecha, presupuesto y criterios de aceptación.

Esta guía es material de estudio independiente; no tiene afiliación ni aval de Linux Foundation ni del Project Management Institute (PMI).

Objetivos de aprendizaje

Distinguir un proyecto de una operación y reconocer sus restricciones.
Describir las fases del ciclo de vida y el propósito de cada una.
Explicar la planificación de alcance, cronograma, costo y calidad.
Identificar riesgos, interesados y el control de cambios.
Comparar enfoques predictivos, ágiles e híbridos.

Prerrequisitos y conexiones

No se requiere experiencia previa en gestión. Ayuda comprender cómo se construye y despliega software, cubierto en devops-basics. El topic se conecta con software-architecture, porque las decisiones estructurales condicionan el esfuerzo y el riesgo, y con functional-analysis, que produce los requisitos que delimitan el alcance.

Del proyecto al ciclo de vida

Un proyecto es temporal: tiene inicio y final definidos, aunque el producto resultante dure años. Es único y se elabora de forma progresiva, con detalle creciente a medida que se reduce la incertidumbre. El éxito no depende solo de entregar a tiempo; importan el alcance acordado, el presupuesto, la calidad y la satisfacción de los interesados.

La restricción triple relaciona alcance, tiempo y costo. Ampliar el alcance sin más tiempo ni dinero obliga a sacrificar calidad o asumir riesgo; reducir el plazo puede exigir recortar alcance o sumar recursos. Es una herramienta para razonar sobre compensaciones, no una ley física. La calidad atraviesa las tres dimensiones y no debería tratarse como una variable libre.

El ciclo de vida agrupa el trabajo en fases. En la iniciación se define la necesidad, se evalúa el caso de negocio y se autoriza el proyecto. En la planificación se detallan alcance, entregables, cronograma, costos, riesgos y comunicación. La ejecución produce los entregables; la monitorización y el control comparan el desempeño real con la línea base. El cierre formaliza la aceptación, transfiere el resultado y archiva la información. Un hito marca un logro; una compuerta de fase decide si el proyecto continúa o se cancela.

Planificación del alcance, tiempo y costo

El alcance describe qué está incluido y qué queda fuera. Un enunciado claro evita interpretaciones divergentes y sirve de base para la aceptación. Los requisitos se descomponen en una estructura de desglose del trabajo (EDT o WBS), que divide el entregable en paquetes manejables. Cada paquete debe poder estimarse, asignarse y verificarse; la EDT no es un organigrama ni una lista de tareas sin relación con entregables.

El cronograma parte de actividades, dependencias y duraciones estimadas. La ruta crítica es la secuencia más larga de actividades dependientes y determina la duración mínima; un retraso en ella traslada la fecha de fin, salvo que se comprima el cronograma. Comprimir puede implicar añadir recursos (crashing), con mayor costo, o solapar actividades (fast tracking), con mayor riesgo de retrabajo. Los costos se estiman por paquete y se consolidan en un presupuesto con contingencia para riesgos identificados. La línea base integra alcance, cronograma y costo aprobados; cambiarla exige control formal.

Riesgos, interesados y control de cambios

Un riesgo es un evento incierto que, si ocurre, afecta objetivos; puede ser una amenaza o una oportunidad. La identificación produce un registro con causa, evento, impacto, probabilidad, propietario y respuesta. El análisis cualitativo prioriza por probabilidad e impacto; el cuantitativo modela efectos sobre costo o plazo cuando aporta valor.

Las respuestas a amenazas incluyen evitar, mitigar, transferir y aceptar. Para oportunidades existen explotar, mejorar, compartir y aceptar. Un riesgo aceptado sigue registrado y se monitoriza. Los interesados son quienes afectan o son afectados por el proyecto; conviene analizar su poder, interés y expectativas, y definir la comunicación. Una comunicación tardía suele convertirse en resistencia o en requisitos descubiertos al final.

El control de cambios recibe solicitudes, analiza su impacto en alcance, cronograma, costo, calidad y riesgo, y decide con la autoridad competente. Si se aprueba, se actualizan las líneas base y se comunica. Sin este proceso aparece el aumento descontrolado de alcance (scope creep). Un problema ya ocurrido es un asunto (issue), no un riesgo.

Registro de riesgos: ejemplo

ID	Evento incierto	Probabilidad	Impacto	Propietario	Respuesta planeada
R1	El proveedor cambia el contrato de su API sin aviso previo	Media	Alto	Arquitecto de integraciones	Mitigar: fijar versión, probar el contrato en CI y exigir notificación por escrito
R2	La migración altera acentos y símbolos en nombres propios	Alta	Medio	Responsable de datos	Mitigar: muestreo previo, conciliación posterior y reversión ensayada
R3	El especialista de soporte clave se ausenta en la ventana de carga	Baja	Alto	Jefe de proyecto	Transferir: cláusula de sustitución en el contrato de servicio
R4	El piloto consume horas de los agentes que atienden a los clientes	Media	Bajo	Responsable de negocio	Aceptar: reservar margen en el cronograma y vigilar la carga

La escala de probabilidad e impacto se define una sola vez y se aplica igual en todos los paquetes, o las prioridades dejan de ser comparables entre sí. El propietario es una persona con autoridad para ejecutar la respuesta; designar a un comité como titular deja el riesgo sin seguimiento operativo entre revisiones. Los riesgos aceptados conservan su entrada y una fecha de revisión, y cuando el evento ocurre se convierten en asunto y activan la respuesta prevista. La reserva de contingencia cubre los riesgos identificados y forma parte de la línea de costes; la reserva de gestión cubre trabajo no previsto y exige autorización del patrocinador.

Análisis de interesados: ejemplo

Interesado	Posición en la matriz	Expectativa principal	Estrategia de implicación
Dirección de operaciones	Poder alto, interés alto	Que el sistema no detenga la atención al cliente	Gestionar de cerca: comité quincenal con métricas de incidencias
Responsable de facturación	Poder alto, interés bajo	Que los cobros sigan cuadrando	Satisfacer: informe mensual y consulta antes de cambios de formato
Agentes de atención	Poder bajo, interés alto	Menos trabajo manual y formación clara	Mantener informados: talleres prácticos y canal de dudas con respuesta garantizada
Equipo de seguridad	Poder medio, interés medio	Auditoría y trazabilidad de accesos	Colaborar: revisión de artefactos antes de cada entrega

La posición de cada persona no es fija: una normativa nueva puede elevar el poder del área de cumplimiento y convertir un interés bajo en alto. La matriz se revisa al cierre de cada fase y siempre que entra un patrocinador distinto. Identificar tarde a un interesado con poder suele traducirse en requisitos aparecidos durante la aceptación, cuando incorporarlos ya encarece el alcance. También conviene apuntar quién se opondrá al cambio, porque su resistencia se anticipa con información y evidencias, no con presión.

Plan de comunicación

Audiencia	Contenido	Formato	Frecuencia	Emisor
Comité de dirección	Avance frente a la línea base, riesgos altos y decisiones pendientes	Panel de una página más reunión	Mensual	Jefe de proyecto
Equipo del proyecto	Bloqueos, siguiente incremento y acuerdos de la iteración	Tablero compartido y reunión corta	Diaria o semanal según el enfoque	Responsable de la iteración
Áreas afectadas	Cambios de proceso, fechas de capacitación e impacto en su gente	Correo con acuse y sesión abierta de preguntas	Quincenal	Responsable de negocio
Proveedor externo	Requisitos de integración, hitos de entrega y evidencias de aceptación	Acta firmada y portal compartido	Por hito	Gestor de contratos

Enviar no equivale a recibir: conviene exigir acuse en los avisos críticos y cerrar cada ronda de preguntas con un resumen de acuerdos. La carga de comunicación crece con el tamaño del equipo, porque el número de canales entre sus integrantes sigue la fórmula n × (n − 1) / 2; ocho personas generan veintiocho canales, de ahí que los equipos grandes necesiten acuerdos de formato. Cada reunión termina con decisiones, responsables y fechas escritas; un encuentro sin acta deja el mismo estado de conocimiento que antes de convocarlo. La ruta de escalado fija en cuántos días se resuelve una discrepancia y a quién se eleva cuando el equipo no llega a un acuerdo.

Enfoques predictivos, ágiles e híbridos

El enfoque predictivo, asociado a cascada, planifica gran parte del trabajo antes de construir y avanza por fases secuenciales. Funciona cuando el alcance es estable, los requisitos son conocidos y los cambios tardíos son costosos, como en ciertos entornos regulados. Su debilidad aparece con alta incertidumbre: descubrir un supuesto erróneo al final puede invalidar gran parte del esfuerzo.

El enfoque ágil acepta la incertidumbre y entrega incrementos frecuentes para obtener retroalimentación. El Manifiesto Ágil valora individuos e interacciones, software funcionando, colaboración con el cliente y respuesta al cambio por encima de procesos, documentación exhaustiva, negociación contractual y plan rígido. Scrum define tres responsabilidades —Product Owner, Scrum Master y Developers—, tres artefactos —Product Backlog, Sprint Backlog e Incremento— y eventos como la planificación, la reunión diaria, la revisión y la retrospectiva. Kanban visualiza el flujo, limita el trabajo en curso y mide el tiempo de ciclo, sin exigir los roles ni los eventos de Scrum.

Muchos proyectos son híbridos: mantienen gobernanza, presupuesto y hitos, pero entregan por iteraciones. La elección debe basarse en la incertidumbre, la criticidad, la cultura y las obligaciones externas. Un ágil mal aplicado, sin acuerdos claros ni disciplina, produce la misma falta de previsibilidad que un cascada mal planificado.

Factores de decisión entre enfoques

Factor	Favorece lo predictivo	Favorece lo ágil
Estabilidad del alcance	Requisitos firmados y cambios costosos	Descubrimiento continuo de la necesidad
Incertidumbre técnica	Tecnología dominada por el equipo	Experimentación y prototipos necesarios
Exigencias de auditoría	Evidencias y aprobaciones por fase	Pruebas automatizadas y revisión continua
Disponibilidad del usuario	Ventanas fijas de validación	Un representante presente en cada iteración
Tamaño y distribución del equipo	Muchos actores y dependencias externas	Equipos pequeños y autónomos
Coste del error tardío	Corregir en producción resulta prohibitivo	El incremento permite corregir pronto
Necesidad de valor temprano	El producto completo es la entrega de valor	Se puede entregar una parte útil primero
Tipo de contrato	Precio cerrado con alcance definido	Presupuesto por capacidad y backlog priorizado

El enfoque híbrido separa la gobernanza de la ejecución: fechas, presupuesto y aprobaciones siguen un modelo predictivo, mientras el trabajo se organiza en iteraciones con entregas frecuentes. El patrocinador revisa incrementos en lugar de una única entrega al final. Adoptar ceremonias ágiles sin un product owner disponible ni un incremento utilizable en cada iteración produce previsibilidad falsa; el equipo se mueve y el alcance no avanza. La elección también depende del contrato: un precio cerrado empuja a congelar el alcance, mientras una relación por capacidad permite repriorizar el backlog con el aprendizaje de cada entrega.

Estimación y medición del desempeño

Entre las técnicas de estimación destaca el cálculo por analogía, que toma como referencia un trabajo similar ya terminado. La estimación de tres puntos combina valores optimista, más probable y pesimista, y el valor esperado se obtiene sumando el optimista, cuatro veces el más probable y el pesimista, y dividiendo entre seis; la distancia entre los extremos muestra la incertidumbre que el propio equipo reconoce. El planning poker reúne estimaciones individuales y fuerza la conversación cuando las cifras divergen, y el dimensionado con camisetas (S, M, L, XL) ordena un backlog largo antes de comprometer números concretos.

Para medir el desempeño, el valor planificado (PV) es lo que debería haberse ejecutado hasta la fecha, el valor ganado (EV) es el valor de lo realmente ejecutado y el costo real (AC) es lo consumido. Un índice de costo EV/AC por debajo de uno indica sobrecoste acumulado, y un índice de programación EV/PV por debajo de uno indica retraso frente al plan. Si un proyecto acumula EV de 80 con AC de 90 y PV de 100, los índices valen 0,89 y 0,80: se gasta más de lo que se avanza. Con esos datos, la proyección de cierre divide el presupuesto entre el índice de costo mientras la desviación siga siendo representativa del comportamiento habitual.

Cierre y lecciones aprendidas

El cierre verifica que los entregables cumplen los criterios de aceptación, obtiene la aprobación formal y transfiere el resultado a la operación o al cliente. Incluye cerrar contratos, liberar recursos, archivar documentación y actualizar los activos de conocimiento. La transición debe contemplar soporte, monitoreo, responsabilidades y documentación operativa.

Las lecciones aprendidas recogen qué funcionó, qué no y qué se cambiaría, para mejorar el sistema y no buscar culpables. Una revisión posterior puede evaluar si se obtuvieron los beneficios esperados, que a menudo se materializan después del cierre.

Criterios de aceptación y evidencias

Entregable	Criterio de aceptación	Método de verificación	Evidencia
Migración de datos	Los totales por cuenta coinciden entre origen y destino sin diferencias	Conciliación automatizada de saldos	Informe de conciliación firmado
Integración de facturación	Los documentos de prueba generan el asiento contable esperado	Pruebas de extremo a extremo con conjunto cerrado	Registro de pruebas con resultados
Formación de agentes	Cada agente completa un caso guiado sin ayuda	Ejercicio práctico en entorno de pruebas	Lista de asistencia y evaluación
Documentación operativa	El procedimiento de contingencia se ejecuta en la ventana ensayada	Simulacro con el turno de guardia	Acta del simulacro y tiempos

Los criterios se escriben junto con el entregable, no en la revisión final: frases como "que funcione bien" trasladan la disputa al momento de aceptar, cuando ya se consumió el presupuesto. La evidencia debe ser reproducible, de modo que quien repita el método llegue a la misma conclusión. Quien acepta debería ser quien operará el resultado después del cierre; si el aceptante no es el responsable de la operación, la transición arranca sin interesado que reclame el entregable.

Ejemplos prácticos

Una empresa migra su sistema de tickets a la nube. En la iniciación define el problema, el patrocinador y el criterio de éxito. En la planificación crea una EDT con migración de datos, integración, capacitación y soporte; identifica el riesgo de pérdida de datos y planifica una copia verificable. El equipo adopta un enfoque híbrido: hitos de gobernanza y entregas por iteraciones.

Durante la ejecución, el proveedor anuncia un cambio de API. El líder registra una solicitud, analiza el impacto en el cronograma y obtiene aprobación para ajustar la integración. El equipo ejecuta un piloto con un grupo reducido, mide incidencias y corrige antes del despliegue general. En el cierre verifica la aceptación, transfiere el soporte y documenta que la estimación no consideró la dependencia externa.

Caso 3: compresión del cronograma. La fecha comprometida se retrasa dos semanas por una dependencia externa. El equipo revisa la ruta crítica y constata que acortar la capacitación no mueve la fecha final, porque esa actividad dispone de holgura. Añade un segundo probador a la integración, que es la actividad que gobierna el plazo, y solapa la documentación con la prueba de aceptación. La fecha se recupera sin recortar alcance, el sobrecosto se aprueba y queda reflejado en la línea base actualizada.

Caso 4: cierre sin transición. El proyecto termina con todos los entregables aprobados, pero nadie asume la monitorización de la integración con el sistema de cobro. Dos meses después, un fallo de conciliación pasa desapercibido durante varios días. La revisión posterior concluye que el plan de transición no incluía responsables ni alertas, y esa comprobación entra en el checklist de cierre del siguiente proyecto.

Errores frecuentes

Confundir proyecto con producto u operación y mantener un esfuerzo sin criterios de cierre.
Planificar tareas sin vincularlas a entregables ni a criterios de aceptación verificables.
Tratar la estimación como un compromiso fijo y no registrar sus supuestos.
Aceptar cambios verbales sin analizar impacto ni actualizar la línea base.
Adoptar Scrum solo como reuniones, sin Product Owner disponible ni incremento utilizable.

Puntos clave para el examen

Proyecto: temporal, único y con elaboración progresiva; operación: repetitiva y continua.
La restricción triple relaciona alcance, tiempo y costo; calidad y riesgo también se ven afectados.
Fases: iniciación, planificación, ejecución, monitorización y control, cierre.
La EDT descompone entregables en paquetes; la ruta crítica fija la duración mínima.
Riesgo es incierto; asunto es un problema ya materializado.
Respuestas a amenazas: evitar, mitigar, transferir, aceptar.
Scrum define roles, artefactos y eventos; Kanban se centra en el flujo y los límites de trabajo en curso.
El control de cambios analiza impacto y actualiza la línea base antes de ejecutar.
El propietario de un riesgo es una persona con autoridad para ejecutar la respuesta; un comité como titular deja el seguimiento sin responsable.
La contingencia cubre riesgos identificados y entra en la línea de costes; la reserva de gestión cubre lo no previsto y necesita autorización del patrocinador.
Enviado no significa recibido: los avisos críticos requieren acuse y las reuniones terminan con decisiones y responsables escritos.
Comprimir el cronograma solo acorta la fecha si la actividad pertenece a la ruta crítica; sobre la holgura no se gana tiempo.
Valor ganado: EV/AC por debajo de uno indica sobrecoste acumulado y EV/PV por debajo de uno indica retraso frente al plan.
Los criterios de aceptación se definen junto con el entregable y exigen evidencia verificable y reproducible.

Recursos externos

PMI, estándares y guías: https://www.pmi.org/pmbok-guide-standards
Manifiesto Ágil: https://agilemanifesto.org/
Principios del Manifiesto Ágil: https://agilemanifesto.org/principles.html
IIBA, BABOK Guide: https://www.iiba.org/standards-and-resources/babok/

Autoevaluación

¿Cuál es la diferencia principal entre un proyecto y una operación? Un proyecto es temporal y produce un resultado único; una operación es continua y repetitiva. La temporalidad y la unicidad permiten decidir si corresponde gestión de proyectos.
Un patrocinador pide añadir funcionalidades sin ampliar plazo ni presupuesto. ¿Qué debe hacer el gestor? Analizar el impacto en alcance, tiempo, costo, calidad y riesgo mediante el control de cambios, y presentar opciones antes de aceptar. Aceptar sin análisis introduce scope creep y vuelve inviable la línea base.
¿Por qué la ruta crítica es relevante para el cronograma? Porque es la secuencia de dependencias más larga y fija la duración mínima. Un retraso en ella afecta la fecha de fin; una actividad fuera de la ruta puede tener holgura.
¿Qué diferencia hay entre mitigar y transferir un riesgo? Mitigar reduce la probabilidad o el impacto; transferir desplaza la consecuencia a otra parte, por ejemplo mediante un contrato. En ambos casos el riesgo sigue registrado y monitorizado.
¿Cuándo puede ser preferible un enfoque predictivo frente a uno ágil? Cuando el alcance es estable, los requisitos están definidos y los cambios tardíos son costosos o restringidos. La decisión depende del contexto, no de una superioridad universal.
¿Por qué el propietario de un riesgo debe ser una persona concreta y no un comité? Porque la respuesta exige decisiones y recursos en un plazo acotado; un comité diluye la responsabilidad y retrasa la acción hasta su siguiente reunión. La rendición de cuentas individual mantiene el riesgo vivo entre revisiones.
Un proyecto reporta EV 80, AC 90 y PV 100. ¿Qué indican los índices calculados? Un costo de 0,89 y una programación de 0,80: se consume más de lo planificado y se avanza menos de lo previsto. Conviene revisar estimación y productividad antes de comprometer de nuevo la fecha de fin.
¿Cómo se atiende a un interesado de poder alto e interés bajo? Informándolo con puntualidad y consultándolo en los puntos que afecten a su responsabilidad, sin involucrarlo en el detalle diario. Su interés puede crecer con una normativa nueva, por lo que conviene actualizar la matriz en cada fase.
¿Qué protege la definición temprana de criterios de aceptación? Evita que la disputa sobre lo que significa "terminado" aparezca en la revisión final, cuando el presupuesto ya está consumido. Además permite generar desde la primera entrega una evidencia comprobable por quien acepta.