The three planning initiatives – Operations Transition, Release Management, and Project Stage Gate – are categorically related to managing IT projects and the deployment of information technology. However, there are distinct reasons for developing each type of plan pertaining to quality, streamlined integration, control, risk mitigation, etc. These are described in more detail below.
I. Operations Transition Planning
The transition of Projects to Operations is a delicate process and, if not planned for or done properly, may result in a substandard or failed system implementation. 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 scheduling. Organizations can deter this problem by implementing the following 6 simple steps to improve Application Governance and 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.
Even a seasoned project team can 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.
II. Release Management Planning
Release Management is the process responsible for planning, scheduling, and controlling a software build through different stages and environments, including testing and deploying software releases. Release Management ensures that IT delivers new and enhanced IT services required by the business, while protecting the integrity of existing services. As software systems, software development processes, and resources become more distributed, they invariably become more specialized and complex. Furthermore, software products, especially web applications, are typically in an ongoing cycle of development, testing, and release deployment. Release Management typically takes the following forms:
• Continuous Delivery, DevOps, and Agile Software Development Release Management. Organizations adopting agile software development will require more releases. With the increasing adoption of agile development, a new approach to software releases known as Continuous Delivery is guiding software transitions from development to a release. Continuous Delivery and DevOps enable the release of applications faster and more frequently. Tools such as application release automation and continuous integration tools help advance the process of Continuous Delivery and incorporate a culture of DevOps by automating a task so that it can be done more quickly, reliably, and is repeatable.
• Enterprise Release Management. While Release Management focuses on the transitions from development to testing and release for a single project or a collection of related projects, Enterprise Release Management (ERM) is focused on the coordination of individual releases within a larger organization. An organization with multiple application development groups may require a highly orchestrated series of releases over multiple months or years to implement a large-scale system. ERM involves the coordinated effort of multiple release managers to synchronize releases in the context of an IT portfolio.
• ITIL/ITSM Release Management. In organizations that manage IT operations using the IT Service Management paradigm, specifically the ITIL framework, release management will be guided by ITIL concepts and principles. There are several formal ITIL processes that pertain to release management, primarily the Release and Deployment Management process, which “aims to plan, schedule and control the movement of releases to test and live environments”, and the Change Management process. In ITIL organizations, releases tend to be less frequent than in an agile development environment. Release processes are managed by IT operations teams using IT Service Management ticketing systems, with less focus on automation of release processes.
III. Project Stage Gate Planning
The Project State Gate process is focuses on the innovation process and typically applies to the waterfall process. It is a project management technique, in which an initiative or project takes place, divided over several stages. These stages achieve milestones upon completion and are connected by gates, each gate having a decision point for whether or not to proceed to the next stage gate. This stage gate decision is based on the prognosis and information available at that moment and in most cases is made by a manager or steering committee. The decision considers the quality of the execution, business motivation to continue financially and the action plan showing what needs to be done in order for the project to have a chance at succeeding. A Project Stage Gate model can be used for new system delivery, system integration, and process changes and/or improvements.
A typical Project Stage Gate is comprised of the following stages:
• Stage 1 – Discovery
• Stage 2 – Scoping
• Stage 3 – Business Plan/ Project Charter
• Stage 4 – Development
• Stage 5 – Testing and Validation
• Stage 6 – Implementation and Deployment
Depending on the size of the project, 2, 3 or all 5 stages are completed. A project that focuses on the implementation of an integrated system of record will go through all 5 stages. A project with less risk will suffice with just stage 1 (scoping) and stage 2 (development of the business plan) and developing it to stage 4 (testing and validation). With very small or simple adjustments, only stage 3 (development) and stage 4 (testing and validation) will be implemented.
IT Architects provides a service to develop Operations Transition, Release Management, and Project Stage Gate Plans. (Note: These plans may have an affinity to each other and may be developed in whole or in part, and combined in certain situations to align with organizational circumstances.)
I. Operations Transition Plan
Operational transition requires careful planning, coordination, and communication between all affected groups and individuals, including partners and affiliates outside the organization. IT Architects provides an Operations Transition Planning Framework to help an organization develop an Operations Transition Plan, which is introduced into the Project Delivery Lifecycle, to achieve the following:
1. Engage leadership support. Solicit direct involvement of the leadership team and define their roles in the support of the entire transition effort, which includes the following steps.
2. Understand current state. Inventory the processes requiring transition, including the attributes and organization of the specific project team(s) and individuals performing these processes. Also, identify current organizational redundancies, issues and opportunities.
3. Define future state. Document specific requirements for the transitioning processes, including the functional owners of specific processes as well as staffing and budgetary constraints for each functional area. This in turn defines the future-state organizational model that will meet both steady-state operational needs and support a high level of ongoing change.
4. Confirm and monitor operational metrics. Define project success based on achieving operational metrics within specific timeframes, and based on having each functional area with processes requiring transition reviewing and agreeing upon these metrics. Monitor these metrics to determine when these processes are ready to transition to the future-state operational owner/team.
5. Enlist expertise and appoint a transition leader. Appoint and train an internal transition leader to plan and execute a project-to-operations transition, and provide strategic and tactical assistance with the transition. This work can include defining the transition plan and approach, directing and overseeing day-to-day transition activities, assisting key staff in transitioning to the new organizational model, and supporting management in defining team roles/responsibilities, organization charts, staffing plans, individual resource transition plans, and team charters.
6. Engage affected personnel. Engage affected personnel in lead roles throughout the transition process – from designing the future organizational model and associated roles and staffing levels to defining the comprehensive transition plan and approach and individual team charters. Similarly, incorporate operational planning at the outset of the process, and not wait until operations have already begun (as can happen with some transition efforts). Cross-validate team and individual roles across functional teams to ensure accountability for all functions, without role duplication.
7. Determine staffing. Based on the future state organizational model and associated operational metrics, the leadership for each functional area should define their team’s roles and responsibilities and the staffing levels required to support the new organizational model and associated operational metrics. Functional and senior leaders should review and approve these plans within budgetary, resource and other constraints. Functional leaders need to identify the individuals assuming specific operational roles, as well as make any staffing changes, such as hiring permanent staff and rolling off consultants and contractors.
8. Develop team charters. Each functional area should develop (or update) individual charters to ensure clarity of each team’s mission, scope of responsibilities, organization structure, roles and responsibilities, staffing, etc. This is important to ensure rightful ownership and management of transitioning processes in the future organizational model. In addition, functional leaders should identify opportunities to gain transitioning or staffing efficiencies, such as by reducing duplicative activities across functional teams.
9. Create and execute transition plans. Determine specific team and individual transition plans to migrate process ownership from the project team to the operational team. Understand the time requirements necessary for transferring knowledge, on-boarding new staff, rolling off project staff, and transitioning project team resources into operational roles. Given the near-certainty that project-focused consultants and contractors will depart, be particularly aware of the need to plan early for knowledge transfer.
10. Establish post-transition processes for documentation and evaluation. Create an easily accessible documentation site, such as via SharePoint, to catalog and inventory all of the documents needed to support the transition effort. This site, and other affiliated tools and documents, will be vital in the future for performing other, similar transitions. Additionally, identify a process for performing periodic, post-transitional organizational reviews to identify areas of potential improvement.
II. Release Management Plan
IT Architects has developed a disciplined Agile Release Management Framework to help organizations deliver an agile Release Management Plan to achieve the following:
1. Plan IT release schedule. Your organization’s overall release schedule needs to be planned and communicated. Many organizations have blackout periods where teams are not allowed to deploy into production (for example, many retail organizations will not allow non-critical production releases near the Christmas holidays). There are many strategies that organizations may choose to adopt when it comes to scheduling releases, including release trains, release streams, ad-hoc releases, and release windows.
2. Schedule solution release. The release of an individual delivery team’s work needs to be scheduled so that it does not conflict with the releases of other teams who want to deploy into the same operational environment.
3. Manage infrastructure configuration. The release management team will work closely with your operations team, in fact they are often members of your operations team, to perform configuration management of your operational environment. To safely deploy into production you must know what is currently in production and how those hardware and software elements depend on each other. The more complex your operational infrastructure, and the more IT delivery teams you have, the more important this process factor becomes.
4. Determine production readiness. Part of the release process is to verify that the solution is ready to be deployed and that the stakeholders are ready to have it deployed to them. The bigger and more infrequent your releases, the more this becomes an issue.
5. Support delivery teams. The release management team, when a separate one exists, will work closely with the IT delivery teams to help them deploy successfully. This help may take the form of coaching the team on deployment techniques, on planning, and even working with them to automate their deployments. The release management team will often help with deployment testing, the verification after the fact that a deployment was in fact successful.
6. Govern releases. Your organization’s overall release efforts should be governed, ideally with the aim to streamline those efforts as much as possible. This governance will include the development of policies and guidelines pertaining to the release process as well as the identification and collection of pertinent metrics. This is part of your overall IT governance efforts.
III. Project Stage Gate Plan
IT Architects provides a Project Stage Gate Planning Framework to help an organization develop a Project Stage Gate process and plan, and define stage gate acceptance/rejection criteria and transitory stage gate activities. The IT Architects’ Stage Gate Plan defines the roles, activities, events, stage gate constructs, decision criteria, and alternate paths for the following stages of system delivery, system integration, and process change and/or improvement initiatives:
• Stage 1 – Business Opportunity & Discovery
• Stage 2 – Business & IT Requirements & Scoping
• Stage 3 – Business Plan & Project Plan/Charter
• Stage 4 – Development & Configuration
• Stage 5 – Testing & Validation
• Stage 6 – Implementation & Deployment
• Stage 7 – Support & Maintenance
IT Architects offers this the Project Stage Gate service for rigorous system development, which typically requires a capability to identify problems and assess progress before the project’s conclusion. Poor projects can be quickly rejected by disciplined use of the process. When using the Project Stage Gate process on a large project, the process can help reduce complexity of what could be a large and limiting innovation process into a straightforward rule-based approach. When the Project Stage Gate process incorporates cost and fiscal analysis tools such as Net Present Value, the organization can potentially be provided with quantitative information regarding the feasibility of developing a system solution. Finally, this process is an opportunity to validate the updated business case by the project’s executive sponsors. One problem with the Project Stage Gate process is the potential for structural organization to interfere with creativity and innovation, as overly structured processes may cause creativity to be reduced in importance and to hinder the largely iterative process of innovation where emerging technologies can be a business enabler within organizations.
