What’s on your go live project checklist?
From the The Money Files Blog
by Elizabeth Harrin
A blog that looks at all aspects of project and program finances from budgets, estimating and accounting to getting a pay rise and managing contracts.
Written by Elizabeth Harrin from RebelsGuideToPM.com.
Recent Posts
Making social impact part of everyday delivery
Who really owns the project budget? Clarifying financial accountability
How to learn AI the sensible way
Making sense of project cost reports
How real PM mentoring actually works
Categories
accounting,
agile,
ai,
appraisals,
Artificial Intelligence,
audit,
Backlog,
Benchmarking,
benefits,
Benefits Management,
Benefits Realization,
Bias,
books,
budget,
Business Case,
business case,
business case,
Career Development,
Career Development,
carnival,
case study,
Change Management,
checklist,
collaboration tools,
communication,
Communications Management,
competition,
complex projects,
Conferences,
config management,
consultancy,
contingency,
contracts,
corporate finance,
corporate finance,
cost,
Cost Management,
cost management,
credit crunch,
CRM,
data,
data security,
debate,
Decision Making,
delegating,
digite,
earned value,
Education,
Energy and Utilities,
Estimating,
events,
FAQ,
financial management,
financial management,
forecasting,
future,
GDPR,
general,
Goals,
Governance,
green,
Information Technology,
Innovation,
insurance,
interviews,
it,
Knowledge Management,
Leadership,
Lessons Learned,
measuring performance,
Mentoring,
merger,
methods,
metrics,
multiple projects,
negotiating,
Networking,
news,
Olympics,
organization,
Organizational Culture,
outsourcing,
personal finance,
Planning,
pmi,
PMO,
PMO,
Portfolio Management,
portfolio management,
presentations,
privacy policy,
process,
procurement,
product management,
productivity,
Program Management,
project closure,
project data,
project delivery,
Project Success,
project testing,
prototyping,
qualifications,
Quality,
quality,
Quarterly Review,
records,
recruitment,
reports,
requirements,
research,
resilience,
Resource Management,
resources,
risk,
Risk Management,
ROI,
salaries,
Schedule Management,
Scheduling,
scope,
Scope Management,
security,
small projects,
Social Impact,
social impact,
social media,
software,
software,
software,
Stakeholder Management,
stakeholders,
Strategy,
success factors,
supplier management,
team,
Teams,
testing,
testing,
timesheets,
tips,
training,
transparency,
trends,
value management,
vendors,
video,
virtual teams,
workflow
Date

Every project needs a go live project checklist – at least, projects where there is a substantial ‘go live’ moment, like a software launch.
The checklist is helpful because it confirms what is needed to go live: the steps and actions that should have been completed. It’s a reminder of what work is required in the run up to the big launch – or the small launch if you’re doing things in a phased or incremental way.
I’m a big fan of go live checklists because they help take the emotion out of the decision about whether or not we are ready. If we have ticked all the boxes, we’re ready. It makes the go/no go call very straightforward.
Here are some typical things to include on a checklist, although bear in mind that every project is different and you’ll need to make sure the items on your list match what it is you are doing.
- Technical infrastructure in place for the production environment
- Adequate staffing in place and critical staff available, taking into account holidays and sickness etc – too many people off and we might delay the launch until they are back
- Support teams and helpdesk briefed
- Go live plan produced and circulated
- Business acceptance testing complete
- Contact list created and circulated
- Communications about the launch drafted and approved
- Major risks reviewed and a decision taken about whether any of them are substantive enough to affect the plans.
We would also book a go live meeting. I remember one call we had for a big software pilot and going round the (virtual) table and asking each workstream leader to say ‘yes’ or ‘no’ depending on whether they felt the go live criteria had been met. It was a challenging call, because while we had on paper met the criteria, things were still a bit wobbly.
These conversations give you a chance to get all stakeholders on the same page about whether to go or not, and that’s helpful for creating a shared sense of responsibility as soon as you make the decision to get started!
I’ve noticed a trend towards incremental delivery and smaller launches, even on projects using a predictive methodology. There is still a place for a go live checklist, because getting everyone together to make a joint decision about next steps is still valuable. It’s the opportunity to get sign off on the approach and next steps from the business representatives, IT representatives, vendor, sponsor and anyone else who has an interest in what happens next.
When to use a checklist
Timing your go live is really important for maximum impact and availability of support staff. For example, we would never put an IT system live on a Friday as there would not be enough project team members around over the weekend in case of issues. We would put software changes in overnight, and have enough staff around in the morning to monitor the system and deal with any unforeseen issues.
Think about when you are going to have your go/no go call and when your go live is going to happen. The call itself needs to be close to the go live but probably not the same day, for example it would work well to have a call on a Friday for a Monday go live, or a Tuesday for a Thursday go live. But look at your schedule, consider the impact on users and make a decision as a team.
Do you use go live checklists? What other items would you put on a generic checklist? Let me know in the comments below and save this post so you can come back to it when you need it!
Posted on: June 20, 2023 08:00 AM |
Permalink
Comments (9)
Please login or join to subscribe to this item
Marco Rosales
Project Manager| Hancock Bank
Mandeville, La, United States
A backout plan should always be part of any deployment. What if the rollout fails completely? How do you roll back to your original state? This should be part of the briefings with the support teams and deployment plan.
Aaron Porter
Community Champion
IT Director| Blade HQ
Payson, UT, United States
In the spirit of having a roll back plan, you should also identify the point of no return, specifically with software changes. Depending upon what you're changing, there can come a point where rolling back is no longer an option. A couple of reasons for this are 1) changes are committed and can't be rolled back, and 2) the amount of time needed to roll back exceeds the downtime window.
I've also had an experience where, due to compliance reasons, we couldn't roll back. There was a failure on the vendor's end, the vendor didn't have the right resources available, and we had a really long weekend. Lesson learned - having the vendor be part of the rollout planning isn't always enough; verify their resource availability (trust but verify).
@Marco, yes, that backout plan is so important.
@Aaron, that's a great point - sounds like it was learned the hard way!
Ming Yeung
Adjunct Professor| Various academic institutes
Toronto, Ontario, Canada
I concur with fellow PMs on the need of a rollback plan in case of a failed implementation with high level of certainty on project resources on the execution of the rollout where applicable. Thank you.
Patrice Blanchard
Expert in transferring his expertise| Museum Box srl
Braine L'Alleud, Brabant Wallon, Belgium
A very important document to have with your checklist is an exhaustive list of the known open issues and a clear status of what is delivered and what iss not.
So often customers have an incorrect understanding of the product that is pushed into production and they are surprised afterwards because it doesn't work as expected.
Having a clear acceptance of the compromises the customer must accept (the open issues left) is very important to get a common understanding of the to-be situaion.
Of course this requires openness towards the customer and no open issues hidden under the carpet.
But this little investment has a huge value to avoid future discussions.
I thought that a yes/no round on the call is old-fashioned, but I see your point of shared sense of responsibility.
That sense has been actually a kind of the issue I've met during
go-lives.(at least until implementation is deployed with success)
Binay Samanta
Director| Project & Environment Consultants
Dhanbad, India
Proper deployment of resources is essentia
Excellent work, very interesting what is described in the publication
Absolutely agree! A go live checklist is essential for smooth launches. Timing the go/no-go call and go live is crucial.
Please Login/Register to leave a comment.
|
"The secret of life is honesty and fair dealing. If you can fake that, you've got it made."
- Groucho Marx
|