The steps that various project teams must plan and execute in order to complete a project successfully are often discussed in blogs. A crucial step in this process is the final go live. It would be a shame for a well-planned and executed project to fail at its very last hurdle - go live.
The go live phase can be mitigated by planning it in detail. The planning of the go live is an important aspect of the project that is often overlooked. Due to the fact that in today's world there are so many components that comprise the go live process. From the various technical objects that have passed through the environments to the data migration and loads (from the legacy systems) that need to be performed. There may also be a number of configuration items, database items, and other technical setup and authorizations associated with the implementation.
The production readiness checklist has been a key component of our success in delivering projects on time and on budget. Checklists for production readiness are essential for a successful launch of a project. Thus, the key value add is not the focus they provide to the core project team, but rather the degree to which the various teams (on the periphery of the project) are prepared for production.
This is a crucial step towards enhancing the customer experience (the reason for implementing the project in the first place). In the event that the application you are implementing does not function, is slow, (or is vulnerable to hacking), you will quickly lose revenue and the trust of your users and customers. Aside from losing credibility with your customer base, you also need to explain the failure to your internal stakeholders and steering committees, and bear the brunt of the consequences.
A project's go-live window or period for production installation is generally clearly defined. In addition to these "go live" windows, there are other business priorities such as monthly "freezes", quarterly "freezes", and year-end "freezes" as well as production system patching windows (among others). It follows, however, that if a project implementation fails, a new date must be negotiated from the outset (while competing with the above priorities).
Back to Production readiness, why is it necessary? As a result, the project manager and the teams are able to consider what is required from all aspects of the go-live. Below are a few phases that can be used to determine the level of readiness:
Non-technical Phase
Technical Phase
Go Live Date – Planning / On the day
This phase focuses on the non-technical components of the rollout. Examples are as follows:
Change Management Processes
PR processes (if required)
Communication Processes
Training of the Users
Change Management Processes
Any software artifact that is to be produced must follow a Change Management Process.
To ensure that the larger IT user community is aware of the changes, change management is necessary
Various stakeholders will be informed of the magnitude and complexity of the change through a CAB (Change Agency Board) meeting
There are typically CAB meetings occurring daily or weekly (sometimes more frequently in some organizations) and the go live dates are determined by the overall IT landscape (considering ALL aspects of the environment).
PR Management Processes
Due to the nature of some projects, PR processes must be followed in order to produce the systems.
When a project of a particular nature is completed, the project manager must define the message to be conveyed to the stakeholders.
Management must be capable of managing both successful and unsuccessful implementations of the system
There is always a preference for pro-activity over reactivity
Communication Management Processes
Communication processes (within an organization) are vital to the success of a rollout.
It typically happens prior to the go live date (typically 1 month to 2 weeks prior)
The communications department sends out a communique to stakeholders informing them of the impending change.
2 days prior to the go live date, another communication is sent to stakeholders informing them of the impending change(s).
It is at this point that the Change Agents' Network (CAN), the implementation team, and the management are preparing themselves for the implementation process to begin.
There is a specific date and time for the Go Live as well as other pertinent information.
The "downtime window" of the systems is clearly specified, (both start and end times) - giving the teams an idea of the time needed to complete work.
The community is given the assurance that the system has been tested and is in a state to be taken into the Production Environment
There is an important point to note: the Go Live / Project Team's contact information is shared, as well as the names of the key members of the team, so that the user community knows who to contact in the event something goes wrong during implementation.
Training Management Processes
The training of users is critical to a successful go-live, as they will be the first to see the new system and report on how it performs.
Users should receive training before the go live date, but not too far in advance - as the users may forget how to utilize the system and the new functionality - creating additional project risks.
The training should be conducted on a system that is HIGHLY representative of the one that will be used in production.
A technical / project manager is usually responsible for notifying stakeholders of the availability of the system following the Go Live process.
Technical Phase (Planning)
To ensure a smooth implementation, this activity is extremely important. The following are some typical activities that take place during the delivery of a project:
Set up meetings with the technical team to:
Understand the dependencies between code, data, and configuration
Ensure removal of roadblocks / key man dependencies
Ensure compliance with technical and governance processes
Teams can consist of Developers / Configurators / Data Base Administrators / System Analysts / Architects / etc. This is highly dependent on the type of roll out that you are managing.
Set up meetings for the CAB Meetings for Approval
Book the CAB well in ADVANCE
Organize all the SIGNOFF's as required by the LEVEL of the change
Articulated the Environments (More than one PROD environment that
will be affected)
Understand which interfaces (which will be affected and for how long)
When you are a member of the CAB, as a Project Manager, you must be prepared to:
Answer all the questions posed at the CAB Session
Come prepared – have your technical team accompany you if needed
Have all your documentation at hand
Set up meetings in the Go Live War Room
Book a venue / virtual team meeting for the duration of the Go Live, over the period when the change will be done
Confirm attendance of Technical and Business Teams
How long will the changes take to roll back (if they are not successful)?
Send invitations to all team members to attend in person or virtually.
Describe the Rollback Plan and steps to resolve the issue.
Database restore
System restore
User Access restore
It is critical to return the System to the state it was in prior to the upgrade.
Articulate the Post Implementation Communications
In the event of a successful go live, then the system will be stabilized by the team, and then monitored carefully over the next few days - up to a month (depending on the type / size of the rollout. The system might also be placed in a state of HyperCare where there is constant monitoring of throughput as well as technical activity and stability.
What happens when there is a failure? The PM and the Change Management team need to (after the successful rollback) explain the reasons for the failed Go Live!
There are a number of factors to consider when determining when to implement
Magnitude of the changes (how many points of failure)
Resources required to support the change once implemented
Recovery Time – how long to restore the system to its original state
Allowed Time window (Business only allows a weekend Go Live)
Conclusion:
It is important to deliver successful projects when managing projects - but this should be done with the least amount of disruption to the business. As part of the project team transition, new code, data, and configuration are being moved into the production environment. There's a risk here, but regression testing can minimize it.
Another important factor is the availability of key staff members in order to ensure a smooth transition into the PRODUCTION environment. It is important to take into account the important business dates, such as year-end and month-end, and any other processes that are crucial to the continuity of the business.
Some further factors are as follows: Can the work be done over a weekend [ on site / on-line ]. Can it be done overnight at a preselected time slot, or during the day (where operational working hours will be impacted).
Last but not least, a major consideration is the user availability, and how can we incentivize end users to test and sign off on system readiness?
For the Project Manager, managing all the moving parts is crucial, and the Production Readiness Checklist is an invaluable tool!
Comments