Taking over a project that someone else started always looks easier from the outside than it actually is. On paper, you inherit something that already exists. There’s a plan, a timeline, maybe even a set of updates and documentation. It feels like you’re stepping into something halfway done. In reality, you’re stepping into something halfway understood.
I’ve taken over projects in all sorts of states. A regulatory compliance programme in iGaming where the deadline hadn’t moved but the team had. A digital product initiative where the original owner had left suddenly. A data platform build where the documentation said one thing, but the actual system told a different story.The common thread is that you don’t just inherit the work. You inherit assumptions, decisions, gaps, and a history you were not part of. That’s what makes it difficult.
The trap most people fall into
The first instinct is usually to read everything. Go through the plan. Review the documents. Catch up on the meetings. Try to reconstruct what has already happened so you can continue from where things left off. It sounds sensible. It’s also where a lot of time gets lost.
In one programme I took over, there were weeks of status reports and multiple versions of a plan. Everything looked detailed and well-structured. But when I started asking simple questions about what was actually complete and what was still in progress, the answers didn’t match what the documents suggested. That was the moment it became clear that the documentation was not the project. It was a version of the project at a point in time. If you rely too heavily on it, you inherit the same blind spots.
Start with what is real, not what is written
The most useful thing you can do early on is to understand the current reality of the project. Not what was planned. Not what was reported. What is actually true right now. What has genuinely been completed? What is in progress but not yet usable? What is blocked? What depends on something else?
I usually start by speaking to the people doing the work rather than the people reporting on it. Engineers, analysts, operations, whoever is closest to the delivery. In a product launch I stepped into, the reporting suggested we were close to release. When I spoke directly to the team, it became clear that several key components had not been integrated and had not gone through end-to-end testing. That gap between perception and reality is common, especially when a project has been running for a while.
Understand how decisions have been made
Every project develops its own way of making decisions. Sometimes it is clear and structured. Sometimes it is informal and inconsistent. When you take over, you need to understand how decisions have been happening. Who has been involved? What gets escalated? What gets delayed? What gets quietly ignored?
In a regulatory programme I worked on, decisions were technically being made, but not always in a way that connected across the project. One team would move forward based on one assumption, while another team was working from a different version of the same requirement. No one was wrong, but the lack of alignment created rework and delays. Until you understand how decisions are currently made, it is difficult to improve how the project moves forward.
Reconnect the moving parts
By the time you take over, most projects are already fragmented. Different teams are working on different parts. Suppliers are delivering pieces. Dependencies exist, but they are not always visible. Your role is not to restart everything. It is to reconnect it.
In a data and AI implementation I stepped into, there were multiple parallel workstreams. Each one made sense individually. But they were not aligned in terms of sequencing or dependencies. We didn’t redesign the whole project. We focused on how those pieces fit together. Which ones depended on others. Which ones could move independently. Which ones were blocking progress elsewhere. That alone made the work feel more coherent.
Decide what you are keeping and what you are changing
Not everything needs to be rebuilt. One of the risks when taking over a project is overcorrecting. Changing too much too quickly can create confusion and slow things down further. At the same time, holding on to structures that are clearly not working doesn’t help either. You need to decide what is worth keeping and what needs to change.
In one iGaming product initiative, the existing structure for tracking work was actually useful. The issue was not the tool, but how priorities were being managed. We kept the structure and changed how work was sequenced and reviewed. In another case, the existing plan was so disconnected from reality that it was easier to rebuild a simpler version than to keep adjusting it.
The key is to be deliberate. Not everything is broken, but not everything is working either.
Build trust before you try to lead
When you step into a project, you are also stepping into an existing dynamic. The team has been working together. They have their own views, frustrations, and ways of doing things. Some people may be relieved you are there. Others may be sceptical. Trust is not built by immediately changing everything. It is built by understanding what is happening, listening properly, and making a few changes that actually help.
In one project, the team was clearly tired of process that didn’t add value. Instead of introducing new structures immediately, we simplified what was already there and focused on removing blockers. That made a noticeable difference, and it created space for further improvements. Without that trust, even good changes can be resisted.
Create a clear view of what happens next
Once you understand the current state, the most important thing you can do is create a clear path forward. Not a perfect long-term plan, but a realistic view of what needs to happen next. What are the key priorities? What needs to be completed first? What decisions are required? What risks need attention?
In a delayed digital project I took over, the biggest shift came from narrowing the focus. Instead of trying to move everything forward at once, we identified a smaller number of critical steps and aligned the team around them. That created momentum, which had been missing.
Accept that you are not starting from zero
One of the more subtle challenges is resisting the urge to treat the project as if it is new. It isn’t. It has history, context, and existing work. Some of that work will be useful. Some of it will not. Your job is to work with what is there, not against it. Across different types of projects, whether in iGaming, regulatory environments, or data-driven initiatives, the most effective takeovers are the ones that respect what has been done while improving how things move forward.
Taking over a project someone else started is less about control and more about understanding. Understanding what is real, what is assumed, what is working, and what is not. Once that becomes clear, the path forward usually becomes clearer as well. You don’t need to know everything that has happened. You need to know what matters now and how to move it forward.