Home / Project Management / From Projects to Operations

From Projects to Operations

The successful implementation of organisational strategy happens through projects. Project teams make the required changes to help the business move from where it is now to where it wants to be, either through a series of small changes or through larger, transformative change.

But there’s a part in that process that has traditionally not worked so well: whether you are using waterfall, agile or a blend of both that fits your needs.

The handover from the project team to the operational teams happens during the project closure phase in most project management literature. You may have a customer representative on the project team to guide the outputs and to ensure that you are on the right track with what you are building. They provide a small link into what the operational team are going to have to live with once the project team move away.

Project to OperationsHowever, the role of the customer or subject matter expert, or even the sponsor, as they too have a vested interest in the outcomes being fit for purpose for use by the rest of their division, is project-focused. You talk about requirements, testing, features, deadlines, and strategic fit. You probably don’t have that many conversations about how the product is going to be integrated into the rest of the operations. I use ‘product’ in the widest sense: you could be delivering a process improvement, or a set of new functionality for an existing system, or anything else.

Beyond the conversations you have about training and this nebulous thing called ‘handover’, project teams don’t often spend a lot of time planning for closure. When we do talk about closure, it’s in relation to celebrating a job well done, archiving project documentation, and getting sign off from people up the chain. These all need to be done, but the biggest thing that equates to long-term strategic success is an effective handover to ops.

Involve the Operations Team Early

The operational team is far larger than the person from that department who sits on your project team. There’s a whole ecosystem of people who should be involved in the project at some stage in order to make the integration of outputs a success.

These will be different for every project depending on what it is you are creating, but could include:

  • The help desk team who will be responsible for taking customer queries about the new system.
  • The HR team responsible for training new starters in the process that you have changed.
  • The IT team who will have to maintain and support the infrastructure that your new or updated system runs on.
  • The business process team who manage and own the business processes.
  • The facilities team responsible for looking after the new offices or building you’ve worked on.
  • Any other team with responsibilities for ongoing training, support, or maintenance related to what you have delivered.

Some of these will have been a critical part of your project, but some might not have been. For example, the teams that train users on processes and systems are often, in my experience, overlooked when it comes to project handover. The users themselves get the training they need, but the people responsible for training new starters don’t have adequate support to pick up the training and deliver it once the project team have moved on.

HandoverPart of your project planning should be identifying and involving these individuals and teams as soon as you can, so that you can understand how they will be impacted by your project’s deliverables.

The more you understand what they are going to have to do to support your deliverables, the easier it is to integrate the handover activities into your project. The earlier you can engage them, the more chance you have of building something that they can actually support. It has been known – and the company concerned will stay anonymous – for an IT support team to get involved so late that the project team built something that couldn’t easily be supported on an ongoing basis. That resulted in expensive changes to the support team structure and the product itself that could have been avoided if the right IT teams had been involved much earlier in the project.

Be Adaptable and Responsive

The operational teams are going to be crucial to the successful delivery of ongoing benefits. They need to understand what it is you are giving them and how that can be slotted in to their day jobs of supporting other elements of the organisation’s infrastructure. That might be easy; it might need some significant rethinking on their part. Your role is to be adaptable and responsive to their needs, helping them understand what is coming and discussing what they need to be able to pick it up.

You can then build those requirements into your project work. They might benefit from all kinds of things that you are creating anyway, or some that you may have to create as bespoke to them. Some examples are:

  • Train the trainer materials
  • User guides
  • Handbooks
  • Product videos
  • How to guides
  • Crib sheets

Projects to OperationsThey might also benefit from access to your project knowledge repository and lessons learned so they don’t have to learn the lessons you already have. You can give them this as soon as it is set up, or prepare a digest for them.

Use Their Handover Process

IT teams in particular often have a process for handing a service into live. There might be a sign off checklist or a process to work through that ensures you have covered everything required in order for them to do a good job of supporting it.

If you don’t know if something like this exists, ask for it. Or perhaps help them create it with the support of your PMO? If you work in a business that regularly puts new processes and systems into production it will be very beneficial to standardise what’s required for this handover process.

From an IT perspective, items to include in this kind of handover to production would include:

  • Briefing and full handover to service desk team
  • Sign off from information governance or security team
  • Infrastructure diagrams delivered to infrastructure team
  • Process to create, manage and delete new user accounts documented and handed over

And so on. You can do the same for any functional, operational team that regularly receives the products of your project. The more you can get into the habit of involving them early and streamlining the handover, the easier it will be for you to walk away as a project manager confident that the business is going to get strategic value out of your project.

In summary, you need to work as an integrated team: project and ops. You’re all on the same side, and you’re all working for the same outcome: the successful integration of project deliverables into the organisation so that the benefits tumble into your lap as a reward for your hard work.


If you enjoyed this post, make sure you subscribe to our RSS feed!

About Elizabeth Harrin

Elizabeth Harrin
Elizabeth Harrin is a career project and programme manager with over a decade of experience in healthcare and financial services. She's also a content strategist, award-winning blogger and author of several books about project management. Find her online at A Girl's Guide to Project Management

Discover the new Adaptive Strategic Execution Programme

%d bloggers like this: