In this category, you will learn about Release Management and Go Live, hand over and sign off, success stories and lessons learned, and when you need to track benefits with Finance.

Release Management and Go Live

Release Management is the process of managing, planning, scheduling, and controlling a software build through different stages and environments, including testing and deploying software releases. It is required any time a new product or changes to an existing product are requested. These are the key activities:

Plan Release

  • Alignment with business stakeholders (requirements, scope, schedule, dependencies with other releases, legal)

Build Release

  • Design and development work is completed
  • Issues are identified and corrected

User Acceptance Testing (UAT)

  • Collect all data and make fixes to get the product where it needs to be for the actual launch
  • The overall build must pass UAT to move to the next step

Prepare Release

  • All documentation is completed
  • Quality Assurance sign off
  • Release management checklist is completed
  • Product Owner approves release

Deploy Release

  • Send out communication and conduct training if required
  • Ensure Support and Operations are informed, trained, and ready to support

Go Live

Go Live is the time at which a product becomes available for the end user. In IT, we may also use the term Technical Go Live, which is when the code or configuration is first moved to a production environment but is not immediately launched to end users.

When setting a Go Live date, be sure key stakeholders are aligned and that you are planning strategically by going live on weekends or during out-of-office hours to minimize impact, for example.

Technical Go Live

During this time, the cutover plan, which includes all critical activities that need to occur before Go Live, should be reviewed with all relevant stakeholders. A communication plan targeting the project team and stakeholders is also essential.

End User Go Live

Again, a communication plan is essential, this time targeting not only the project team and stakeholders but also ALL end users.

To ensure adoption, evaluate with your stakeholders whether the system being replaced should be decommissioned and whether end user access should be removed. In some cases, keeping the old system available minimizes risk, but in other cases, it can confuse users.

Hand Over and Sign Off

Hypercare
A Hypercare period (or warranty period) is the period between a Go Live date and the official project closure date. The goal of Hypercare is to ensure appropriate levels of support are provided during system stabilization, issues are addressed quickly, and knowledge transfer is occurring to delivery organization and end users.

During Hypercare, PMs should:

  • Monitor the work from beginning to end to ensure processes are behaving as expected
  • Track defects, and close them once they are fixed
  • Make sure all functionality is part of Hypercare; for example, if your main process includes a month closing from Finance, the Hypercare period should cover the month closing. This is very important as not all functions and processes may be used immediately after Go Live
  • Ensure the support model is following defined processes
  • Communicate as appropriate (daily, bi-weekly, weekly)

Before closing the Hypercare period:

  • The business needs to approve closure based on the stability of the application and the number of incidents or defects open
  • Ask: Is the support team ready to support it? Prior to releasing the project team, ensure the support team confirms that knowledge transfer has taken place (skills and documentation)

Hand Over

After completing a project, the project team needs to hand over support and maintenance to the appropriate team. This includes all information to support users and maintain the solution over its lifetime.

As a PM you are not only responsible for delivering the project but also for making sure everything is appropriately handed over to Operations. This is a critical step in closing out your project.

Ask yourself the following questions when executing hand over:

  • Will the IT Service Desk or CDS Service Desk support this product? If YES, a Knowledge Database in ServiceNow should be created, in coordination with the Service Desk manager. Knowledge Databases are created in order for Service Desk agents to support the application. If the business will support the product, it is still recommended that you create a Knowledge Database in ServiceNow, as the agents will need to route the user to the right support contact.
  • Will my product need to be supported by a specific IT group? (Client Services, AMS, ERP support, Integration Team, External Team, etc.) If yes, the PM needs to align with that group to deliver appropriate documentation.
  • Is it clear to end users how they can contact support and escalate issues?

Project Close

Project Close involves the process of finalizing all activities to formally complete the phase or project. The PM reviews all prior information relating to project scope, objectives, deliverables, timeline, and cost and compares it with the actual results to ensure that all project work is completed and that the project has met its objectives.

Proper project closure allows us to measure project success both with tangible and intangible metrics. Collected lessons learned and identified areas of improvement help ensure future success and assist with continuous improvement. The official sign off on the project and hand over of support and maintenance-related activities releases project resources. Closing contracts releases Ecolab from all obligations to external providers. Acknowledging the work completed by the project team fosters positive feelings and supports commitment in future projects.

A Project Closure meeting is advised, and the following steps are required from PMs:

  • Review the Project Charter with the Project Sponsor to ensure the objectives of the project were met; the Project Sponsor is required to sign off on the Project Charter at close
  • Officially communicate the project closure to all stakeholders
  • Complete the Project Closure Survey
  • Ensure all invoices have been cleared for the CAR and notify Finance
  • Change the status of the project to Completed in PPM and move it into the Post Delivery Phase

Project Success Stories and Lessons Learned

It is important to celebrate and recognize successes, which can be done through project success stories. Here are some guidelines for creating a project success story:

  • Keep it to one page and make it visual; feel free to use the Global Template on the Intranet or create your own
  • Identify the PM, Scrum Master, Product Owner, and Project Sponsor
  • Include a high-level project description, explaining the problem and describing the solutions implemented
  • List the business impact, including financial benefits if applicable
  • List key project takeaways

Every project has lessons learned and it is very important to track them in PPM in order to share them with our community and ensure that the lessons do not repeat in other projects. At the end of a project, all lessons learned can be grouped and presented to relevant stakeholders. Each quarter, the IT PMO shares key lessons learned to ensure visibility.

Tracking Benefits

If an IT CAR is required, the benefits should be clearly called out in the Project Summary of the CAR, along with the method to track these savings. The PM should always be able to track predicted savings and cost reductions and should partner with their respective Finance representative for all key Objectives, Goals, Strategies, and Measures (OGSM) projects to track savings.

A post-delivery review should be conducted with the Project Sponsor and the Finance representative for projects with stated Type 1 or Type 2 benefits. Examples include:

  • Cost reduction (e.g., elimination of headcount or reduced workload)
  • Work or process efficiencies (e.g., reduction in time needed to complete a certain task or process)