What’s the Difference: Tech PM vs. Service Delivery Manager

 

Mohamed got in touch via the Project Management Café Facebook group, and asked an interesting question:

What is the difference between the below 2 jobs:
-Technical Project Manager.
-Technical Service Delivery Manager.

Great question, and I’m sure many people starting out in IT wonder the same, especially in environments where the Tech PM is paired with a business project manager or change manager, or working with a programme manager. In that kind of environment, the distinction of who is running the project can be a bit blurry to the uninitiated.

Technical Project Manager and Technical Service Delivery Manager (or simply ‘Service Delivery Manager’) are two very separate and distinct roles in an IT function.

What the Tech PM Does

A technical PM works on delivering change. They lead a project, and in this case it would be an IT project, or the IT workstream of a larger project that involves other business teams. In some structures, other business teams might work under the IT project manager, if the PMO and project management expertise sits in the IT function and other business areas don’t have their own project delivery capability. The exact set up is going to differ between companies and organisations depending on the skills and hierarchy of the business but whatever the set up, one thing is clear: the tech PM does work that delivers projects.

They implement new processes or services, or deliver products and facilities. Their work centers on changing the environment.

What the Service Delivery Manager Does

A Service Delivery Manager works on achieving a successful status quo. They are focused on the running the business. They might be responsible for a particular service line and making sure that runs effectively. Or they might face off to a business area and support them, so they are focused on ensuring those teams have the infrastructure and tech set up required for them to do their day jobs.

The role of the Service Delivery Manager can encompass anything required to keep the lights on for the IT services they support. This includes managing changes to operational services through a Change Advisory Board, taking on board customer feedback, managing service outages, liaising with suppliers and being responsible for maintenance contracts.

There are processes to follow to ensure that there are no service interruptions, or if there are, these are dealt with effectively to keep the business running.

Bimodal IT

I don’t really like the phrase ‘bimodal IT’ (was it Gartner that coined that?). In project management we’ve had this distinction forever: it’s the same as the difference between projects and business as usual.

• Some people change the business (these are the project managers, our Tech PM).
• Some people run the business (these are the operational teams, and in this case, our Service Delivery Manager).

However, if you want to use the jargon, bimodal IT describes these two states of being: maintaining the status quo and at the same time changing it. And this is where the overlap between the two roles comes in.

Project Handover

The roles overlap because project managers deliver into live service. We want our products to be used, and they need to be incorporated into the live operational service for the organisation.

To take an example: say you launch a new web service for customers, so that they can pay for your services online. The project goes well and you launch the service. The new web pages are up and running. You then move on to a different project.

If you did a good handover, the operational team will know how to process orders that come from the website pages. They will know how to support and maintain the web pages and they’ll have an idea of what acceptable service looks like.

The Service Delivery Manager will be involved in this too because they will be responsible for the IT elements of the website. For example, the handover would ensure they are equipped to:

• Manage upgrades to the content management service
• Patch the web servers appropriately
• Ensure anti-virus is up to date
• Deal with calls from employees who are trying to access the data captured on the website or other queries
• Be able to reset passwords for the admins

And so on.

The Service Delivery Manager needs to be ready to catch the ball when the project team throw it over.

Handover is Too Late

Having said that, waiting until project closure to start working together is too late. If the Service Delivery Manager hears that there is a project that touches his or her area, they should investigate. The project manager should involve them as early as possible.

Why? Because they know so much about the area they support, their products and services. They can be crucial in creating a product that is actually supportable. You wouldn’t want, for example, a web microsite to be created on a different content management system to the main website, as that would mean two lots of content management systems to support, two lots of admin and password resets to handle, and so on.

I actually know a company who did this. Perhaps there was a reason for it at the time – I never found out, and it always struck me as odd that they’d created extra work for the operational teams through not involving them early enough in the design process.

To summarise, then:

The project manager moves on. The Service Delivery Manager is a long term operational job, stuck with managing and maintaining whatever the project manager hands over.

Make sure you are handing over something supportable and decent, by involving the right people early enough.