Monday, status review on a programme replacing an order management platform at a mid-sized distributor in Rotterdam. The client’s project manager puts the burn-up chart on screen and asks why the warehouse integration has slipped by two sprints. The delivery manager from the nearshore vendor explains that the team was waiting for a decision on the data format. The client’s business analyst says the decision was made ten days ago; it just never reached the vendor’s engineers. Everyone is right, and everyone has a status report. The reports do not match.
Fifteen minutes later the meeting ends with three action items and no answer to the one question that matters: who in this project decides the deadline, and who is accountable when it is missed? On paper there are two people with “manager” in their title. In practice, accountability has dissolved at exactly the point where their responsibilities meet.
This article is for programme managers and project managers who work with an external team, or who are about to choose a vendor. It defends a position many vendors will push back on: in a project with an external team billed on time and materials, accountability for the project outcome stays with the client and cannot be bought along with a delivery manager. A vendor-side delivery manager is valuable only when the role has its own, clearly separated scope: staffing, continuity and the quality of the vendor’s people. When it duplicates the client’s project manager, it becomes overhead the client pays for twice: once on the invoice and once in slower decisions.
What is the difference between a delivery manager and a project manager, and why the confusion?
Project manager is the older and far better defined of the two roles. It owns the project as a whole: objective, scope, schedule, budget, risks, stakeholder communication and acceptance. Every project management framework has it, from PRINCE2 to the PMI standards, and an entire certification industry is built around it, which we looked at in our article on whether the PMP is worth it in IT.
Delivery manager is younger and much less precise. In product companies and in government digital teams it usually means the person who looks after how an agile team works. The UK GOV.UK Service Manual (last updated 6 November 2023) describes the delivery manager as someone who sets up the agile environment the team needs, removes blockers to progress and helps the team become better at organising its own work. Priorities, the goal of the service and accepting user stories belong, in the same document, to a separate product manager role.
At IT services firms, the same title often means something else: the person on the vendor side responsible for the client relationship and for the vendor keeping its promises. Staffing, attrition, cover, billing, the quality of the consultants’ work, contractual escalations. The role may also be called account manager, service delivery manager or engagement manager. The scope is similar.
The confusion arises because both meanings meet in one project. The client hears “delivery manager” and understands “someone who will deliver the project”. The vendor says “delivery manager” and means “someone who looks after our side of the contract”. Unless someone pins this down at the start, each side assumes the other is steering.
Why can’t accountability for the project outcome move to the vendor in staff augmentation?
Because accountability follows decision rights. In staff augmentation, a specialist joins the client’s team and works to the client’s processes and priorities. That is how any honest description of the model reads, including our page on staff augmentation services: the client directs the specialist’s work, and the vendor is responsible for selection, the contract, billing and continuity of staffing. If the client decides what the team does this week, the client is accountable for whether the right thing gets built in the right order.
The same logic applies to any time-and-materials engagement, including when the vendor supplies a whole team. The vendor sells time and capability, not an outcome. It can commit to quality of work, availability and fast replacement, but not to a feature being ready by the end of the quarter, because it controls neither scope, nor priorities, nor the decisions the date depends on. For the vendor to own the date, it would have to take over those decisions, and then the engagement is no longer staff augmentation but a project with a defined scope.
There is also a legal dimension that international buyers should not ignore. Under section 1(1) of Germany’s Temporary Agency Work Act (AÜG), workers count as leased when they are integrated into the hirer’s work organisation and subject to its instructions, and leasing workers commercially requires a permit. Other EU countries and the UK have their own tests for who directs a contractor’s work. The practical point for a programme manager is not to give legal advice but to recognise that “who directs the work” is a question with contractual and regulatory weight, and the role split should be designed deliberately and checked with counsel, not left to grow on its own.
The first practical consequence is this. A vendor delivery manager who promises to “deliver the project” in this model is promising something they cannot guarantee. Not because they are weak, but because they lack the authority. They can speed up staffing, arrange cover, improve a specific person’s performance. They cannot decide that the warehouse integration matters more than the new reporting module.
The second consequence is less obvious. A client that buys a delivery manager believing it is transferring project risk stops investing in its own project manager. The client-side role gets filled “on the side” by someone with other responsibilities. Then the two roles do not overlap; both are incomplete. The delivery manager has no right to decide, and the client-side person has no time to.
If you really want to transfer risk to the vendor, you need a different contract model, one where the vendor takes on scope and is accountable for the result. That has its own price, as we argue in our article on who really pays for risk transfer in fixed price. Adding a role to the proposal does not substitute for it.
What do Scrum, PRINCE2 and PMI say about who runs the project?
It is worth going back to the sources, because each solves the problem differently, and teams mix the approaches without noticing that their assumptions contradict each other.
The Scrum Guide, in its November 2020 version, does not have a project manager role at all. It defines three accountabilities within the Scrum Team: the Developers, the Product Owner and the Scrum Master. It says explicitly that within a Scrum Team there are no sub-teams or hierarchies, that the Product Owner is one person, not a committee, and that the Product Owner is accountable for maximising the value of the product. Scrum says nothing about clients and vendors. If half the developers come from a vendor, Scrum treats them as members of the same team, not as a separate structure with its own manager. From that point of view, a vendor delivery manager running “their” part of the team is exactly the kind of sub-team the guide rules out.
PRINCE2 takes the opposite approach and, importantly for this topic, provides for the supplier relationship explicitly. The project board brings together three roles: the Executive representing the business, the Senior User representing users, and the Senior Supplier representing those who supply the work. The project manager runs the project day to day and reports to the board. Team managers are responsible for producing the products, and they may come either from the commissioning organisation or from an external supplier. The latest, seventh edition of PRINCE2 was published in 2023; the method is now owned by PeopleCert, which acquired AXELOS in 2021.
This is the closest official equivalent to a vendor delivery manager: a team manager on the supplier side, accountable for producing agreed work packages, not for the project. The project has one project manager and one board, on which the supplier has a voice but not the final word.
The PMI standards have changed a great deal in recent years. The seventh edition of the PMBOK Guide in 2021 replaced the ten knowledge areas with twelve principles, and the eighth edition in 2025 moved to six principles and seven performance domains. One tool that matters here has survived the changes: the RACI matrix, also called a responsibility assignment matrix, was described in both the fifth edition of 2013 and the seventh of 2021. Its purpose is to make clear, for each activity, who does the work and who answers for the result.
The conclusion from the comparison is simple. Scrum dissolves the manager role into the team and the Product Owner, with no sub-teams or hierarchies. PRINCE2 has one project manager, with team managers, including supplier ones, working under that role. The RACI tool from the PMI tradition exists precisely so that accountability for a result does not split across two people. The model “client PM plus vendor DM, both accountable for the project” has no basis in any of these sources. It is the product of a commercial negotiation, not of organisational design.
What does the client-side project manager own?
Simply put: everything the client cannot hand over because its business depends on it. Scope and changes to it. The release plan and the milestones promised to the board or to end customers. The budget and its burn. Project risks as a whole, including risks sitting with other departments and other vendors. Communication with stakeholders who never attend the daily stand-up. Acceptance, and the decision that something is done.
On top of that comes a task that is routinely underestimated in projects with external teams: making sure decisions are made on time. A vendor team, however good, will not decide the data format, the business rules or the priorities, because it has no mandate to. Every unanswered question is time the client pays for while the team either works on something less important or waits. A programme manager who tracks team velocity but not the time from question to decision is looking at half the problem.
In an agile project, part of this load moves to a client-side Product Owner, who decides the order of work in the backlog. That does not change the substance: whatever the client calls its roles, someone on the client side must have both the right and the time to decide. If you are unsure whether the client side needs a business analyst or a systems analyst to prepare those decisions, our article on business analyst vs systems analyst will help.
What should the client’s project manager not do? Manage the vendor’s contract from the inside: check whether a consultant has the right line manager at the vendor, sort out the vendor’s HR issues, negotiate holiday cover. It is not their employer and not their toolset. If they end up doing it themselves, the role on the other side either does not work or does not exist.
What does the vendor-side delivery manager own?
The vendor keeping promises that can be measured independently of the project outcome. Five areas recur in every well-defined scope.
Staffing. Finding people for the roles the client described, within the agreed time. At ARDURA, the standard process to a specialist starting work takes two weeks, and urgent placements from a pre-vetted pool take 48–72 hours. Someone on the vendor side has to hit those timelines and react when a profile proves harder to fill than expected.
Continuity and cover. Holidays, sickness, departures, internal reassignments at the vendor. This is where a delivery manager earns their rate or does not. ARDURA offers a two-week replacement guarantee at no extra cost and, if a specialist leaves during the engagement, a replacement within five business days. A guarantee in the contract is one thing; someone who acts on it before the client has to ask is another.
Quality of the vendor’s people’s work. Not product quality, which belongs to the whole team under the client’s direction, but whether each consultant performs at the level the client is paying for: whether they grow, follow the client’s standards and respond to feedback. The delivery manager gathers that feedback and acts before the client runs out of patience.
Billing and formalities. Timesheets, invoices, contract compliance, confidentiality, access, the vendor’s own security obligations. Dull, but each can stall a project for days.
Contractual escalation. When something is wrong at the level of the contract rather than the task, the client needs one address on the vendor side with authority to act: change a person, change headcount, change terms.
Notice what is not on this list. No priorities, scope, release plan or acceptance. The delivery manager can advise on them, because they see the team up close and know its pace, but the decisions belong to the client. At ARDURA, in staff augmentation this function is performed by a dedicated account manager on our side who monitors the engagement, collects feedback and steps in when something is not working, while the client directs the specialist’s work. That split is deliberate, not a saving.
What does a RACI matrix look like for a project with an external team?
A RACI matrix is the simplest tool that forces both sides to name who does what. Four letters: R (Responsible) does the work, A (Accountable) answers for the result and signs it off, C (Consulted) is asked before a decision, I (Informed) is told after it. Common practice is exactly one A per activity. Some authors treat that as a rule and others as a recommendation, but in a project spanning two organisations, breaking it is the simplest recipe for a dispute.
The matrix below describes a typical time-and-materials engagement in which the vendor supplies a team of several people and the client directs its work. The client and vendor columns are kept apart on purpose.
| Activity or decision | Client sponsor | Client project manager | Vendor delivery manager | Vendor team (tech lead) |
|---|---|---|---|---|
| Project objective, scope and budget | A | R | I | C |
| Priorities and backlog order | A (or Product Owner) | R | C | C |
| Schedule, milestones, release plan | I | A/R | C | C |
| Definition of done and quality standards | I | A | C | R |
| Project-level risks | I | A/R | C | C |
| Progress report to the board | I | A/R | C | I |
| Selecting and replacing vendor specialists | I | C | A/R | I |
| Staffing continuity: holidays, cover, departures | — | I | A/R | C |
| Development and appraisal of vendor staff | — | C | A/R | R |
| Timesheets and billing | — | A (approves hours) | R | R |
| Acceptance of work | A | R | I | C |
| Contract-level escalation | A | R | R | I |
Three things in the table matter more than the rest. First, the vendor delivery manager has no A in any row about the project, and every A in the rows about staffing and people. Second, the client’s project manager holds the A on approving hours, because the client pays for time and only the client knows whether that time went on the right things. Third, both sides hold an R in contract-level escalation, but the A sits with the client sponsor, who ultimately decides whether to change or end the contract.
If in your project the vendor’s delivery manager holds the A for the schedule or for priorities while the vendor bills on time and materials, the matrix exposes a contradiction no status meeting will fix: someone is accountable for decisions they cannot make. When the matrix also needs to reflect people outside the project team, such as compliance, operations or the client’s own customers, the glossary entry on stakeholder management covers the basics of mapping them.
When is a vendor-side delivery manager worth it?
When their work gives the client something the client’s project manager will not do, or will do worse. Five situations meet that test. A similar accountability line applies to a contract solution architect, and team continuity can be measured as described in specialist attrition in outsourcing.
The vendor is accountable for an outcome. In a fixed-scope or fixed-price project, the vendor takes over decisions about how to deliver the agreed scope and needs its own project lead to do so. In that case the vendor side really has a project manager, whatever the business card says, and the client side keeps the roles of contract owner and acceptor. That is a fair split, as long as everyone calls it what it is.
The vendor team is large and mixed. When several people in different roles come from the vendor (developers, QA, DevOps, an analyst), the number of staffing issues, cover arrangements and development conversations grows faster than headcount. Fred Brooks pointed to the simple arithmetic in “The Mythical Man-Month” (1975): a group of n people has n(n−1)/2 communication channels. Five people have 10 channels; ten people have 45. Someone on the vendor side who takes part of that load genuinely relieves the client.
Several vendors work on the same programme. Each needs a single point of contact who knows its commitments and can enforce them inside its own company. The client’s project manager coordinates the programme; each vendor’s delivery manager answers for that vendor’s part. We discuss this set-up in more depth in our piece on quality and risk in multi-vendor IT projects.
Staffing changes often. A project that scales up and down every quarter, or needs rare skills for short periods, requires continuous staffing management. Without someone on the vendor side doing it proactively, the client’s project manager ends up spending half their time on recruitment they were never meant to run.
The client has no one to put in the project manager role. This is the only situation in which replacing a client role with a vendor role makes sense, but it needs honest labelling: the client is not buying a delivery manager, it is hiring a project manager to work on its side, in its name and with its mandate. That person belongs in the client column of the RACI matrix, not the vendor’s, and should report to the client sponsor, not to their employer.
When does a delivery manager become overhead?
When the client pays for a role that relays information instead of making decisions. The numbers make this easiest to see.
An illustrative example based on ARDURA’s pricing: a senior project manager costs EUR 355–485 per day and a senior backend developer EUR 335–485. Take the midpoints (EUR 420 and EUR 410) and 21 working days a month. Three senior backend engineers cost about EUR 25,800 a month. A half-time delivery manager billed separately costs about EUR 4,400, which is roughly 17% of the team’s cost. With eight senior engineers the team costs about EUR 68,900 and the same half-time role is about 6%. Comparable rates for engineers based in Western Europe or the US would be higher, but the ratio, and the argument, stay the same.
These figures do not say that a delivery manager is expensive. They say that with a small team the role has to deliver a lot to pay for itself. With three engineers, it would need to raise the team’s throughput by roughly a sixth, or save the client the equivalent of several working days a month, just to break even. If its contribution is a weekly report that repeats what the task tracker already shows, plus attendance at meetings the client’s project manager already attends, it will not.
The overhead has a second, hidden component: decision time. Every extra intermediary between the team and the person who decides lengthens the path of a question. When a vendor engineer asks the delivery manager about a business rule, who asks the client’s project manager, who asks the analyst, the answer comes back in two days instead of two hours. In staff augmentation, specialists should ask the client-side person who knows the answer directly. The delivery manager should not be on that path at all.
The warning signs are fairly consistent. The delivery manager has no authority over staffing decisions at the vendor and “checks with head office” on everything. The delivery manager’s report and the client project manager’s report show different numbers and nobody knows which is right. The delivery manager runs separate planning sessions with the vendor’s people, parallel to the client’s planning. The vendor team receives tasks from two sources.
The overhead need not appear as a separate line item. Often the delivery manager is “included in the rates”. That is convenient, but it does not exempt you from asking what the role does. If it is included, you pay for it in every hour of every specialist, so it is worth knowing whether the vendor offers it as value or as its own cost passed on to the client.
How does the contract model change the split between client and vendor?
The contract model determines who has decision rights, and therefore where accountability should sit. The table below covers the three most common set-ups.
| Engagement model | Who is accountable for the project outcome | Role on the vendor side | When a separate delivery manager makes sense |
|---|---|---|---|
| Staff augmentation (1–4 specialists in the client team) | Client (project manager and sponsor) | Account manager: staffing, cover, billing | Rarely; an account manager is usually enough |
| Dedicated team on time and materials | Client, with active input from the vendor’s tech lead | Delivery manager or team manager in the PRINCE2 sense | When the team spans several roles and its composition changes often |
| Fixed-scope or fixed-price project | Vendor within the scope; client for the business objective and acceptance | Vendor project manager | Always, but called a project manager outright |
In the first row, a full-time delivery manager is usually overkill. The specialists work inside the client’s team, tools and rhythm, and the vendor’s side of things can be handled through short, regular contact with an account manager. In the second row the role starts to make sense, but you have to make sure it does not absorb project decisions. In the third it is essential, but then it is honestly called a project manager and owns the scope, while the client has a contract manager who accepts deliverables and guards the business objective.
The trouble starts when the contract comes from the first or second row and the expectations from the third. The client pays for time but expects the vendor to “deliver”. The vendor puts forward a delivery manager to meet those expectations but never receives decision rights. After a few months both sides are disappointed, even though each is doing exactly what the contract says.
How the team works matters too. In Scrum there is practically no room for a separate manager of the vendor’s people inside the team, because the team is meant to be one, with no sub-teams. In Kanban, where a team often works in a more service-like way with continuous flow, it is easier to draw the boundary of what the vendor owns. How to match the working method to the type of work is covered in our article on Kanban vs Scrum.
What signals show that roles overlap, or that nobody is steering?
Programme managers usually learn about a role-split problem too late, because the symptoms look like team performance issues. A few signals appear earlier.
Two status reports on the same thing. If the client’s project manager and the vendor’s delivery manager prepare separate reports for different audiences, the numbers will diverge sooner or later. One report, one data source, one person accountable for its content. The delivery manager can add a section on staffing and continuity.
The vendor team asks “who should I ask?”. That question appears when vendor specialists have two bosses for task matters. The rule should be unambiguous: for work, ask the client-side person; for employment and development, ask the vendor-side person.
Time from question to decision keeps growing. Most projects do not measure it, yet it shows better than anything whether someone on the client side is steering. Tag tasks blocked on a decision in your tracker and count the days they spend there. If the average rises month after month, the problem is not in the vendor team.
Escalations take the long way round. When the client sponsor hears about a staffing problem from the vendor’s leadership rather than from the project manager, information has bypassed the place it should have gone through. Usually that is because the delivery manager reports into their own company and the client’s project manager does not know there is a problem.
Nobody owns the delay. The most telling signal of all. Ask “why are we late?” and each side points at the other, often with partial justification. That is exactly the meeting this article opened with. The answer is not better communication; it is a single A in the RACI matrix next to the schedule.
When these signals appear, run a short retrospective of the collaboration, not just of the team’s work. An hour with the client’s project manager, the vendor’s delivery manager and the sponsor, with the RACI matrix on screen, is usually enough to see where the contradiction lies.
What should go into the contract and the first week of the engagement?
A role split agreed in a meeting and never written down survives until the first change of personnel on either side. So turn it into documents, and keep them short.
In the contract or a ways-of-working annex:
- who on the vendor side is the contact for staffing matters, and what they can decide (replace a person, arrange cover, change headcount) without referring to the vendor’s leadership;
- response times: how long the vendor has to present a candidate, to provide cover when someone leaves, to replace a person who does not fit the team; at ARDURA these are 48–72 hours for urgent placements from the pre-vetted pool, a two-week replacement guarantee and a replacement within five business days;
- whether the delivery manager or account manager role is included in the rates or billed separately, and how much of their time you get;
- notice periods and the rules for scaling down; at ARDURA, scaling down requires 30 days’ notice, with no penalties;
- the format and frequency of the vendor’s report on what the vendor owns: staffing, continuity, cover, open issues.
In the minutes of the first week:
- the RACI matrix for this specific project, with names, not just roles;
- one source of truth for tasks and progress, used by both sides;
- a question path: whom a vendor specialist goes to on subject matter, and whom on employment matters;
- a three-step escalation path: team level, project manager and delivery manager level, sponsor and vendor leadership level, with a response time at each;
- the date of the first collaboration review, ideally after four to six weeks, with a direct question: is the role split working the way we wrote it down?
Two things are easy to overlook. First, who stands in for the client’s project manager when they are away. Without that, two weeks of holiday mean two weeks in which the vendor’s delivery manager is de facto running the project, because nobody else is making decisions. Second, who on the client side onboards new vendor team members into the business domain. The vendor can prepare a person technically, but it does not know the client’s business rules.
How do you move from the current set-up to a clear split without replacing anyone?
Most programme managers do not start from scratch. The project is under way, the roles are filled, and the division of accountability has formed on its own. Changing it does not require new people, only naming what exists and fixing a few places.
Step one: record the current state. Take the RACI table from this article and fill it in the way the project works today, not the way it should. Ask the client’s project manager and the vendor’s delivery manager to do it separately. The differences between the two versions show where the sides hold different assumptions.
Step two: find rows with two As or none. Those are where the project is losing time. For each, decide who holds decision rights under this contract model. On time and materials, project decisions go to the client and decisions about the vendor’s people go to the vendor.
Step three: cost the vendor role against what it delivers. If the delivery manager is billed separately, set their cost against what they actually do in their own column: staffing, continuity, quality of people, billing. If most of their time goes on items in the client project manager’s column, you have two options: move those tasks to the client and reduce the role, or accept openly that you are hiring a project manager and move that person into the client column with a full mandate.
Step four: consolidate reporting. One report, one data source. The vendor’s part covers staffing, continuity and open issues on its side. The metrics worth tracking come from both columns: for the client, delivery throughput and time from question to decision; for the vendor, time to fill a role, time to cover and team stability.
Step five: check after a month. Go back to the matrix and ask the vendor team whether they know whom to ask about what. If the answers agree, the split works. If not, go back to step two.
Such a change rarely needs a contract renegotiation, just an addendum or meeting minutes, and takes a few weeks. Hardly anyone loses. A delivery manager who stops duplicating the project manager has more time for what their company is actually accountable for. The client’s project manager regains control of the decisions they were accountable for anyway.
How do you assess a vendor proposal that includes a delivery manager?
At vendor selection, a few questions quickly reveal what the delivery manager in a given proposal really is.
What exactly is the scope of the role, item by item? A good answer covers staffing, continuity, cover, the quality of the vendor’s people and billing. “They make sure the project succeeds” is a warning sign, because on time and materials the vendor has no tools to guarantee that.
Which decisions can they make alone, without referring to the vendor’s leadership? If they cannot decide on a replacement or on cover themselves, their value to you is limited to passing messages along.
How many engagements do they run in parallel, and how much of their time is yours? A delivery manager with a dozen clients will not actively manage your staffing; they will respond to escalations. That may be enough for a small team, but then do not pay for a full role.
Is the role included in the rates or billed separately? Both are fine, but they give different reference points. With a separate line you compare the role’s cost with its benefit. With the role included, compare the rates of whole proposals, not just the specialists’ rates.
Who reports to whom? If the delivery manager reports only to their manager at the vendor and sends you a status, news of problems will reach you later than it reaches the vendor’s leadership. Agree that on matters concerning your project, they inform you in parallel.
These are not trick questions. A vendor that has thought the delivery manager role through will answer them on the spot. A vendor that added the role to make the proposal look fuller will answer in generalities.
What are the key takeaways?
A delivery manager and a project manager are not two names for one role, and they are not two halves of one accountability. The project manager owns the project. The vendor’s delivery manager owns how the vendor supplies people and their work. In a project with an external team on time and materials, the first role stays with the client, because the client holds the decision rights the outcome depends on, and it cannot be bought as an extra line in a proposal.
Remember five things. First, accountability follows decision rights: whoever decides priorities and scope owns the deadline. Second, neither Scrum nor PRINCE2 provides for two equal managers of one project; PRINCE2 gives the supplier a team manager role, not a project manager role. Third, write a RACI matrix with separate client and vendor columns and keep exactly one A per decision. Fourth, cost the delivery manager against team size: half-time alongside three engineers is about 17% of the cost, alongside eight about 6%, and that changes the business case. Fifth, if nobody on the client side can run the project, hire a project manager into the client column, with the client’s mandate, rather than hoping the vendor’s delivery manager will fill the gap. And wherever the specialists work for a client in another jurisdiction, such as Germany, have counsel look at who directs the work before the role split is final.
If you are building a team with external specialists and want the role split right from day one, see how our staff augmentation services work: specialists work under your direction, a dedicated account manager on our side owns staffing and continuity, and a project manager can be added to the team when you need one. Rates for every role, including project managers, are on our pricing page, and you can ask us about a specific team composition.