Planning the deployment of a business critical development project is never an easy task. Naturally, when a successful deployment is the only goal, planning is something to really invest in. I recommend this process for deployment planning:
When to plan
Start planning the deployment either at the end of specification phase or at the beginning of the building phase, but always before acceptance testing.
The draft
First, make a draft of the plan with the vendor(s). The draft doesn’t need to be perfect, but it should include major steps and preliminary schedules. Include the tech people so you can be sure that the draft is realistic. This is to get an understanding, when the deployment would be possible.
You need the big picture, a clear idea about when and how long will the business down time be, and a communication plan – when to inform everyone involved and what are the messages.
It’s also important to understand how the day-to-day business changes after the deployment, for example business processes and people’s job descriptions.
Communicating with the business
Go through the draft plan with business. This is best done in fairly small groups maybe one business area at a time. People tend to be more communicative when there’s not that many people involved, especially people they don’t know.
Check, which functions are business critical and need to be 100% percent secure and working.
Plan the down time. Go through any breaks in the system availability, and their impact on business. What happens if the system is unavailable from Friday 12:00PM to Monday 06:00AM or whatever the planned cut-over window is.
Make a communication plan on how and when to inform staff, clients and other parties the deployment affects.
Deployment plan (Cut over plan)
Even though Excel is fine for making plans, there are far better software for demanding deployment planning.
Here’s the basic structure I prefer in deployment planning.
- Preliminaries + briefing + reserving resources
- Check point, Go/NoGo
- Timespan from 5 to 1 days before deployment
- Check point, Go/NoGo
- Cut over
- Check point, Go/NoGo
- Production test/authentication
- Check point, Go/NoGo
- First day in production use
- Check point
- Second day in production use
- Check point
The plan will include hundreds of activities for dozens of people, so communication and clear task list on what to do and when, are critical.
Rollback plan
The rollback plan is like an insurance. Hopefully it’s unnecessary, but it does make sure the business is safe if something goes wrong.
Deployment exercise
Deployment should be tested before actually going live. You will verify that everything can be done within the time window and see if there’s something you missed when planning.
A good time to do the deployment exercise is when you start acceptance testing. This will also make your acceptance testing better. Read more here.
Observations from the deployment exercise help finalize the deployment plan and make sure you didn’t miss anything.
Going through tasks and the communication plan
Go through every task with every resource, so they know what to do and when. Make sure they know how to check/ report the tasks as ready, what to do when there are problems, and who to contact if decisions are needed.
Releasing tasks to task lists
The deployment must be done one step at a time, in a controlled manner that allows you to make go/no go decisions at each check point. Thus resources can work on tasks set to our current check point, but not tasks that come after the check point.
I use ProjectTOP, so I just do this:
- Tasks that can be done are set in status: Open
- Tasks that can NOT be done yet are set in status: Pending.
When the check point has been passed ok, I release the next set of tasks.
Check points
Real time information of task progress and any occurring problems is important. If the problems are just passed around in emails, making decisions is difficult. Systematic communication is an important part of deployment management.
Check point meetings need to include decision makers, so that decisions can be made at the spot.
With these steps you will avoid many common issues in deployments. One post isn’t really enough to break it all down though. Every project is different and you will have to adapt these guide to your situation. But whatever your project is, this is the most important piece of advice: Don’t think about what is the easiest way to plan the deployment. Think about what is the easiest way to manage the deployment.
Want to hear more?
Book a 30 minute chat and we’ll see if ProjectTOP is good fit for you.
Want to hear more?
I would love to have a chat about your deployment project. Book a 30-minute meeting with us and see if there’s anything we could help you with.
