The Money Files

In this video I share a few quick tips for preparing for a project audit. It shouldn't be a scary event and yet some project managers still feel daunted by the process. I get it - it's time consuming and it does feel like you are in the spotlight for a while. But the outcome is worth it, as long as the process is robust.

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.

Here’s a short video sharing three ways to keep your project on budget, but be warned, these are suggestions for project managers willing to take the difficult decisions and have hard conversations!

You can see more tips on how to keep your project on budget in this article.

I put this infographic together to show the various different levels of project financial management maturity, as outlined by the P3O guidance from AXELOS. My view is that most companies should be looking to aim for Level 4. Level 5, with the implications that you are using Monte Carlo simulations and other types of advanced estimating tools, is probably overkill for most smaller projects or businesses without the exposure to risk that this helps mitigate. What are your thoughts? Is Level 5 where we should all be heading?

If you’d like to read more about the different levels, you can in this article.

I wrote last month about the differences between project accounting and financial accounting. One of the big challenges of juggling the two is the issue of securing ongoing funding for your project over multiple financial years.

You know the situation: your project has a three-year lifespan but you’re only granted funding for Year 1. So you start the work, hoping that next year there will be funding available for you to continue.

Ideally, you should get capital funding put aside for all years prior to starting work, but in reality it’s not practical to tie up company funds like this when they could more profitably be used in other ways. So you might find yourself revisiting the project funding process every 12 months to secure the funding you need.

There are some advantages to doing this, especially as your financial needs may change throughout the project and you might not require all the funding you thought (or you might need to apply for more).

Here are some tips on how to secure continued funding for your project.

Know the Dates

If you know you are going to have to apply for funding for your project for next year, make sure you are clear on the budget process timeline. Talk to people who know what’s required.

One thing I have found over the years is that the planning cycle dates can change. One year it seems like we start in October, other years we’re scrabbling to do it all in December. So if you hear the message that the timeline isn’t firm yet, be aware that at some point it will be firm and you can still start planning right now.

Revise Your Estimates

You’ll get asked whether these are the latest estimates for your project. Make sure that they are! You should revisit your schedule estimates with your team so that you can use accurate dates and effort information to plan the costs.

Make sure you’ve been through any external costs as well, so that you know what, if any, capital expenditure is required above the funding for your team.

Create a Budget for the Next Year

You’ve revised your estimates – but you probably did that for the whole project, right? That’s not a problem, in fact, it’s good practice. But you only need to ask for the money that you’ll be spending in the next financial year.

Split out your budget forecast for the coming financial year. I believe you should submit the big picture as well so that everyone knows the total costs being requested over time (because this is as good a point as any to revisit the benefits in the business case) but make it obvious what part of the funding you require in the next 12 months.

Review the Benefits

The powers that be will pour over your request for extra money carefully. Remember, they’ll have lots of people asking for funding for new projects and operational expenditure. They are trying to juggle the needs of the whole company. So you need to make sure that your proposition is still compelling. They might just be looking for a reason to kill off a few expensive projects.

Revisit the business case. Talk to your sponsor. Garner some support from influential people around the right time – that kind of thing!

Make sure that if asked they can justify why the project should continue.

You should submit your rationale for continued funding along with the request for budget, but keep it short. The decision makers are going to be looking at hundreds of these. If they have a particular template they want you to use, then use it, otherwise a cut down version of a business case would do.

Plan Ahead

The next step is to apply for the funding when the time comes and then sit back and wait for the decision. While that’s happening you can plan ahead.

Make sure that you know when you are likely to hear the outcome of the decision. For now, assume that it is going to be a yes. With that in mind, you can plan how to mobilise the next stage of the project to ensure work can continue without a pause in proceedings.

It’s also worth having a Plan B for what happens if you don’t get funding in time for when you need it to continue. Sometimes it takes longer – I’ve known of businesses where funding for projects wasn’t released until three months into the financial year. That’s a lot of project teams not able to do very much while they wait for permission to spend the money to continue.

Think about what impact that would havve on your project. Could you carry on for a bit without spending any money, if you still had internal resource to work on your project? Would the worrk have to stop? Would you lose key resources from  suppliers orr contractors if you couldn’t pay for them? All of this would have an impact on your ability to be able to complete the project successfully, so make sure that the decision makers know what the impact of a late approval would be.

Hopefully, all of this is built into your PMO processes and the ongoing needs of your finance team. Hopefully, there is good communication between your finance team and the rest of the business. Hopefully, the timetable is clear and you all know what’s expected of you. Hopefully this whole thing is a tick box exercise.

Unfortunately, the ‘tick box exercise’ scenario is rarely the case in my experience and you will have to plan, forecast and justify the continued existence of your project. This is not a bad thing. It’s robust business, financial and project governance. Go with it. Build time to do this into your plans and think ahead.