Project Manager vs Service Delivery Manager
Who is Service Delivery Manager
To answer this seemingly simple question, I have prepared the following text, which, as you will see in a moment, is neither short nor fully unambiguous, as is the role of SDM in organizations
Opinions…
During my nearly 15-year long career in management-as-a-service, in which I had the opportunity to work as a Service Delivery Manager and as a recruiter for SDM positions, I often heard those two:
Question asked by C-level management in an embarrassed voice
😅 what SDM really is?
Disappointed statement of the candidate
😕 not what I expected from this offer.
In the case of the Project Manager, virtually everyone has an opinion. One way or another, we can paint a fairly common picture of who can be a PM, an avatar if you will. That is a big difference, everyone has opinions, different ones but they have them in contrast when it comes to SDM, the problem is often the lack of any definition of this role in the organization, and therefore who can be an SDM.
Project Manager vs Service Delivery Manager — So What Is the Actual Difference?
Since the title of this article promises a comparison, let me deliver one — finally.
The confusion between PM and SDM is real, widespread, and honestly a little bit funny once you’ve seen it up close enough times.
Here is the simplest way I can put it:
A Project Manager manages a beginning and an end. A Service Delivery Manager manages everything that happens in between — forever.
A PM is wired for the temporary. There is a scope, a budget, a deadline, and a finish line. When the project is done, the PM moves on. That is not a criticism — it is literally the job, and it takes a particular kind of mind to do it well. PMs are builders, they thrive in the structured chaos of getting something from zero to done.
An SDM is wired for the continuous. There is no finish line. The service must run tomorrow, and the day after, and in three years when half the original team has moved on and the technology has changed twice. SDMs are operators and guardians. They keep the engine running, they adapt it, and they are the ones who get the call at 2 AM when something breaks.
Put it this way in a table and it looks like this:
| Project Manager | Service Delivery Manager | |
|---|---|---|
| Time horizon | Temporary (project lifecycle) | Permanent (ongoing service) |
| Success metric | On time, on budget, on scope | SLA, uptime, client satisfaction |
| Primary focus | Delivery of a defined output | Continuity and quality of a service |
| Typical relationship | Client engagement per project | Long-term client partnership |
| Risk posture | Manage risk to protect the project | Manage risk to protect the service |
| Team dynamics | Builds and disbands teams | Builds and retains teams |
| Ends when… | The project closes | It doesn’t |
Now here is where it gets interesting — and where most hiring mistakes happen.
Many organizations reach a point where their “project” never really ends. The software gets delivered, and then it needs to be supported, updated, integrated, scaled, and kept alive. At that moment, the company often realizes it still has a PM at the wheel of what has quietly become a service operation. The PM is looking for a finish line that no longer exists. And everyone is confused about why things feel… stuck.
That moment — that realization — is usually when someone calls us.
So… who can play the role of a Service Delivery Manager?
From my experience in recruiting and being one I can say that
- Other Managers, especially Project Managers but also people that are other types of managers like managers of the people — people managers, or resources — resource managers, or knowledge — knowledge managers, etc. They all make good SDMs, they know the right methodologies and they have the right toolbox for the role.
- Architects, I mean architects of corporate solutions, architects of business systems, and I do not necessarily mean software, but rather architects of workflow and procedures, optimizers responsible for identifying risks and eliminating losses. If they have relevant domain knowledge, they can be really helpful and make Service Delivery an art of sorts. They have a special mindset just like the next group.
- Analysts. I myself come from an analytical background — I am a Full Stack Analyst — so anyone who has an analytical mindset can be SDM as well, there are many Business Analysts, Business Consultants especially in Big Four and in top financial institutions who turned out to be very good SDMs.
- Engineers and Scientists, especially those with ‘senior’, ‘chief’, or ‘lead’ in the title, usually dipped their feet in management roles already and have deep domain knowledge and the right mindset.
As you can see, the Service Delivery Manager path is open to a very wide group of specialists.
What are the two most important things for being a successful Service Delivery Manager?
In my experience, the two most important things for Service Delivery Manager are
- Domain Knowledge, i.e. an in-depth understanding of processes and technologies in a specific business
- Management skills, which is a rich set of tools that you can use to do your job well
Domain knowledge is intimate know-how; such for example, how cash is circulating in a company, which is, for example, a manufacturing company, what are the regulations on credit risk assessment in a commercial bank in a given country, or regulations regarding data protection and processing by the medical sector.
Imagine for a second — or a minute if you really want — yourself as a C-level manager, do you imagine a situation where your SDM doesn’t understand what you are talking about or is unable to communicate clearly with the customer? I say that you and your client definitely know how things work in whatever your business is doing.
So does the Service Delivery Manager have to know everything about anything? Be the jack of all trades?
Definitely not, otherwise, SDM will end up being the master of none. It will be necessary at some point to specialize in some industry of the market and then maybe even in some specific niche of this industry. That is why people who already have deep domain knowledge, which I mentioned more than a few times in a previous post are so good in the role of SDMs.
As important as Domain Knowledge is the Management Skillset, knowledge of various management methodologies and tools is essential for the correct setting of processes. Because as an SDM you will have the possibility to create or deeply modify them. But your responsibility is also to ensure their smooth and efficient operation and adaptation to changing business conditions, especially in today’s world of VUCA design environments, so without that toolbox SDM just simply can’t do it.
Unfortunately, a toolbox full of methodologies alone is not enough, Service Delivery Manager still needs to be a leader. A successful SDM should know how to build cohesive teams through mutual trust and understanding. Know how to create a shared understanding of the task ahead and know how to reflect on past experiences, good or bad. He should know how to understand the often vague, mist-covered C-level business intent and know how to pass that clear intent down the line. A successful SDM should finally know how to arouse the desire to solve problems through exercising disciplined initiative, and how to cede assignments. and most of all, he should know how to assess, evaluate, and finally whether to accept the risk he is facing.
What Service Delivery Manager actually do?
Well… that depends 
I will focus here on the role of SDM in technology companies.
Depending on the position of SDM in the company’s big picture for management strategy, SDM can be responsible for the strategic or tactical decisions. That is the single biggest difference you would see. This difference can push you into an advisory role close to the company’s Board or put you in the position of a middle manager.
It all really depends!
Generally, the rest of your responsibilities will revolve around the delivery of IT services, ensuring the continuous operation of IT systems. You can expect to manage teams of professionals and internal and external relationships.
You can be a policy maker and administrator of an internal knowledge and procedure database, for the development and updating of which you can be directly responsible or you will be responsible for delegating appropriate tasks to the team. Those tasks can involve establishing and maintaining documentation, good practices, procedures, and policies, and generally every written guideline your team needs to follow, some of them will be technical some of them will be legal some will be just the how-to-with-people.
You can be the person responsible for delegating all the work or be responsible for the ticketing system and other client-facing communications like your company’s chat. That can involve contact with KAMs and Marketers in your company and it can mean that your responsibilities will be overlapping so you’d better make friends with them, even if you’re the typical introvert in a plaid shirt.
You can expect to be responsible for vendor and supplier management as well, especially if your company deals with the server or special hardware. Even if your company is fully remote, cloud native, and anything-as-a-service first you still will have to manage all the purchases, tenders, and the life cycle of these services and products your company uses.
That brings us to budgeting and general financial management. In smaller companies, you can expect to be on a short budget and without the support of costly bookkeepers so you should expect from yourself at least basic bookkeeping and finance literacy. It can be especially tricky when your team works in different legal jurisdictions.
Risk, Change, and Incident management will always be part of your daily routine as an SDM. You will be responsible or you will be taking part in a team effort to foresee or find, address and manage all that volatility, uncertainty, complexity, and ambiguity.
To manage all that you will be involved in capacity management and operations, but you need to be able to stand aside and look at the whole thing with some tactical or strategic perspective.
And all that brings us to maintaining the SLA from contracts… and that is what, from your boss’s perspective, will probably be your only task and worry.
A Story That May or May Not Have Happened Exactly Like This
Let me tell you about a company — let’s call them MegaWidget GmbH — a mid-sized technology firm that had just successfully delivered a major internal platform. Big project, long journey, great PM at the helm. Project closed, PM celebrated, LinkedIn post written, confetti everywhere.
Six months later, the CEO calls me.
“We have a problem,” he says. “The platform is falling apart and nobody seems to be in charge of it.”
They had handed the delivered platform to — and I am not making this up — a very talented developer who had been promoted into a vague management role with the title of, and I quote, “IT Coordinator.” The IT Coordinator was technically excellent, deeply introverted, had never managed a vendor contract in his life, and was now supposed to be managing three external suppliers, an SLA with their biggest client, and a team of seven people spread across four countries.
He was also still writing code because there was nobody else to do it.
The platform was not falling apart because the technology was bad. The platform was falling apart because there was no SDM. There was no one to own the service, no one to read the SLA and ask the uncomfortable questions, no one to manage the incident when the biggest client called on a Friday afternoon, and no one to look at the whole picture and say: this is what we need to do next week, next month, and next year.
We placed an SDM with them on a part-time basis within two weeks. Within three months, the incidents were under control, the suppliers were back in line, the IT Coordinator was writing excellent code again, and the CEO had stopped calling me in a panic.
The IT Coordinator, by the way, later told me it was the best thing that had happened to him professionally in years.
I changed a few details. The confetti was real.
Summary
As you can see, the role of Service Delivery Manager is very demanding and quite a lot about it depends on where it is positioned in the enterprise management strategy of your organization.
Regardless of the exact scope of duties, being an SDM has always been for me and for the people I have prepared for this role very rewarding and enriching.
Lorem ipsum dolor sit amet, consectetur adipiscing elit. Ut elit tellus, luctus nec ullamcorper mattis, pulvinar dapibus leo.
When applying for the position of SDM, it is worth approaching the subject with an open mind, the role of SDM in most organizations is not well defined, often someone has to choose one of three job titles: Product Manager, Project Manager, and Service Delivery Managr, and he or she just chose the one that automated recruitment systems just points out as the best choice.
In any case, if you are applying for a position like this …
Good Luck!
You will need it…
…all of it 😉
Does Your Company Actually Need a Service Delivery Manager?
If you have read this far and the story above felt uncomfortably familiar — this part is for you.
The question organizations usually bring to us is not “what is an SDM” — it is one of these:
- “We are not sure if we need a PM or an SDM for what we are trying to do.”
- “We have a PM, but the project ended and now the service is running and nobody is managing it properly.”
- “We need an SDM but we cannot justify a full-time hire right now.”
- “We hired someone with the title SDM but they are doing something completely different and we are not sure what.”
These are all solvable problems — and solving them is a significant part of what we do at Iron Oak Consulting.
We provide experienced Service Delivery Managers and Project Managers through our Body Leasing service — which means you get a seasoned professional embedded in your team, on your terms, without the overhead and risk of a permanent hire. Part-time, full-time, short engagement, long-term — we work around what your organization actually needs, not around a standard contract template.
Our SDMs bring domain knowledge from technical and technology companies across different markets, they know the methodologies, they have seen the disasters, and they are not going to need six months to get up to speed on what matters.
If any part of this article made you think “we have a gap here” — that gap is worth a conversation.