Gerente de proyectos Preguntas de entrevista & Respuestas

Respuesta modelo

I inherited a CRM implementation project that was 3 months behind schedule and 40% over budget. The previous PM had departed and team morale was low. In my first week, I conducted one-on-one meetings with every team member and key stakeholder to understand the real issues. I discovered three root causes: the scope had expanded 3x from the original plan without timeline adjustments, the vendor was underperforming on integrations, and two critical team members were reassigned to other projects. I presented a recovery plan: renegotiated scope with the business sponsor, cutting 30% of features to a Phase 2 and focusing Phase 1 on the must-have capabilities. I escalated the vendor performance issue to procurement, who applied contract penalties and got us a dedicated senior developer. I secured part-time backfill for the reassigned team members. We delivered Phase 1 one month late (vs. three), within the adjusted budget, and with 92% stakeholder satisfaction. The Phase 2 features were delivered in the following quarter.

Respuesta modelo

Two senior engineers on my team disagreed fundamentally about the architecture for a data migration — one advocated for a big-bang cutover, the other for a phased approach. The disagreement had become personal, affecting team meetings. I met with each separately to understand their concerns. The big-bang advocate was worried about maintaining two systems in parallel. The phased advocate was worried about data loss during cutover. Both concerns were valid. I facilitated a structured design review where each presented their approach with risk analysis. I asked the team to evaluate both on three criteria: risk of data loss, operational complexity, and timeline. The data showed the phased approach was lower risk but higher effort. I made the call: phased approach, but with automation to reduce the parallel-system burden (addressing the first engineer's concern). I acknowledged the big-bang advocate's valid concerns publicly and assigned them to lead the automation work. The migration succeeded with zero data loss.

Respuesta modelo

Midway through a 6-month platform migration, the compliance team identified new regulatory requirements that added 8 weeks of work. The business sponsor still expected the original deadline. I immediately ran an impact analysis: the new requirements added 320 hours of development and 80 hours of testing. I presented three options to the steering committee. Option A: extend the deadline by 8 weeks to accommodate the full scope. Option B: add 3 contractors to maintain the deadline at an additional cost of $90K. Option C: defer non-compliance features to keep the deadline and budget, then deliver those features 6 weeks later. I recommended Option C because compliance was non-negotiable, but several deferred features weren't needed until Q3 anyway. The steering committee agreed. I updated the project plan, communicated the change to all stakeholders with clear rationale, and delivered the compliance-focused release on time. The deferred features shipped 5 weeks later. The key was presenting options with tradeoffs rather than just delivering bad news.

Respuesta modelo

I managed a website redesign project with team members in New York, London, and Bangalore — three time zones with only 3 hours of overlap. I established a communication structure that respected time zones: async-first communication via Slack and Confluence for everything that didn't need real-time discussion, a daily 15-minute standup during the overlap window for blockers only, and weekly deep-dive sessions that rotated between time zone-friendly slots so no one was always on a late-night call. I created detailed sprint documentation so the Bangalore team could pick up work left by the New York team and vice versa. I also invested heavily in relationship building — monthly virtual team events and quarterly video one-on-ones with each team member. The project delivered on time with a team satisfaction score of 4.5/5. Two team members told me it was the best-run distributed project they'd worked on.

Respuesta modelo

I choose based on three factors: requirement stability, stakeholder flexibility, and team experience. Waterfall works when requirements are well-defined and unlikely to change (regulatory compliance projects, construction, hardware), when the client needs a fixed price and timeline upfront, or when the project has hard dependencies that must follow a sequence. Agile works when requirements will evolve based on user feedback (product development, digital transformation), when delivering incremental value is more important than waiting for a complete solution, and when the team is experienced with iterative work. In practice, most projects benefit from a hybrid: Agile execution within a Waterfall governance framework. I define the overall scope and milestones upfront (for budget and stakeholder alignment) but execute in sprints with flexibility to adjust priorities within the scope. The anti-pattern I avoid: using Agile as an excuse for no planning, or using Waterfall as an excuse for no flexibility.

Respuesta modelo

I use a combination of techniques depending on the project phase. Early-stage (order of magnitude): analogous estimation — compare to similar past projects adjusted for complexity. This gives a range, not a point estimate. 'Based on the CRM project last year, this is 4-6 months.' Planning phase: bottom-up estimation — break work into tasks, have the team estimate each task (I use Planning Poker for relative sizing), add dependencies and buffer. I apply the 1.5x rule: whatever the team estimates, multiply by 1.5 for unknown unknowns, integration complexity, and context switching. For individual tasks, I ask for three-point estimates: optimistic, most likely, and pessimistic. The PERT formula (O + 4M + P) / 6 gives a weighted average. I always present estimates as ranges, never single numbers. And I re-estimate at every major milestone as we learn more about the project. The most dangerous estimate is the one that never gets updated.

Respuesta modelo

I maintain a living risk register that's reviewed weekly. For each risk, I capture: description, probability (1-5), impact (1-5), risk score (probability x impact), owner, mitigation strategy, and trigger indicators. I categorize risks: technical (new technology, integration complexity), resource (key person dependency, skill gaps), external (vendor delays, regulatory changes), and schedule (dependency chains, estimation uncertainty). For the top 5 risks by score, I develop specific mitigation plans. Some examples: for key person dependency, I ensure knowledge sharing and documentation. For vendor risk, I maintain a backup vendor relationship. For schedule risk on the critical path, I add time buffers and identify tasks that can be parallelized. I distinguish between risk mitigation (reduce probability or impact before it happens) and contingency planning (what we do if the risk materializes). Every risk owner reports status weekly. Risks that materialize become issues and get tracked in the issue log with an owner and resolution timeline.

Respuesta modelo

I track four categories. Schedule: sprint velocity trend (is the team accelerating, stable, or decelerating?), milestone completion rate, and schedule performance index (earned value / planned value). Budget: actual spend vs. planned spend, burn rate, and estimate-at-completion. Quality: defect density, test pass rate, and rework percentage (how much work gets returned). Team: team satisfaction (monthly pulse surveys), overtime hours (sustained overtime signals trouble), and attrition risk. I present these on a single-page dashboard that uses red/amber/green for each category. The most important metric isn't any individual number — it's the trend. A velocity that's stable at 30 story points is fine. A velocity that was 40 last sprint and is now 30 is a warning sign that needs investigation. I also track one 'honest' metric that can't be gamed: actual vs. predicted delivery dates for completed milestones. If we consistently deliver late, our estimation process needs fixing.

Respuesta modelo

First, I'd have an honest conversation with the departing team member about their timeline and willingness to help with knowledge transfer. Even 2 weeks of structured handover is valuable. I'd immediately assess the impact: what work depends on this person's unique knowledge? What tasks are they currently working on? Where are the single points of failure? Then I'd act on three fronts. Knowledge capture: intensive documentation sessions and recorded walkthroughs of their work. Even imperfect documentation is better than none. Workload redistribution: reassign their tasks based on other team members' capacity and skills. Be realistic — the team will slow down temporarily. Communication: inform stakeholders about the impact on timeline and what I'm doing about it. I'd rather deliver bad news early with a plan than surprise them with a late delivery. For the replacement: start the hiring/backfill process immediately but plan for the project to continue without them. No project should be held hostage to a single person — if it is, that's a risk I should have mitigated earlier.

Respuesta modelo

I'd start by making the conflicts visible. Often stakeholders don't know they're in conflict because each one has communicated their priorities to the PM separately. I'd organize a priority alignment session with all key stakeholders, presenting: the full list of requirements, the available resources and timeline, and the fact that we can't deliver everything at once. I'd use a forced-ranking exercise: each stakeholder gets 100 points to distribute across the features. This makes tradeoffs tangible — you can't give everything 100 points. Where rankings diverge significantly, I'd facilitate a discussion: what's the business case for each priority? What's the cost of delay? Often, hearing each other's reasoning resolves the conflict. If it doesn't, I'd escalate to the project sponsor for a tie-breaking decision, armed with the data from the ranking exercise and my recommendation. After alignment, I'd document the agreed priorities and share them widely. When priorities inevitably shift, I'd repeat the process rather than making the call myself.

Respuesta modelo

I'd act fast — budget overruns get worse the longer you wait. First, root cause analysis: why are we over budget? Common causes: scope creep (work was added without budget adjustment), estimation errors (tasks took longer than expected), resource costs changed, or external factors (vendor price increases, regulatory requirements). Second, I'd present the situation and options to the project sponsor. Option A: increase the budget by 25% and deliver full scope. I'd justify the increase with specifics on what changed. Option B: reduce scope to fit the original budget — here are the features we'd defer and their business impact. Option C: extend the timeline (if the overrun is due to overtime costs, spreading work over more time can be cheaper). Option D: optimize execution — can we reduce costs through automation, renegotiating vendor rates, or using different resources? I'd present my recommendation with data supporting it. Whatever the decision, I'd implement tighter cost controls going forward: weekly budget reviews instead of monthly, approval gates for any new scope, and updated estimates for remaining work. The key: never let a budget surprise be a surprise. Communicate early.

Respuesta modelo

I'd investigate before prescribing. First, I'd analyze the data: which types of work are we missing on? Is it consistently underestimated, or are interruptions pulling team members away from sprint work? Are there dependency bottlenecks where one team blocks another? Then I'd talk to the team in retrospectives: do they feel the sprint goals are realistic? Are there systemic issues they see that I don't? Common root causes I'd look for: over-commitment (the team plans for 100% capacity when reality is 70% due to meetings, support, and interruptions), poor estimation (stories are consistently 2-3x larger than estimated), unclear requirements (stories get into the sprint and then spend 2 days in clarification), and context switching (team members pulled into incidents or other projects). My fixes depend on the diagnosis: build in a 30% capacity buffer, improve story refinement to catch ambiguity before sprint planning, negotiate protected focus time with management, or break stories into smaller pieces that are easier to estimate and complete.