Transitioning from Project to Operations

Marianne Hang, Senior Project Manager

April 11, 2018

How can a project go from start to finish, and then find itself unprepared when it comes time to hand off the new system to Operations? This happens a lot more often than you’d think so I thought I’d offer some pointers on how to successfully transition a project to Operations. As a PMO Lead, one of the first things I do to get a PMO airborne is talk with folks in the organization and make a list of their pain points. Together, we can then figure out how to eliminate that pain. One pain point organizations regularly bring to the table is the turbulent transition to an Operations process within the project lifecycle. It’s that crucial time in a project when testing is complete, go-live is successful, and the project is done – except it isn’t done after someone yells “Surprise!” and we find out that done doesn’t mean the system is ready for use. And that’s exactly why the transition to Operations can be a source of agony for the Project Team, its clients, and the people who will be supporting the new and long-awaited system. I’m sure you can see my PMO focus regarding project transition to Operations and why this transition is so important to lasting project success.

Operations Engagement: The Sooner the Better

Let’s start with timing. At what point in the project lifecycle should transition to Operations planning begin? Just to be clear, transitioning to Operations refers to the project tasks of moving functions pertaining to production readiness, support, and maintenance of a newly delivered solution from the Project Team to the Operations Team. The Operations Team is responsible for ongoing business support and system maintenance long after the Project Team has disbanded. The Operations Team assumes various roles including the owner, administrator, power user, trainer, troubleshooter, keeper of documentation, client, and vendor liaison, and all around technical go-to staff for the new production system. Thus, the Operations Team exceeds expectations of simply taking a solution and adding it to the operational library and technical matrix, as many believe. With a better understanding of the real expectations for accepting a project-delivered solution, it’s time to consider how well we position the Operations Team to successfully accept their new system responsibility and how to engage them as early as possible. That means as early as project visioning begins – literally during the very first stage of the project lifecycle.

Engagement of the Operations Team for a successful transition is one of the top issues in project management, and as such, also one of the top criticisms of project management – i.e. “You didn’t engage the folks in Operations early enough!” It’s a priority that stakeholders notify the PMO regarding operational preparedness and have it addressed before it becomes a political issue. And yes, the Operations Team is a stakeholder on every project, not just another face in the crowd. I’ve had the pleasure of managing project rescues where lack of engagement on behalf of the Operations Team caused a project standstill because they refused to sign off on project stage gates, documentation, testing, training, and go-live requirements. I’ve also experienced refusal by Operations to assign their resources to a project when that request came too late in the project lifecycle – typically resulting in catch up with Operational resources as a full-time job. There is also the game of covert pushback by Operations on projects where their resources were not asked to project meetings or included in project communications. Nobody likes to be taken for granted, excluded, or considered an after-thought – especially not the team of folks who’ll be responsible for the new system once the Project Team is gone.

Operations Engagement: Requirements for Success

So what does early engagement of Operations look like? For maximum effectiveness, it means identifying and engaging the right Operational resources at the visioning or initial stages of an initiative. By engaging Operations early, the business case for the project is stronger and more believable. One of the questions I ask as PMO Lead when I get a project request is the rationale for why an initiative is being put forward as a project rather than a work request or service order. I want to know that Operations has been part of that discussion and decision, and if they haven’t, why not. In some cases, Operations has knowledge that can stop a project request when it should be a service order – thereby potentially saving time, money, and resources. In other cases, Operations puts their weight behind why work should be a project – thereby strengthening the business case for that project with governance and ensuring the initiative is best positioned within a successful process. When it’s clear that work is best done as a project, involving Operations on Day 1 helps ensure transparency and clarity with the same group that will have the solution handed over to them when the project ends. This translates to a transition process that is as quick, seamless, and painless as possible. It means that the project benefits from the operational expertise and historical knowledge, established vendor relationships, existing understanding of potential “gotchas” in solutioning and in working relationships, and technical support for the existing technical matrix within which the solution will reside. It’s easy to forget Operations representation early on in a project when there are so many moving pieces to stabilize. It’s tempting to not want to add any more voices, opinions, requirements, signatories, and decision makers to the already challenging mix in a project. For these reasons, early engagement of Operations also means early establishment and communication, and sometimes reminders of roles and responsibilities. But this is the case for every stakeholder, and Operations should not be left out just because they’re one more party to deal with. Operations engagement also requires time and budget – even more important why this engagement needs to start early.

What happens when we don’t take early engagement of Operations seriously? Well, that would mean missing out on all the critical input I’ve mentioned above, all of which culminates into a serious impact on the project. For example, what if Operational testers need to be represented during the testing phase but aren’t included? That’s a recipe for go-live disaster and we can’t even use the excuse of “we didn’t know what we didn’t know” because we turned a blind eye to the need for operational test scenarios. What if a solution works in a non-production environment but not a production environment because we didn’t have a full understanding of that environment from the Operations folks who maintain it? And remember that it’s rare, for good reason, to be able to test a solution in a production environment prior to go-live so we’re always taking a leap of faith, even if just the smallest one when we migrate a solution to production. Sure, we’re relying on rigorous testing to mitigate that risk, but mitigate here is the keyword – it’s rarely 100% risk-free. What if solution go-live is successful but the Project Team is unable to transition to Operations because they don’t know who in Operations to transition to, what that process looks like and it’s requirements, how long it’ll take, and where the Operations staff will get training for solution maintenance? In this case, there are two choices – either the Project Team must remain intact throughout a much longer project warranty period while transition to Operations catches up or the Operations folks get volleyed something they do their best to manage but risk the solution appearing fraught with issues because this is the first time they’ve seen it. There is actually a third choice but it’s a scary one – Operations simply sidesteps the volley and denies all knowledge. No matter which choice we take, a project cannot close and complete successfully without effective transition to Operations. And without that transition, the final perception of an initiative is negative.

Operations Engagement: Doing it Right!

Now let’s talk about what happens when we do take early engagement of Operations seriously. We do that by clarifying roles and responsibilities up front and early on, thus facilitating an initiative that has a streamlined and inclusive communications process. We’re then able to forecast resources, hours, and budget more accurately because we have a better idea of who needs to be involved, when, and for what. We mitigate risk in many areas, not the least of which are technical risks, and that means fewer surprises throughout the project lifecycle. We help ensure our solution design, build, testing, documentation, and implementation all benefit by the due diligence of engaging Operational experts. We increase our chances of a successful go-live because of that same due diligence. We help ensure that we transition the solution into operational mode and maintenance in as seamless a manner as possible, which means our client experience is enhanced and we can disband the Project Team on schedule. We add to the body of knowledge for the solution, as well as the project management process. We build positive working relationships, move away from work silos, support skill sets, and enhance individual as well as organizational knowledge retention. Overall, teamwork and team dynamics are acknowledged as critical in transitioning from the Project Team to the Operations Team.

One of the best ways to open lines of communication with the Operations Team and support their engagement on projects is to work closely with the IT Architect. That person is often embedded within operations so knows who’s who, how things work, and also what hasn’t worked in the past (in other words, what pitfalls to avoid). They’re uniquely positioned as an inroad resource to Operations for a project because they’re situated at both a strategic and tactical level, with one foot in the Operations camp and the other in the project support camp. They often have a strong presence at the governance level as well, to help streamline Operational engagement that while important, is also not a simple process and comes with its own issues. As noted in one of my earlier articles pertaining to Project Managers working with IT Architects, having a strong IT Architect on the project leadership team has many benefits and this article, with its focus on early engagement of the Operations Team, clearly shows one of those benefits in terms of being a key player in that process.

Ms. Marianne Hang is a Senior Project Manager affiliated with IT Architects in Calgary, Alberta. IT Architects (www.itarchitects.ca) is an information consulting firm specializing in business process optimization, system evolution planning, and the deployment of leading-edge technologies. If you require further information, Marianne can be reached at info@itarchitects.ca or 403-815-7505.

Leave a Reply

Your email address will not be published.