Entrevista de Gerente de Proyectos de TI en Uruguay: preguntas reales y respuestas que cierran

Imaginá esto: te llega el mail con el asunto “Entrevista – Gerente de Proyectos de TI”. Lo leés dos veces. Te alegrás… y a los 30 segundos te cae la ficha: no te van a preguntar “¿cuál es tu mayor debilidad?”. Te van a tirar con alcance, fechas, proveedores, riesgos, compliance y gente que no te responde.

En Uruguay, la entrevista para Gerente de Proyectos de TI suele ser práctica y bastante “de cancha”: quieren saber si podés llevar un proyecto a producción sin incendiar al equipo ni romper el negocio. Acá tenés preguntas que de verdad aparecen, cómo contestarlas con estructura y qué preguntar vos para sonar como alguien que ya estuvo ahí.

1) Cómo funcionan las entrevistas para este rol en Uruguay

En el mercado uruguayo, el proceso típico para un IT Project Manager arranca con una llamada corta de RR. HH. para validar seniority, disponibilidad (híbrido/remoto), rango salarial y nivel de inglés si el cliente es de afuera. Después viene la entrevista “de verdad” con el área: a veces el Head of Delivery, un Gerente de Tecnología o un Jefe de Proyectos de Tecnología. Ahí se juega el partido: te piden que cuentes proyectos concretos, cómo planificás, cómo controlás cambios y qué hacés cuando el equipo no llega.

En empresas de software y consultoras (muy comunes en Montevideo), es normal que haya una tercera instancia: entrevista con cliente o con un líder técnico. No esperes un examen tipo universidad, pero sí mini-casos: “tenés un Go-Live en dos semanas y el proveedor no entrega”. También es habitual que te pregunten por tu forma de documentar (actas, RAID log, cronograma) y por herramientas (Jira/Confluence, MS Project, Azure DevOps). El tono suele ser cordial y directo; se valora la claridad y la humildad práctica: “esto lo medí así”, “esto lo escalé así”, “esto lo negocié así”.

2) Preguntas generales y conductuales (pero específicas del rol)

Estas preguntas parecen “blandas”, pero en un Project Manager de TI son el filtro para ver si sabés liderar sin autoridad formal, si entendés el negocio y si tenés método cuando todo cambia.

Q: Contame un proyecto de TI que hayas llevado a producción y cómo controlaste alcance, tiempo y calidad.

Why they ask it: Quieren evidencia de delivery real, no teoría.

Answer framework: STAR + “triple restricción” (alcance/tiempo/calidad): describí contexto, tu sistema de control y el resultado medible.

Example answer: “En mi último rol como Jefe de Proyecto, lideré la implementación de un módulo de facturación para una fintech con 12 personas entre dev, QA y analistas. El alcance lo cerré con un backlog priorizado y criterios de aceptación por historia; el tiempo lo controlé con un plan por releases y un burn-up semanal; y la calidad con gates de QA y métricas de defectos por sprint. Hubo presión por adelantar el Go-Live, así que negocié un MVP con funcionalidades críticas y dejé mejoras para un release 2. Salimos en fecha y bajamos un 30% los reclamos post-producción en el primer mes.”

Common mistake: Hablar del proyecto como si lo hubiera hecho “el equipo” sin explicar tu mecanismo de control.

Entre esta pregunta y la siguiente hay una línea fina: no alcanza con “entregar”. En Uruguay te van a medir por cómo manejás fricción con negocio y con tecnología.

Q: ¿Cómo manejás un sponsor que pide cambios todo el tiempo sin ajustar fecha ni presupuesto?

Why they ask it: Están testeando si sabés decir “no” sin romper la relación.

Answer framework: Problema–Opciones–Decisión: mostrás alternativas con impacto y forzás una decisión explícita.

Example answer: “Primero registro el cambio y lo traduzco a impacto: esfuerzo, riesgo y efecto en la fecha. Después llevo 2–3 opciones al sponsor: (1) mantenemos fecha recortando alcance, (2) mantenemos alcance moviendo fecha, (3) mantenemos ambos agregando presupuesto o capacidad. Lo clave es que la decisión quede documentada en un acta o en el flujo de change request. Si el sponsor insiste en ‘todo sin costo’, escalo con datos al steering y protejo al equipo de compromisos imposibles.”

Common mistake: Aceptar cambios “para quedar bien” y después justificar el atraso.

Q: Contame un conflicto fuerte con un líder técnico o arquitecto. ¿Cómo lo resolviste?

Why they ask it: Quieren ver si podés alinear sin entrar en guerra de egos.

Answer framework: STAR + “intereses vs posiciones”: separá el objetivo del tono.

Example answer: “En un proyecto de migración, el arquitecto quería reescribir componentes críticos y el negocio quería continuidad. En vez de discutir ‘quién tiene razón’, armé una sesión corta para listar riesgos y beneficios, y pedí un spike técnico de 3 días para validar el impacto real. Con esa evidencia, acordamos una migración por etapas: primero compatibilidad y observabilidad, después refactor. El conflicto bajó porque la decisión se basó en datos y no en opiniones.”

Common mistake: Contar el conflicto como una pelea personal (“él era difícil”).

Q: ¿Qué métricas seguís semanalmente para saber si un proyecto está sano?

Why they ask it: Buscan un Responsable de Proyectos de TI que gestione por señales, no por intuición.

Answer framework: “Tablero en 4 cuadrantes” (alcance/tiempo/calidad/flujo): nombrá métricas y cómo actuás.

Example answer: “Miro avance contra baseline (burn-up o hitos), estabilidad del alcance (cambios por semana), calidad (defectos abiertos/cerrados y severidad) y flujo (lead time, WIP, bloqueos). Si veo caída de throughput o aumento de bloqueos, no ‘aprieto’: reviso dependencias, redefino prioridades y saco impedimentos con los dueños. La métrica sin acción es decoración.”

Common mistake: Responder con métricas vagas (“cumplir objetivos”) sin instrumentos concretos.

Q: ¿Cómo te organizás cuando llevás varios proyectos a la vez (típico en consultoras en Uruguay)?

Why they ask it: Quieren saber si podés manejar contexto cambiante sin perder control.

Answer framework: “Cadencia + límites”: explicá tu sistema de priorización, rituales y comunicación.

Example answer: “Trabajo con una cadencia fija: lunes revisión de riesgos y prioridades, mitad de semana seguimiento de dependencias, viernes cierre de compromisos y reporte ejecutivo. Limito WIP: si tengo tres frentes, defino un ‘proyecto foco’ por semana y el resto queda en modo mantenimiento con checkpoints claros. Y uso un RAID log vivo para no depender de la memoria. Eso me permite responder rápido sin vivir apagando incendios.”

Common mistake: Decir “me adapto” sin describir un sistema.

Q: ¿Por qué querés este rol y no seguir como analista/tech lead? (adaptada a PM de TI)

Why they ask it: Están validando motivación real por gestión y accountability.

Answer framework: “Evidencia + dirección”: 1 ejemplo de transición + qué querés construir.

Example answer: “Me gusta estar cerca del impacto: que algo salga y funcione en el negocio. En mi rol anterior empecé tomando coordinación de releases y gestión de stakeholders, y vi que mi fortaleza era ordenar el caos: priorizar, negociar y hacer visibles los riesgos. Quiero seguir creciendo como Gerente de Proyectos Tecnológicos en entornos con producto y operaciones, donde el delivery tenga métricas y aprendizaje, no solo ‘terminar tareas’.”

Common mistake: Hablar solo de “me gusta liderar” sin ejemplos de accountability.

3) Preguntas técnicas y profesionales (las que separan a un PM real)

Acá es donde muchas entrevistas en Uruguay se ponen interesantes. No te van a pedir que programes, pero sí que entiendas el terreno: delivery ágil, dependencias, seguridad, proveedores, y cómo se gobierna un proyecto cuando hay auditoría o un cliente enterprise.

Para preparar estas respuestas, pensá como Director de Proyectos de TI: método, evidencia y decisiones explícitas.

Q: ¿Qué metodología usás: Scrum, Kanban o híbrido? ¿Cómo decidís cuál aplicar?

Why they ask it: Quieren pragmatismo, no fanatismo.

Answer framework: “Contexto–Señales–Diseño”: tipo de trabajo, incertidumbre, dependencias y cadencia.

Example answer: “Si tengo producto con incertidumbre y necesidad de feedback, uso Scrum con sprints cortos y definición de listo/hecho fuerte. Si es soporte evolutivo con flujo continuo, Kanban con límites de WIP y políticas explícitas. En la práctica suelo ir a un híbrido: planificación por sprint, pero con tablero que muestre bloqueos y lead time. La decisión la tomo mirando variabilidad del trabajo y costo de cambiar prioridades.”

Common mistake: Responder “Scrum siempre” sin justificar.

Q: En Jira, ¿qué configuraciones o tableros te ayudan a controlar un proyecto sin microgestionar?

Why they ask it: Buscan dominio de herramientas reales de delivery.

Answer framework: “Tablero–Métrica–Acción”: qué ves, qué medís, qué decidís.

Example answer: “Armo un tablero por equipo con estados que reflejen el flujo real (incluyendo ‘Blocked’ con causa). Uso versiones/releases para compromisos y un dashboard con burn-up, cumulative flow y aging de issues. Lo importante es que el tablero sea un espejo del sistema: si hay mucho ‘In Progress’, ajusto WIP y destrabo dependencias; si el burn-up se aplana, reviso alcance o capacidad.”

Common mistake: Hablar de Jira como lista de tareas, sin métricas ni decisiones.

Q: ¿Cómo armás y mantenés un RAID log (Riesgos, Asunciones, Issues, Dependencias) en un proyecto de TI?

Why they ask it: Esto es “oficio” de Jefe de Proyectos de Tecnología; pocos lo hacen bien.

Answer framework: “Plantilla mínima viable + cadencia”: qué campos, quién lo actualiza, cómo se usa.

Example answer: “Uso un RAID log simple en Confluence o Excel compartido: descripción, probabilidad/impacto, dueño, fecha, plan de mitigación y gatillos. Lo reviso semanalmente con el equipo y quincenalmente con stakeholders. Si un riesgo se materializa, pasa a issue con plan y fecha. Y las dependencias las conecto a hitos: si no hay fecha y responsable, no es dependencia, es deseo.”

Common mistake: Tratar riesgos como ‘lista para auditoría’ y no como herramienta viva.

Q: ¿Cómo estimás y planificás cuando el equipo te dice “no sabemos, nunca lo hicimos”?

Why they ask it: Quieren ver si sabés gestionar incertidumbre técnica.

Answer framework: “Descubrimiento–Spike–Reestimación”: convertir incertidumbre en aprendizaje.

Example answer: “Primero separo lo desconocido en hipótesis y riesgos. Propongo spikes timeboxed para validar arquitectura, performance o integraciones. Con resultados, reestimamos y definimos un plan por incrementos con checkpoints. Prefiero un plan que admita cambios a una fecha ‘de fe’ que después se rompe.”

Common mistake: Forzar una estimación exacta sin reducir incertidumbre.

Q: ¿Cómo gestionás integraciones con proveedores (por ejemplo, pasarelas de pago, facturación electrónica o servicios cloud) en Uruguay?

Why they ask it: En UY es común depender de terceros; quieren ver control contractual y técnico.

Answer framework: “Contrato–Interfaz–Prueba”: SLA/alcance, definición de API, plan de pruebas end-to-end.

Example answer: “Alineo expectativas por escrito: entregables, SLA, ventanas de soporte y criterios de aceptación. A nivel técnico, cierro contrato de interfaz (API, formatos, errores, timeouts) y un plan de pruebas con ambientes y datos. Y pongo hitos de integración temprano: si esperás al final, el proveedor te define la fecha. Prefiero fallar rápido en sandbox que fallar en producción.”

Common mistake: Tratar al proveedor como ‘caja negra’ y descubrir problemas al final.

Q: ¿Qué harías si el día del Go-Live falla el pipeline de CI/CD o el despliegue?

Why they ask it: Quieren un plan de contingencia real, no heroísmo.

Answer framework: Respuesta por capas: contención → diagnóstico → decisión → comunicación.

Example answer: “Primero activo el plan de release: freeze, roles claros y canal único de comunicación. Si el pipeline falla, evalúo si hay rollback seguro o si conviene pausar y volver a la versión estable. Paralelamente, asigno a un responsable a diagnóstico (logs, permisos, runners, credenciales) y a otro a comunicación con negocio. La regla: no improvisar en producción; ejecutar runbook y documentar post-mortem.”

Common mistake: “Nos quedamos hasta que salga” sin rollback ni comunicación.

Q: ¿Cómo manejás seguridad y compliance en proyectos (por ejemplo, datos personales)?

Why they ask it: En Uruguay hay exigencias reales de protección de datos y auditoría.

Answer framework: “Shift-left de riesgos”: requisitos → controles → evidencia.

Example answer: “Involucro seguridad desde el inicio: clasificación de datos, controles de acceso, logging y retención. Si hay datos personales, pido revisión de cumplimiento con la normativa local y políticas internas, y lo traduzco a historias y criterios de aceptación. Además, dejo evidencia: decisiones, aprobaciones y pruebas. Seguridad no es un ‘check’ al final; es diseño.”

Common mistake: Delegar todo en el área de seguridad y enterarte al final.

Q: ¿Qué estándares o certificaciones te sirven en el rol (PMP, PRINCE2, ITIL, Scrum) y cómo los aplicás en la práctica?

Why they ask it: Quieren separar “tengo el papel” de “lo uso para decidir”.

Answer framework: “Principio–Aplicación–Resultado”: 1 principio, 1 práctica, 1 impacto.

Example answer: “De PMP tomo el foco en gestión de alcance, riesgos y stakeholders: acta, WBS cuando aplica y control de cambios. De Scrum, la inspección y adaptación: retrospectivas con acciones reales. Y de ITIL, el cuidado del cambio en producción: ventanas, aprobaciones y comunicación. La certificación suma si se ve en cómo ordenás el trabajo y reducís sorpresas.”

Common mistake: Enumerar siglas sin aterrizarlas a prácticas.

Q: ¿Cómo armás un business case simple para priorizar un proyecto frente a otro?

Why they ask it: En empresas uruguayas medianas, el PM muchas veces ayuda a priorizar inversión.

Answer framework: “Valor–Costo–Riesgo–Tiempo”: 4 variables, una decisión.

Example answer: “Pongo en una hoja: beneficio esperado (ingresos, ahorro, riesgo evitado), costo total (equipo + licencias + proveedor), riesgos y time-to-value. Si dos iniciativas compiten, priorizo la que entregue valor antes con riesgo controlado. Y dejo supuestos explícitos: si cambian, cambia la decisión.”

Common mistake: Priorizar por ‘quién grita más fuerte’.

Q: ¿Cómo reportás a dirección sin caer en status reports eternos?

Why they ask it: Quieren comunicación ejecutiva, no burocracia.

Answer framework: “Semáforo + decisiones”: estado, riesgos top 3, decisiones requeridas.

Example answer: “Hago un reporte de una página: semáforo por alcance/tiempo/calidad, hitos próximos, riesgos top con mitigación y, sobre todo, decisiones que necesito del steering. Si no hay decisiones, el reporte es demasiado largo o demasiado tímido. Dirección compra claridad, no detalle.”

Common mistake: Mandar un mail largo con tareas y sin pedidos concretos.

4) Preguntas situacionales y de caso (lo que te puede caer en la entrevista)

En Uruguay, especialmente en consultoras y software factories, te tiran escenarios para ver cómo pensás bajo presión. No buscan “la respuesta perfecta”. Buscan orden mental.

Q: Estás a 10 días del release y QA encuentra un bug crítico en un flujo de pagos. El negocio igual quiere salir. ¿Qué hacés?

How to structure your answer:

1. Definí severidad e impacto (usuarios, dinero, reputación, compliance).
2. Planteá opciones (fix + retest, feature flag, rollback, postergar) con riesgos.
3. Forzá decisión con responsables y comunicación (acta + plan de contingencia).

Example: “Clasifico el bug como ‘stop-ship’ si afecta cobros o conciliación. Propongo salida con feature flag desactivando el flujo afectado o postergar el release si no hay mitigación segura. Lo documento y lo elevo al sponsor: salir con riesgo financiero no es ‘valentía’, es deuda cara.”

Q: El cliente (o sponsor interno) te pide una fecha cerrada, pero el equipo aún no tiene arquitectura definida.

How to structure your answer:

1. Negociá una fecha de descubrimiento (timebox) antes de comprometer delivery.
2. Convertí incertidumbre en entregables: spike, prototipo, definición de arquitectura.
3. Comprometé por hitos y rangos, no por promesas.

Example: “Ofrezco una fecha para ‘arquitectura validada + estimación con rango’ en 2 semanas, y recién ahí cierro un plan por releases. Si me exigen una fecha hoy, la doy como escenario (optimista/realista/pesimista) con supuestos explícitos.”

Q: Descubrís que el proveedor clave no va a llegar con su entrega y nadie lo había escalado.

How to structure your answer:

1. Confirmá hechos y nueva fecha (por escrito).
2. Activá plan B (re-secuenciar, mock, alternativa técnica, cambio de alcance).
3. Escalá con impacto y decisión requerida.

Example: “Pido confirmación formal de la nueva fecha y causa. Replanifico para que el equipo avance con mocks y pruebas internas, y llevo al steering el impacto y opciones: cambiar alcance, mover fecha o sumar otro proveedor.”

Q: El equipo está quemado y la rotación empieza a aparecer en medio del proyecto.

How to structure your answer:

1. Medí la carga real (WIP, horas extra, interrupciones, guardias).
2. Ajustá sistema: recorte de alcance, límites de WIP, protección del foco.
3. Acordá con negocio un plan sostenible y revisable.

Example: “Si el equipo está en modo ‘heroico’, el proyecto ya está en riesgo. Bajo WIP, corto reuniones inútiles, priorizo y negocio alcance. Prefiero un plan más lento y estable que velocidad falsa con renuncias.”

5) Preguntas que deberías hacer vos (para sonar senior)

Un Gerente de Proyectos de TI no entra a ciegas. Tus preguntas tienen que mostrar que pensás en gobernanza, riesgos y delivery, no en “beneficios”. Además, en Uruguay esto se valora: demuestra madurez y evita sorpresas.

• “¿Cómo definen éxito del proyecto: métricas de negocio, adopción, SLAs, reducción de incidentes?” — Te posiciona en outcomes, no en tareas.
• “¿Quién es el sponsor y cómo funciona el steering: cadencia, decisiones, escalamiento?” — Si no hay gobernanza, vas a sufrir.
• “¿Qué nivel de autonomía tiene el equipo para priorizar y decir ‘no’ a cambios?” — Te muestra como alguien que protege el delivery.
• “¿Qué herramientas usan hoy (Jira/Azure DevOps/Confluence/MS Project) y qué esperan que ordene en los primeros 60 días?” — Aterriza expectativas.
• “¿Cuáles son las dependencias externas más riesgosas (proveedores, áreas internas, compliance)?” — Pregunta de oficio.

6) Negociación salarial en Uruguay para este rol

En Uruguay, el salario suele aparecer temprano (RR. HH.) para evitar perder tiempo, pero la negociación real se cierra cuando ya te quieren. Tu tarea: llegar a esa instancia con argumentos de valor, no con “necesito X”. Para rangos, mirá referencias en Glassdoor, LinkedIn Jobs y portales locales como Buscojobs Uruguay y Computrabajo Uruguay. Contrastá con seniority, industria (software/finanzas) y si el rol es para cliente exterior.

Tu palanca como IT Project Manager: certificaciones (PMP/PSM), experiencia en migraciones cloud, manejo de proveedores, inglés y track record de delivery medible.

Frase útil: “Por el alcance del rol y mi experiencia liderando releases con equipos cross-funcionales, estoy apuntando a un rango de X a Y nominal. Si el paquete incluye bono/guardias/híbrido, lo ajustamos, pero me gustaría mantenerme en ese orden.”

7) Red flags (señales de alerta) específicas del rol

Si en la entrevista evitan decir quién decide prioridades, mala señal: vas a ser un “pararrayos” sin poder real. Si te piden “hacer de PM y de Scrum Master y de analista funcional y de QA” en el mismo rol, ojo: puede ser una empresa sin estructura que quema gente. Si no existe ambiente de staging, ni pipeline, ni plan de rollback, el riesgo operativo es tuyo aunque no te lo digan. Y si el sponsor no aparece nunca en el proceso, preparate para cambios de alcance por WhatsApp a último momento.

10) Cierre

La entrevista de Gerente de Proyectos de TI en Uruguay se gana con ejemplos concretos: cómo controlás cambios, cómo manejás riesgos, cómo negociás con negocio y cómo evitás el “heroísmo” en producción. Practicá tus historias con estructura y llevá preguntas que muestren gobernanza y delivery.

Antes de sentarte frente al entrevistador, dejá tu CV listo para pasar filtros y vender tu seniority. Creá un currículum optimizado para ATS en cv-maker.pro y después salí a cerrar la entrevista.