The following article is going to outline how to take over a project and conduct a robust project handover.
The Key Steps To Taking Over a Project
Set an Initial Timeline
Review Existing Project Documentation
Speak to Stakeholders
Clarify the Project Goals
Review Resources
Confirm Processes and Governance
A few times in my career, I’ve needed to step into in-flight IT projects, pick them up and run with them. It’s not an easy thing to do. Especially with the complexities and knowledge that you need to get to grips with as you are learning the ropes, but it can be done and can be very rewarding.
I’m going to summarise some of my learnings and try to put a little structure around how to go about a project handover.
Of course, not all projects are the same, and not all circumstances are equal, so some assumptions need to be made, but broadly speaking, the handover can be broken into six distinct parts. They aren’t necessarily sequential steps, and you may jump between them depending upon availability of stakeholders and other resources. That's ok.
Step 1: Set an Initial Timeline
So. We need to estimate and timebox the handover.
This timeline is not to be confused with the overall project plan, though it must seamlessly integrate into it. The timeline we're discussing here serves as a roadmap for how you will take over the project and ensures that all stakeholders are on the same page about the transition process.
Why is this Important?
If you're stepping into a project midway, you're not just picking up where someone else left off; you're also entering an existing workflow and perhaps even a cultural ecosystem.
A timeline ensures that you're not just reacting to what comes your way but are proactively managing the transition. A timeline also puts stakeholders at ease because they can see a plan for the change in leadership, minimising uncertainty and potential disruptions.
Having a mini-project plan for your project plan sets the right tone. Just don’t be too over the top with detail, or everyone will think they’ve engaged a weirdo.
Step 2: Review Existing Project Documentation
Ask for anything and everything the project has. Find a quiet room and some coffee, sit down and start reading.
Draft conclusions, notes and questions based on what you read. Some of these you will answer yourself as you investigate further, but much will form the basis of the stakeholder sessions and help you feel slightly more informed as you sit down to discuss things.
The documentation will, of course, depend upon the size and nature of the project and how well it has been maintained (recognising that a lack of documentation doesn’t mean the project has been poorly run or has problems).
Key Documents to Review
Project Charter / Project Initiation Document
A summary document that lays out the overall approach, objectives, plans, etc., for the project. It can be telling if these are wildly out of date by the time you get to them. If they are, they need updating and re-approval.
Project Plan
Start with the high-level plan. Find it, and ensure it covers all workstreams at the highest level.
Sometimes, you get resistance from the lower echelons, saying that a one-page project plan over-simplifies things, but that’s what we need. A nice, simple, holistic view of significant milestones and workstreams. If it doesn’t exist, it will soon need to.
Then, dive into it, ensuring just enough detail (nothing overwhelming) about the major tasks & milestones for each workstream.
Are dependencies recognised?
Are the timescales holding?
Is anything missing?
Risk Register
Is there a collection of the project risks?
Usually, the risk register is a spreadsheet that was setup early in the project and hasn’t been looked at again, but you might be pleasantly surprised.
Is it up to date, with clear risk ownership?
The tendency is for risks to be collective ownership, which is all nice and all, but they need to be owned. Someone needs to feel sweaty under the collar if a risk is open and they own it. The ownership gets them to sit up at the table and pay attention. Without it, risks are left recognised but unaddressed.
Again, the focus here needs to be on the show-stopper risks. Let the workstream leads manage and escalate any smaller risks as necessary.
Other key documents
In no particular order, here are some other documents I’d be asking about:
Decisions log
Who has made which decisions, and why? But more critically, which decisions are outstanding? More often than not, decision-making blocks project progress, so make sure it exists and is up to date.
Project History Log
It’s unlikely to exist, but it's useful if it does, but it's also a good time to get something started. This is a project diary and can be very useful in covering your arse when everyone forgets how things unfolded. It's probably something where you can get AI to create it for you as you go.
Solution Documentation
This could be a technical solution overview, or something similar. Is there an architectural plan at a high level you can see? If not, alarm bells should be ringing—agile or not…
Resource Plan
We’ll come back to this in a moment.
Roles & Responsibilities
They may be part of the project charter or other documentation, but clear R&Rs are critical.
High-level solution or design documents
These should be sufficiently high level that anyone in the project team can review them and get a reasonable understanding of the actual technical solution being put in place.
Step 3: Speak To Stakeholders
Now is the time to engage directly with all your major stakeholders on a one-to-one basis first, then if necessary, as a team.
Listen.
Absorb and digest what they say.
You may have to ask leading questions; after all, we are trying to get under the skin of things. Sometimes, you have to lead a little to get a result. I find this is normally needed for technical people. The more technical, the more I have to lead the questions and keep digging into their answers until suddenly I find some horrible truth. I don’t know why, but it seems that you need to sometimes ask questions a certain way to get to the interesting answers.
One of my key questions in this situation is always about risks and issues. I’ll maybe reach for one of the following;
What concerns you about the project?
What keeps you up at night?
Is the level of risk around the project well understood?
Recognising here that we aren’t trying to detail every little risk but pick up on the major ones. The potential show-stoppers.
If you think it helps, then I have a stakeholder analysis template that could help you identify your stakeholders and define the management plan around them. Check it out below.
Types of Stakeholders
I’d imagine you’ll have at least 4 major types of stakeholders;
Project sponsor / senior executive
This person has (or at least should have) the greatest interest in the project success, but they are likely removed from the detail. However, a chat with them can be illuminating in terms of their expectations, perceptions and understanding the level of their engagement.
Delivery lead(s)
This will be you dev team or workstream lead(s). These are the people that should be owning the various aspects of delivery.
It is always interesting here to see how much the actually know about what’s going on. Is it a lot, or very little? Do you feel they have their finger on the pulse, or are they aloof and delegate all of it.
It is crucial you have the right person here. If they don’t know what’s happening, it’s a red flag. Either they need to pull up a chair and get involved, or they need to delegate the responsibility.
Delivery teams
I strongly recommend finding time to sit and chat with those at the coalface who are actually working on the delivery. Sometimes you’ll find huge misalignment between what they believe the situation is and the level of confidence and that of the workstream lead.
User Representative
In PRINCE2 terms this is the ‘Senior User’. There’s no typically comparative role in PMBOK, but it may be the path leads back to the project sponsor, although I’d be surprised.
This is the person who is accepting the change; The person to whom it is happening.
It could be a Product Manager (not owner!) or a business unit lead. But engage with them, find out how involved and informed they are and whether they are playing a central part in guiding requirements and making key decisions about priorities.
If this role isn’t there, then the project will deliver what it thinks is right, which is almost always wrong, or at least needs better alignment with business / customer expectations.
Step 4: Clarify the Project Goals
At this point, you need to be asking the big ticket questions such as; What is this project trying to achieve?
In previous articles I’ve spoken of my preference for OKRs (Objective and Key Results). So, I like to make sure I’ve drafted the overarching OKRs for the project; What is its objective, and what are the key results (outcomes) that measure success? This can be incredibly powerful as a tool. It sharpens the focus, and has you asking simple questions which will immediately tell you if the project has significant problems or not.
Things like;
What does success look like?
Is it written down and clearly understood by everyone?
What delivery date are we aiming for, and why? (More often than not, someone has plucked some date out of the air rather than it being driven by any absolute necessity).
I want to stop here and emphasise the importance of getting crystal clear clarity on what needs to be delivered and when. I’m sure it seems like a simple thing I’m saying, and it is, but for some reason, projects are often very confused about what they are aiming for.
Once those goals are clarified, I recommend playback to all major stakeholders and those working on the delivery. Sometimes there is jaw-dropping misalignment between objectives and people due to assumptions, misunderstandings or just plain misinformation.
So, define your goal in SMART terms. Then define your key results. Play them back to major stakeholders, and then communicate them to all project members.
Step 5: Explore Resource Management
I said we’d come back to this, and here we are…
Resource management is a big area, with a lot to be said about it, but here were are really focusing on the questions to be asked and the tyres to be kicked during a project handover.
Review The Resource Plan
First up, I want to know if there is a resource plan. It’ll depend on the size and nature of the project, but I would expect to see some kind of high level view of the resources and their percentage allocation to the project.
That percentage allocation is crucial.
If you think you have a full-time architect or particular resource dedicated to your project and the reality is that they are 50%, then you are probably going to experience issues. I believe passionately in ring-fenced resources for projects.
We vastly underestimate how long things will take due to confirmation biases, and having someone split between two or three major tasks while working on a project is a pathway to failure. However, we need to be pragmatic and sometimes this isn’t a luxury we are going to be afforded.
I’ll reflect here on a recent in-flight project I was asked to consult on, and the shock as we went around each member of the team and discussed what if any other commitments they had. Most of them were working on other things. Many of them thought the other things were more important than the delivery (they weren’t). To my horror, some people had decided that it was more critical for them to deliver on a new operating structure because of the political fanfare surrounding it than it was to deliver the project successfully. The failure of one of these events would have been catastrophic, the other, an inconvenience.
So, the questions to ask are;
What percentage of your time is allocated to this project (during the current phase)?
What other conflicting priorities do you have?
Where does this project sit on that list of priorities?
What training or other resources do you need to succeed?
Left without direction, many people choose their priorities. Quite often, it's what interests them the most, not what is essential to the organisation.
Other times, people have misinterpreted management direction, for example, holding back on commitment.
If there is no resource plan, get one created. It only has to be at the highest level (perhaps by team), but list the essential resources, ensure there is understanding and a shared view of commitment, and, most importantly, the resources are aware of the expectations. It might surprise people when they find out who some of the resources are who are allocated to the project. It’s certainly been the case for me in the past.
Evaluate the Budget
I’m not going to go into tremendous detail here; apart from that, if you have a budget for your project, then now is the time to go through it with a fine-toothed comb.
I would say this:
If you can, get support from a finance team member to conduct the review.
Ensure you understand the spend profile - what is coming from the bank account and when. For most organisations, this kind of cash flow forecast is crucial.
Ensure that each line item has an associated owner. I.e. the project budget does not sit entirely with the Project Manager but with the workstream leads. The Project Manager should be coordinating, but the control of spend should be coming from those who own each item.
Step 6: Confirm Processes & Governance
Based on discussions with stakeholders, you must determine whether the current governance is acceptable. This is a broad subject and can be approached in many different ways, but you are looking for the best way to run the project going forward. This could include;
Reporting frequencies & channels
Reviewing the project team structure
Clarifying roles & responsibilities.
Hopefully, you can adapt and adopt what’s already there, but if it isn’t working, you must come at it afresh.
At the very least, I’d suggest establishing;
A reporting cycle: Both internal workstream reports on progress and external facing stakeholder updates. It will depend on how good the existing discipline is.
Communication channels: Clarify what tools and methods are being used.
Meeting frequency and attendees: Nobody likes meetings. Nobody wants to spend their days sitting in them, but they are an opportunity for everyone to sync up and talk about concerns. I’ve had to request the dissolving of an existing project team and reformation based on a much slimmed-down audience. I only want owners and decision-makers. When you have 15+ people in a room, it’s not a meeting; it’s a broadcast.
Once you have defined your governance structure, you need to communicate it. How is down to yourself, but I’d strongly recommend utilising your project sponsor here. If they endorse governance and control to the rest of the team, it will be seen as both authoritative and fair. If it comes from the project manager, it’s easier for pushback and a lack of adherence.
Conclusion
From there, it is just a case of delivering the project. No problem, huh?
Taking over a project isn’t easy, but then running a project isn’t easy. It can be frankly daunting and tiring to begin with. You’ll get overwhelmed with information and opinions, and it’s essential to always bring it back to basics.
Don’t be afraid to ask questions, regardless of how simple they seem. It’s these very questions that sometimes lead to epiphanies and breakthroughs that put you as the project manager suddenly on the map.
Comments