15 min read
As project managers (PMs), we rarely have the luxury of starting a project from scratch. Most of the time, when we manage a project, it has already been started by someone else before us. To successfully take over such projects, a project manager has to apply a certain discipline to make sure everything is taken into consideration.
In this guide, we will outline the most important steps that we think are necessary to pay attention to by dissecting our problem into five different levels:
As a project manager, you should aim to gather all relevant information in each of these categories as soon as you start the project. Some of this will happen organically as you meet your new colleagues and team members. However, other things will require you to be more proactive in setting up meetings, retrieving information, and documenting from internal sources. Whichever situation you find yourself in, we hope this guide will be a useful reference point for you in making sure you have a smooth project transition.
Company Mission and Vision
Too many PMs jump into the daily tasks without getting a good grasp of the company’s mission and vision. These terms might seem cliché or detached from the everyday reality of the employees, yet cannot be understated, especially for PMs taking projects with existing history.
In some cases—typically in smaller companies—they might not be explicitly stated altogether. Other other cases, we find the mission and vision combined into one statement—a sort of raison d’etre. However, here are two reasons why you should spend at least some time understanding both the company mission and vision when taking over a project:
- It provides a mental foundation for your high-level overview. If you don't instantly grasp the meaning, ask your direct manager to break it down for you and let them explain how they understand it. It will make internalizing the goals of the business, product, and project much easier for you.
- It provides purpose to you and your team. Which of these is more exciting?
If you internalize the company mission and vision, you will find more purpose in your daily tasks, especially when things get difficult. Moreover, you will be better equipped to inspire your team and create a shared purpose whenever necessary.
Company culture is an important aspect to look at when taking over a project, especially in a new company. Companies can have very different types of culture, which impact how people communicate and work together. This meta information about the social fabric and the relationships between different parts of the company can be very useful when trying to negotiate budgets, influence stakeholders, or simply communicate with other departments.
For example, traditional financial institutions, such as banks, tend to have a very rigid company culture that has a lot of unwritten rules about everything, from the dress code to which department has specific responsibilities or who to ask for help. This needs to be taken into account when taking over so that you can better fit in and work with your team within the cultural norms they are used to.
On the other hand, some startups have a remote culture, where people rarely meet in person. Instead, most of the social interactions happen over tools, such as Slack and JIRA. Such a “remote first” culture might be unfamiliar to the project managers coming from a more traditional project management environment. In this scenario, make sure that you have a good microphone and webcam to make the communication as seamless as possible. Also, reach out to people regularly to foster relationships.
When taking over a project, become aware of the cultural norms that exist in the new company and try to adjust your actions and management style accordingly.
Local vs. Global Decision-making
Within any company, there are decisions that a project manager can make on their own as opposed to rules and procedures that they have to follow. The procedures tend to change as a company grows. More decisions are taken globally to reduce chaos and standardize how the company operates.
This is important to understand because it will influence how you can make decisions in your project later in the project lifecycle. For example, the responsibilities of a project manager can be very different across a startup compared to an enterprise. Of course, there will always be a distribution—for example, when a PM can formulate a course of action but would need an approval from senior management.
Here are a few situations and how they would differ if decisions are made locally or globally:
|Communication tool||Teams are free to choose.||Everyone uses the same tool.|
|Vendor selection||PM can choose a vendor for non-critical areas without approvals.||All new vendors have to go through the procurement office.|
|Hiring/firing||PM manages the team within the budget available.||PM has no say over who joins or leaves the team.|
|Stakeholder update||PM updates stakeholders in their own way.||Project management office requests information from PM and updates stakeholders in a standardized way.|
|Expenses||Team managers are able to approve expenses.||Expenses are approved by the finance team or the startup founder.|
Knowing which case your company falls in to will help you to prepare for the decision-making in your project.
Business and Product Level
The Business Model
On the first days of a project takeover, you need to spend the time to create a mental high-level picture of the whole company, business, and product, and how your project fits into those. In one way or another, your company is making money to be able to carry out the mission and the vision.
You don’t need to spend a lot of time memorizing all the revenue streams and growth metrics in the initial stages of a project takeover. However, try to grasp how money moves in and out of the company as well as what the main revenue drivers and cost centers are. Also, ask around if there are any big company-wide short to mid-term goals (like entering a new market). Having knowledge about this will help you to better understand the choices that are being made and how they will impact your project in the future.
Your company will have one or multiple products that are generating revenue, and your project will be part of one of them. Understanding the product will help you better place your project within the right context. A good place to start is testing out the product yourself. Below is a list of questions you should address to get a better initial grasp of the product:
- Is the product internal or external?
- Who are the main users of the product? Are the same people buying the product?
- What stage is this product in (MVP, growing, declining)?
- How is the product marketed?
- Who are the main competitors?
Knowing answers to these questions will help you to better understand the reasons for your project and where it fits in the overall product business value chain.
One of the most important jobs of a PM is stakeholder management. Even if you are delivering on time and within budget, your team might be working on outdated stakeholder needs. Alternatively, if the stakeholders do not have enough information, they might not be invested in your project. Stakeholder management is an ongoing, daily task but there are a few important things to consider at the very beginning when taking over a project.
The Project Manager Book of Knowledge (PMBOK) has a whole chapter on identifying stakeholders with the necessary tools and methodologies. This work is very important and will take some time, but here are the most important stakeholder groups that you should be looking at on the first day:
- Project Team. This includes team members like developers, designers, QA experts, and others. Your team can provide you with a deep insight into the history of the product and business decisions and how it impacted their work previously. This can help you identify the challenges that might repeat in the future.
- Project Sponsor. This can be one person (your direct manager or a startup co-founder) or a group of people within an enterprise, who have conceived the project and secured funding for it. A project sponsor is a champion of the project and should be one of the first stakeholders you contact to get an overview of the existing project and its history.
- Portfolio Manager or Program Manager. These roles might not be present in all companies; however, these they are usually managing multiple functions and business-wise related projects at once. They will help you put your project into a wider context and figure out if there are any related projects and other PMs that you should engage.
- Customers or Users. Whether you are working on a B2C, B2B, or internal product, your project will still have some sort of a user group. If your team includes a product manager, then they should be able to provide an overview of this stakeholder group and their expectations. Otherwise, contact them to understand what’s their current feedback and what they expect of your project in the future.
Once you identified these stakeholders, you can make a RACI matrix to better understand where they fit in the overall project structure, and if and how they will impact your project.
Why Are You Taking Over?
The very first question you should ask before even looking at the budget, schedule, team, or anything else is, “Why are you taking over?” Three scenarios are most plausible:
- There was no project manager before and things started slipping through the cracks. This typically happens when a small and short project becomes bigger and longer. There might be no particular problems, just that more structure and progress visibility is needed. Implement the suggestions from this article relevant to your project.
- The project manager was removed or fired. If this is the case, then you should ask the key stakeholders where the biggest problems were and make sure you focus on those areas in the beginning. Try to find some quick wins to gain the confidence and trust of the stakeholders.
- The previous project manager left. Did the PM leave because they got a better offer somewhere but the stakeholders were happy with their work? If so, try to maintain the status quo while looking for opportunities for improvement. If the PM left because they weren’t getting along with some stakeholders then if possible, contact the previous PM and discuss this. Building rapport with the stakeholders in question will be of key importance for you.
Scope, Schedule, and Budget
Figuring out the scope of an existing project is different compared to when you are starting a new project. In the latter case, you gather requirements from stakeholders and define the scope based on the budget you have. When you are taking over, someone has presumably done this work and now your job is to understand if the defined scope is realistic and achievable.
The first natural step is to look through the existing project assets. It could be a Gantt chart, work breakdown structure (WBS), or an Agile backlog and release plan. Sometimes, you will be constrained by hours dedicated by internal company teams instead of the direct budget. In this case, try to figure out if they have any other deadlines and if your project can be delayed because of their other commitments.
Whatever you find, you have to realign the project scope and schedule with your key stakeholders. Remember the question “Why are you taking over?” Unmanaged stakeholder expectations might be the reason why the previous PM was removed. Thus, in this case, you were selected to make sure this doesn’t happen again. It might turn out that the scope, schedule, or budget are unrealistic. Come to this conclusion as early on as possible and discuss it with the project sponsor. The initial stages of project takeover are a good time to correct the mistakes made before you, but the longer you wait to resolve these problems, the more your stakeholders might question your ability to complete the project.
Finding Project Champions
While exploring the project and its stakeholders, it is important to find out more about people who are invested in your project’s success. Some of these stakeholders will be what it is sometimes called project champions.
These are the people who agree with the cause of your projects even if they are not directly responsible for it. They will go out of their way to help your project succeed. For example, if you are building a new time tracking application, project champions would be people who are interested in seeing your project completed and deployed in the company.
It’s important to identify them early because they can provide valuable insight into what is needed for your project to be successful. Sometimes they can also indirectly help you by testing out early versions of the product and providing feedback or by advocating the importance of the product to their peers.
Try and find these champions by talking to your project teammates and people who originally developed a concept for the initiative. Once found, be sure to keep them informed and updated about your project lifecycle.
Team Relationships and Structure
If you are taking over a project, the team will already be in place. You first need to treat it as a constant and figure out how the team is structured, how it operates, and who the main influencers within the team are. Was the team gathered just for this project or has it worked together in the past? Which stage the team is at—forming, storming, norming, or performing? Is the team co-located or remote? Is everyone an employee or are there contractors or freelancers who also work in the team.
All of these questions will impact on your ability to successfully manage the project and will require for you to adjust your approach along the way. For example, if your team is still in the storming phase, you will have to step in and manage the relationships of the team members to push them into normalizing them before they can reach their maximum level of performance. The team might also be at the separate stages within itself. If you have few separate offices, different parts of the team can have a very different dynamic, and you might need to put in the extra effort to normalize the team dynamic across the team but also across different locations.
Also if you have team members that are operating remotely, you will have to make sure that they are included in the conversations and day to day decision making. Otherwise, they can start feeling like they are just being assigned tasks and they are not a real part of the team. This can be mitigated by everyone using the same tools for submitting new ideas and working on them. If, for example, new ideas are submitted on Slack or another remote collaboration tool by everyone, it gives a chance for remote team members to join the discussions at the equal access level.
Team Dynamics and History
If the previous PM was removed, one reason could have been that they were not able to manage the team effectively. If that turns out to be the case, try to figure out the root causes of the problems and use the project takeover as an opportunity to restart the team relationships.
Also, gather all the informal information about the team member statuses, and their history of working with each other. This tacit information can provide some key insights into the reasons for your team’s performance or lack of it. For example, if there is a dominating member within your project that others are afraid to challenge it could be that they are a root cause of a lot of friction within the team.
Staffing and Growth Status
Having analyzed the project scope, schedule, and budget, does the project team seem adequately staffed to complete the project? If not, try to find out the reasons behind the situation. Maybe there is a blocker in the hiring process; maybe HR has not been able to find the in-demand specialists.
If that is the case, you can try to look for remote professionals or reach out to staffing agencies to fill the roles needed. Since staffing can be one of the major bottlenecks for many projects, it is important that you do it early on, therefore it’s a key thing to check when taking over the project.
Project Manager Level
Expectations for the PM
Different companies and projects have very different expectations about what project managers should do and why. To avoid confusion and disagreements later on, it is important to figure out what is expected of a PM both from the client perspective and from the perspective of all the other members of the team.
For example, some companies expect that a project manager should also be a Scrum master. Even if this is a separate role, some projects and companies have expectations that go beyond the original job description of a PM. This might not be totally clear before you start a project, so remember to probe this matter once you do.
It’s important to also figure out how project manager performance is measured and valued. Are you going to have a clear set of KPIs you are going to judge at? Or is your team’s success the only performance indicator your stakeholders will use? How often will you have performance reviews, and will you have someone who will be your mentor or a company “buddy”?
Since this impacts the project manager directly, it’s good to do this as early as possible to be able to perform according to the expectations.
Depending on what backlog your new team has in front of you, you can be hit by a procurement-related task on the first day or after three months. Even if it is the latter case, it is very important to have at least a rough idea of how procurement and vendor selection works in your company. This knowledge will let you make better decisions about backlog items and project schedule and can help you avoid unexpected delays.
Whatever the size of your company, there will be some process for procurement even if it is not written down anywhere. Ask your direct manager or other PMs how vendors are selected and confirmed. You might be required you to to create a request for proposal (RFP), rank all the submissions based on specified criteria, and choose the winner.
Alternatively, the process could be less stringent and you could be able to choose vendors independently. In this case, make sure to ask around about already existing vendors. Even though your team members have been working here for longer, they might not be aware of all the parts of the platform and the different vendors used by other teams. Also, ask your direct manager if you need to sign off with them about new vendors and how you should provide this information.
One more thing to note is the service-level agreement (SLA) expectations within your company. If your project is business critical, then you should be looking at vendors with 24-hour supports and quick problem resolution timeframes. If the expectations are not that high, then you could be looking at cheaper options with longer response times.
Create a Vendor List
If there wasn’t one in place already, start an existing vendor list for your project. You don’t have to fill it out to 100% right away. Just start a new document with the following fields:
- Name – You can hyperlink to their website.
- Category – Don’t think about this too much in the beginning, just write down what makes the most sense at the time and change it later if clearer categories emerge.
- Short description – Be brief, just enough to let you or others understand how the vendor helps you out (“e-shop payments,” “infographics freelancer”).
- Vendor contact – A good idea to keep those handy as they can get lost in emails.
- Internal contact – If there is someone in your team or the company who is keeping in contact with the vendor or a developer who has integrated a third-party solution. This would be the person who knows the most about the vendor and your company’s engagement with it.
Having this list will help you to track and manage project performance related to each vendor. Also, it will help you to have a much better grasp of the current situation in the project and where the main bottlenecks might be.
This guide and checklist is no way exhaustive; however, it tries to provide the best possible overview about the things you should check first when taking over the project. Some of them might be familiar and others might be less so, but going through all of these will make sure you have a solid foundation to take over a project.
Below is a summarized checklist you can use for your future reference.
Key Takeaways – Project Takeover Checklist
Understanding the Basics
What are the four stages of team development within a project?
Forming, storming, norming, and performing. This is according to Bruce Tuckman’s stages of group development, first proposed in 1965.
Why do project managers get assigned to existing projects?
A project manager might be assigned to an existing project because there was no PM before in the team and the project required more structured management. If there was a PM, they might have been removed because they were not competent enough for the project. Lastly, the PM might have left the company.
Which stakeholders you should engage first when taking over a project?
There are many different stakeholders in any project, all of which should be managed during a project. However, when taking over a project, you should most importantly reach out and build relationships with the project team, project sponsor, program manager, and customers or users.