Project Transition to Operations

Have you ever struggled to support a newly deployed application while managing subsequent releases? Have you ever had problems with project transition to operations?

Enterprise projects and programs often have multiple releases to various countries and business units. Project teams risk becoming lost in transition when the initial release is not properly transitioned to an operation support model.

In this scenario, the project team continues to work on the next release while struggling with the production support role. The team ineffectively juggles operational activities with crucial project deliverables. Without defined operational roles and responsibilities, project teams endanger future releases and suffer from role confusion.

This article provides several recommendations to avoid becoming lost in transition.

Context in IT Organizations

During a recent project, an IT organization was implementing a new financial accounting package over six months with two planned releases. The first release was implemented for 1/3 of the company, and the second was scoped for the remainder. The first launch was challenging as the system experienced production support issues, and the business partners were uncomfortable that the system was stable enough to support the remaining 2/3 of the organization. As the team approached the decision to launch the second release, the business partners and the project team decided to postpone the launch for 30 days.

The key reason wasn’t the product’s technical capabilities or outstanding minor production support incidents. During the launch decision meeting, the business partners raised concerns about the instability of the application and the lack of sufficient operational support. After further investigation, the instability was a perception rather than reality. The application response time was acceptable, and the Web server never went down. The system functioned as designed; however, the perceived instability was directly related to the lack of response from the support team. The key reason for the lack of response was that the existing project team provided production support. The project team never transitioned operational support to another team or an individual.

The project team continued to respond to operational issues while trying to deliver the next release of the software implementation. The project issues log compiled the operational problems and release-specific matters. The project also relied on multiple vendors to manage integration with the software product. The various vendors raised operations issues to numerous points of contact. The result was confusion. The project team members became defensive once the decision to defer the launch was finalized. They were demoralized by the lack of ownership and recognition for the long hours spent delivering the second phase and production support.

This entire “lost in transition” scenario could have been avoided if the project team included operations support planning and early transition in the project planning and schedule development. The project team solved the problem by implementing six simple steps to improve application governance and operational support.

1. Identify support resources for the application

Even in resource-constrained organizations, it is essential to have an individual resource or team responsible for production support. The role may be shared or dedicated to production support and application management, depending on the volume.

2. Establish the status of an operation meeting with business partners and IT stakeholders

An operations status meeting is similar to a project status meeting, except it focuses on the IT application’s operations and the results being delivered to the business. The operations status meeting includes business partners and IT management to jointly review the application’s health and performance.

3. Establish production issues and incidents meeting with business subject matter experts and the technical team

The project team can focus on topics relevant to the next release by establishing a separate meeting to review production issues and incidents. In contrast, the operations team focuses on immediate support issues. Failing to separate production and project issues will drain the team from their intended goals and objectives. The end user becomes confused as they struggle to identify a single point of contact for assistance.

4. Establish a change control board to manage ongoing change in the operational environment

Change management is an ongoing operational process and a project management process area. Business needs will change, and new reports, fields, interfaces, and customizations will be needed. Some of these enhancements can be bundled with a future software release, and others will be made off-cycle based on the severity of the request. By establishing a change control board, the business customer will have a method to request changes to the application without deterring the project team from their intended goal. The changes introduced to the change control board should also be vetted and reviewed with the project team to ensure no impacts or conflicts.

5. Communicate the governance model to project stakeholders

Once the participants are identified for each key operational meeting, business and IT stakeholders should communicate and review the operations governance model. By presenting a solution for how issues, changes, and operational status will be reviewed, the business partners will have greater confidence in the IT manager’s role in delivering services and supporting the business.

6. Provide knowledge transfer between the project team and the support team.

Another key to a successful operations process is the knowledge transfer from the project team to the operational support team. In some cases, project team members will become operational support; in other cases, new operations support teams will be hired independently of the project. The project schedule should include transition documentation tasks to communicate the processes and procedures required to support the application. The process documentation includes batch schedules, help desk coordination, escalation contacts, known problems and solutions, and disaster recovery procedures.

Conclusion

Readers may be surprised that even a seasoned project team could get “lost in transition,” but this often happens when projects are faced with insufficient resources and short timelines. The triple constraint of scope, time, and resources is adjusted when the time parameter is fixed. Scope and resource constraints will adjust, and unfortunately, operations support may be de-scoped and poorly implemented. By following these six steps, project teams can better separate duties between ongoing operations and future application delivery.

Suggested article: How to Transition from Project to Operation