Appendix B - MSF Glossary
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.
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 solution or product by internal resources.
approach
An early form of a plan that describes that is included in the solution concept, an essential part of the vision/scope document. Approaches evolve into actual plans and specifications at a later stage of the project.
architecture
The physical construction or design of a computer system and its components.
baseline
A measurement or known state by which something is measured or compared, which is necessary for managing change. It can be thought of as a snapshot at a set point in time. In MSF, a baseline consists of the original approved plan, plus or minus approved scope changes. It is usually used with a modifier (a cost baseline or schedule baseline, for example). 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.
best practice
A procedure or functional principle that is considered by experts to be optimal, based on industry experience. When followed, best practices for solution building generally result in enhanced work flow, improved results, and other benefits in completing project activities.
beta testing
Testing of a stabilized solution or product by external end users.
bottom-up estimating
A principle of good scheduling. It means having those who do the work estimate the effort because the most accurate estimates are based upon experience, and then rolling up task-level estimates in order to make activity-level and project-level estimates.
budget plan
One of several plans that are rolled up into the master project plan. It documents all of the projected costs of the project, covering such areas as: hardware for the solution (PCs, servers, routers, and controllers), additional required bandwidth for the solution, software for the solution, hardware and software for the development environment, contractors, training courseware and other training aids, and communications development. See also master project plan.
buffer
In project scheduling, time added to the schedule by the program manager to help the project team accommodate unexpected problems and changes. 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 solution.
bug classification
Making a bug actionable by determining severity (see bug severity), which measures its impact on the solution, and by priority (see bug priority), which measures how important it is to fix the bug.
Bug Convergence Interim Milestone
An interim milestone in the Stabilizing Phase marking the point at which the rate of fixed bugs exceeds the rate of found bugs. Bug convergence is a visible indication that the team is making progress against the active bug count. It is a sign that the project end is within reach.
bug priority
A determination of the importance of fixing a bug.
bug resolution
Addressing a bug in some fashion (such as fixing it, labeling it as intentional by design, or deciding not to fix it) in order to close the bug.
bug severity
A determination of the extent to which a bug affects the solution.
bug triaging
Evaluating and prioritizing bugs to determine their appropriate resolution.
build
A periodic assembly of all the solution elements that are sufficiently complete to be included. Builds include code components, directory structures, infrastructure elements, documentation, and sometimes automated deployment scripts.
build cycle
A part of the internal release cycle. It is the process of adding features, creating test cases for each, stabilizing each feature before building new features, and then releasing for evaluation. See also build and daily build.
build verification test
A test that is run after the daily build to verify that compilation of source code has been built successfully. See also coverage testing.
business function
The highest level of the intended accomplishments of a business process. For example, financial management is a business function; accounts receivable is a related business process. See also business process.
business goal
A component of the envisioning process in which the first steps toward defining the solution concept is the definition of business goals of the solution, as well as the definition of the design goals.
business need
A desire of the project customer that focuses on a business problem; its fulfillment is strategic to organization goals.
business perspective
A view of the IT project through the lens of the associated business processes. This is most commonly the view taken by the project customer, sponsor, and product manager.
business process
A structured, measured set of activities designed to produce a specified output for a particular customer or market. Business processes have customers and, in most cases (but not always), cross organizational boundaries.
capacity plan
One of several plans that are rolled up into the master project plan. Projects the additional usage of systems and networks due to the solution, evaluates current capability to handle extra usage, and plans the additional hardware and services that will be needed. Focuses on capacity of disks, memory, and processors as well as network bandwidth. See also master project plan.
change advisory board
A group of people who are responsible for assessing and authorizing changes. In MSF projects, the changes in question are limited to the project, and the advisory board is typically made up of key stakeholders and project team members. In MOF, the changes being considered are to the IT environment. The change advisory board (CAB) is a key component of the formal change management process described in the framework, and is likely to be made up of representatives from all areas within IT as well as representatives from business units.
change authorization
Consideration and approval or disapproval of a change by the change advisory board. An essential step in the MSF change control process for projects. Also, a more formal step in the change management process described in MOF.
change classification
Assigning a priority and a category to a change, using its urgency and its impact on the infrastructure or users as criteria. A formal step in the change management process described in MOF. An optional step in the MSF change control process for projects.
change control
A process to request, review, approve, document, and distribute changes. The level of required formality for a project depends on the projects scope and complexity. Change control for a project may use many of the steps of the organizations IT change management process.
change request
The formal initiation of a change in a project (MSF) or in the IT production environment (MOF). In MOF, this procedure is accomplished through the submission of a request for change.
check-in test
Quick automated tests that developers perform before checking in code. See also coverage testing.
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.
closeout report
A document signifying formal project closure. It documents final deliverable versions, compiles customer/user surveys, and summarizes next steps.
code review
Assessing code to improve its quality and the capabilities of the development team. Types of code review include formal review, peer-based review, and third-party review.
communications plan
One of several plans that are rolled up into the master project 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. See also master project plan.
compatibility test
A type of usage test that checks for compatibility of the solution with other elements of the target environment.
competency
In the context of the MSF Readiness Management Discipline, the knowledge, skills, and performance level required to work effectively within a given area of an IT project.
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, core
Components located at central or key locations that enable interoperability of the overall solution.
component, site
Components located at individual locations that enable users to access and use the solution.
conceptual design
A major stage in the design process for a solution in 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 usage scenarios that the solution must encompass. Conceptual design is analogous to the rough sketches created when designing a house. These are easily understood models jointly created by the customer and the architect.
configuration baseline
Configuration of a solution or system established at a specific point in time that captures both its structure and details and enables the solution or system to be rebuilt later.
configuration management
In MSF, the formalized tracking and control of the state of various project elements, including version control for code, documentation, user manuals and Help files, schedules, plans, and the state of hardware, network, and software settings of a solution. It provides the baseline data that the team needs in order to make effective change control decisions.
In MOF, one of the service management functions in the changing quadrant of the process model. 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 test
A type of usage test.
constraint
A nonfunctional requirement that applies to various aspects of projects (such as budget, resources, technology, and so on) and that places a limit or dictates a limited range of possibilities.
constraint, adjustable
Project constraints that may be adjusted to accommodate other project constraints.
constraint, chosen
Project constraints that are identified as desired priorities.
constraint, fixed
A project constraint that is essentially unchangeable.
contingency plan
In MSF projects, a plan for addressing recognized risks that may arise during the project. For development projects, the plan may, for instance, reallocate resources or drop features to react to an unanticipated change in schedule.
core component
See component, core.
core team
An MSF project team in which each of the six defined role clusters are represented by members who have the skill sets needed for the project. In special cases, another role cluster may need to be defined. The core team functions as the lead team when the complexity or size of a project increases and requires additional resources.
Core Team Organized Interim Milestone
The point during the Envisioning Phase at which key team members have been assigned to the project and are ready to move the project forward. The full team is usually not assembled yet.
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.
coverage testing
Testing that is done primarily during the Developing Phase. Its goal is to thoroughly test every feature of the solution as well as the code base of the solution. Types of coverage tests include unit, functional, check-in, build verification, and regression.
customer
An individual or organization that expects to gain a business value from the solution. Also known as the business sponsor. Also, the recipient of a service or product.
customer-focused mindset
A characteristic of a successful project 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, each of which are best practices.
daily build
Building the solution in an executable form on a daily basis. Includes a cycle of development, testing, and validation.
deliverable
A physical artifact created by the team, usually associated with reaching an interim or major milestone. It can be a single artifact or one of several artifacts associated with that milestone. Deliverables may be internal for use by the project team, or delivered to and subject to approval by an external customer or sponsor.
Deploying Phase
The final stage of the MSF process model, during which the project team deploys the tested solution to all planned sites, stabilizes the deployment, transitions the project to operations and support, and obtains final customer approval of the project. The Deploying Phase culminates in the Deployment Complete Milestone.
Deployment Complete Milestone
The point at which the deployed solution provides 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.
deployment plan
One of the plans that is rolled up into the master project plan. It covers installation strategy, contingencies, support, site/line-of-business survey approach, deployment mechanisms, deployment resources, and systems support approach. See also master project plan.
Deployment Stabilized Interim Milestone
An interim milestone of the Deploying Phase that signifies that the customer and team agree that the deployed sites are operating satisfactorily, though problems may continue.
design document
Separate from the functional specification, the design document records the results of the design process. It is kept internal to the team, is focused on describing the internal workings of the solution, and can be changed without burdening the customer with technical issues.
design goals
Goals set during the Envisioning Phase that outline, at a high level, the process of designing an IT solution for a business problem.
design, conceptual
See conceptual design.
design, logical
See logical design.
design, physical
See physical design.
Developing Phase
The third phase in the MSF process model. Depending on the nature of the project, most solution components are built (documentation as well as code) and installation scripts, configuration settings for deployment, test specifications, and test cases are created during this phase. The Developing Phase is preceded by the Project Plan Approved Milestone and culminates with the Scope Complete Milestone.
Development Role Cluster
One of six MSF team role clusters (roles), it creates coding, scripts, and configurations, focusing on using the solution architecture, the solution designs, and the functional specification to build the solution. It participates in design, focusing on physical design; estimates time and effort to complete each feature; and serves the team as a technology consultant.
Development/Test Environment Set Up Interim Milestone
The point during the Planning Phase at which the project team has prepared the environment in which development and testing will take place.
discipline
Industry processes and best practices, in specific categories, as viewed from an MSF perspective. The three MSF disciplines are Project Management, Risk Management, and Readiness Management.
dogfooding
Microsoft jargon for the internal use of solutions and products that Microsoft is developing, prior to releasing them to customers. Eating our own dogfood means that Microsoft releases only solutions and products that it would use internally.
end user
The person who actually uses a solution, as opposed to the customer, who is the person or organization that commissions the project, provides funding, and expects to get business value from the solution.
enterprise architecture (EA)
A structure that describes the organizations business activities, the applications and automation that support them, the information necessary to carry them out, and the technologies and infrastructure used to deliver the applications and information. It provides a strategic basis for implementing IT in a way that takes best advantage of available IT technologies. Also helps organizations to extend and evolve IT capabilities in response to changing needs of the business environment. Technical advantages that result from an effective EA provide important business benefits.
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 often has unique features and characteristics that dictate how it is administered.
Envisioning Phase
The first of five 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.
events trigger
A true or false condition that invokes a contingency plan. An events trigger relies upon specific events to occur. An example of an events trigger is a change in the structure of a project team. See also trigger.
external communication
The process of keeping stakeholders apprised of the progress of a project and how the solution will affect them.
failed project
Projects that are cancelled before completion or are never implemented.
fast tracking
Compressing the project schedule by overlapping activities that would normally be done in sequence, such as design and construction.
feature team
In large projects, a multidisciplinary sub-team that is organized around and responsible for a particular feature set of the solution or product.
fixed ship date mindset
A principle of good scheduling. It means treating a projects projected ship date as unchangeable and committing to a ship date because it is realistic.
function team
In large projects, a multidisciplinary sub-team that is responsible for a particular functional role, such as product management or user experience. A function team is used to fulfill just one role and is also known as a unidisciplinary sub-team.
functional specification
A deliverable for the Planning Phase that describes a solution, product feature set, or other final project deliverable in explicit detail.
Functional Specifications Baselined Interim Milestone
The point during the Planning Phase at which the project team has drafted and the functional specification and begins formally tracking changes.
functional test
A test that is performed to ensure that features are present and functioning as described in the functional specification. See also coverage test.
gap analysis
A study that is conducted to discover the gap between the current state and the desired state of an aspect of a project, such as the readiness of the team members to carry out the project.
go/no go decision
A decision to proceed with, or delay, a project action.
high potential project
A project that is important to achieve future success for a business. This project classification is part of a definition process that is useful in determining skill requirements for a project.
initial risk list
See risk list.
internal release
The process of getting the solution or product to a known state and incrementally building upon it.
Internal Release N Complete Interim Milestone
An interim milestone in the Developing Phase that marks the completion of a particular internal release. There may be several internal release complete interim milestones, depending on the size of the project.
iterative development
The development of a solution or product by building, testing, and deploying a core set of basic features first, and then adding features in successive versions.
key concepts
Specific ideas, captured as statements, that are characteristic of MSF and important to the practice of MSF principles and disciplines. An example of an MSF key concept is: Risk is an inherent aspect of any project or process.
key operational project
A project upon which a company depends for its current success. This project classification is part of a definition process that is useful in determining skill requirements for a project.
knowledge
In the context of the MSF Readiness Management Discipline, the information and understanding that an individual must possess to perform a job competently.
lag time
A project management term describing the interval between the end of one project activity and the beginning of a dependent project activity.
lead time
A project management term describing the interval between the start of one project activity and the start of a dependent, yet concurrent activity.
life cycle
The phases a solution goes through from the time it is conceived until the time it is retired from service.
living document
A document that is regularly updated and referred to.
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 structure
The comprehensive organization of elements of a solution or a system without regard to how it is implemented.
master project plan
A major deliverable in the Planning Phase for a solution development project that describes how the solution will be built. It consolidates several detailed plans prepared by feature team leads and core team roles. Typically, 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 Baselined 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 that includes the release date. The program manager prepares it by that combining and integrating all of the detailed project schedules prepared by each team lead.
Master Project Schedule Baselined Interim Milestone
The point during the Planning Phase at which the project team, driven by the program manager, has created and baselined the master project schedule.
master risk list
See risk list.
MOF
Microsoft Operations Framework.
MOF Process Model
See Process Model, MOF.
MOF Team Model
See team model.
MSF
Microsoft Solutions Framework.
MSF Process Model
See Process Model, MSF.
MSF Team Model
See team model.
Microsoft Solutions Framework
A framework that offers guidance in how to organize people and projects to plan, build, and deploy successful IT solutions.
milestone
A point on the project schedule at which the project team assesses progress and quality and then reviews deviations in scope and specifications. A project may have interim milestones for internal use only, as well as external milestones or major milestones, typically at the end of major phases of work, that are associated with the completion of major deliverables.
milestone review meeting
A gathering of customers, stakeholders, sponsors, and team members for the purpose of gaining agreement that the milestone criteria have been met and for making go/no go decisions.
milestone, external
Another name for a major milestone. It is called external because it involves customers and other stakeholders who are external to the project team. 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, external and milestone, major.
milestone, major
A point that represents team and customer agreement to proceed and signals a transition from one project phase to the next. The MSF Process Model has five major milestones. 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.
model
A schematic or graphical representation of principles, concepts, and best practices that describe an entity or process. The two MSF models are team and process. See also principle, concept, and proven practice.
MOF
See Microsoft Operations Framework.
MSF
See Microsoft Solutions Framework.
objectives
What a project team wants to achieve in the long term. They usually are linked with goals. See also goals.
operations
The IT organization responsible for ongoing operation of the solution after delivery.
performance level
In the context of the MSF Readiness Management Discipline: ability, or the expected results from capable execution.
phase
A distinct division within a process model or solution life cycle, typically culminating in a major or external milestone, or representing a fundamental transition in the development of a product or service. The MSF Process Model has five phases. Activities or tasks within each phase occur sequentially, with demarcations between phases, although some overlap may occur.
physical design
The third major stage in the design process for a solution in which the project team determines how to specifically implement the logical design. 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.
physical environment
The geographic and workspace layout and artifacts that affect and support work.
pilot
Introduction of the solution into the production environment, and the trial by installers, systems support staff, and end users.
Pilot Complete Interim Milestone
An interim milestone of the Stabilizing Phase, and the point at which the project team has piloted the solution and determined that it is ready for deployment.
pilot plan
One of several plans that are rolled up into the master project plan. It describes participant profiles and the selection process, pilot scope, number of participants, number of pilots, and pilot feedback mechanisms.
pilot review
A part of the Stabilizing Phase that follows the pilot implementation. A pilot review compiles and evaluates pilot data, identifies frequently-experienced user errors, and selects one of several strategies for moving forward.
plan
The description of how the solution will be completed.
planned project
A project originating out of a prioritized portfolio and based on the organization's enterprise architecture. See also unplanned project.
Planning Phase
In MSF, the second phase of the five-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 Approved Milestone.
point-in-time trigger
A true or false condition that invokes a contingency plan. An example of a point-in-time trigger is a milestone completed late. See also trigger.
post-milestone review
A formal process followed by the project team reviewing what went right and what went wrong with a project as a way of learning for the future. Sometimes referred to as a postmortem.
postmortem
See post-milestone review.
predecessor task
In project management planning, a task or activity that must start or finish before another, dependent task.
Pre-Production Testing Complete Interim Milestone
An interim milestone of the Stabilizing Phase that focuses on preparing for a pilot release. It indicates the point at which the project team has tested and validated that all of the elements developed to deploy the solution are ready for a pilot release.
process
A collection of activities that yield a result, product, or service that is usually a continuous operation. A series of actions or operations designed to achieve an end.
process control
The process of planning and regulating a process with the objective of performing it effectively and efficiently.
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; 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 through deployment. It is characterized by the use of phases and milestones, iterations, and an integrated approach to building and deploying solutions. The model comprises five distinct phases: envisioning, planning, developing, stabilizing, and deploying the solution into the enterprise.
process model, MSF enterprise architecture
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.
Product Management Role Cluster
One of six team role clusters (roles) in MSF, this role cluster leads 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.
proficiency
In the context of the MSF Readiness Management Discipline: the measure of ability to execute the tasks associated with a particular competency.
program
A group of related projects, managed in a coordinated way. Programs usually include an element of ongoing work.
Program Management Role Cluster
One of six team role clusters (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 solution or 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.
program manager
The title for a person holding the program management role in an MSF team or the head (in name only) of a large IT (or other) program involving several projects, ongoing projects, or other complex management activities. See also Program Management Role Cluster.
project
A temporary endeavor undertaken to create a unique solution, product, service, or result.
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 Readiness Approved Milestone. These documents 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
Traditionally, an individual responsible for managing a project. In MSF, project management responsibilities are generally the domain of the program manager, but are shared among team members on projects that involve more than the core team.
project phase
A collection of logically related project activities, usually culminating in the completion of a major deliverable. The MSF Process Model for building and deploying IT solutions defines five phases.
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. In MSF, individual project plans are combined into the master project plan. See also master project plan.
Project Plans Approved Milestone
In MSF, the second of five major milestones. It represents the culmination of the Planning Phase and indicates that the project team, customer, and key project stakeholders agree on what will be delivered and when.
project risk
The possibility of a negative outcome that is assumed in order to pursue an opportunity for gain in the project. See also risk.
project schedule
The planned dates for performing activities and meeting milestones. The master project schedule integrates and synchronizes individual project schedules and is an important deliverable for the Planning Phase.
project scope
The work performed by the team to deliver certain items in the solution scope. See also scope.
project sponsors
Individuals who initiate and approve a project and its results.
project structure document
A deliverable of the Envisioning Phase that defines the approach the team will take in organizing and managing the project. It includes information on team roles and responsibilities, team member contact information, logistical information, and project processes and approaches such as change control and status reporting. It also clarifies the chain of accountability to the customer and designates the team's points of contact with the customer.
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.
proof of concept
Verification that the infrastructure for a solution is viable in a test lab environment (simulated production environment).
Proof of Concept Complete Interim Milestone
An interim milestone of the Developing Phase at which key elements of the solution have been tested in a simulated version of the production environment to validate the requirements of users and operations staff.
prototyping
The creation of a working model of a new computer system or program for testing and refinement.
proven practices
Techniques, methods, or processes that have been demonstrated to work under real-world conditions.
purchasing and facilities plan
One of several plans that are rolled up into the master project plan. Addresses considerations such as vendor contracts, order processing, pre-configuration, warehousing/staging, receiving/storage, and obsolete equipment disposal for hardware and software, as well as considerations such as building permits, end-user workspace, cabling, power/air conditioning, and the server rooms for physical facilities. See also master project plan.
quiet period
In an MSF solution development project, a period of 15-30 days following deployment when project closeout is initiated. It acts as the baseline for service level agreement negotiation.
regression test
A test that is run after the daily build to verify that code has not regressed in quality. See also coverage testing.
release
A collection of new or changed configuration items that are tested and then introduced into the production IT environment.
release candidate
A build that has been tested and is ready for release to a pilot.
Release Candidates Interim Milestone
An interim milestone in the Stabilizing Phase. Each release candidate is prepared and released to the pilot group and represents an interim milestone. Release candidates continue until testing determines that one meets all of the acceptance criteria for release to the pilot.
release candidate testing
Determining whether a candidate solution or product build is suitable for release.
Release Management Role Cluster
One of six team role clusters (roles) in MSF. Release Management is responsible for ensuring that released solutions are deployed smoothly and are manageable and supportable in the future. An externally focused role, it represents the operations viewpoint within the team and functions as a liaison between the development and operations groups. It encompasses five functional areas of responsibility: infrastructure, support, operations, logistics, and commercial release management.
Release Readiness Approved Milestone
In the MSF Process Model, the Release Readiness Approved Milestone is the culmination of the Stabilizing Phase and occurs when the team has addressed all outstanding issues, has completed a pilot review, achieved release-ready versions of source code and executables, scripts and installation documentation, end-user help and training materials, operations documentation, and release notes. The team demonstrates its readiness to move on to the Deploying Phase of the project at this major milestone.
requirement, business
A type of high-level requirement. Business requirements represent the functional needs of the business that are the core reasons for initiating the project. They can also be thought of as the benefits that project sponsors and stakeholders must receive from the solution. See also conceptual design.
requirement, high-level
A requirement that the solution must meet that focuses on business requirements. These requirements provide input for creating the solution concept and form part of the criteria for evaluating the vision/scope.
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.
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.
risk
See project risk.
risk acceptance
One of several alternative approaches in the risk action 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 action plan
A document that organizes such risk management approaches as research, avoidance, transfer (to other projects or teams), mitigation, contingencies, and acceptance.
risk analysis
The process of transforming the estimates or data about specific project risks identified during step one of the risk management process into a form that the team can use to make decisions around prioritization.
risk assessment document
A consolidation of the teams risk management output in a single document.
risk avoidance
Controlling a risk by changing the scope of the project in such a fashion as to eliminate the risk altogether or protect the project objectives from its impact.
risk classification
A structured approach to risk identification that provides a ready-made list of project areas where risks may reside. It provides a basis for standardized risk terminology the team needs for reporting and tracking risks throughout a project and is critical in creating and maintaining enterprise or industry risk knowledge bases. Risk classification lists are also known as risk categories or risk taxonomies.
risk condition
The first part of the risk statement. It describes an existing project's state of affairs that might lead to a loss.
risk consequence
The second part of the risk statement. It describes an undesirable project event, attribute, or state of affairs that would occur if the risk became certain. See also risk condition.
risk contingency
A pre-designed plan or process for dealing with a realized risk event In order to minimize its impact.
risk control
The process of executing risk contingency plans and their associated status reporting.
risk database
A tool used to store and track individual risk items, plans, and status during a project. See also risk knowledge base.
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 that balances the likelihood of actual loss with the magnitude of the potential loss. It is used by the team to rate and rank risks. It is calculated by multiplying probability by impact. See also risk probability and risk impact.
risk identification
Discovering and recognizing potential problems with the project, as early and frequently as possible throughout the project.
risk identifier
The unique name used to identify a risk for reporting and tracking purposes.
risk impact
An estimate of the severity of adverse effects, or the magnitude of a loss, or the potential opportunity cost if the risk consequences occur. It can be measured in financial terms or with a subjective measurement scale.
risk knowledge base
A formal or informal mechanism by which an organization captures learning to assist in future risk management. It captures risk classifications, definitions, diagnostic criteria, scoring systems, and feedback on the teams experience using them. It is distinct from the risk database. See also risk database.
risk learning
Formalizes the lessons learned and relevant project artifacts and tools and captures that knowledge in reusable form for reuse within the team and by the enterprise.
risk list
Either of two types: "initial," which defines risk according to classification, root cause, condition, consequence, and downstream effect; and "master," compiled after prioritization is complete and exposure is calculated.
risk management
A proactive, formalized process for decision-making and actions to continuously assess what can go wrong in a project, determine what risks are important to address, and implement strategies to deal with those risks.
risk mitigation
In risk management activities, an action that may be taken ahead of time to either prevent a risk from occurring altogether or reduce the impact or consequences of its occurring to an acceptable level.
risk planning
The development of detailed strategies and actions for the project risks that have been judged to be most important, and then prioritizing the risk actions and creating an integrated risk management plan.
risk plans
Plans for actions that address how to prevent a risk from occurring or reduce the likelihood that it will occur and reduce the impact if it does occur.
risk prioritization
The ranking of risks in order of their overall threat to the organization and, therefore, their priority for action. See also risk impact.
risk probability
A measure of the likelihood (between zero and 100 percent) that the state of affairs described in the risk consequence portion of the risk statement will actually occur. See also risk impact and risk exposure.
risk reporting
The process of making sure that the team, sponsor, customer, and other stakeholders are aware of the status of project risks and the plans to manage them.
risk review
A part of the risk learning process. A risk review ensures that all learning is captured.
risk scheduling
The integration of the tasks required to implement the risk actions plans into the project schedule by assigning them to individuals. Incorporating these tasks within the standard day-to-day project management process and infrastructure ensures that risk management is carried out as part of the day-to-day activities of the team. Risk scheduling explicitly connects risk planning with project planning.
risk source
A broad classification of the underlying area from which a risk originates, it is used to identify areas where recurrent root causes of risk should be sought. People, process, technology, and external sources represent four main risk sources for projects and include such examples as customers, politics, budget, requirements, security, laws, and competition.
risk statement
A condition-consequence statement that helps to clearly articulate risk by expressing a causal relationship between a real, existing project state of affairs or attribute, and a potential, unrealized second project state of affairs or attribute.
risk tracking
Monitors the status of specific risks and the progress in their respective action plans.
risk transference
Shifting the impact of a risk to a third party together with ownership of the response.
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
See role cluster.
role cluster
One of six general categories (program management, development, test, release management, user experience, and product management) of functional areas typically required for MSF projects and defined in the MSF team model. The role cluster groups functional areas that all support the same quality goal for the project. A role cluster is not a job description, and it does not imply any kind of organizational chart. Depending upon the intensity of labor involved and the size of the organization, one person can fulfill the responsibilities of multiple role clusters within an organization, or multiple persons may be needed to fulfill a single role clusters responsibilities. Role cluster and role can be used interchangeably.
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 or to reduce the number of individuals needed on a project team by combining roles.
scale up
To expand the scope of a project or plan or to use feature and/or function teams to adopt the MSF team model to projects that are too large or complex to be handled by a core team.
scenario
A single sequence of interactions between objects or between objects and actors. It is a particular instance of a use case.
scenario, as-is
A usage scenario existing before the solution is implemented.
scenario, to-be
A usage scenario after the solution implementation.
schedule
The set of data that describes when the project tasks will be completed by applying resources and task durations in sequence. Also, in relation to the trade-off triangle, one of its three sides, the other two being resources and features. It means time.
scheduling for an uncertain future
A principle of good scheduling that recognizes that the future is uncertain and requires the creation of schedules that can adjust to the unexpected. It represents a specific instance of the foundational principle, "stay agile, expect change."
scope
The parts of the vision for the solution that can be accomplished within the constraints of a given version. Negotiating the scope of a project balances customer needs and desires against technological and business constraints. See also solution scope and project scope.
Scope Complete Milestone
The third of five major milestones in the MSF Process Model, representing the culmination of the Developing Phase. It indicates that all features have been completed and the solution or 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 plan
One of several plans that are rolled up to form the master project plan. Its goal is to eliminate the chance of loss of data, denial of access to a resource, or compromise of data, resources, and services for the solution. It describes how established security guidelines will be implemented, what actions will be taken to mitigate any risk in the absence of established security guidelines, and what interim security measures will be taken if established security measures conflict with the successful completion of the project. See also master project plan.
self-assessment
A procedure whereby individuals assess their own level of proficiency. Self-assessment requires individuals to measure their own ability scale, ranging from familiarity to expert levels.
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 completeness: a service provides a direct business value, whereas a component cannot.
service level agreement (SLA)
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.
shared project vision
An MSF foundational principle, advocated as a necessary characteristic of a successful MSF team and built into the Envisioning Phase of the MSF Process Model. It means that all team members as well as the customer clearly understand project goals and objectives and accept them. It is important because it provides the team a uniform sense of purpose, resolves conflicting and contradictory visions, and ensures that team members are working toward the same goal. It also provides a way to measure success.
showstopper
An issue important enough to jeopardize a ship date or schedule date.
Site Deployments Complete Interim Milestone
The point during the deployment phase at which the project team has deployed the selected technology at all the sites and all targeted users have access to the solution. Each site owner has signed off that their site is operating. This interim milestone is not applicable to projects such as Web development projects that do not involve client-side deployments.
skills
In the context of the MSF Readiness Management Discipline, the behaviors or abilities comprising competencies.
skills assessment
An evaluation of the actual expertise of an individual. It requires individuals to respond to specific, often technical, questions to show their knowledge, perform specific tasks, and to demonstrate analysis abilities.
smoke test
The testing of a piece of hardware after assembly or repairs by turning it on. The device fails the test if it produces smoke, explodes, or has some other unexpected violent or dramatic reaction, even if it appears to work.
solution
The coordinated delivery of the elements needed (including technologies, documentation, training and support) to successfully respond to a unique customers business problem or opportunity.
solution concept
A high-level description of how the solution will meet goals and requirements. Includes an early description of functionality, an initial approach to building and delivering the solution, and project success factors and acceptance criteria.
solution design document
A component of the functional specification that contains technology-specific and solution-specific information that will enable the team to move forward with project planning and schedule deployment activities.
solution scope
The sum of the products and services to be provided as a solution. See also scope.
source code and executables
A deliverable of the Developing Phase. These represent the physical reality of the solution or product itself.
sources of risk
See risk sources.
sponsor
Individuals who initiate and approve a project and its results.
Stabilizing Phase
The fourth of the five 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 Readiness Approved Milestone, at which point the solution is ready for full deployment to the live production environment and responsibility for ongoing management and support of the solution begins to shift to the operations and support teams. This shift is complete at the end of the Deploying Phase.
stakeholder
A person with a significant interest in the outcome of a project. A business unit vice president is an example of a stakeholder.
stakeholder map
A diagram that shows the political relationships of stakeholder groups and individuals to one another and identifies the change roles (sponsor, agent, recipient, advocate) that each entity is playing.
step
The smallest level of action that cannot be reduced any further.
strategic project
A project that is critical to sustain future business opportunity for a company. This project classification is part of a definition process that is useful in determining skill requirements for a project.
sub-team
A smaller team created from a larger team for the purposes of faster implementation and lower overhead in the areas of process, management, and communication. Sub-teams also allow a focus upon a particular capability. A core MSF team will coordinate and synchronize sub-teams.
successor task
In project management planning, a task or activity that depends upon the completion of another task and that must start or finish after it.
support project
A project that is valuable but not critical to overall success of a business. This project classification is part of a definition process that is useful in determining skill requirements for a project.
synchronization
Aligning tasks in the correct order to ensure the proper sequencing of activities.
system
An integrated composite that consists of one or more of the processes, hardware, software, facilities, and people that provide a capability to satisfy a stated need or objective.
task
A generic term for work that is not included in the work breakdown structure (WBS), 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 lead
A member of a project sub-team who has project management responsibilities. The sub-team collectively represents a team role or team role cluster within an MSF or MOF 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. The team model is scalable up and down for large and small projects, respectively. In MSF, the team role clusters are Program Management, Product Management, Development, Test, Release Management, and User Experience. In MOF, the team role clusters are Release, Operations, Support, Partner, Infrastructure, and Security.
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 role clusters (roles)
The six divisions of the MSF team model, including product management, program management, development, user experience, test, and release management.
Technology Validation Complete Interim Milestone
The point during the Planning Phase at which the project team has evaluated the products or technologies to ensure that they work according to the vendors specifications.
Test Role Cluster
One of six MSF team role clusters (roles). 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 for the solution. The test role also has the responsibility to accurately portray the status of the solution at any time by determining and clearly documenting what is currently wrong and right with the solution.
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. It is critical, however, to keep it separate from the production environment.
test plan
One of several plans that are rolled up into the master project plan. It is developed by the test role and outlines the strategy the team will use to test the solution. It specifies the specific types of tests to be used, areas to be tested, test success criteria, the resources (both hardware and people) required for testing, and procedures for change control, configuration management, and issue and bug tracking. See also master project plan.
threshold trigger
A true or false condition that invokes a contingency plan. An example of a threshold trigger is a bug count reaching a certain number. See also trigger.
top n risk list
An identification of the n top priority risks taken from the risk assessment document.
traceability
The capability of being tracked backward to origination point.
trade-off matrix
A technique for managing project trade-offs by portraying them in a matrix that shows three project constraints in the context of three indications of their priority—fixed, chosen, or adjustable. Fixed constraints are essentially unchangeable, chosen constrains are desired priorities, and adjustable constraints can be adjusted to accommodate fixed and chosen constraints. Early in the project the team and customer agree about the default priorities for tradeoff decisions. See also trade-off triangle.
trade-off triangle
A triangle of project variables whose three sides are resources (people and money), schedule (time), and features (the solution or 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 solution 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.
training plan
One of the plans that is rolled up into the master project plan. Includes information on the schedule and funding of training, availability of skilled training development and delivery resources, and impact of the solution on end users and network administrators. See also master project plan.
trigger
In the Risk Management Discipline, a measurement threshold that indicates that a risk 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. Sometimes called risk symptoms or warning signs, triggers are monitored as part of the track and report step in the risk management process. See also point-in-time trigger, threshold trigger, and events trigger.
trigger, risk contingency
The criterion for executing a contingency plan.
unit test
A type of test that is done to discover bugs before a build. See also coverage test.
unplanned project
A project that originates in response to unexpected changes, problems, or opportunities within an organization. See also planned project.
usability
The ease and adaptability with which a solution or product can be applied to the performance of the work for which it is designed. A high degree of usability implies ease of learning, flexibility, freedom from bugs, and good design that does not involve unnecessarily complicated features.
usability test
A test that measures a solution's usability from the user's perspective. Ordinary users perform tasks in a lab environment where they are observed by tests. Aspects of usability, such as how many clicks are required to accomplish a task, or how different Web page designs help or hinder attempts to find information, are tested.
usage scenario
Descriptions of the tasks that users perform to accomplish their work.
usage testing
Testing that is performed to ensure that the solution works in the environment for which it is intended. It focuses on testing the solution as users and operations staff would use it. Includes configuration, compatibility, stress, performance, documentation, help file, and usability tests. It occurs primarily during the Stabilizing Phase. See also coverage testing.
use case
A part of a usage scenario that is broken down to the task level.
user
The person who uses the solution or services on a day-to-day basis. Individuals or systems that directly interact with the solution.
User Acceptance Testing Complete Interim Milestone
An interim milestone of the Stabilizing Phase. It indicates that users have tested and accepted the release in a non-production environment and verified that the system integrates with existing business applications and the IT production environment.
User Experience Role Cluster
One of six MSF team role clusters (roles). It represents the end user and is responsible for optimizing the end users 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 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 that focuses on the solution to the business problem; its fulfillment is necessary for day-to-day performance of work processes.
version
One of a number of sequential forms in which a solution or product is released. Early versions of the solution or product contain core functionality and later versions, which add new features, are created as long as they add value. See versioned release strategy.
versioned release strategy
A time and resource control strategy in which a project is treated as if it were a series of versioned product releases. This strategy allows the team to deliver a solution within the expected time frame by providing the most critical functionality in the first version and postponing other desirable features until later releases.
versioning
Providing the most critical functionality for a solution or 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 in a solution.
vision statement
A statement that expresses the long-term vision of the solution and provides a context for decision-making. A deliverable of the Envisioning Phase in the MSF Process Model.
Vision/Scope Approved Milestone
The first of the major milestones in the MSF Process Model 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 Baselined Interim Milestone
An interim milestone of the Envisioning Phase at which the first draft of the vision/scope document has been completed and is circulated among the team, customer, and stakeholders for review.
vision/scope document
The primary deliverable for the Envisioning Phase. It expresses project goals and constraints as a business case.
WBS
See work breakdown structure.
willingness to learn
A key concept that describes an attribute of a successful project team. It means committing to self-improvement through gathering and sharing knowledge and institutionalizing learning through such techniques as reviews and post-milestone reviews. It is important because it allows team members to benefit from mistakes, helps team members to break away from old ways of doing things when change is called for and to repeat successes, and it mandates time for the team to learn. It is closely related to the foundational principles learn from all experience and stay agile, expect change.
work
The resources expended in a project multiplied by the duration of the project.
work breakdown structure
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 resource
The personnel and equipment required to perform project activities.
Zero Bug Bounce Interim Milestone
An interim milestone in the Stabilizing Phase that indicates the first specific moment in the project when there are no active bugs.
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; rather, it establishes perfection as a consistent goal for which to strive. It is important because it increases solution or product stability, schedule predictability, and accountability.
Download
Get the UNIX Migration Project Guide
Update Notifications
Sign up to learn about updates and new releases
Feedback