Integrated Glossary For

• Microsoft Solutions Framework
• Microsoft Operations Framework
• Project Management Office

A B C D E F-G H-I J-K L-M N-O P-Q R S T U-Z

Credits

Ralph Barton, director, Microsoft Frameworks

Laurie Dunham, editor, Microsoft Frameworks

Christian Jensen, program manager, Worldwide PMO

Michael Lubrecht, technical writer, Microsoft Frameworks

Enzo Paschino, program manager, Microsoft Frameworks-MSF

Michael Peila, program manager, Worldwide PMO

Allison Robin, group program manager, Microsoft Frameworks-MSF

^©2001 Microsoft Corporation. All rights reserved

The information contained in this document represents the current view of Microsoft Corporation on the issues discussed as of the date of publication. Because Microsoft must respond to changing market conditions, it should not be interpreted to be a commitment on the part of Microsoft, and Microsoft cannot guarantee the accuracy of any information presented after the date of publication

 

This document is for informational purposes only. MICROSOFT MAKES NO WARRANTIES, EXPRESS OR IMPLIED, IN THIS DOCUMENT

 

Microsoft is a registered trademark of Microsoft in the United States and/or other countries

Integrated Glossary For

• Microsoft Solutions Framework
• Microsoft Operations Framework
• Project Management Office

A B C D E F-G H-I J-K L-M N-O P-Q R S T U-Z

Credits

Ralph Barton, director, Microsoft Frameworks

Laurie Dunham, editor, Microsoft Frameworks

Christian Jensen, program manager, Worldwide PMO

Michael Lubrecht, technical writer, Microsoft Frameworks

Enzo Paschino, program manager, Microsoft Frameworks-MSF

Michael Peila, program manager, Worldwide PMO

Allison Robin, group program manager, Microsoft Frameworks-MSF

^©2001 Microsoft Corporation. All rights reserved

The information contained in this document represents the current view of Microsoft Corporation on the issues discussed as of the date of publication. Because Microsoft must respond to changing market conditions, it should not be interpreted to be a commitment on the part of Microsoft, and Microsoft cannot guarantee the accuracy of any information presented after the date of publication

 

This document is for informational purposes only. MICROSOFT MAKES NO WARRANTIES, EXPRESS OR IMPLIED, IN THIS DOCUMENT

 

Microsoft is a registered trademark of Microsoft in the United States and/or other countries

Integrated Glossary For

• Microsoft Solutions Framework
• Microsoft Operations Framework
• Project Management Office

A B C D E F-G H-I J-K L-M N-O P-Q R S T U-Z

Credits

Ralph Barton, director, Microsoft Frameworks

Laurie Dunham, editor, Microsoft Frameworks

Christian Jensen, program manager, Worldwide PMO

Michael Lubrecht, technical writer, Microsoft Frameworks

Enzo Paschino, program manager, Microsoft Frameworks-MSF

Michael Peila, program manager, Worldwide PMO

Allison Robin, group program manager, Microsoft Frameworks-MSF

^©2001 Microsoft Corporation. All rights reserved

The information contained in this document represents the current view of Microsoft Corporation on the issues discussed as of the date of publication. Because Microsoft must respond to changing market conditions, it should not be interpreted to be a commitment on the part of Microsoft, and Microsoft cannot guarantee the accuracy of any information presented after the date of publication

 

This document is for informational purposes only. MICROSOFT MAKES NO WARRANTIES, EXPRESS OR IMPLIED, IN THIS DOCUMENT

 

Microsoft is a registered trademark of Microsoft in the United States and/or other countries

A

accept
One of three key concepts in the Microsoft approach to managing project trade-offs. It refers to accepting costs and resources as a time-and-materials strategy. See also optimize and constrain.

acceptance test
A release readiness test for validating whether or not the technical solution satisfies the usability and operability requirements specified in the functional specification.

access control
Access and privileges granted to users so that they can perform certain authorized functions on a system.

activity
An element of work performed during the course of a project. An activity normally has an expected duration, expected costs, and expected resource requirements. Activities can be subdivided into tasks.

alpha testing
Testing of an early, feature-complete product by internal resources.

analysis
In conceptual design, the breaking down and examination of business and user information into use cases and scenarios documenting work processes. In logical design, the identification of services, objects, attributes, and relationships from scenarios. In physical design, the examination of physical constraints of the infrastructure and the physical requirements of the application to select candidate implementation technologies and to draft a preliminary deployment model.

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

analyzing risk
Converting risk data into risk decision-making information.

application
The information system component that is composed of the application software and its accompanying datasets and thus represents the functionality of the information system.

application perspective
Viewing the enterprise architecture from the point of view of the applications used to support business processes. The application perspective is represented by the A in the BAIT acronym.

architecture
The manner in which components are organized and integrated.

assign
The action of delegating a service event to a service group or specialist. The person accepting the assignment becomes the resolution owner.

assumption
Factors that, for planning purposes, are considered to be true, real, or certain. Assumptions affect all aspects of project planning, and are part of the progressive elaboration of the project.

attribute
A property of an entity.

authentication
The method by which users prove to the system that they are who they claim to be. Authentication is used in passwords, smart cards, biometrics, and so forth.

availability
The ability of a component or service to perform its required function at a stated instant or over a stated period of time. It is usually expressed as the availability ratiothat is, the proportion of time that the service is actually available for use by the customers within the agreed service hours.

availability management
A MOF service management function in the optimizing quadrant. It employs the process of describing, managing, directing, and proactively maintaining the availability of information and services at a reasonable cost and in accordance with agreed service delivery levels.

Note The IT Infrastructure Library (ITIL) also uses this term to connote a similar meaning and process. MOF uses the underlying ITIL characterization as a foundation and then extends it by incorporating partner experience and Microsoft-specific features. For the specific ITIL definition, please consult the ITIL glossary, located at the time of publication at the ITIL Web site.

availability plan
Compiled and/or refined within the availability management process. The availability plan sets out what availability is necessary in the long term. The plan contains a number of set scenarios with respect to future availability requirements.

B

baseline
A snapshot of a project, specification, schedule, or other entity at a set point in time. A baseline consists of the original approved plan, plus or minus approved scope changes; it is used as a point of reference to measure progress. It is usually used with a modifier (a cost baseline or schedule baseline, for example). It may document an IT architecture and underlying dependencies at a given point in time, or may be used to document the current status of a development or other project.

For availability management in an operations setting, the term also is used to identify an agreed set of availability definitions and targets for an IT service. Such definitions and targets normally would have been proved through modeling and, once defined, would be used as key availability design and reporting criteria.

best practices
An optimal set of procedures and functional principles, typically derived from previous experience. When followed, best practices generally result in improved results, enhanced work flow, and other benefits in completing project activities. However, following best practices does not guarantee satisfactory results from a particular project.

beta testing
Testing of a stabilized product by external end users.

bottom-up estimating
A principle of good scheduling. It means having those who do the work estimate the effort, rolling up task-level estimates, and recognizing that experience is the best estimating technique.

breakdown
An incidental, short-term interruption of automated information services.

buffer
Time added to a project schedule to help the project team accommodate unexpected problems and changes. Synonymous with PMI Body of Knowledge reserve, which may be applied to either schedule or cost. A buffer is typically created by setting an internal deadline that occurs sooner than the external one that has been publicized.

bug
Any issue arising from the use of the product.

bug classification
Making bugs actionable by determining severity, which measures its impact on the product, and by priority, which measures how important it is to fix the bug.

bug convergence
The point at which the rate of fixed bugs exceeds the rate of found bugs.

bug resolution
Addressing a bug in some fashion.

bug triaging
Evaluating and prioritizing bugs to determine their appropriate resolution.

build
The process involved in taking one or more input configuration items and processing them (building them) to create one or more output configuration itemsfor example, software compile and load.

build strategy
One of the four strategies designed to extricate an organization from the IT abyss. The build strategy endeavors to define a long-term infrastructure target that increases flexibility while maintaining cost levels.

business consequence
In the MOF risk model, a description of the way in which the operational consequence would affect the business as a whole.

business function
The highest level of what business processes are intended to accomplish. For example, financial management is a business function; accounts receivable is a related business process. See also business process.

business need
A desire of the project customer that focuses on the business problem; its fulfillment is strategic to organization goals. See also user requirement.

business perspective
An IT project from the point of view of the associated business processes. Most commonly, this is the view taken by the project customer, sponsor, and/or product manager.

business process
A process is a structured, measured set of activities designed to produce a specified output for a particular customer or market. It implies a strong emphasis on how work is done within an organization. (Davenport, Harvard Business Review, 1993). Business processes have customers and in most cases (but not always) cross organizational boundaries.

business service
A unit of application logic that controls the sequencing and enforcing of business rules.

C

CAB
See change advisory board.

candidate components
Preliminary or proposed, before being baselined or finalized, as in candidate components, services, objects, or technologies.

candidate project list
Compiled during the planning phase of the enterprise architecture, when determining which IT projects to undertake requires complex trade-offs in uncertain situations. The candidate project list helps IT planners to balance business needs and goals against technological possibilities and risks and prioritize projects for a versioned release of the enterprise architecture.

capacity management
A MOF service management function in the optimizing quadrant. The process of describing, managing, directing, and proactively maintaining the capacity of information and supplied services in accordance with agreed quality performance levels and processing capacity at reasonable cost.

Note The IT Infrastructure Library (ITIL) also uses this term to connote a similar meaning and process. MOF uses the underlying ITIL characterization as a foundation and then extends it by incorporating partner experience and Microsoft-specific features. For the specific ITIL definition, please consult the ITIL glossary, located at the time of publication at the ITIL Web site.

capacity planning
The process of forecasting system and environment utilization and workloads and then developing plans to ensure that the system and environment will be able to support anticipated performance demands.

category
Classification of a group of configuration items, change documents, or problems.

CCTA
See Central Computer and Telecommunications Agency.

Central Computer and Telecommunications Agency
A United Kingdom government executive agency chartered with development of best practice advice and guidance on the use of information technology in service management and operations.

change
The addition, modification, or removal of approved, supported, or baselined hardware, network, software, application, environment, system, desktop build, or associated documentation.

change advisory board
A group of people representing service delivery and support functions who are responsible for assessing, planning, and authorizing changes to the IT environment. This board is a key component of a formal change management process and is likely to be made up of representatives from all areas within IT and representatives from business units.

change control
Principles and processes that facilitate the management of change without compromising the quality or integrity of an IT project or solution, through structured procedures for submitting, approving, implementing, and reviewing change requests.

change history
Auditable information records that describe what was done, when it was done, by whom, and why.

change log
A log of requests for change raised during a project, showing information on each change, its evaluation, what decisions have been made, and its current status, such as raised, reviewed, approved, implemented, or closed.

change management
A MOF service management function in the changing quadrant. It employs the practice of administering changes with the help of tested methods and techniques in order to avoid new errors and minimize the impact, if any, on the agreed IT service levels in accordance with service level agreements.

change record
A record containing details of which configuration items are affected by an authorized change (planned or implemented), and how.

changing quadrant
The first quadrant in the MOF process model where a new release is prepared and then released into production. The changing quadrant starts with a release approved review to determine if the release is ready for implementation in the target environment and culminates in the release readiness review in which the release is assessed for effective implementation.

Examples of changing quadrant activities include:

• Verifying the readiness of the release.
• Verifying the release functionality in the physical environment.
• Verifying the preparedness of the operations staff and processes.
• Creating and following through on the installation plan.
• Creating a contingency plan.
• Analyzing potential impacts on other systems.

CI
See configuration item.

CI level
The lowest level at which identifiable items can still be uniquely distinguished.

classification
Expressing the value of items by placing them in a certain order on the basis of category, impact, and urgency. Also, the process of formally grouping configuration items by type (for example, software, hardware, documentation, environment, application). Classification can be used to support decisions based on priorities.

client manager
Synonym for MSF product manager within an engagement.

client/server
The combination of software, hardware, and network components in which one or more clients (computers) request services from one or more servers (computers) and through which the computer network functions for the user as one computer.

closure
When the customer is satisfied that an incident has been resolved.

CMDB
See configuration management database.

code review
Assessing code to improve its quality and the capabilities of the development team.

cohesion
The relationship among different internal elements of an object.

communications plan
A formal plan, usually a document, for how a project team will handle communications within the team and between the team and external entities.

component
A unit of application logic that delivers a set of specified services that can be accessed only through a published interface or interface contract.

component interface
The predefined part of a component that allows a component user to access component functions exposed at that predefined part.

Component Object Model (COM)
A language-independent, system-level object model that provides a standard way for components and applications to interoperate.

component topology
A component distribution map that indicates the location of components and their services in relation to the network topology.

conceptual design
A major stage in the design process, through which the project team translates the business requirements into a common language to be shared by users and developers, and describes the feature set and/or usage scenarios that the solution must encompass.

conceptual design baseline
The culmination of the research, analysis, and optimization steps of conceptual design.

confidentiality
A component of encryption. Confidentiality mechanisms ensure that only authorized people can see data stored on or traveling across the network.

configuration baseline
Configuration of a product or system established at a specific point in time, which captures both the structure and details of that product or system and enables that product or system to be rebuilt later.

configuration control
Activities that control changes to configuration items. They include evaluation, coordination, approval, or rejection of changes.

configuration documentation
Documents that define requirements, system design, build, production, and verification for a configuration item.

configuration item
A component of the IT environment (or infrastructure) that may impact the service level agreement if changed. A configuration item (CI) can be either a physical or a logical object and can be composed of other configuration items. CIs may vary widely in complexity, size, and type, from an entire system (including all hardware, software, and documentation) to a single software module or a minor hardware component.

configuration management
A MOF service management function in the changing quadrant. It employs the process of identifying and defining configuration items in a system, recording and reporting the status of configuration items and requests for change, and verifying the completeness and correctness of configuration items.

configuration management database
A database that contains all relevant details of each configuration item (CI) and details of the important relationships between CIs. The database can include ID code, copy and serial number, category, status, version, model, location, responsibility, historical information about the item, and so on. The level of detail employed in this depends either on the aims or on the degree to which information is to be available.

configuration management plan
A document setting out the organization and procedures for the configuration management of a specific product, project, system, support group, or service.

configuration structure
A hierarchy of all the configuration items that make up a configuration.

consensus
When everyone on the team supports the teams decision without feeling they are compromising any important needs or values.

constrain
One of three key concepts in the Microsoft approach to managing project trade offs. In the trade-off matrix, constraining costs and resources requires a not-to-exceed strategy.

constraint
A nonfunctional requirement that places a limit or dictates a limited range of possibilities. For example, an infrastructure constraint.

context
An information source for scenarios. It provides background or a frame of reference.

contingency plan
A plan for addressing recognized risks that may arise during the course of a project. For development projects, the plan may, for instance, reallocate resources or drop features to react to an unanticipated change in schedule. For operations, a contingency plan provides details for an alternative system or manner of conducting business during an IT crisis.

continuity
Uninterrupted consistency and persistence of processes and the certainty that the processes will continue in operation. See also service continuity management.

continuum
A coherent whole characterized as a sequence or progression of elements. Hence, the design continuum describes a progression of design elements: in conceptual design, the scenarios; in logical design, the services and objects, high-level user interface, and logical database; in physical design, the components, user interface, and physical database.

control
The process of comparing actual performance with planned performance, analyzing variances, evaluating possible alternatives, and taking appropriate corrective action as needed.

control strategy
One of the four strategies designed to extricate an organization from the IT abyss. Organizations in the IT abyss attempt to get all IT under control by setting funding targets for future application and infrastructure spending.

controlling risk
Addressing the results of risk tracking and the process as a whole.

core components
Components of the solution that are deployed at a central location, rather than at individual sites.

core team organized interim milestone
The point during the envisioning phase at which the core project team has been formed and is ready to move the project forward.

core technology deployed interim milestone
The point during the deploying phase at which the team has deployed the selected technology at the central, or core, location(s).

countermeasure
A technological or procedural response to address a single point of failure or other threat to the availability of an IT service. Two examples are the use of redundant power supplies and the implementation of a proven database backup procedure.

coupling
The relationship of an object to other objects.

coverage testing
Used primarily during the developing phase, it attempts to thoroughly test every feature of the product and the code base of the product.

critical path
The series of activities that determines the duration of a project. It is the longest continuous chain of linked activities through a project schedule; a chain of activities to which no slack or float time is assigned. Delays in any of the linked activities will delay the entire project.

critical success factors
Activities, tasks, technology, funding, and milestone requirements that must be accomplished before an organization can reach its long-term goals and objectives. Similar to dependencies.

current state assessment
An assessment of the actual present-day status of the organization's business processes, applications, information stores, and technological support made during the planning phase of the enterprise architecture.

customer
The recipient of a service (or product).

customer-focused mindset
A best practice or principle of a successful team. It means committing to understanding and solving the business problem, focusing on the alignment of business and technology, and involving the customer throughout the process.

D

daily build
Building the product in an executable form on a daily basis.

data availability
In security, the ability of authorized users to access the data they need, when they need it.

data confidentiality
In security, the ability to restrict data accessibility.

data integrity
In security, ensuring that data presented to authorized users is accurate and not improperly modified.

data service
A unit of application logic that provides the lowest visible level of detail used to manipulate data.

data topology
A data distribution map that indicates data store locations in relation to the network topology.

decomposing work
Breaking the scope of work for a complex project into more manageable parts. See also work breakdown structure.

definitive software library
A secure software library where all versions of software configuration items that the change advisory board has accepted are held in their definitive, quality-controlled form (by necessity this logical library may have to occupy one or more physical locations).

deliverable
A physical artifact created by the team, usually associated with reaching an interim or major milestone. It can be the only product or one of several products associated with that milestone. Deliverables may be internal for use by the project team, or more narrowly, may be delivered to and subject to approval by an external customer or sponsor.

delivery support
See service delivery.

deploying phase
The fourth stage of the process model, during which the project team deploys the tested solution to all planned sites. The deploying phase culminates in the deployment complete milestone.

deployment complete milestone
The point at which the deployed solution is providing the expected business value to the customer and the customer has signed off on the project. The deployment complete milestone is the culmination of the deploying phase.

design
The process of shaping the future by applying new capabilities to the current reality.

design goals
Goals set during the envisioning phase that outline, at a high level, the process of designing a software solution for a business problem.

design, conceptual
The goal in conceptual design is to identify business needs and to understand what users do and what they require. It is not the approach taken or the technologies used to build a solution. Conceptual design is analogous to the rough sketches and scenarios created when designing a house. These are easily understood models jointly created by the customer and the architect.

design, logical
Logical design organizes the details of the application that the team builds to fulfill business needs and user requirements. Logical design is created by the architect's team and lays out the structure of the solution and the communication paths among elements. Logical design corresponds to a floor plan and elevation, where elements such as spatial relationships are organized.

design, physical
Physical design addresses the technology that will be used by the end user. The goal is to apply real-world technology constraints to the logical design, such as implementation and performance considerations. Physical design corresponds to a contractor's blueprints for the physical elements of a structure-wiring, plumbing, heating, and ventilation. The contractor's plans add detail to the architect's plans and reflect real-world construction constraints.

desired architecture
The future envisioned state of the enterprise architecture.

developing phase
Within Microsoft Solutions Framework, the third of four phases within the MSF process model. Depending upon the nature of the project, all code and documentation development, solution testing and pilots, and installation script and process creation is accomplished during this phase. The developing phase is bounded by the project plan approved (input) and release (output) milestones.

development environment set up interim milestone
The point during the planning phase at which the project team has prepared the environment in which development will take place.

development role
One of six team roles, it focuses on coding to the functional specification and on meeting customer expectations. It participates in design, focusing on physical design; estimates time and effort to complete each feature; and serves the team as a technology consultant.

digital nervous system
An obsolete Microsoft marketing term, its use is not advised. A digital nervous system is analogous to a biological nervous system in that it provides an organization with the information it needs. A digital nervous system supports basic business operations, prepares an organization to react to both planned and unplanned events, and helps to gain and/or maintain a competitive advantage.

direct costs
Costs that can be traced to a particular activity or organizational department.

directory services administration
A MOF service management function in the operating quadrant. It provides the day-to-day operations, maintenance, and support of the enterprise directory.

disaster recovery
Similar to contingency plan. However, it traditionally refers to a recovery from a natural disaster. The contingency plan may anticipate and serve the purpose of the disaster recovery plan if it is broad in scope.

distributed COM (DCOM)
Extends COM across machine boundaries, providing remote invocation of COM components in a location-transparent manner.

downtime
The unavailability of one or more configuration items (CIs). It is measured from the start of the incident to the restoration of an IT service.

DSL
See definitive software library.

E

EA plan approved milestone
The second of four major milestones, representing the culmination of the planning phase, indicating the project team, customer, and key project stakeholders agree on what will be delivered and when.

EA release milestone
The last of four major milestones, representing the culmination of the stabilizing phase, at which point responsibility for the product shifts to the operations team.

EA scope complete milestone
The third of four major milestones, representing the culmination of the developing phase, indicating all features have been completed and the product is ready for external testing and stabilization.

EA vision approved milestone
The first of four major milestones, representing the culmination of the envisioning phase, indicating team and customer agreement on project direction.

effort-driven task
A task whose duration will decrease if more resources are assigned to it (for example, more people are working on it).

element
One of the parts, substances, or principles that make up a compound or complex whole.

end user
The person who actually uses an application, as opposed to the customer, who pays for it.

endgame
The process of driving the product to a releasable state.

enterprise
A large company or corporation.

enterprise architecture
A structure that describes:

• The organization's business activities.
• The applications and automation that support those business activities.
• The information necessary to carry out those business activities.
• The technologies and infrastructure used to deliver the applications and information.

The enterprise architecture is the blueprint for integrating these key business processes and technologies.

enterprise architecture planning
The process of working from a current state to an envisioned future state of the enterprise architecture. The process anticipates and plans for the obstacles that impede progress toward initiation of projects that will move the organization forward.

enterprise architecture process
A rational way to make decisions that lead to action rather than reporting. Once this rational process is in place, the team can focus on project selection and prioritization, and plan while building rather than plan first and then build.

enterprise strategy consultant
A Microsoft Consulting Services consultant assigned to strategic consultation duties for an enterprise-caliber client.

entity
A unit of application that represents information.

environment
A collection of hardware, software, network communications, and procedures that work together to provide a discrete type of computer service. There may be one or more environments on a physical platform-for example, test and production. An environment has unique features and characteristics that dictate how they are administered in similar, yet diverse, manners.

envisioning phase
The first of four distinct phases of the MSF process model. It is the period during which the team and the customer define the business requirements and the overall goals of the project. It culminates in the vision/scope approved milestone, indicating team and customer agreement on project direction.

error control
Correcting and/or minimizing the negative consequences of existing errors in the IT infrastructure to provide the agreed service level.

error handling
The design of a system to trap all types of processing errors, with proper notification of the error condition to the end user and system administrator, and ending in a proper way that allows the system to recover state and clean up invalid data.

error (known)
An undesired situation in the IT infrastructure in which a particular configuration item is identified as the cause of a (potential) decline in the agreed service level. In general, an error is the root cause of a problem.

error management
See error control.

ESC
See enterprise strategy consultant.

escalation
The process of informing increasing levels of management when a service level is not met. This is defined according to service level management rules established in the service level agreement.

execute strategy
One of the four strategies designed to extricate an organization from the IT abyss. Organizations eager to leave the IT abyss focus on execution, in both operations and new development to reach competitive status as soon as possible.

exposure
In the MOF and MSF risk models, the result of multiplying the probability of risk by the impact. For example, if the probability is 20 percent and the impact is 3, then the exposure is 0.6.

extend strategy
One of the four strategies designed to extricate an organization from the IT abyss. A strategy for organizations that aspire to lead and must focus their energies on identifying and testing new opportunities while continuing to drive performance.

F

facilities management
The process involved in the management of physical structures that support the operations environment. It includes property, utilities, power backup, property maintenance, and monitoring. This is often performed by external specialists.

fast tracking
Compressing the project schedule by overlapping activities that would normally be done in sequence, like design and construction.

feature team
In large projects, a multidisciplinary subteam that is responsible for a particular product feature set.

features
One of the three sides of the trade off triangle, the other two being resources and schedule, it refers to the product and its quality.

financial management
A MOF service management function in the optimizing quadrant. It provides the sound management of monetary resources in order to support organizational goals. Financial management may include cost accounting, budgeting, project investment appraisals, and in some organizations, cost recovery.

fixed ship-date mindset
A principle of good scheduling. It means treating a project's projected ship date as unchangeable and committing to a ship date because it's realistic.

forecasting
Projecting future trends through the use of historical data. For example, the forecasting of network utilization trends enables the network manager to anticipate when user performance demands are likely to reach or exceed current levels of computing capacity.

four perspectives
Together, they make up the one enterprise architecture. The MSF process model uses the acronym BAIT to refer to the four perspectives: business, applications, information, and technology.

full release
A release that replaces all components of a release unit, regardless of whether or not they have changed since the last version of the software.

function
Description of the performance of a feature, product, or component.

function team
In large projects, a multidisciplinary subteam that is responsible for a particular functional role, like product management or user education.

functional management
A process responsible for the maintenance of the functionality of an information system that is central to its use.

functional specification
A deliverable that describes a solution, product feature set, or other final project deliverable in explicit detail.

functional specification drafted interim milestone
The point during the planning phase at which the project team has drafted and baselined the functional specification.

gap analysis
A study that is conducted to discover the gap between the current state and the desired state of the enterprise architecture.

Note Also an analysis of readiness data collected to assess the gap between an organization's current state of readiness to deploy a solution compared to the recommended state of readiness.

goals
What the business intends to accomplish or attain.

golden release
Accepting a release candidate as the final release of the product.

guidelines
A recommended course of action to achieve particular ends

.

H - I

HIP
High-impact project, necessitating review by an opportunity review board at the local, regional, or global level before a response is made to pursue an opportunity.

identification
Any mechanism used to uniquely identify a user or a set of privileges on a system. Identification can be likened to a key. Access control can be likened to a lock. Both the key and lock must match in order to gain access.

identification process
The iterative procedure of discovering services, objects, attributes, and relationships from scenarios. Also known as noun-verb analysis.

identifying risk
Discovering and recognizing potential problems with the project.

impact
In the MOF and MSF risk models, the degree of loss that the business consequence would cause. This is measured on a numeric scale: the higher the impact, the higher the number. This is closely related to the ITIL^® meaning of this term: the business criticality of an incident.

impact analysis
A quantitative research method in which a study is conducted into the effects that an error or change implementation may have on the other parts of the configuration and the subsequent consequences for the service level, taking into account the risks of such an error or change implementation and the potential severity.

implementation
The process of executing the production release and stabilization of an IT change that encompasses one or more configuration items (CIs).

implementation scenario
A short overview of the organizational aspects and scheduling relating to the execution of installation work. The scenario involves a step-by-step plan that includes the various actions and tests, persons responsible, and the duration of the actions to be carried out.

implementation technologies
The programming language, application programming interface (API), and component technology.

incident
Any event that deviates from the (expected) standard operation of a system. Such an event influences the system, even though the influence may be small or even invisible to the user of the system. Every incident is assigned to a problem or a known error.

incident control
See incident management.

incident management
A MOF service management function in the supporting quadrant. It is the function that controls and manages the life cycle of all incidents from occurrence to closure.

information
What the organization needs to know to run its business processes and operations. It includes standard data models, data management policies, and descriptions of the patterns of information consumption and production in the organization.

information perspective
The enterprise architecture from the point of view of the information that the organization has stored for its use.

information stores
A database or other kind of repository where information in all of its forms is kept.

information system
The entirety of the hardware with accompanying basic software and applications software, datasets, persons, and the procedures according to which they work, for gaining knowledge of and/or directing or supporting business processes.

information systems management
The totality of the activities involved in maintaining information systems, the components from which they are constructed, and the accompanying data processing and information processes in accordance with the requirements and preconditions set for their use.

information technology
The architecture, structures, and processes that are the core of an information systems strategy. The entirety of those components (for example, computers, networks, and information systems) with which information provision is realized.

Information Technology Infrastructure Library (ITIL^®)
A widely recognized collection of IT service management best practices and processes for the management of IT services.

information technology life cycle
The process of planning, building, and managing information technology.

infrastructure
The total set of resources necessary to support the enterprise computing environment. These resources consist of the technologies and standards, the operational processes, and the people and organizational resources.

infrastructure deployment
The process of converting functional specifications, training, and plans into a complete, deployment-ready solution.

infrastructure role
One of six roles in the MOF team model. It is responsible for the evolving enterprise architecture and ensures that plans are in place to meet the new and changing requirements of running the business from a networking, telecommunications, hardware, and software perspective. Additionally, the infrastructure role includes responsibility for shared/common data management such as customer and product data, space, and storage planning (data centers, field and remote offices, test labs, development labs, and so forth), and the tools necessary to support the infrastructure.

initial candidate project list
See candidate project list.

integration
The degree to which consecutive types of actions or work are carried out by an organizational unit.

interface
Physical or functional interaction at the boundary between configuration items.

interface contract
The specification of how a component will allow a component user access to specific, predefined services.

internal release
The process of getting the product to a known state and incrementally building upon it.

IT
See information technology.

IT abyss
A model used to describe the gap that stands between an enterprise and its ability to maximize value from its IT investments. The IT abyss is the most prominent feature of the IT landscape and represents the present state of an organization on the IT landscape chart, situated between past and future states. An organizations position relative to the abyss on the IT landscape chart determines which of four strategies it should adopt to help it emerge from or cross the IT abyss.

IT assets
Three main areas: application portfolio, technology infrastructure, and IT organization.

IT diagnostic areas
Enterprise architecture planners can evaluate an organization's current IT environment in three key diagnostic areas: IT assets (what the organization has), IT management processes (how things are done), and IT/business performance (current performance).

IT infrastructure
The sum of an organization's IT-related hardware, software, data communication facilities, procedures, automation tools, documentation, and people.

IT Infrastructure Library
See Information Technology Infrastructure Library.

IT inventory
A quick, high-level inventory across the enterprise, looking only at the details of the areas that the vision identifies as being of interest. The IT inventory of an organization can be divided into three categories:

• Applications. Systems made up of executable software.
• Information. Computerized data stores containing information, often accessed through a database management system.
• Technology. Hardware, software, and electronic networks that support applications and data stores.

For analysis purposes, the inventory also includes items that are planned or under development.

IT landscape
A graphical representation of an organization's IT assets evaluation depicting past, present, and future performance. The IT abyss model describes varying levels of the IT landscape. Factors contributing to the IT abyss include IT assets, IT management processes, and IT business performance.

IT life cycle
The process of planning, building, and managing information technology.

IT management processes
Typically, an examination of five main areas in evaluating IT management processes: strategic direction-setting, technical direction-setting, funding, execution, and review.

IT service
Any hardware, software, or facility (or combination thereof) that is provided to business customers for their use and is managed by IT.

IT service management
An approach that IT organizations can utilize to plan, develop, deliver, and maintain quality IT services that are customer focused and process driven, and that meet both cost and performance targets as defined by the service level agreement or operating level agreement.

IT service provider
Any organizational units, whether internal or external, that deliver and support IT services to a customer.

IT/business performance
Has two main areas: spending and results.

iteration
One execution of a sequence of operations in a process or cycle.

ITIL^®
See Information Technology Infrastructure Library.

J - K

job scheduling
A MOF service management function in the operating quadrant. It involves the continuous organization of jobs and processes into the most efficient sequence, maximizing system throughput and utilization to meet service level agreement (SLA) requirements.

key performance indicators
Significant metrics that indicate the level of functionality and viability of a component.

kickoff meeting
A meeting at which the sales side of the business hands over ownership of the project to the delivery side of business. It is important that this be as smooth as possible and hence it is crucial that both teams are well represented at this meeting.

KM
Knowledge management. An enterprise endeavor to consciously and comprehensively gather, organize, share, and analyze its IT system knowledge to create a complete information resource. Due to the complexity and enterprise knowledge depth that most IT organizations possess, this process is most often automated by using knowledge management (KM) tools.

Most often, KM is used to facilitate the functions that service desk and product support services provide. Knowledge repositories, usually large, indexed, and searchable databases, enable quick retrieval of the relevant possible problems and known errors that may be the root cause of a customer's incident.

The KM system collects the most common problems, questions, and general tips and tricks regarding the organization's supported products, systems, and technologies. It greatly reduces the amount of time required to identify, troubleshoot, and resolve reported incidents and problems by collating the efforts of many support personnel into a single source, enabling each support person to benefit from the knowledge of the others.

The infrastructure role frequently owns the specification of these kinds of automation tools as a core service to other operations management groups.

known error
A condition in the IT environment in which a certain configuration item(s) has been identified as the cause of a (potential) degradation or disruption in the agreed service level.

L - M

lag time
The interval between the end of one project activity and the beginning of a dependent project activity.

lead time
The interval between the start of one project activity and the start of a dependent, yet concurrent activity.

life cycle
The phases an IT component goes through from the time it is conceived to the time it is retired from service. The life cycle represents an approval process for configuration items, problem reports, and change documents.

line-of-business application
A software application that is critical to the functioning of the enterprise.

living documents
Documents that are regularly updated and referred to.

LOB
See line-of-business application.

logical design
A major activity in the design process, in which the team deconstructs scenarios into basic elements and makes high-level decisions about the interaction and integration of IT components, prior to making specific technology decisions.

logical relationship
A dependency between two project activities, or between a project activity and a milestone. The four possible types of logical relationships are:

• Finish-to-start. The initiation of work of the successor depends upon the completion of work of the predecessor.
• Finish-to-finish. The completion of work of the successor cannot finish until the completion of work of the predecessor.
• Start-to-start. The initiation of work of the successor depends upon the initiation of work of the predecessor.
• Start-to-finish. The completion of the successor is dependent upon the initiation of the predecessor.

logical structure
The comprehensive organization of elements of a solution or a system, without regard to how it is implemented.

logical system hierarchy
The organization, classification, and ranking of functions into varying levels of hierarchy or nesting.

logistics management role
One of six team roles in MSF. Logistics management is responsible for ensuring smooth deployment of released products and that the product is manageable and supportable in the future. It does this by representing the operations viewpoint within the team and providing liaison between the two groups; planning and managing product deployment; participating in design and focusing on manageability, supportability, and deployability; supporting the product through beta testing; and training operations and help desk personnel for product release.

maintainability (internal focus)
The ability of a component or an IT service, under stated conditions of use, to be retained in or restored to a state in which it can perform its required functions.

maintenance
The implementation of changes in the technical infrastructure that can result from such things as errors in the application software, necessary extension of the functionality, or technical developments in the area of hardware and basic software.

master project plan
A deliverable of the planning phase for a development project. It consolidates feature team and role plans. For MCS, the master project plan includes a budget plan, capacity plan, communications plan, deployment plan, pilot plan, purchasing and facilities plan, security plan, test plan, and training plan.

master project plan drafted interim milestone
The point during the planning phase at which the project team has assembled and baselined the master project plan.

master project schedule
A deliverable of the planning phase. It consolidates feature team and role schedules. For MCS, the master project schedule includes a development schedule, testing schedule, user education schedule, logistics management schedule, and product management schedule.

master project schedule drafted interim milestone
The point during the planning phase at which the project team has created and baselined the master project schedule.

master risk assessment document
A deliverable of the planning phase. It consolidates feature team and role risk assessments.

materials resource
Physical objects consumed during the course of a project. Generally not a large factor in IT projects.

mean time between failure
The average elapsed time between the full restoration of an IT service or supporting component and the next occurrence of a failure to the same service or component.

mean time between system incidents
The average elapsed time between the occurrence of one system failure and the next failure.

mean time to failure
The mean time expected to the first failure of a component. It is a statistical value and is meant to be the mean over a long period of time and large number of component units.

mean time to repair
The average elapsed time from the occurrence of an incident to resolution of the incident.

Microsoft Operations Framework
A framework developed by Microsoft for managing, running, and maintaining distributed computing systems. The manage, run, and maintain phase within Microsoft's IT-related frameworks. MOF provides comprehensive and prescriptive technical guidance for achieving mission-critical reliability, availability, and manageability solutions and services on Microsoft technologies. MOF comprises white papers, operations guides, assessment tools, operations kits, best practices, case studies, and support tools that address the people, process, and technologies for effectively managing production systems within today's complex distributed IT environment.

Microsoft Solutions Framework
A framework developed by Microsoft for planning, building, and managing distributed computing systems. MSF is a set of proven practices for organizing software development teams and project planning that can be applied to planning and implementing almost any form of computing technology. This guidance includes white papers, case studies, and courseware in the areas of enterprise architecture, application development, component design, and infrastructure deployment.

milestone
A point (there may be many of them) on the project schedule at which the project team assesses progress and corrects deviations from scope, specifications, or other issues. A project may have interim milestones for internal use only, as well as external or major milestones, typically at the end of major phases of work, that are associated with the completion of major deliverables.

milestone, external
A point that represents team and customer agreement to proceed and signals a transition from one phase into the next. In scheduling, these often appear as a task with a duration of zero work units. Major milestones are generally exposed on customer reports. See also milestone, major and milestone, interim.

milestone, interim
A point in time that signals a transition within a phase and helps to divide large projects into workable pieces. See also milestone, internal and milestone, major.

milestone, internal
A task with no duration (zero days) used to identify internal events, or checkpoints, within a schedule rationalized by team leads, such as team focus and motivation on key deliverables/events, a tool to manage and track progress, or synchronization points for internal/external dependencies. These milestones are usually not displayed on customer reports.

milestone, major
A point that represents team and customer agreement to proceed and signals a transition from one phase into the next. In scheduling, these often appear as a task with a duration of zero work units. Major milestones are generally exposed on customer reports. See also milestone, external and milestone, interim.

mitigation, risk
In risk management activities, an action that may be taken to reduce the probability or impact of a risk, transfer the risk to another party, or avoid the risk entirely. A given risk may have several, one, or no mitigation actions attached to it.

mode of operational failure
In reference to the MOF risk model, the four main ways in which IT operations problems can cause failure:

• Cost. The infrastructure can work properly, but at too high a cost, causing too little return on investment.
• Agility. The infrastructure can work properly, but be unable to adapt to changing circumstances.
• Performance. The infrastructure can fail to meet users' expectations, either because the expectations were set wrong, or because the infrastructure performs incorrectly.
• Security. The infrastructure can fail the business by not providing enough protection for data and resources, or by enforcing so much security that legitimate users can't access data and resources.

model
A representation of a complex, real-world phenomenon designed to help understand questions about that phenomenon.

MOF
See Microsoft Operations Framework.

MOF service management functions
Foundational-level best practices and prescriptive guidance that are the core of the MOF process model. Although no service management function (SMF) is exclusive to a given quadrant in MOF, each SMF has a home quadrant or primary planning and execution quadrant. The following are examples of SMFs:

• Configuration management
• Problem management
• Service continuity management
• Workforce management

MSF
See Microsoft Solutions Framework.

MSF enterprise architecture process model
A process model based on MSF principles that establishes the enterprise architecture process as not just a plan, but also the implementation. Planning and implementation become simultaneous activities in this model.

MSF process model
A project life cycle model that establishes the order for all development cycle activities up to the initial release of an IT solution, or for the deployment of an existing solution into an enterprise.

MTTF
See mean time to failure.

MTTR
See mean time to repair.

N - O

narrative
A type of scenario that incorporates a day-in-the-life story in the language of the user.

network administration
A MOF service management function in the operating quadrant. It employs the process of maintaining communications systems, links, and accompanying data-processing procedures, in accordance with the requirements and preconditions arising from their use and the characteristics of the network components.

network topology
An infrastructure map that indicates hardware locations and interconnections.

noneffort-driven task
A task whose duration is independent of the number of resources assigned to complete it.

norm
An idea held by members of a group that can be expressed in the form of a rule and specifies what members are expected to do in given circumstances.

normalization
The administration of technical specifications for products, working methods, and so on, by an official, independent authority. Application of these standard specifications is not mandatory.

object
An encapsulation of an entity (data) and its corresponding services (functions) as a way of organizing them.

objectives
What an organization wants to achieve in the long term. They usually are linked with goals. See also goals.

OLA
See operating level agreement.

OLO
See operating level objective.

operating level agreement
An internal agreement between two or more IT entities that defines the responsibilities of all participating parties. An operating level agreement (OLA) binds these parties to provide a particular service (or service component, such as hardware, software, and so on) of a specific agreed-upon quality and quantity, and constrains the demands users may place upon the service (or service component) to those agreed-upon limits defined by the contract.

operating level objective
An agreed-upon, measurable service metric target between two or more IT entities, applied to the services provided to those entities and described in an operating level agreement.

operating quadrant
The second quadrant in the MOF process model It encompasses the day-to-day activities of an IT organization. Its activities ensure the smooth operation of the operations environment. Examples of these day-to-day activities include:

• System administration
• Batch processing
• Backup procedures
• Security
• Directory services

operating system
The basic software that runs on a computer system and allows application software to function.

operational consequence
In the MOF risk model, a description of the way in which the condition would affect the IT environment. The mode of failure typically influences the operational consequence.

operational level agreement
Internal agreements between departments and/or suppliers of an IT organization that allow service level agreement commitments to be fulfilled.

operations
The on-going (day-to-day) activities IT personnel perform on IT environment components to run and manage the information technology system and support the business organization. These activities emphasize execution and are particularly evident in the MOF operating quadrant.

operations review
The management review within the MOF operating quadrant. The primary goal of the operations review is to assess the effectiveness of internal operating processes and procedures and make improvements as appropriate. This evaluation is focused on internal processes and procedures utilized to meet service level requirements and in turn how those activities can be improved. The operations review assists in the retention of the corporate knowledge. It is crucial that, as the operations staff gains experience with a process, system, or application, it documents this experience and retains it in the corporate knowledge base. The operations reviews can be both release based and time based.

operations role
One of six roles in the MOF team model. It includes skilled specialists who focus on technology areas and production-systems tasks necessary to run the business on a daily basis. Enterprise operations roles include dedicated specialties such as messaging, telecommunications, networking, and database administration.

opportunity management
A formalized process for identifying, qualifying, managing, bidding, and evaluating project opportunities for IT projects.

optimization
Making a process as fully functional or effective as possible given the circumstances or inputs at present.

optimize
One of three key concepts in the Microsoft approach to managing project trade-offs. In the trade-off matrix, optimizing costs and resources means seeking their lowest possible allocation (a minimum-cost strategy).

optimizing quadrant
The fourth quadrant in the MOF process model. It evaluates the operational functionality of an IT organization.

The goal of this quadrant is to manage costs while continuously improving the level of services. The optimizing quadrant addresses two specific elements of operations:

• Business service reliability
• Cost

The objective of this quadrant is the optimization of cost, performance, capacity, and availability in the delivery of IT services. The optimizing quadrant includes the service management functions to manage costs while maintaining or improving service levels. This includes review of outages/incidents, examination of cost structures, staff assessments, availability, and performance analysis as well as capacity forecasting.

ORB
Opportunity review board. A panel convened to review project opportunities and provide recommendations for opportunity management (for example, whether to pursue resources).

P - Q

package release
A release that includes a package of software configuration items that are introduced into the production environments.

partner role
One of six roles in the MOF team model. It includes management of a broad collection of IT partners, service suppliers, and outsource vendors who work as virtual members of the IT staff in providing hardware, software, networking, hosting, and support services.

patch
An update (commonly called a fix) to a version or release. Each patch introduced into the environment needs a corresponding version adjustment.

performance support plan
A plan drawn up by the user education role for how to support end users of a software product.

phase
A distinct division within a process model or product life cycle, typically culminating in a major or external milestone, or representing a fundamental transition in the development of a product or service. In Microsoft Solutions Framework, process models and the product life cycle comprise four phases.

Phase in MSF correlates with "quadrant" in MOF. Phase as used in MSF infers that activities or tasks within each phase occur sequentially, with distinct demarcations between phases, although some overlap may occur. Quadrant is used in MOF to distinguish the fact that tasks or activities from each quadrant may begin nearly simultaneously and may continue concurrently for the life of the project.

physical design
The third major stage in the design process, in which the project team determines how to specifically implement the logical design.

physical environment
The geographic and workspace layout and artifacts that affect and support work.

pilot
Introduction of the solution into the production environment, and trial by installers, systems support staff, and end users; an "opening night."

pilot complete interim milestone
The point during the developing phase at which the project team has piloted the solution and is ready for deployment.

plan, build, manage IT life cycle
The fundamental IT life cycle upon which MSF is based. Enterprise architecture focuses on the planning aspects of the MSF life cycle.

planning phase
In MSF, the second phase of the four-phase process model. In this phase, the project team and other major stakeholders define the project scope, create the schedule, and prepare for the next phase. The planning phase culminates in the project plan or EA project plan approved milestone.

postmortem
A formal process of reviewing what went right and what went wrong with a project as a way of learning for the future.

predecessor task
A task or activity that must start or finish before another, dependent task

preliminary deployment model
The proposed network, data, and component topologies, determined by physical constraints of the infrastructure, physical requirements of the application, the enterprise architecture, and proofs of concept that will all still be evolving throughout the validation of physical design.

preproduction test complete interim milestone
The point during the developing phase at which the project team has tested and validated the elements created during development.

preventive maintenance
Maintenance directed at preventing errors so that they don't recur and cause future disruption in operations.

principal
A responsible party who is formally empowered to enter into service level agreements.

print and output management
A MOF service management function in the operating quadrant. It is responsible for managing the costs and resources associated with business output. The output could be printed documents, faxes, e-mail, Web pages, electronic transactions, or computer files.

priority
The sequence in which an incident or problem needs to be resolved, based on impact and urgency.

proactive analysis
An evaluation of how new and unused technologies can be applied to the organization. In this approach, planners do not treat the boundaries of current business practices as limitations, but try to change business processes through a new application of technology in a way that adds value to the organization. The proactive approach means that IT professionals have to imagine future directions that the organization might take and look for ways to apply new or unexploited old technologies to business. See also reactive analysis.

probability
In the MOF risk model, the likelihood that the condition will occur. (Note that this is not the likelihood of the consequence. It is assumed that if the condition happens, the consequence is a guaranteed result.) Probability is measured on a numeric scale, and it is never zero (because a risk that can't happen isn't something to manage) and never 100 percent (because that condition would be guaranteed: a known problem, not a risk).

problem
Underlying cause of one or more incidents.

problem diagnosis
The actions leading to the acknowledgement of an error, including the localization of the malfunction and establishment of the cause.

problem management
A MOF service management function in the supporting quadrant. Its primary objective is to effectively address the underlying/root cause of incidents in order to reduce the quantity and severity of incidents within the production IT environment. It employs the processes aimed at detecting and effecting structural improvements in the technical infrastructure and the settlement of problems arising from the use and management of information systems.

problem resolution owner
The person to whom a problem is assigned. This person owns responsibility for solving the problem, although not implementing the solution. Implementation is done by change management.

problem statement
A concise summation of the problem that the project is intended to solve.

procedure
The description of a formalized method of working (when and in what order actions are to be carried out) for a specified process or part thereof. Procedures provide for coordination between departments. Among other things, a procedure can be described as:

• The course taken through the company.
• What one department supplies to another, in what form, and at what moment.
• Rules relating to several departments.

process
A collection of activities that yield a result, product, or service; usually a continuous operation. A series of actions or operations designed to achieve an end.

process control
The process of planning and regulating, with the objective of performing a process in an effective and efficient way.

process model
See process model, MOF and process model, MSF.

process model, MOF
A spiral process model that provides a structure for the continuous assessment of all aspects of IT operations. It provides a mechanism for the rapid identification and incorporation of required changes to provide highly reliable and cost-effective services and solutions. This spiral process does not happen serially, but rather occurs in parallel across the service solutions. The MOF process model supports the successful provision of IT services by addressing four key principles: structured architecture, rapid life cycle and iterative improvement, review-driven management, and embedded risk management.

process model, MSF
The MSF project life cycle model that establishes the order for all development cycle activities up to the initial release. The model comprises four distinct phases: envisioning, planning, developing, and deploying the solution into the enterprise.

processing
The daily operation of all systems in the IT environment.

product management role
One of six team roles in MSF, this role's key contribution to lead the team to a shared vision of the requirements for meeting a customer need. The role acts as liaison between the team and customer; manages customer expectations; promotes shared project vision/scope; develops, maintains, and executes the business case; promotes features versus schedule trade-offs; and develops, maintains, and executes the communications plan.

product mindset
A best practice or principle of a successful team. It means treating all work as part of a project and treating the final deliverable of the project as a product. It is important because it focuses the team on execution rather than process, enables the team to use product development techniques such as versioned releases, and increases team identity and accountability.

product scope
The deliverables a project creates.

product-level vision
A long-term vision of what the product is intended to do.

program
A group of related projects, managed in a coordinated way. Programs usually include an element of ongoing work.

program management role
One of six team roles in MSF, it is responsible for driving the timely completion of an IT solution project. The program manager expedites critical trade-off decision-making, manages resource allocation, manages the project schedule and reports project status, manages the product specification, facilitates team communication and negotiation, and drives the development process. Conceptually, this role is roughly equivalent to the traditional project manager; however, in MSF the program manager acts as a coordinator among several peer roles, each of which has responsibility for its own set of tasks and activities. In PMO, a program manager usually directs the operations of several projects, either simultaneously or sequentially. This aspect of the MSF program manager role may be true, but it is not required. The program manager in PMO is also responsible for the success of the entire project-this is a shared responsibility in MSF.

program manager
The title for a person holding the program management role in an MSF team or the titular head of a large IT (or other) program involving several projects, ongoing projects, or other complex management activities. See also program management role.

programming model
Prescribes how to use implementation technologies, sets design guidelines as the foundation for component specification, and uses different considerations to address different aspects of the solution: stateful and stateless objects, in-process and out-of-process function calls, connected and connectionless modes, synchronicity, threading, error handling, security, and distribution.

project
A temporary endeavor undertaken to create a unique product, service, or result.

project assurance
A PMO role that provides overview, consultation, and advice on complex projects. Role typically assumed by a principal consultant, not involved in day-to-day project activities.

project closure
The definitive end point of a project, agreed upon and documented by the consultant and project sponsors. Project closure may occur due to successful project completion, loss of project viability (no longer appropriate), or risk exposures that have become unacceptably high.

project documents
One of the deliverables leading to the release milestone. They archive project artifacts for future reference.

project lead
Synonym for MSF program manager within an engagement.

project life cycle
A collection of generally sequential project phases whose name and number are controlled by the needs of the organization or organizations involved in the project.

project manager
The individual responsible for managing a project.

project phase
A collection of logically related project activities, usually culminating in the completion of a major deliverable.

project plan
A formal, approved document used to guide both project execution and project control. The primary uses of the project plan are to document planning assumptions and decisions, facilitate communications among stakeholders, and document approved scope, cost, and schedule baselines. A project plan may be summarized or detailed.

project plan approved milestone
In MSF, the second of four major milestones. It represents the culmination of the planning phase, indicating the project team, customer, and key project stakeholders agree on what will be delivered and when.

project schedule
The planned dates for performing activities and the planned dates for meeting milestones.

project scope
The work (schedule and resources) required to create the deliverable in the product scope.

project structure document
A deliverable of the envisioning phase, leading to the vision/scope approved milestone.

project trade-off triangle
A model that displays the relationships between the three components of a project that describe the scope of work (resources, schedule, features). See also resource and trade-off triangle.

project variables
The three sides of the trade-off triangle. They include resources, schedule, and features.

project-level vision
A short-term vision of what the project team wants the current version of the product to do.

proof of concept complete interim milestone
The point in the developing phase at which the project team has deployed the selected technology in a lab environment designed to simulate the production environment.

protocol
The standardized way in which communication takes place between two components.

quadrant
The four distinct divisions of the MOF process model, culminating in a major or external review. Quadrant in MOF correlates with "phase" in PMO and MSF. Quadrant is used in MOF to distinguish the fact that tasks or activities from each quadrant may begin nearly simultaneously and may continue concurrently for the life of the project. Phase as used in PMO and MSF infers that activities or tasks within each phase occur sequentially, with distinct demarcations between phases, although some overlap may occur.

quality
The totality of those properties and characteristics of a product or service that are important in enabling the fulfillment of established or self-evident needs.

quality assurance
A role some organizations use to ensure that a quality bar is set and met; not to be confused with the testing role in the MSF team model, which is responsible for tracking the status of product development.

quality level
A measure of quality, expressed as a measurable quantity (the response time or availability percentage, for example).

R

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.

relationship
An illustration of how entities are related to each other.

release
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).

reliability
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.

requirements
A condition necessary for the proper definition of the solution.

research
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.

reserve
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.

resilience
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.

resolution
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.

resource
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.

RFC
See request for change.

risk
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.

role
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.

roll-up
A series of patches joined consecutively.

S

scale
A way of adjusting the scope of a planned project so that it matches a fixed ratio or actual need.

scale down
To narrow the scope of a project or plan.

scale up
To expand the scope of a project or plan.

scenario
A single sequence of object interactions and interactions between objects and actors; a particular instance of a use case.

schedule
One of three sides of the trade-off triangle, the others being resources and features. It means time.

scheduling for an uncertain future
A principle of good scheduling recognizing that the future is uncertain and creating schedules that are designed to adjust to the unexpected.

scope
The sum of the products and services to be provided as a project. Negotiating the scope of a project balances customer needs and desires against technological and business constraints.

scope complete milestone
The third of four major milestones, representing the culmination of the developing phase, indicating all features have been completed and the product is ready for external testing and stabilization.

scope creep
Unmanaged scope change. The risk that additional user requirements will cause the project to expand beyond the original scope. Scope creep should be avoided when possible.

security
Comprises security policies as specified by security design and processes that address IT asset confidentiality (protection of data), integrity (accuracy of data), and availability (access to data).

security administration
A MOF service management function in the operating quadrant. It employs the process of developing, implementing, and managing security controls. Components include data confidentiality, data integrity, and data availability.

security role
One of six role clusters in the MOF team model. It is responsible for corporate data, network, and operational security. A second area of responsibility is the development and implementation of a comprehensive plan for the retention, classification, and secure disposal of data. Additionally, the security role is responsible for a sufficient plan to recover a corporate network to at least a minimum operational configuration in a short amount of time, including all critical business applications.

service
In application development and related fields (MSF), a component of an application that implements operations, functions, or transformations to data. In IT operations (MOF), a set of activities performed and/or supplied by an organizational department. Service level agreements are negotiated regarding the level of service to be supplied, which is then formally documented. Services differ from components in completenessa service provides a direct business value, a component cannot.

service catalog
A directory of all services that an IT organization offers. The service catalog should contain a page for each service and include the following:

• A description of the service
• Agreed service level
• Contact list (names phone number, e-mail address) of the service manager and the key customers

service continuity management
A MOF service management function in the optimizing quadrant. It focuses on procedures and components necessary to minimize service disruption of mission-critical systems.

service delivery
A collection of IT service management disciplines and processes that are directed at optimizing operational processes (service support) and that are responsible for the final service provision. The service delivery disciplines are service level management, service continuity management, availability management, capacity management, and financial management.

service desk
A MOF service management function in the supporting quadrant. It provides first-line support to the user community for incidents associated with the use of IT services. The goal of the service desk is to restore service to the user(s) as quickly as possible. The service desk is tasked with end-to-end tracking and control of incidents through resolution. A service desk may be an organizational unit composed of multiple service groups-for example, a call center and one or more site support teams (infrastructure and/or application service providers).

service entity
A collection of service groups and specialists. There are four types of service entities: call center, infrastructure, application, and monitoring and control.

service event
An event that requires action from a support group. There are four types of service events: incident, request for information (RFI), request for change-standard (routine change), and request for change-formal (a change requiring the change management process). Requests for training (RFT) will be included in RFI.

service level
An agreed quality and quantity of services to be supplied.

service level agreement
An agreement between IT and the user community that defines the responsibilities of all participating parties and that binds IT management to provide a particular service of a specific agreed-upon quality and quantity. It constrains the demands users may place upon the service to those limits defined by the agreement.

service level management
A MOF service management function in the optimizing quadrant. It employs the processes of planning, coordinating, drafting, agreeing, monitoring, and reporting on service level agreements, and the ongoing review of service achievements to ensure that IT and business are aligned and that service quality is cost justifiable.

Note The IT Infrastructure Library (ITIL) also uses this term to connote a similar meaning and process. MOF uses the underlying ITIL characterization as a foundation and then extends it by incorporating partner experience and Microsoft-specific features. For the specific ITIL definition, please consult the ITIL glossary, located at the time of publication at the ITIL Web site.

service level objective
An agreed-upon, measurable service metric target between the IT organization and one or more of its customer communities, applied to the services provided to those communities and described in a service level agreement.

service management
A collection of people, processes, and technology through which conditions are created that ensure the continuity and quality of the agreed services. Service management includes IT operations as a practice in delivering services, but maintains a broader scope by emphasizing, supporting, and continually improving IT services.

service management architecture
A structured system of management processes, personnel, the management organization, and the supporting information system, as well as their mutual interrelationship. A well-designed architecture enables an IT management organization to supply its customers with IT functionality in a controlled manner.

service management function
See MOF service management functions.

service manager
Ultimately, the responsible entity for day-to-day provision and monitoring of an individual service across all relevant sites; responsible for providing SLA compliance measures and for ensuring that the service review is carried out. Normally there is one service manager per service.

service monitoring and control
A MOF service management function in the operating quadrant. It allows operations to observe the health of an IT organization in real time. This process ensures that service levels are always in a state of compliance.

service provider
Internal or external provider of IT service.

service request
All incidents other than failures in the IT infrastructure.

service support
A collection of operational disciplines and processes that support the management of the IT production environment; in other words, configuration management, service desk, problem management, and change management.

serviceability (external focus)
The contractual conditions with suppliers, outside of the internal IT, covering the availability of an IT service and the conditions under which the contractual conditions are valid for a configuration item or system.

shared project vision
A best practice or principle of a successful team. It means clearly understanding project goals and objectives, and understanding and buying into a vision that is held by all team members and the customer. It is important because it provides the team a uniform sense of purpose, resolves conflicting and contradictory visions, clarifies project goals and objectives, and ensures that team members are working toward the same goal.

shared project vision
A vision for the project that all members of the project team share. Shared vision unites the team in pursuit of a common goal and is vital to the success of a project.

single point of failure
Any component of an IT service that would cause downtime in the event of it failing to function correctly. Availability management aims to cost-effectively remove as many single points of failure as possible through the use of appropriate countermeasures.

site deployments complete interim milestone
The point during the deployment phase at which the project team has deployed the selected technology at all the phase sites.

SLA
See service level agreement.

SLA review
The interval-based review at the end of the MOF supporting quadrant. The operations staff, lead by the support team, reviews the SLAs and the associated metrics during this review and determines which services have met the service level requirements. The staff then takes corrective action to address those areas that fail to meet the requirements.

An SLA typically contains information and requirements on service hours, availability, workload and throughput, priorities, support levels, responsiveness, restrictions, functionality, contingency, security, costs and charges.

It is the management review that assesses the effectiveness of the IT operations group in delivery of the agreed-upon service levels contained in the approved SLA. It focuses its assessment on the delivery of services to the customer and end users and on what changes are required to address any inadequacies in these services.

The SLA review is how MOF recommends that customers, end users, and the operations staff monitor service delivery and is one method of identifying changes required in service levels, system functionality, new business requirements, and/or key process changes.

SMF
See MOF service management functions.

software environment
Software used to support the application, such as operating system, database management system, development tools, compilers, and application software.

software library
A controlled collection of software configuration. It includes all of the new, modified, or existing software configuration items that are made available for use at any given time.

solution concept
The part of the vision/scope document that outlines the approach the project team will take to solve the problem. It provides the basis for planning and scoping the analysis and investigative work required to build a specification.

solution design document
A component of the functional specification that contains technology- and product-specific information that will enable the team to move forward with project planning and schedule deployment activities.

source code and executables
A deliverable of the developing phase. These represent the physical reality of the product itself.

sources of risk
Related to the ITIL term category. There are four main sources of risk in IT operations:

• People. Even if the group's processes and technology are flawless, people make mistakes, and these mistakes can put the business at risk.
• Process. Flawed or badly documented processes can put the business at risk even if they are followed perfectly.
• Technology. The IT staff may perfectly follow a perfectly designed process, yet the business can fail because of problems with the hardware, software, and so on.
• External. Some factors are beyond the IT group's control but can still harm the infrastructure in a way that causes business failure. Natural events such as earthquakes and floods fall into this category, as do externally generated, man-made problems such as civil unrest, computer virus attacks, and changes to government regulations.

specialization
The degree by which various organization units carry out specific actions or work per product or service.

spiral life cycle model
A life cycle model that relies on iterations for creativity and continued improvement.

stabilization complete interim milestone
The point during the deployment phase at which the project team has stabilized the solution and transitioned responsibility for the technology to the production support staff.

stabilizing phase
The last of four distinct phases of the MSF process model. It is the period during which all team efforts are directed at addressing all issues, ranging from code defects to mismanaged expectations. No new development occurs during this phase. It culminates in the release milestone, at which point responsibility for the product shifts to the operations team.

standardization
The establishment of technical specifications for products, working methods, and similar components for system uniformity. Use of the standard specifications can be made mandatory for subordinate organizations.

standards
Established or prescribed course of action or procedure to be followed for specific situations, operations, or business processes.

step
The smallest level of action that cannot be decomposed any further.

storage management
A MOF service management function in the operating quadrant. It provides management of on-site and off-site data storage for the purposes of data restoration and historical archiving.

strategic management/level
Actions concerning the relationship of the organization to its environment and the basic outlines of the organization structure. Decisions on a strategic level influence the processes within the organization. Final responsibility lies with the directors, but functionaries at lower management levels have an important role as information providers. Strategic management gives direction to the business-economic, organizational, and technological aspects of management.

strengths, weaknesses, opportunities, threats
Factors in an organization that may impact proposed solutions to enterprise architecture problems. Analyzing these factors may influence IT decisions. See also SWOT analysis.

subenvironment
A logically autonomous part of a conceptual environment that belongs to a specific application or service.

successor task
A task or activity that depends upon the completion of another task, and must start or finish after it.

support role
One of six role clusters in the MOF team model. The support role includes service desk and production support functions. The goal of the service desk is to provide timely, efficient, and accurate customer support in the resolution of incidents while production support teams are typically the second level in the escalation chain of incident management.

supporting quadrant
The third quadrant in the MOF process cycle. It supports IT operations in day-to-day operations. The supporting quadrant incorporates the concepts of integrated resolution processes. These processes include a service desk, incident management, problem management, and service recovery processes. Tasks performed in the supporting quadrant are concurrent with tasks performed in the operating quadrant.

SWOT analysis
A way to evaluate strategies with respect to the organization's resources and environment.

system
An integrated composite that consists of one or more of the processes, hardware, software, facilities, and people that provides a capability to satisfy a stated need or objective.

system administration
A MOF service management function in the operating quadrant. It focuses on the day-to-day tasks associated with maintaining enterprise systems.

T

tactical management/level
Actions relating to the coordination and organization of work (in progress). Decisions on the tactical level influence the procedures employed in the various departments. Tactical management is responsible for translating the separate management sectors into actuality as well as all equipment needed for this (hardware and software) and personnel.

task
A generic term for work that is not included in the work breakdown structure, but potentially could be a further decomposition of work by the individuals responsible for that work. It is also the lowest level of effort on a project.

task sequence
A type of scenario that includes detailed steps for required activities.

team goals for success
A set of principles for successful teaming that focus on giving customers what they want, on time and within budget.

team lead
The manager of a project subteam that collectively represents a team role or team role cluster within a MOF or MSF project.

team model
An organizational work model that emphasizes the use of small, cohesive teams of interdependent, multidisciplinary role specialists who communicate on an equal basis in the accomplishment of their individual and group tasks. In MOF, the team role clusters are release, operations, support, partner, infrastructure, security. In MSF, the team role clusters include are program management, product management, development, test, logistics, and user education.

team model for application development
A small team of peers working in interdependent, multidisciplinary roles. The team model is a starting point, not the final answer, for good project management, emphasizing a flexible approach, dependent on project scope, team size, and team member skills.

team of peers
An organizational work model that emphasizes the use of small, cohesive teams of role specialists who communicate on an equal basis in the accomplishment of their individual and group tasks. This work model contrasts to that of the traditional top-down, linear-structure work model, and has been functionally proven in a variety of different organizations, cultures, and project sizes.

team roles
The six divisions of the MSF team model, including product management, program management, development, user education, test, and logistics.

technical lead
Synonym for MSF development lead within an engagement.

technology perspective
A technology perspective views the enterprise architecture from the perspective of the technological infrastructure that supports the business processes of the enterprise architecture.

technology validation complete interim milestone
The point during the developing phase at which the project team has evaluated the technology against the functional specification in an isolated, clean environment.

test environment
An environment that corresponds as closely as possible to the production environment and within which system and user acceptance tests can be carried out.

test plan
A plan developed by the testing role that outlines how testing plans to maintain the reliability of the product and to ensure that all issues are known.

testing
Ensuring that the right things are done right at the right time.

testing elements
Deliverables of the developing phase that outline what testing plans to do (including the test plan) and are baselined at the scope complete milestone.

testing results and testing tools
One of the deliverables leading to the release milestone. They capture the bug database and test materials for future reference.

testing role
One of six MSF team roles. The testing role's responsibility is to accurately portray the status of the product or solution at any time by clearly documenting what is currently wrong and what is currently right with the product. It develops testing strategy, plans, and scripts to ensure all issues are known; manages the build process; conducts tests to determine the status of production development accurately; and participates in setting the quality bar.

top 10 risk list
An identification of the 10 top priority risks, taken from the risk assessment document.

tracking owner
The person who tracks progress on a service incident to ensure service levels are not violated. In most cases, the tracking owner is the person who registers a service incident, although tracking ownership can be transferred in rare cases.

tracking risk
Monitoring the risks and their mitigation plans.

trade-off matrix
A technique for managing project trade-offs by portraying them in a matrix that reflects the three project variables in the context of three decisions-whether to optimize, constrain, or accept a given variable.

trade-off triangle
A triangle of project variables whose three sides are resources (people and money), schedule (time), and features (the product and its quality). It is used to make project trade-offs. A change to one of its sides requires that the team make a correction on one of the three sides to maintain project balance, including potentially the same side on which the change first occurred. For example, a decision to add a feature to a product may require that other features be removed if sufficient time and resources are unavailable to support their development.

traditional team
A team based on a hierarchical organization chart, with a manager at the top and subordinates below.

trigger
In the MOF risk model, a measurement threshold that indicates that the condition is about to occur. It is a value that is either true or false. When it shifts from false to true, the team executes the contingency plan.

trigger, risk
Indications that a risk has occurred or is about to occur. They sometimes are called risk symptoms or warning signs. Triggers may be discovered in the risk identification process and watched in the risk monitoring and control process.

trigger, risk contingency
The criterion for executing a contingency plan.

TSC
Technology strategy consultant

U-Z

underpinning contract
A contract between IT and one or more external vendors that defines the responsibilities of all participating parties. The contract binds these parties to provide a particular service (or service component, such as hardware, software, and so on) of a specific agreed-upon quality and quantity, and constrains the demands IT and/or its users may place upon the service (or service component) to those agreed-upon limits defined by the contract.

undesired architecture
The enterprise architecture that results when an organization does not attempt to plan for the future.

upgrade
An adjustment to the version or release in which the version number changes.

uptime
The time between incidents or failures when customer expectations are met as specified by the operating level agreement or the service level agreement.

urgency
The degree to which an action does not tolerate delay.

usage testing
Testing whether the product works as intended. It occurs primarily during the stabilizing phase. See also coverage testing.

use case
A behaviorally related sequence of interactions that an actor performs in a dialog with a system to provide some measurable value to the actor; a collection of scenarios.

user
The person who uses the services on a day-to-day basis.

user education role
One of six MSF team roles. It represents the end user and is responsible for optimizing the end user's performance and experience with the solution. It functions as team advocate to the end user and end-user advocate to the team, participates in defining user requirements and designing features, designs and develops performance support systems, including training materials, and drives the usability process.

user interface
The part of the application that interacts with the people operating it.

user performance support elements
One of the deliverables leading to the release milestone. They constitute the final release of the support elements.

user profile
A description of the eventual users of the solution in terms of geography, organizational and communication structures, user functions, resource availability, and other relevant information.

user requirement
A desire of the end user of the application that focuses on the solution to the business problem; its fulfillment is necessary for day-to-day performance of work processes.

user service
A unit of application logic that provides an application with its user interface.

validation
Testing concepts through walk-throughs and prototyping.

variance
The difference between a project's baseline status and current status.

version
The status of a configuration item, consisting of one or more changes at the specification level. The functional specifications are therefore changed in relation to the earlier version.

version identifier
A version number, version date, or version date and time stamp.

version management
A process directed at bringing and keeping under control various versions of configuration items of the technical infrastructure.

version number
A combination of xxnn in which xx is the major number and nn is the minor number.

versioned release strategy
A time and resource control strategy in which a deployment project is treated as if it were a series of versioned product releases. This strategy allows the team to deliver a deployment within the expected time frame by providing the most critical functionality in the first version and postponing other desirable features until later releases.

versioned releases
Providing the most critical functionality for a product in the first version and postponing other desirable features into later releases. See also versioned release strategy.

vision
An unbounded view of what the team wants to accomplish.

vision document
A major milestone at the end of the envisioning phase that sets forth all the projects and goals for the next versioned release of the enterprise architecture.

vision statement
A deliverable that expresses the long-term vision of the product and provides a context for decision-making.

vision/scope approved milestone
The first of four major milestones in the IT project life cycle, at which the project team and the customer have agreed on the overall direction of the project. The vision/scope approved milestone is the culmination of the envisioning phase.

vision/scope document
The primary deliverable for the envisioning phase. It expresses project goals and constraints as a business case.

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

waterfall life cycle model
A project life cycle model that works well for complex projects as long as the team can easily specify requirements at the beginning. It uses milestones as transition and assessment points.

willingness to learn
A best practice or principle of a successful team. It means committing to self-improvement through gathering and sharing knowledge and institutionalizing learning through such techniques as reviews and postmortems. It is important because it allows team members to benefit from mistakes, helps team members to repeat successes, and mandates time for the team to learn.

work
The resources expended in a project, multiplied by the duration of the project.

work breakdown structure (WBS)
A deliverable-oriented group of project elements that organizes and defines the total work scope of the project. Each descending level represents an increasingly detailed definition of the project work.

work order
Provides coordination within a department. The work order indicates which function must carry out which action, in which order, and when.

work resource
The personnel and equipment required to perform project activities.

workaround
A method of avoiding an incident or problem, either from a temporary fix or from a technique, that means the customer is not reliant on a particular aspect of a service that is known to have a problem.

workflow process
A type of scenario that includes communication and coordination of discrete work processes.

workforce management
A MOF service management function in the optimizing quadrant. It recommends best practices to recruit, retain, maintain, and motivate the IT workforce.

zero-bug release
The first release to testing after all active bugs have been resolved.

zero-defect mindset
A best practice or principle of a successful team. It describes a commitment by the project team to do work at the highest quality possible at the time it is being done, and a commitment by each team member to individually help achieve the desired level of quality. As a practice, the zero-defect mindset does not require that deployed solutions be perfect with literally no defects; rather, it establishes perfection as a consistent goal for which to strive. It is important because it increases product stability, schedule predictability, and accountability.