In my 25+ years in Information Technology, I have “worn hats” in two main areas: projects and support operations. Sometimes I worked exclusively on projects, other times dedicated to operations, and at times both simultaneously. Normally, the flow of product deliverables goes from a project team to the operations team that will sustain the solution when the project is over. I have helped to hand off deliverables to operations, received deliverables from projects, and even went with deliverables, moving from the project team to the operations team.
Experiencing and participating in both sides of this equation, I accumulated observations on what may help to ensure a successful transition of an IT solution from the originating project to the operations group(s) that will support the final deliverable. Although most of my experience involved traditional (waterfall) projects, I have started to see Agile-like efforts injected into my large organization as well. But assuming the project, whether waterfall or Agile, has some semblance of a closure phase, i.e. not making project-driven changes in perpetuity, these observations apply to both delivery approaches.
Weighing all factors as objectively as I can, since both sides carry important responsibilities to make the transition a success, I feel operations has the ultimate burden. When the project and all of its resources and funding are gone, it will be up to the operations team to support the deliverable, now part of its support portfolio. They will need to manage emergent defects and customer enhancement requests that may not have been foreseen during the project. While not all scenarios can be anticipated in advance, the operations team must think ahead on how all facets of the IT solution will be supported, from hosting to integrations to availability requirements, as well as how the overall lifecycle will be managed. This is not an easy task, even for simpler projects, but nonetheless must be done, starting during the project’s planning phase. Cooperation between the project and operations teams throughout all development and testing phases is key.
Let’s start with the project team. From the very beginning of any project, how the IT deliverable will be maintained and supported post-project must always be taken into consideration. Have you ever seen a project receive accolades for completing on-time and within-budget, but not long after the project is dispersed, a “project after the project” is spun up to address a myriad of functional and technical issues? I have personally been involved with this type of scenario in the past, several times. Once I worked the after-project for an effort I was not originally involved with, and on another, I went from the project team to operations team and then took responsibility for post-project “cleanup” when the deliverable reached maintenance. So I have experienced the spectrum of this issue, and can soundly say that the causes may not always be within the project’s control to anticipate and correct. Deadlines and funding restrictions can have ripple impacts that must be addressed by the operations team months or even later after the project concludes.
With transition to operations in mind, here are tips for the project team as they plan and execute the implementation effort.
- Engage the operations team early – the sooner operations teams are looped into a project, the better. The absolute worst scenario is a “cold” hand-off, where the operations team was not involved in any project phase, and then receives little guidance just as the project closes out. This scenario is a failure on many levels, but it is squarely the project team’s responsibility to ensure operations teams are given the chance to participate in the project, at least as stakeholders.
- Understand which operations teams should be involved – in smaller organizations, this task may not be challenging, as there may be only one team, or even one person. But the larger an organization is, the more distributed operations are likely to be. Will one operations team “own” the deliverable? What level of knowledge and involvement will be necessary for secondary, ancillary teams that will contribute to operations? Having this organizational awareness will allow the project to tailor transition activities appropriately.
- When possible, “embed” a member of the operations team into the project – having a member or members of an operations team be part of the actual project, or go “on loan” to the project, will smooth the eventual transition. Embedded operations member(s) can be either part or full time. There is no substitute for learning by doing, and having firsthand knowledge of how deliverables were designed, coded, and/or implemented will be valuable in the long term as that firsthand knowledge is disseminated throughout the ops team(s).
- Acknowledge time management and commitments from the operations team – whether operations team members are embedded to the project or not, it is vitally important for the project to be mindful that the operations team has a plethora of responsibilities. A project manager may be singularly or at least significantly focused on a project, and it is easy to forgot that other parts of the organization, operations in particular, will have pressing demands day in and day out. When possible, level set resource commitments ahead of time between project and operations management.
- Include operations in status – ensure operations management, supervisors, and team leads are regularly engaged and informed of the project’s status. That can be easily done by including members of the operations organization at level-appropriate status calls. The operations team should also have access to the project’s status reports, again with level-appropriate detail.
- Develop knowledge transition materials – although this may be more akin with the waterfall approach, Agile having less emphasis on extensive documentation, you have to look at the operations team’s point-of-view. Does the operations team have enough documentation to support and maintain the solution? Would a programmer or IT analyst be able to understand how to support or change the system a year hence, if none of the original project team is available? This task requires the project team to view the perspective of the operations team, to ascertain the correct level of detail. Engaging the operations team for feedback and technical specifics is recommended.
- Conduct transition sessions – all IT projects should have transition meetings with the operations teams that will take responsibility of the deliverable post-project. The project team should plan, schedule, and drive these transition sessions, which will allow the operations teams plenty of opportunity to ask questions.
On the support operations side, there is a twofold responsibility. First is to aid the project as it progresses and builds the deliverable. Regardless of size and scope, an operations entity will have to be involved in the long-term sustainability of the product, once complete as defined by the project. Second is to anticipate support demands once the deliverable is in production. These tips should help with both.
- Review planning documents – when getting involved early in a project, even if only as a stakeholder with no direct impact work, it is important to review materials at initiation, be it charters or requirements specifications. Both operations management and support personnel must have a firm grasp of the project’s objectives and how its deliverable will eventually be supported by support and operations.
- Learn design and architecture – beyond the review, the operations team must fully understand the proposed IT solution. Is the deliverable completely new, an upgrade, or a replacement for an existing solution? Study the design details and make sure they clearly explain how the deliverable will be constructed and, just as important, how it will integrate into your existing systems and infrastructure.
- Identify operations impacts – this begins the hard part, because though the project can construct deliverables largely on their own, the project team may not fully understand how their solution will work with all existing operations components. If your ops portfolio is exclusively a Wintel environment but the project is delivering a solution built on a Linux distribution, how will that impact the operations team? Are new skill sets needed? Anticipating maintenance needs for operations early in the project will make the eventual transition smoother.
- Raise questions and challenge – operations teams cannot be idle or sit on the sidelines while an IT deliverable is being built that ops will have to support. In this regard, operations must protect their own interests by ensuring the maintenance organization has all it needs to be successful supporting the deliverable once it goes into production. No question is stupid; any question that operations has about the project should be given to the project manager and included in the project’s RAID log.
- Understand the RAID log – Risks, Actions, Issues, Decisions, all facets of potential obstacles and resolutions impacting a project’s delivery are tracked in RAID. The operations team(s) should be keenly aware of items within the project’s RAID log and how roadblocks and decisions made within a project could impact future support operations. This goes hand-in-hand with asking questions and challenging, as RAID is the common tracking mechanism for all facets of the project.
- Contribute to the transition schedule – the operations team should understand the timeframe for when the project’s deliverable will be handed over to operations for support. How involved will operations be for the deliverable’s “go-live”? Will the project team handle initial support, and if so, for how long? A week, a month, 90 days? When will the operations team be fully responsible for the deliverable? If the operations team has its own constraints, they should be brought to the project manager for tracking (RAID), discussion, and resolution.
- Plan intake of all project deliverables – how project artifacts are managed may be set by organization standards, or fall exclusively to the operations team to deem what items from the project are necessary to retain for support and maintenance. As a general rule, “all of it” has to be the default answer unless there is a solid reason to not retain any of the project’s artifacts for possible future reference. Code should be stored in the operations team’s repository, and all documentation should be archived. As necessary, existing operations procedures will need to incorporate parts of the deliverable as pertinent both to day-to-day maintenance as well as possible future troubleshooting and enhancement requests.
Do you concur with my tips for successful IT transitions from projects to operations? Do you have your own tips to strengthen my suggestions? Please leave a comment, and thanks for reading.
