Planning business critical development project deployment is a challenging task. Naturally, when a successful deployment is the most important goal, planning is something to really invest in. I recommend this process for deployment planning:

When to plan

Deployment planning is good to get going either at the end of specification phase or in the beginning of the execution phase, but always before the acceptance testing.

Deployment requirements may cause changes to execution.

The draft

First, make a draft with the vendors. Include the tech people so you can be sure that the draft is possible.

You need the big picture, information about the breaks and communication material.

It’s also important to have information about how deployment changes the business, for example people’s job descriptions.

Communicating with business

Go through the plan with the business and in sufficiently small groups, so you can truly plan the deployment.

Check, which functions are business critical and need to be made secure.

Go through any breaks in the system availability and their impact on business.

Make an agreement about communication with clients and collaborators.

Deployment plan (Cut over plan)

Even though Excel is fine for making plans, there are far better softwares for demanding deployment planning.

Here’s the basic structure I prefer in deployment planning.

1. Preliminaries + briefing + reserving resources
   • Check point, Go/NoGo
2. Timespan 5 → 1 d before deployment
   • Check point, Go/NoGo
3. Cut over
   • Check point, Go/NoGo
4. Production test/authentication
   • Check point, Go/NoGo
5. First day in production use
   • Check point
6. Second day in production use
   • Check point

The plan will easily include hundreds of activities for dozens of people, so communication and collaborating with the plan is important.

Rollback plan

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. Moving on to acceptance testing as an deployment exercise is a fine way of doing it. Read more here.

Observations from the deployment exercise help fix the deployment plan.

Going through tasks and the communication plan

Go through with every resource, so they know what to do and when.

How the tasks are checked as ready, what to do when there are problems, decisions are needed etc.

Releasing tasks for job lists

Resources can do tasks that are set after accepted check point, but not those tasks that are after unaccepted check point.

Because I use ProjectTOP, I 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, 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. Planned communication is an important part of management.

Check point meetings need to include decision makers, so that real decisions can be made.

One post about this subject can’t really drill it down. Because every project is unique, no general guidelines can be given. Except for this: Don’t think about how to easily make an deployment plan. Think about how the deployment is most easily managed.