a new release, as a collection of enhancements or bug fixes, is expected to improve overall functionality and service effectiveness. change managers and release planners should be able to anticipate any negative effects, but the communication about those issues to end users or the helpdesk usually does not happen.
at minimum, problem managers need a heads-up to give them a chance to write some sort of release note to give the helpdesk a hint as to the expected impact.
backups are susceptible to collisions during the implementations of new releases.
the release manager should ensure that the backup shedule does not overlap the change window and that all changes are evaluated for impact to the backup process.
for that matter, people have to decide how change implementations are going to be production validated.
discrete change windows usually mean that approved changes are all implemented at essentially the same time. change managers coordinate the resources and report success in the context of individual changes.
a “release manager” should be responsible to evaulate the bigger picture, a aggregate view of a current changes, understanding the relationship of one change to another, and the resource impact during the change window.
release plan approval should be the final line item in the change board agenda; we’re trying to verify that the pending changes are synchronizzed in terms of resources and backout plans.