Preguntas de entrevista Jefe de proyecto

Mi primer paso es entender exactamente por qué el proyecto va con retraso. ¿Es un problema de planificación, de recursos, de una dependencia que se retrasó o un problema de alcance no anticipado? La causa raíz determina la respuesta. Una vez que conozco la causa, reevalúo el camino crítico e identifico qué actividades están bloqueando realmente la entrega frente a cuáles pueden paralelizarse o reducirse sin comprometer el resultado. Luego tengo una conversación honesta con los stakeholders lo antes posible: las sorpresas en el plazo son mucho más dañinas que las advertencias tempranas. Las opciones que presento suelen ser alguna combinación de extender el calendario, reducir el alcance, añadir recursos o aceptar una entrega por fases.

La prevención es mejor que la cura. Establezco un documento de alcance claro al inicio de cada proyecto que describe qué está incluido y qué está explícitamente excluido, aprobado por los stakeholders clave. Cuando llegan nuevas solicitudes, uso un proceso de solicitud de cambio que requiere al solicitante documentar la petición, la justificación de negocio y el impacto estimado en el calendario y presupuesto. Para las solicitudes que pasan ese filtro, presento el impacto de forma transparente al patrocinador del proyecto: el alcance adicional debe ir acompañado de tiempo, recursos adicionales o una reducción en otro lugar. Nunca absorbo silenciosamente los cambios de alcance.

Empiezo por asegurarme de entender el objetivo subyacente de cada stakeholder, no solo su posición declarada. A menudo las prioridades conflictivas son un síntoma de métricas de éxito diferentes, y una vez visibles, la alineación se facilita mucho. Reúno a los stakeholders en conflicto en una conversación estructurada en lugar de negociar por separado. Uso los datos y las restricciones del proyecto para enmarcar las decisiones objetivamente: dado nuestro calendario y recursos, ¿qué secuenciación sirve mejor al objetivo del proyecto? Documento los acuerdos por escrito inmediatamente después de cada discusión.

Lideré un proyecto de implementación de software que se retrasó cuatro meses. El problema principal fue que subestimamos la complejidad de migrar datos legacy y no identificamos ese trabajo como camino crítico hasta la semana seis. En el post-mortem identifiqué tres causas: discovery insuficiente antes de la planificación, sin recurso dedicado a la migración, y un registro de riesgos mantenido pero no revisado activamente. Como resultado, ahora incluyo una fase de discovery estructurada antes de cualquier planificación base, trato la migración de datos como un trabajo prioritario por defecto, y mantengo una revisión semanal de riesgos como punto fijo del orden del día.

A mitad de un proyecto de lanzamiento de producto, nuestro proveedor externo principal nos informó de que no podía entregar una integración clave en la fecha original. En lugar de esperar al siguiente comité de dirección, solicité una reunión urgente con el patrocinador del proyecto el mismo día. Llegué preparado con tres opciones: retrasar el lanzamiento seis semanas, lanzar sin la integración y añadirla en fase dos, o buscar un proveedor alternativo. Presenté los datos de cada opción sin preseleccionar ninguna. El patrocinador eligió el lanzamiento por fases. Dar malas noticias pronto con opciones claras casi siempre se recibe mejor que darlas tarde sin alternativas.

Durante un largo proyecto de migración de infraestructura, el equipo atravesó un período desmoralizador hacia la mitad. Hice tres cosas. Primero, dividí el trabajo restante en hitos de dos semanas y empecé a celebrar cada uno de forma visible con reconocimiento específico. Segundo, mantuve reuniones individuales para entender qué motivaba a cada persona y ajusté la asignación de tareas donde pude. Tercero, creé un seguimiento de progreso visible que mostraba el camino recorrido, no solo el que quedaba. En el último trimestre la energía del equipo se había recuperado notablemente y entregamos a tiempo.

Tengo experiencia tanto con Waterfall como con Agile, y en la práctica la mayoría de los proyectos que he liderado usan un enfoque híbrido. Uso la planificación Waterfall cuando el alcance está bien definido de antemano y el coste de los cambios tardíos es alto: los grandes proyectos de infraestructura o los entregables regulatorios suelen encajar en este patrón. Uso Agile o Scrum cuando los requisitos probablemente evolucionarán y la iteración rápida es más valiosa que la predictibilidad. En proyectos híbridos uso Agile para los trabajos de entrega y Waterfall para la capa de gobernanza.

Construyo el plan en colaboración con el equipo de entrega, no de forma aislada. Las personas que hacen el trabajo están mejor posicionadas para estimar el esfuerzo, y involucrarlas pronto crea sentido de propiedad. Comienzo con los entregables y trabajo hacia atrás, identifico todas las dependencias, asigno responsables a cada tarea y establezco el camino crítico explícitamente. Uso un RACI para clarificar la responsabilidad de cada área de trabajo. Una vez en la línea base, actualizo el plan semanalmente como mínimo y señalo cualquier cambio en el camino crítico como riesgo de inmediato.

Mantengo un registro de riesgos activo desde la primera semana de cada proyecto. Cada riesgo tiene un responsable, una calificación de probabilidad e impacto, un evento desencadenante y una acción de mitigación. Crucialmente, reviso el registro en cada reunión de estado del proyecto en lugar de solo actualizarlo. También distingo entre riesgos (eventos inciertos que podrían ocurrir) e incidencias (problemas que ya han ocurrido), porque necesitan respuestas diferentes. Para riesgos de alta probabilidad y alto impacto incluyo la mitigación directamente en el plan del proyecto.