In the last month, I had to be on top of four different deployments, and after four smooth (but not issue-free) runs, I’ve decided to write down a list of things I keep in mind for future deployments. Maybe that way, the deployments will finally be issue-free.
So here are a few things to keep in mind when planning a deployment to production (from a Project Manager’s perspective)
- Deadline
- Website might need to be “under maintenance”
- Inventory of all expected changes (Client’s expectations)
- Inventory of all expected changes (PM’s expectation)
- Inventory of all things that need to be done manually
- Testing environment should be almost identical to production
- Team member in charge of deployment
Two of this month’s deployments were system updates. In most of these cases, the planning is a whole lot simpler. The client isn’t really expecting anything (date or functionality wise), and as a PM all you expect is for the system to keep working exactly as it used to. Still, you will need to know what is being updated, and when the developer is planning to deploy. In most cases, deploying those updates requires scheduled downtime so it’s always better to know in advance when the down time will be happening.
The other two deployments were about adding new functionality and improvements to the system. For those cases, I definitely recommend completing the list above.
Deadline
I probably don’t have to tell you this, but knowing the date the client expects the deployment to be ready, is a must. And you should try to get it as soon as you start the work. This way, you can plan your way back to ensure you meet the deadline without any major inconveniences.
If you’re doing Agile, you should be showing your progress to all stakeholders frequently. But depending on the size of the job, I would recommend you have a release in your staging environment so stakeholders can test it, at least 2 weeks before the deadline. That way your team can have 1 week to make any necessary adjustments.
Of course, always expect stakeholders to be asking for last minute changes. If you’re lucky, most of them will be tiny ones and your team can meet the deadline.
Website might need to be “under maintenance”
During a deployment, the site might need to be under maintenance. You need to know if it’s necessary and for how long. That way you can schedule the deployment to best suit the needs of the client and the system’s users.
Inventory of Changes (Client’s expectations)
You probably already have a list from the client with all the expected changes, but it’s likely incomplete. Update that list every time the client asks for a new change or a tweak. I recommend you use this list at least twice. Once when after the release in the Staging environment, and a second time after the deployment to production. In both cases, go over each item and make sure it was done correctly.
Inventory of all unexpected changes (PM’s expectations)
When working on the changes requested by the client, a few bugs might come up. I suggest you update the Inventory of Changes with these items.
Inventory of all things that need to be done manually
This one is as much for you as for your team. During a deployment, there might be a few things that need to be done manually. Make sure you the whole team has access to this list. This items will probably be part of the Inventory of Changes, but they should also be kept on a separate list to go through during the deployment, not after.
Testing environment should be almost identical to production
It is very recommended for all environments that will be used for testing, to be as similar to production. Before releasing the work to Staging for stakeholders to test, you should be able to test regularly in an environment (either dev or staging) that has a copy of production. And don’t leave this until the last minute! Ideally, by the time the stakeholders will be testing in Staging, all the work should be bug-free.
Team member in charge of deployment
This one might be very obvious, but always keep in mind who’s the team member in charge of deployment. This person needs to be always be aware of all the work that needs to be done, and everything the client expects from the deployment.
We could probably remove some of these points if we made automated tests for everything we do, but knowing myself, I would still like to go through all of them.
One last tip for planning, be transparent with the client. Make them feel part of the process by keeping them posted at every turn. They’ll appreciate your work and they’ll be more understanding if anything goes wrong.
