Release Schedules | Release Policy and Procedures

A key benefit of release management is being able to determine and schedule when a new IT service or enhancement will be implemented into the production environment. Being able to plan and schedule new functionality allows for better resource utilization, increased quality through planned testing, reduced financial cost, and greater implementation success. Another by-product of good release planning is the increase of customer satisfaction with the customer and end user.

There are two types of release schedules. The first is the enterprise release schedule, and the second is the release schedule of a specific service; both play a part in creating a successful release practice.

Enterprise release schedules are used to gain a holistic view of when all releases are scheduled within the enterprise. This type of release schedule is used primarily for the scheduling of development resources and financial planning. An enterprise release schedule should include, at minimum, a view of releases that are scheduled for the next twelve months, ideally, eighteen months to twenty-four months. Not only should an enterprise release schedule include releases by service, it should also include releases of cross-functional IT services used to support the business services and applications. An example of a release schedule would be: version 1.0 of a database is scheduled for May and an upgrade to that database to version 2.0 is scheduled for June of the following year. While this is important for the reasons previously stated, it can be more important for application teams to understand which versions of infrastructure or technology are being used since applications are typically built to use specific versions of technology products. If there is a change in version, the functionality of that technology product may change and the existing application functionality may not be able to work properly or may be disabled. Therefore, it is extremely important to understand when the underlying infrastructure of the enterprise is changing.

As illustrated in Figure 1, an enterprise release schedule can be as simple as a spreadsheet with products and dates or as complex as detailed release plans.

Release	Jan.	Feb.	Mar.	Apr.	May	June	July	Aug.	Sept.	Oct.	Nov.	Dec.
e-Mail		MGR		MR		MR		MR		MR		MR
CRM	MR		MR		MR		MR		MR		MGR
Receivables System	MGR	MR	MR	MR		MR		MR		MR		MR
Database Upgrade	MR		MR		MR		MR		MR		MR
MGR - Major Release MR - Minor Release

Figure 1: Enterprise release schedule.

Release schedules can play an important role in financial and strategic planning in terms of providing a roadmap showing when expenditures will be needed and providing the timing of capitalization of the assets being developed.

The second type of release schedule is related to the individual release of a specific service or application. While the common practice is to relate a release to a specific application or CI, consideration must be given to how that release will affect the specific service and related services. This type of release schedule can be called a service release schedule or a product release schedule. Typically, these types of release schedules contain both major and minor releases of the specific product or service. Major releases are typically scheduled once every twelve to eighteen months and involve significant planning and development. Minor releases can vary when they are scheduled from every thirty days to every six months; much of this is dependent on the stability of the service or product. A newly implemented service will typically require more frequent minor releases and as it becomes more stable, will require fewer minor releases.

When planning a service release schedule, several factors must be considered, including timing, resources, cost, funding, and business need. In some companies, system enhancements are implemented at the whim of the associated business unit or customer and are not scheduled. When this happens, the time to delivery may be quicker, however, typically the delivery cost is increased significantly and the quality is reduced due to inadequate planning and testing.

The release policy should include a couple of release schedule models to help the service owners understand the different time frames that could be used in developing their release schedules. Figure 2 provides some sample release schedule models.

Release Model	Program
Mature	Quarterly minor releases Major release 10 months
Standard	Minor release 6 weeks Major release 12 months
Unstable or new	Minor release 4 weeks Major release 8 months

Figure 2: Release schedule models.

An enterprise release schedule will be created when the individual service's schedules are rolled up into a holistic schedule for the enterprise. Both will be managed by release management; each at different levels. This is a very simplistic explanation of what a release schedule is, however, it gives the basic premise of understanding and helps to point out that there is no need to overcomplicate the creation.

Incident Management Plan Policies and Procedures

The IMP should be aligned with the overarching policies and practices outlined within the overall Business Continuity Management Plan. Information flow should occur according to the communications plan. Organic and outsourced expertise and resources should be leveraged in conjunction with the organizational interface plan and the resource and procurement management plan. Interaction with media, families, and other groups should be guided by the public relations plan, and crisis response actions and decisions should conform with trigger plans and decision and authority matrixes. The IMP should also operate within the auspices of security management plans, standard operating procedures and tactics, techniques, and procedure policies. All policies, procedures, and plans should be complementary, with minimal duplication and overlap to avoid confusion, contradictory guidance, and wasted resources. Often the IMP and Business Continuity Management Plan will complement or leverage any company health and safety plans, as well as existing policies on dealing with the media or other operating practices; and companies may wish to provide some form of guidance to managers as to how the IMP will operate within the Business Continuity Management Plan, and what is expected of them during a crisis event.

The IMP may also work within the framework of security plans, which might determine how security and risk management is undertaken within a facility. A degree of tailoring may be required to merge the IMP into specific regional or task policies and plans. The IMP may also be supported by government response plans, and the points of connection should be defined and aligned to ensure that friction between internal and external plans or protocols does not occur. Modifications to the IMP should be done only as sanctioned by appropriate managers (or an IMP Custodian) in order to avoid conflicts with corporate interests, as well as to reduce the amount of deviation from response measures and information reporting formats.

Information Security
Some aspects of the IMP may be considered sensitive in nature, and consideration should therefore be given to who is permitted access to the plan. Other elements of the plan will be generic and intended for a wider audience, such as fire drills or suspect call responses, and managers should ensure that information and training are made available to the different levels of user audience. Where necessary, terms such as restricted and unrestricted can be applied to different elements of the IMP in order to ensure that managers share appropriate information with a wider audience, or restrict information to defined positions as required. Each recipient of the IMP is responsible for its safekeeping and for ensuring that no unauthorized copies are made.

Web Server Policies and Procedures

- It is highly recommended that the Chief Information Officer formally approve the content and operation of any Web server to be connected to any organization system.

- Any and all Web site content and features must be approved and installed by the organization's Webmaster.

- Under no circumstances will sensitive information be made available on any company Web site internally or externally accessible.

- All enterprise Web sites must be reviewed, vetted, and approved in the same fashion as officially released reports or other outside correspondence.

- At all times, copyrights will be protected and observed.

- There should be no reason for control of the Web server other than from the Web server's console. Logging on to the Web server from any device other than this console is not permitted, and the server's software should be configured accordingly.

- Systems administrators, firewall administrators, and Webmasters are to report any and all attempts to gain unauthorized access to the Web server located on either the Internet or internal intranet.

- Incoming packet traffic will be scanned and connections to unapproved Web sites will be immediately reported to senior managers.

- Systems maintenance will include the installation of operating systems and applications patches.

- Senior administrators and Webmasters are responsible for change management. Any and all changes must be justified, documented, and submitted to a thorough quality control process before installation.

- Senior administrators and Webmasters are responsible for monitoring system performance, taking appropriate security measures, and ensuring Web sites reflect the highest quality standards.

- Implementation of common gateway interchange (CGI) scripts will be strictly monitored and controlled.

- In order to avoid buffer overflows, systems developers must keep buffer sizes defined when accepting data. In order to avoid CGI vulnerabilities, regular testing will be performed and appropriate security measures taken.

- All user input to any Web site, internal and external, will be filtered for appropriate content.

- In the case of third party applications interacting with programs that contain buffers that do not check for incoming data correctness, it is important that these applications are monitored and patched appropriately.

Web Server Security Policies and Procedures

Most businesses, governments, and organizations have external Web sites describing their purpose and structure, and often provide the opportunity for public interaction. E-commerce on the Internet is not something that only large businesses can afford to do. It can be a profitable operation for every "Mom and Pop" enterprise as well. For security reasons, Internet Web servers are usually positioned inside the packet-screening firewall that faces the Internet and inside the firewalls that protect precious interior networks. Such architecture has a good security track record if implemented correctly, and is called the demilitarized zone (DMZ).

Organizations may also choose to develop and deploy intranet Web sites for employee use. In these cases, the Web servers are located inside the interior network, as these systems are not intended for outside eyes. Regardless of the organization's size and whether it has Internet or intranet Web sites, considerable amounts of money and resources are spent in the development of a suitable Web site that is informative yet practical. In a very real sense, the company's Web site reflects the organization's branding, image, and business reputation.

The development, maintenance, management, and administration of the company's Internet Web site is usually assigned to a team of experts within the enterprise or outsourced. It is possible a director of online marketing development is responsible for identifying and implementing new online business development opportunities while the company's Webmaster takes charge of the site's technical excellence, content development, management, and security. On the part of the Webmaster, there is a development team responsible for site design, coding, graphics, and business features such as shopping carts.

Internal company Web sites are generally used for posting information relevant to employees. Birthdays, presentations, corporate calendars, directories, organizational charts, and project information are often posted. Project management information posted to an internal network can provide a central reference point for the project team and senior managers with project oversight. Internal Web sites do not have the same visibility as Internet Web sites, but they have the same need to be managed through specific policies and procedures.

Policies and Procedures Involving Outsourcing

Policies and Procedures Involving Outsourcing: What Is Yours and What Is Mine?

An organization's policies and procedures must govern the interaction between the organization and outside contractors.

Instead of structuring a relationship based on the value of service they are contracted to provide, they base it on the necessity of doing business, as they are the only people who have the source code. In other cases, they have not delivered sufficient documentation for the organization's employees to maintain the system, thereby requiring their continued services. It is essentially a monopoly of one. Because the organization does not have the source code to their custom system, it has lost control of one of its critical assets. Regrettably, this condition is usually brought to the company's attention after it has already happened. The situation grows more desperate as the company is reluctant to notify its lawyers, fearing that the contracted developers might sabotage the source code by modifying it to render it useless at some time. When structuring systems development projects performed by outside contractors, these are a few policy suggestions to reduce risks:

Get the source code. Be certain to investigate the work history of the contractor, and by all means contact all professional references to ascertain if there were any past problems. The organization must ensure it receives the source code, and there are contractual arrangements with strict requirements to this effect. No excuses are acceptable. The source code must be installed according to the organization's certification and accreditation policies.

Licensing and documentation. Purchase the appropriate licenses for the source code. Businesses want to replicate the development environment exactly, having the ability to keep the code up to date during the maintenance development phase. Make certain the contractor is drafting the required documentation of effort. This documentation should be subject to inspection and audit by the organization's representatives before the product is delivered. If the organization has the resources, any agreements must permit a representative of the organization to conduct an ongoing review of the code. This inspection must also include documentation.

Confirmation. Confirm that you are going to receive what you contracted. Force a rebuild of the programs if you are not satisfied. If you have to pay for it, consider it the cost of doing business.

Secondary plan. Have in the wings a backup developer or other reliable resource familiar with the code base and system design. What if the contractor becomes disabled and is unable to complete the project?

Ownership and delivery. The organization's policy should require that the contract stipulates who is going to own what. Who owns the software? Does the organization own the software or merely a license to use it? Does the organization own the software to such an extent it may do what it wants with it? Write the contract carefully, and by all means have an attorney familiar with these issues review it before signing.

The best outcome is one of complete control where the organization has its asset with the system working as intended in the event of a problem with the developer. What does the organization have to do in the event the developer fails? Much will depend on the contract's language, your lawyer, and the developer. If you have to go to litigation in order to enforce the contract, you may not have possession of your application, and litigation takes time. By the end of legal wrangling, it is possible everyone loses.

Vendor Policies and Procedures

Vendor Policies and Procedures
The size of business operations and the uneven demand for services influence the type and amount of outsource services required. Within the business, available funds are balanced with needs, and often they are not in agreement. Service vendors outside the organization come in a variety of flavors including consultants, technical service and hardware vendors, and contract human resources. Good business sense, based on ethics and morals, is the best policy in dealing with outside vendors.

Several units within the organization come into play when selecting outside services. The organization's purchasing unit should provide information about vendors, their reliability, financial status, reputation in the business community, and whether they will be in business a year from now. This is information that should be at hand before negotiating a contract.

The legal unit must review any vendor contracts before they are signed and large amounts of capital committed. One of the more-important tasks the legal unit performs is the review of the contract's performance language where there are penalties assessed in the event the vendor fails to complete its responsibilities.

The legal units must ensure there is contract language detailing that promised services or products meet the organization's expectations. This language needs to dovetail with SDLC provisions if services or products must be certified and accredited before the contract is fulfilled. If the project involves classified materials, the legal unit is responsible for requiring and verifying that contractors have security clearances.

The organization's audit unit should be included in the contract review to see that important provisions are detailed that will require its involvement. Such details involve auditing of ongoing contract compliance by the vendor. Auditors should be involved if the vendor provides services within the provisions of the SDLC. The contract should allow the review of development procedures and the quality of the services or product.

Outsource Potentials
Following are possible areas for outsourcing efforts:

- Operations that are difficult to staff and manage

- Providing special skills not available within the organization

- Reducing internal operation costs by not having to develop skills that will be used infrequently

- Delivering system improvements or benefits more quickly than can be performed internally

Consultant Procedures
Outsourcing consultant services can be a valuable asset if the proper relationship is developed. Consultants can just as easily be acquired or employed for all the wrong reasons. Following are several wrong reasons for contracting a consultant:

Not having clear goals and performance expectations. Having very clearly defined goals and performance expectations will permit maximum benefit to be derived from consultants.

If there is bad news for projects in trouble, let the consultant deliver it. Wrong idea. If a project is in trouble, the future of the organization's credibility may be at stake. Handle any internal project problems within the organization. Do not outsource them.

Contracting a "hired gun" from out of town to impress the locals. For some unknown reason, the distance the expert traveled, the cost of the expert, and the perception of the expert's skill set frequently impresses employees. Senior managers have an ability to be impressed with experts who have many titles behind their names. It is not unusual that a consultant came up with a solution that was the same as one developed by your own employees.

Weak senior management. Project managers lacking decisive skills will often attempt to employ consultants to make decisions for them. Consultants are contracted at the staff level of an organization. They should not be substituted for poor managers.

Outsource Vendor Selection Procedures
Choosing vendors for services, software and support, and hardware requires evaluation procedures. When a business decides it requires a vendor to submit proposals, a request for proposal letter is sent to all possible vendor candidates.

In the case of hardware, this request approach details the proposed time period, professional and financial references, hardware and hardware configuration, architecture, and requests a price quote. With software and support, a request defines the target system and asks the vendor to provide a support performance objective for a specific configuration. System operation performance requirements include systems design, configuration and architecture, types and number of users, production volume, maintenance and operation objectives, and price. Outsource service proposals should include at least the following items:

- Professional and financial references

- Objective of delivered services

- Security requirements

- Services delivery schedule

- Documentation

- Pricing

In all request for proposals, there should be a deadline by which proposals must be received by the organization to be considered viable.

Evaluating Proposals
All received vendor proposals should be analyzed in detail. There should be common elements addressing the specific proposal requirements. Organize an ad hoc committee to evaluate the submitted proposals and discuss them. Be mindful that there may be laws and regulations governing the request for proposals and their submission. Most notable are organizations requiring legal adherence of those doing business with federal, state, and local governments. Some governments have requirements where selection preference is granted to vendors doing business within municipal boundaries. In some cases, these restrictions are codified as regulations or laws, and in other cases they merely follow custom or tradition. Failing to observe such restrictions can result in protracted grievance proceedings and litigation.

Connecting to the Internet: Policies and Procedures of Survivability

Computer networks such as the Internet that do not have central administrative controls or unified security policies should be called open-ended networks. Because of their open-ended nature, there is no realistic way to determine just how many nodes are attached to the network. Regardless of the best efforts of information security officers, no degree of hardening will assure that a computer system that is connected to an open-ended system can be made invulnerable to attacks. However, if systems were designed with the goal of delivering profitable services while maintaining properties such as confidentiality, integrity, and availability, they would go a long way to contributing to an organization's survivability in the face of disasters.

Today's large-scale networks are highly distributed in an effort to improve efficiency and effectiveness by permitting high levels of integration. These levels of integration, while providing great strength of communication between networks, also carry elevated risks associated with unauthorized intrusion and compromise. These risks can be somewhat mitigated by implementing survivability in an organization's systems. Survivability incorporates risk management, fault tolerance, performance testing, and auditing.

Survivability is easily defined as the capability of a system attached to an open-ended network to continue to deliver profitable services in the presence of accidents, attacks, or systems failures.

The terms accidents, attacks, and failures are meant to include all potentially damaging events. Attacks include intrusions, viruses, worms, Trojan horses, and denial-of-service attacks. Any system with an overly restrictive structure because of attack threats may significantly reduce its functionality while directing excessive resources to protect and monitor its assets.

Failures and accidents are risks caused by deficiencies in the system itself, or in an external item on which the system depends. Failures may be attributable to design errors, human errors, hardware failures, coding errors, or corrupted data.

Accidents are usually described as random events such as naturally occurring disasters such as floods, blizzards, earthquakes, etc.

For a system to achieve high levels of survivability, it must react to and recover from damaging events while continuing to deliver efficient and effective services. In fact, reaction and recovery must be at acceptable levels whether or not the cause of the damaging event is ascertained. Levels of survivability are central to the notion that the system is sufficiently redundant that even if significant portions of the system were damaged or destroyed, the system would continue to meet demands.

For example, a survivable financial system maintains confidentiality, integrity, and availability of critical information when nodes or communication systems are not functioning as a result of harmful events. This financial system is survivable owing to its robust design. It recovers and delivers critical services in a timely manner in the face of disaster. The hallmark of a survivable system is the identification of critical services, the essential components that support them within the system and the ability to deliver these services in spite of harmful events. These are some of the key elements of survivable systems connected to open-ended networks:

Resistance to attacks. Strategies include strong user authentication and verification, configuration management, change controls, upgrade and patching policies, audit policies, antivirus policies, e-mail policies; partitioned sub-networks; firewalls; proxy services; network address translation services; redundant data backup copies and critical services; and well-developed risk-management programs.

Recognition of system attacks. Strategies include detecting intrusion attacks and understanding the current state of the system such that evaluating the extent of damage can be accomplished effectively.

Creation of event and transactions logs. These logs must document the external and internal activities taking place on the network. Having details contained in these logs can go a long way to saving your system administration and legal bacon. Many experienced administrators strongly suggest that logs are maintained on Write Once, Read Many (WORM) media. This logging media will prevent a malicious person from deleting his or her harmful activities once done.

Recognition of intrusion attack patterns. Strategies include virus scans, systems vulnerability scans, internal integrity checking, logging, audits, system monitoring, and network monitoring.

Recovery of full or critical services is based on critical asset prioritization, recovery, and business resumption.

Development and implementation of strategies for restoring the following: compromised data, critical functionality, limiting extent of damage, maintenance or resumption of critical services, and the eventual restoration of services as time and resources allow.

Restoration of critical data and applications. Use of alternative services, use of redundant components with same or similar interface, operational procedures to restore system configuration state, containment and isolation of damage, and practiced ability to operate critical services with reduced resources.

Risk management planning requires that risk management decisions and financial balances must be made by senior managers with guidance and recommendations of technical experts in application and data domains, security, and software engineering. System survivability depends at least as much on risk management development and implementation as it does on the technical abilities of the organization's employees. Experts in security and technical issues have the role of providing senior managers with the information necessary to make informed risk management decisions.

In the design of new systems or refitting older systems, survivability imposes structures on all phases of system and software development processes. At the requirement and specification levels, critical assets must be identified. Requirements for damage resistance, recognition, recovery, and resumption should be specifically addressed. System architectures should address survivability equally with other performance properties as capacity, reliability, and maintainability. In the selection of commercial off-the-shelf software, solutions should be chosen with survivability as one of the highest priorities.

Software solution design and implementation should include techniques for containment and isolation, replication, restoration, and migration of critical assets. Survivability solutions must be integrated into both new and existing systems, avoiding systems failure due to attack, accident, or natural disasters.

Policies and Procedures

Policies, Procedures, Standards, and Politics
Modern organizations have developed into a complex waltz of human resources, data, equipment, facilities, processes, policies, and procedures. For most of us, our daily activities are not scripted and rely on policies and procedures to create an efficient and productive environment. Developing and implementing fixed policies often seems like a futile exercise, yet unless there is a formal architecture, employees end up spinning their wheels.

In the same sense that countries require laws governing the conduct of their citizens, organizations require policies to govern the conduct of their critical assets. Policy development and enforcement is neither an academic drill nor an exercise just to placate auditors. It is an essential component of sound business operations. If appropriate conduct were decided on a voluntary basis, it would be observed about as often as those who make a complete stop at stop signs without a police officer present. True, it does happen, but not often.

Policies are the methods by which business processes are documented and disseminated. Not all policies are going to apply to all business units. Consequently, policies may have general coverage areas, or coverage that is directed to specific business units and even specific functions. They provide employees with limits, alternatives, and governance. Formal policies allow senior managers to conduct their business without constant intervention, enabling employees to work within defined frameworks. They reduce the range of individual decisions and encourage managers to deal with items that are only outside that framework.

Policies assure equitable access to secure resources for authorized users. They make certain that safe, consistent, correct procedures are being employed to conduct the organization's work. Many policies are not optional; rather, they are mandated by legal and regulatory requirements while others are based on fear, uncertainty, and doubt (FUD).

Ask any system administrator how many times he or she has repeated the company's policy mandating that employees not open e-mail attachments. Before long, the system administrator has to deal with an employee who has done exactly the opposite.

There is another purpose for developing written policies and procedures to help guide the practice and performance of professionals who are faced with a combination of mundane tasks and crisis-related activities requiring an immediate decision. Professionals such as lawyers, accountants, auditors, scientists, physicians, and others are dependent on policies to assure their efforts are directed toward specific accepted practices. The logic behind policies for professionals assures that the work is done the same way, regardless of who is doing it, as the accepted manner of completing the task is consistent from professional to professional.

Under most circumstances, senior employees are expected to be promoted, leaving vacancies behind them. The generally accepted idea is that the employee accepting the position will be able to "hit the ground, running," because there will be written policies and procedures left by the employee vacating the position. Written policies and procedures refined by the incumbent ensure that the employee filling this position will be able to work effectively and efficiently at this job with a minimum of delay. These policies bridge the gap between two employees doing the same job at different times, locations, or even business divisions.

When followed, these policies guarantee the consistency of the work performed previously or in different locations. They form a core of institutional communication between the experienced, knowledgeable person who developed or enhanced the work plan, and the new person assuming the position. Policies address ways to handle routine situations, and can form a directory of operating procedures to be used in unique circumstances. As a learning tool, policy documents form a basis for describing new procedures or explaining the application of special circumstances to others.

Written policies and procedures form essential components of the organization's management system because they detail management instructions that are often the result of high-level discussions or legislated requirements. Statements of policy, especially as they relate to critical incident management, are the manifestation of executive direction in the organization's environment. As practical instruments of managers, written procedures bind the organization's philosophy to the actual work-related task.