Preguntas de entrevista: Project Manager

A realistic schedule combines scope decomposition, team-owned estimates, dependencies, capacity, and explicit uncertainty.

• I start from the deliverables, decompose them into a work breakdown structure, then define the activities, their durations, and the dependencies between them.
• I estimate durations with input from the people who will do the work rather than imposing dates, and I sequence activities into a network to find the critical path.
• I add the calendar, resource availability, and buffers where uncertainty is high, then baseline it so I can measure variance later.

The critical path determines the earliest possible finish and where schedule attention matters most.

• The critical path is the longest sequence of dependent activities through the schedule, and it determines the shortest possible project duration.
• It matters because any delay on a critical path task delays the whole project, while tasks off the path have some float.
• I focus my attention and risk management on critical path activities and watch for near-critical paths that could become critical if they slip.

Float shows where the schedule can absorb delay without immediately moving a successor or the project finish.

• Float is the amount of time an activity can slip without delaying its successor, called free float, or without delaying the project, called total float.
• Critical path activities have zero total float, so I use float to see where I have flexibility to reallocate resources or absorb small delays.
• Tracking float also warns me when a non-critical task is eating its slack and is about to become critical.

Dependencies stay manageable when ownership, handoff dates, relationship types, and risks are visible.

• I map dependencies explicitly, distinguishing mandatory hard logic from discretionary sequencing and internal from external dependencies, and I capture the relationship types like finish-to-start.
• For cross-team dependencies I get a committed handoff date from the owning team and track it as a milestone, because these are where schedules silently break.
• I look for chances to run work in parallel or use leads and lags to compress the timeline safely.

Resource leveling makes the schedule respect actual capacity, even when that changes the finish date.

• Resource leveling adjusts the schedule to resolve over-allocation, where a person or resource is assigned more work than they have capacity for in a period.
• I apply it when the initial schedule assumes someone works on multiple tasks at once beyond what is realistic, and I shift start dates within available float first.
• If leveling pushes past the deadline I escalate the trade-off rather than pretend the plan is achievable.

Leveling protects capacity, while smoothing evens demand without moving the committed completion date.

• Resource leveling resolves over-allocation and can extend the project end date if needed, because respecting capacity takes priority.
• Resource smoothing adjusts activities only within their available float so the completion date does not change, evening out resource peaks without breaking the deadline.
• I reach for smoothing when I want a steadier resource profile but cannot move the finish, and leveling when capacity is genuinely exceeded.

Uncertain durations need ranges, evidence, delivery-team input, and transparent assumptions.

• I use a three-point estimate, gathering optimistic, most likely, and pessimistic values and weighting them, which gives a more honest expected duration than a single guess.
• I anchor estimates in analogous past work and in the judgment of the people doing the task, and I separate effort from duration since availability stretches calendar time.
• I make the assumptions behind each estimate explicit so they can be challenged and revised.

Schedule compression is a deliberate trade-off among time, cost, and delivery risk.

• I have two main levers: crashing, where I add resources to critical path tasks to shorten them, and fast tracking, where I run sequential activities in parallel.
• Crashing costs money and has diminishing returns, while fast tracking adds risk from overlapping work that may need rework, so I model both against cost and risk.
• I only compress the critical path, since shortening tasks with float buys nothing.

Milestones are outcome-based checkpoints that make progress, approvals, and handoffs visible.

• A milestone is a zero-duration marker of a significant event, like a phase completion, an approval, or a key deliverable handoff.
• I use milestones to give stakeholders visible checkpoints, to structure payment or decision gates, and to track schedule health at a level above individual tasks.
• Meaningful milestones are tied to real outcomes, not arbitrary dates, so slipping one is a genuine signal.

A live schedule must reflect actual progress, current dependencies, and the latest forecast.

• I collect progress on a regular cadence, updating percent complete or remaining duration, and I re-run the critical path so I see the real forecast finish rather than the original plan.
• I compare against the baseline to quantify variance and I look ahead at the next tasks to confirm resources and dependencies are ready.
• A schedule nobody updates becomes fiction, so I treat maintenance as a discipline, not an afterthought.

Gantt charts communicate timing, while network diagrams expose the logic that drives timing.

• A Gantt chart shows activities against a timeline with their durations and is the best way to communicate schedule and progress to stakeholders.
• A network diagram shows the logical dependencies between activities and is how I actually calculate the critical path and analyze the flow of work.
• I use the network to build and analyze the schedule and the Gantt to communicate it.

A one-week slip requires immediate impact analysis, recovery options, and transparent communication.

• First I confirm the impact by re-running the critical path to see whether the whole project moves or float absorbs it, and I check which downstream tasks are affected.
• Then I look at recovery options like reassigning resources, fast tracking, or crashing the remaining critical path, and I weigh their cost and risk.
• I communicate the revised forecast and the options to stakeholders promptly rather than hiding the slip and hoping to recover quietly.

Buffers should reflect real uncertainty and remain visible enough to manage deliberately.

• I size buffer based on the uncertainty and risk of the activities, putting more where estimates are shaky or dependencies are external.
• Rather than padding every task, which hides slack and invites it to be consumed, I prefer a visible buffer at the end of a critical chain or before key milestones.
• I make the buffer explicit so consuming it is a tracked decision, not a silent erosion of the plan.

Risk management starts with structured identification and continues through ownership, response, and review.

• I run a risk identification session with the team and stakeholders using techniques like brainstorming, checklists, and lessons learned from similar projects, and I log everything in a risk register.
• For each risk I assess probability and impact, prioritize with a qualitative matrix, and assign an owner and a response.
• I revisit the register on a regular cadence because risk is not a one-time exercise, and new risks appear as the project evolves.

A useful risk register turns uncertainty into specific, owned, and actionable records.

• Each entry has a clear risk description in cause-and-effect terms, its probability and impact rating, the resulting priority or score, a named owner, the planned response, and a trigger that tells us it is materializing.
• I also track status and any residual risk after the response.
• A register with vague one-line risks and no owners is theater, so I keep entries specific and actionable.

Qualitative analysis prioritizes quickly, while quantitative analysis measures selected exposure numerically.

• Qualitative analysis rates risks by probability and impact on a scale to prioritize them quickly, and it is where most projects live.
• Quantitative analysis puts numbers on the prioritized risks, for example modeling their effect on cost or schedule with techniques like a Monte Carlo simulation or expected monetary value.
• I use qualitative to triage everything and quantitative selectively on the biggest risks where a numeric answer justifies the effort.

Threat responses either remove, transfer, reduce, or consciously retain the exposure.

• For threats I choose from avoid, transfer, mitigate, or accept.
• Avoid removes the cause, for example changing the plan to eliminate the risky approach; transfer shifts the impact to a third party through insurance or a contract clause; mitigate reduces probability or impact; and accept means I take no proactive action beyond a contingency reserve.
• I match the strategy to the risk's severity and the cost of the response.

Risk triggers define the observable point at which monitoring becomes action.

• A trigger is an early warning indicator that a risk is about to occur or has started, for example a vendor missing an interim date signaling a delivery risk.
• I define triggers so the team acts on a contingency plan at the right moment instead of reacting late once the impact has already hit.
• Without triggers, a risk register is passive documentation rather than an early warning system.

A risk is uncertain and future-facing, while an issue already requires action.

• A risk is a potential future event that may or may not happen, so it is managed with probability, impact, and a planned response.
• An issue is a risk that has materialized or a problem happening now, so it needs immediate action and ownership rather than a probability.
• I move risks to the issue log when they occur and manage them differently, since confusing the two leads to either panic over hypotheticals or neglect of real problems.

Contingency reserve covers identified uncertainty, while management reserve covers genuinely unforeseen work.

• Contingency reserve covers identified risks, the known unknowns, and I control it as part of the project budget and schedule.
• Management reserve covers unforeseen work, the unknown unknowns, and it usually sits above my authority with the sponsor, requiring approval to access.
• I draw on contingency when a known risk fires and I escalate to management reserve only for genuinely unanticipated events.