• Version, date, or revision history indicating maintenance of the policies over time.

• Repository of policies (e.g., intranet web access) making them visible and accessible to the organization
• Mapping of policies to CMMI process areas
• Organizational process architecture, e.g., linkage of policies, processes, procedures
• Signature of policies by authorized senior manager
• Audit results for implementation of the policies

• In general, senior management is responsible for establishing and communicating guiding principles, direction, and expectations for the organization.
• Policies should demonstrate management commitment and establish expectations for the processes to be performed
• Terms other than "policy" may be used in the organizational context
• Policies need not unique to each Practice Area, one policy may cover multiple Practice Areas.
• Not all practices need to be explicitly mentioned, this might be implicitly required by invoking applicable processes and procedures. However, the linkage between Practice Areas, policies, and processes should be discernable to ensure coverage.
• Policies should be visible to those in the organization that are affected, recognizing that most staff do not typically deal with the policies on a daily basis, but rather the processes that comply with the policies.
• Policies could exist at multiple levels within the organization (e.g. corporate, division, department, etc.)
• A documented and approved waiver to the policy does not offset the existence of the generic practice.

• Using the project's defined process and collaborating with relevant stakeholders
• establishes organizational expectations for using Integrated Product and Process Development concepts for carrying out the objectives of the organization.

• Identifying, analyzing, and selecting suppliers; and for monitoring supplier processes, work products, and performance
• analyzing and managing risks relevant to potential sources and the project-supplier relationship.

• Objectively evaluating whether processes and associated work products adhere to the applicable process descriptions, standards, and procedures, and ensuring that noncompliance is addressed
• Process and product quality assurance being in place for all projects.

• Documented plan for performing the process.
• Revisions to the plan, as necessary.

• Documented requirements and objectives for the process (e.g., quality, cost, schedule).
• Documented process descriptions, including standards and procedures; this may be included as part of the plan or by reference.
• Schedules and resources (funding, people, tools) established for performing the process.
• Measures tracking and controlling progress of the plan.
• Evidence of review and agreement to the plan by relevant stakeholders (e.g., signature, approval, meeting minutes).

• More detail is provided in the Project Planning Practice on what is expected and typical plan contents^N
• Establishing a plan includes documenting the plan and providing a process description. Maintaining the plan includes changing it as necessary, in response to either corrective actions or to changes in requirements and objectives for the process. It is permissible for the plan not to have changed if none of these conditions have occurred.
• The plan for performing the process may be a standalone document, embedded in a more comprehensive document, or distributed across multiple documents. It may be part of the project plan established in the Project Planning Practice Area.
• This practice establishes the plans for performing the process, which are implemented in Practices 2.3 through 2.10 in accordance with the plan.

• Recognize this is a plan for the project planning activities, i.e., how will the planning get done? This is often done during proposal or project start-up.

• This plan for performing the project monitoring and control process is typically a part of the project plan, as described in the Project Planning process area.

• Typically, portions of this plan for performing the supplier agreement management process are a part of the project plan as described in the Project Planning process area. Often, however, some portions of the plan reside outside of the project with an independent group, such as contract management.

• plan for the project process tailoring activities, i.e., how will the tailoring get done? This is often done during proposal or project start-up
• planning for how the project will be managed in an integrated way.
• Typically this plan for performing the integrated project management process is a part of the project plan as described in the Project Planning process area.

• Typically this plan for performing the risk management process is included in (or referenced by) the project plan, which is described in the Project Planning process area. The plan for performing the risk management process differs from both the risk management strategy and the risk mitigation plans described in the specific practices in this process area. The plan called for in this generic practice would address the comprehensive planning for all of the specific practices in this process area, from determining risk sources and categories all the way through to the implementation of risk mitigation plans. In contrast, the risk mitigation strategy called for in one specific practice would address the project-specific risk strategy for things such as risk sources, thresholds, tools, and techniques, and would monitor time intervals. The risk mitigation plans called for in another specific practice would address more focused items such as the levels that trigger risk-handling activities.

• Typically, this plan for performing the integrated teaming process is a part of the project plan as described in the Project Planning process area

• Typically, this plan for performing the integrated supplier management process is a part of the project plan as described in the Project Planning process area.

• See Project Planning Practice Area
• Quantitative Project Management Plan.

• Typically, this plan for performing the quantitative project management process is included in (or referenced by) the project plan, which is described in the Project Planning process area.

• This plan for performing the organizational process focus process, which is often called "the process-improvement plan," differs from the process action plans described in specific practices in this process area. The plan called for in this generic practice addresses the comprehensive planning for all of the specific practices in this process area, from the establishment of organizational process needs all the way through to the incorporation of process-related experiences into the organization's process assets.

• Typically this plan for performing the organizational process definition process is a part of the organization's process-improvement plan.

• This plan for performing the organizational training process differs from the tactical plan for organizational training described in a specific practice in this process area. The plan called for in this generic practice would address the comprehensive planning for all of the specific practices in this process area, from the establishment of strategic training needs all the way through to the assessment of the effectiveness of the organizational training effort. In contrast, the organizational tactical training plan called for in the specific practice would address the periodic planning for the delivery of individual training offerings.

• This plan for performing the organizational process performance process may be included in or referenced by the organization's process-improvement plan, which is described in the Organizational Process Focus process area, or it may be documented in a separate plan that describes only the plan for the organizational process performance process.

• This plan for performing the organizational innovation and deployment process differs from the deployment plans described in a specific practice in this process area. The plan called for in this generic practice would address the comprehensive planning for all of the specific practices in this process area, from collecting and analyzing improvement proposals all the way through to the measurement of improvement effects. In contrast, the deployment plans called for in the specific practice would address the planning needed for the deployment of individual process and technology improvements.

• Typically this plan for performing the requirements management process is a part of the project plan as described in the Project Planning process area.

• Typically this plan for performing the requirements development process is a part of the project plan as described in the Project Planning process area.

• Typically, this plan for performing the technical solution process is a part of the project plan as described in the Project Planning process area.

• Integration sequence, schedules, budgets, and resources

• This plan for performing the product integration process addresses the comprehensive planning for all of the specific practices in this process area, from the preparation for product integration all the way through to the delivery of the final product.

• Typically, this plan for performing the verification process is included in (or referenced by) the project plan, which is described in the Project Planning process area

• Typically, this plan for performing the validation process is included in (or referenced by) the project plan, which is described in the Project Planning process area

• This plan for performing the configuration management process can be included in (or referenced by) the project plan, which is described in the Project Planning process area

• This plan for performing the process and product quality assurance process may be included in (or referenced by) the project plan, which is described in the Project Planning process area

• Typically, this plan for performing the measurement and analysis process is included in (or referenced by) the project plan, which is described in the Project Planning process area

• Typically, this plan for performing the decision analysis and resolution process is included in (or referenced by) the project plan, which is described in the Project Planning process area

• This plan for performing the organizational environment for integration process may be included in or referenced by the project plan, which is described in the Project Planning process area, or it may be documented in a separate plan that describes only the plan for the organizational environment for integration process.

• This plan for performing the causal analysis and resolution process differs from the action proposals and associated action plans described in the specific practice in this process area. The plan called for in this generic process would address the organization's overall causal analysis and resolution process. In contrast, the process action proposals and associated action plans address the activities needed to remove the root cause under study

• Documented process descriptions and plans (strategic or tactical) for performing the process, which include a characterization of resources needed. (see Generic Practice 2.2 Plan Process).
• Evidence that adequate resources (funding, facilities, skilled people, tools, etc.) are actually provided as planned.

• Staffing profiles and labor reports showing effort spent on performing the process.
• Documented skill prerequisites for filling process roles and responsibilities, and evidence that assigned staff meet these criteria.
• Development environment and facilities (hardware, software, licenses, tools, labs, test equipment, etc.).
• Cost performance measures showing provision of funding in accordance with the plan.
• Analyses, reports, or metrics tracking availability of resources vs. plan.

• Ensure the resources necessary to perform the process as defined by the plan are available when they are needed.
• Resources include adequate funding, appropriate physical facilities, skilled people, and appropriate tools."
• The interpretation of the term 'adequate' depends on many factors and may change over time." Adequacy is subjective, and most likely determined through affirmations of sufficiency from those performing the work. Listen also for cases where the process failed due to insufficient resources. This may indicate weaknesses in the plan or in the implementation.
• Care should be taken in relying on affirmations of "inadequate" resources. A performer often wishes they had more time, money, or tools, but still has "adequate" resources to accomplish their planned tasks.
• Separate budgets are not needed for each PA; they may be distributed over several PAs. A key consideration is whether the manager of that process has sufficient visibility to recognize the need for more resources.

• Tools: spreadsheet programs; estimating models; project planning and scheduling packages, historical project performance database; data analysis and graphing tools; risk database; office automation tools; desktop publishing tools
• Staff: experienced estimators; schedulers; technical experts in application domain and technologies]

• Look for a basic set of project planning and management tools, with historical data repositories used to calibrate and validate estimates

• Tools: cost tracking systems; effort reporting systems; action item tracking systems; project management and scheduling programs, problem tracking packages; measurement collection, analysis, and reporting tools; risk database; office automation tools, project planning and scheduling tools; estimating models; spreadsheet programs; historical project performance database

• Tools: preferred supplier lists; requirements tracking programs; project management and scheduling programs, research and reference libraries of vendors and COTS products; supplier database; COTS product licenses; action item database
• Facilities: secure repositories for limited access to source selection data
• Staff: domain experts in applications and technologies being acquired

• Sometimes engineering staff are assigned subcontractor oversight as a secondary task, in addition to their primary assignment. Ensure that assigned staff have adequate time to perform their role in this process area effectively

• Tools: see PP and PMC GP PIIDs for planning and management tools that might be relevant (e.g. estimation and scheduling tools; analysis tools; cost / effort tracking and reporting systems,

  coordination: problem tracking and trouble reporting packages; groupware; video conferencing; email; integrated decision database; integrated product support environments

• Tools: risk management databases; risk mitigation tools; prototyping tools; modeling and simulation tools, risk analysis and reporting tools
• Funding: budget or percentage of management reserve available for risk mitigation
• Staff: risk manager or risk champion; risk review board

• At Maturity level 3, there should not only be a plan and set of identified risks, but budget available for proactive mitigation of risks

• Facilities: team war rooms, available conference rooms; projection equipment; video teleconferencing equipment
• Tools: groupware tools for electronic communication and data presentation

• Ability to evaluate potential sources and select suppliers
• supplier management, including appraising a supplier's planning documents, processes, work products, and services
• risk management
• the domain of the product being acquired
• current engineering processes, work products, verification methods, technology, costing methodologies, and tools

• Staff: expertise in statistics and statistical process control]
• Tools: system dynamics models; automated test coverage analyzers; statistical process control tools; quality control packages; statistical analysis packages, measurement repository; process asset library; defect and problem reporting database; data reduction and graphical analysis tools

• Look for funding allocated to the measurement function responsible for quantitative analysis.

• Tools: DBMS; process improvement tools; web page builders and browsers; groupware; quality improvement tools (e.g., cause-and-effect diagrams, affinity diagrams, Pareto charts, assessment tools)
• Financial: Budgets, resources, and staff allocated to process assessment, improvement, and deployment of process action plans, percentage of the overhead budget allocated to process improvement; provision of engineering staff for process action teams.
• People: process group staffing level and percentage relative to the engineering population; organizational steering group responsible for providing long-term commitment and resources
• Org chart depicting role and reporting of the process group and process owners, with representation across disciplines.

• The responsibility of facilitating and managing the organization's process improvement activities is typically assigned to a process group. The organization provides the long-term commitment and resources required to sponsor this group.
• Staffing of the process group need not be on a full-time basis, but should reflect organizational commitment
• Look at staffing and funding commitments not only for the process group, but also for making staff available to work on process improvement or process action teams.

• Tools: DBMS, process modeling tools, web page builders and browsers, historical project performance database; data analysis and graphing tools; risk database; office automation tools; desktop publishing tools, measurement repository; process asset library
• Financial: Budgets, resources, and staff allocated to definition and support of organizational processes
• Org chart depicting role and reporting of the process group and process owners, with representation across disciplines.
• Document repository containing published process documentation and assets.

• A process group typically manages the OPD activities…. This group is supported by process owners and people with expertise in various disciplines.

• Funding: budget allocated to training and development
• Staff: subject matter experts; curriculum designers; instructional designers; instructors; training administrators]
• Facilities: training rooms, labs, instructional resources
• Tools: training needs analysis tools; workstations; instructional design tools; packages for developing presentation materials, training repository; training records database; skills database; collaborative environments; bulletin boards

• Look for provision of instructors with the experience and qualifications necessary to facilitate effective learning.
• Consider resources for both formal and informal training and development, orientation, or support (e.g., mentoring programs)
• Consider resources such as sponsored luncheon forums, brown bag presentations, vendor demos, video tapes, CBT, self-study, etc.

• Tools: DBMS; system dynamic models; process modeling tools; statistical analysis packages; problem tracking packages, estimation tools
• Staff: statisticians; measurement analysts

• Special expertise in statistics and statistical process control may be needed to establish the performance baseline of the organization's set of standard processes

• Tools: simulation packages; prototyping tools; statistical packages; dynamic systems modeling; subscriptions to online technology databases; process modeling tools, piloting environments and test beds; process performance database; measurement repository
• Resources: research and reference libraries

• Tools: requirements tracking tools; traceability tools

• Staff: expertise in application domain, eliciting stakeholder needs, methods and tools for analyzing requirements

  access to end users, domain experts; working group

• Tools: requirements specification tools; simulators and modeling tools; prototyping tools; scenario definition and management tools; requirements tracking tools, use case tools; requirements tracking tools; traceability tools; reverse engineering tools

• Tools: design specification tools; simulators and modeling tools; prototyping tools; scenario definition and management tools; requirements tracking tools; interactive documentation tools.

  number of licenses for development tools

• Staff: Interface Control Working group
• Facilities: assembly and delivery facilities
• Tools: prototyping tools; analysis tools; simulation tools; interface management tools; assembly tools (e.g., compilers, make files, joining tools, jigs, fixtures)

• Tools: test management tools; test case generators; test coverage analyzers; simulators; emulators; scenario generators; data reduction tools; environmental controls; interface tools; special test equipment
• Facilities: special tools, equipment, facilities, e.g., meeting rooms
• Staff: trained staff, e.g. peer review moderators, equipment operators

• Facilities: special facilities for validating the product and product components
• Tools: test management tools; test case generators; test coverage analyzers; simulators; load, stress, and performance tools
• Staff: skilled operators

• Tools: configuration management tools; data management tools; archiving and reproduction tools; database programs

  change request systems; configuration control, status, auditing, and reporting tools

• Staff: configuration control board

• A measurement group may exist to support measurement activities across multiple projects.

• Tools: evaluation tools; noncompliance tracking tool.

• Staff: measurement personnel
• Tools: statistical packages; data collection tools, automated measurement collection tools; data analysis tools; measurement repository

• Tools: simulators and modeling tools; prototyping tools; tools for conducting surveys

• Facilities: manufacturing and production facilities; prototyping equipment; work space; office equipment and supplies; raw materials; transportation resources; help desk; information brokerage services; support staff and/or services
• Tools: communications systems; computer resources; simulation tools; engineering tools; information-technology capabilities

• Tools: database systems; process modeling tools; statistical analysis packages; tools, methods, and analysis techniques (e.g., Ishakawa or fishbone diagram, Pareto analysis, histograms, process capability studies, control charts).

• Documentation assigning responsibility for process activities, work products, or services; e.g., job descriptions, or plans for performing the process (see Generic Practice 2.2 Plan Process).
• Task descriptions and activities for defined roles.

• Acceptance of responsibility by those assigned; this might be documented in many ways (e.g., signature, commitment, agreement, appearance on an org chart, web page contacts, etc.)

• ensure that there is accountability throughout the life of the process for performing the process and achieving the specified results. The people assigned must have the appropriate authority to perform the assigned responsibilities."
• Responsibility assignments may be to individuals or groups, and may vary across the life of the process.
• Ensure that the people assigned are available to do the work.
• Assignments may be defined in various ways; e.g., work authorizations, job descriptions, project plans.
• Many PAs will have the various goals/practices assigned to different people; make sure the entire PA has been assigned.

• Assignments are often in the project plan

• Look to make sure planning activities are assigned at each appropriate level (e.g. project managers, team leaders)

• Assignments are often in the project plan

• Look to make sure planning activities are assigned at each appropriate level (e.g. project managers, team leaders)

• Assignments are often in the project plan, or a supplier management plan

• Responsibility is often distributed within an organization (e.g. between project personnel and a subcontracts or purchasing group)

• Assignments are often in the project plan

• It may be a different set of people who initially set up the project than those who are responsible for ongoing project management
• Look for coverage of responsibility for coordination with stakeholders as in SG2. These assignments may vary on a per stakeholder basis.

• Assignments are often in the project plan or a risk management plan.

• Look to make sure risk management activities are assigned at each appropriate level (e.g. project manager, team leaders)
• Responsibility may be assigned to an individual or group (e.g., risk review board)

• Assignment is often in the project plan
• Criteria for team member selection and skill mix
• Org chart depicting team relationships and interfaces
• Minutes or products from team building

• The sponsor of an integrated team is a person or group (e.g., project manager or even another integrated team) who can assign work tasks and provide resources

• Assignment is often in the project plan

• Assignment is often in the project plan
• Process group minutes (at the organizational or project level)
• Process improvement action plans (containing responsibilities)

• Project management, along with the organization's or project's process group is likely to be responsible for the overall implementation of this PA, but the expertise of a statistician may also be needed.
• Consider also the relationship between QPM and OPP, and allocation of responsibility between the organizational and project groups.

• Process group minutes
• Steering committee presentations or minutes
• Process appraisal minutes or report
• Process improvement action plans (containing responsibilities), reviews, and reports
• Process improvement charter statements or organization chart (e.g., management steering group, process group)

• Two groups are typically established and assigned responsibility for process improvement - a management steering committee for process improvement to provide senior-management sponsorship; and a process group to facilitate and manage the process-improvement activities.
• Other groups may be sponsored or formed to implement process improvement tasks (e.g., process action teams, appraisal teams). (see Practices 2.1 and 2.2-1)

• Process group minutes
• Process improvement action plans (containing responsibilities), reviews, and reports
• Process improvement charter statements or organization chart
• Custodians identified for web pages or repositories.

• A process group typically manages the OPD activities…. This group is supported by process owners and people with expertise in various disciplines (Generic Practice 2.3)
• The "establishers" may be a different group of people than the "maintainers". Process action teams may involved in the initial creation of assets.
• There will likely be a senior management sponsor for these activities

• Organization-level training plan (containing responsibilities)
• List of instructors or coordinators identified for training courses
• Charter statements for training responsibilities
• Minutes or presentations indicating participation in training status reviews

• There will likely be a senior management group responsible for defining the strategic and tactical needs separate from the training group responsible for developing / delivering the training and maintaining the records
• There may be an organizational training group responsible for coordination, delivery, record collection, etc. This may be a responsibility assigned to the HR organization.

• Process group minutes
• Process improvement action plans (containing responsibilities)
• Charter statements

• A Process group is likely to be responsible for the overall implementation of this Practice Areea, but the expertise of a statistician will be useful.

• Process group minutes
• Process improvement action plans (containing responsibilities)
• Charter statements

• A Process group is likely to be responsible for the overall implementation of this Practice Areea, but the expertise of a statistician will be useful.

• Assignment is often in the project plan

• Look to make sure requirements management activities are assigned at each appropriate level (e.g. system, subsystem, unit)

• Assignment is often in the project plan

• Look to make sure requirements development activities are assigned at each appropriate level (e.g. system, subsystem, unit)

• Assignment is often in the project plan

• Look to make sure technical solution activities are assigned at each appropriate level (e.g. system, subsystem, unit)

• Assignment is often in the project plan

• Look to make sure product integration activities are assigned at each appropriate level (e.g. system, subsystem, unit)

• Assignment is often in the project plan

• Look to make sure verification activities are assigned at each appropriate level (e.g. system, subsystem, unit)

• Assignment is often in the project plan

• Look to make sure validation activities are assigned at each appropriate level (e.g. system, subsystem, unit)

• Assignment is often in the project plan or configuration management plan

• These activities may be distributed across different groups within the organization (e.g. systems, software, CM group).
• Responsibility may change as development progresses across the life cycle.

• Assignment is often in the project plan or quality assurance plan.

• These activities may be distributed across different groups within the organization (e.g. one group responsible for process quality and another group responsible for product quality.
• "Objective evidence" does not necessarily mean independent evidence.
• A separate quality assurance group is not necessarily required.
• The assigned individuals or groups responsible for this Generic Practice Area may vary for different processes, and assignments may change across the project life cycle.

• Assignment is often in the project plan

• As the organization moves up the capability/maturity scales, the focus of this PA should move from project to organization to quantitative improvement. This may affect the assignment of responsibility at each level.
• These activities may be distributed across different groups (e.g. project personnel and a separate "measurement and analysis" group

• Assignment is often in the project plan

• Look to make sure DAR activities are assigned at each appropriate level (e.g. system, subsystem, unit)

• Assignment is often included in or referenced by the project plan
• Charter statements and functional descriptions for integration of organizational business and technical elements

• Assignment is often in the project plan
• Process group minutes (at the organizational and project level)
• Process improvement action plans (containing responsibilities)

• Project management, along with the organization's process group is likely to be responsible for the overall implementation of this PA, but the expertise of a statistician may also be needed.
• Consider the allocation of responsibility between the project and the organization. CAR activities provide a mechanism for projects to evaluate their processes at the local level and look for improvements that can be implemented." … "When improvements are judged to be effective, the information is extended to the organizational level."

• Training courses, materials, and methods.
• Training records (e.g., attendance, course descriptions, evaluation forms).

• Qualifications and criteria defined for process tasks and assignments.
• Training waiver criteria and approvals.
• Skills matrix or database.
• Training plans, and delivery of training according to the plan.
• Training effectiveness data (e.g., surveys, exams, feedback forms).

• The training provided may be formal (e.g., classroom, CBT) or informal (e.g., structured mentoring), and may vary according to assigned role (e.g. detailed training for those performing the work, orientation overview provided to those who interact or support those performing the work).
• Consider other methods besides formal classroom training that might be used (e.g., CBT, mentoring, videotapes). The method should ensure that skills and knowledge are impacted.
• Recognize that training need not be provided on a PA basis; a single training course could cover multiple processes.
• An approved waiver, stating that an individual possesses the skills and knowledge imparted in the course, is equivalent to having received training.
• It is impractical that 100% of the performers of a process are trained at any point in time, due to new hires, transfers, promotions, etc. Judgment is called for in determining whether an excessive number of people are untrained.

• Mentoring or apprenticeship programs
• Project planning workshops

• Estimating, Budgeting, Negotiating, Risk identification and analysis, Data management, Planning, Scheduling

• Mentoring or apprenticeship programs
• Project planning workshops

• Examples of training topics: Monitoring and control of projects, Risk management, Data management

• Certification in acquisition and contracting regulations

• Regulations and business practices related to negotiating and working with suppliers
• Acquisition planning and preparation
• COTS products acquisition
• Supplier evaluation and selection
• Negotiation and conflict resolution
• Supplier management
• Testing and transitioning of acquired products
• Receiving, storing, using, and maintaining acquired products

• Team building orientation sessions.

• Tailoring the organization's set of standard processes to meet the needs of the project
• Procedures for managing the project based on the project's defined process
• Using the organization's measurement repository
• Using the organizational process assets
• Integrated management
• Intergroup coordination
• Group problem solving
• Building the project's shared vision
• Team building

• Risk management concepts and activities (e.g., risk identification, evaluation, monitoring, mitigation)
• Measure selection for risk mitigation

• Team building orientation

• Use of integrated work environments
• Interpersonal skills
• Communication skills
• Team building
• Collaborative problem solving and decision making.

• Identifying potential sources for candidate products to be acquired
• Acquisition feasibility and product life-cycle costs analysis
• Evaluating supplier work products
• Monitoring supplier processes

• Process modeling and analysis
• Process measurement data selection, definition, and collection.

• Training materials for deploying the process assets and changes to the process assets

• CMMI and other process and process-improvement reference models
• Planning and managing process improvement
• Tools, methods, and analysis techniques
• Process modeling
• Facilitation techniques
• Change management

• CMMI and other process and process-improvement reference models
• Planning, managing, and monitoring processes
• Process modeling and definition
• Developing a tailorable standard process

• Trainer development program
• Orientation on training plans and objectives

• Knowledge and skills needs analysis
• Instructional design
• Instructional techniques (e.g., train the trainer)
• Refresher training on subject matter

• Process and process-improvement modeling
• Quantitative and statistical methods (e.g., estimating models, Pareto analysis, and control charts)

• Planning, designing, and conducting pilots
• Cost/benefit analysis
• Technology transition
• Change management

• Application domain
• Requirements definition, analysis, review, and management
• Requirements management tools
• Configuration management
• Negotiation and conflict resolution

• Application domain
• Requirements definition and analysis
• Requirements elicitation
• Requirements specification and modeling
• Requirements tracking

• Training pertinent to product component operational concepts, scenarios, and environments for all pertinent life-cycle processes (operations, support, manufacturing, verification, deployment/fielding/delivery/disposal)
• Training materials included with support documentation of products.

• Application domain of the product and product components
• Design methods
• Interface design
• Unit testing techniques
• Standards (e.g., product, safety, human factors, environmental)

• Application domain
• Product integration procedures and criteria
• Organization's facilities for integration and assembly
• Assembly methods
• Packaging standards

• Training for specialized verification methods/tools and facilities

• Application domain
• Verification principles, standards, and methods (e.g., analysis, demonstration, inspection, test)
• Verification tools and facilities
• Peer review preparation and procedures
• Meeting facilitation

• Application domain
• Validation principles, standards, and methods
• Intended-use environment

• Roles, responsibilities, and authority of the configuration management staff
• Configuration management standards, procedures, and methods
• Configuration library system

• Application domain
• Customer relations
• Process descriptions, standards, procedures, and methods for the project
• Quality assurance objectives, process descriptions, standards, procedures, methods, and tools

• Training on the appropriate use and understanding of measurement results.

• Statistical techniques
• Data collection, analysis, and reporting processes
• Development of goal-related measurements (e.g.,Goal Question Metric)

• Formal decision analysis
• Methods for evaluating alternative solutions against criteria.

• Work environment development
• Ergonomics
• Leadership policies for IPPD
• Managing people for integration and collaboration

• List of work products identified for configuration management and the level of configuration management for each work product is identified
• Work products that are under configuration management (e.g., work products having version identifiers, change histories)
• Change control documentation (e.g., change requests, problem reports, status reports indicating disposition)
• Baselines and a description of their contents.

• Configuration management life cycle for identified work products, i.e., the point at which products are placed under various levels of control, change control authority, etc.
• Configuration management processes, populated repository, and tools.
• Change Control/Advisory Board meeting minutes
• Written status of work products (e.g., in-work, in review, accepted for baseline, etc.)

• Is enabled by the Configuration Management Practice Area; refer to that PA for additional information on configuration management practices.
• Ensure the work products are controlled and revised in accordance with the documented plans for the PA being examined.
• formality may vary according to the work product (e.g., version control vs. configuration management) - see Generic Practice 2.6 description.
• In examining the work products identified for each Practice Area , "different versions" are recognizable by version labels, distribution dates, change histories, etc.
• Different levels of configuration management are appropriate for different work products and for different points in time. It is the project or organization prerogative to define what level of CM is appropriate for each work product.

• Work breakdown structure
• Project plan
• Data management plan
• Stakeholder involvement plan.

• Project performance data
• Corrective action plans
• Risk item status
• Metrics.

• Statements of work
• Supplier agreements
• Memoranda of agreement
• Subcontracts
• Preferred supplier lists
• Supplier management plan

• The project's defined process
• Project plans
• Other plans that affect the project
• Integrated plans
• Actual process and product measures collected from the project
• Integrated team structure.

• Risk management strategy
• Identified risk items
• Risk mitigation plans.

• List of team members
• List of the level of effort and resources, including access to staff, to perform each team function
• Work task formal commitment lists
• Team shared-vision statement
• Team charter

• Results of the acquisition feasibility and product life-cycle costs analysis
• Supplier agreements
• Discrepancy reports.

• Subprocesses to be included in the project's defined process
• Operational definitions of the measures, their collection points in the subprocesses, and how the integrity of the measures will be determined
• Collected measures.

• Process-improvement proposals
• Approved process action plans
• Training materials for deploying process assets
• Process appraisals.

• Set of standard processes
• Descriptions of the life-cycle models
• Tailoring guidelines for the set of standard processes
• Definitions of the common set of product and process measures
• measurement data.

• Change approval and access mechanisms for maintenance of training records.

• Training tactical plan, records, materials and supporting artifacts
• Instructor evaluation forms

• Quality and process-performance objectives
• Definition for the selected measures of process performance
• Baseline data on process performance.

• Documented lessons learned from pilots
• Revised process- and technology-improvement measures, objectives, priorities, and deployment plans
• Updated training material
• Proposed innovation improvements
• Pilot and deployment plans

• Requirements
• Requirements traceability matrix.

• Requirements of Customer, Product and product-component and Interfacing
• Functional architecture

• Product, product component, process, service, and interface designs
• Technical data packages
• Interface design documents
• Criteria for design and product-component reuse
• Implemented design (e.g., software code, fabricated product components)
• User, installation, operation, and maintenance documentation

• Acceptance documents for the received product components
• Evaluated assembled product and product components
• Product integration sequence
• Updated interface description or agreement.

• Verification procedures and criteria
• Peer review training material
• Peer review data
• Verification reports.

• Lists of products and product components selected for validation
• Validation methods, procedures, and criteria
• Validation reports

• Access lists
• Change status reports
• Change request database
• Change Control/Advisory Board meeting minutes
• Archived baselines.

• Noncompliance reports
• Evaluation logs and reports.

• Specifications of base and derived measures
• Data collection and storage procedures
• Base and derived measurement data sets "
• Analysis results and draft reports
• Data analysis tools.

• Guidelines for when to apply a formal evaluation process
• Evaluation reports containing recommended solutions.

• Guidelines that determine the degree of empowerment of individuals and integrated teams
• Process documentation for issue resolution
• Shared vision

• Action proposals
• Action proposals selected for implementation
• Causal analysis and resolution records

• Documentation showing identification of relevant stakeholders (stakeholder list, involvement matrix, memoranda, plans, distribution lists, Conops, etc.)
• Plans that identify relevant stakeholders and how they are involved.
• Evidence that stakeholders are involved as planned.

• Mechanisms and documentation of relevant stakeholder involvement (e-mail, memoranda, meeting minutes, signature approval, charters, distribution lists, attendance lists, reviews, surveys, reports, web pages, etc.)
• The plan for stakeholder involvement, as specified in the Project Planning PA. This may be part of the project plan.

• The term "relevant stakeholder^N" is used to designate a stakeholder that is identified for involvement in specified activities and is included in an appropriate plan^N.
• The set of relevant stakeholders for each PA may vary across the life cycle or as the organization increases its process capability/maturity.
• The identification and involvement of relevant stakeholders may vary according to project characteristics and attributes (e.g., size, complexity, duration).

• Establishing estimates
• Reviewing and resolving issues on the completeness and correctness of the project risks
• Reviewing data management plans
• Establishing project plans
• Reviewing project plans and resolving issues on work and resource issues.

• Assessing the project against the plan
• Managing corrective actions to closure

  Reviewing:

• commitments and resolving issues
• project risks
• data management activities
• project progress

• Establishing criteria for evaluation of potential suppliers
• Reviewing potential suppliers
• Establishing supplier agreements
• Resolving issues with suppliers
• Reviewing supplier performance.

• Resolving issues about the tailoring of process assets
• Resolving issues among the project plan and the other plans that affect the project
• Reviewing project performance to align with current and projected needs, objectives, and requirements
• Creating the project's shared vision
• Defining the integrated team structure for the project.

• Establishing a collaborative environment for free and open discussion of risk
• Reviewing the risk management strategy and risk mitigation plans
• Participating in risk identification, analysis, and mitigation activities
• Communicating and reporting risk management status.

Establishing and maintaining:
• the team's charter
• the team's operating procedures

• Collaborating with interfacing teams

Resolving issues about:
• Improvements to supplier agreements
• the meaning of the requirements to be fulfilled by the supplied products
• the reporting of performance data and handling of discrepancies.

• Establishing project objectives
• Resolving issues among the project's quality and process-performance objectives
• Appraising performance of the selected subprocesses
• Identifying and managing the risks in achieving the project's quality and process performance objectives
• Identifying what corrective action should be taken.

• Coordinating and collaborating on process-improvement activities with process owners, those that are or will be performing the process, and support organizations (e.g., training staff and quality assurance representatives)
• Establishing process needs and objectives
• Appraising processes
• Implementing process action plans
• Coordinating and collaborating on the execution of pilots to test selected improvements
• Deploying process and changes to process assets
• Communicating the plans, status, activities, and results related to the implementation of process-improvement activities.

• Reviewing the set of standard processes
• Reviewing life-cycle models
• Resolving issues on the tailoring guidelines
• Assessing the definitions of the common set of process and product measures.

• Establishing a collaborative environment for discussion of training needs and training effectiveness to ensure that training needs are met
• Identifying training needs
• Reviewing a training tactical plan
• Assessing training effectiveness.

• Establishing the quality and process-performance objectives and their priorities
• Reviewing and resolving issues on process performance baselines
• Reviewing and resolving issues on process performance models.

• Reviewing process and technology improvement proposals that may have major impacts on process performance or on customer and end-user satisfaction
• Providing feedback on the status and results of the process- and technology-improvement deployment activities

• Resolving issues on the understanding of the requirements
• Assessing the impact of requirements changes
• Communicating the bi-directional traceability
• Identifying inconsistencies among project plans, work products, and requirements.

• Reviewing the adequacy of requirements in meeting needs, expectations, constraints, and interfaces
• Establishing operational concepts and scenarios
• Assessing the adequacy of requirements
• Establishing product and product-component requirements
• Assessing product cost, schedule, and risk.

• Developing alternative solutions and selection criteria
• Evolving operational concept and scenarios
• Obtaining approval on external interface specifications and design descriptions
• Developing the technical data package
• Assessing the make, buy, or reuse alternatives for product components
• Implementing the design.

• Reviewing interface descriptions for completeness
• Establishing the product integration sequence
• Establishing the product integration procedures and criteria
• Assembling and delivering the product and product components
• Communicating the results after evaluation
• Communicating new, effective product integration processes to give affected people the opportunity to improve their performance.

• Selecting work products and methods for verification
• Establishing verification procedures and criteria
• Conducting peer reviews
• Assessing verification results and identifying corrective action,

• Selecting the products and product components to be validated
• Establishing the validation methods, procedures, and criteria
• Reviewing results of product and product-component validation and resolving issues
• Resolving issues with the customers or end users.

• Establishing baselines
• Reviewing configuration management system reports and resolving issues
• Assessing the impact of changes for the configuration items
• Performing configuration audits
• Reviewing the results of configuration management audits.

• Establishing criteria for the objective evaluations of processes and work products
• Evaluating processes and work products
• Resolving noncompliance issues
• Tracking noncompliance issues to closure.

• Establishing measurement objectives and procedures
• Assessing measurement data
• Providing meaningful feedback to those responsible for providing the raw data on which the analysis and results depend.

• Establishing guidelines for which issues are subject to a formal evaluation process
• Establishing evaluation criteria
• Identifying and evaluating alternatives
• Selecting evaluation methods
• Selecting solutions.

Establishing and maintianing:
• the shared vision
• the integrated work environment
• IPPD skill needs
• IPPD leadership mechanisms
• policies for the management of people in an IPPD environment.

• Conducting causal analysis
• Assessing the action proposals.

• Measures of actual performance against plan (e.g., process, work products, and services).
• Progress tracking reports, e.g. status reports, financials, graphs, analyses.
• Evidence of reviews of activities, status, and results of the process held with immediate level of management responsible for the process and identification of issues; (e.g. briefings, reports, presentations, milestones).
• Issues and corrective actions for deviations from plan (e.g., action items, variance reports, change requests).

• Revisions and change history to plans and commitments (e.g., replanned schedule, costs, resources).

• Reviews can be both periodic and event-driven.
• Ensure that corrective actions have been tracked to closure.

^Note

• Effort spent planning the project
• Project planning reviews and action items.

• Number of revisions to the plan
• Cost, schedule, and effort variance per plan revision

• Project risk item status (e.g., open, closed, risk exposure)
• Effort spent managing and monitoring the project.

^Note

• Number of open and closed corrective actions
• Project milestone dates (e.g., planned versus actual and slipped milestones)
• Number and type of reviews performed
• Review schedule (planned versus actual and slipped target dates)

• Effort spent managing suppliers
• Supplier performance rating database
• Supplier award fees
• Number of candidate suppliers evaluated
• Minutes of supplier technical and management reviews
• Measures of supplier product quality

• Number of changes made to the requirements for the supplier
• Cost and schedule variance per supplier agreement

^Note

• Effort expended to manage the project
• Number of changes to the project's defined process
• Number of documented commitments between the project and relevant stakeholders
• Interface coordination issue trends (i.e., number identified and number closed)
• Project's shared vision and effectiveness
• Integrated team-structure usage and effectiveness
• Indicators of shared-vision effectiveness.

• Minutes of risk management status reviews
• Effort spent for risk management activities.

• Number of risks identified, managed, tracked, and controlled
• Risk exposure and changes to the risk exposure for each assessed risk, and as a summary percentage of management reserve
• Change activity for the risk management plan (e.g., processes, schedule, funding)
• Occurrence of unanticipated risks
• Risk categorization volatility
• Comparison of estimated vs. actual risk mitigation effort and impact.

• Action items for resolution of integrated teaming issues
• Minutes of reviews of effectiveness and alignment of shared vision
• Measures indicating status and likelihood for achieving project critical success factors
• Team decision-making matrix
• Stability of inter-team interfaces.

• Performance according to plans, commitments, and procedures for the integrated team, and deviations from expectations
• Ability to achieve team objectives

• Discrepancy reports for supplier products.

^Note

• Effort expended to manage the evaluation of sources and selection of suppliers
• Number of changes to the requirements in the supplier agreement
• Number of documented commitments between the project and supplier
• Interface coordination issue trends (i.e., number identified and number closed
• Quality measures of supplied products.

• Corrective actions to address special causes of variation
• Effort spent for quantitative project management activities
• Minutes from quantitative project management reviews.

• Profile of sub-processes under statistical management (e.g., number planned to be under statistical management, number currently being statistically managed, and number that are statistically stable)
• use of statistically-based methodologies and appraoch such as Six Sigma
• Number of special causes of variation identified

• Process group minutes at which status is reviewed
• Process improvement action plans and task lists.

• Number of process improvement proposals submitted, accepted or implemented
• CMMI maturity level or capability level descriptions

• Change requests and metrics for revisions to the organizational processes and assets.
• Process metrics
• Process database or repository usage indicators.

• Percentage of projects using the process
• architectures and process elements of the set of standard processes
• Defect density of each process element of the set of standard processes

• Training review board records
• Revisions to the training curriculum and materials.

• Number of training courses delivered (e.g., planned versus actual)
• Post-training evaluation ratings
• >Training program quality survey ratings.

• Organization process performance trends (e.g., customer satisfaction)
• Stability of process performance baselines

• Trends in process performance with respect to changes in work products and task attributes (e.g., size growth, effort, schedule, and quality

• Change requests to the process for measurable improvement
• Cost to benefit ratio analysis for improvement of processes and technologies.

• Change in quality or process performance

• Number of clarifications to requirements
• Requirements counts, status, and traceability metrics
• Action items to resolve requirements discrepancies or inconsistencies relative to project plans
• Impact assessments for requirements changes.

• Requirements volatility (percentage of requirements changed)

• Number of requirements elicitation meetings
• Requirements allocation status and metrics
• Number of operational use cases or scenarios.

• Cost, schedule, and effort expended for rework
• Number of Defects in of requirements specifications

• Number of alternative solutions evaluated
• Estimated life cycle cost of alternative solutions
• Corrective action status from design and implementation reviews
• Unit-level test cases completed vs. plan.

• Cost, schedule, and effort expended for rework
• Percentage of requirements addressed in the product or product component design
• Size and complexity of the product, product components, interfaces, and documentation
• Defect density of technical solutions work products.

• Change activity for interface descriptions
  • Integration effort, schedule, and resources vs. plan.

• Product-component integration profile (e.g., product-component assemblies planned and performed, and number of exceptions found)
• Integration evaluation problem report on trends (e.g., number written and number closed) and aging (i.e., how long each problem report has been open).

• Product change request trends
• Measures and trends of duration in verification testing
• Analyses of peer review effectiveness.

• Verification profile (e.g., the number of verifications planned, performed, and defects found
• Number of defects detected
• Verification problem report on trends (e.g., number written and number closed) and status (i.e., how long each problem report has been open).

• Measures and trends of duration in validation and scenario testing
• Number and extent of changes to validation and scenario tests (and simulation tools)

• Number of validation activities completed (planned versus actual)
• Validation problem report on trends (e.g., number written and number closed)and aging (i.e., how long each problem report has been open)

• Distribution of change requests to configuration items or categories
• Change request status (number open, closed, etc.).

• Number of changes to configuration items
• Number of configuration audits conducted.

• Staffing ratio of PPQA function vs. project head count.
• Actions item status from process and product evaluations.

• Variance of objective process evaluations planned and performed
• Variance of objective product evaluations planned and performed.

• Minutes of project metrics reviews

• Percentage of projects using progress and performance measures
• Percentage of measurement objectives addressed.

• Number of alternative approaches evaluated

• Cost to benefit ratio of using formal evaluation processes

• Alignment of project and organizational shared visions
• Evaluations of effectiveness of integrated team environments and tools
• Status of action items related to the organizational environment

• Number of improvement proposals
• Measurable improvements in project quality and productivity as a result of causal analysis and resolution

• Number of root causes removed
• Change in quality or process performance per instance of the causal analysis and resolution process

• Records of evaluations or audits being performed as planned (e.g., reports, completed checklists).
• Noncompliance issues resulting from objective evaluation of adherence to processes, objectives, and standards

• Identification of processes, work products, and services to be objectively evaluated.
• Criteria against which processes and work products are evaluated.
• Assignment of responsibility for performing objective evaluations (see Generic Practice 2.4 Assign Responsibilty).
• Revised plans, work products, or standards reflecting corrective action resulting from objective evaluations.

• Projects may elect not to use additional procedures or standards beyond the organizational policies.
• Objectivity is necessary, but independence is not necessarily required. Objective reviews "can be done by independent groups, or by project members themselves."
• People not directly responsible for managing or performing the activities of the process typically evaluate adherence. In many cases, adherence is evaluated by people within the organization, but external to the process or project, or by people external to the organization. As a result, credible assurance of adherence can be provided even during times when the process is under stress (e.g., when the effort is behind schedule or over budget).

^NOTE

• Work Breakdown Structure
• Project plan
• Data management plan
• Stakeholder involvement plan

• Records of project performance
• Project review results

• Plan for Supplier Agreement Management
• Supplier agreements

• Project's defined process
• Project plans
• Other plans that affect the project
• Integrated plans
• Shared-vision statements

• Risk management strategy
• Risk mitigation plans

• Descriptions of roles and responsibilities
• Descriptions of product ownership boundaries and team interfaces.

• Adherence data in measurement repository

• Subprocesses to be included in the project's defined process
• Collected measures
• Operational definitions of the measures.

• Process improvement plans
• Process action plans
• Plans for the organization's process appraisals.

• Set of standard processes
• Descriptions of the life-cycle models
• Tailoring guidelines for the organization's set of standard processes
• Measurement data

• Training tactical plan
• Training materials and supporting artifacts
• Instructor evaluation forms

• Process performance plans
• Quality and process-performance objectives
• Definition for the selected measures of process performance.

• Deployment plans
• Revised process- and technology-improvement measures, objectives, priorities, and deployment plans
• Updated training material

• Requirements
• Requirements traceability matrix.

• Product requirements
• Product-component requirements
• Interface requirements

• Functional architecture.

• Technical data packages
• Product, product-component, and interface designs
• Implemented designs (e.g., software code, fabricated product components)
• User, installation, operation, and maintenance documentation.

• Product integration sequence
• Product integration procedures and criteria
• Acceptance documents for the received product components
• Assembled product and product components.

• Verification procedures and criteria
• Peer review checklists
• Verification reports.

• Validation methods, procedures, and criteria.

• Archives of the baselines
• Change request database

• Noncompliance reports
• Evaluation logs and reports.

• This "auditing" of Quality Control activities is typically done by an independent expert, either from inside or outside the project.

• Specifications of base and derived measures
• Data collection and storage procedures
• Analysis results and draft reports

• Guidelines for when to apply a formal evaluation process
• Evaluation reports containing recommended solutions

• Shared vision
• Guidelines that determine the degree of empowerment of individuals and integrated teams
• Process documentation for issue resolution
• Compensation policies and procedures.

• Action proposals selected for implementation
• Causal analysis and resolution records.

• Materials and results from reviews (e.g. status reports and briefings) held with higher-level management, on both a periodic and event-driven basis.

• Action items and corrective action resulting from management reviews.
• Metrics and analyses summarizing project status.
• Schedule for reviews held with higher-level management.

• The purpose of this practice is to provide higher-level management with the appropriate visibility into the process."
• The purpose of the review is not to duplicate GP 2.8 Monitor and Control, but to focus on whether the process, as implemented, is satisfying organizational goals (e.g., employee morale, customer satisfaction).
• "These reviews are expected to be both periodic and event-driven." The periodicity of the reviews can be defined by the organization, but should be frequent enough to address organizational issues. Typical event-driven reviews would occur at the completion of a major phase of the life cycle.
• Reviews do not have to be face-to-face (e.g., submission and review of a status report), but they must show evidence of manager review of pertinent information and corrective action where appropriate.

• Status of Improvements being developed by process action teams
• Results of pilots
• Results of deployments
• Schedule status for achieving significant milestones (e.g., readiness for an assessment, or progress towards achieving a pre-defined organizational maturity or process capability level.

• Reviews are typically in the form of a briefing presented to the management steering committee by the process group and the process action teams.

• Proposed changes to commitments to be made external to the organization are reviewed with higher level management to ensure that all commitments can be accomplished.

• Defined process description (purpose, inputs, entry criteria, activities, roles, measures, verification steps, outputs, exit criteria) tailored from the set of standard processes.
• Change records for the defined process descriptions.

• Records of how the standard process was tailored for a particular project or process application
• Artifacts showing that the defined process, as tailored, is followed
• Identification of the baseline of standard process used.

• Process descriptions may exist only at the organizational (not project) level. Projects may also have processes that are not standardized at the organizational level.
• See Organizational Process Definition Practice Area for further guidance on the practices used to establish the standard process
• See Integrated Project Management Practice 1.1 on how to establish and maintain the project's defined process
• A family of process descriptions may exist for use in different situations.
• Separate process description need not exist for every PA; process descriptions may cover multiple PAs or part of a PA.
• "Establish and maintain" implies usage, so it is expected that the defined processes are used by the projects or organization, tailored as appropriate, and revised as necessary.

• Work products (e.g., documentation) for inclusion in the organizational library of process-related assets.
• Process and product measures and measurement results (see General Practice 2.8 - Monitor and Control for examples)
• Improvement information (e.g. lessons learned, proposed improvements)

• Changes resulting from incorporation of improvement information
• Requests for submitting documentation to the organizational process library
• Improvement proposals
• Descriptions of common set of product and process measures for the organization's processes and process assets
• Populated organizational measurement repository and associated analyses
• Processes and procedures for submission, incorporation, and maintenance of assets in the organizational library
• Populated organizational process library
• Catalogue of process documentation items that exist in the library
• Plans, processes, and procedures for performing the process area.

• Material is collected from across the organization
• ppropriate levels of security should be defined so that information is accessible to those who need it
• The process and product measures are primarily those that are defined in the common set of measures for standard processes
• Refer to Process Definition Practice Area for more information about the organizational measurement repository and organizational process asset library.
• Reference General Practice 2.8 - Monitor and Control for typical measures that could be collected.

• Project work breakdown structures (WBS)
• Estimating models
• Project attribute estimates
• Bases of estimates (BOEs)
• Project estimation rationale
• Project effort, schedule and cost estimates
• Project schedules
• Identified risks
• Project data management plans
• Project resource plans
• Project training plans
• Stakeholder involvement plans
• Project plans
• Other plans that affect the project.

• Project effort, schedule and cost actuals
• Records of project performance, project commitment reviews, project risk monitoring, data management, stakeholder involvement
• Project and milestone review results
• Issue list
• Corrective action plans.

• Acquisition types for acquired products and services
• Candidate supplier lists
• Preferred supplier lists
• Supplier selection rationale
• Supplier evaluation criteria and resulting evaluations
• Solicitation materials and requirements
• Supplier statement of work
• Supplier agreements (e.g., contracts, memoranda of agreement, licensing agreements)
• COTS trade studies, price lists, evaluation criteria, and product reviews
• Supplier progress reports
• Supplier review materials and reports
• Acceptance test procedures and results
• Transition plans and reports
• Support and maintenance reports.

• Project's defined process and tailoring from the organization's standard process
• Lessons learned and measures from use of organizational process assets and estimating models
• Approaches for integration of project plans
• Measures for effort and schedule to tailor the organization's standard process
• Communications strategy
• Organizational expectations and constraints that apply to projects
• Measures for evaluating the performance of integrated teams.

• Risk management process(es), procedures
• Risk sources and categories
• Risk evaluation, classification and prioritization criteria and measures
• Risk management strategies
• Risk management plans
• Risk mitigation plans
• Records of risk monitoring and mitigation.

• Descriptions of team work tasks, roles, and responsibilities
• Team skills matrix and knowledge profile
• Criteria for selection of team members
• Team shared visions
• Team charters and critical success factors
• Team operating procedures
• Team performance measures
• Work product and process deployment charts
• Team work plans and commitment lists.

• Lists and information for potential product sources
• Market studies
• Product trade studies
• Analysis and evaluation reports for selection of product sources
• Supplier activity reports, performance measures, and discrepancy reports
• Supplier agreements and revisions.

• Project quality and process-performance objectives
• Criteria used for identifying valid sub-process candidates
• Sub-processes selected to be included in the project's defined process
• Sub-processes that were selected to be statistically managed
• Process and product attributes of the selected processes that were measured and controlled
• Operational definitions of the measures
• Instrumentation and environment for automatic data collection
• Analytical techniques for statistical management of subprocess performance
• Collected and verified measures
• Analyses of subprocess capability, such as natural bounds of performance and special causes of variation,

• Process needs and objectives
• Process improvement action plans
• Appraisal plans
• Pilot plans
• Appraisal findings
• Improvement recommendations
• Analysis of candidate process improvements
• Status and results of implementing process improvement plans
• Process improvement deployment plans
• Process improvement proposals
• Process lessons learned
• Measurements on process assets
• Records of process improvement activities
• Information on process assets and improvements to them.

• Set of standard processes
• Descriptions of life-cycle models
• Tailoring guidelines for the set of standard processes
• Definition of common set of product and process measures for the set of standard processes.

• Training needs
• Skill assessment analysis
• Organizational training plan
• Training materials and artifacts
• Training records
• Training effectiveness surveys
• Training program performance assessments
• Instructor evaluation forms
• Training examinations.

• Improvement information associated with the Organizaitonal Training Practice Area may be in a separate database
• Individuals within the organization should be able to see information regarding available training, training schedules, their training records, training effectiveness surveys and instructor evaluation forms.

• Definitions for selected measures of process performance
• quality and process performance objectives
• Baseline data on process performance
• Process performance models
• List of processes or process elements identified for process performance analyses
• Measurement data collected from projects to derive the organization's process performance.

• Pilot plans, evaluation reports, and lessons learned
• Plans for performing the Innovation & Deployment process
• Measures used in monitoring and controlling the activities of the Innovation & Deployment Practice Area
• Lessons learned from performing the Innovation & Deployment activities
• Process(es) and procedures for performing the Innovation & Deployment activities
• Results of analysis of process improvement proposals
• Deployment plans.

• Requirements documents and measures
• Requirements database schema and repository
• Requirements traceability matrices
• Defects identified in requirements peer reviews.

• Requirements elicitation techniques and assets
• Prototypes and models
• Customer requirements
• Functional architecture
• Use cases
• Operational concepts and scenarios
• Test cases
• Product and product component requirements
• Interface requirements
• Requirement defect reports
• Technical performance measures
• Results of requirements validation .

• Design methods and associated criteria
• Criteria for selection among alternative solutions
• New technology evaluations
• Product component selection decisions and rationale
• Operational concepts and scenarios
• Product, product component, process, service and interface designs
• Technical data packages
• Interface design documents
• Interface specifications and templates
• Make or buy analyses
• Guidelines for choosing COTS components
• Design documents
• Design and component reuse criteria
• User, installation, operation and maintenance documentation.
• End-user training materials.

• Product integration environment definitions and support documentation
• Product integration procedures and criteria
• Interface descriptions
• Acceptance documents for the received product components
• Product component assembly information
• Exception reports for evaluated products
• Interface evaluation reports
• Product delivery documentation.

• Verification plans, procedures, results, and reports
• Descriptions of the verification support equipment, tools and environment
• Peer review checklists
• Entry and exit criteria for work products
• Peer review data and performance measures
• Trouble reports
• Defect and problem data.

• List of products selected for validation
• Descriptions of the validation environment
• Validation procedures & criteria used by the projects
• Test and evaluation procedures
• Validation results and reports
• Validation deficiency reports
• Validation issues.

• Configuration management plans
• Configuration management standards, procedures, and methods
• Lists of identified Configuration Items
• Descriptions of configuration management library and change request database
• Change request data, analyses, and reports
• Change Control/Advisory Board meeting minutes
• Configuration audit reports.

• Quality assurance plans
• Evaluation reports
• Noncompliance reports
• Reports of quality trends
• Quality measures and attributes.

• Measurement objectives
• Specifications of base and derived measures
• Data collection and storage procedures
• Data collection and analysis tools
• Data analysis specifications and procedures
• Analysis results, reports and presentations.

• Guidelines for when to apply structured decision-making
• Decision making techniques and tools
• Evaluation criteria
• Evaluation results & selected solutions
• Trade studies of candidate products or approaches.

• Guidelines for building a shared vision
• Descriptions of integrated work environments
• Guidelines for empowerment, leadership, and decision-making context
• Issue resolution processes and guidance
• Procedures for performance recognition that reinforce collaboration.

• Causal analysis action proposals
• Causal analysis action plans
• Measures of performance and performance change
• Causal analysis and resolution records.

• Sub-processes identified for quantitative analysis
• Quantitative objectives for quality and process performance are established
• Performance of subprocesses critical to the performance of the process are stabilized
• understanding of the ability of the process to achieve the established quantitative objectives for quality and process performance.

• statistical models depicting process performance
• data warehouses maintaining process performance data
• Product and process attributes are identified that are important contributors to quality and process performance
• special causes of sub-process variations are identified
• Selected sub-processes are monitored with the objective of bringing their performance within natural bounds.

• Quantitative objectives for the project planning process

• Data on sub-process variation
• Recommendations to treat sources of sub-process variation

• Knowledge of the contributions of the sub-processes towards process objectives
• multi-staged quantitative objectives

• Stabilizing selected sub-processes of the process supports predicting the ability of the process to achieve the established quantitative quality and process-performance objectives
• A stable sub-process shows no significant indication of special causes of process variation
• Stable sub-processes are predictable within the limits established by the natural bounds of the sub-process
• Variations in the stable sub-process are due to a constant system of chance causes, and the magnitude of the variations may be small or large.

• Quantitative process-improvement objectives ^N
• Strategies and managed deployment of selected process improvements

• Empowered workforce^N
• Cost-benefit analyses with costs and benefits of improvements estimated quantitatively

• The organization’s ability to rapidly respond to changes and opportunities is enhanced by finding ways to accelerate and share learning
• Innovative technological improvements are typically pursued as a distinct effort.

• Root Cause Analyses

• Infrastructure problems reduced
• Requests for Changes to infrastructure to remove root causes of problems
• Improved availability of servicea.

• Refer to the Causal Analysis and Resolution process area for more information on identifying and correcting root causes of selected defects
• Techniques such as Six Sigma are fruitfully applied in analyzing and treating defects.