of impending changes. You may have to fight for preparation time early in a project, but specify it in a work breakdown structure or build it into your regular deployment process so that the team doesn’t feel ambushed when they are working against different deadlines than those you have in mind.
5. Understand the Impact
Well before software changes are deployed, clearly discern the impact on the existing system(s). You may have to adjust your expectations for release timing or the availability of people based on what subsystems are affected by the proposed changes. During a finite window at 3 A.M. is not the opportune time to discover that particular expertise or access is needed to complete the work. By the same token, understand what systems are reliant on the changes and ensure that relevant batch jobs or other activities are placed on hold if need be during the deployment work. A couple of things that often trip up a release are the preparation of hardware and the related network integration. Setting up URLs and getting site certificates are also common “gotchas”. They are most likely not your responsibility, but it never hurts to ask if the work is completed. I thoroughly recommend a pre-launch meeting with the team to go over each step of a release to make sure that everything is covered and everyone knows the times and personnel involved in each activity.
6. Get the Right People Involved
Make sure that the people who will (or may) be needed to successfully deploy the software are scheduled and prepared. They will need to know the appropriate timing, as well as the location or conference numbers and access codes. Know who is required to be on site and who can simply be “accessible”. You may have a project manager to chase these details down for a major release, but if you’re doing a regular deployment, odds are you will have to do it yourself. Where possible, create calendar entries in the email system so it’s easily visible to the others and actively reminds them.
7. Communicate the Release
Communication is important before, during, and after the release. In some organizations, the communication is split internally and externally so that a business representative will be the conduit of information to the client. Team members should know in advance what’s happening and be kept aware of progress during the release process. Clients, managers, and team members may all require different forms of correspondence in terms of content and formality. Distributions lists created in advance can be extremely handy to avoid leaving someone off of an email at a critical moment.
8. Execute Efficiently
Time is quite frequently at a premium during a software release. For both significant projects and maintenance work, the order of work should be delineated in advance and structured to improve quality and reduce the expenditure of time. Most releases are not done single-handedly, but involve numerous individuals from across the organization, each with a dollar cost associated to the work. Per hour costs can run easily run into the thousands depending on the complexity of the release.
9. Verification and Validation
As the objects are deployed, a team should be verifying successful implementation of the code itself. This might take the form of running sp_help on databases or running server audits to ensure the right material was migrated successfully. Post deployment testing by the QA group, client or business, or both should validate that the code is operating as intended. Just as before release, the test teams will face pressure to complete the work quickly. Don’t hesitate to step