Quick Answer

Taking over an existing project means stepping into work already in motion and answering two questions before you change anything. What state is the project really in, and is there a plan clear enough to follow? Confirm your authority, read everything, and meet the sponsor and team first. The answers tell you whether to sustain, document, recover, or reset.

How do you take over an existing project?

Projects change hands for ordinary reasons, like a reorganization or a resignation. Sometimes the project is in trouble and you are the fix. Either way, a team and a sponsor are watching your first moves.

A takeover is not a fresh start. Decisions and commitments came with the project, often for reasons nobody wrote down. Find out what is true before you decide what to change.

The seven performance domains in the PMBOK® Guide, Eighth Edition make a practical takeover checklist:

  • Governance: the charter, your authority, the sponsor, and who signs off on what
  • Scope: the vision, the objectives, and what done looks like
  • Schedule: the baseline, actual progress, and the next real milestone
  • Finance: the approved budget, spend to date, and open commitments
  • Stakeholders: who expects what, how often, and through which channel
  • Resources: who is assigned, for how long, and what the PMO can tell you
  • Risk: the risk register, the issue log, and pending change requests

Play the newcomer card while you have it. Asking for old invoices and status reports is expected in week one and awkward in month three.

A two by two matrix for choosing your first move on an inherited project Columns ask whether the plan is unclear or clear. Rows ask whether delivery is on track or troubled. On track with an unclear plan: document, write the plan down before the knowledge leaves. On track with a clear plan: sustain, keep the cadence and change little. Troubled with an unclear plan, highlighted in orange: reset, stop committing to dates and rebuild the plan with the sponsor. Troubled with a clear plan: recover, find the cause and show the sponsor the variance early. Two questions decide your first move on an inherited project Plan unclear or missing Plan clear and current On track delivery is healthy Troubled slipping or at risk Document The work is going well, but the plan lives in people's heads. Write it down before that knowledge walks out the door. Sustain Keep the cadence the team already trusts. Learn the people, confirm the baseline, and change as little as you can. Reset Stop committing to dates. Rebuild the plan with the sponsor and team, then set a new baseline through change control. Recover The plan is sound and execution slipped. Find the cause, show the sponsor the variance early, and work back to baseline. Place the project honestly in your first two weeks. The quadrant tells you whether to protect, write down, repair, or rebuild.
PMTraining framework showing how plan clarity and delivery health point to your first move on an inherited project. Scenario is illustrative.

How it works in practice

A warehouse fit-out that quietly ran over budget. A project manager inherits a distribution center fit-out mid-project. The charter and schedule are solid, but nobody has reconciled the budget in two months. Invoices show committed costs 12% above what was last reported. The plan is sound and execution slipped, so the move is recover. The new manager takes the variance and a recovery option to the sponsor in week two, not at the next quarterly review.

A mobile app team after a reorganization. Imagine a delivery lead who inherits an agile team mid-release. The team is shipping, but there is no written release goal and the backlog holds 300 unordered items. Delivery is healthy and the plan lives in people's heads, so the move is document. One refinement session produces a release goal and an ordered backlog. Nothing else changes for two sprints.

We often see new project managers try to prove themselves with a big change in week one. The ones who look good usually spend that week listening.

Where to learn more

A Guide to the Project Management Body of Knowledge (PMBOK® Guide) is the primary home for this work. The Eighth Edition, published in November 2025, organizes practice into the seven performance domains used above and expands its coverage of PMOs, often the best record of an inherited project's history.

The Agile Practice Guide, co-published by PMI and the Agile Alliance, helps when you inherit an iterative team. It shows how agile teams keep their plan in backlogs and working agreements, which tells you where to look when the paperwork is thin.

Frequently Asked Questions

What should you do in your first week on an inherited project?

Listen and read. Confirm your authority and what success means with the sponsor, meet each team lead, and collect every document. Hold major changes until you can answer the two takeover questions with evidence.

Should you rebaseline a project you inherit?

Only when the evidence says the current baseline cannot be met. If the plan is sound and execution slipped, recover against the baseline you have. If the plan never matched reality, bring the sponsor a new baseline with the reasons, and run it through change control.

Conclusion and next steps

Looking good on a takeover is mostly discipline. Answer the two questions and choose the move that fits. Never blame the last project manager. The team worked for them, and they are watching how you talk about it.

Our live PMP certification classes work through governance, stakeholder engagement, and recovery scenarios with an experienced instructor, so you practice the judgment a takeover demands.

About the Author

Christopher Scordo, PMP, ITIL, is Founder and Managing Director of PMTraining, a PMI Premier Authorized Training Partner that has trained more than 175,000 professionals. More about the team.

Related reading: 11 Steps to Remember when Rescuing a Project and Who are Our Project Stakeholders (And What Do They Want).

Sources:

Project Management Institute, A Guide to the Project Management Body of Knowledge (PMBOK® Guide), Eighth Edition

Project Management Institute and Agile Alliance, Agile Practice Guide