Purpose
The purpose of Project Planning (PP) is to establish and maintain plans that define project activities.
Introductory Notes
The Project Planning process area involves the following:
· Developing the project plan
· Interacting with stakeholders appropriately
· Getting commitment to the plan
· Maintaining the plan
Planning begins with requirements that define the product and project.
Planning includes estimating the attributes of the work products and tasks, determining the resources needed, negotiating commitments, producing a schedule, and identifying and analyzing project risks. Iterating through these activities may be necessary to establish the project plan. The project plan provides the basis for performing and controlling the project’s activities that address the commitments with the project’s customer.
The project plan will usually need to be revised as the project progresses to address changes in requirements and commitments, inaccurate estimates, corrective actions, and process changes. Specific practices describing both planning and replanning are contained in this process area.
The term “project plan” is used throughout the generic and specific practices in this process area to refer to the overall plan for controlling the project.
Related Process Areas
Refer to the Requirements Development process area for more information about developing requirements that define the product and product components. Product and product component requirements and changes to those requirements serve as a basis for planning and replanning.
Refer to the Requirements Management process area for more information about managing requirements needed for planning and replanning.
Refer to the Risk Management process area for more information about identifying and managing risks.
Refer to the Technical Solution process area for more information about transforming requirements into product and product component solutions.
Specific Goal and Practice Summary
SG 1 Establish Estimates
SP 1.1 Estimate the Scope of the Project
SP 1.2 Establish Estimates of Work Product and Task Attributes
SP 1.3 Define Project Lifecycle
SP 1.4 Determine Estimates of Effort and Cost
SG 2 Develop a Project Plan
SP 2.1 Establish the Budget and Schedule
SP 2.2 Identify Project Risks
SP 2.3 Plan for Data Management
SP 2.4 Plan for Project Resources
SP 2.5 Plan for Needed Knowledge and Skills
SP 2.6 Plan Stakeholder Involvement
SP 2.7 Establish the Project Plan
SG 3 Obtain Commitment to the Plan
SP 3.1 Review Plans That Affect the Project
SP 3.2 Reconcile Work and Resource Levels
SP 3.3 Obtain Plan Commitment
SG 1 Establish Estimates
Estimates of project planning parameters are established and maintained.
Project planning parameters include all information needed by the project to perform the necessary planning, organizing, staffing, directing, coordinating, reporting, and budgeting.
Estimates of planning parameters should have a sound basis to instill confidence that any plans based on these estimates are capable of supporting project objectives.
Factors that are typically considered when estimating these parameters include the following:
· Project requirements, including the product requirements, the requirements imposed by the organization, the requirements imposed by the customer, and other requirements that impact the project
· Scope of the project
· Identified tasks and work products
· Technical approach
· Selected project lifecycle model (e.g., waterfall, incremental, or spiral)
· Attributes of the work products and tasks (e.g., size or complexity)
· Schedule
· Models or historical data for converting the attributes of the work products and tasks into labor hours and cost
· Methodology (e.g., models, data, algorithms) used to determine needed material, skills, labor hours, and cost
Documentation of the estimating rationale and supporting data is needed for stakeholders’ review and commitment to the plan and for maintenance of the plan as the project progresses.
SP 1.1 Estimate the Scope of the Project
Establish a top-level work breakdown structure (WBS) to estimate the scope of the project.
The WBS evolves with the project. Initially a top-level WBS can serve to structure the initial estimating. The development of a WBS divides the overall project into an interconnected set of manageable components. Typically, the WBS is a product oriented structure that provides a scheme for identifying and organizing the logical units of work to be managed, which are called “work packages.” The WBS provides a reference and organizational mechanism for assigning effort, schedule, and responsibility and is used as the underlying framework to plan, organize, and control the work done on the project. Some projects use the term “contract WBS” to refer to the portion of the WBS placed under contract (possibly the entire WBS). Not all projects have a contract WBS (e.g., internally funded development).
Typical Work Products
1. Task descriptions
2. Work package descriptions
3. WBS
Subpractices
1. Develop a WBS based on the product architecture.
The WBS provides a scheme for organizing the project’s work around the product and product components that the work supports. The WBS should permit the identification of the following items:
· Identified risks and their mitigation tasks
· Tasks for deliverables and supporting activities
· Tasks for skill and knowledge acquisition
· Tasks for development of needed support plans, such as configuration management, quality assurance, and verification plans
· Tasks for integration and management of nondevelopmental items
2. Identify the work packages in sufficient detail to specify estimates of project tasks, responsibilities, and schedule.
The top-level WBS is intended to help in gauging the project work effort in terms of tasks and organizational roles and responsibilities. The amount of detail in the WBS at this more detailed level helps in developing realistic schedules, thereby minimizing the need for management reserve.
3. Identify product or product components that will be externally acquired.
Refer to the Supplier Agreement Management process area for more information about acquiring products from sources external to the project.
4. Identify work products that will be reused.
SP 1.2 Establish Estimates of Work Product and Task Attributes
Establish and maintain estimates of the attributes of the work products and tasks.
Size is the primary input to many models used to estimate effort, cost, and schedule. The models can also be based on inputs such as connectivity, complexity, and structure.
Examples of types of work products for which size estimates are made include the following:
· Deliverable and nondeliverable work products
· Documents and files
· Operational and support hardware, firmware, and software
Examples of size measures include the following:
· Number of functions
· Function points
· Source lines of code
· Number of classes and objects
· Number of requirements
· Number and complexity of interfaces
· Number of pages
· Number of inputs and outputs
· Number of technical risk items
· Volume of data
· Number of logic gates for integrated circuits
· Number of parts (e.g., printed circuit boards, components, and mechanical parts)
· Physical constraints (e.g., weight and volume)
The estimates should be consistent with project requirements to determine the project’s effort, cost, and schedule. A relative level of difficulty or complexity should be assigned for each size attribute.
Typical Work Products
1. Technical approach
2. Size and complexity of tasks and work products
3. Estimating models
4. Attribute estimates
Subpractices
1. Determine the technical approach for the project.
The technical approach defines a top-level strategy for development of the product. It includes decisions on architectural features, such as distributed or client/server; state-of-the-art or established technologies to be applied, such as robotics, composite materials, or artificial intelligence; and breadth of the functionality expected in the final products, such as safety, security, and ergonomics.
2. Use appropriate methods to determine the attributes of the work products and tasks that will be used to estimate the resource requirements.
Methods for determining size and complexity should be based on validated models or historical data.
The methods for determining attributes evolve as our understanding of the relationship of product characteristics to attributes increases.
Examples of current methods include the following:
· Number of logic gates for integrated circuit design
· Lines of code or function points for software
· Number/complexity of requirements for systems engineering
· Number of square feet for standard-specified residential homes
3. Estimate the attributes of the work products and tasks.
SP 1.3 Define Project Lifecycle
Define the project lifecycle phases on which to scope the planning effort.
The determination of a project’s lifecycle phases provides for planned periods of evaluation and decision making. These are normally defined to support logical decision points at which significant commitments are made concerning resources and technical approach. Such points provide planned events at which project course corrections and determinations of future scope and cost can be made.
The project lifecycle phases need to be defined depending on the scope of requirements, the estimates for project resources, and the nature of the project. Larger projects may contain multiple phases, such as concept exploration, development, production, operations, and disposal. Within these phases, subphases may be needed. A development phase may include subphases such as requirements analysis, design, fabrication, integration, and verification. The determination of project phases typically includes selection and refinement of one or more development models to address interdependencies and appropriate sequencing of the activities in the phases.
Depending on the strategy for development, there may be intermediate phases for the creation of prototypes, increments of capability, or spiral model cycles.
Understanding the project lifecycle is crucial in determining the scope of the planning effort and the timing of the initial planning, as well as the timing and criteria (critical milestones) for replanning.
Typical Work Products
1. Project lifecycle phases
SP 1.4 Determine Estimates of Effort and Cost
Estimate the project effort and cost for the work products and tasks based on estimation rationale.
Estimates of effort and cost are generally based on the results of analysis using models or historical data applied to size, activities, and other planning parameters. Confidence in these estimates is based on the rationale for the selected model and the nature of the data. There may be occasions when the available historical data does not apply, such as where efforts are unprecedented or where the type of task does not fit available models. An effort is unprecedented (to some degree) if a similar product or component has never been built. An effort may also be unprecedented if the development group has never built such a product or component.
Unprecedented efforts are more risky, require more research to develop reasonable bases of estimate, and require more management reserve. The uniqueness of the project must be documented when using these models to ensure a common understanding of any assumptions made in the initial planning stages.
Typical Work Products
1. Estimation rationale
2. Project effort estimates
3. Project cost estimates
Subpractices
1. Collect the models or historical data that will be used to transform the attributes of the work products and tasks into estimates of the labor hours and cost.
Many parametric models have been developed to aid in estimating cost and schedule. The use of these models as the sole source of estimation is not recommended because these models are based on historical project data that may or may not be pertinent to your project. Multiple models and/or methods can be used to ensure a high level of confidence in the estimate.
Historical data include the cost, effort, and schedule data from previously executed projects, plus appropriate scaling data to account for differing sizes and complexity.
2. Include supporting infrastructure needs when estimating effort and cost.
The supporting infrastructure includes resources needed from a development and sustainment perspective for the product.
Consider the infrastructure resource needs in the development environment, the test environment, the production environment, the target environment, or any appropriate combination of these when estimating effort and cost.
Examples of infrastructure resources include the following:
· Critical computer resources (e.g., memory, disk and network capacity, peripherals, communication channels, and the capacities of these)
· Engineering environments and tools (e.g., tools for prototyping, assembly, computer-aided design [CAD], and simulation)
· Facilities, machinery, and equipment (e.g., test benches and recording devices)
3. Estimate effort and cost using models and/or historical data.
Effort and cost inputs used for estimating typically include the following:
· Judgmental estimates provided by an expert or group of experts (e.g., Delphi Method)
· Risks, including the extent to which the effort is unprecedented
· Critical competencies and roles needed to perform the work
· Product and product component requirements
· Technical approach
· WBS
· Size estimates of work products and anticipated changes
· Cost of externally acquired products
· Selected project lifecycle model and processes
· Lifecycle cost estimates
· Capability of tools provided in engineering environment
· Skill levels of managers and staff needed to perform the work
· Knowledge, skill, and training needs
· Facilities needed (e.g., office and meeting space and workstations)
· Engineering facilities needed
· Capability of manufacturing process(es)
· Travel
· Level of security required for tasks, work products, hardware, software, personnel, and work environment
· Service level agreements for call centers and warranty work
· Direct labor and overhead
SG 2 Develop a Project Plan
A project plan is established and maintained as the basis for managing the project.
A project plan is a formal, approved document used to manage and control the execution of the project. It is based on the project requirements and the established estimates.
The project plan should consider all phases of the project lifecycle. Project planning should ensure that all plans affecting the project are consistent with the overall project plan.
SP 2.1 Establish the Budget and Schedule
Establish and maintain the project’s budget and schedule.
The project’s budget and schedule are based on the developed estimates and ensure that budget allocation, task complexity, and task dependencies are appropriately addressed.
Event-driven, resource-limited schedules have proven to be effective in dealing with project risk. Identifying accomplishments to be demonstrated before initiation of the event provides some flexibility in the timing of the event, a common understanding of what is expected, a better vision of the state of the project, and a more accurate status of the project’s tasks.
Typical Work Products
1. Project schedules
2. Schedule dependencies
3. Project budget
Subpractices
1. Identify major milestones.
Milestones are often imposed to ensure completion of certain deliverables by the milestone. Milestones can be event based or calendar based. If calendar based, once milestone dates have been agreed on, it is often very difficult to change them.
2. Identify schedule assumptions.
When schedules are initially developed, it is common to make assumptions about the duration of certain activities. These assumptions are frequently made on items for which little if any estimation data is available. Identifying these assumptions provides insight into the level of confidence (uncertainties) in the overall schedule.
3. Identify constraints.
Factors that limit the flexibility of management options need to be identified as early as possible. The examination of the attributes of the work products and tasks often will bring these issues to the surface. Such attributes can include task duration, resources, inputs, and outputs.
4. Identify task dependencies.
Typically, the tasks for a project can be accomplished in some ordered sequence that will minimize the duration of the project. This involves the identification of predecessor and successor tasks to determine the optimal ordering.
Examples of tools that can help determine an optimal ordering of task activities include the following:
· Critical Path Method (CPM)
· Program Evaluation and Review Technique (PERT)
· Resource-limited scheduling
5. Define the budget and schedule.
Establishing and maintaining the project’s budget and schedule typically includes the following:
· Defining the committed or expected availability of resources and facilities
· Determining time phasing of activities
· Determining a breakout of subordinate schedules
· Defining the dependencies between the activities (predecessor or successor relationships)
· Defining the schedule activities and milestones to support accuracy in progress measurement
· Identifying milestones for delivery of products to the customer
· Defining activities of appropriate duration
· Defining milestones of appropriate time separation
· Defining a management reserve based on the confidence level in meeting the schedule and budget
· Using appropriate historical data to verify the schedule
· Defining incremental funding requirements
· Documenting project assumptions and rationale
6. Establish corrective action criteria.
Criteria are established for determining what constitutes a significant deviation from the project plan. A basis for gauging issues and problems is necessary to determine when a corrective action should be taken. The corrective actions may require replanning, which may include revising the original plan, establishing new agreements, or including mitigation activities within the current plan.
SP 2.2 Identify Project Risks
Identify and analyze project risks.
Refer to the Risk Management process area for more information about risk management activities.
Refer to the Monitor Project Risks specific practice in the Project Monitoring and Control process area for more information about risk monitoring activities.
Risks are identified or discovered and analyzed to support project planning. This specific practice should be extended to all the plans that affect the project to ensure that the appropriate interfacing is taking place between all relevant stakeholders on identified risks. Project planning risk identification and analysis typically include the following:
· Identifying risks
· Analyzing the risks to determine the impact, probability of occurrence, and time frame in which problems are likely to occur
· Prioritizing risks
Typical Work Products
1. Identified risks
2. Risk impacts and probability of occurrence
3. Risk priorities
Subpractices
1. Identify risks.
The identification of risks involves the identification of potential issues, hazards, threats, vulnerabilities, and so on that could negatively affect work efforts and plans. Risks must be identified and described in an understandable way before they can be analyzed. When identifying risks, it is a good idea to use a standard method for defining risks. Risk identification and analysis tools can be used to help identify possible problems.
Examples of risk identification and analysis tools include the following:
· Risk taxonomies
· Risk assessments
· Checklists
· Structured interviews
· Brainstorming
· Performance models
· Cost models
· Network analysis
· Quality factor analysis
2. Document the risks.
3. Review and obtain agreement with relevant stakeholders on the completeness and correctness of the documented risks.
4. Revise the risks as appropriate.
Examples of when identified risks may need to be revised include the following:
· When new risks are identified
· When risks become problems
· When risks are retired
· When project circumstances change significantly
SP 2.3 Plan for Data Management
Plan for the management of project data.
IPPD Addition
When integrated teams are formed, project data includes data developed and used solely within a particular team as well as data applicable across integrated team boundaries, if there are multiple integrated teams.
Data are the various forms of documentation required to support a program in all of its areas (e.g., administration, engineering, configuration management, finance, logistics, quality, safety, manufacturing, and procurement). The data can take any form (e.g., reports, manuals, notebooks, charts, drawings, specifications, files, or correspondence). The data may exist in any medium (e.g., printed or drawn on various materials, photographs, electronic, or multimedia). Data may be deliverable (e.g., items identified by a program’s contract data requirements) or data may be nondeliverable (e.g., informal data, trade studies and analyses, internal meeting minutes, internal design review documentation, lessons learned, and action items). Distribution can take many forms, including electronic transmission.
The data requirements for the project should be established for both the data items to be created and their content and form, based on a common or standard set of data requirements. Uniform content and format requirements for data items facilitate understanding of data content and help with consistent management of the data resources.
The reason for collecting each document should be clear. This task includes the analysis and verification of project deliverables and nondeliverables, contract and noncontract data requirements, and customer-supplied data. Often, data is collected with no clear understanding of how it will be used. Data is costly and should be collected only when needed.
Typical Work Products
1. Data management plan
2. Master list of managed data
3. Data content and format description
4. Data requirements lists for acquirers and for suppliers
5. Privacy requirements
6. Security requirements
7. Security procedures
8. Mechanism for data retrieval, reproduction, and distribution
9. Schedule for collection of project data
10. Listing of project data to be collected
Subpractices
1. Establish requirements and procedures to ensure privacy and security of the data.
Not everyone will have the need or clearance necessary to access the project data. Procedures must be established to identify who has access to what data as well as when they have access to the data.
2. Establish a mechanism to archive data and to access archived data.
Accessed information should be in an understandable form (e.g., electronic or computer output from a database) or represented as originally generated.
3. Determine the project data to be identified, collected, and distributed.
SP 2.4 Plan for Project Resources
Plan for necessary resources to perform the project.
IPPD Addition
When integrated teams are formed, planning for project resources should consider staffing of the integrated teams.
Defining project resources (labor, machinery/equipment, materials, and methods) and quantities needed to perform project activities builds on the initial estimates and provides additional information that can be applied to expand the WBS used to manage the project.
The top-level WBS developed earlier as an estimation mechanism is typically expanded by decomposing these top levels into work packages that represent singular work units that can be separately assigned, performed, and tracked. This subdivision is done to distribute management responsibility and provide better management control. Each work package or work product in the WBS should be assigned a unique identifier (e.g., number) to permit tracking. A WBS can be based on requirements, activities, work products, or a combination of these items. A dictionary that describes the work for each work package in the WBS should accompany the work breakdown structure.
Typical Work Products
1. WBS work packages
2. WBS task dictionary
3. Staffing requirements based on project size and scope
4. Critical facilities/equipment list
5. Process/workflow definitions and diagrams
6. Program administration requirements list
Subpractices
1. Determine process requirements.
The processes used to manage a project must be identified, defined, and coordinated with all the relevant stakeholders to ensure efficient operations during project execution.
2. Determine staffing requirements.
The staffing of a project depends on the decomposition of the project requirements into tasks, roles, and responsibilities for accomplishing the project requirements as laid out within the work packages of the WBS.
Staffing requirements must consider the knowledge and skills required for each of the identified positions, as defined in the Plan for Needed Knowledge and Skills specific practice.
3. Determine facilities, equipment, and component requirements.
Most projects are unique in some sense and require some set of unique assets to accomplish the objectives of the project. The determination and acquisition of these assets in a timely manner are crucial to project success.
Lead-time items need to be identified early to determine how they will be addressed. Even when the required assets are not unique, compiling a list of all of the facilities, equipment, and parts (e.g., number of computers for the personnel working on the project, software applications, and office space) provides insight into aspects of the scope of an effort that are often overlooked.
SP 2.5 Plan for Needed Knowledge and Skills
Plan for knowledge and skills needed to perform the project.
Refer to the Organizational Training process area for more information about knowledge and skills information to be incorporated into the project plan.
Knowledge delivery to projects involves both training of project personnel and acquisition of knowledge from outside sources.
Staffing requirements are dependent on the knowledge and skills available to support the execution of the project.
Typical Work Products
1. Inventory of skill needs
2. Staffing and new hire plans
3. Databases (e.g., skills and training)
Subpractices
1. Identify the knowledge and skills needed to perform the project.
2. Assess the knowledge and skills available.
3. Select mechanisms for providing needed knowledge and skills.
Example mechanisms include the following:
· In-house training (both organizational and project)
· External training
· Staffing and new hires
· External skill acquisition
The choice of in-house training or outsourced training for the needed knowledge and skills is determined by the availability of training expertise, the project’s schedule, and the business objectives.
4. Incorporate selected mechanisms into the project plan.
SP 2.6 Plan Stakeholder Involvement
Plan the involvement of identified stakeholders.
IPPD Addition
When integrated teams are formed, stakeholder involvement should be planned down to the integrated team level.
Stakeholders are identified from all phases of the project lifecycle by identifying the type of people and functions needing representation in the project and describing their relevance and the degree of interaction for specific project activities. A two-dimensional matrix with stakeholders along one axis and project activities along the other axis is a convenient format for accomplishing this identification. Relevance of the stakeholder to the activity in a particular project phase and the amount of interaction expected would be shown at the intersection of the project phase activity axis and the stakeholder axis.
For the inputs of stakeholders to be useful, careful selection of relevant stakeholders is necessary. For each major activity, identify the stakeholders who are affected by the activity and those who have expertise that is needed to conduct the activity. This list of relevant stakeholders will probably change as the project moves through the phases of the project lifecycle. It is important, however, to ensure that relevant stakeholders in the latter phases of the lifecycle have early input to requirements and design decisions that affect them.
Examples of the type of material that should be included in a plan for stakeholder interaction include the following:
· List of all relevant stakeholders
· Rationale for stakeholder involvement
· Roles and responsibilities of the relevant stakeholders with respect to the project, by project lifecycle phase
· Relationships between stakeholders
· Relative importance of the stakeholder to success of the project, by project lifecycle phase
· Resources (e.g., training, materials, time, and funding) needed to ensure stakeholder interaction
· Schedule for phasing of stakeholder interaction
Conduct of this specific practice relies on shared or exchanged information with the previous Plan for Needed Knowledge and Skills specific practice.
Typical Work Products
1. Stakeholder involvement plan
SP 2.7 Establish the Project Plan
Establish and maintain the overall project plan content.
A documented plan that addresses all relevant planning items is necessary to achieve the mutual understanding, commitment, and performance of individuals, groups, and organizations that must execute or support the plans. The plan generated for the project defines all aspects of the effort, tying together in a logical manner: project lifecycle considerations; technical and management tasks; budgets and schedules; milestones; data management, risk identification, resource and skill requirements; and stakeholder identification and interaction. Infrastructure descriptions include responsibility and authority relationships for project staff, management, and support organizations.
For Software Engineering
For software, the planning document is often referred to as one of the following:
· Software development plan
· Software project plan
· Software plan
For Hardware Engineering
For hardware, the planning document is often referred to as a hardware development plan. Development activities in preparation for production may be included in the hardware development plan or defined in a separate production plan.
Examples of plans that have been used in the U.S. Department of Defense community include the following:
· Integrated Master Plan—an event-driven plan that documents significant accomplishments with pass/fail criteria for both business and technical elements of the project and that ties each accomplishment to a key program event.
· Integrated Master Schedule—an integrated and networked multi-layered schedule of program tasks required to complete the work effort documented in a related Integrated Master Plan.
· Systems Engineering Management Plan—a plan that details the integrated technical effort across the project.
· Systems Engineering Master Schedule—an event-based schedule that contains a compilation of key technical accomplishments, each with measurable criteria, requiring successful completion to pass identified events.
· Systems Engineering Detailed Schedule—a detailed, time-dependent, task-oriented schedule that associates specific dates and milestones with the Systems Engineering Master Schedule.
Typical Work Products
1. Overall project plan
SG 3 Obtain Commitment to the Plan
Commitments to the project plan are established and maintained.
To be effective, plans require commitment by those responsible for implementing and supporting the plan.
SP 3.1 Review Plans That Affect the Project
Review all plans that affect the project to understand project commitments.
IPPD Addition
When integrated teams are formed, their integrated work plans are among the plans to review.
Plans developed within other process areas will typically contain information similar to that called for in the overall project plan. These plans may provide additional detailed guidance and should be compatible with and support the overall project plan to indicate who has the authority, responsibility, accountability, and control. All plans that affect the project should be reviewed to ensure a common understanding of the scope, objectives, roles, and relationships that are required for the project to be successful. Many of these plans are described by the Plan the Process generic practice in each of the process areas.
Typical Work Products
1. Record of the reviews of plans that affect the project
SP 3.2 Reconcile Work and Resource Levels
Reconcile the project plan to reflect available and estimated resources.
IPPD Addition
When integrated teams are formed, special attention should be paid to resource commitments in circumstances of distributed integrated teams and when people are on multiple integrated teams in one or more projects.
To establish a project that is feasible, obtain commitment from relevant stakeholders and reconcile any differences between the estimates and the available resources. Reconciliation is typically accomplished by lowering or deferring technical performance requirements, negotiating more resources, finding ways to increase productivity, outsourcing, adjusting the staff skill mix, or revising all plans that affect the project or schedules.
Typical Work Products
1. Revised methods and corresponding estimating parameters (e.g., better tools and use of off-the-shelf components)
2. Renegotiated budgets
3. Revised schedules
4. Revised requirements list
5. Renegotiated stakeholder agreements
SP 3.3 Obtain Plan Commitment
Obtain commitment from relevant stakeholders responsible for performing and supporting plan execution.
IPPD Addition
When integrated teams are formed, the integrated team plans should have buy-in from the team members, the interfacing teams, the project, and the process owners of the standard processes that the team has selected for tailored application.
Obtaining commitment involves interaction among all relevant stakeholders both internal and external to the project. The individual or group making a commitment should have confidence that the work can be performed within cost, schedule, and performance constraints. Often, a provisional commitment is adequate to allow the effort to begin and to permit research to be performed to increase confidence to the appropriate level needed to obtain a full commitment.
Typical Work Products
1. Documented requests for commitments
2. Documented commitments
Subpractices
1. Identify needed support and negotiate commitments with relevant stakeholders.
The WBS can be used as a checklist for ensuring that commitments are obtained for all tasks.
The plan for stakeholder interaction should identify all parties from whom commitment should be obtained.
2. Document all organizational commitments, both full and provisional, ensuring appropriate level of signatories.
Commitments must be documented to ensure a consistent mutual understanding as well as for tracking and maintenance. Provisional commitments should be accompanied by a description of the risks associated with the relationship.
3. Review internal commitments with senior management as appropriate.
4. Review external commitments with senior management as appropriate.
Management may have the necessary insight and authority to reduce risks associated with external commitments.
5. Identify commitments on interfaces between elements in the project, and with other projects and organizational units so that they can be monitored.
Well-defined interface specifications form the basis for commitments.
Wednesday, October 31, 2007
4.15. PROCESS AND PRODUCT QUALITY ASSURANCE
Purpose
The purpose of Process and Product Quality Assurance (PPQA) is to provide staff and management with objective insight into processes and associated work products.
Introductory Notes
The Process and Product Quality Assurance process area involves the following:
· Objectively evaluating performed processes, work products, and services against the applicable process descriptions, standards, and procedures
· Identifying and documenting noncompliance issues
· Providing feedback to project staff and managers on the results of quality assurance activities
· Ensuring that noncompliance issues are addressed
The Process and Product Quality Assurance process area supports the delivery of high-quality products and services by providing the project staff and managers at all levels with appropriate visibility into, and feedback on, processes and associated work products throughout the life of the project.
The practices in the Process and Product Quality Assurance process area ensure that planned processes are implemented, while the practices in the Verification process area ensure that the specified requirements are satisfied. These two process areas may on occasion address the same work product but from different perspectives. Projects should take advantage of the overlap in order to minimize duplication of effort while taking care to maintain the separate perspectives.
Objectivity in process and product quality assurance evaluations is critical to the success of the project. (See the definition of “objectively evaluate” in the glossary.) Objectivity is achieved by both independence and the use of criteria. A combination of methods providing evaluations against criteria by those not producing the work product is often used. Less formal methods can be used to provide broad day-to-day coverage. More formal methods can be used periodically to assure objectivity.
Examples of ways to perform objective evaluations include the following:
· Formal audits by organizationally separate quality assurance organizations
· Peer reviews which may be performed at various levels of formality
· In-depth review of work at the place it is performed (i.e., desk audits)
· Distributed review and comment of work products
Traditionally, a quality assurance group that is independent of the project provides this objectivity. It may be appropriate in some organizations, however, to implement the process and product quality assurance role without that kind of independence. For example, in an organization with an open, quality-oriented culture, the process and product quality assurance role may be performed, partially or completely, by peers; and the quality assurance function may be embedded in the process. For small organizations, this might be the most feasible approach.
If quality assurance is embedded in the process, several issues must be addressed to ensure objectivity. Everyone performing quality assurance activities should be trained in quality assurance. Those performing quality assurance activities for a work product should be separate from those directly involved in developing or maintaining the work product. An independent reporting channel to the appropriate level of organizational management must be available so that noncompliance issues can be escalated as necessary.
For example, in implementing peer reviews as an objective evaluation method:
· Members are trained and roles are assigned for people attending the peer reviews.
· A member of the peer review who did not produce this work product is assigned to perform the role of QA.
· Checklists are available to support the QA activity.
· Defects are recorded as part of the peer review report and are tracked and escalated outside the project when necessary.
Quality assurance should begin in the early phases of a project to establish plans, processes, standards, and procedures that will add value to the project and satisfy the requirements of the project and the organizational policies. Those performing quality assurance participate in establishing the plans, processes, standards, and procedures to ensure that they fit the project’s needs and that they will be useable for performing quality assurance evaluations. In addition, the specific processes and associated work products that will be evaluated during the project are designated. This designation may be based on sampling or on objective criteria that are consistent with organizational policies and project requirements and needs.
When noncompliance issues are identified, they are first addressed within the project and resolved there if possible. Any noncompliance issues that cannot be resolved within the project are escalated to an appropriate level of management for resolution.
This process area applies primarily to evaluations of the activities and work products of a project, but it also applies to evaluations of nonproject activities and work products such as training activities. For these activities and work products, the term “project” should be appropriately interpreted.
Related Process Areas
Refer to the Project Planning process area for more information about identifying processes and associated work products that will be objectively evaluated.
Refer to the Verification process area for more information about satisfying specified requirements.
Specific Goal and Practice Summary
SG 1 Objectively Evaluate Processes and Work Products
SP 1.1 Objectively Evaluate Processes
SP 1.2 Objectively Evaluate Work Products and Services
SG 2 Provide Objective Insight
SP 2.1 Communicate and Ensure Resolution of Noncompliance Issues
SP 2.2 Establish Records
SG 1 Objectively Evaluate Processes and Work Products
Adherence of the performed process and associated work products and services to applicable process descriptions, standards, and procedures is objectively evaluated.
SP 1.1 Objectively Evaluate Processes
Objectively evaluate the designated performed processes against the applicable process descriptions, standards, and procedures.
Objectivity in quality assurance evaluations is critical to the success of the project. A description of the quality assurance reporting chain and how it ensures objectivity should be defined.
Typical Work Products
1. Evaluation reports
2. Noncompliance reports
3. Corrective actions
Subpractices
1. Promote an environment (created as part of project management) that encourages employee participation in identifying and reporting quality issues.
2. Establish and maintain clearly stated criteria for the evaluations.
The intent of this subpractice is to provide criteria, based on business needs, such as the following:
· What will be evaluated
· When or how often a process will be evaluated
· How the evaluation will be conducted
· Who must be involved in the evaluation
3. Use the stated criteria to evaluate performed processes for adherence to process descriptions, standards, and procedures.
4. Identify each noncompliance found during the evaluation.
5. Identify lessons learned that could improve processes for future products and services.
SP 1.2 Objectively Evaluate Work Products and Services
Objectively evaluate the designated work products and services against the applicable process descriptions, standards, and procedures.
Typical Work Products
1. Evaluation reports
2. Noncompliance reports
3. Corrective actions
Subpractices
1. Select work products to be evaluated, based on documented sampling criteria if sampling is used.
2. Establish and maintain clearly stated criteria for the evaluation of work products.
The intent of this subpractice is to provide criteria, based on business needs, such as the following:
· What will be evaluated during the evaluation of a work product
· When or how often a work product will be evaluated
· How the evaluation will be conducted
· Who must be involved in the evaluation
3. Use the stated criteria during the evaluations of work products.
4. Evaluate work products before they are delivered to the customer.
5. Evaluate work products at selected milestones in their development.
6. Perform in-progress or incremental evaluations of work products and services against process descriptions, standards, and procedures.
7. Identify each case of noncompliance found during the evaluations.
8. Identify lessons learned that could improve processes for future products and services.
SG 2 Provide Objective Insight
Noncompliance issues are objectively tracked and communicated, and resolution is ensured.
SP 2.1 Communicate and Ensure Resolution of Noncompliance Issues
Communicate quality issues and ensure resolution of noncompliance issues with the staff and managers.
Noncompliance issues are problems identified in evaluations that reflect a lack of adherence to applicable standards, process descriptions, or procedures. The status of noncompliance issues provides an indication of quality trends. Quality issues include noncompliance issues and results of trend analysis.
When local resolution of noncompliance issues cannot be obtained, use established escalation mechanisms to ensure that the appropriate level of management can resolve the issue. Track noncompliance issues to resolution.
Typical Work Products
1. Corrective action reports
2. Evaluation reports
3. Quality trends
Subpractices
1. Resolve each noncompliance with the appropriate members of the staff where possible.
2. Document noncompliance issues when they cannot be resolved within the project.
Examples of ways to resolve noncompliance within the project include the following:
· Fixing the noncompliance
· Changing the process descriptions, standards, or procedures that were violated
· Obtaining a waiver to cover the noncompliance issue
3. Escalate noncompliance issues that cannot be resolved within the project to the appropriate level of management designated to receive and act on noncompliance issues.
4. Analyze the noncompliance issues to see if there are any quality trends that can be identified and addressed.
5. Ensure that relevant stakeholders are aware of the results of evaluations and the quality trends in a timely manner.
6. Periodically review open noncompliance issues and trends with the manager designated to receive and act on noncompliance issues.
7. Track noncompliance issues to resolution.
SP 2.2 Establish Records
Establish and maintain records of the quality assurance activities.
Typical Work Products
1. Evaluation logs
2. Quality assurance reports
3. Status reports of corrective actions
4. Reports of quality trends
Subpractices
1. Record process and product quality assurance activities in sufficient detail such that status and results are known.
2. Revise the status and history of the quality assurance activities as necessary.
4.16. QUANTITATIVE PROJECT MANAGEMENT
Purpose
The purpose of Quantitative Project Management (QPM) is to quantitatively manage the project’s defined process to achieve the project’s established quality and process-performance objectives.
Introductory Notes
The Quantitative Project Management process area involves the following:
· Establishing and maintaining the project’s quality and process-performance objectives
· Identifying suitable subprocesses that compose the project’s defined process based on historical stability and capability data found in process-performance baselines or models
· Selecting the subprocesses of the project’s defined process to be statistically managed
· Monitoring the project to determine whether the project’s objectives for quality and process performance are being satisfied, and identifying appropriate corrective action
· Selecting the measures and analytic techniques to be used in statistically managing the selected subprocesses
· Establishing and maintaining an understanding of the variation of the selected subprocesses using the selected measures and analytic techniques
· Monitoring the performance of the selected subprocesses to determine whether they are capable of satisfying their quality and process-performance objectives, and identifying corrective action
· Recording statistical and quality management data in the organization’s measurement repository
The quality and process-performance objectives, measures, and baselines identified here are developed as described in the Organizational Process Performance process area. Subsequently, the results of performing the processes associated with the Quantitative Project Management process area (e.g., measurement definitions and measurement data) become part of the organizational process assets referred to in the Organizational Process Performance process area.
To effectively address the specific practices in this process area, the organization should have already established a set of standard processes and related organizational process assets, such as the organization’s measurement repository and the organization’s process asset library for use by each project in establishing its defined process. The project’s defined process is a set of subprocesses that form an integrated and coherent lifecycle for the project. It is established, in part, through selecting and tailoring processes from the organization’s set of standard processes. (See the definition of “defined process” in the glossary.)
The project should also ensure that the measurements and progress of the supplier’s efforts are made available. Establishment of effective relationships with suppliers is necessary for the successful implementation of this process area’s specific practices.
Process performance is a measure of the actual process results achieved. Process performance is characterized by both process measures (e.g., effort, cycle time, and defect removal efficiency) and product measures (e.g., reliability, defect density, and response time).
Subprocesses are defined components of a larger defined process. For example, a typical organization’s development process may be defined in terms of subprocesses such as requirements development, design, build, test, and peer review. The subprocesses themselves may be further decomposed as necessary into other subprocesses and process elements.
One essential element of quantitative management is having confidence in estimates (i.e., being able to predict the extent to which the project can fulfill its quality and process-performance objectives). The subprocesses that will be statistically managed are chosen based on identified needs for predictable performance. (See the definitions of “statistically managed process,” “quality and process-performance objective,” and “quantitatively managed process” in the glossary.)
Another essential element of quantitative management is understanding the nature and extent of the variation experienced in process performance, and recognizing when the project’s actual performance may not be adequate to achieve the project’s quality and process-performance objectives.
Statistical management involves statistical thinking and the correct use of a variety of statistical techniques, such as run charts, control charts, confidence intervals, prediction intervals, and tests of hypotheses. Quantitative management uses data from statistical management to help the project predict whether it will be able to achieve its quality and process-performance objectives and identify what corrective action should be taken.
This process area applies to managing a project, but the concepts found here also apply to managing other groups and functions. Applying these concepts to managing other groups and functions may not necessarily contribute to achieving the organization’s business objectives, but may help these groups and functions control their own processes.
Examples of other groups and functions include the following:
· Quality assurance
· Process definition and improvement
· Effort reporting
· Customer complaint handling
· Problem tracking and reporting
Related Process Areas
Refer to the Project Monitoring and Control process area for more information about monitoring and controlling the project and taking corrective action.
Refer to the Measurement and Analysis process area for more information about establishing measurable objectives, specifying the measures and analyses to be performed, obtaining and analyzing measures, and providing results.
Refer to the Organizational Process Performance process area for more information about the organization’s quality and process-performance objectives, process-performance analyses, process-performance baselines, and process-performance models.
Refer to the Organizational Process Definition process area for more information about the organizational process assets, including the organization’s measurement repository.
Refer to the Integrated Project Management process area for more information about establishing and maintaining the project’s defined process.
Refer to the Causal Analysis and Resolution process area for more information about how to identify the causes of defects and other problems, and taking action to prevent them from occurring in the future.
Refer to the Organizational Innovation and Deployment process area for more information about selecting and deploying improvements that support the organization’s quality and process-performance objectives.
Specific Goal and Practice Summary
SG 1 Quantitatively Manage the Project
SP 1.1 Establish the Project’s Objectives
SP 1.2 Compose the Defined Process
SP 1.3 Select the Subprocesses that Will Be Statistically Managed
SP 1.4 Manage Project Performance
SG 2 Statistically Manage Subprocess Performance
SP 2.1 Select Measures and Analytic Techniques
SP 2.2 Apply Statistical Methods to Understand Variation
SP 2.3 Monitor Performance of the Selected Subprocesses
SP 2.4 Record Statistical Management Data
SG 1 Quantitatively Manage the Project
The project is quantitatively managed using quality and process-performance objectives.
SP 1.1 Establish the Project's Objectives
Establish and maintain the project’s quality and process-performance objectives.
When establishing the project’s quality and process-performance objectives, it is often useful to think ahead about which processes from the organization’s set of standard processes will be included in the project’s defined process, and what the historical data indicates regarding their process performance. These considerations will help in establishing realistic objectives for the project. Later, as the project’s actual performance becomes known and more predictable, the objectives may need to be revised.
Typical Work Products
1. The project’s quality and process-performance objectives
Subpractices
1. Review the organization's objectives for quality and process performance.
The intent of this review is to ensure that the project understands the broader business context in which the project will need to operate. The project’s objectives for quality and process performance are developed in the context of these overarching organizational objectives.
Refer to the Organizational Process Performance process area for more information about the organization’s quality and process-performance objectives.
2. Identify the quality and process performance needs and priorities of the customer, suppliers, end users, and other relevant stakeholders.
Examples of quality and process-performance attributes for which needs and priorities might be identified include the following:
· Functionality
· Reliability
· Maintainability
· Usability
· Duration
· Predictability
· Timeliness
· Accuracy
3. Identify how process performance is to be measured.
Consider whether the measures established by the organization are adequate for assessing progress in fulfilling customer, end-user, and other stakeholder needs and priorities. It may be necessary to supplement these with additional measures.
Refer to the Measurement and Analysis process area for more information about defining measures.
4. Define and document measurable quality and process-performance objectives for the project.
Defining and documenting objectives for the project involve the following:
· Incorporating the organization’s quality and process-performance objectives
· Writing objectives that reflect the quality and process-performance needs and priorities of the customer, end users, and other stakeholders, and the way these objectives should be measured
Examples of quality attributes for which objectives might be written include the following:
· Mean time between failures
· Critical resource utilization
· Number and severity of defects in the released product
· Number and severity of customer complaints concerning the provided service
Examples of process-performance attributes for which objectives might be written include the following:
· Percentage of defects removed by product verification activities (perhaps by type of verification, such as peer reviews and testing)
· Defect escape rates
· Number and density of defects (by severity) found during the first year following product delivery (or start of service)
· Cycle time
· Percentage of rework time
5. Derive interim objectives for each lifecycle phase, as appropriate, to monitor progress toward achieving the project’s objectives.
An example of a method to predict future results of a process is the use of process-performance models to predict the latent defects in the delivered product using interim measures of defects identified during product verification activities (e.g., peer reviews and testing).
6. Resolve conflicts among the project’s quality and process-performance objectives (e.g., if one objective cannot be achieved without compromising another objective).
Resolving conflicts involves the following:
· Setting relative priorities for the objectives
· Considering alternative objectives in light of long-term business strategies as well as short-term needs
· Involving the customer, end users, senior management, project management, and other relevant stakeholders in the tradeoff decisions
· Revising the objectives as necessary to reflect the results of the conflict resolution
7. Establish traceability to the project’s quality and process-performance objectives from their sources.
Examples of sources for objectives include the following:
· 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
An example of a method to identify and trace these needs and priorities is Quality Function Deployment (QFD).
8. Define and negotiate quality and process-performance objectives for suppliers.
Refer to the Supplier Agreement Management process area for more information about establishing and maintaining agreements with suppliers.
9. Revise the project’s quality and process-performance objectives as necessary.
SP 1.2 Compose the Defined Process
Select the subprocesses that compose the project’s defined process based on historical stability and capability data.
Refer to the Integrated Project Management process area for more information about establishing and maintaining the project’s defined process.
Refer to 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.
Refer to the Organizational Process Performance process area for more information about the organization’s process-performance baselines and process-performance models.
Subprocesses 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.
Typical Work Products
1. Criteria used in identifying which subprocesses are valid candidates for inclusion in the project’s defined process
2. Candidate subprocesses for inclusion in the project’s defined process
3. Subprocesses to be included in the project’s defined process
4. Identified risks when selected subprocesses lack a process-performance history
Subpractices
1. Establish the criteria to use in identifying which subprocesses are valid candidates for use.
Identification may be based on the following:
· Quality and process-performance objectives
· Existence of process-performance data
· Product line standards
· Project lifecycle models
· Customer requirements
· Laws and regulations
2. Determine whether the subprocesses that are to be statistically managed, and that were obtained from the organizational process assets, are suitable for statistical management.
A subprocess may be more suitable for statistical management if it has a history of the following:
· Stable performance in previous comparable instances
· Process-performance data that satisfies the project’s quality and process-performance objectives
Historical data are primarily obtained from the organization’s process-performance baselines. However, these data may not be available for all subprocesses.
3. Analyze the interaction of subprocesses to understand the relationships among the subprocesses and the measured attributes of the subprocesses.
Examples of analysis techniques include system dynamics models and simulations.
4. Identify the risk when no subprocess is available that is known to be capable of satisfying the quality and process-performance objectives (i.e., no capable subprocess is available or the capability of the subprocess is not known).
Even when a subprocess has not been selected to be statistically managed, historical data and process-performance models may indicate that the subprocess is not capable of satisfying the quality and process-performance objectives.
Refer to the Risk Management process area for more information about risk identification and analysis.
SP 1.3 Select the Subprocesses that Will Be Statistically Managed
Select the subprocesses of the project's defined process that will be statistically managed.
Selecting the subprocesses 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 two. For example, if a particular process is selected, the measurable attributes and quality and process-performance objectives may be constrained by that process.
Typical Work Products
1. Quality and process-performance objectives that will be addressed by statistical management
2. Criteria used in selecting which subprocesses will be statistically managed
3. Subprocesses that will be statistically managed
4. Identified process and product attributes of the selected subprocesses that should be measured and controlled
Subpractices
1. Identify which of the quality and process-performance objectives of the project will be statistically managed.
2. Identify the criteria to be used in selecting the subprocesses that are the main contributors to achieving the identified quality and process-performance objectives and for which predictable performance is important.
Examples of sources for criteria used in selecting subprocesses include the following:
· Customer requirements related to quality and process performance
· Quality and process-performance objectives established by the customer
· Quality and process-performance objectives established by the organization
· Organization’s performance baselines and models
· Stable performance of the subprocess on other projects
· Laws and regulations
3. Select the subprocesses that will be statistically managed using the selection criteria.
It may not be possible to statistically manage some subprocesses (e.g., where new subprocesses and technologies are being piloted). In other cases, it may not be economically justifiable to apply statistical techniques to certain subprocesses.
4. Identify the product and process attributes of the selected subprocesses that will be measured and controlled.
Examples of product and process attributes include the following:
· Defect density
· Cycle time
· Test coverage
SP 1.4 Manage Project Performance
Monitor the project to determine whether the project’s objectives for quality and process performance will be satisfied, and identify corrective action as appropriate.
Refer to the Measurement and Analysis process area for more information about analyzing and using measures.
A prerequisite for such a comparison is that the selected subprocesses of the project’s defined process are being statistically managed and their process capability is understood. The specific practices of specific goal 2 provide detail on statistically managing the selected subprocesses.
Typical Work Products
1. Estimates (predictions) of the achievement of the project’s quality and process-performance objectives
2. Documentation of the risks in achieving the project’s quality and process-performance objectives
3. Documentation of actions needed to address the deficiencies in achieving the project’s objectives
Subpractices
1. Periodically review the performance of each subprocess and the capability of each subprocess selected to be statistically managed to appraise progress toward achieving the project’s quality and process-performance objectives.
The process capability of each selected subprocess is determined with respect to that subprocess’ established quality and process-performance objectives. These objectives are derived from the project’s quality and process-performance objectives, which are for the project as a whole.
2. Periodically review the actual results achieved against established interim objectives for each phase of the project lifecycle to appraise progress toward achieving the project’s quality and process-performance objectives.
3. Track suppliers’ results for achieving their quality and process-performance objectives.
4. Use process-performance models calibrated with obtained measures of critical attributes to estimate progress toward achieving the project’s quality and process-performance objectives.
Process-performance models are used to estimate progress toward achieving objectives that cannot be measured until a future phase in the project lifecycle. An example is the use of process-performance models to predict the latent defects in the delivered product using interim measures of defects identified during peer reviews.
Refer to the Organizational Process Performance process area for more information about process-performance models.
The calibration is based on the results obtained from performing the previous subpractices.
5. Identify and manage the risks associated with achieving the project’s quality and process-performance objectives.
Refer to the Risk Management process area for more information about identifying and managing risks.
Example sources of the risks include the following:
· Inadequate stability and capability data in the organization’s measurement repository
· Subprocesses having inadequate performance or capability
· Suppliers not achieving their quality and process-performance objectives
· Lack of visibility into supplier capability
· Inaccuracies in the organization’s process-performance models for predicting future performance
· Deficiencies in predicted process performance (estimated progress)
· Other identified risks associated with identified deficiencies
6. Determine and document actions needed to address the deficiencies in achieving the project’s quality and process-performance objectives.
The intent of these actions is to plan and deploy the right set of activities, resources, and schedule to place the project back on track as much as possible to meet its objectives.
Examples of actions that can be taken to address deficiencies in achieving the project’s objectives include the following:
· Changing quality or process-performance objectives so that they are within the expected range of the project’s defined process
· Improving the implementation of the project’s defined process so as to reduce its normal variability (reducing variability may bring the project’s performance within the objectives without having to move the mean)
· Adopting new subprocesses and technologies that have the potential for satisfying the objectives and managing the associated risks
· Identifying the risk and risk mitigation strategies for the deficiencies
· Terminating the project
Refer to the Project Monitoring and Control process area for more information about taking corrective action.
SG 2 Statistically Manage Subprocess Performance
The performance of selected subprocesses within the project's defined process is statistically managed.
This specific goal describes an activity critical to achieving the Quantitatively Manage the Project specific goal of this process area. The specific practices under this specific goal describe how to statistically manage the subprocesses whose selection was described in the specific practices under the first specific goal. When the selected subprocesses are statistically managed, their capability to achieve their objectives can be determined. By these means, it will be possible to predict whether the project will be able to achieve its objectives, which is key to quantitatively managing the project.
SP 2.1 Select Measures and Analytic Techniques
Select the measures and analytic techniques to be used in statistically managing the selected subprocesses.
Refer to the Measurement and Analysis process area for more information about establishing measurable objectives; on defining, collecting, and analyzing measures; and on revising measures and statistical analysis techniques.
Typical Work Products
1. Definitions of the measures and analytic techniques to be used in (or proposed for) statistically managing the subprocesses
2. Operational definitions of the measures, their collection points in the subprocesses, and how the integrity of the measures will be determined
3. Traceability of measures back to the project’s quality and process-performance objectives
4. Instrumented organizational support environment to support automatic data collection
Subpractices
1. Identify common measures from the organizational process assets that support statistical management.
Refer to the Organizational Process Definition process area for more information about common measures.
Product lines or other stratification criteria may categorize common measures.
2. Identify additional measures that may be needed for this instance to cover critical product and process attributes of the selected subprocesses.
In some cases, measures may be research oriented. Such measures should be explicitly identified.
3. Identify the measures that are appropriate for statistical management.
Critical criteria for selecting statistical management measures include the following:
· Controllable (e.g., can a measure’s values be changed by changing how the subprocess is implemented?)
· Adequate performance indicator (e.g., is the measure a good indicator of how well the subprocess is performing relative to the objectives of interest?)
Examples of subprocess measures include the following:
· 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 lifecycle
· Percentage of the total effort expended in the different phases of the project lifecycle
4. Specify the operational definitions of the measures, their collection points in the subprocesses, and how the integrity of the measures will be determined.
Operational definitions are stated in precise and unambiguous terms. They address two important criteria as follows:
· 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
5. Analyze the relationship of the identified measures to the organization’s and project’s objectives, and derive objectives that state specific target measures or ranges to be met for each measured attribute of each selected subprocess.
6. Instrument the organizational support environment to support collection, derivation, and analysis of statistical measures.
The instrumentation is based on the following:
· Description of the organization’s set of standard processes
· Description of the project’s defined process
· Capabilities of the organizational support environment
7. Identify the appropriate statistical analysis techniques that are expected to be useful in statistically managing the selected subprocesses.
The concept of “one size does not fit all” applies to statistical analysis techniques. What makes a particular technique appropriate is not just the type of measures, but more important, 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.
Examples of statistical analysis techniques are given in the next specific practice.
8. Revise the measures and statistical analysis techniques as necessary.
SP 2.2 Apply Statistical Methods to Understand Variation
Establish and maintain an understanding of the variation of the selected subprocesses using the selected measures and analytic techniques.
Refer to the Measurement and Analysis process area for more information about collecting, analyzing, and using measurement results.
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.
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.
Sources of anomalous patterns of variation may include the following:
· 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 subprocess
· Environmental changes during subprocess execution
· Schedule pressure
· Inappropriate sampling or grouping of data
Typical Work Products
1. Collected measures
2. Natural bounds of process performance for each measured attribute of each selected subprocess
3. Process performance compared to the natural bounds of process performance for each measured attribute of each selected subprocess
Subpractices
1. Establish trial natural bounds for subprocesses having suitable historical performance data.
Refer to the Organizational Process Performance process area for more information about organizational process-performance baselines.
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.
When a subprocess is initially executed, suitable data for establishing trial natural bounds are sometimes available from prior instances of the subprocess or comparable subprocesses, process-performance baselines, or process-performance models. These data are typically contained in the organization’s measurement repository. As the subprocess is executed, data specific to that instance are collected and used to update and replace the trial natural bounds. However, if the subprocess in question has been materially tailored, or if the conditions are materially different from those in previous instantiations, the data in the repository may not be relevant and should not be used.
In some cases, there may be no historical comparable data (e.g., when introducing a new subprocess, when entering a new application domain, or when significant changes have been made to the subprocess). In such cases, trial natural bounds will have to be made from early process data of this subprocess. These trial natural bounds must then be refined and updated as subprocess execution continues.
Examples of criteria for determining whether data are comparable include the following:
· Product lines
· Application domain
· Work product and task attributes (e.g., size of product)
· Size of project
2. Collect data, as defined by the selected measures, on the subprocesses as they execute.
3. Calculate the natural bounds of process performance for each measured attribute.
Examples of where the natural bounds are calculated include the following:
· Control charts
· Confidence intervals (for parameters of distributions)
· Prediction intervals (for future outcomes)
4. Identify special causes of variation.
An example of a criterion for detecting a special cause of process variation in a control chart is a data point that falls outside of the 3-sigma control limits.
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.
5. Analyze the special cause of process variation to determine the reasons the anomaly occurred.
Examples of techniques for analyzing the reasons for special causes of variation include the following:
· Cause-and-effect (fishbone) diagrams
· Designed experiments
· Control charts (applied to subprocess inputs or to lower level subprocesses)
· Subgrouping (analyzing the same data segregated into smaller groups based on an understanding of how the subprocess was implemented facilitates isolation of special causes)
Some anomalies may simply be extremes of the underlying distribution rather than problems. The people implementing a subprocess are usually the ones best able to analyze and understand special causes of variation.
6. Determine what corrective action should be taken when special causes of variation are identified.
Removing a special cause of process variation does not change the underlying subprocess. It addresses an error in the way the subprocess is being executed.
Refer to the Project Monitoring and Control process area for more information about taking corrective action.
7. Recalculate the natural bounds for each measured attribute of the selected subprocesses as necessary.
Recalculating the (statistically estimated) natural bounds is based on measured values that signify that the subprocess has changed, not on expectations or arbitrary decisions.
Examples of when the natural bounds may need to be recalculated include the following:
· There are incremental improvements to the subprocess
· New tools are deployed for the subprocess
· A new subprocess is deployed
· The collected measures suggest that the subprocess mean has permanently shifted or the subprocess variation has permanently changed
SP 2.3 Monitor Performance of the Selected Subprocesses
Monitor the performance of the selected subprocesses to determine their capability to satisfy their quality and process-performance objectives, and identify corrective action as necessary.
The intent of this specific practice is to do the following:
· Determine statistically the process behavior expected from the subprocess
· Appraise the probability that the process will meet its quality and process-performance objectives
· Identify the corrective action to be taken, based on a statistical analysis of the process-performance data
Corrective action may include renegotiating the affected project objectives, identifying and implementing alternative subprocesses, or identifying and measuring lower level subprocesses to achieve greater detail in the performance data. Any or all of these actions are intended to help the project use a more capable process. (See the definition of “capable process” in the glossary.)
A prerequisite for comparing the capability of a selected subprocess against its quality and process-performance objectives is that the performance of the subprocess is stable and predictable with respect to its measured attributes.
Process capability is analyzed for those subprocesses and those measured attributes for which (derived) objectives have been established. Not all subprocesses or measured attributes that are statistically managed are analyzed regarding process capability.
The historical data may be inadequate for initially determining whether the subprocess is capable. It also is possible that the estimated natural bounds for subprocess performance may shift away from the quality and process-performance objectives. In either case, statistical control implies monitoring capability as well as stability.
Typical Work Products
1. Natural bounds of process performance for each selected subprocess compared to its established (derived) objectives
2. For each subprocess, its process capability
3. For each subprocess, the actions needed to address deficiencies in its process capability
Subpractices
1. Compare the quality and process-performance objectives to the natural bounds of the measured attribute.
This comparison provides an appraisal of the process capability for each measured attribute of a subprocess. These comparisons can be displayed graphically, in ways that relate the estimated natural bounds to the objectives or as process capability indices, which summarize the relationship of the objectives to the natural bounds.
2. Monitor changes in quality and process-performance objectives and selected subprocess’ process capability.
3. Identify and document subprocess capability deficiencies.
4. Determine and document actions needed to address subprocess capability deficiencies.
Examples of actions that can be taken when a selected subprocess’s performance does not satisfy its objectives include the following:
· Changing quality and process-performance objectives so that they are within the subprocess’ process capability
· Improving the implementation of the existing subprocess 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 subprocesses and technologies that have the potential for satisfying the objectives and managing the associated risks
· Identifying risks and risk mitigation strategies for each subprocess’s process capability deficiency
Refer to the Project Monitoring and Control process area for more information about taking corrective action.
SP 2.4 Record Statistical Management Data
Record statistical and quality management data in the organization’s measurement repository.
Refer to the Measurement and Analysis process area for more information about managing and storing data, measurement definitions, and results.
Refer to the Organizational Process Definition process area for more information about the organization’s measurement repository.
Typical Work Products
1. Statistical and quality management data recorded in the organization’s measurement repository
The purpose of Quantitative Project Management (QPM) is to quantitatively manage the project’s defined process to achieve the project’s established quality and process-performance objectives.
Introductory Notes
The Quantitative Project Management process area involves the following:
· Establishing and maintaining the project’s quality and process-performance objectives
· Identifying suitable subprocesses that compose the project’s defined process based on historical stability and capability data found in process-performance baselines or models
· Selecting the subprocesses of the project’s defined process to be statistically managed
· Monitoring the project to determine whether the project’s objectives for quality and process performance are being satisfied, and identifying appropriate corrective action
· Selecting the measures and analytic techniques to be used in statistically managing the selected subprocesses
· Establishing and maintaining an understanding of the variation of the selected subprocesses using the selected measures and analytic techniques
· Monitoring the performance of the selected subprocesses to determine whether they are capable of satisfying their quality and process-performance objectives, and identifying corrective action
· Recording statistical and quality management data in the organization’s measurement repository
The quality and process-performance objectives, measures, and baselines identified here are developed as described in the Organizational Process Performance process area. Subsequently, the results of performing the processes associated with the Quantitative Project Management process area (e.g., measurement definitions and measurement data) become part of the organizational process assets referred to in the Organizational Process Performance process area.
To effectively address the specific practices in this process area, the organization should have already established a set of standard processes and related organizational process assets, such as the organization’s measurement repository and the organization’s process asset library for use by each project in establishing its defined process. The project’s defined process is a set of subprocesses that form an integrated and coherent lifecycle for the project. It is established, in part, through selecting and tailoring processes from the organization’s set of standard processes. (See the definition of “defined process” in the glossary.)
The project should also ensure that the measurements and progress of the supplier’s efforts are made available. Establishment of effective relationships with suppliers is necessary for the successful implementation of this process area’s specific practices.
Process performance is a measure of the actual process results achieved. Process performance is characterized by both process measures (e.g., effort, cycle time, and defect removal efficiency) and product measures (e.g., reliability, defect density, and response time).
Subprocesses are defined components of a larger defined process. For example, a typical organization’s development process may be defined in terms of subprocesses such as requirements development, design, build, test, and peer review. The subprocesses themselves may be further decomposed as necessary into other subprocesses and process elements.
One essential element of quantitative management is having confidence in estimates (i.e., being able to predict the extent to which the project can fulfill its quality and process-performance objectives). The subprocesses that will be statistically managed are chosen based on identified needs for predictable performance. (See the definitions of “statistically managed process,” “quality and process-performance objective,” and “quantitatively managed process” in the glossary.)
Another essential element of quantitative management is understanding the nature and extent of the variation experienced in process performance, and recognizing when the project’s actual performance may not be adequate to achieve the project’s quality and process-performance objectives.
Statistical management involves statistical thinking and the correct use of a variety of statistical techniques, such as run charts, control charts, confidence intervals, prediction intervals, and tests of hypotheses. Quantitative management uses data from statistical management to help the project predict whether it will be able to achieve its quality and process-performance objectives and identify what corrective action should be taken.
This process area applies to managing a project, but the concepts found here also apply to managing other groups and functions. Applying these concepts to managing other groups and functions may not necessarily contribute to achieving the organization’s business objectives, but may help these groups and functions control their own processes.
Examples of other groups and functions include the following:
· Quality assurance
· Process definition and improvement
· Effort reporting
· Customer complaint handling
· Problem tracking and reporting
Related Process Areas
Refer to the Project Monitoring and Control process area for more information about monitoring and controlling the project and taking corrective action.
Refer to the Measurement and Analysis process area for more information about establishing measurable objectives, specifying the measures and analyses to be performed, obtaining and analyzing measures, and providing results.
Refer to the Organizational Process Performance process area for more information about the organization’s quality and process-performance objectives, process-performance analyses, process-performance baselines, and process-performance models.
Refer to the Organizational Process Definition process area for more information about the organizational process assets, including the organization’s measurement repository.
Refer to the Integrated Project Management process area for more information about establishing and maintaining the project’s defined process.
Refer to the Causal Analysis and Resolution process area for more information about how to identify the causes of defects and other problems, and taking action to prevent them from occurring in the future.
Refer to the Organizational Innovation and Deployment process area for more information about selecting and deploying improvements that support the organization’s quality and process-performance objectives.
Specific Goal and Practice Summary
SG 1 Quantitatively Manage the Project
SP 1.1 Establish the Project’s Objectives
SP 1.2 Compose the Defined Process
SP 1.3 Select the Subprocesses that Will Be Statistically Managed
SP 1.4 Manage Project Performance
SG 2 Statistically Manage Subprocess Performance
SP 2.1 Select Measures and Analytic Techniques
SP 2.2 Apply Statistical Methods to Understand Variation
SP 2.3 Monitor Performance of the Selected Subprocesses
SP 2.4 Record Statistical Management Data
SG 1 Quantitatively Manage the Project
The project is quantitatively managed using quality and process-performance objectives.
SP 1.1 Establish the Project's Objectives
Establish and maintain the project’s quality and process-performance objectives.
When establishing the project’s quality and process-performance objectives, it is often useful to think ahead about which processes from the organization’s set of standard processes will be included in the project’s defined process, and what the historical data indicates regarding their process performance. These considerations will help in establishing realistic objectives for the project. Later, as the project’s actual performance becomes known and more predictable, the objectives may need to be revised.
Typical Work Products
1. The project’s quality and process-performance objectives
Subpractices
1. Review the organization's objectives for quality and process performance.
The intent of this review is to ensure that the project understands the broader business context in which the project will need to operate. The project’s objectives for quality and process performance are developed in the context of these overarching organizational objectives.
Refer to the Organizational Process Performance process area for more information about the organization’s quality and process-performance objectives.
2. Identify the quality and process performance needs and priorities of the customer, suppliers, end users, and other relevant stakeholders.
Examples of quality and process-performance attributes for which needs and priorities might be identified include the following:
· Functionality
· Reliability
· Maintainability
· Usability
· Duration
· Predictability
· Timeliness
· Accuracy
3. Identify how process performance is to be measured.
Consider whether the measures established by the organization are adequate for assessing progress in fulfilling customer, end-user, and other stakeholder needs and priorities. It may be necessary to supplement these with additional measures.
Refer to the Measurement and Analysis process area for more information about defining measures.
4. Define and document measurable quality and process-performance objectives for the project.
Defining and documenting objectives for the project involve the following:
· Incorporating the organization’s quality and process-performance objectives
· Writing objectives that reflect the quality and process-performance needs and priorities of the customer, end users, and other stakeholders, and the way these objectives should be measured
Examples of quality attributes for which objectives might be written include the following:
· Mean time between failures
· Critical resource utilization
· Number and severity of defects in the released product
· Number and severity of customer complaints concerning the provided service
Examples of process-performance attributes for which objectives might be written include the following:
· Percentage of defects removed by product verification activities (perhaps by type of verification, such as peer reviews and testing)
· Defect escape rates
· Number and density of defects (by severity) found during the first year following product delivery (or start of service)
· Cycle time
· Percentage of rework time
5. Derive interim objectives for each lifecycle phase, as appropriate, to monitor progress toward achieving the project’s objectives.
An example of a method to predict future results of a process is the use of process-performance models to predict the latent defects in the delivered product using interim measures of defects identified during product verification activities (e.g., peer reviews and testing).
6. Resolve conflicts among the project’s quality and process-performance objectives (e.g., if one objective cannot be achieved without compromising another objective).
Resolving conflicts involves the following:
· Setting relative priorities for the objectives
· Considering alternative objectives in light of long-term business strategies as well as short-term needs
· Involving the customer, end users, senior management, project management, and other relevant stakeholders in the tradeoff decisions
· Revising the objectives as necessary to reflect the results of the conflict resolution
7. Establish traceability to the project’s quality and process-performance objectives from their sources.
Examples of sources for objectives include the following:
· 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
An example of a method to identify and trace these needs and priorities is Quality Function Deployment (QFD).
8. Define and negotiate quality and process-performance objectives for suppliers.
Refer to the Supplier Agreement Management process area for more information about establishing and maintaining agreements with suppliers.
9. Revise the project’s quality and process-performance objectives as necessary.
SP 1.2 Compose the Defined Process
Select the subprocesses that compose the project’s defined process based on historical stability and capability data.
Refer to the Integrated Project Management process area for more information about establishing and maintaining the project’s defined process.
Refer to 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.
Refer to the Organizational Process Performance process area for more information about the organization’s process-performance baselines and process-performance models.
Subprocesses 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.
Typical Work Products
1. Criteria used in identifying which subprocesses are valid candidates for inclusion in the project’s defined process
2. Candidate subprocesses for inclusion in the project’s defined process
3. Subprocesses to be included in the project’s defined process
4. Identified risks when selected subprocesses lack a process-performance history
Subpractices
1. Establish the criteria to use in identifying which subprocesses are valid candidates for use.
Identification may be based on the following:
· Quality and process-performance objectives
· Existence of process-performance data
· Product line standards
· Project lifecycle models
· Customer requirements
· Laws and regulations
2. Determine whether the subprocesses that are to be statistically managed, and that were obtained from the organizational process assets, are suitable for statistical management.
A subprocess may be more suitable for statistical management if it has a history of the following:
· Stable performance in previous comparable instances
· Process-performance data that satisfies the project’s quality and process-performance objectives
Historical data are primarily obtained from the organization’s process-performance baselines. However, these data may not be available for all subprocesses.
3. Analyze the interaction of subprocesses to understand the relationships among the subprocesses and the measured attributes of the subprocesses.
Examples of analysis techniques include system dynamics models and simulations.
4. Identify the risk when no subprocess is available that is known to be capable of satisfying the quality and process-performance objectives (i.e., no capable subprocess is available or the capability of the subprocess is not known).
Even when a subprocess has not been selected to be statistically managed, historical data and process-performance models may indicate that the subprocess is not capable of satisfying the quality and process-performance objectives.
Refer to the Risk Management process area for more information about risk identification and analysis.
SP 1.3 Select the Subprocesses that Will Be Statistically Managed
Select the subprocesses of the project's defined process that will be statistically managed.
Selecting the subprocesses 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 two. For example, if a particular process is selected, the measurable attributes and quality and process-performance objectives may be constrained by that process.
Typical Work Products
1. Quality and process-performance objectives that will be addressed by statistical management
2. Criteria used in selecting which subprocesses will be statistically managed
3. Subprocesses that will be statistically managed
4. Identified process and product attributes of the selected subprocesses that should be measured and controlled
Subpractices
1. Identify which of the quality and process-performance objectives of the project will be statistically managed.
2. Identify the criteria to be used in selecting the subprocesses that are the main contributors to achieving the identified quality and process-performance objectives and for which predictable performance is important.
Examples of sources for criteria used in selecting subprocesses include the following:
· Customer requirements related to quality and process performance
· Quality and process-performance objectives established by the customer
· Quality and process-performance objectives established by the organization
· Organization’s performance baselines and models
· Stable performance of the subprocess on other projects
· Laws and regulations
3. Select the subprocesses that will be statistically managed using the selection criteria.
It may not be possible to statistically manage some subprocesses (e.g., where new subprocesses and technologies are being piloted). In other cases, it may not be economically justifiable to apply statistical techniques to certain subprocesses.
4. Identify the product and process attributes of the selected subprocesses that will be measured and controlled.
Examples of product and process attributes include the following:
· Defect density
· Cycle time
· Test coverage
SP 1.4 Manage Project Performance
Monitor the project to determine whether the project’s objectives for quality and process performance will be satisfied, and identify corrective action as appropriate.
Refer to the Measurement and Analysis process area for more information about analyzing and using measures.
A prerequisite for such a comparison is that the selected subprocesses of the project’s defined process are being statistically managed and their process capability is understood. The specific practices of specific goal 2 provide detail on statistically managing the selected subprocesses.
Typical Work Products
1. Estimates (predictions) of the achievement of the project’s quality and process-performance objectives
2. Documentation of the risks in achieving the project’s quality and process-performance objectives
3. Documentation of actions needed to address the deficiencies in achieving the project’s objectives
Subpractices
1. Periodically review the performance of each subprocess and the capability of each subprocess selected to be statistically managed to appraise progress toward achieving the project’s quality and process-performance objectives.
The process capability of each selected subprocess is determined with respect to that subprocess’ established quality and process-performance objectives. These objectives are derived from the project’s quality and process-performance objectives, which are for the project as a whole.
2. Periodically review the actual results achieved against established interim objectives for each phase of the project lifecycle to appraise progress toward achieving the project’s quality and process-performance objectives.
3. Track suppliers’ results for achieving their quality and process-performance objectives.
4. Use process-performance models calibrated with obtained measures of critical attributes to estimate progress toward achieving the project’s quality and process-performance objectives.
Process-performance models are used to estimate progress toward achieving objectives that cannot be measured until a future phase in the project lifecycle. An example is the use of process-performance models to predict the latent defects in the delivered product using interim measures of defects identified during peer reviews.
Refer to the Organizational Process Performance process area for more information about process-performance models.
The calibration is based on the results obtained from performing the previous subpractices.
5. Identify and manage the risks associated with achieving the project’s quality and process-performance objectives.
Refer to the Risk Management process area for more information about identifying and managing risks.
Example sources of the risks include the following:
· Inadequate stability and capability data in the organization’s measurement repository
· Subprocesses having inadequate performance or capability
· Suppliers not achieving their quality and process-performance objectives
· Lack of visibility into supplier capability
· Inaccuracies in the organization’s process-performance models for predicting future performance
· Deficiencies in predicted process performance (estimated progress)
· Other identified risks associated with identified deficiencies
6. Determine and document actions needed to address the deficiencies in achieving the project’s quality and process-performance objectives.
The intent of these actions is to plan and deploy the right set of activities, resources, and schedule to place the project back on track as much as possible to meet its objectives.
Examples of actions that can be taken to address deficiencies in achieving the project’s objectives include the following:
· Changing quality or process-performance objectives so that they are within the expected range of the project’s defined process
· Improving the implementation of the project’s defined process so as to reduce its normal variability (reducing variability may bring the project’s performance within the objectives without having to move the mean)
· Adopting new subprocesses and technologies that have the potential for satisfying the objectives and managing the associated risks
· Identifying the risk and risk mitigation strategies for the deficiencies
· Terminating the project
Refer to the Project Monitoring and Control process area for more information about taking corrective action.
SG 2 Statistically Manage Subprocess Performance
The performance of selected subprocesses within the project's defined process is statistically managed.
This specific goal describes an activity critical to achieving the Quantitatively Manage the Project specific goal of this process area. The specific practices under this specific goal describe how to statistically manage the subprocesses whose selection was described in the specific practices under the first specific goal. When the selected subprocesses are statistically managed, their capability to achieve their objectives can be determined. By these means, it will be possible to predict whether the project will be able to achieve its objectives, which is key to quantitatively managing the project.
SP 2.1 Select Measures and Analytic Techniques
Select the measures and analytic techniques to be used in statistically managing the selected subprocesses.
Refer to the Measurement and Analysis process area for more information about establishing measurable objectives; on defining, collecting, and analyzing measures; and on revising measures and statistical analysis techniques.
Typical Work Products
1. Definitions of the measures and analytic techniques to be used in (or proposed for) statistically managing the subprocesses
2. Operational definitions of the measures, their collection points in the subprocesses, and how the integrity of the measures will be determined
3. Traceability of measures back to the project’s quality and process-performance objectives
4. Instrumented organizational support environment to support automatic data collection
Subpractices
1. Identify common measures from the organizational process assets that support statistical management.
Refer to the Organizational Process Definition process area for more information about common measures.
Product lines or other stratification criteria may categorize common measures.
2. Identify additional measures that may be needed for this instance to cover critical product and process attributes of the selected subprocesses.
In some cases, measures may be research oriented. Such measures should be explicitly identified.
3. Identify the measures that are appropriate for statistical management.
Critical criteria for selecting statistical management measures include the following:
· Controllable (e.g., can a measure’s values be changed by changing how the subprocess is implemented?)
· Adequate performance indicator (e.g., is the measure a good indicator of how well the subprocess is performing relative to the objectives of interest?)
Examples of subprocess measures include the following:
· 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 lifecycle
· Percentage of the total effort expended in the different phases of the project lifecycle
4. Specify the operational definitions of the measures, their collection points in the subprocesses, and how the integrity of the measures will be determined.
Operational definitions are stated in precise and unambiguous terms. They address two important criteria as follows:
· 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
5. Analyze the relationship of the identified measures to the organization’s and project’s objectives, and derive objectives that state specific target measures or ranges to be met for each measured attribute of each selected subprocess.
6. Instrument the organizational support environment to support collection, derivation, and analysis of statistical measures.
The instrumentation is based on the following:
· Description of the organization’s set of standard processes
· Description of the project’s defined process
· Capabilities of the organizational support environment
7. Identify the appropriate statistical analysis techniques that are expected to be useful in statistically managing the selected subprocesses.
The concept of “one size does not fit all” applies to statistical analysis techniques. What makes a particular technique appropriate is not just the type of measures, but more important, 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.
Examples of statistical analysis techniques are given in the next specific practice.
8. Revise the measures and statistical analysis techniques as necessary.
SP 2.2 Apply Statistical Methods to Understand Variation
Establish and maintain an understanding of the variation of the selected subprocesses using the selected measures and analytic techniques.
Refer to the Measurement and Analysis process area for more information about collecting, analyzing, and using measurement results.
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.
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.
Sources of anomalous patterns of variation may include the following:
· 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 subprocess
· Environmental changes during subprocess execution
· Schedule pressure
· Inappropriate sampling or grouping of data
Typical Work Products
1. Collected measures
2. Natural bounds of process performance for each measured attribute of each selected subprocess
3. Process performance compared to the natural bounds of process performance for each measured attribute of each selected subprocess
Subpractices
1. Establish trial natural bounds for subprocesses having suitable historical performance data.
Refer to the Organizational Process Performance process area for more information about organizational process-performance baselines.
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.
When a subprocess is initially executed, suitable data for establishing trial natural bounds are sometimes available from prior instances of the subprocess or comparable subprocesses, process-performance baselines, or process-performance models. These data are typically contained in the organization’s measurement repository. As the subprocess is executed, data specific to that instance are collected and used to update and replace the trial natural bounds. However, if the subprocess in question has been materially tailored, or if the conditions are materially different from those in previous instantiations, the data in the repository may not be relevant and should not be used.
In some cases, there may be no historical comparable data (e.g., when introducing a new subprocess, when entering a new application domain, or when significant changes have been made to the subprocess). In such cases, trial natural bounds will have to be made from early process data of this subprocess. These trial natural bounds must then be refined and updated as subprocess execution continues.
Examples of criteria for determining whether data are comparable include the following:
· Product lines
· Application domain
· Work product and task attributes (e.g., size of product)
· Size of project
2. Collect data, as defined by the selected measures, on the subprocesses as they execute.
3. Calculate the natural bounds of process performance for each measured attribute.
Examples of where the natural bounds are calculated include the following:
· Control charts
· Confidence intervals (for parameters of distributions)
· Prediction intervals (for future outcomes)
4. Identify special causes of variation.
An example of a criterion for detecting a special cause of process variation in a control chart is a data point that falls outside of the 3-sigma control limits.
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.
5. Analyze the special cause of process variation to determine the reasons the anomaly occurred.
Examples of techniques for analyzing the reasons for special causes of variation include the following:
· Cause-and-effect (fishbone) diagrams
· Designed experiments
· Control charts (applied to subprocess inputs or to lower level subprocesses)
· Subgrouping (analyzing the same data segregated into smaller groups based on an understanding of how the subprocess was implemented facilitates isolation of special causes)
Some anomalies may simply be extremes of the underlying distribution rather than problems. The people implementing a subprocess are usually the ones best able to analyze and understand special causes of variation.
6. Determine what corrective action should be taken when special causes of variation are identified.
Removing a special cause of process variation does not change the underlying subprocess. It addresses an error in the way the subprocess is being executed.
Refer to the Project Monitoring and Control process area for more information about taking corrective action.
7. Recalculate the natural bounds for each measured attribute of the selected subprocesses as necessary.
Recalculating the (statistically estimated) natural bounds is based on measured values that signify that the subprocess has changed, not on expectations or arbitrary decisions.
Examples of when the natural bounds may need to be recalculated include the following:
· There are incremental improvements to the subprocess
· New tools are deployed for the subprocess
· A new subprocess is deployed
· The collected measures suggest that the subprocess mean has permanently shifted or the subprocess variation has permanently changed
SP 2.3 Monitor Performance of the Selected Subprocesses
Monitor the performance of the selected subprocesses to determine their capability to satisfy their quality and process-performance objectives, and identify corrective action as necessary.
The intent of this specific practice is to do the following:
· Determine statistically the process behavior expected from the subprocess
· Appraise the probability that the process will meet its quality and process-performance objectives
· Identify the corrective action to be taken, based on a statistical analysis of the process-performance data
Corrective action may include renegotiating the affected project objectives, identifying and implementing alternative subprocesses, or identifying and measuring lower level subprocesses to achieve greater detail in the performance data. Any or all of these actions are intended to help the project use a more capable process. (See the definition of “capable process” in the glossary.)
A prerequisite for comparing the capability of a selected subprocess against its quality and process-performance objectives is that the performance of the subprocess is stable and predictable with respect to its measured attributes.
Process capability is analyzed for those subprocesses and those measured attributes for which (derived) objectives have been established. Not all subprocesses or measured attributes that are statistically managed are analyzed regarding process capability.
The historical data may be inadequate for initially determining whether the subprocess is capable. It also is possible that the estimated natural bounds for subprocess performance may shift away from the quality and process-performance objectives. In either case, statistical control implies monitoring capability as well as stability.
Typical Work Products
1. Natural bounds of process performance for each selected subprocess compared to its established (derived) objectives
2. For each subprocess, its process capability
3. For each subprocess, the actions needed to address deficiencies in its process capability
Subpractices
1. Compare the quality and process-performance objectives to the natural bounds of the measured attribute.
This comparison provides an appraisal of the process capability for each measured attribute of a subprocess. These comparisons can be displayed graphically, in ways that relate the estimated natural bounds to the objectives or as process capability indices, which summarize the relationship of the objectives to the natural bounds.
2. Monitor changes in quality and process-performance objectives and selected subprocess’ process capability.
3. Identify and document subprocess capability deficiencies.
4. Determine and document actions needed to address subprocess capability deficiencies.
Examples of actions that can be taken when a selected subprocess’s performance does not satisfy its objectives include the following:
· Changing quality and process-performance objectives so that they are within the subprocess’ process capability
· Improving the implementation of the existing subprocess 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 subprocesses and technologies that have the potential for satisfying the objectives and managing the associated risks
· Identifying risks and risk mitigation strategies for each subprocess’s process capability deficiency
Refer to the Project Monitoring and Control process area for more information about taking corrective action.
SP 2.4 Record Statistical Management Data
Record statistical and quality management data in the organization’s measurement repository.
Refer to the Measurement and Analysis process area for more information about managing and storing data, measurement definitions, and results.
Refer to the Organizational Process Definition process area for more information about the organization’s measurement repository.
Typical Work Products
1. Statistical and quality management data recorded in the organization’s measurement repository
Monday, October 29, 2007
4.17. REQUIREMENTS DEVELOPMENT
Purpose
The purpose of Requirements Development (RD) is to produce and analyze customer, product, and product component requirements.
Introductory Notes
This process area describes three types of requirements: customer requirements, product requirements, and product component requirements. Taken together, these requirements address the needs of relevant stakeholders, including those pertinent to various product lifecycle phases (e.g., acceptance testing criteria) and product attributes (e.g., safety, reliability, and maintainability). Requirements also address constraints caused by the selection of design solutions (e.g., integration of commercial off-the-shelf products).
All development projects have requirements. In the case of a project that is focused on maintenance activities, the changes to the product or product components are based on changes to the existing requirements, design, or implementation. The requirements changes, if any, might be documented in change requests from the customer or users, or they might take the form of new requirements received from the requirements development process. Regardless of their source or form, the maintenance activities that are driven by changes to requirements are managed accordingly.
Requirements are the basis for design. The development of requirements includes the following activities:
· Elicitation, analysis, validation, and communication of customer needs, expectations, and constraints to obtain customer requirements that constitute an understanding of what will satisfy stakeholders
· Collection and coordination of stakeholder needs
· Development of the lifecycle requirements of the product
· Establishment of the customer requirements
· Establishment of initial product and product component requirements consistent with customer requirements
This process area addresses all customer requirements rather than only product-level requirements because the customer may also provide specific design requirements.
Customer requirements are further refined into product and product component requirements. In addition to customer requirements, product and product component requirements are derived from the selected design solutions. Throughout the process areas, where we use the terms product and product component, their intended meanings also encompass services and their components.
Requirements are identified and refined throughout the phases of the product lifecycle. Design decisions, subsequent corrective actions, and feedback during each phase of the product’s lifecycle are analyzed for impact on derived and allocated requirements.
The Requirements Development process area includes three specific goals. The Develop Customer Requirements specific goal addresses defining a set of customer requirements to use in the development of product requirements. The Develop Product Requirements specific goal addresses defining a set of product or product component requirements to use in the design of products and product components. The Analyze and Validate Requirements specific goal addresses the necessary analysis of customer, product, and product component requirements to define, derive, and understand the requirements. The specific practices of the third specific goal are intended to assist the specific practices in the first two specific goals. The processes associated with the Requirements Development process area and those associated with the Technical Solution process area may interact recursively with one another.
Analyses are used to understand, define, and select the requirements at all levels from competing alternatives. These analyses include the following:
· Analysis of needs and requirements for each product lifecycle phase, including needs of relevant stakeholders, the operational environment, and factors that reflect overall customer and end-user expectations and satisfaction, such as safety, security, and affordability
· Development of an operational concept
· Definition of the required functionality
The definition of functionality, also referred to as “functional analysis,” is not the same as structured analysis in software development and does not presume a functionally oriented software design. In object-oriented software design, it relates to defining what are called “services” or “methods.” The definition of functions, their logical groupings, and their association with requirements is referred to as a “functional architecture.”
Analyses occur recursively at successively more detailed layers of a product’s architecture until sufficient detail is available to enable detailed design, acquisition, and testing of the product to proceed. As a result of the analysis of requirements and the operational concept (including functionality, support, maintenance, and disposal), the manufacturing or production concept produces more derived requirements, including consideration of the following:
· Constraints of various types
· Technological limitations
· Cost and cost drivers
· Time constraints and schedule drivers
· Risks
· Consideration of issues implied but not explicitly stated by the customer or end user
· Factors introduced by the developer’s unique business considerations, regulations, and laws
A hierarchy of logical entities (functions and subfunctions, object classes and subclasses) is established through iteration with the evolving operational concept. Requirements are refined, derived, and allocated to these logical entities. Requirements and logical entities are allocated to products, product components, people, or associated processes.
Involvement of relevant stakeholders in both requirements development and analysis gives them visibility into the evolution of requirements. This activity continually assures them that the requirements are being properly defined.
Related Process Areas
Refer to the Requirements Management process area for more information about managing customer and product requirements, obtaining agreement with the requirements provider, obtaining commitments with those implementing the requirements, and maintaining traceability.
Refer to the Technical Solution process area for more information about how the outputs of the requirements development processes are used, and the development of alternative solutions and designs used in refining and deriving requirements.
Refer to the Product Integration process area for more information about interface requirements and interface management.
Refer to the Verification process area for more information about verifying that the resulting product meets the requirements.
Refer to the Validation process area for more information about how the product built will be validated against the customer needs.
Refer to the Risk Management process area for more information about identifying and managing risks that are related to requirements.
Refer to the Configuration Management process area for information about ensuring that key work products are controlled and managed.
Specific Goal and Practice Summary
SG 1 Develop Customer Requirements
SP 1.1 Elicit Needs
SP 1.2 Develop the Customer Requirements
SG 2 Develop Product Requirements
SP 2.1 Establish Product and Product Component Requirements
SP 2.2 Allocate Product Component Requirements
SP 2.3 Identify Interface Requirements
SG 3 Analyze and Validate Requirements
SP 3.1 Establish Operational Concepts and Scenarios
SP 3.2 Establish a Definition of Required Functionality
SP 3.3 Analyze Requirements
SP 3.4 Analyze Requirements to Achieve Balance
SP 3.5 Validate Requirements
SP 1.1 Elicit Needs
Elicit stakeholder needs, expectations, constraints, and interfaces for all phases of the product lifecycle.
Eliciting goes beyond collecting requirements by proactively identifying additional requirements not explicitly provided by customers. Additional requirements should address the various product lifecycle activities and their impact on the product.
Examples of techniques to elicit needs include the following:
· Technology demonstrations
· Interface control working groups
· Technical control working groups
· Interim project reviews
· Questionnaires, interviews, and operational scenarios obtained from end users
· Operational walkthroughs and end-user task analysis
· Prototypes and models
· Brainstorming
· Quality Function Deployment
· Market surveys
· Beta testing
· Extraction from sources such as documents, standards, or specifications
· Observation of existing products, environments, and workflow patterns
· Use cases
· Business case analysis
· Reverse engineering (for legacy products)
· Customer satisfaction surveys
Examples of sources of requirements that might not be identified by the customer include the following:
· Business policies
· Standards
· Business environmental requirements (e.g., laboratories, testing and other facilities, and information technology infrastructure)
· Technology
· Legacy products or product components (reuse product components)
Subpractices
1. Engage relevant stakeholders using methods for eliciting needs, expectations, constraints, and external interfaces.
SP 1.2 Develop the Customer Requirements
Transform stakeholder needs, expectations, constraints, and interfaces into customer requirements.
The various inputs from the relevant stakeholders must be consolidated, missing information must be obtained, and conflicts must be resolved in documenting the recognized set of customer requirements. The customer requirements may include needs, expectations, and constraints with regard to verification and validation.
In some situations, the customer provides a set of requirements to the project, or the requirements exist as an output of a previous project's activities. In these situations, the customer requirements could conflict with the relevant stakeholders' needs, expectations, constraints, and interfaces and will need to be transformed into the recognized set of customer requirements after appropriate resolution of conflicts.
Relevant stakeholders representing all phases of the product's lifecycle should include business as well as technical functions. In this way, concepts for all product-related lifecycle processes are considered concurrently with the concepts for the products. Customer requirements result from informed decisions on the business as well as technical effects of their requirements.
Typical Work Products
1. Customer requirements
2. Customer constraints on the conduct of verification
3. Customer constraints on the conduct of validation
Subpractices
1. Translate the stakeholder needs, expectations, constraints, and interfaces into documented customer requirements.
2. Define constraints for verification and validation.
Keywords : appropriate ; customer ; customer requirement ; document ; process ; product ; product-related lifecycle processes ; project ; relevant stakeholder ; requirement ; stakeholder ; subpractice
SG 2 Develop Product Requirements
Customer requirements are refined and elaborated to develop product and product component requirements.
Customer requirements are analyzed in conjunction with the development of the operational concept to derive more detailed and precise sets of requirements called “product and product component requirements.” Product and product component requirements address the needs associated with each product lifecycle phase. Derived requirements arise from constraints, consideration of issues implied but not explicitly stated in the customer requirements baseline, and factors introduced by the selected architecture, the design, and the developer’s unique business considerations. The requirements are reexamined with each successive, lower level set of requirements and functional architecture, and the preferred product concept is refined.
The requirements are allocated to product functions and product components including objects, people, and processes. The traceability of requirements to functions, objects, tests, issues, or other entities is documented. The allocated requirements and functions are the basis for the synthesis of the technical solution. As internal components are developed, additional interfaces are defined and interface requirements are established.
Refer to the Maintain Bidirectional Traceability of Requirements specific practice of the Requirements Management process area for more information about maintaining bidirectional traceability.
SP 2.1 Establish Product and Product Component Requirements
Establish and maintain product and product component requirements, which are based on the customer requirements.
The customer requirements may be expressed in the customer’s terms and may be nontechnical descriptions. The product requirements are the expression of these requirements in technical terms that can be used for design decisions. An example of this translation is found in the first House of Quality Function Deployment, which maps customer desires into technical parameters. For instance, “solid sounding door” might be mapped to size, weight, fit, dampening, and resonant frequencies.
Product and product component requirements address the satisfaction of customer, business, and project objectives and associated attributes, such as effectiveness and affordability.
Derived requirements also address the cost and performance of other lifecycle phases (e.g., production, operations, and disposal) to the extent compatible with business objectives.
The modification of requirements due to approved requirement changes is covered by the “maintain” function of this specific practice; whereas, the administration of requirement changes is covered by the Requirements Management process area.
Refer to the Requirements Management process area for more information about managing changes to requirements.
Typical Work Products
1. Derived requirements
2. Product requirements
3. Product component requirements
Subpractices
1. Develop requirements in technical terms necessary for product and product component design.
Develop architecture requirements addressing critical product qualities and performance necessary for product architecture design.
2. Derive requirements that result from design decisions.
Refer to the Technical Solution process area for more information about developing the solutions that generate additional derived requirements.
Selection of a technology brings with it additional requirements. For instance, use of electronics requires additional technology-specific requirements such as electromagnetic interference limits.
3. Establish and maintain relationships between requirements for consideration during change management and requirements allocation.
Refer to the Requirements Management process area for more information about maintaining requirements traceability.
Relationships between requirements can aid in evaluating the impact of changes.
SP 2.2 Allocate Product Component Requirements
Allocate the requirements for each product component.
Refer to the Technical Solution process area for more information about allocation of requirements to products and product components. This specific practice provides information for defining the allocation of requirements but must interact with the specific practices in the Technical Solution process area to establish solutions to which the requirements are allocated.
The requirements for product components of the defined solution include allocation of product performance; design constraints; and fit, form, and function to meet requirements and facilitate production. In cases where a higher level requirement specifies performance that will be the responsibility of two or more product components, the performance must be partitioned for unique allocation to each product component as a derived requirement.
Typical Work Products
1. Requirement allocation sheets
2. Provisional requirement allocations
3. Design constraints
4. Derived requirements
5. Relationships among derived requirements
Subpractices
1. Allocate requirements to functions.
2. Allocate requirements to product components.
3. Allocate design constraints to product components.
4. Document relationships among allocated requirements.
Relationships include dependencies in which a change in one requirement may affect other requirements.
SP 2.3 Identify Interface Requirements
Identify interface requirements.
Interfaces between functions (or between objects) are identified. Functional interfaces may drive the development of alternative solutions described in the Technical Solution process area.
Refer to the Product Integration process area for more information about the management of interfaces and the integration of products and product components.
Interface requirements between products or product components identified in the product architecture are defined. They are controlled as part of product and product component integration and are an integral part of the architecture definition.
Typical Work Products
1. Interface requirements
Subpractices
1. Identify interfaces both external to the product and internal to the product (i.e., between functional partitions or objects).
As the design progresses, the product architecture will be altered by technical solution processes, creating new interfaces between product components and components external to the product.
Interfaces with product-related lifecycle processes should also be identified.
Examples of these interfaces include interfaces with test equipment, transportation systems, support systems, and manufacturing facilities.
2. Develop the requirements for the identified interfaces.
Refer to the Technical Solution process area for more information about generating new interfaces during the design process.
Requirements for interfaces are defined in terms such as origination, destination, stimulus, data characteristics for software, and electrical and mechanical characteristics for hardware.
SG 3 Analyze and Validate Requirements
The requirements are analyzed and validated, and a definition of required functionality is developed.
The specific practices of the Analyze and Validate Requirements specific goal support the development of the requirements in both the Develop Customer Requirements specific goal and the Develop Product Requirements specific goal. The specific practices associated with this specific goal cover analyzing and validating the requirements with respect to the user’s intended environment.
Analyses are performed to determine what impact the intended operational environment will have on the ability to satisfy the stakeholders’ needs, expectations, constraints, and interfaces. Considerations, such as feasibility, mission needs, cost constraints, potential market size, and acquisition strategy, must all be taken into account, depending on the product context. A definition of required functionality is also established. All specified usage modes for the product are considered, and a timeline analysis is generated for time-critical sequencing of functions.
The objectives of the analyses are to determine candidate requirements for product concepts that will satisfy stakeholder needs, expectations, and constraints; and then to translate these concepts into requirements. In parallel with this activity, the parameters that will be used to evaluate the effectiveness of the product are determined based on customer input and the preliminary product concept.
Requirements are validated to increase the probability that the resulting product will perform as intended in the use environment.
SP 3.1 Establish Operational Concepts and Scenarios
Establish and maintain operational concepts and associated scenarios.
A scenario is typically a sequence of events that might occur in the use of the product, which is used to make explicit some of the needs of the stakeholders. In contrast, an operational concept for a product usually depends on both the design solution and the scenario. For example, the operational concept for a satellite-based communications product is quite different from one based on landlines. Since the alternative solutions have not usually been defined when preparing the initial operational concepts, conceptual solutions are developed for use when analyzing the requirements. The operational concepts are refined as solution decisions are made and lower level detailed requirements are developed.
Just as a design decision for a product may become a requirement for product components, the operational concept may become the scenarios (requirements) for product components. Operational concepts and scenarios are evolved to facilitate the selection of product component solutions that, when implemented, will satisfy the intended use of the product. Operational concepts and scenarios document the interaction of the product components with the environment, users, and other product components, regardless of engineering discipline. They should be documented for all modes and states within operations, product deployment, delivery, support (including maintenance and sustainment), training, and disposal.
The scenarios may include operational sequences, provided those sequences are an expression of customer requirements rather than operational concepts.
Typical Work Products
1. Operational concept
2. Product or product component installation, operational, maintenance, and support concepts
3. Disposal concepts
4. Use cases
5. Timeline scenarios
6. New requirements
Subpractices
1. Develop operational concepts and scenarios that include functionality, performance, maintenance, support, and disposal as appropriate.
Identify and develop scenarios, consistent with the level of detail in the stakeholder needs, expectations, and constraints in which the proposed product or product component is expected to operate.
2. Define the environment in which the product or product component will operate, including boundaries and constraints.
3. Review operational concepts and scenarios to refine and discover requirements.
Operational concept and scenario development is an iterative process. The reviews should be held periodically to ensure that they agree with the requirements. The review may be in the form of a walkthrough.
4. Develop a detailed operational concept, as products and product components are selected, that defines the interaction of the product, the end user, and the environment, and that satisfies the operational, maintenance, support, and disposal needs.
SP 3.2 Establish a Definition of Required Functionality
Establish and maintain a definition of required functionality.
The definition of functionality, also referred to as “functional analysis,” is the description of what the product is intended to do. The definition of functionality can include actions, sequence, inputs, outputs, or other information that communicates the manner in which the product will be used.
Functional analysis is not the same as structured analysis in software development and does not presume a functionally oriented software design. In object-oriented software design, it relates to defining what are called “services” or “methods.” The definition of functions, their logical groupings, and their association with requirements is referred to as a functional architecture. (See the definition of “functional architecture” in the glossary.)
Typical Work Products
1. Functional architecture
2. Activity diagrams and use cases
3. Object-oriented analysis with services or methods identified
Subpractices
1. Analyze and quantify functionality required by end users.
2. Analyze requirements to identify logical or functional partitions (e.g., subfunctions).
3. Partition requirements into groups, based on established criteria (e.g., similar functionality, performance, or coupling), to facilitate and focus the requirements analysis.
4. Consider the sequencing of time-critical functions both initially and subsequently during product component development.
5. Allocate customer requirements to functional partitions, objects, people, or support elements to support the synthesis of solutions.
6. Allocate functional and performance requirements to functions and subfunctions.
SP 3.3 Analyze Requirements
Analyze requirements to ensure that they are necessary and sufficient.
In light of the operational concept and scenarios, the requirements for one level of the product hierarchy are analyzed to determine whether they are necessary and sufficient to meet the objectives of higher levels of the product hierarchy. The analyzed requirements then provide the basis for more detailed and precise requirements for lower levels of the product hierarchy.
As requirements are defined, their relationship to higher level requirements and the higher level defined functionality must be understood. One of the other actions is the determination of which key requirements will be used to track progress. For instance, the weight of a product or size of a software product may be monitored through development based on its risk.
Refer to the Verification process area for more information about verification methods that could be used to support this analysis.
Typical Work Products
1. Requirements defects reports
2. Proposed requirements changes to resolve defects
3. Key requirements
4. Technical performance measures
Subpractices
1. Analyze stakeholder needs, expectations, constraints, and external interfaces to remove conflicts and to organize into related subjects.
2. Analyze requirements to determine whether they satisfy the objectives of higher level requirements.
3. Analyze requirements to ensure that they are complete, feasible, realizable, and verifiable.
While design determines the feasibility of a particular solution, this subpractice addresses knowing which requirements affect feasibility.
4. Identify key requirements that have a strong influence on cost, schedule, functionality, risk, or performance.
5. Identify technical performance measures that will be tracked during the development effort.
Refer to the Measurement and Analysis process area for more information about the use of measurements.
6. Analyze operational concepts and scenarios to refine the customer needs, constraints, and interfaces and to discover new requirements.
This analysis may result in more detailed operational concepts and scenarios as well as supporting the derivation of new requirements.
SP 3.4 Analyze Requirements to Achieve Balance
Analyze requirements to balance stakeholder needs and constraints.
Stakeholder needs and constraints can address cost, schedule, performance, functionality, reusable components, maintainability, or risk.
Typical Work Products
1. Assessment of risks related to requirements
Subpractices
1. Use proven models, simulations, and prototyping to analyze the balance of stakeholder needs and constraints.
Results of the analyses can be used to reduce the cost of the product and the risk in developing the product.
2. Perform a risk assessment on the requirements and functional architecture.
Refer to the Risk Management process area for information about performing a risk assessment on customer and product requirements and the functional architecture.
3. Examine product lifecycle concepts for impacts of requirements on risks.
SP 3.5 Validate Requirements
Validate requirements to ensure the resulting product will perform as intended in the user's environment.
Requirements validation is performed early in the development effort with end users to gain confidence that the requirements are capable of guiding a development that results in successful final validation. This activity should be integrated with risk management activities. Mature organizations will typically perform requirements validation in a more sophisticated way using multiple techniques and will broaden the basis of the validation to include other stakeholder needs and expectations.
Examples of techniques used for requirements validation include the following:
· Analysis
· Simulations
· Prototyping
· Demonstrations
Typical Work Products
1. Record of analysis methods and results
Subpractices
1. Analyze the requirements to determine the risk that the resulting product will not perform appropriately in its intended-use environment.
2. Explore the adequacy and completeness of requirements by developing product representations (e.g., prototypes, simulations, models, scenarios, and storyboards) and by obtaining feedback about them from relevant stakeholders.
Refer to the Validation process area for information about preparing for and performing validation on products and product components.
3. Assess the design as it matures in the context of the requirements validation environment to identify validation issues and expose unstated needs and customer requirements.
The purpose of Requirements Development (RD) is to produce and analyze customer, product, and product component requirements.
Introductory Notes
This process area describes three types of requirements: customer requirements, product requirements, and product component requirements. Taken together, these requirements address the needs of relevant stakeholders, including those pertinent to various product lifecycle phases (e.g., acceptance testing criteria) and product attributes (e.g., safety, reliability, and maintainability). Requirements also address constraints caused by the selection of design solutions (e.g., integration of commercial off-the-shelf products).
All development projects have requirements. In the case of a project that is focused on maintenance activities, the changes to the product or product components are based on changes to the existing requirements, design, or implementation. The requirements changes, if any, might be documented in change requests from the customer or users, or they might take the form of new requirements received from the requirements development process. Regardless of their source or form, the maintenance activities that are driven by changes to requirements are managed accordingly.
Requirements are the basis for design. The development of requirements includes the following activities:
· Elicitation, analysis, validation, and communication of customer needs, expectations, and constraints to obtain customer requirements that constitute an understanding of what will satisfy stakeholders
· Collection and coordination of stakeholder needs
· Development of the lifecycle requirements of the product
· Establishment of the customer requirements
· Establishment of initial product and product component requirements consistent with customer requirements
This process area addresses all customer requirements rather than only product-level requirements because the customer may also provide specific design requirements.
Customer requirements are further refined into product and product component requirements. In addition to customer requirements, product and product component requirements are derived from the selected design solutions. Throughout the process areas, where we use the terms product and product component, their intended meanings also encompass services and their components.
Requirements are identified and refined throughout the phases of the product lifecycle. Design decisions, subsequent corrective actions, and feedback during each phase of the product’s lifecycle are analyzed for impact on derived and allocated requirements.
The Requirements Development process area includes three specific goals. The Develop Customer Requirements specific goal addresses defining a set of customer requirements to use in the development of product requirements. The Develop Product Requirements specific goal addresses defining a set of product or product component requirements to use in the design of products and product components. The Analyze and Validate Requirements specific goal addresses the necessary analysis of customer, product, and product component requirements to define, derive, and understand the requirements. The specific practices of the third specific goal are intended to assist the specific practices in the first two specific goals. The processes associated with the Requirements Development process area and those associated with the Technical Solution process area may interact recursively with one another.
Analyses are used to understand, define, and select the requirements at all levels from competing alternatives. These analyses include the following:
· Analysis of needs and requirements for each product lifecycle phase, including needs of relevant stakeholders, the operational environment, and factors that reflect overall customer and end-user expectations and satisfaction, such as safety, security, and affordability
· Development of an operational concept
· Definition of the required functionality
The definition of functionality, also referred to as “functional analysis,” is not the same as structured analysis in software development and does not presume a functionally oriented software design. In object-oriented software design, it relates to defining what are called “services” or “methods.” The definition of functions, their logical groupings, and their association with requirements is referred to as a “functional architecture.”
Analyses occur recursively at successively more detailed layers of a product’s architecture until sufficient detail is available to enable detailed design, acquisition, and testing of the product to proceed. As a result of the analysis of requirements and the operational concept (including functionality, support, maintenance, and disposal), the manufacturing or production concept produces more derived requirements, including consideration of the following:
· Constraints of various types
· Technological limitations
· Cost and cost drivers
· Time constraints and schedule drivers
· Risks
· Consideration of issues implied but not explicitly stated by the customer or end user
· Factors introduced by the developer’s unique business considerations, regulations, and laws
A hierarchy of logical entities (functions and subfunctions, object classes and subclasses) is established through iteration with the evolving operational concept. Requirements are refined, derived, and allocated to these logical entities. Requirements and logical entities are allocated to products, product components, people, or associated processes.
Involvement of relevant stakeholders in both requirements development and analysis gives them visibility into the evolution of requirements. This activity continually assures them that the requirements are being properly defined.
Related Process Areas
Refer to the Requirements Management process area for more information about managing customer and product requirements, obtaining agreement with the requirements provider, obtaining commitments with those implementing the requirements, and maintaining traceability.
Refer to the Technical Solution process area for more information about how the outputs of the requirements development processes are used, and the development of alternative solutions and designs used in refining and deriving requirements.
Refer to the Product Integration process area for more information about interface requirements and interface management.
Refer to the Verification process area for more information about verifying that the resulting product meets the requirements.
Refer to the Validation process area for more information about how the product built will be validated against the customer needs.
Refer to the Risk Management process area for more information about identifying and managing risks that are related to requirements.
Refer to the Configuration Management process area for information about ensuring that key work products are controlled and managed.
Specific Goal and Practice Summary
SG 1 Develop Customer Requirements
SP 1.1 Elicit Needs
SP 1.2 Develop the Customer Requirements
SG 2 Develop Product Requirements
SP 2.1 Establish Product and Product Component Requirements
SP 2.2 Allocate Product Component Requirements
SP 2.3 Identify Interface Requirements
SG 3 Analyze and Validate Requirements
SP 3.1 Establish Operational Concepts and Scenarios
SP 3.2 Establish a Definition of Required Functionality
SP 3.3 Analyze Requirements
SP 3.4 Analyze Requirements to Achieve Balance
SP 3.5 Validate Requirements
SP 1.1 Elicit Needs
Elicit stakeholder needs, expectations, constraints, and interfaces for all phases of the product lifecycle.
Eliciting goes beyond collecting requirements by proactively identifying additional requirements not explicitly provided by customers. Additional requirements should address the various product lifecycle activities and their impact on the product.
Examples of techniques to elicit needs include the following:
· Technology demonstrations
· Interface control working groups
· Technical control working groups
· Interim project reviews
· Questionnaires, interviews, and operational scenarios obtained from end users
· Operational walkthroughs and end-user task analysis
· Prototypes and models
· Brainstorming
· Quality Function Deployment
· Market surveys
· Beta testing
· Extraction from sources such as documents, standards, or specifications
· Observation of existing products, environments, and workflow patterns
· Use cases
· Business case analysis
· Reverse engineering (for legacy products)
· Customer satisfaction surveys
Examples of sources of requirements that might not be identified by the customer include the following:
· Business policies
· Standards
· Business environmental requirements (e.g., laboratories, testing and other facilities, and information technology infrastructure)
· Technology
· Legacy products or product components (reuse product components)
Subpractices
1. Engage relevant stakeholders using methods for eliciting needs, expectations, constraints, and external interfaces.
SP 1.2 Develop the Customer Requirements
Transform stakeholder needs, expectations, constraints, and interfaces into customer requirements.
The various inputs from the relevant stakeholders must be consolidated, missing information must be obtained, and conflicts must be resolved in documenting the recognized set of customer requirements. The customer requirements may include needs, expectations, and constraints with regard to verification and validation.
In some situations, the customer provides a set of requirements to the project, or the requirements exist as an output of a previous project's activities. In these situations, the customer requirements could conflict with the relevant stakeholders' needs, expectations, constraints, and interfaces and will need to be transformed into the recognized set of customer requirements after appropriate resolution of conflicts.
Relevant stakeholders representing all phases of the product's lifecycle should include business as well as technical functions. In this way, concepts for all product-related lifecycle processes are considered concurrently with the concepts for the products. Customer requirements result from informed decisions on the business as well as technical effects of their requirements.
Typical Work Products
1. Customer requirements
2. Customer constraints on the conduct of verification
3. Customer constraints on the conduct of validation
Subpractices
1. Translate the stakeholder needs, expectations, constraints, and interfaces into documented customer requirements.
2. Define constraints for verification and validation.
Keywords : appropriate ; customer ; customer requirement ; document ; process ; product ; product-related lifecycle processes ; project ; relevant stakeholder ; requirement ; stakeholder ; subpractice
SG 2 Develop Product Requirements
Customer requirements are refined and elaborated to develop product and product component requirements.
Customer requirements are analyzed in conjunction with the development of the operational concept to derive more detailed and precise sets of requirements called “product and product component requirements.” Product and product component requirements address the needs associated with each product lifecycle phase. Derived requirements arise from constraints, consideration of issues implied but not explicitly stated in the customer requirements baseline, and factors introduced by the selected architecture, the design, and the developer’s unique business considerations. The requirements are reexamined with each successive, lower level set of requirements and functional architecture, and the preferred product concept is refined.
The requirements are allocated to product functions and product components including objects, people, and processes. The traceability of requirements to functions, objects, tests, issues, or other entities is documented. The allocated requirements and functions are the basis for the synthesis of the technical solution. As internal components are developed, additional interfaces are defined and interface requirements are established.
Refer to the Maintain Bidirectional Traceability of Requirements specific practice of the Requirements Management process area for more information about maintaining bidirectional traceability.
SP 2.1 Establish Product and Product Component Requirements
Establish and maintain product and product component requirements, which are based on the customer requirements.
The customer requirements may be expressed in the customer’s terms and may be nontechnical descriptions. The product requirements are the expression of these requirements in technical terms that can be used for design decisions. An example of this translation is found in the first House of Quality Function Deployment, which maps customer desires into technical parameters. For instance, “solid sounding door” might be mapped to size, weight, fit, dampening, and resonant frequencies.
Product and product component requirements address the satisfaction of customer, business, and project objectives and associated attributes, such as effectiveness and affordability.
Derived requirements also address the cost and performance of other lifecycle phases (e.g., production, operations, and disposal) to the extent compatible with business objectives.
The modification of requirements due to approved requirement changes is covered by the “maintain” function of this specific practice; whereas, the administration of requirement changes is covered by the Requirements Management process area.
Refer to the Requirements Management process area for more information about managing changes to requirements.
Typical Work Products
1. Derived requirements
2. Product requirements
3. Product component requirements
Subpractices
1. Develop requirements in technical terms necessary for product and product component design.
Develop architecture requirements addressing critical product qualities and performance necessary for product architecture design.
2. Derive requirements that result from design decisions.
Refer to the Technical Solution process area for more information about developing the solutions that generate additional derived requirements.
Selection of a technology brings with it additional requirements. For instance, use of electronics requires additional technology-specific requirements such as electromagnetic interference limits.
3. Establish and maintain relationships between requirements for consideration during change management and requirements allocation.
Refer to the Requirements Management process area for more information about maintaining requirements traceability.
Relationships between requirements can aid in evaluating the impact of changes.
SP 2.2 Allocate Product Component Requirements
Allocate the requirements for each product component.
Refer to the Technical Solution process area for more information about allocation of requirements to products and product components. This specific practice provides information for defining the allocation of requirements but must interact with the specific practices in the Technical Solution process area to establish solutions to which the requirements are allocated.
The requirements for product components of the defined solution include allocation of product performance; design constraints; and fit, form, and function to meet requirements and facilitate production. In cases where a higher level requirement specifies performance that will be the responsibility of two or more product components, the performance must be partitioned for unique allocation to each product component as a derived requirement.
Typical Work Products
1. Requirement allocation sheets
2. Provisional requirement allocations
3. Design constraints
4. Derived requirements
5. Relationships among derived requirements
Subpractices
1. Allocate requirements to functions.
2. Allocate requirements to product components.
3. Allocate design constraints to product components.
4. Document relationships among allocated requirements.
Relationships include dependencies in which a change in one requirement may affect other requirements.
SP 2.3 Identify Interface Requirements
Identify interface requirements.
Interfaces between functions (or between objects) are identified. Functional interfaces may drive the development of alternative solutions described in the Technical Solution process area.
Refer to the Product Integration process area for more information about the management of interfaces and the integration of products and product components.
Interface requirements between products or product components identified in the product architecture are defined. They are controlled as part of product and product component integration and are an integral part of the architecture definition.
Typical Work Products
1. Interface requirements
Subpractices
1. Identify interfaces both external to the product and internal to the product (i.e., between functional partitions or objects).
As the design progresses, the product architecture will be altered by technical solution processes, creating new interfaces between product components and components external to the product.
Interfaces with product-related lifecycle processes should also be identified.
Examples of these interfaces include interfaces with test equipment, transportation systems, support systems, and manufacturing facilities.
2. Develop the requirements for the identified interfaces.
Refer to the Technical Solution process area for more information about generating new interfaces during the design process.
Requirements for interfaces are defined in terms such as origination, destination, stimulus, data characteristics for software, and electrical and mechanical characteristics for hardware.
SG 3 Analyze and Validate Requirements
The requirements are analyzed and validated, and a definition of required functionality is developed.
The specific practices of the Analyze and Validate Requirements specific goal support the development of the requirements in both the Develop Customer Requirements specific goal and the Develop Product Requirements specific goal. The specific practices associated with this specific goal cover analyzing and validating the requirements with respect to the user’s intended environment.
Analyses are performed to determine what impact the intended operational environment will have on the ability to satisfy the stakeholders’ needs, expectations, constraints, and interfaces. Considerations, such as feasibility, mission needs, cost constraints, potential market size, and acquisition strategy, must all be taken into account, depending on the product context. A definition of required functionality is also established. All specified usage modes for the product are considered, and a timeline analysis is generated for time-critical sequencing of functions.
The objectives of the analyses are to determine candidate requirements for product concepts that will satisfy stakeholder needs, expectations, and constraints; and then to translate these concepts into requirements. In parallel with this activity, the parameters that will be used to evaluate the effectiveness of the product are determined based on customer input and the preliminary product concept.
Requirements are validated to increase the probability that the resulting product will perform as intended in the use environment.
SP 3.1 Establish Operational Concepts and Scenarios
Establish and maintain operational concepts and associated scenarios.
A scenario is typically a sequence of events that might occur in the use of the product, which is used to make explicit some of the needs of the stakeholders. In contrast, an operational concept for a product usually depends on both the design solution and the scenario. For example, the operational concept for a satellite-based communications product is quite different from one based on landlines. Since the alternative solutions have not usually been defined when preparing the initial operational concepts, conceptual solutions are developed for use when analyzing the requirements. The operational concepts are refined as solution decisions are made and lower level detailed requirements are developed.
Just as a design decision for a product may become a requirement for product components, the operational concept may become the scenarios (requirements) for product components. Operational concepts and scenarios are evolved to facilitate the selection of product component solutions that, when implemented, will satisfy the intended use of the product. Operational concepts and scenarios document the interaction of the product components with the environment, users, and other product components, regardless of engineering discipline. They should be documented for all modes and states within operations, product deployment, delivery, support (including maintenance and sustainment), training, and disposal.
The scenarios may include operational sequences, provided those sequences are an expression of customer requirements rather than operational concepts.
Typical Work Products
1. Operational concept
2. Product or product component installation, operational, maintenance, and support concepts
3. Disposal concepts
4. Use cases
5. Timeline scenarios
6. New requirements
Subpractices
1. Develop operational concepts and scenarios that include functionality, performance, maintenance, support, and disposal as appropriate.
Identify and develop scenarios, consistent with the level of detail in the stakeholder needs, expectations, and constraints in which the proposed product or product component is expected to operate.
2. Define the environment in which the product or product component will operate, including boundaries and constraints.
3. Review operational concepts and scenarios to refine and discover requirements.
Operational concept and scenario development is an iterative process. The reviews should be held periodically to ensure that they agree with the requirements. The review may be in the form of a walkthrough.
4. Develop a detailed operational concept, as products and product components are selected, that defines the interaction of the product, the end user, and the environment, and that satisfies the operational, maintenance, support, and disposal needs.
SP 3.2 Establish a Definition of Required Functionality
Establish and maintain a definition of required functionality.
The definition of functionality, also referred to as “functional analysis,” is the description of what the product is intended to do. The definition of functionality can include actions, sequence, inputs, outputs, or other information that communicates the manner in which the product will be used.
Functional analysis is not the same as structured analysis in software development and does not presume a functionally oriented software design. In object-oriented software design, it relates to defining what are called “services” or “methods.” The definition of functions, their logical groupings, and their association with requirements is referred to as a functional architecture. (See the definition of “functional architecture” in the glossary.)
Typical Work Products
1. Functional architecture
2. Activity diagrams and use cases
3. Object-oriented analysis with services or methods identified
Subpractices
1. Analyze and quantify functionality required by end users.
2. Analyze requirements to identify logical or functional partitions (e.g., subfunctions).
3. Partition requirements into groups, based on established criteria (e.g., similar functionality, performance, or coupling), to facilitate and focus the requirements analysis.
4. Consider the sequencing of time-critical functions both initially and subsequently during product component development.
5. Allocate customer requirements to functional partitions, objects, people, or support elements to support the synthesis of solutions.
6. Allocate functional and performance requirements to functions and subfunctions.
SP 3.3 Analyze Requirements
Analyze requirements to ensure that they are necessary and sufficient.
In light of the operational concept and scenarios, the requirements for one level of the product hierarchy are analyzed to determine whether they are necessary and sufficient to meet the objectives of higher levels of the product hierarchy. The analyzed requirements then provide the basis for more detailed and precise requirements for lower levels of the product hierarchy.
As requirements are defined, their relationship to higher level requirements and the higher level defined functionality must be understood. One of the other actions is the determination of which key requirements will be used to track progress. For instance, the weight of a product or size of a software product may be monitored through development based on its risk.
Refer to the Verification process area for more information about verification methods that could be used to support this analysis.
Typical Work Products
1. Requirements defects reports
2. Proposed requirements changes to resolve defects
3. Key requirements
4. Technical performance measures
Subpractices
1. Analyze stakeholder needs, expectations, constraints, and external interfaces to remove conflicts and to organize into related subjects.
2. Analyze requirements to determine whether they satisfy the objectives of higher level requirements.
3. Analyze requirements to ensure that they are complete, feasible, realizable, and verifiable.
While design determines the feasibility of a particular solution, this subpractice addresses knowing which requirements affect feasibility.
4. Identify key requirements that have a strong influence on cost, schedule, functionality, risk, or performance.
5. Identify technical performance measures that will be tracked during the development effort.
Refer to the Measurement and Analysis process area for more information about the use of measurements.
6. Analyze operational concepts and scenarios to refine the customer needs, constraints, and interfaces and to discover new requirements.
This analysis may result in more detailed operational concepts and scenarios as well as supporting the derivation of new requirements.
SP 3.4 Analyze Requirements to Achieve Balance
Analyze requirements to balance stakeholder needs and constraints.
Stakeholder needs and constraints can address cost, schedule, performance, functionality, reusable components, maintainability, or risk.
Typical Work Products
1. Assessment of risks related to requirements
Subpractices
1. Use proven models, simulations, and prototyping to analyze the balance of stakeholder needs and constraints.
Results of the analyses can be used to reduce the cost of the product and the risk in developing the product.
2. Perform a risk assessment on the requirements and functional architecture.
Refer to the Risk Management process area for information about performing a risk assessment on customer and product requirements and the functional architecture.
3. Examine product lifecycle concepts for impacts of requirements on risks.
SP 3.5 Validate Requirements
Validate requirements to ensure the resulting product will perform as intended in the user's environment.
Requirements validation is performed early in the development effort with end users to gain confidence that the requirements are capable of guiding a development that results in successful final validation. This activity should be integrated with risk management activities. Mature organizations will typically perform requirements validation in a more sophisticated way using multiple techniques and will broaden the basis of the validation to include other stakeholder needs and expectations.
Examples of techniques used for requirements validation include the following:
· Analysis
· Simulations
· Prototyping
· Demonstrations
Typical Work Products
1. Record of analysis methods and results
Subpractices
1. Analyze the requirements to determine the risk that the resulting product will not perform appropriately in its intended-use environment.
2. Explore the adequacy and completeness of requirements by developing product representations (e.g., prototypes, simulations, models, scenarios, and storyboards) and by obtaining feedback about them from relevant stakeholders.
Refer to the Validation process area for information about preparing for and performing validation on products and product components.
3. Assess the design as it matures in the context of the requirements validation environment to identify validation issues and expose unstated needs and customer requirements.
Subscribe to:
Posts (Atom)