Home �   ITSM Glossary�  Index

Microsoft Frameworks Integrated Glossary

The Microsoft Integrated Glossary contains terms for: MSF - Microsoft Solutions Framework MOF - Microsoft Operations Framework MSPMO - Project Management Office
Mar 4, 2004

ITSM Watch Staff




reactive analysis
A top-down approach in which the organization initiates no action unless an event of some kind threatens the status quo. Then an individual or a team is given the task of forestalling change or attempting to control change as the organization drifts toward another-usually unplanned-for-state.


An illustration of how entities are related to each other.


A collection of new and/or changed configuration items that are tested and then introduced into the production IT environment.


release approved review
The first review in the MOF process cycle where the new release is reviewed to determine if it is ready for implementation in the target environment. The release approved review is typically the result of an approved modification that is being evaluated for implementation. The underlying process that supports this review is the key integration between MSF and MOF. Through this process, key attributes of a given release are assessed against standards, policies, and quality metrics as well as certain readiness factors.


release candidate
A shippable product that is suitable for final testing.


release candidate testing
Determining whether a candidate product build is suitable for release.


release management
A MOF service management function in the changing quadrant. It employs the processes of coordinating and managing the activities by which all releases to the production IT environment are planned, tested, and implemented.


release milestone
In MSF, the point at which the project team has tested and piloted the solution and is prepared to deploy it in the production environment. The release milestone is the culmination of the developing phase. Note that the release milestone is the third major milestone in Principles of Infrastructure Deployment, rather than the fourth major milestone as in other MSF courses.


release notes
One of the deliverables leading to the release milestone. They document general release information and late changes.


release readiness review
The review that completes the changing quadrant of the MOF process model. It evaluates the introduction of the release into the target environment.


release role
One of six role clusters in the MOF team model. It participates in system upgrades and ongoing revisions of software development projects. It frequently serves as the primary factor in releasing a new service offering into IT operations. The release role of the MOF team model is the point where the logistics manager role of the MSF team model intersects with MOF. This is where the handoff between development/test and production operations occurs, which is a crucial juncture for the smooth transition of the system into production.


release unit
A component or set of components packaged together as a single release unit and released into the test and production environments (for example, a full teleprocessing system, a suite, a program, a single module).


The ability of a component or IT service to perform a required function without failing, under stated conditions for a stated period of time.


request for change
A description of a proposed change, what the change entails, and which configuration item(s) it involves. On the basis of the proposal, the impacts are assessed and, if approved, the change is scheduled for implementation.


A condition necessary for the proper definition of the solution.


The identification and gathering of input. In conceptual design, the identification and gathering of business needs and user requirements. In physical design, the identification and gathering of physical constraints of the infrastructure and physical requirements of the application. Logical design has no research step because the input is the scenarios from conceptual design.


research baseline
The point in research where the project team is in consensus that the research deliverables are sufficient in breadth and depth to continue to the next step in conceptual design or physical design.


A provision in the project plan to mitigate cost and/or schedule risk. Often used with a modifier (management reserve, contingency reserve, for example) to provide further detail on what types of risk are to be mitigated.


The capacity of an IT service to continue to provide a required function in the event that a portion of the underlying infrastructure suffers a failure.


An action that will resolve an incident. This may be a workaround.


resolution owner
The person to whom an incident is assigned. This person owns responsibility for resolving the service event.


The specific groups or individuals who complete the project work and their associated financial resources (project budget). This also includes specific equipment, such as computers and computer labs. Resources compose one side of the trade-off triangle with schedule and features being the other two.


response time
The time between the start (sending a request or command) and the end (obtaining the result) of an online transaction.


responsibility matrix
A document that explicitly calls out the individual team members who are tasked with executing, reviewing, and approving work packages within a project.


retiring risk
Eliminating risk from the risk plan. One approach to retiring a risk is to archive the risk and its management plan (successful or otherwise) into a repository for use and reference by future projects. Conversely, risks can be simply removed from the risk management process after they have occurred or been resolved.


See request for change.


An uncertain event or condition that, if it occurs, may have a positive or negative effect on a projects objectives. An inevitable known event is not a risk. Losses are relative: Failure to achieve maximum benefit may be considered a loss. Opportunities are positive risks: the possibility of achieving an unintended gain.


risk acceptance
A technique of the risk response planning process. It indicates that the project team has decided not to change the project plan to deal with a risk, or is unable to identify any other suitable response strategy.


risk assessment
Determining risk probability (the likelihood that a risk will occur) and risk impact (the severity of loss if the risk does occur).


risk assessment document
A consolidation of the teams risk management output in a single document.


risk assessment drafted interim milestone
An interim milestone of the envisioning phase, leading to the vision/scope approved milestone.


risk avoidance
Performing a task to eliminate the risk posed by another task. Risk avoidance often involves changing the project plan to eliminate the risk or to protect the project objectives from its impact. It is one of three risk mitigation strategies; see also risk reduction and risk transference.


risk condition
In the MOF risk model, a description of a possible future event that could result in a loss.


risk contingency
A predesigned plan or process for dealing with a realized risk event.


risk event
A discrete occurrence that may affect the project for better or worse.


risk exposure
A quantification of the overall threat constituted by a risk. It is calculated by multiplying probability times impact.


risk impact
The severity or magnitude of loss if a risk occurs.


risk management
A proactive, formalized process for decision-making and actions to continuously assess what can go wrong, determine what risks are important to address, and implement strategies to deal with those risks.


risk mitigation
Reducing the probability and/or impact of a risk to an acceptable level.


risk planning
Anticipating risks with consequences that an organization cannot accept. Risk planning involves examining how much is known about the risk, and if the organization can live with the consequences, or avoid the risk entirely. The plan can include a way to reduce the likelihood the risk will occur, and determine ways to reduce the impact should the risk occur.


risk plans
Actions to address how to prevent and minimize risk and what to do if it occurs.


risk probability
The likelihood that a risk will occur.


risk reduction
Dealing with risk by minimizing the likelihood the risk will occur. One of three risk mitigation strategies; see also risk transference and risk avoidance.


risk response planning
Developing procedures and techniques to enhance opportunities and reduce threats to the projects objectives. The tools include avoidance, mitigation, transference, and acceptance.


risk sources
Where risk can originate.


risk statement
A condition-consequence statement that helps to clearly articulate risk. In the MOF risk model, the combination of risk elements recognized in the identification step: source of risk, mode of failure, condition, operations consequence, business consequence.


risk transference
Shifting the impact of a risk to a third party together with ownership of the response. One of three risk mitigation strategies; see also risk reduction and risk avoidance.


risk-driven scheduling
A principle of good scheduling that prioritizes tasks based on the level of risk involved and prioritizes features based on their importance to key stakeholders.


A subdivision of a role cluster. It performs specific functions within an IT organization. Depending upon the intensity of labor involved and the size of the organization, one person can perform multiple roles within an organization, or multiple persons can perform a single role.


role cluster
Defines six general categories of activities and processes. The processes within a role cluster all support the same quality goal. It is important to recognize that the role clusters are groups of activities that share a common goal. They are not job descriptions, and they do not imply any kind of organizational chart.


A series of patches joined consecutively.