Have you ever struggled with supporting 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 run the risk of 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 project team ineffectively juggles operational activities with key project deliverables. Without defined operational roles and responsibilities, project teams endanger future releases as well suffer from role confusion.
This article provides several recommendations to avoid becoming “lost in transition”.
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 to 1/3 of the company and the second release was scoped for the remainder of the company. The first launch was a challenged launch as the system experienced production support issues and the business partners were not comfortable that the system was stable enough to support the remaining 2/3 of the organization. As the team approached the launch decision for the second release, the business partners and the project team decided to postpone the launch for 30 days.
The key reason wasn’t the technical capabilities of the product 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 an actual 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 contributing to the lack of response was that production support was provided by the existing project team. 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 was a compilation of operational issues and release specific issues. The project also relied on multiple vendors to manage integration with the software product. The various vendors raised operations issues to multiple points of contact. The end result was confusion. Once the decision to defer the launch was finalized, the project team members became defensive and a bit demoralized by the lack of ownership and the lack of recognition for 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 transition early on in the project planning and schedule development. The project team solved the problem by implementing the following six simple steps to improve application governance and improve operational support.
1. Identify support resources for the application
Even in resource constrained organizations, it is important to have an individual resource or team responsible for production support. Depending on the volume, the role may be shared or dedicated to production support and application management.
2. Establish an operations status meeting with business partners and IT stakeholders
An operations status meeting is similar to a project status meeting except the focus is on the operations of the IT application and the results being delivered to the business. The operations status meeting includes business partners and IT management to jointly review the health and performance of the application.
3. Establish a production issues and incidents meeting with business subject matter experts and the technical team
By establishing a separate meeting to review production issues and incidents, the project team can focus on issues relevant to the next release while the operations team focuses on immediate support issues. Failing to separate production issues from project issues will only drain the project team from their intended goals and objectives. The end user becomes confused as they struggle with identifying 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 as well as 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 request’s severity.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 there are no impacts or conflicts.
5. Communicate the governance model to project stakeholders
Once the participants are identified for each of the key operational meetings, the operations governance model should be communicated and reviewed by business and IT stakeholders. By presenting a solution on 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 project team and support team.
Another key to a successful operations process is the knowledge transfer provided by the project team to the operational support team. In some cases, project team members will become operational support and in other cases, new operations support teams will be hired independent of the project. The project schedule should include transition documentation tasks to communicate the processes and procedures required to support the application. The processes documentation can include batch schedules, help desk coordination, escalation contacts, known problems and solutions, and disaster recovery procedures.
Readers may be surprised that even a seasoned project team could get “lost in transition”, but it 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 maybe de-scoped and poorly implemented. By following these six steps, project teams can ensure a better separation of duties between ongoing operations and future application delivery.
