SCAMPI: Project Management Process Area Artifacts
Project Planning Monitoring & Control Supplier Agreement Management Integrated Project Management for IPPD Risk Management Integrated Teaming Integrated Supplier Management Quantitative Project Management

PP - Project Planning

Practice Area
Basic & Advanced Maturity		ArtifactsConsiderations
DirectIndirect
Goal 1: Estimates of project planning parameters are established and maintained.d
Practice 1.1 - Establish a top-level work breakdown structure (WBS) to estimate the scope of the project.
  • Work Breakdown Structure
    • Top-level WBS revision history.
  • Task descriptions
  • Work product descriptions
    • Product requirements, product roadmaps
    • Organizational standard WBS template
    • Identification of work products (or components of work products) that will externally acquired.
  • Determination of WBS usage for this practice must be based on top-level WBS only, not its fully elaborated and expanded form as referenced in subsequent practices of this Practice Area.
  • Top-level work breakdown structure should be driven by and linked to specified product requirements. (See Requirements Management Practice Area).
  • See Supplier Agreement Management process area for more information about acquiring work products from other sources external to the project.
  • Level of supporting documentary evidence will vary based on project size/duration. Larger projects may have minutes from estimation meetings, estimation teams, and tools use, etc. Smaller may have none. Assessment team will need consensus on the WBS elements that will be expected. See Project Planning Practice 1.4 (below) for derivation of detailed work breakdown structures from top-level work breakdown structures.
Practice 1.2 - Establish and maintain estimates of the attributes of the work products and tasks.
  • Attribute estimates
    • Estimates of the attributes of the work products and tasks (e.g., size)
    • Estimates, as appropriate, of labor, machinery, materials, and methods that will be required by the project.
    • Estimates revision history.
  • Technical approach
  • Estimating models
    • Estimating tools, algorithms, and procedures
    • Operational definitions (e.g., procedure/criteria) for establishing and documenting the estimates of the attributes of the work products and tasks.
    • Bases of estimates (BOEs)
    • Use of validated models.
    • Use of models that are calibrated with historical data.
  • Estimates should be consistent with project requirements to determine the project's effort, cost, and schedule.
Practice 1.3 - Define the project lifecycle phases upon which to scope the planning effort.
  • Project life-cycle phases
    • Relationships, interdependencies and sequencing of project phases.
  • Systems engineering identifies the major product phases for the current state of the product, expected future phases, and the relationships and effects among phases.
  • Software Engineering typically includes selection and refinement of a software development methodology to address interdependencies and appropriate sequencing of software project activities.
  • The project life cycle consists of phases that need to be defined depending on the scope of requirements, the estimates for project resources, and the structure of the project.
  • Larger projects may contain multiple phases
  • Phases may contain sub-phases
  • Depending on the strategy for development, there may be intermediate phases e.g. prototyping, increments of capability.
Practice 1.4 - Estimate the project effort and cost for the work products and tasks based on estimation rationale.
  • Project effort estimates
  • Project cost estimates
    • Documented assumptions, constraints, and rationale affecting project estimates, and identify risks.
    • Bases of estimates (BOEs)
  • Estimation rationale
    • Historical data or repository from previously executed projects.
    • Estimating methods (e.g., Delphi), models, tools, algorithms, and procedures
    • Support needs (e.g., facilities and equipment resources).
  • See Practice 1.1 (above) for development of detailed work breakdown structure
  • See Practice 1.2 (above) for development of attributes of the work products and tasks.
Goal 2: A project plan is established and maintained as the basis for managing the project.
Practice 2.1 - Establish and maintain the project's budget and schedule.
  • Project schedules
  • Schedule dependencies
  • Project budget
    • Revision history for schedule and budget.
  • Staffing profile
  • Identified major milestones
  • Scheduling assumptions and constraints
  • Task dependencies
  • Criteria for corrective action based on deviation from project plan
  • Comparisons of actual project performance results to estimates (for re-planning).
  • This practice accumulates the project effort and cost estimates generated in practice 1.4 (above).
  • See Practice 2.5 for typical activities in development of budget and schedule
  • See Monitor and Control Practices 1.1 and 2.2 for factors that may drive re-planning activities.
Practice 2.2 - Identify and analyze project risks.
  • Identified risks
    • List of current project risks
    • Revision history of risks.
  • Risk impacts and probability of occurrence
  • Risk priorities
  • Records of stakeholder involvement in risk identification activities
  • Criteria to be used to identify and analyze project risks.
  • The project plan typically contains a list project risks.
  • See Risk Management process area for more information about risk management activities.
  • See Monitoring and Control Practice 1.3 for more information about monitoring risks against those identified in the project plan.
Practice 2.3 - Plan for the management of project data.
  • Data management plan
  • Master list of managed data
  • Data content and format description
  • Data requirements lists for acquirers and for suppliers
  • Privacy requirements
  • Security requirements
  • Security procedures
  • Mechanism for data retrieval, reproduction, and distribution
  • Schedule for collection of project data
  • Listing of project data to be collected
    • Project data management repository and access mechanisms
    • Project data identified, collected and distributed.
Practice 2.4 - Plan for necessary resources to perform the project
  • WBS work packages
    • WBS task dictionary
  • Staffing requirements based on project size and scope
    • Staffing plans and profiles.
  • Critical facilities/equipment list
  • Facilities plan
  • Process/workflow definitions and diagrams.
  • Program administration requirements list
    • Budget reviews
    • Long lead-time items identified early.
  • See Practice 1.1 for top-level work breakdown structure from which detailed WBS work packages and WBS task dictionaries are derived.
  • See Practice 2.5 for the planning for knowledge and skills needed to perform the project.
  • See Organizational Training process area for more information on knowledge and skills information to be incorporated on the project plan.
Practice 2.5 - Plan for needed knowledge and skills needed to perform the project.
  • Inventory of skill needs
  • Staffing and new hire plans
    • Plans for providing needed knowledge and skills (e.g., training plan).
  • Databases (e.g., skills and training)
  • The needed knowledge and skills in this SP should be compared with those provided by the project staff as determined in the previous Practice 2.4-1).
  • See Organizational Training process area for more information on knowledge and skills information to be incorporated on the project plan.
Practice 2.6 - Plan the involvement of identified stakeholders.
  • Stakeholder involvement plan
  • List of relevant stakeholders for the project
  • Schedule for stakeholder interaction
  • Roles and responsibilities for stakeholders
  • Defined criteria (e.g., procedure) used to plan the involvement with identified stakeholders.
  • See model for examples of typical contents of the stakeholder involvement plan.
  • This is an accumulation of the stakeholders across all Practice Areass as a result of Generic Practice 2.7
  • See Monitoring and Control Practice 1.5 for monitoring stakeholder involvement against the project plan.
  • Stakeholder involvement will vary with project phase and activity and in any project re-planning.
Practice 2.7 - Establish and maintain the overall project plan content.
  • Overall project plan
    • Project plan revision history.
  • Issues and conflicts identified across subordinate plans.
  • Consider periodic revisions to the project plan due to changes in status of its dependencies (See Practice 3.2 [below])
  • The overall project plan ties together all the subordinate planning information; this may be a single plan or consolidation of multiple plans.
  • The project plan resolves issues and conflicts associated with the subordinate plans.
Goal 3: Commitments to the project plan are established and maintained.
Practice 3.1 - Review all plans that affect the project to understand project commitments.
  • Record of the reviews of plans that affect the project
    • Review and signature cycle of the set of plans describing project scope, objectives, roles, and relationships.
  • Project plan
  • Integrated work plans
  • Evidence of project plan coordination meetings and correspondence.
  • This practice considers the compatibility of other plans that may be related or subordinate to the project plan. This may include plans called for in other CMMI process areas, many of which are described by Generic Practice 2.2 (Plan the Process). An organization may choose to develop separate plans, or integrate all content into a single project plan.
Practice 3.2 - Reconcile the project plan to reflect available and estimated resources.
  • Re-negotiated budgets
  • Revised schedules
  • Revised requirements list
  • Renegotiated stakeholder agreements
  • Revised methods and corresponding estimating parameters (e.g., better tools, use of off-the-shelf components)
    • Project change requests
    • Project plan revision history.
  • Revised plans, etc., should be re-communicated to the affected parties.
Practice 3.3 - Obtain commitment from relevant stakeholders responsible for performing and supporting plan execution.
  • Documented commitments
    • Documented commitment by those implementing the plan.
    • Documented commitments by those responsible for providing resources.
  • Documented requests for commitments
    • Commitment review meeting minutes
    • Identification and documentation of issues
    • Identified commitments on interfaces between elements in the project, with other projects, and organizational units.
  • Commitments may include relevant stakeholders, both internal and external to the project and organization. This should include the individuals responsible for providing the resources identified in the plan (e.g., staffing, facilities, funding).
  • Commitment is typically demonstrated by signature, but may include other mechanisms.
  • For commitments external to the organization, this practice may be satisfied by an implicit agreement, e.g., a clear communication of the needed resource, signature of a contract referencing the plan or resource.
  • Commitment by those implementing the plan may be demonstrated by a representative of the implementers, e.g., a leader signing for their staff.
  • Ensure this is performed not only for the initial project plan, but also for subsequent reconciliation and changes (see practice SP3.2 above).

[To top of Page]

MC - Project Monitoring and Control

Practice Area
Basic & Advanced Maturity		ArtifactsConsiderations
DirectIndirect
Goal 1: Actual performance and progress of the project are monitored against the project plan.
Practice 1.1 - Monitor the actual values of the project planning parameters against the project plan.
  • Records of Project performance
  • Records of significant deviations against plan
    • Performance actual values vs. plan (e.g., schedule, cost, effort, work product attributes, resources, knowledge and skills)
    • Comparisons of actual Project Project performance results to estimates (for re-planning).
  • Earned value management metrics
  • Variance reports,
  • Status reports
  • Relevant project management/milestone progress review materials
  • Identified major milestones
  • Project or organizational repository for performance measurements (See Practice 1.4 below).
  • Indications knowledge and skills of Project personnel are monitored.
  • See Practices 2.1-1, 2.2-1, 2.3 for corrective actions taken.
  • See Project Planning Practice Area for Project planning parameters and plans to be monitored.
Practice 1.2 - Monitor commitments against those identified in the Project plan.
  • >Records of commitment reviews
    • Status reports or tracking minutes
    • Quality assurance audit reports of performance against cost, schedule, and technical commitments documented in approved plans
    • Reports against cost account and earned value plans
    • Project review records, project meeting minutes, and project presentations packages showing planned activities are performed per commitments made).
  • Project plans, and commitments tracking system.
  • Reviews of documented commitments and revisions as necessary (e.g., presentations).
Practice 1.3 - Monitor risks against those identified in the Project plan.
  • Records of Project risk Monitoring
    • Periodic review and revision of risk status (e.g., probability, priority, severity)
    • Communications of risk status to relevant stakeholders.
  • Defined criteria (e.g., procedure) used to monitor risks against those identified in the Project plan.
Practice 1.4 - Monitor the management of Project data against the project plan.
  • Records of data management
    • Data management reports (e.g., inventory, delivery schedules and status)
    • Reviews/inventories/master lists or audits of project data repository status
    • Results of data management reviews.
  • Master list of managed data
    • Data management plan
  • See Project Planning Practice 2.3-1 for planning for identifying the types of data that should be managed and how to plan for their management.
  • See Practice 1.1 for project measurement repository.
Practice 1.5 - Monitor stakeholder involvement against the Project plan.
  • Records of stakeholder involvement
    • Project team stakeholder reviews (presentation materials, minutes, action items and action item status)
    • Stakeholder issues and status.
  • Stakeholder meeting and communications schedules
  • Distribution lists for communication of issues
  • Stakeholder correspondence with issues indicated
  • Mechanisms/tools for monitoring and resolving stakeholder issues (e.g., files and spreadsheets).
Practice 1.6 - Periodically review the Project's progress, performance, and issues.
  • Documented Project review results
    • Project review packages
    • Project review minutes and action items
    • Reviews of project monitoring measurements and analysis.
  • Collection and analyses of project performance measures (schedules, effort, deviations from plan).
  • Records of communications of project status to relevant stakeholders
  • Records of issues, change requests, problem reports for work products and processes
  • Defined criteria (e.g., procedure) used for periodically reviewing the Project's progress, performance, and issues (including work products, processes, schedules/intervals, and checklists/standards for conducting reviews).
  • Practice 2.1 for collecting and analyzing the issues and determining the corrective actions necessary to address the issues.
  • Project progress reviews may be informal, and not specified explicitly in project plans.
Practice 1.7 - Review the accomplishments and results of the Project at selected Project milestones.
  • Documented milestone review results
    • Milestone review packages
    • Milestone review minutes and action items
    • Documented issues from the reviews.
  • Milestone progress performance indicators.
  • Defined criteria (e.g., procedure) used to review the accomplishments and results of the Project at selected Project milestones (including definitions of milestones).
  • Standards/formats/checklists supporting milestone reviews.
  • Refer to the Project Planning practice 2.1-1 for more information about milestone planning.
  • Project milestone reviews are specified in the project plan and schedule, and can be event based or calendar based.
Goal 2: Corrective actions are managed to closure when the project's performance or results deviate significantly from the plan.
Practice 2.1 - Collect and analyze the issues and determine the corrective actions necessary to address the issues
  • List of issues needing corrective actions
    • List of issues needing corrective actions
    • Documented analysis of issues needing corrective action.
See general evidence.
  • See Practice 1.1 (above) for monitoring of project actual parameters and identifying deviations from the project plan
  • See Practice 1.6 (above) for review of issues
  • Reference Project Planning Practice 2.1-1 for information about corrective action criteria.
Practice 2.2 - Take corrective action on identified issues.
  • Corrective action plan
    • Revision to project plans and work products (SOW, estimates, requirements, estimates, commitments, resources, processes, risks) incorporating the corrective actions.
  • Defined criteria (e.g., procedure) used to develop the corrective action plan and take corrective action on identified issues
  • Reference Project Planning Pratcie Area when Project re-planning is needed. The corrective actions may require re-planning, which may include revising the original plan, establishing new agreements, or including mitigation activities within the current plan.
Practice 2.3 - Manage corrective actions to closure.
  • Corrective action results
    • Evidence that resources have been applied and schedules have been followed to take the planned corrective actions on identified issues.
    • Corrective action status, tracking reports, or metrics (e.g. quantity open / closed, trending).
  • Review and meeting minutes associated with corrective actions
  • Corrective action effectiveness analysis
  • Closed corrective action requests.
 

[To top of Page]

SAM - Supplier Agreement Management

Practice Area
Basic & Advanced Maturity		ArtifactsConsiderations
DirectIndirect
Goal 1: Agreements with suppliers are established and maintained.
Practice 1.1 - Determine the type of acquisition for each product or product component to be acquired.
  • List of the acquisition types that will be used for all products and product components to be acquired
  • Make/buy analysis or trade study with product acquisition options
  • Management authorization to proceed with acquisition of a product or service
  • System architecture/design documentation identifying products or components to be acquired (e.g., non-developmental items)
  • This process area primarily applies to the acquisition of products and product components that are delivered to the project's customer. This Practice Area is not directly applicable to non-deliverable products or labor sub-contracts (i.e., hiring contractors to supplement the acquirer's staff in an integrated project team).
  • The entry to this Practice Area assumes that a decision to acquire the product externally has already been made (i.e., requirements and make/buy analysis have been performed in Engineering Practice Areas); This Pratice Area deals with managing the acquisition from suppliers.
  • Example acquisition types include: COTS products; obtaining products through a contractual agreement (or sub-contract); in-house/3rd party development; customer-furnished products; co-development, or some combination of above.
Practice 1.2 - Select suppliers based on an evaluation of their ability to meet the specified requirements and established criteria.
  • Rationale for selection of suppliers
  • Evaluation criteria
    • Supplier evaluation results.
  • List of candidate suppliers
  • Preferred supplier list
  • Advantages and disadvantages of candidate suppliers
  • Solicitation materials and requirements
    • Requirements allocation to the product to be acquired.
    • Procurement documentation (e.g., tech spec, SOW, interfaces, solicitation, proposals, etc.)
    • Supplier surveys.
    • Analysis of acquisition risks and best value supplier.
    • Source selection decision.
  • Evidence that the "established criteria" were identified in advance and actually used to evaluate suppliers.
  • Most procurement-specific data will be source selection sensitive and may not available for inspection. It may be necessary to use alternative data, such as blank evaluation forms and summary briefings or supplement with interview observations.
  • Recognize that non-technical factors may be applicable to supplier selection (strategic partnerships, market positioning, political, etc.). This may result in selection of suppliers that are neither best technical nor lowest cost, but should still be reflected in the evaluation criteria and factors used for supplier selection.
Practice 1.3 - Establish and maintain formal agreements with the supplier.Documented formal supplier agreement, with approved revisions as necessary.
  • Negotiated contractual terms, conditions, and constraints (e.g., deliverables, requirements, schedule, budget, standards, facilities, acceptance criteria).
  • Defined parameters, criteria, and objectives for evaluating supplier performance.
  • Acquirer plans to monitor supplier progress and product quality (e.g., quality plans, IV&V plans)
  • Integration of supplier products and schedules into acquirer plans (e.g., milestones, interfaces, dependencies, environment, testing, etc.)
  • Acquirer impact assessment and revision to project plans, as necessary.
  • Supplier Work Breakdown Structure.
  • Issues or action items relating to definition or revision of the supplier agreement.
  • A formal agreement is any legal agreement between the organization (representing the project) and the supplier."; e.g., contract, license, MOA. The type of agreement may vary according to the product acquisition type (subcontracted custom product, COTS product, customer-furnished product, etc.)
  • Investigate how the formal agreement is "maintained"; e.g., contractual revisions, renegotiations, impact assessment, interfaces, replanning.
Goal 2: Agreements with the suppliers are satisfied by both the project and the supplier.
Practice 2.1 - Review candidate COTS products to satisfy the specified requirements that are covered under a supplier agreement.
  • Reviews of COTS products
    • Identification of selected >COTS products with rationale for selection.
  • Trade studies
  • Price lists
  • Evaluation criteria
  • Supplier performance reports
    • Negotiated licenses or agreements for purchase of COTS products.
    • Requirements allocation to COTS products or components.
    • Checklists, criteria, risk assessments, or trade studies for evaluation and selection of COTS products.
  • Identification of product components that will be satisfied by COTS is performed in the Technical Solution Practice Area. This practice focuses on selection of appropriate COTS products to satisfy these needs.
Practice 2.2 - Perform activities with the supplier as specified in the supplier agreement.All products specified in the supplier agreement must be considered in assessing this practice.
  • Supplier progress reports and performance measures
  • Supplier review materials and reports
  • Documentation of work product and document deliveries.
  • Action items tracked to closure
    • Audits, corrective action requests, and plans to improve supplier performance.
    • Supporting evidence of supplier technical and management reviews (agenda, minutes, etc.)
  • The direct artifacts listed here (e.g., typical work products) are commonly specified in supplier agreements, but the presence or absence of some of these may vary according to the terms of the specific supplier agreement.
Practice 2.3 - Ensure that the supplier agreement is satisfied before accepting the acquired product.
  • Acceptance test results
  • Acceptance test procedures
  • Discrepancy reports or corrective action plans
    • Configuration audit results
    • Traceability reports indicating coverage of requirements for the acquired product by acceptance test procedures.
    • Verification of functional performance, configuration, and adherence to defined requirements and commitments
    • Closure or termination of supplier agreement.
  • the acceptance of products includes satisfaction of both technical and non-technical commitments.
  • acceptance does not necessarily require testing to ensure satisfaction of the supplier agreement; other mechanisms may be suitable, such as inspections, reviews, audits, etc. However, it would be reasonable to expect that the acceptance results are documented.
  • Refer to the Verification Practice Area for additional information about verifying products.
Practice 2.4 - Transition the acquired products from the supplier to the project.
  • Transition plans
    • Records reflecting implementation of transition plans.
  • Training reports
  • Support and maintenance reports
    • Configuration Management reports indicating control, auditing, and maintenance of acquired products.
    • Records indicating integration of the acquired product into the project
    • Vendor maintenance agreements.
  • There should be evidence of the transition plan actually being implemented. Depending on the lifecycle phase of the appraised projects, it may be difficult to obtain objective evidence of deployment and transition of supplier products. The supplier product may be still be in the acquisition phase, in which case only transition plans are available. Or, the project may itself have completed shortly following acceptance and delivery of the acquired product, and therefore might not even be selected as a sample project for the appraisal.
  • It may be useful to think of this practice in terms of (1) subcontractors, and (2) COTS products, where this might include delivery and support of licenses, etc.

[To top of Page]

IPM - Integrated Project Management For IPPD

Practice Area
Basic & Advanced Maturity		ArtifactsConsiderations
DirectIndirect
Goal 1: The project is conducted using a defined process that is tailored from the organization's set of standard processes
Practice 1.1 - Establish and maintain the project's defined process.
  • The project's defined process
    • Peer Review results of the project's defined process.
    • Revision history for the project's defined process.
  • Organizational standard processes.
  • Defined criteria (e.g., process) that describe how the project's defined process is to be established and maintained.
  • Set of organization standard life cycle model descriptions.
  • Tailoring guidelines for producing the project's defined process.
  • Set of typical tailoring for projects, e.g., application domains or lifecycles.
  • Organizational asset library/repository and measurement database/repository.
  • Approved waivers to deviations from the organization's standard process.
  • The project's defined process is a set of defined processes and sub-processes that form an integrated, coherent lifecycle for the project.
  • The project's defined process covers all the processes needed by the project, including those processes addressed by the process areas at maturity level 2. Maturity level 2 process areas must incorporate the Maturity Level 3 Generic Practices.
  • See Organization Process Definition Practice Area for the establishment and maintenance of the set of standard processes, the library of process assets, measurement repository, life-cycle models, and tailoring guidelines.
  • See Organization Process Focus Practice Area for more information about organizational process needs and objectives.
Practice 1.2 - Use the organizational process assets and measurement repository for estimating and planning the project's activities.
  • Project estimates
  • Project plans
    • Records of independent validation of historical data.
    • Records of assumptions and rationale used to select the historical data for the project estimates.
    • Revision history of project estimates.
  • Organizational measurement database/repository.
  • Organizational asset library/repository.
  • Estimating tools, algorithms, and procedures.
  • Operational definitions (e.g., process/criteria) for establishing and documenting the estimates of the attributes of the work products and tasks.
  • Bases of Estimates (BOEs).
  • Project's defined process that includes the size and complexity of tasks and work products to be produced.
  • Estimation planning parameters.
  • In order for the practice to be implemented, the organization must have established and populated an organizational asset library/repository and an organizational measurement database/repository. This need not be a single database, but could be a set of related databases.
  • See Organizational Process Definition for information on the organizational asset library and the organization's measurement repository.
Practice 1.3 - Integrate the project plan and the other plans that affect the project to describe the project's defined process.
  • Integrated plans
    • Integrated plan revision history.
    • Plan changes reviewed by relevant stakeholders.
  • Project's defined process.
  • List of other plans that affect the project plan.
  • Definitions of measures and measurement activities for managing the project.
  • Identification and analysis of product and project interface risks.
  • Plans for performing peer reviews on the work products of the project's defined process.
  • List of relevant stakeholders.
  • Project schedule and schedule dependencies.
  • Databases (e.g., skills and training).
  • Training plans or training that is needed to perform the project' defined process.
  • Entry and exit criteria for the tasks defined in the WBS.
  • Meeting minutes from stakeholder reviews of the project plan.
  • Stakeholder conflict resolution procedure.
  • A distinction between Integrated Project Management and Project Planning is that this practice expands the development of the project plan to include additional activities such as incorporating the Project's Defined Process, coordinating plans with relevant stakeholders, using the organizational process assets, incorporating plans for peer reviews on work products of the project's defined process, and establishing objective entry and exit criteria for authorized project tasking
  • Many of the indirect artifacts identified above could be documented in the project plan.
  • See Project Planning Practice Area for information about establishing and maintaining a project plan.
  • See Verification Practice Area for more information about peer reviews.
Practice 1.4 - Manage the project using the project plan, the other plans that affect the project, and the project's defined process
  • Work products created by performing the project's defined process
  • Collected measures ("actuals") and progress records or reports
    • Records of project tracking (e.g., metrics, analyses, variance reports) against the project's planning parameters using documented thresholds.
  • Revised requirements, plans, and commitments
    • Corrective actions based on discrepancies vs. plan.
  • Integrated plans
    • Records of reviews held to monitor progress against project plans and corrective actions taken as necessary.
  • Project plan and other plans that affect the project
  • Project's defined process.
  • Criteria or checklists used to track and manage transition across the project or product life cycle.
  • Monitoring of product and project interface risks.
  • Project entries into the organizational measurement database/repository.
  • Entry and exit criteria and documented completion for the tasks defined in the project's defined process.
Practice 1.5 - Contribute work products, measures, and documented experiences to the organizational process assets.
  • Proposed improvements to the organization's process assets
  • Actual process and product measures collected from the project
  • Documentation (e.g., exemplary process descriptions, plans, training modules, checklists, and lessons learned)
    • Project best practices and lessons learned
    • Records of the project recording process and product measures in the organization's measurement repository.
  • Processes, procedures, and criteria for submitting improvements to the organizations process assets.
  • Organizational measurement database/repository that reflects actual process and product measures from the projects.
  • Organizational asset library/repository that provides evidence that work products and lessons learned are being populated by the projects.
  • Records of proposed process improvements and disposition.
Goal 2: Coordination and collaboration of the project with relevant stakeholders is conducted
Practice 2.1 - Manage the involvement of the relevant stakeholders in the project.
  • Agendas and schedules for collaborative activities
  • Documented issues (e.g. issues with the customer requirements, product and product-component requirements, product architecture, and product design)
    • Issues and dispositions for resolving stakeholder interfaces and misunderstanding.
    • Recommendations on resolving stakeholder issues
    • Records that show relevant stakeholder involvement is maintained.
  • Project plan, identifying relevant stakeholders
  • Plan for stakeholder involvement
  • Project schedule(s) that identify critical dependencies with relevant stakeholders.
  • Milestone/stakeholder review meeting minutes.
  • Organizational chart.
  • Records of reviews, demonstrations or testing on work products produced to satisfy commitments to meet the requirements of the recipient projects.
  • Reference Project Planning process area for more information on identifying stakeholders and planning their appropriate involvement
  • the involvement of relevant stakeholders should be managed in such a way that product and product component requirements, plans, issues and risks are coordinated in a timely manner.
  • The plan for stakeholder involvement may be contained in the project plan. This plan should contain how relevant stakeholder involvement will be managed through project plan and subordinate plan reviews, periodic stakeholder meetings, etc.
Practice 2.2 - Participate with relevant stakeholders to identify, negotiate, and track critical dependencies.
  • Defects, issues, and action items arising from reviews with relevant stakeholders
  • Critical dependencies
  • Commitments to address critical dependencies
  • Status of critical dependencies
  • Records of reviews to address critical dependencies and corrective actions taken.
  • Project plan, identifying relevant stakeholders
  • Projects defined process for identifying, negotiating, and tracking critical dependencies
  • Project schedule(s) that identify critical dependencies with relevant stakeholders.
  • Stakeholder milestone/project status reviews
  • Updated project plans reflecting and associated artifacts demonstrating negotiating and tracking.
  • Escalation procedures when actual and potential problems are not resolved.
  • Relevant stakeholders identified in the project plan should participate in project plan and other plan reviews.
  • See Project Monitoring and Control for more information about tracking commitments.
Practice 2.3 - Resolve issues with relevant stakeholders.
  • Relevant stakeholder coordination issues
  • Status of relevant stakeholder coordination issues
    • Records of tracking issues to closure with relevant stakeholder involvement.
  • Reviews, reports, or briefings communicating issues to stakeholders.
  • Issue tracking database with evidence of issues status being tracked and issues being resolved.
  • Evidence of escalation of issues to managers as needed. Could be through stakeholder meeting minutes with subsequent project status reports documenting issues.
 
Goal 3: Use the Project's Shared Vision for IPPD
Practice 3.1 - Identify expectations, constraints, interfaces, and operational conditions applicable to the project's shared vision context.
  • Organizational expectations and constraints that apply to the project
  • External interfaces that the project is required to observe
  • Operational conditions that that affect the project's activities
  • Project's shared vision context
  • Summary of project members' personal aspirations for the project
  • The term "Project's Shared Vision Context" is used to include organizational expectations and constraints, interfaces between the project and stakeholders external to the project operational conditions within which the project must operate and objectives and expectations of all relevant stakeholders (internal and external)
  • Thie practice captures contextual information that guides development of the project's shared vision in Practice 3.2-1.
Practice 3.2 - Establish and maintain a shared vision for the project.
  • Shared vision and objective statements
  • Published principles, shared-vision statement, mission statement, and objectives (e.g., posters, wallet cards published on posters suitable for wall hanging]
    • Stakeholder agreement and commitment to the project's shared vision.
  • Meeting minutes for shared vision building exercises
  • Statements of values and principles
  • Communications strateg
  • Handbook for new members of the project
  • Presentations to relevant stakeholders
    • Reviews of project and individual activities and tasks for alignment with the project's shared vision.
  • The shared vision should be communicated, and agreement and commitment of the relevant stakeholders should be obtained.
Goal 4: Organize Integrated Teams for IPPD.:
Practice 4.1 - Determine the integrated team structure that will best meet the project objectives and constraints.
  • Integrated team structures based on the WBS and adaptations
  • Selected integrated team structure
  • Assessments of the product and product architectures, including risk and complexity
  • Alternative concepts for integrated team structures that include responsibilities, scope, and interfaces.
  • The team structure should be based on understanding of the shared visions at both the organizational and project levels
Practice 4.2 - Develop a preliminary distribution of requirements, responsibilities, authorities, tasks, and interfaces to teams in the selected integrated team structure.
  • Preliminary distribution of integrated team authorities and responsibilities
  • Preliminary distribution of the work product requirements, technical interfaces, and business (e.g., cost accounting, project management) interfaces each integrated team will be responsibilities for satisfying.
  • Traceability matrix allocating requirements to integrated teams
  • Task matrix allocating responsibilities to integrated teams.
  • The preliminary distribution of requirements to integrated teams is done before any teams are formed to verify that the selected team structure is workable and covers all the necessary requirements, responsibilities, authorities, tasks, and interfaces.
Practice 4.3 - Establish and maintain teams in the integrated team structure.
  • A list of project integrated teams
  • Responsibilities and authorities for each integrated team
  • New integrated team structures (for corrective actions).
  • List of team leaders
  • Requirements allocated to each integrated team
  • Measures for evaluating the performance of integrated teams
  • Quality assurance reports] (for integrated teams)
  • Periodic status reports] (on integrated team performance)
    • esources (e.g. budget) allocated to integrated teams.

[To top of Page]

RM - Risk Management

Practice Area
Basic & Advanced Maturity		ArtifactsConsiderations
DirectIndirect
Goal 1: Preparation for risk management is conductedN
Practice 1.1 - Determine risk sources and categories.
  • Risk sources lists (external and internal)
  • Risk categories list.
  • Risk taxonomy or hierarchy (e.g., risk classes, elements, attributes)
  • Risk management plan and procedures
  • Risk management tool or database
  • Risk categorization guidelines (e.g., source, impact types).
  • Risk categories reflect the 'bins' for collecting and organizing risks.
  • This may include an organizational standard risk taxonomy, which might be tailored for application to the specific projects. The initial set of identified sources and categories may be refined as the project progresses
  • The risk sources and categories may be contained in a risk management plan or inherent in a risk management tool.
Practice 1.2 - Define the parameters used to analyze and categorize risks, and the parameters used to control the risk management effort.
  • Risk evaluation, categorization, and prioritization criteria
  • Risk management requirements (control and approval levels, reassessment intervals, etc.).
  • Risk management plan and procedures
  • Risk management tool or database
  • Defined ranges and parameters for risk evaluation, categorization, and prioritization, such as risk likelihood (probability), consequence (severity)
  • Defined thresholds (e.g., control points, scoping boundary conditions, exclusions, triggers) and criteria for taking action.
  • Risk priority may be defined as a combination of risk probability and severity
  • These risk parameters may be defined at the organizational level, or might be tailored for application to specific projects.
  • Thresholds can be defined separately for each risk category, or could be defined on a project-wide basis (e.g., variance thresholds)
  • Risk parameters and thresholds may be defined and applied on a quantitative or qualitative basis.
Practice 1.3 - Establish and maintain the strategy to be used for risk management.
  • Project risk management strategy
  • Risk management plan
  • Revisions to the risk management strategy.
  • Evidence of reviews of the risk management strategy held with project stakeholders (e.g., signature approval, minutes, action items)
  • Measures identified for monitoring risk status
  • Risk management procedures and tools
  • Description and application of risk mitigation techniques (prototyping, simulation, etc.).
  • The risk management strategy is often documented in an organizational or project risk management plan. This may include the risk sources and categories (Practice 1.1-1) and risk parameters (Practice 1.2-1) to be used.
  • The risk management plan may be a standalone document, or its content reflected in other existing project plans.
  • Work products and artifacts produced by the practices covered under goals 2 and 3 can be used to substantiate the establishment and maintenance of the practices associated with goal 1.
Goal 2: Risks are identified and analyzed to determine their relative importance.
Practice 2.1 - Identify and document the risks.
  • List of identified risks, including the context, conditions, and consequences for occurrence
  • Revisions to list of identified risks.
  • Structured risk statements
  • Risk assessment results or evidence of occurrence
  • Risk taxonomy-based questionnaire interviews.
  • Reference Project Planning Practice 2.2-1 for additional information about identifying project risks. The risk sources, categories, and parameters defined here in Practice 1.1 and 1.2 provide a structured mechanism for the systematic identification of risks. This is a potential distinction from risk identification in Project Planning Practice 2.2-1, which may be performed more informally.
  • Coverage of risks (cost, schedule, performance) should be ensured across appropriate product life-cycle phases
  • A risk management tool or database may be used to capture and manage identified risks
  • Look to see that this is an ongoing activity performed across the project lifecycle, i.e., not just a one-time identification of risks, but reviewed and maintained over time.
Practice 2.2 - Evaluate and categorize each identified risk using the defined risk categories and parameters, and determine its relative priority.
  • List of risks, with a priority assigned to each risk
    • Categorization and parameter values of identified risks.
  • Aggregated and consolidated set of risks, with cause and effect relationships identified between related risks
  • Project reviews or briefings of risks and risk parameters
  • Criteria used to quantify risks and assign risk parameters.
  • Derived measures for identified risks (e.g., risk exposure).
  • Risks are evaluated, categorized, and analyzed according to the categories and parameters defined in practices 1.1 and 1.2.
  • Risks may be evaluated using quantitative or qualitative criteria
  • Like risk identification, these are not simply one-time activities, and should be continuously applied across the product life cycle.
  • Relative priority is typically determined using a combination of assigned risk parameters (e.g., severity, likelihood, timeframe). This should be described in the risk management plan.
  • Different risk management terminology may be commonly used within the organization. Consider typical synonyms in determining implementation of this practice; e.g. risk assessment, risk analysis, likelihood vs. probability, consequence vs. impact, risk exposure vs. risk priority.
Goal 3: Risks are handled and mitigated, where appropriate, to reduce adverse impacts on achieving objectives.
Practice 3.1 - Develop a risk mitigation plan for the most important risks to the project, as defined by the risk management strategy.
  • Risk mitigation plans
  • Contingency plans.
  • Documented handling options for each identified risk
  • List of those responsible for tracking and addressing each risk
    • Risk levels and thresholds defined to trigger deployment of risk mitigation plans.
    • Risk mitigation cost/benefit tradeoff analyses
    • Management reserve budget allocation for deployment of risk mitigation plans.
  • See Practice 1.3 for components of the risk management strategy applicable to risk mitigation, e.g., parameters, thresholds, methods, tools.
  • A critical component of a risk mitigation plan is to develop alternative courses of action, workarounds, and fallback positions, with a recommended course of action for each critical risk.
  • Not all risks require mitigation. Mitigation plans are often generated only for selected risks of high consequence; other risks may be accepted and simply monitored.
  • Mitigation plans in this context include risk reduction plans and/or contingency plans. Different terms may be used in the organization, such as risk handling or risk action plans.
  • Thresholds and triggers for deployment of mitigation plans may be contained in the risk management strategy/plan, or may be specific to individual risk items.
  • Look for the realistic budgeting and allocation of resources to mitigation plans; plans without resources are not meaningful.
  • Look for ongoing risk monitoring and risk mitigation across the project life cycle.
Practice 3.2 Monitor the status of each risk periodically and implement the risk mitigation plan as appropriate.
  • Updated lists of risk status
  • Updated assessments of risk likelihood, consequence, and thresholds
    • Implemented risk mitigation actions or contingency plans.
  • Updated lists of risk-handling options
  • Updated list of actions taken to handle risks
  • Risk mitigation plans
    • Risk status reports, analyses, performance measures, trending.
    • Evidence of risk management status reviews (periodic and event-driven)
    • Newly identified risks
    • Risk handling actions, tracked to closure.
  • Risk monitoring and status reviews of all risks should be performed at the intervals defined by the risk management strategy. Monitoring should continue even after initiation of risk mitigation activities.
  • Inspect risk items to ensure deployment of mitigation plans upon exceeding defined thresholds or criteria.
  • Implementation of risk mitigation plans should be checked: - check commitment of resources invested toward risk mitigation (e.g. staffing, schedule, tools).

[To top of Page]

IT - Integrated Teaming

Practice Area
Basic & Advanced Maturity		ArtifactsConsiderations
DirectIndirect
Goal 1: 1 A team composition that provides the knowledge and skills required to deliver the team's product is established and maintained.
Practice 1.1 - Identify and define the team's specific internal tasks to generate the team's expected output.
  • Descriptions of internal work tasks
  • List of results the team is expected to achieve for all work tasks.
  • See Intgrated Project Management Practice 4.2 and 4.3 for background or project level information needed for the identification of team tasks
Practice 1.2 - Identify the knowledge, skills, and functional expertise needed to perform team tasks.
  • List of the knowledge, key skills, and critical expertise
  • List of disciplines or functions required to perform the tasks
  • Initial profiles of team skills and knowledge for the core team and the extended team
    • Skill gaps and training needs.
  • Involve Human Resources to obtain lists of job competencies and employees with these particular skills and competencies
  • See Organizational Training Practice 1.1-1 for more information on organizational strategic training needs
  • Staffing a team is similar to staffing a project, just at a lower level (See the Project Planning Practice 2.5-1)
  • The skill mix needs may vary at different phases in the work product life cycle.
Practice 1.3 - Assign the appropriate personnel to be team members based on required knowledge and skills.
  • List of team members
    • Assessment or adjustment of current team membership relative to the documented knowledge and skills needed.
  • Set of selection criteria
  • Revised skills matrix and knowledge profiles
  • List of the level of effort and resources, including access to staff, to perform each team function
    • Databases or records of potential team members and their skills and knowledge
    • Assessment of team's capability to meet its objectives based on the initial staffing.
  • Note that this goal requires the team composition to be "established and maintained", even though this is not explicit in the practices. Team composition and skill mix should be considered throughout the product life cycle and adjusted as necessary when conditions change.
Goal 2: Operation of the integrated team is governed according to established principles.
Practice 2.1 - Establish and maintain a shared vision for the integrated team that is aligned with any overarching or higher level vision.
  • Documented shared vision
    • Revision history for the integrated team's shared vision.
  • Boundary conditions and interfaces within which the team must operate
  • Presentation materials of the shared-vision statement suitable for team members and various audiences that need to be informed
    • Evaluations of the integrated team's shared vision relative to current conditions or constraints
    • Minutes from meetings at which the integrated team's shared vision is developed or reviewed
    • Documented agreement and commitment to the integrated team's shared vision.
Practice 2.2 - Establish and maintain a team charter based on the integrated team's shared vision and overall team objectives.
  • Team charter
    • Team charter revision history
    • Signature of sponsor and team members expressing commitment to the team charter.
  • Procedures for setting the expectations for the work to be done and for measuring team performance
  • List of critical success factors
  • List of specific strategies the team expects to employ
    • List of team objectives
    • Records, such as meeting minutes, documenting team participation in process of establishing a charter.
  • The team charter is the contract among team members and between the team and its sponsor for the expected work effort and level of performance
  • See Organizational Environment for Integration Practices 2.1-1, 2.2-1, 2.3 for guidelines on decision-making, rewards and recognition, and on balancing home and organization responsibilities that may be relevant to parts of the team charter.
Practice 2.3 - Clearly define and maintain each team member's roles and responsibilities.
  • Descriptions of roles and responsibilities
  • Assignment statements
  • Responsibility matrix
    • Mapping of roles, responsibilities, and expertise of the team members to the team tasks and expected deliverables.
  • Records of team member work assignments and team member work outputs which are consistent with the defined roles and responsibilities
    • Team organization chart and reporting relationships.
 
Practice 2.4 - Establish and maintain integrated team operating procedures
  • Operating procedures and ground rules
    • Operating procedures revision history.
  • Procedures for work expectations and performance measures
    • Records, such as meeting minutes, documenting team participation in process of defining operating procedures
    • Reviews or measures substantiating that team operating procedures are followed.
  • See Organizational Environment for Integration Practice 2.1 - Establish Leadership Mechanisms for more information about establishing a process for setting the context for decision making and for resolving conflicts and differences of opinion
Practice 2.5 - Establish and maintain collaboration among interfacing teams.
  • Work product and process deployment charts
  • Input to the integrated master plan and integrated schedules
    • Definition and tracking of dependencies among teams
  • Commitment lists
  • Team work plans
    • Minutes from commitment meetings
    • Minutes from collaborative reviews attended by interfacing teams (e.g., design reviews, peer reviews, status meetings)

[To top of Page]

ISM - Integrated Supplier Management

Practice Area
Basic & Advanced Maturity		ArtifactsConsiderations
DirectIndirect
Goal 1: Potential sources of products that best fit the needs of the project are identified, analyzed, and selected
Practice 1.1 - Identify and analyze potential sources of products that may be used to satisfy the project's requirements.
  • List of potential sources of products that might be acquired
  • Market studies
  • Trade studies
  • Information about potential sources such as past performance, post-delivery support, corporate viability, and risks.
  • Integrated Supplier Management is not required for projects using off-the-shelf items that are generally available and that are not modified in any wayN.
  • The term "source" refers to a potential supplier or suppliers before selection
  • This practice is critically tied to Supplier Agreement Management Practice (SAM) 1.2-1. To distinguish this practice from SAM, look for examples of proactively monitoring the marketplace to identify potential sources of products prior to selecting a supplier. The set of Direct/Indirect Artifacts that satisfy this practice may also apply to SAM Practice 1.2-1 and vice-versa.
Practice 1.2 - Use a formal evaluation process to determine which sources of custom-made and off-the-shelf products to use.
  • Analysis and evaluation reports
  • Revised list of product sources
  • Supplier comparison matrix
  • Evaluation criteria
  • Supplier surveys
  • Advantages and disadvantages of suppliers.
  • This pratice is critically tied to SAM Practice 1.2-1. It provides guidance to proactively identify suppliers that best fit the needs of the project. The set of Direct/Indirect Artifacts that satisfy this practice may also apply to SAM Practice 1.2-1 and vice-versa.
Goal 2: Work is coordinated with suppliers to ensure the supplier agreement is executed appropriately.
Practice 2.1 - Monitor and analyze selected processes used by the supplier
  • List of processes selected for monitoring
  • Activity reports
  • Performance reports
  • Performance curves
  • Discrepancy reports
    • Trend analyses performed on supplier processes.
  • Action items for noncompliance issues, tracked to closure
    • Criteria and checklists used for process evaluations (e.g. what, when, how, who); may include sampling criteria
    • Schedule for performing process evaluations (planned, actual) at selected milestones throughout the Supplier Agreement period of performance.
  • This practice augments SAM Practice 2.2-1 by providing more guidance for monitoring selected supplier processes to proactively detect problems as early in the product life cycle as possible. The set of Direct/Indirect Artifacts that satisfy this practice may also apply to SAM Practice 2.2-1 and vice-versa.
  • The supplier agreement that results from SAM Practice 1.3-1 would typically specify what processes are monitored.
Practice 2.2 - For custom-made products, evaluate selected supplier work products.
  • List of work products selected for monitoring
  • Activity reports
  • Discrepancy reports
  • Action items for deficiencies, tracked to closure
    • Criteria and checklists used for work product evaluations (e.g. what, when, how, who); may include sampling criteria.
    • Schedule for performing work product evaluations (planned, actual) at selected milestones throughout the supplier agreement period of performance.
  • This Practice augments SAM Practice 2.2-1 by providing more detail for monitoring selected supplier work products to proactively detect problems as early in the product life cycle as possible. The set of Direct/Indirect Artifacts that satisfy this practice may also apply to SAM Practice 2.2-1 and vice-versa.
  • The supplier agreement that results from SAM Practice 1.3-1 would typically specify what work products are evaluated.
Practice 2.3 - Revise the supplier agreement or relationship, as appropriate, to reflect changes in conditions
  • Revisions to the supplier agreement
    • Stakeholder agreement and commitment to the revised supplier agreement
  • Revisions to the project's and supplier's processes and work products
  • The distinction here between this practice and SAM (Practices 1.3 and 2.2-1) includes proactively monitoring not only supplier performance and risks, but also the marketplace for additional sources of supply and adjusting the project-supplier relationship as appropriate.
  • These revisions are to the supplier agreement generated in SAM Practice 1.3-1

[To top of Page]

QPM - Quantitative Project Management

Practice Area
Basic & Advanced Maturity		ArtifactsConsiderations
DirectIndirect
Goal 1: Quantitatively Manage the Project
Practice 1.1 - Establish and maintain the project’s quality and process performance objectives.
  • Project’s quality and process-performance objectives
  • Quality and process performance attributes - Functionality, Reliability, Maintainability, Usability, Duration, Predictability, Timeliness, Accuracy
  • organization’s quality and process-performance objectives
  • lifecycle objectives
  • Objectives traceability matrixes
    • Requirements
    • Organization's quality and process-performance objectives
    • Customer's quality and process-performance objectives
    • Business objectives
    • Discussions with customers and potential customers
    • Market surveys
  • Supplier quality and process-performance objectives.
Practice 1.2 - Compose the Defined Process
  • Criteria used in identifying which sub-processes are valid candidates for inclusion in the project’s defined process
  • Candidate sub-processes for inclusion in the project’s defined process
  • Sub-processes to be included in the project’s defined process
  • Identified risks when selected sub-processes lack a process performance history
  • criteria used to identify which subprocesses have quanitfiable objective include:
    • Quality and process-performance objectives
    • Existence of process-performance data
    • Product line standards
    • Project life-cycle models
    • Customer requirements
    • Laws and regulations
  • sub-process which are statistically managed may have a history of Stable performance in previous comparable instances and/or Process performance data that satisfies the project's quality and process-performance objectivesN
  • Results of analyzsis of the interaction of sub-processesN - analysis techniques include system dynamics models and simulations.
  • Sub-processes are identified from the process elements in the organization's set of standard processes and the process artifacts in the organization's process asset library
  • Reference the Integrated Project Management process area for more information about establishing and maintaining the project’s defined process.
  • Reference the Organizational Process Definition process area for more information about the organization’s process asset library, which might include a process element of known and needed capability.
  • Reference the Organizational Process Performance process area for more information about the organization’s process performance baselines and process performance models
Practice 1.3 - Select the Subprocesses that Will Be Statistically ManagedN
  • Quality and process-performance objectives that will be addressed by statistical management
  • Criteria used in selecting which subprocesses will be statistically managed
  • Sub-processes that will be statistically managed
  • Identified process and product attributes of the selected sub-processes that should be measured and controlled.
  • Sources for criteria used in selecting subprocesses include:
    • Customer requirements related to quality and process performance
    • Quality and process-performance objectives established by the customer and the organization
    • Organization’s performance baselines and models
    • Stable performance of the sub-process on other projects
    • Laws and regulations.
  • Product and process attributes:
  • Selecting the sub-processes to be statistically managed is often a concurrent and iterative process of identifying applicable project and organization quality and process-performance objectives, selecting the subprocesses, and identifying the process and product attributes to measure and control.
  • Often the selection of a process, quality and process-performance objective, or measurable attribute will constrain the selection of the other twoN.
Practice 1.4 - Manage Project Performance
  • Estimates (predictions) of the achievement of the project’s quality and process-performance objectives
  • Documentation of the risks in achieving the project’s quality and process-performance objectives
  • Documentation of actions needed to address the deficiencies in achieving the project’s objectives
  • Sub-process’ established quality and process-performance objectives
  • Appraisals of the progress toward achieving the project’s quality and process-performance objectives
  • Suppliers' results
  • Results of process performance modelsN
  • Risk analysis of parameters associated with achieving the project’s quality and process-performance objectives
  • Documentation on actions needed to address the deficiencies in achieving the project’s quality and process-performance objectives.
Goal 2: Statistically Manage Sub-process Performance
Practice 2.1 - Select Measures and Analytic Techniques
  • Definitions of the measures and analytic techniques to be used in statistically managing the sub-processes
  • Operational definitions of the measures, their collection points in the sub-processes, and how the integrity of the measures will be determined
  • Traceability of measures back to the project’s quality and process-performance objectives
  • Instrumented organizational support environment to support automatic data collection
  • Common measures that support statistical management from the organizational process assets
  • Additional measures that are needed to cover critical product and process attributes and are managable statistically:
    • Requirements volatility
    • Ratios of estimated to measured values of the planning parameters (e.g., size, cost, and schedule)
    • Coverage and efficiency of peer reviews
    • Test coverage and efficiency
    • Effectiveness of training (e.g., percent of planned training completed and test scores)
    • Reliability
    • Percentage of the total defects inserted or found in the different phases of the project life cycle
    • Percentage of the total effort expended in the different phases of the project life cycle
    • Operational definitionsN
    • Analyses of the relationship of the identified measures to the organization’s and project’s objectives
    • policies and practcies with regard to instrumentation and balanced scorecards
  • Operational definitions should be stated in precise and unambiguous terms and should address two important criteria:
    • Communication: What has been measured, how it was measured, what the units of measure are, and what has been included or excluded
    • Repeatability: Whether the measurement can be repeated, given the same definition, to get the same results
  • What makes a particular statistical technique appropriate is not just the type of measures, but more importantly, how the measures will be used and whether the situation warrants applying that technique. The appropriateness of the selection may need to be investigated from time to time
  • Reference the Organizational Process Definition process area for more information about common measures.
Practice 2.2 - Apply Statistical Methods to Understand Variation
  • Collected measures
  • Natural bounds of process performance for each measured attribute of each selected sub-process
  • Process performance compared to the natural bounds of process performance for each measured attribute of each selected sub-process
  • Possible sources of anomalous patterns of variation:
    • Lack of process compliance
    • Undistinguished influences of multiple underlying subprocesses on the data
    • Ordering or timing of activities within the subprocess
    • Uncontrolled inputs to the sub-process
    • Environmental changes during sub-process execution
    • Schedule pressure
    • Inappropriate sampling or grouping of data
  • Process performance data
  • Identifed special causes of variationN
  • results of techniques for analyzing the reasons for special causes of variation:
  • Understanding variation is achieved, in part, by collecting and analyzing process and product measures so that special causes of variation can be identified and addressed to achieve predictable performance
  • Natural bounds of an attribute are the range within which variation normally occurs. All processes will show some variation in process and product measures each time they are executed. The issue is whether this variation is due to common causes of variation in the normal performance of the process or to some special cause that can and should be identified and removed.
  • The criteria for detecting special causes of variation are based on statistical theory and experience and depend on economic justification. As criteria are added, special causes are more likely to be identified if present, but the likelihood of false alarms also increases
  • A special cause of process variation is characterized by an unexpected change in process performance. Special causes are also known as “assignable causes” because they can be identified, analyzed, and addressed to prevent recurrence
  • The identification of special causes of variation is based on departures from the system of common causes of variation. These departures can be identified by the presence of extreme values, or other identifiable patterns in the data collected from the subprocess or associated work products. Knowledge of variation and insight about potential sources of anomalous patterns are typically needed to detect special causes of variation
  • Reference Measurement and Analysis process area for more information about collecting, analyzing, and using measure results
  • Reference the Organizational Process Performance process area for more information about organizational process performance baselines.
Practice 2.3 - Monitor Performance of the Selected Sub-processes
  • Natural bounds of process performance for each selected sub-process compared to its established (derived) objectives
  • For each sub-process, its process capability
  • For each sub-process, the actions needed to address deficiencies in its process capability.
  • Comparisons of the quality and process-performance objectives to the natural bounds of the measured attribute
  • documentation and actions to remove sub-process capability deficiencies
  • Corrective action may include renegotiating the affected project objectives, identifying and implementing alternative sub-processes, or identifying and measuring lower level sub-processes to achieve greater detail in the performance data
  • A prerequisite for comparing the capability of a selected sub-process against its quality and process-performance objectives is that the performance of the sub-process is ,em>stable and predictable with respect to its measured attributes
  • Process capability is analyzed for those sub-processes and those measured attributes for which (derived) objectives have been established.
  • Not all sub-processes or measured attributes that are statistically managed are analyzed regarding process capability
  • The historical data may be inadequate for initially determining whether the sub-process is capable. It also is possible that the estimated natural bounds for sub-process performance may shift away from the quality and process-performance objectives. In either case, statistical control implies monitoring capability as well as stability.
  • Examples of actions that can be taken when a selected subprocess’ performance does not satisfy its objectives:
    • Changing quality and process-performance objectives so that they are within the subprocess’ process capability
    • Improving the implementation of the existing sub-process so as to reduce its normal variability (reducing variability may bring the natural bounds within the objectives without having to move the mean)
    • Adopting new process elements and sub-processes and technologies that have the potential for satisfying the objectives and managing the associated risks
    • Identifying risks and risk mitigation strategies for each subprocess’ process capability deficiency
  • Reference the Project Monitoring and Control process area for more information about taking corrective action.
Practice 2.4 - Record Statistical Management Data
  • Statistical and quality management data recorded in the organization’s measurement repository
 

[To top of Page]

Visit my web site