Who is managing your project?
That should be an easy question. Yet some projects have two or three people giving directions, talking to the client, changing priorities, and each acting as though they are the project manager. The team then has to work out whose instructions to follow.
Having more people helping to manage a project can be useful. Having several people independently managing the same project can cause a lot of problems.
I believe every project needs one clearly identified lead project manager. That person should coordinate delivery, manage the client relationship, keep oversight of risks and resources, and bring the different parts of the project together. They should delegate plenty of work, but everyone should know who is leading the project.
It sounds obvious. Unfortunately, writing someone’s name in a project management plan does not always mean that this is how the project actually operates.
Problem: Several People Are Managing the Same Project
The Team Gets Conflicting Instructions
Imagine a small facility upgrade. One manager tells the designer to finish the equipment layout first so procurement can start. Another manager tells the same designer to stop that work and revise the access arrangements following a client discussion.
Both tasks might be necessary. Both managers might have good reasons for their instructions. But the designer cannot give both tasks first priority.
The designer either chooses, asks for clarification, or tries to do a bit of each. Meanwhile, the first manager assumes the equipment layout is progressing, and the second assumes the access changes are underway.
By Friday, neither task is finished and everyone wants to know why. The problem started before the designer did any work. Nobody had resolved the competing priorities or checked the effect on the rest of the project.
Client Commitments Get Made Without the Full Picture
A client asks one of your managers for an extra drawing. The manager agrees because it seems simple. Later, the client asks another manager to bring a delivery date forward. That manager also agrees.
Neither person knows about the other’s commitment. Neither has checked whether the same designer is needed for both tasks.
Now you have extra work, a shorter delivery period, and possibly no extra budget. The client believes your organisation has agreed to everything. Your team is left trying to deliver promises that were never considered together.
This is closely related to having a single decision maker in client communication. People need to know who can make commitments, and those commitments need to be coordinated.
Responsibility Falls Between the Managers
When several people share an undefined project manager role, each can assume the others are looking after something.
One thinks the other has updated the forecast. Another assumes the variation has been submitted. Everyone knows a supplier is late, but nobody has checked the effect on commissioning.
You can also get the opposite problem: two managers prepare different forecasts, contact the same contractor, or issue competing status reports. Work is duplicated while other work gets missed.
The difficulty is not necessarily a lack of effort. People may be working very hard. The difficulty is that responsibility has not been allocated clearly enough to make their effort useful.
The Official Project Manager Is Different from the Actual One
Another problem occurs when the project manager listed in the finance system is different from the person running the project.
Perhaps someone took over informally. Perhaps a department manager kept approving costs after handing the project to someone else. Or perhaps the original PM still receives the reports and answers client questions because nobody updated the contact details.
Which person is checking the total forecast? Who is responsible for reporting? Who is authorised to issue instructions?
This becomes particularly confusing during handover or when a project crosses departments. An informal arrangement can continue for months, until something goes wrong and everyone suddenly wants to establish who was responsible.
Solution: Appoint One Lead Project Manager and Make the Role Clear
Define the Project and Name Its Lead PM
Start by confirming what the project includes and who is responsible for managing its delivery. Record the lead project manager in the project management plan, organisation chart, contact list and relevant business systems.
Tell the team, client, sponsor and contractors. Make the appointment clear at the startup meeting, and repeat it when new people join.
The practical test is simple: if you ask several people who the project manager is, you should get the same answer.
On a large project, there may be package managers, deputy PMs, design managers and construction managers. Each can manage a defined area. Their roles should show how they report to the lead PM and how decisions affecting other areas are resolved.
My post on why your project needs a project management plan covers the basic information that helps a team understand how its project will operate.
Give the PM Authority That Matches the Role
Appointing someone as project manager is only useful if they can actually manage.
Clarify what they can approve, what they can direct, and what they must escalate. This includes expenditure, resource allocation, procurement, variations and commitments to the client.
The PM might have authority to make small purchases within the approved budget, but need sponsor approval for additional funding. They might set priorities for agreed project resources, but need a department manager’s agreement to obtain more people. Put these arrangements in writing. Include approval limits and the person responsible for decisions beyond those limits.
A project manager who must chase several managers for every minor decision will struggle to keep work moving. Allow for the approval process in your schedule, and make sure urgent decisions have a clear escalation route.
Accountability should be agreed from the start, together with the authority, information and support needed to do the job.
Delegate Work and Define the Boundaries
One project manager cannot do everything, and should not try.
The PM should maintain oversight of the client relationship, project risks, resources, cost, schedule and overall delivery. Much of the detailed work should be delegated to people with the right skills.
For each delegated area, agree on:
- The scope and deliverables.
- The person responsible for the work.
- The budget or hours available and required completion dates.
- The decisions they can make independently.
- The matters they must refer to the PM.
- The information they must report and when.
For example, the design manager can coordinate design activities and technical reviews. The planner can maintain the schedule. The cost controller can prepare forecasts. These people need enough authority to perform their roles without asking permission for every routine action.
However, a design decision that delays procurement or increases installation costs needs consideration across the project. The lead PM makes sure the affected people are involved and obtains the necessary approvals.
See also 5 Reasons Why Clear Project Roles and Responsibilities Are Important.
Use a RACI Where It Helps
For projects involving several departments, a responsibility matrix can help explain the arrangement.
A RACI identifies who is Responsible for doing an activity, Accountable for it, Consulted about it, and Informed of it. Atlassian’s guide to RACI charts provides a useful explanation and examples.
Apply it to specific activities and decisions. Avoid putting the PM in every box simply because they lead the project. A technical authority may be accountable for technical approval, while a sponsor authorises a funding increase.
The matrix should make the work easier to manage. If people need a meeting to interpret every row, simplify it.
Most importantly, talk through the responsibilities with the people named. A spreadsheet stored in a folder does not establish agreement by itself.
Keep Client Communication Coordinated
Your client should know who their primary project contact is, who can agree to changes, and who will provide the overall project status.
This does not mean the PM must personally relay every technical question. Engineers, designers and construction staff often need to speak directly with their client counterparts to get work done efficiently.
Agree on those communication channels. Make the limits clear. Discussing a technical option does not automatically authorise a change to the agreed scope or delivery date.
If a request affects cost, scope, schedule or risk, bring it to the PM for coordination through the agreed approval process. Record the decision and tell the affected people before they act on it.
The same clarity is useful during procurement. As I explain in having a single contact person in tender requests and offers, a clearly identified primary contact helps avoid conflicting answers.
Keep One Agreed View of the Project
The project needs a coordinated schedule, cost forecast and status report. Specialist teams can maintain supporting information, but it must feed into the overall project position. Otherwise, design can report that it is on schedule while construction is already waiting for drawings. Procurement can report a saving while the cheaper equipment creates additional installation costs.
The PM should regularly review the combined position with the team. Check dependencies, outstanding approvals, emerging risks and commitments made since the previous review.
Use a project communication, decision and action register to help track important agreements and follow-up work. Assign owners and due dates, and check that actions are completed.
Having one lead PM does not remove the need for reporting. It gives someone a clear responsibility to bring that reporting together and act on what it shows.
Make Deputies and Handover Arrangements Explicit
A deputy project manager can be very useful. They can manage delegated areas, help coordinate the team, and provide cover when the PM is away.
Agree whether the deputy is supporting the PM or acting in their place. If they are acting, specify the dates, authority limits and reporting arrangements. Give them access to the information they need.
When the PM returns, review decisions, commitments and unresolved issues. The team should not have to guess whether the temporary arrangement has ended.
For a permanent change, use a formal handover with a written status summary and signed acceptance. Record the effective date, outstanding risks, current forecast, pending variations and upcoming commitments. Update the business systems and tell stakeholders who now leads the project.
A handover period can involve two people working together. It still needs a clear point at which responsibility transfers.
Keep Sponsors and Senior Managers in Their Roles
The sponsor and senior managers have important responsibilities. They provide direction, approve matters within their authority, resolve escalated problems and challenge project performance.
The sponsor’s accountability for the business case and benefits is different from the PM’s responsibility for coordinating delivery. The Association for Project Management discusses this distinction in its article on project sponsorship and delivery responsibilities.
Trouble starts when a senior manager gives instructions directly to project staff without coordinating with the PM. Even a helpful instruction can change priorities or create commitments elsewhere.
Agree how these directions will be communicated and recorded. If the PM is not performing, address that openly through the management process. Quietly creating a second management channel makes it harder to establish what is happening and who needs to correct it.
Allow for Client, Contractor and Package Project Managers
A client PM and a contractor PM can work on the same overall undertaking without breaking this principle. They manage different organisational responsibilities and contractual scopes.
A major program can also contain several projects, each with its own PM. A large project may have package PMs reporting to an overall delivery lead.
Define those boundaries and interfaces. Make it clear who coordinates the combined schedule, who resolves conflicts between packages, and which party can issue or accept contractual directions.
The problem is overlapping authority over the same delivery scope. Simply counting how many people have “project manager” in their job title will not tell you whether the arrangement works.
Support the PM Without Creating a Bottleneck
If the PM is overloaded, first look at their workload. Are they spending hours formatting reports, arranging meetings or doing technical work that others could manage?
Provide administrative help, planning support, cost control or a deputy as needed. Review whether their delegated decisions are too limited. Make routine information easy for the team to access.
The PM should trust specialists to do their work, listen when people raise concerns, and resolve conflicts promptly. Having one lead does not remove technical review, independent assurance, safety responsibilities or escalation rights.
A useful check is to ask the team whether they know what they can decide and where to take a problem. If every task waits for the PM, improve delegation. If people receive competing instructions, clarify authority.
Lesson: Make It Clear Who Is Managing the Project
Only have one clearly identified lead project manager for a defined project delivery scope.
Give that person the authority and support to coordinate the work. Delegate tasks and specialist responsibilities, but make the boundaries clear. Ensure the client, team and senior managers understand how decisions are made and how conflicting priorities are resolved.
Keep the appointment accurate in your plans and systems. When responsibility changes, document the handover and tell everyone affected.
A project needs plenty of people contributing ideas, expertise and effort. It also needs someone bringing those contributions together into an achievable plan.
If your team cannot confidently answer “Who is managing this project?”, sort that out before the next instruction, promise or scope change makes the answer even less clear.
