The Release Role Cluster is where the transition between development/test and production operations occurs; it is a crucial juncture for the smooth transition of the system into production. The Release Role Cluster serves as the primary liaison between the project development team and the operations groups.

The Configuration Management service management function (SMF) is most commonly associated with this role cluster. Configuration management is responsible for the identification, recording, tracking, and reporting of key IT components or assets. The goal of configuration management is to ensure that only authorized configuration items are used in the IT environment and that all changes to configuration items are recorded and tracked through their component life cycle.

For example, suppose someone performs configuration management work related to the deployment of Microsoft Windows Server 2003 R2. Recently, the team has debated the level of detail to collect on the systems being upgraded. If the team collects too much information, it may fall behind schedule-but what if it collects too little? An operational consequence might be that the other SMFs do not have the information they need to perform correctly, so problems could occur that would have been easy to prevent. Once the risk associated with collecting too little information is recognized, the team can mitigate the risk by collecting additional detail.

The context for this risk is that someone in the Release Role Cluster is performing configuration management work related to a Microsoft Windows Server 2003 R2 deployment. That person is trying to assess the correct amount of data to collect for each part of the infrastructure affected by the deployment.

The following table shows various examples of risk components pertinent to a scenario involving the Release Role Cluster.

Table: Release Role Cluster risk components

Risk component	Statement
Root cause:	Process
Condition: The following event occurs ...	Configuration management team does not record enough detail about each configuration item (CI) during the deployment, so the information never reaches the configuration management database (CMDB).
Operations consequence: ... operations will be hurt in this manner ...	Other SMFs have insufficient information and are not able to perform their jobs effectively.
Downstream effect: ... and the business as a whole will be hurt in this manner ...	Employee productivity suffers due to undocumented anomalies in the configuration, anomalies that incident management and problem management would have detected quickly had the relevant information been in the CMDB.
Mitigation: Prior to the condition occurring, we will try to reduce the impact and/or probability by ...	Reduce both impact and probability by beginning to add detail to each of the CIs in the database.
Trigger: If the condition is imminent (but has not yet occurred), we will know because this happens...	The CMDB might indicate that everyone in one department runs a particular application, but the users complain that they can't share data, and the cause turns out to be the mixed versions in use: a problem that wasn't apparent because the configuration management team tracked only the names of installed applications, not the version numbers.
Contingency: If we are unable to prevent the condition, we will respond to the trigger in this way:	Add levels of attribute detail to the affected CIs.

In this example, the trigger may seem a bit contrived, but it illustrates the reason why this is a difficult operations problem. It is very hard to know when the information you have is no longer sufficient to do the job. The trigger listed here is just one example of how the lack of needed information might manifest itself. The team managing this risk would likely produce a more generic trigger, or would define several other specific triggers.