One of the most important documents you can have at your disposal as a release manager is the corporate release management policy. This is the document that sets out the key terms of release management and the rules for deploying releases into the production environment.

If you need to create a release management policy, start by looking at other policy documents in your organization so that your new policy has a consistent look and feel to other documentation used within your enterprise. This will make it easy to understand and follow (as well as making it look official).

This policy should include elements such as:

• Schedule – how often will releases be allowed. This will depend on the cadence of your organization, and there’s “no one size fits all.” Some organizations deploy releases multiple times a day and, at the other end of the scale, there are other businesses that might release far less infrequently. There’s no right or wrong answer, only what meets the need of your business stakeholders (in terms of balancing benefits, costs, and risks).
• Quality criteria – ensuring that the release is fit for purpose. This policy section will include quality gates and the criteria needed to exit each stage of testing ahead of making the new, or updated, service available to the business.
• Roll-out planning – how will releases be deployed in your environment? There are multiple options, from big bang to phased, to pilot releases to parallel environments, to continual release models. Know your business and its appetite for risk before proceeding here.

When performing service testing, here are some points to consider:

• Validation of utility – ensuring that the service is fit for purpose and meets the operational, functional, and management requirements of the service as per the test criteria agreed to by business, customers, and stakeholders.
• Verification of warranty – ensuring that the service meets the availability, performance, and redundancy requirements set out at the design stage.
• Use agreed test criteria – such that testing includes entry and exit criteria throughout each stage of the process, ensuring that all criteria have been double checked and validated.
• Use governance and policy testing – ensuring that any, and all, regulatory requirements have been met.
• Apply test models – to test business processes to ensure that the end-to-end service works as expected by the end-user community.
• Use test types – these are the tools, techniques, and methods used in each test model so that testing is carried out consistently.

When creating a knowledge management, or knowledge sharing, capability look for quick wins – the things that can get results quickly and deliver real value.

Some examples, starting with common knowledge-sharing issues, include:

• Including representatives from the IT service desk in the user training for major releases. All too often the service desk is the last to know about new products and services. And, even worse is when no one tells the service desk that something new has gone live and they’re forced to handle incidents and service requests with no knowledge or training to fall back on. By including the service desk in end user training the involved analysts will get a holistic view of the new, or changed, service and can then document the highlights for the rest of the team to use when dealing with related tickets.
• Documenting the most frequently-logged tickets for your most business-critical system. You might not be able to fix everything at the first point of contact but having the most common issues documented will improve first time fix rates as well as freeing up second- and third-line support for the more challenging issues.
• Capturing information about legacy systems – there’s always at least one application that predates almost everyone in the IT department, which then depends on the skills and expertise of one or two people. Document what was done to resolve each and every incident related to these applications to build up a basic support document for the services.