Taking over an ongoing project as a Program Manager can feel like trying to jump into a moving car. You’re not starting fresh, and honestly, you’re probably not getting the clearest picture of where you’re headed. The project’s already got its own rhythm, history, and set of problems that you’ll have to pick up the pieces from.

In this post, I’m going to break down the most common struggles you’ll face when you take over a project that’s already in motion—and how I deal with it.

1. Getting a Handle on the Project’s History

Before you do anything, you need to figure out what’s been going on. Why was the project started? What decisions were made? Where’s the project at now? If the last PM, EM, or technical lead didn’t leave behind clear notes, you’re gonna have to do some detective work. The lack of context can make you feel like you’re piecing together a mystery.

It’s important to remember that a bad decision, might have been a sensible option at some point during the project. Context is either extremely important, or completely irrelevant. It really depends on your personal style and the requirements at hand. Understanding history so you don’t repeat the same mistakes can be beneficial, but at the same time, you have no reason to limit yourself because of past decisions.

Consider the following:

  • Dig through anything you can find: old meeting notes, project documents, and Slack/email conversations.
  • Get a quick rundown from the team members who’ve been around the longest.
  • Ask about the big decisions, current blockers, and what still needs to be done.
  • Understand what are the biggest risks.
  • Manage expectations from day 1. Figure out what can be delivered and what’s important.

2. Dealing with Existing Team Dynamics

Most likely, the team has already been working together, so they’ve got their own ways of getting things done. Here you are, trying to shake things up and attempt to convince them you’re not an idiot with a title. You’ll likely feel like an outsider at first, so it’s all about finding your rhythm with them without stepping on too many toes.

You might not agree with a lot of the things they do, but understanding why they are done this way and then trying to steer them into the “right” direction is a good way to quickly show respect and a willingness to integrate.

How I approach this:

  • Watch how the team interacts and how they get things done.
  • Build trust by listening to their concerns, without immediately trying to fix everything.
  • When you do need to make changes, do it gradually and make sure everyone feels heard.
  • Be mindful of team dynamics and company politics.

3. Aligning with Stakeholders and Their Expectations

Stakeholders can make or break you. Some of them may have been given outdated timelines or promises that don’t fit with where the project actually is. It’s your job to reset expectations and make sure you’re all on the same page moving forward.

Remember that they are not all necessarily on the same page and each stakeholder might have different views, expectations and requirements out of a project.

Here’s an example:

The project is called API Gateway.

  • The team building it wanted to build a custom gateway, introduce new technologies, add supporting services for the APIs and improve the quality of the APIs the organisation produces.
  • Senior management wants a centralised way to sell APIs as a product, and manage things such as billing and customer accounts.
  • The EM from a dependent team thinks the API Gateway team is just following tutorials, does no real job, and his team’s work is negatively impacted with this crap.

You cannot and should not walk into this without consolidating the views of the stakeholders (somehow) and establishing a commonly understood plan.

4. Tackling Technical Debt and Existing Issues

Let’s be real—there’s always technical debt when you inherit a project, and chances are, there’s a pile of things that haven’t been touched in a while. Whether it’s outdated code, bugs, or process inefficiencies, it’s all now your responsibility. The sooner you start addressing it, the better.

Some things to look out for:

  • Services without owners.
  • Factually incorrect documentation.
  • Things not working as people think they do.
  • Hacks and hardcoded values.
  • Limitations imposed on the system because of a hard crunch period.

5. Navigating Your Own Learning Curve

You’re gonna need to catch up quickly. From codebases to tools to industry-specific needs, there’s a lot to learn. But the faster you get up to speed, the quicker you can start making decisions and steering the project in the right direction.

Some coping mechanisms:

  • Focus on learning the project’s tech side, even if you’re not a dev. It’ll help you communicate better with the team.
  • Use your background to talk shop with engineers, so you don’t feel out of your depth.
  • Don’t be afraid to ask a lot of questions, especially about things that directly impact the project’s success.
  • They brought you on for your expertise. Highlight things that are negatively impacting the project from your point of view.
  • Build relationships with key people.
  • Have regular check-ins and syncs with key people in the project and the core stakeholders.

Wrapping It Up

Taking over an ongoing project isn’t easy, and there’s no quick fix for all the moving parts you’ll have to juggle. But if you break it down into manageable pieces, stay patient, and communicate openly, you can turn things around.

Just remember: it’s all about understanding where things have been, aligning expectations, fixing the most pressing issues, and learning quickly. Stay proactive, and you’ll make it work.

Good luck!