Transcript The Journey to Level 4

Pittsburgh, PA 15213-3890
CMMI FOR SMALL BUSINESS
PILOT – ASI KICKOFF MEETING
SuZ Garcia, SEI
Sandra L. Cepeda, SEI Visiting Scientist/CSSA
July, 2003
Copyright 2004, Carnegie Mellon University. All rights reserved.
Topics
Introductions
Context
CMMI Overview
Business Issues Analysis
Path Forward
Copyright 2004, Carnegie Mellon University. All rights reserved.
2
CMMI OVERVIEW
Copyright 2004, Carnegie Mellon University. All rights reserved.
3
TOPICS IN THIS SECTION
Purpose of CMM frameworks
CMMI Executive Overview
How CMMI Meets Its Purpose (basic model structures and terms)
CMMI Process Area Contents Overview
Overview Summary
Copyright 2004, Carnegie Mellon University. All rights reserved.
4
Purpose of CMM Frameworks
The overall purpose of capability models is to establish a
process improvement roadmap upon which a route can be
drawn from “where we are today” to “where we want to be.”
Capability models define the characteristics of good
processes and avoid prescribing how the processes must
be enacted.
Adapted from paper by Sarah Sheard, “Help! How Do I make my organization comply with yet another new model”
Copyright (C) Software Productivity Consortium, NFP,2001
Originally published in International Council on Systems Engineering Symposium Proceedings 2001
Copyright 2004, Carnegie Mellon University. All rights reserved.
5
More specifically, CMMs Help
You to:
Verify process contents. Capability models encapsulate basic
industry knowledge for an organization to use to help improve
quality, customer satisfaction, productivity, and cycle time
Demonstrate progress. Another primary use of capability models
is to demonstrate improvement from year to year
Benchmark. A model can be used to validate process
improvement progress in comparison with competitors
Structure new processes. Organizations that have not yet
captured their basic engineering practices in documented
processes frequently will look at capability models as a list of
what needs to be included
Copyright 2004, Carnegie Mellon University. All rights reserved.
6
SEI Capability Maturity Model
(CMM) Evolution in a Nutshell
Software CMM initially developed by the Software
Engineering Institute (circa 1987-1993)
• Characterizes organizational software process capability
in terms of “maturity” as evidenced by the widespread
use of desirable practices
• Widely accepted by Government and industry
• Used both for external evaluation and self assessment
Significant Improvements in quality and productivity
reported over a wide variety of business contexts
A plethora of discipline-specific CMM’s emerged in the 90’s
• System Engineering, Integrated Product/Process Dev,
Software Acquisition, Security, People and more
CMMI v1.0 issued August 2000 followed by v1.1 in 2001
Copyright 2004, Carnegie Mellon University. All rights reserved.
7
Why CMMI :
It Becomes the Integrating Element
Needed to integrate SW and SE disciplines
Industry was interested and supportive
SE arena had already integrated SE models
SW CMM update was being finalized
IPD CMM was almost final
Solution was to integrate SW-CMM Ver. 2.0c (draft), EIA/IS 731, & IPD CMM v0.98
into a combined framework that could address either Software, Systems Engineering,
or both, along with IPPD and supplier management.
Copyright 2004, Carnegie Mellon University. All rights reserved.
8
Why CMMI :
Multiple discipline-specific models have a common core
Example Lines of Business
Include:
SEI CMMI
Core
IT Consulting
SW
Sys Arch, Engin & Delivery
Enterprise Integration
Core
Data Center Operation
IT Infrastructure Management
SE
Core Processes
Core IPPD
Applications Management
SETA
IPPD Discipline
Functional Process
Outsourcing
Copyright 2004, Carnegie Mellon University. All rights reserved.
Other
CMM’s
9
What do we typically do when
problems arise?
Ignorance
is bliss
Denial
AIIEEE
!
Not a good method for problem solving
CMMI Provides a Path to a Better
Way
“The Purpose of CMM Integration is to provide guidance
for improving your organization’s processes and your ability
to manage the development, acquisition and maintenance
of products and services.”
CMMI Version 1.1
CMMI OVERVIEW
PART I: EXECUTIVE OVERVIEW
Copyright 2004, Carnegie Mellon University. All rights reserved.
12
What is the CMMI Model?
CMMI Is a Process-Improvement Model that provides a set
of Best Practices that address productivity, performance,
costs, and stakeholder satisfaction.
CMMI Is NOT a set of “Bolt-On Processes” that last only as
Long as the wheel is squeaking. CMMI provides a
consistent, enduring framework that accommodates new
initiatives.
CMMI focuses on the total-system problem, unlike other
predecessor CMMs.
CMMI facilitates enterprise-wide process improvement,
unlike single-discipline models.
Copyright 2004, Carnegie Mellon University. All rights reserved.
13
CMMI Scope & Coverage
Multiple Disciplines
• Engineering Development
- Software Engineering
- Systems Engineering
- Concurrent Engineering
- Hardware Engineering
- “Assurance” Engineering
• Program Management
- Project Management
- Quality Assurance
- Configuration and Data
Management
Multiple Applications
• Architecture
• Design
- Systems
- Electrical
- Mechanical
- Software
• System Integration and Test
• Logistics
• Operations
• Maintenance
Total Product Life Cycle
Copyright 2004, Carnegie Mellon University. All rights reserved.
14
CMMI In A Nutshell
Staged
ML4
ML3
ML2
ML 1
Organization
Maturity Level 5 OID, CAR
Maturity Level 4 OPP, QPM
Maturity Level 3 RD, TS, PI,
VER, VAL, OPF, OPD, OT, IPM,
RSKM, DAR, OEI, IT, ISM
Requirements Development (RD)
Technical Solution (TS)
Product Integration (PI)
Verification (VER)
Validation (VAL)
Organizational Process Focus (OPF)
Organizational Process Definition (OPD)
Organizational Training (OT)
Integrated Project Management (IPM)
Risk Management (RSKM)
Decision Analysis and Resolution (DAR)
Organizational Environment for Integration (OEI)
Integrated Teaming (IT)
Integrated Supplier Management (ISM)
Capability
Requirements Management (REQM)
Project Planning (PP)
Project Monitoring and Control (PMC)
Measurement and Analysis (MA)
Process and Product Quality Assurance (PPQA)
Configuration Management (CM)
Supplier Agreement Management (SAM)
ML5
Maturity Level 2 REQM, PP,
Continuous
Process Areas (SE/SW/IPPD/SS)
PA
PA
Process
Management
OPF, OPD, OT,
OPP, OID
Project
Management
PP, PMC, SAM,
ISM, IPM, RSKM,
QPM, IT
Organizational Process Performance (OPP)
Quantitative Project Management (QPM)
PMC, MA, PPQA, CM, SAM
Organizational Innovation & Deployment (OID)
Causal Analysis and Resolution (CAR)
 Two Representations Per CMMI Model
 One Appraisal Method (SCAMPI)
Copyright 2003, CSSA, Inc. Used with permission.
PA
Process
Support
CM, PPQA, MA,
CAR, DAR, OEI
Engineering
REQM, RD, TS,
PI, VER, VAL
Using CMMI Correctly
Correct use of CMMI implies:
Reflecting on the reality of your business environment
• Tailoring (interpreting) CMMI to suit your context and
needs
• Allowing for professional judgment
Identifying problems as objectively as possible
Thinking and analyzing how the CMMI applies
• Doing and not just thinking!
• Not forcing foolish decisions!
Supporting worker participation and empowerment
 Use the Model As a Guide, Not a Dictate
 Tie Process Improvement to Business Goals
Copyright 2004, Carnegie Mellon University. All rights reserved.
16
Value of CMMI (1 of 2)
CMMI builds upon SW-CMM legacy:
• Better, expanded model scope
• Since many “software problems” are linked to systems issues,
capabilities associated with disciplines other than software contribute
to causal factors
CMMI adds:
•
•
•
•
•
New emphasis on product as well as process
Coverage of services as well as systems
Emphasis on process capability and organizational maturity
Early emphasis on measurement and analysis
Better coverage of engineering management
• A common, integrated vision of improvement for all elements of your
organization
• Efficient, effective appraisals and improvement across multiple
process disciplines
Additional Productivity and Quality Gains
Copyright 2004, Carnegie Mellon University. All rights reserved.
17
Value of CMMI (2 of 2)
CMMI helps organizations…
• Improve delivery of promised performance, cost, and
schedule
• Integrate stakeholders into project activities
• Provide competitive world-class products and services
• Implement an integrated, enterprise, business and
engineering perspective
• Use common, integrated, and improving processes for
systems and software
• Implement proactive program management techniques
• Enable staff members to move between projects and still
use the same processes
• Create and improve processes that adapt to a changing
business environment
Copyright 2004, Carnegie Mellon University. All rights reserved.
18
Pittsburgh, PA 15213-3890
Business Case for Using CMMI
Copyright 2004, Carnegie Mellon University. All rights reserved.
Notional Business Case for CMMI
•
Reduced Development/ Maintenance Costs
•
•
•
Increased Revenue/Profitability
Reduced Post-Release Defects
Measurable Improvements of
Reliability and Quality
•
•
Repeat Business
Increased Product Sales
•
•
Enhanced Time-to-Market Performance
Bonuses for Early Delivery
•
Reduced Employee Turnover and
Retraining Costs
Improved Competitive Advantage
Reduced Cycle Time
•
•
•
Improved Customer Satisfaction
•
•
•
Improved Productivity
Less Rework
Improved Process Performance
Improved Professional Staff
•
•
Improved Employee Morale
Increased Developer and Maintainer
Confidence
•
Better Products – Not Just Software – Out Sooner And Cheaper
Copyright 2003, CSSA, Inc. Used with permission.
Building on the Legacy of SWCMM Success
Current ROI Value
to Programs
(DACS, 1999)
Improvements From Adopting SW-CMM (SEI, 1994)
-19%
Post-Release
Defect Reports
+35%
Time to
Market
40
35
30
25
20
15
10
5
0
Productivity
Percentage Improvement
-39%
Savings vs.
cost of
software
process
improvement
(median) 5:1
Application of SPI to “Example
Organization With Example
Projects”:
Development Costs
Reduced 73%
Rework Costs
Reduced 96%
Average Schedule
Length
Reduced 37%
Post-Release
Defects
Reduced 80%
Weighted Risk
Likelihood
Reduced 92%
Return On
Investment
Annual Medians
Expect Even Higher ROI For CMMI
21:1
The Entire Supply Chain Is or Will Be
Involved in CMMI
• Improve Integration of
Products and Services
DoD
Customers
• Will Use
Organizational
Maturity or Process
Capability to Advise
Customers
• Will Use
Organizational
Maturity or Process
Capability to
Competitive
Advantage
Associate
Contractors
Suppliers
• May Require
Organizational
Maturity or Process
Capability in RFP,
Implicitly or
Explicitly
• May Use
Organizational
Maturity or Process
Capability
As a Discriminator
Competitors
• Improve Integration of
Products and Services
• Provide Insight Into
Supplier Performance
and Quality
DoD Contractors Have Additional Motivation To Transition To The CMMI
Feedback from Early Adopters
CMMI is less burdensome in the implementation
phases. CMMI provides detailed integrated
acquisition management coverage that was only
partially available in SW-CMM
CMMI Transition Workshop
“You have many reference systems available to
measure how efficient you are and to evaluate the
progress you make; the CMMI presents this
advantage to be a reference as well as a guide
towards good practices.”
Thales
“Involvement with and use of CMMI could have prevented a
$21M cost overrun if we had had level 3 capability
measurement and analysis process in place”
Don Michels, SOF System Program Office, USAF/WR-ALC
Copyright 2004, Carnegie Mellon University. All rights reserved.
23
CMMI Adoption
Copyright 2004, Carnegie Mellon University. All rights reserved.
24
Planned CMMI Adoption Life
Cycle
Phase 1
Understand
Existing Company
Environment
Phase 2
Establish CMMI
Adoption Project
ID Problematic
Business Issues
Provide awareness
education about CMMI
Define Initial Goals
Begin Metrics
Collection
Analyze Workflow/
Existing Processes
Identify Metrics to
Collect
Baseline
Organizational
Enablers wrt CMMI
Identify Improvement
Team/Approach
Draft Business Case
Draft CMMI Adoption
Plan
Evaluate Company
Practices against
CMMI
Select subset of CMMI
content based on
business issues
Draft Cost/Benefit
Analysis
Analyze as is
processes/practices
against selected CMMI
content areas
Recommend areas for
CMMI adoption
ID Adoption Risks
Copyright 2004, Carnegie Mellon University. All rights reserved.
Phase 3
Prepare for CMMI
Adoption
Implement and
Adopt CMMI
Build/Deploy Transition
Mechanisms for
Communication about
CMMI
Work with
implementation team
to develop new CMMIinformed process
Finalize CMMI
Adoption Plan
Build/Deploy Transition
Mechanisms for
Implementation of
CMMI-informed
process
Establish Level of Use
Goals for selected
PAs
ID company areas
(possibly pilots) for PA
Adoption
Analyze and
Deliver CMMI
Adoption Project
Results
Roll Out New
Processes to Relevant
Stakeholders
Document Business
Impact
Collect CMMI Adoption
Lessons Learned
Manage Adoption
Issues and Risks
25
CMMI Adoption Challenges
Understanding CMMI content and scope
Interpreting and tailoring model for your organization
Defining scope of improvement
Selecting model representation
Integrating disciplines, functions, and applications
Eliminating existing process inconsistencies and reducing
duplication
Minimizing impact to projects
Managing organizational change
Analyzing legacy transition mechanisms
Optimizing CMMI implementation as it relates to other
quality improvement efforts
Copyright 2004, Carnegie Mellon University. All rights reserved.
26
CMMI...Re-cap
... Supports engineering, management, and
infrastructure improvement
… Can be expanded to include special interest areas of
disciplines not already included
... Supports flexible process improvement approaches
via 2 reflexive representations
... Builds on a solid heritage of both principle and data to
support process improvement
... Provides the organizational infrastructure to support
sustainment of other high-impact software
engineering techniques
Copyright 2004, Carnegie Mellon University. All rights reserved.
27
The Bottom Line
Without constant vigilance, steady pressure, and active visible support,
the
will melt down
Copyright 2004, Carnegie Mellon University. All rights reserved.
28
CMMI Overview Part II – Model
Overview
Model Representations
Model Components and Fundamental Concepts
High Level Overview of Process Area Contents and
Relationships to Typical Business Issues
Copyright 2004, Carnegie Mellon University. All rights reserved.
29
Model Representations
Continuous
Staged
…for a single process area or
set of process areas
…for a pre-defined set of process
areas across an organization
Maturity Level 5
5
Optimizing: Focus on
Process Improvement
4
Quantitatively Managed: Process
Measured and Controlled
OID, CAR
CL4
Maturity Level 4
OPP, QPM
CL3
Maturity Level 3
3
RD, TS, PI, VER, VAL, OPF, OPD, OT,
IPM, RSKM, DAR, OEI, IT, ISM
Defined: Process Characterized
for the Organization and
Is Proactive
CL2
Maturity Level 2
2
Managed: Process
Characterized for Projects
and Is Often Reactive
CL1
(Initial)
Process Area Capability
CL5
REQM, PP, PMC, MA, PPQA, CM, SAM
Maturity Level 1
PA
z
PA y
PA
x
Initial: Process Unpredictable, Poorly Controlled, and Reactive
Essentially the Same Content but Organized in a Different Way.
Copyright 2003, CSSA, Inc. Used with permission.
CL0
(Incomplete)
CMMI Model Structure
Continuous
Staged
Maturity Levels
(1-5)
Process Area 1
Process Area N
Process Area 1
Process Area 2
Generic Goals
Process Area 2
Specific Goals
(2-3)
Process Area N
Generic Goals
Specific Goals
(1-5)
Common Features
Commitment
To Perform
Ability
To Perform
Directing
Implementation
Capability Levels
Verification
(0-5)
Generic Practices
Generic Practices
(2.1-2.10
3.1-3.2)
Specific Practices
(1.1, 2.1-2.10
3.1-3.2, 4.1-4.2
5.1-5.2)
Specific Practices
Process Areas
A Process Area (PA) Is a Cluster of Related Practices in an
Area That, When Performed Collectively, Satisfy a Set of
Goals Considered Important for Making Significant
Improvement in That Area
Practices Are Actions Expected to Be Performed to Achieve
the Goals of a Process Area
All CMMI Process Areas Are Common to Both Continuous
and Staged Representations
A Process Area Is NOT a Process Description
Copyright 2004, Carnegie Mellon University. All rights reserved.
32
CMMI Process Areas
Staged
Continuous
Process Areas
Process Areas
LEVEL 5
Organizational Innovation & Deployment (OID)
Causal Analysis and Resolution (CAR)
LEVEL 4
Organizational Process Performance (OPP)
Quantitative Project Management (QPM)
LEVEL 3
Requirements Development (RD)
Technical Solution (TS)
Product Integration (PI)
Verification (VER)
Validation (VAL)
Organizational Process Focus (OPF)
Organizational Process Definition (OPD)
Organizational Training (OT)
Integrated Project Management (IPM)
Risk Management (RSKM)
Decision Analysis and Resolution (DAR)
Organizational Environment for Integration (OEI)
Integrated Teaming (IT)
Integrated Supplier Management (ISM)
LEVEL 2
Requirements Management (REQM)
Project Planning (PP)
Project Monitoring and Control (PMC)
Measurement and Analysis (MA)
Process and Product Quality Assurance (PPQA)
Configuration Management (CM)
Supplier Agreement Management (SAM)
Project Management
Quantitative Project Management (QPM)
Integrated Project Management (IPM)
Risk Management (RSKM)
Integrated Teaming (IT)
Integrated Supplier Management (ISM)
Project Planning (PP)
Project Monitoring and Control (PMC)
Supplier Agreement Management (SAM))
Process Management
Organizational
Organizational
Organizational
Organizational
Organizational
Innovation & Deployment (OID)
Process Performance (OPP)
Process Focus (OPF)
Process Definition (OPD)
Training (OT)
Engineering
Requirements Management (REQM)
Requirements Development (RD)
Technical Solution (TS)
Product Integration (PI)
Verification (VER)
Validation (VAL)
Support
Causal Analysis and Resolution (CAR)
Decision Analysis and Resolution (DAR)
Organizational Environment for Integration (OEI)
Measurement and Analysis (MA)
Process and Product Quality Assurance (PPQA)
Configuration Management (CM)
CMMI Model Structure
Continuous
Staged
Maturity Levels
(1-5)
Process Area 1
Process Area N
Process Area 1
Process Area 2
Generic Goals
Process Area 2
Specific Goals
(2-3)
Process Area N
Generic Goals
Specific Goals
(1-5)
Common Features
Commitment
To Perform
Ability
To Perform
Directing
Implementation
Capability Levels
Verification
(0-5)
Generic Practices
Generic Practices
(2.1-2.10
3.1-3.2)
Specific Practices
(1.1, 2.1-2.10
3.1-3.2, 4.1-4.2
5.1-5.2)
Specific Practices
Specific Goals (SGs)
A Specific Goal Applies to a Process Area and Addresses
the Unique Characteristics That Describe What Must Be
Implemented to Satisfy That Process Area
Example From the Project Planning Process Area:
SG 2: A Project Plan Is Established And Maintained as
the Basis For Managing The Project
Copyright 2004, Carnegie Mellon University. All rights reserved.
35
Specific Practices (SPs)
A Specific Practice is an activity that is considered
important in achieving the associated Specific Goal
Practices are the major building blocks in establishing the
process maturity of an organization
Example from the Project Planning process area :
• Sp 2.1-1: Establish and maintain the project’s budget
and schedule
Copyright 2004, Carnegie Mellon University. All rights reserved.
36
CMMI Model Structure
Continuous
Staged
Maturity Levels
(1-5)
Process Area 1
Process Area N
Process Area 1
Process Area 2
Generic Goals
Process Area 2
Specific Goals
(2-3)
Process Area N
Generic Goals
Specific Goals
(1-5)
Common Features
Commitment
To Perform
Ability
To Perform
Directing
Implementation
Capability Levels
Verification
(0-5)
Generic Practices
Generic Practices
(2.1-2.10
3.1-3.2)
Specific Practices
(1.1, 2.1-2.10
3.1-3.2, 4.1-4.2
5.1-5.2)
Specific Practices
Generic Goals (GGs)
Achievement of a generic goal in a process area signifies
improved control in planning and implementing the
processes associated with that process area
Generic Goals are called “generic” because the same goal
statement applies to multiple process areas
Copyright 2004, Carnegie Mellon University. All rights reserved.
41
Generic Practices (GPs)
Generic Practices are activities that ensure that the
processes associated with the process area will be
effective, repeatable, and lasting
Generic Practices contribute to the achievement of the
generic goal when applied to a particular process area
Copyright 2004, Carnegie Mellon University. All rights reserved.
42
Generic Goals And Practices
Level
CL 1
CL 2
ML 3
ML 4
ML 5
Generic Goals
Generic Practices
GG1: Achieve
Specific Goals
GP 1.1: Perform Base Practices
GG2: Institutionalize
a Managed Process
GP 2.1: Establish an Organizational Policy
GP 2.2: Plan the Process
GP 2.3: Provide Resources
GP 2.4: Assign Responsibility
GP 2.5: Train People
GP 2.6: Manage Configurations
GP 2.7: Identify and Involve Relevant Stakeholders
GP 2.8: Monitor and Control the Process
GP 2.9: Objectively Evaluate Adherence
GP 2.10: Review Status with Higher Level Management
ML 2
CL3
GG3: Institutionalize
a Defined Process
GP 3.1: Establish a Defined Process
GP 3.2: Collect Improvement Information
CL4
GG4: Institutionalize
a Quantitatively
Managed Process
GP 4.1: Establish Quantitative Objectives for the Process
GP 4.2: Stabilize Subprocess Performance
CL5
GG5: Institutionalize
an Optimizing
Process
GP 5.1: Ensure Continuous Process Improvement
GP 5.2: Correct Root Causes of Problems
Copyright 2003, CSSA, Inc. Used with permission.
Common Features Mapping
Commitment to Perform
Ability to Perform
Directing Implementation
Verifying Implementation
Improving Maturity Levels (Staged
Representation)
GP 2.1- GP 3.2 applied to All Process
Areas in ML 2, ML 3, ML 4, and ML 5
All SP’s for the ML 2, ML 3, ML 4, and
ML 5 Process Areas
GP 2.1- GP 3.2 applied to All Process
Areas in ML 2, ML 3, and ML 4
All SP’s for the ML 2, ML 3, and ML 4
Process Areas
GP 2.1- GP 3.2 applied to All Process
Areas in ML 2 and ML 3
All SP’s for the ML 2 and ML 3
Process Areas
GP 2.1- GP 2.10 applied to all
process areas in ML 2
All SP’s for the ML 2 Process Areas
ML5
Optimizing
Defect Prevention; Proactive
Improvement; Innovative Technology
Insertion and Deployment
ML4
Quantitatively Managed
Measure Process Performance; Stabilize
Process; Control Charts; Deal With Causes
of Special Variations
ML3
Defined
Project’s Process Is Tailored From
Organization’s Standard Processes;
Understand Process Qualitatively; Process
Contributes to the Organization’s Assets
ML2
Managed
ML1
Initial
Adhere to Policy; Follow Documented
Plans and Processes; Apply Adequate
Resources; Assign Responsibility and
Authority; Train People; Apply CM;
Monitor and Control Process; Evaluate
Process and Product Quality; Identify and
Involve Stakeholders; Review With
Management
Process Is Unpredictable
Improving A Process Area (Continuous
Representation)
GP1.1 through GP5.2
CL1+CL2*+CL3* SPs
CL5
Optimizing
GP1.1 through GP4.2
CL1+CL2*+CL3* SPs
CL4
Quantitatively Managed
GP1.1 through GP3.2
CL1+CL2*+CL3* SPs
CL3
Defined
GP1.1 through GP2.10
CL1 + CL2* SPs
CL2
Managed
GP1.1
CL1 (base) SPs
CL1
Performed
No GPs or SPs exist
CL0
Incomplete
* Advanced practices exist only in the Engineering PAs.
Defect Prevention; Proactive Improvement;
Innovative Technology Insertion and Deployment
Measure Process Performance; Stabilize
Process; Control Charts; Deal With Causes
of Special Variations
Project’s Process Is Tailored From Organization’s
Standard Processes; Understand Process Qualitatively;
Process Contributes to the Organization’s Assets
Adhere to Policy; Follow Documented Plans and
Processes;Apply Adequate Resources; Assign
Responsibility and Authority; Train People; Apply CM;
Monitor and Control Process; Evaluate Process and
Product Quality; Identify and Involve Stakeholders;
Review With Management
Perform the Work
Not Performed, Incomplete
Required Components in CMMI
Continuous
Staged
Maturity Levels
(1-5)
Process Area 1
Process Area N
Process Area 1
Process Area 2
Generic Goals
Process Area 2
Specific Goals
(2-3)
Process Area N
Generic Goals
Specific Goals
(1-5)
Common Features
Commitment
To Perform
Ability
To Perform
Directing
Implementation
Capability Levels
Verification
(0-5)
These model components
 Are essential to achieving process improvement in a given
Process
Area
Generic Practices
Generic Practices
(1.1, 2.1-2.10
 Are (2.1-2.10
used in appraisals toSpecific
determine
Process
Area Capability
Practices
Specific Practices
3.1-3.2, 4.1-4.2
3.1-3.2)
5.1-5.2)
Expected Components in CMMI
Continuous
Staged
Maturity Levels
(1-5)
Process Area 1
Process Area N
Process Area 1
Process Area 2
Commitment
To Perform
Process Area N
Process Area 2
Generic
Goals
Generic Goals
These
model
components Specific Goals
Specific Goals
(2-3)
(1-5)
 Explain what will typically be done to cover the scope of
the process
and its goals
Common Features
 Are meant to guide model users and help appraisers
 AllowDirecting
acceptable
alternatives
Capability Levels
Ability
Verification
To Perform
(0-5)
Implementation
Generic Practices
(2.1-2.10
3.1-3.2)
Specific Practices
Generic Practices
(1.1, 2.1-2.10
3.1-3.2, 4.1-4.2
5.1-5.2)
Specific Practices
Informative Model Components
Everything else is informative
These model components provide details about
the model
Copyright 2004, Carnegie Mellon University. All rights reserved.
48
Pittsburgh, PA 15213-3890
PROCESS AREA CONTENTS AND
RELATED BUSINESS ISSUES
Copyright 2004, Carnegie Mellon University. All rights reserved.
Project Management (ML 2):
PP (1 of 4)
Project Planning
Purpose: Establish and Maintain Plans That Define Project Activities
Estimates of project planning
parameters are established
and maintained
A project plan is established
and maintained as the basis
for managing the project
Copyright 2004, Carnegie Mellon University. All rights reserved.
Commitments to the project
plan are established and
maintained
50
Project Management (ML 2):
PP (2 of 4)
Project Planning
Establish Estimates
Estimate the Scope of
The Project
Establish Estimates of Work
Product & Task Attributes
Develop a Project
Plan
Obtain Commitment
To the Plan
• Task Descriptions
• Work Package Descriptions
• WBS
• Technical Approach
• Size and Complexity of Tasks and Work Products
• Estimating Models
Define Project Life
Cycle
• Project Life-Cycle Phases
Determine Estimates of
Effort & Cost
• Estimation Rationale
• Project Effort Estimates
• Project Cost Estimates
Goals
Copyright 2004, Carnegie Mellon University. All rights reserved.
Practices
Typical Work Products
51
Project Management (ML 2):
PP (3 of 4)
Project Planning
Establish Estimates
Develop a Project
Plan
Establish the Budget &
Schedule
Identify Project Risks
Goals
Obtain Commitment
To the Plan
• Project Schedules
• Schedule Dependencies
• Project Budget
• Identified Risks
• Risk Impacts and Probability of Occurrence
• Risk Priorities
Plan for Data Management
• Data Management Plan
• Master List of Managed Data
• Data Content and Format Description
Plan for Project Resources
• WBS Work Packages
• WBS Task Dictionary
• Staffing Requirements Based on Project Size & Scope
Plan for Needed Knowledge
& Skills
• Inventory of Skill Needs
• Staffing and New Hire Plans
• Databases (e.g., Skills and Training)
Practices
Typical Work Products
Plan Stakeholder
Involvement
Establish the Project Plan
Copyright 2004, Carnegie Mellon University. All rights reserved.
• Stakeholder Involvement Plan
• Overall Project Plan
52
Project Management (ML 2):
PP (4 of 4)
Project Planning
Establish Estimates
Develop a Project
Plan
Obtain Commitment
To the Plan
Review Plans That Affect
The Project
Reconcile Work and
Resource Levels
Goals
Obtain Plan Commitment
Practices
• Record of the Reviews of
Plans that Affect the Project
• Revised Methods and Corresponding
Estimating Parameters
• Renegotiated Budgets
• Revised Schedules
• Documented Requests for Commitments
• Documented Commitments
Typical Work Products
Copyright 2004, Carnegie Mellon University. All rights reserved.
53
When Project Planning isn’t done
well…
Symptoms
•
•
•
•
•
Poor estimates that lead to cost and schedule overruns
Failed projects
Unable to discover deviations from undocumented plans
Resources aren’t available/applied when needed
Unable to meet commitments
Why Should You Care? Because….
• Customers don’t trust suppliers who waste their resources -- loss of
future business
• No lessons learned for future projects means making the same
mistakes on multiple projects
• Unhappy customers, employees ,and stockholders means a short life
for the business
• If you fail to plan then you plan to fail!
Copyright 2004, Carnegie Mellon University. All rights reserved.
54
Project Management (ML 2):
PMC (1 of 3)
Project Monitoring & Control
Purpose: Provide an Understanding of the Project’s Progress So That
Appropriate Corrective Actions Can Be Taken When the Project’s
Performance Deviates Significantly From the Plan.
Actual Performance and
Progress of the Project are
Monitored Against the
Project Plan
Copyright 2004, Carnegie Mellon University. All rights reserved.
Corrective Actions are
Managed to Closure When the
Project’s Performance or
Results Deviate Significantly
From the Plan
55
Project Management (ML 2):
PMC (2 of 3)
Project Monitoring & Control
Monitor Project
Against Plan
Monitor Project Planning
Parameters
Monitor Commitments
Monitor Project Risks
Monitor Data Management
Manage Corrective
Action to Closure
• Records of Project Performance
• Records of Significant Deviations
• Records of Commitment Reviews
• Records of Project Risk Monitoring
• Records of Data Management
Monitor Stakeholder
Involvement
• Records of Stakeholder Involvement
Conduct Progress Reviews
• Documented Project Review Results
Conduct Milestone Reviews
Goals
Practices
Typical Work Products
• Documented Milestone Review Results
Copyright 2004, Carnegie Mellon University. All rights reserved.
56
Project Management (ML 2):
PMC (3 of 3)
Project Monitoring & Control
Monitor Project
Against Plan
Manage Corrective
Action to Closure
Analyze Issues
Take Corrective Action
• List of Issues Needing Corrective Actions
• Corrective Action Plan
Goals
Practices
Manage Corrective Action
• Corrective Action Results
Typical Work Products
Copyright 2004, Carnegie Mellon University. All rights reserved.
57
When Project Monitoring and
Control isn’t done well….
Symptoms
• Crisis management
• High rework levels throughout the project
• Lots of time spent in meetings trying to “discover” project status rather
than reporting on it
• Data needed for management decisions is unavailable when needed
• Actions that should have been taken early on aren’t discovered until
it’s too late
Why Should You Care? Because….
• If you don’t know what’s going on, corrective action can’t be taken
early when it’s least expensive
• Lack of management insight/oversight makes project results highly
unpredictable, even later in the project
• If your confidence in the status you give to your customer is low, they
probably perceive that!
Copyright 2004, Carnegie Mellon University. All rights reserved.
58
Project Management (ML 2):
SAM (1 of 3)
Supplier Agreement Management
Purpose: Manage the Acquisition of Products From
Suppliers for Which There Exists a Formal Agreement.
Agreements With the
Suppliers are Established
and Maintained
Copyright 2004, Carnegie Mellon University. All rights reserved.
Agreements With the
Suppliers are Satisfied by
Both the Project and the
Supplier
59
Project Management (ML 2):
SAM (2 of 3)
Supplier Agreement Management
Establish Supplier
Agreements
Determine Acquisition Type
Select Suppliers
Establish Supplier
Agreements
Goals
Satisfy Supplier
Agreements
• List of the Acquisition Types That Will
be Used for All Products and Product
Components to be Acquired
• List of Candidate Suppliers
• Preferred Supplier List
• Rationale for Selection of Suppliers
• Statements of Work
• Contracts
• Memoranda of Agreement
Practices
Typical Work Products
Copyright 2004, Carnegie Mellon University. All rights reserved.
60
Project Management (ML 2):
SAM (3 of 3)
Supplier Agreement Management
Establish Supplier
Agreements
Satisfy Supplier
Agreements
Review COTS Products
Execute the Supplier
Agreement
Goals
Accept the Acquired Product
• Trade Studies
• Price Lists
• Evaluation Criteria
• Supplier Progress Reports and Performance
Measures
• Supplier Review Materials and Reports
• Action items tracked to Closure
• Acceptance Test Procedures
• Acceptance Test Results
• Discrepancy Reports or Corrective Action Plans
Practices
Typical Work Products
Transition Products
Copyright 2004, Carnegie Mellon University. All rights reserved.
• Transition Plans
• Training Reports
• Support and Maintenance Reports
61
When Supplier Agreement
Management isn’t done well…
Symptoms:
• Sub-optimal Supplier selection– not based on the right criteria
• Integration of supplier products into product baseline is
problematic
• Management and technical staff do not have insight into
supplier’s activities
• Supplier issues are not uncovered in a timely manner
• Supplier products are accepted even when they don’t meet the
product requirements
Why Should You Care? Because….
• A supplier can make or break your project
• You are ultimately responsible to your customer for supplier
performance
Copyright 2004, Carnegie Mellon University. All rights reserved.
62
Project Management (ML 3):
IPM (1 of 3)
Integrated Project Management
Purpose: Establish and Manage the Project and the Involvement of the
Relevant Stakeholders According to an Integrated and Defined Process That Is
Tailored From the Organization's Set of Standard Processes.
The Project is Conducted
Using a Defined Process That
is Tailored from the
Organization’s Set of
Standard Processes
Copyright 2004, Carnegie Mellon University. All rights reserved.
Coordination and
Collaboration of the Project
With Relevant Stakeholders
is Conducted
63
Interaction Between OPD and IPM
Organization’s Set
of Standard Processes
Life-Cycle Model
Descriptions
Organization’s
Measurement
Repository
Process
Architectures
Organizational Assets
Tailoring
Guidelines
Organization’s
Process
Asset Library
OPD
Project Environment
IPM
Reviews
Project A’s
Defined Process
Project B’s
Defined Process
Project C’s
Defined Process
Reviews
Project A’s
Project Plan
Project B’s
Project Plan
Copyright 2004, Carnegie Mellon University. All rights reserved.
Project C’s
Project Plan
64
Project Management (ML 3):
IPM (2 of 3)
Integrated Project Management
Coordinate and
Collaborate With
Relevant
Stakeholders
Use the Project’s
Defined Process
Establish the Project’s Defined
Process
Goals
Practices
• The Project’s Defined Process
Use Organizational Process
Assets for Planning Project
Activities
• Project Estimates
• Project Plans
Integrate Plans
• Integrated Plans
Manage the Project Using the
Integrated Plans
• Work Products Created by Performing the Project’s Defined Process
• Collected Measures (“Actuals”) and Progress Records or Reports
• Revised Requirements, Plans, and Commitments
Typical Work Products
Contribute to the
Organizational Process Assets
• Proposed Improvements to the Organizational Process Assets
• Actual Process and Product Measures Collected From the Project
• Documentation (e.g., exemplary process descriptions, plans, training modules,
checklists, and lessons learned)
Copyright 2004, Carnegie Mellon University. All rights reserved.
65
Project Management (ML 3):
IPM (3 of 3)
Integrated Project Management
Use the Project’s
Defined Process
Coordinate and
Collaborate With
Relevant
Stakeholders
Manage Stakeholder
Involvement
Manage Dependencies
Goals
• Agendas and Schedules for Collaborative Activities
• Documented Issues (e.g., issues with customer
requirements, product and product-component
requirements, product architecture, and product design)
• Recommendations for Resolving Relevant Stakeholder
Issues
• Defects, Issues, and Action Items Resulting From
Reviews With Relevant Stakeholders
• Critical Dependencies
• Commitments to Address Critical Dependencies
Practices
Typical Work Products
Resolve Coordination
Issues
Copyright 2004, Carnegie Mellon University. All rights reserved.
• Relevant Stakeholder Coordination Issues
• Status of Relevant Stakeholder Coordination Issues
66
When Integrated Project
Management isn’t done well…..
Symptoms:
• Unclear responsibilities across functional area boundaries
• No integrated master schedule is available to guide the stakeholders of the
project
• Data/artifacts to support future similar projects aren’t available when needed
• Relationship of project’s process/plans to organizational standards is unclear
Why Should You Care? Because…..
• Managing a “stovepiped” project increases the time/effort needed to assure
that all the requirements are being met
• Different stakeholders stepping on each other’s toes is a huge waste of
time/effort/money
• The customer will see different perspectives, status, etc from different
elements of the same project
• You may be the project manager for the “next” project and will need all the
help you can get from past projects
• You may be using less effective processes than the organization knows about
through its standard processes
Copyright 2004, Carnegie Mellon University. All rights reserved.
67
Project Management (ML 3):
RSKM (1 of 4)
Risk Management
Purpose: Identify Potential Problems Before They Occur, So That Risk-handling
Activities May Be Planned and Invoked As Needed Across the Life of the Product or
Project to Mitigate Adverse Impacts on Achieving Objectives.
Preparation for Risk
Management is Conducted
Risks are Identified and
Analyzed to Determine Their
Relative Importance
Copyright 2004, Carnegie Mellon University. All rights reserved.
Risks are Handled and
Mitigated, Where
Appropriate, to Reduce
Adverse Impacts on
Achieving Objectives
68
Project Management (ML 3):
RSKM (2 of 4)
Risk Management
Prepare for Risk
Management
Determine Risk Sources and
Categories
Define Risk Parameters
Establish a Risk
Management Strategy
Identify and Analyze
Risks
Mitigate Risks
• Risk Source Lists (external and internal)
• Risk Categories List
• Risk Evaluation, Categorization, and Prioritization Criteria
• Risk Management Requirements (control and approval
levels, reassessment intervals, etc.)
• Project Risk Management Strategy
Goals
Practices
Typical Work Products
Copyright 2004, Carnegie Mellon University. All rights reserved.
69
Project Management (ML 3):
RSKM (3 of 4)
Risk Management
Prepare for Risk
Management
Identify and Analyze
Risks
Identify Risks
Evaluate, Categorize, and
Prioritize Risks
Mitigate Risks
• List of Identified Risks, Including the Context,
Conditions, and Consequences of Risk Occurrence
• List of Risks, With a Priority Assigned to Each Risk
Goals
Practices
Typical Work Products
Copyright 2004, Carnegie Mellon University. All rights reserved.
70
Project Management (ML 3):
RSKM (4 of 4)
Risk Management
Prepare for Risk
Management
Identify and Analyze
Risks
Mitigate Risks
Develop Risk Mitigation
Plans
Implement Risk Mitigation
Plans
• Documented Handling Options for
Each Identified Risk
• Risk Mitigation Plans
• Updated Lists of Risk Status
• Updated Assessment of Risk Likelihood,
Consequence, and Thresholds
• Updated Lists of Risk-Handling Options
Goals
Practices
Typical Work Products
Copyright 2004, Carnegie Mellon University. All rights reserved.
71
When Risk Management isn’t
done well…
Symptoms:
• Idealistic approach that assumes “all is well” even when there
is evidence that all is NOT well
• Issues that are known risks to project staff are a surprise to
management
• Every time a new problem manifests, a new management
technique is tried
Why Should You Care? Because…
• The project may escape some of the “bullets”, but not all
• No lessons learned for future projects means making the same
mistakes on multiple projects
• Repeated project failures due to the realization of unforeseen
(but predictable!) risks costs you business, if not the whole
company
Copyright 2004, Carnegie Mellon University. All rights reserved.
72
Project Management (ML 3):
ISM (1 of 3)
Integrated Supplier Management
Purpose: Proactively Identify Sources of Products That May Be Used to
Satisfy the Project’s Requirements and Manage Selected Suppliers While
Maintaining a Cooperative Project-supplier Relationship.
Potential Sources of Products
That Best Fit the Needs of the
Project are Identified, Analyzed,
and Selected
Copyright 2004, Carnegie Mellon University. All rights reserved.
Work is Coordinated With
Suppliers to Ensure the Supplier
Agreement is Executed
Appropriately
73
Project Management (ML 3):
ISM (2 of 3)
Integrated Supplier Management
Analyze and Select
Sources of Products
Analyze Potential Sources of
Products
Evaluate and Determine
Sources of Products
Coordinate Work
With Suppliers
• List of Potential Sources of Products That Might be Acquired
• Market Studies
• Trade Studies
• Analysis and Evaluation Reports
• Revised List of Product Sources
Goals
Practices
Typical Work Products
Copyright 2004, Carnegie Mellon University. All rights reserved.
74
Project Management (ML 3):
ISM (3 of 3)
Integrated Supplier Management
Analyze and Select
Sources of Products
Goals
Coordinate Work
With Suppliers
Monitor Selected Supplier
Processes
• List of Processes Selected for Monitoring
• Activity Reports
• Performance Reports
Evaluate Selected Supplier
Work Products
• List of Work Products Selected for Monitoring
• Activity Reports
• Discrepancy Reports
Revise the Supplier
Agreement or Relationship
• Revisions to the Supplier Agreement
• Revisions to the Project’s and Supplier’s
Processes and Work Products
Practices
Typical Work Products
Copyright 2004, Carnegie Mellon University. All rights reserved.
75
Support (ML 2):
CM (1 of 4)
Configuration Management
Purpose: Establish and Maintain the Integrity of Work Products Using
Configuration Identification, Configuration Control, Configuration
Status Accounting, and Configuration Audits.
Baselines of Identified Work
Products are Established
Changes to the Work Products
Under Configuration
Management are Tracked and
Controlled
Copyright 2004, Carnegie Mellon University. All rights reserved.
Integrity of Baselines is
Established and Maintained
76
Support (ML 2):
CM (2 of 4)
Configuration Management
Establish Baselines
Identify Configuration
Items
Establish a Configuration
Management System
Create or Release Baselines
Goals
Track and Control
Changes
Establish Integrity
• Identified Configuration Items
• Configuration Management System With Controlled Work Products
• Configuration Management System Access Control Procedures
• Change Request Database
• Baselines
• Description of Baselines
Practices
Typical Work Products
Copyright 2004, Carnegie Mellon University. All rights reserved.
77
Support (ML 2):
CM (3 of 4)
Configuration Management
Establish Baselines
Track and Control
Changes
Track Change Requests
Control Configuration Items
Establish Integrity
• Change Requests
• Revision History of Configuration Items
• Archives of the Baselines
Goals
Practices
Typical Work Products
Copyright 2004, Carnegie Mellon University. All rights reserved.
78
Support (ML 2):
(4 of 4)
Configuration Management
Establish Baselines
Track and Control
Changes
Establish Integrity
Establish Configuration
Management Records
Perform Configuration
Audits
• Revision History of Configuration Items
• Change Log
• Copy of the Change Requests
• Configuration Audit Results
• Action Items
Goals
Practices
Typical Work Products
Copyright 2004, Carnegie Mellon University. All rights reserved.
79
When Configuration
Management isn’t done well…
Symptoms:
• Baseline system can’t be produced when needed
• Rework during test because components are not what was expected
• Complete inventory of system components unavailable when needed
- Causes wasted time to find parts and specs and interfaces
• Uncontrolled changes that lead to uncontrolled rework
Why Should You Care? Because…
• Not knowing what is in the product leads to embarrassing discussions
with customers
• Inability to rebuild/revisit a previous baseline wastes money and
resources during maintenance
• Not being able to verify that the product tested is the product delivered
costs you time, effort, and customer confidence
• If you don’t know what’s in or out of the product, you don’t know what
you don’t know!
Copyright 2004, Carnegie Mellon University. All rights reserved.
80
Support (ML 2):
PPQA (1 of 3)
Process and Product Quality Assurance
Purpose: Provide Staff and Management With Objective Insight Into Processes and
Associated Work Products.
Adherence of the Performed Process
and Associated Work Products and
Services to Applicable Process
Descriptions, Standards, and
Procedures is Objectively Evaluated
Copyright 2004, Carnegie Mellon University. All rights reserved.
Noncompliance Issues are Objectively
Tracked and Communicated, and
resolution is ensured
81
Support (ML 2):
PPQA (2 of 3)
Process and Product Quality Assurance
Objectively Evaluate
Processes and Work
Products
Provide Objective
Insight
Objectively Evaluate
Processes
• Evaluation Reports
• Noncompliance Reports
• Corrective Actions
Objectively Evaluate Work
Products and Services
• Evaluation Reports
• Noncompliance Reports
• Corrective Actions
Goals
Practices
Typical Work Products
Copyright 2004, Carnegie Mellon University. All rights reserved.
82
Support (ML 2):
PPQA (3 of 3)
Process and Product Quality Assurance
Objectively Evaluate
Processes and Work
Products
Provide Objective
Insight
Communicate and Ensure
Resolution of
Noncompliance Issues
Establish Records
Goals
• Corrective Action Reports
• Evaluation Reports
• Quality Trends
• Evaluation Logs
• Quality Assurance Reports
• Status Reports of Corrective Actions
Practices
Typical Work Products
Copyright 2004, Carnegie Mellon University. All rights reserved.
83
When Process and Product Quality
Assurance aren’t done well…
Symptoms:
• No assurance is available that quality standards are followed or
achieved
• Poor quality work products being produced
• Ineffective processes that staff avoid using
• No accountability for not following process or meeting standards
• Significant project issues are not escalated for management
attention
Why Should You Care? Because…
• Loss of management insight into development process can cause
significant issues to be missed
• Poor quality interim products reduce customer’s confidence that
you can provide a high quality delivered product
- You’re likely to lose that customer’s business in future
Copyright 2004, Carnegie Mellon University. All rights reserved.
84
Support (ML 2):
MA (1 of 3)
Measurement & Analysis
Purpose: Develop and Sustain a Measurement Capability That Is
Used to Support Management Information Needs.
Measurement Objectives and
Activities are Aligned With
Identified Information Needs and
Objectives
Copyright 2004, Carnegie Mellon University. All rights reserved.
Measurement Results That
Address Identified Information
Needs and Objectives are
Provided
85
Support (ML 2):
MA (2 of 3)
Measurement & Analysis
Align Measurement
and Analysis
Activities
Establish Measurement
Objectives
Specify Measures
• Measurement Objectives
• Specifications of Base and Derived Measures
Specify Data Collection and
Storage Procedures
• Data Collection and Storage Procedures
• Data Collection Tools
Specify Analysis Procedures
• Analysis Specification and Procedures
• Data Analysis Tools
Goals
Practices
Provide
Measurement
Results
Typical Work Products
Copyright 2004, Carnegie Mellon University. All rights reserved.
86
Support (ML 2):
MA (3 of 3)
Measurement & Analysis
Align Measurement
and Analysis
Activities
Provide
Measurement
Results
Collect Measurement Data
Analyze Measurement Data
Goals
Store Data and Results
Practices
Typical Work Products
Communicate Results
Copyright 2004, Carnegie Mellon University. All rights reserved.
• Base and Derived Measurement Data Sets
• Results of Data Integrity Tests
• Analysis Results and Draft Reports
• Stored Data Inventory
• Delivered Reports and Related Analysis Results
• Contextual Information or Guidance to Aid in the
Interpretation of Analysis Results
87
When Measurement and
Analysis isn’t done well…
Symptoms:
• Measurements unknowingly used inappropriately/ out of context
• Management by perception/judgment vs. by fact
• Measurement presentations being used to confuse rather than
enlighten
• Useless measures being collected
Why Should You Care? Because…
• Poor decisions that cannot be justified reduce customer and staff
confidence
• Collected measures don’t allow you to quantify how close you are
to meeting your business goals
• Having no valid basis for prioritizing improvements could lead you
to significant wasted overhead time, effort, money
• High risk for not meeting customer expectations wrt.
delivery/quality of product
Copyright 2004, Carnegie Mellon University. All rights reserved.
88
Support (ML 3):
DAR (1 of 2)
Decision Analysis & Resolution
Purpose: Analyze Possible Decisions Using a Formal Evaluation Process
That Evaluates Identified Alternatives Against Established Criteria.
Decisions are Based on an Evaluation of
Alternatives Using Established Criteria
Copyright 2004, Carnegie Mellon University. All rights reserved.
89
Support (ML 3):
DAR (2 of 2)
Decision Analysis & Resolution
Evaluate Alternatives
Establish Guidelines for
Decision Analysis
Establish Evaluation Criteria
Identify Alternative
Solutions
Goals
Select Evaluation Methods
• Guidelines for When to Apply a Formal Evaluation Process
• Documented Evaluation Criteria
• Rankings of Criteria Importance
• Identified Alternatives
• Selected Evaluation Methods
Practices
Typical Work Products
Evaluate Alternatives
Select Solutions
Copyright 2004, Carnegie Mellon University. All rights reserved.
• Evaluation Results
• Recommended Solutions to Address Significant Issues
90
When Decision Analysis &
Resolution isn’t done well…..
Symptoms:
•
•
•
•
Unclear who is authorized to make what decisions
Decisions are made on primarily subjective basis
Same issue is “decided” over and over and over……
Rationale for earlier decisions is unavailable when needed to
understand the decision later in the project
• Only a few choices considered for major decisions
Why Should You Care? Because…..
• Decisions getting made without all the relevant factors being
considered usually costs time or money later on
• Missing a more optimal solution can cost you time, money, credibility,
perhaps even the whole project
• Revisiting decisions, digging up rationale, undoing decisions reduce
customer confidence in your expertise and technical ability to serve
their needs
Copyright 2004, Carnegie Mellon University. All rights reserved.
91
The Engineering Process Areas
Requirements
REQM
Product and product
component requirements
Alternative
solutions
RD
Product
components
TS
Product
PI
Customer
Requirements
Product components,
verification and
work products,
validation reports
Ver
Val
Customer needs
Copyright 2004, Carnegie Mellon University. All rights reserved.
92
Engineering (ML 2):
REQM (1 of 2)
Requirements Management
Purpose: Manage the Requirements of the Project's Products and
Product Components and Identify Inconsistencies Between Those
Requirements and the Project's Plans and Work Products.
Requirements are Managed and
Inconsistencies With Project Plans and
Work Products are Identified
Copyright 2004, Carnegie Mellon University. All rights reserved.
93
Engineering (ML 2):
REQM (2 of 2)
Requirements Management
Manage
Requirements
Obtain an Understanding of
Requirements
• List of Criteria for Distinguishing Appropriate Requirements
Providers
• Criteria for Evaluation and Acceptance of Requirements
• Results of Analysis Against Criteria
Obtain Commitment to
Requirements
• Requirements Impact Assessments
• Documented Commitments to Requirements and
Requirements Changes
Manage Requirements
Changes
• Requirements Status
• Requirements Database
• Requirements Decision Database
Maintain Bidirectional
Traceability of
Requirements
• Requirements Traceability Matrix
• Requirements Tracking System
Goals
Practices
Typical Work Products
Identify Inconsistencies
Between Project Work and
Requirements
Copyright 2004, Carnegie Mellon University. All rights reserved.
• Documentation of Inconsistencies Including Sources,
Conditions, and Rationale
• Corrective Actions
94
When Requirements Management
isn’t done well….
Symptoms:
• High levels of re-work throughout the project
• Requirements accepted by staff from any source they deem to be
authoritative
• “Galloping” requirements creep
• Inability to “prove” that the product meets the approved requirements
Why Should You Care? Because….
• Lack of agreement among stakeholders as to what are the “real”
requirements increases time and cost to complete the project
• You’re highly likely to deliver an incorrect or incomplete product
• Revisiting requirements changes over and over is a waste of resource
highly visible to the customer
Copyright 2004, Carnegie Mellon University. All rights reserved.
95
Engineering (ML 3):
RD (1 of 4)
Requirements Development
Purpose: Produce and Analyze Customer, Product, and Productcomponent Requirements.
Shareholder Needs,
Expectations, Constraints,
and Interfaces are Collected
and Translated Into Customer
Requirements
Customer Requirements are
Refined and Elaborated to
Develop Product and ProductComponent Requirements
Copyright 2004, Carnegie Mellon University. All rights reserved.
The Requirements are
Analyzed and Validated, and a
Definition of Required
Functionality is Developed
96
Engineering (ML 3):
RD (2 of 4)
Requirements Development
Develop Customer
Requirements
Develop Product
Requirements
Analyze and Validate
Requirements
Collect Stakeholder Needs
Elicit Needs
Goals
Develop the Customer
Requirements
• Customer Requirements
• Customer Constraints on the Conduct of Verification
• Customer Constraints on the Conduct of Validation
Practices
Typical Work Products
Continuous Representation Only
Copyright 2004, Carnegie Mellon University. All rights reserved.
97
Engineering (ML 3):
RD (3 of 4)
Requirements Development
Develop Customer
Requirements
Develop Product
Requirements
Analyze and Validate
Requirements
Establish Product and
Product-component
Requirements
• Derived Requirements
• Product Requirements
• Product-Component Requirements
Allocate Product-component
Requirements
• Requirement Allocation Sheets
• Provisional Requirement Allocations
• Design Constraints
Goals
Identify Interface
Requirements
• Interface Requirements
Practices
Typical Work Products
Copyright 2004, Carnegie Mellon University. All rights reserved.
98
Engineering (ML 3):
RD (4 of 4)
Requirements Development
Develop Customer
Requirements
Develop Product
Requirements
Analyze and Validate
Requirements
Establish Operational
Concepts and Scenarios
Establish a Definition of
Required Functionality
Analyze Requirements
Goals
Practices
Analyze Requirements to
Achieve Balance
• Operational Concept
• Product Installation, Operational, Maintenance,
and Support Concepts
• Disposal Concepts
• Functional Architecture
• Activity Diagrams and Use Cases
• Object-Oriented Analysis With Services Identified
• Requirements Defects Reports
• Proposed Requirements Changes to Resolve Defects
• Key Requirements
• Assessment of Risks Related to Requirements
Typical Work Products
Continuous Representation Only
Validate Requirements
Validate Requirements With
Comprehensive Methods
Copyright 2004, Carnegie Mellon University. All rights reserved.
• Results of Requirements Validation
• Record of Analysis Methods and Results
99
When Requirements
Development isn’t done well…
Symptoms:
• Unstated requirements, poorly stated requirements that lead to
confusion among staff and customers
• Design, implementation, and test work products that inconsistently
interpret the requirements
• Inordinately long time to get to agreement on product design
Why Should You Care? Because…
• Unusable products and unhappy customers lead to loss of future
business
• Wasted time and resources building product to requirements that
customer may not want threatens your profitability
• Staff get tired of re-doing work because the requirements have been
re-interpreted “yet again”
• The potential for excessive spending to meet customer expectations
increases when you don’t identify requirements well
Copyright 2004, Carnegie Mellon University. All rights reserved.
100
Engineering (ML 3):
TS (1 of 4)
Technical Solution
Purpose: Design, Develop, and Implement Solutions to Requirements.
Solutions, Designs, and Implementations encompass Products,
Product Components, and Product-related Lifecycle Processes
Product or Product-Component
Solutions are Selected From
Alternative Solutions
Product or Product-Component
Designs are Developed
Copyright 2004, Carnegie Mellon University. All rights reserved.
Product Components, and
Associated Support
Documentation, are
Implemented From Their
Designs
101
Engineering (ML 3):
TS (2 of 4)
Technical Solution
Select ProductComponent
Solutions
Develop Alternative
Solutions and Selection
Criteria
Develop Detailed Alternative
Solutions and Selection
Criteria
Evolve Operational Concepts
and Scenarios
Select Product-component
Solutions
Develop the Design
Implement the
Product Design
• Alternative Solutions
• Selection Criteria
• Alternative Solution Screening Criteria
• Evaluations of New Technologies
• Alternative Solutions
• Product-Component Operational Concepts, Scenarios, and
Environments for All Product-Related Life-Cycle Processes
• Timeline Analyses of Product-Component Interactions
• Use Cases
• Product-Component Selection Decisions and Rationale
• Documented Relationships Between Requirements and Product Components
• Documented Solutions, Evaluations, and Rationale
Goals
Practices
Typical Work Products
Continuous Representation Only
Copyright 2004, Carnegie Mellon University. All rights reserved.
102
Engineering (ML 3):
TS (3 of 4)
Technical Solution
Select ProductComponent
Solutions
Develop the Design
Design the Product or
Product Component
Establish a Technical Data
Package
Goals
Establish Interface
Descriptions
Implement the
Product Design
• Product Architecture
• Product-Component Designs
• Technical Data Package
• Interface Design
• Interface Design Documents
Practices
Typical Work Products
Design Interfaces Using
Criteria
Continuous Representation Only
Perform Make, Buy, or
Reuse Analyses
Copyright 2004, Carnegie Mellon University. All rights reserved.
• Interface Design Specifications
• Interface Control Documents
• Interface Specification Criteria
• Criteria for Design and Product-Component Reuse
• Make-or-Buy Analyses
• Guidelines for Choosing COTS Product Components
103
Engineering (ML 3):
TS (4 of 4)
Technical Solution
Select ProductComponent
Solutions
Develop the Design
Implement the
Product Design
Implement the Design
Develop Product Support
Documentation
• Implemented Design
• End-User Training Materials
• User’s Manual
• Operator’s Manual
Goals
Practices
Typical Work Products
Copyright 2004, Carnegie Mellon University. All rights reserved.
104
When Technical Solution isn’t
done well…
Symptoms:
• Less than optimal solution is “settled on”
• Products that don’t meet technical performance requirements
and/or user needs
• Increased testing/rework to resolve design/architecture issues
• Customer is surprised at the solution that resulted from their
requirements
Why Should You Care? Because…
• Increased cost to test and to address rework
• Future business is at risk with the customer if performance
expectations aren’t met
• Product may not be able to accommodate technology
upgrades and future growth if technical solution isn’t well
conceived
Copyright 2004, Carnegie Mellon University. All rights reserved.
105
Engineering (ML 3):
PI (1 of 4)
Product Integration
Purpose: Assemble the Product From the Product Components, Ensure That
the Product, As Integrated, Functions Properly, and Deliver the Product.
Preparation for Product
Integration is Conducted
The Product-Component
Interfaces, Both Internal and
External, are Compatible
Copyright 2004, Carnegie Mellon University. All rights reserved.
Verified Product components
are Assembled and the
Integrated, Verified, and
Validated Product is Delivered
106
Engineering (ML 3):
PI (2 of 4)
Product Integration
Prepare for Product
Integration
Determine Integration
Sequence
Establish the Product
Integration Environment
Establish Product Integration
Procedures and Criteria
Ensure Interface
Compatibility
Assemble Product
Components and
Deliver the Product
• Product Integration Sequence
• Rationale for Selecting or Rejecting Integration Sequences
• Verified Environment for Product Integration
• Support Documentation for the Product Integration Environment
• Product Integration Procedures
• Product Integration Criteria
Goals
Practices
Typical Work Products
Copyright 2004, Carnegie Mellon University. All rights reserved.
107
Engineering (ML 3):
PI (3 of 4)
Product Integration
Prepare for Product
Integration
Goals
Ensure Interface
Compatibility
Assemble Product
Components and
Deliver the Product
Review Interface
Descriptions for
Completeness
• Categories of Interfaces
• List of Interfaces Per Category
• Mapping of the Interfaces to the Product Components
and Product Integration Environment
Manage Interfaces
• Table of Relationships Among the Product Components and the
External Environment
• Table of Relationships Between the Different Product Components
• List of Agreed-to Interfaces Defined for Each Pair of Product
Components, When Applicable
Practices
Typical Work Products
Copyright 2004, Carnegie Mellon University. All rights reserved.
108
Engineering (ML 3):
PI (4 of 4)
Product Integration
Prepare for Product
Integration
Ensure Interface
Compatibility
Assemble Product
Components and
Deliver the Product
Confirm Readiness of
Product Components for
Integration
Assemble Product
Components
Goals
Practices
Typical Work Products
Evaluate Assembled Product
Components
Package and Deliver the
Product or Product
Component
Copyright 2004, Carnegie Mellon University. All rights reserved.
• Acceptance Documents for the Received Product Components
• Delivery Receipts
• Checked Packing Lists
• Assembled Product or Product Components
• Exception Reports
• Interface Evaluation Reports
• Product Integration Summary Reports
• Packaged Product or Product Components
• Delivery Documentation
109
When Product Integration isn’t
done well…..
Symptoms:
• Subsystems don’t operate together
• Increased integration/test time
• Building test harnesses/procedures/etc late in the project
• Integration environment is inadequate to support the
integration activities
Why Should You Care? Because…..
• You can’t release the system until it operates as a unit
• You’ll spend more time in integration/test than you planned/can
afford
• You can’t accurately estimate integration-related costs,
reducing your customer’s confidence
• There’s nothing quite as embarrassing as installing a product
that doesn’t integrate with the customer’s system
Copyright 2004, Carnegie Mellon University. All rights reserved.
110
Verification Versus Validation
Verification
• Are you building the product right?
• That is, are you meeting the specified requirements?
Validation
• Are you building the right product?
• That is, are you meeting the operational need?
Copyright 2004, Carnegie Mellon University. All rights reserved.
111
Engineering (ML 3):
VER (1 of 4)
Verification
Purpose: Ensure That Selected Work Products Meet Their Specified Requirements.
Preparation for Verification is
Conducted
Peer Reviews are Performed
on Selected Work Products
Copyright 2004, Carnegie Mellon University. All rights reserved.
Selected Work Products are
Verified Against Their
Specified Requirements
112
Engineering (ML 3):
VER (2 of 4)
Verification
Prepare for
Verification
Perform Peer
Reviews
Select Work Products for
Verification
• List of Work Products Selected for Verification
• Verification Methods for Each Selected Work Product
Establish the Verification
Environment
• Verification Environment
Establish Verification
Procedures and Criteria
• Verification Procedures
• Verification Criteria
Verify Selected Work
Products
Goals
Practices
Typical Work Products
Copyright 2004, Carnegie Mellon University. All rights reserved.
113
Engineering (ML 3):
VER (3 of 4)
Verification
Prepare for
Verification
Perform Peer
Reviews
Prepare for Peer Reviews
Conduct Peer Reviews
Verify Selected Work
Products
• Peer Review Schedule
• Peer Review Checklist
• Entry and Exit Criteria for Work Products
• Peer Review Results
• Peer Review Issues
• Peer Review Data
Goals
Practices
Analyze Peer Review Data
• Peer Review Data
• Peer Review Action Items
Typical Work Products
Copyright 2004, Carnegie Mellon University. All rights reserved.
114
Engineering (ML 3):
VER (4 of 4)
Verification
Prepare for
Verification
Perform Peer
Reviews
Verify Selected Work
Products
Perform Verification
Goals
Practices
Analyze Verification Results
and Identify Corrective
Action
Typical Work Products
Copyright 2004, Carnegie Mellon University. All rights reserved.
• Verification Results
• Verification Reports
• Demonstrations
• Analysis Report (such as statistics on performances,
causal analysis of nonconformances, comparison of the
behavior between the real product and models, and trends)
• Trouble Reports
• Change Requests for the Verification Methods, Criteria,
and Environment
115
When Verification isn’t done
well…..
Symptoms:
• Disagreement among technical staff as to the “done-ness” of different
components
• Product under test doesn’t meet requirements/design expectations
• Defects that could have been caught early escape into later life cycle
phases
• Increased integration/test time
Why Should You Care? Because…..
• Product reliability suffers if defects aren’t detected/ corrected prior to
customer release
• Product costs more to test if early verification activities are ignored
• Customers don’t want to pay for defective products
- You probably won’t get their business next time
Copyright 2004, Carnegie Mellon University. All rights reserved.
116
Engineering (ML 3):
VAL (1 of 3)
Validation
Purpose: Demonstrate That a Product or Product Component
Fulfills Its Intended Use When Placed in Its Intended Environment.
Preparation for Validation is
Conducted
Copyright 2004, Carnegie Mellon University. All rights reserved.
The Product or Product
Components are Validated to
Ensure That They are Suitable
for Use in Their Intended
Operating Environment
117
Engineering (ML 3):
VAL (2 of 3)
Validation
Prepare for
Validation
Select Products for
Validation
Validate Product or
Product Components
• Lists of Products and Product Components Selected for Validation
• Validation Methods for Each product or Product Component
• Requirements for Performing Validation for Each Product or Product Component
Establish the Validation
Environment
• Validation Environment
Establish Validation
Procedures and Criteria
• Validation Procedures
• Validation Criteria
• Test and Evaluation Procedures for Maintenance, Training, and Support
Goals
Practices
Typical Work Products
Copyright 2004, Carnegie Mellon University. All rights reserved.
118
Engineering (ML 3):
VAL (3 of 3)
Validation
Prepare for
Validation
Validate Product or
Product Components
Perform Validation
Analyze Validation Results
Goals
• Validation Reports
• Validation Results
• Validation Cross-Reference Matrix
• Validation Deficiency Reports
• Validation Issues
• Procedure Change Request
Practices
Typical Work Products
Copyright 2004, Carnegie Mellon University. All rights reserved.
119
When Validation isn’t done
well…..
Symptoms:
• Lots of user change requests before/soon after the product is
released
• Arguments among the technical staff as to what the user
“really” wants
• Released product doesn’t meet user expectations
Why Should You Care? Because…..
• Customers don’t want to pay for products that don’t meet their
needs
• If an end user refuses to use the product as delivered, their
confidence in you is eroded
- You’ll spend a lot of money trying to “make it right” or you’ll
give up that customer’s future business
Copyright 2004, Carnegie Mellon University. All rights reserved.
120
Process Management (ML 3):
OPF (1 of 3)
Organizational Process Focus
Purpose: Plan and Implement Organizational Process Improvement Based
on a Thorough Understanding of the Organizational Process Assets
Strengths, Weaknesses, and
Improvement Opportunities for the
Organization’s Processes are Identified
Periodically and as Needed
Copyright 2004, Carnegie Mellon University. All rights reserved.
Improvements are Planned and
Implemented, Organizational Process
Assets are Deployed, and ProcessRelated Experiences are Incorporated
Into the Organizational Process Assets
121
Organizational Process Focus
Determine Process Improvement Opportunities
Establish
Organizational
Process Needs
Establish Process
Action Plans
Appraise the
Organization’s
Processes
Identify the
Organization’s
Process
Improvements
Plan and implement process improvement
Implement Process
Action Plans
Deploy Organizational
Process Assets
Copyright 2004, Carnegie Mellon University. All rights reserved.
“OPD”
Organization’s
Process Assets
122
Process Management (ML 3):
OPF (2 of 3)
Organizational Process Focus
Plan and Implement
Process
Improvement
Activities
Determine Process
Improvement
Opportunities
Establish Organizational
Process Needs
Appraise the Organization’s
Processes
Goals
• Organization’s Process Needs and Objectives
• Plans for the Organization’s Process Appraisals
• Appraisal Findings That Address Strengths and Weaknesses of the Organization’s Processes
• Improvement Recommendations for the Organization’s Processes
Practices
Typical Work Products
Identify the Organization's
Process Improvements
• Analysis of Candidate Process Improvements
• Identification of Improvements for the Organization’s Processes
Copyright 2004, Carnegie Mellon University. All rights reserved.
123
Process Management (ML 3):
OPF (3 of 3)
Organizational Process Focus
Determine Process
Improvement
Opportunities
Plan and Implement
Process
Improvement
Activities
Establish Process Action
Plans
Implement Process Action
Plans
• Organization’s Approved Process Action Plans
• Commitments Among the Various Process Action Teams
• Status and Results of Implementing Process Action Plans
• Plans for Pilots
Goals
Practices
Typical Work Products
Deploy Organizational
Process Assets
Incorporate Process-related
Experiences Into the
Organizational Process
Assets
Copyright 2004, Carnegie Mellon University. All rights reserved.
• Plans for Deploying the Organizational Process Assets and
Changes to Organizational Process Assets
• Training Materials for Deploying the Organizational Process
Assets and Changes to Organizational Process Assets
• Documentation of Changes to the Organizational Process Assets
• Process Improvement Proposals
• Process Lessons Learned
• Measurements on the Organizational Process Assets
124
When Organization Process
Focus isn’t done well…..
Symptoms:
• Lots of staff changes in the Engineering Process Group or equivalent
• Lack of visible senior management support for process improvement
activities
• The things that are chosen for improvement are not aligned with
business priorities
• False starts and rocky implementations of improvement efforts
Why Should You Care? Because…..
• Each time the organization visibly fails at improvement, the harder it is
to get support the next time
• Lack of alignment with business priorities means lots of overhead
money gets wasted
• If the organization can’t effectively support improvement, employee
pride in their work is eroded when they can’t meet customer
expectations
• Employees will only tolerate so many “improvements” that don’t work
before they look for another job
Copyright 2004, Carnegie Mellon University. All rights reserved.
125
Process Management (ML 3):
OPD (1 of 2)
Organizational Process Definition
Purpose: Establish and Maintain a Usable Set of Organizational Process Assets
A Set of Organizational Process Assets
is Established and Maintained
Copyright 2004, Carnegie Mellon University. All rights reserved.
126
Process Management (ML 3):
OPD (2 of 2)
Organizational Process Definition
Establish
Organizational
Process Assets
Establish Standard Processes
Goals
Practices
• Organization’s Set of Standard Processes
Establish Life-cycle Model
Descriptions
• Descriptions of Life-Cycle Models
Establish Tailoring Criteria
and Guidelines
• Tailoring Guidelines for the Organization’s
Set of Standard Processes
Establish the Organization’s
Measurement Repository
Typical Work Products
Establish the Organization’s
Process Asset Library
Copyright 2004, Carnegie Mellon University. All rights reserved.
• Definition of the Common Set of Product and Process
Measures for the Organization’s Set of Standard Processes
• Design of the Organization’s Measurement Repository
• Organization’s Measurement Repository (i.e., the
repository structure and support environment)
• Design of the Organization’s Process Asset Library
• Organization’s Process Asset Library
• Selected Items to be Included in the Organization’s Process
Asset Library
127
When Organization Process
Definition isn’t done well…..
Symptoms:
• Staff resist using the guidance in the standard processes that have
been defined
• “Mother of all process manuals” sits on the real (or virtual!) shelf
• Lots of time being spent getting process waivers
• Extreme amount of tailoring requested by each project
Why Should You Care? Because…..
• Since defining processes is an overhead task, defining processes that
can’t be used/cause lots of work to “get around” is a direct waste of
profit
• Using processes that are ineffective can cause many of the other
symptoms we’ve discussed
• Staff who lack confidence in the organization’s ability to provide useful
guidance will probably look elsewhere for jobs
• Lots of tailoring leads to less and less reuse of process knowledge
and skills, thus reducing your ROI in process definition activities
Copyright 2004, Carnegie Mellon University. All rights reserved.
128
Process Management (ML 3):
OT (1 of 3)
Organizational Training
Purpose: Develop the Skills and Knowledge of People So
They Can Perform Their Roles Effectively and Efficiently
A Training Capability That
Supports the Organization’s
Management and Technical Roles
is Established and Maintained
Copyright 2004, Carnegie Mellon University. All rights reserved.
Training Necessary for Individuals
to Perform Their Roles Effectively
is Provided
129
Process Management (ML 3):
OT (2 of 3)
Organizational Training
Establish an
Organizational
Training Capability
Establish the Strategic
Training Needs
Determine Which Training
Needs Are the Responsibility
of the Organization
Provide Necessary
Training
• Training Needs
• Assessment Analysis
• Common Project and Support Group Training Needs
• Training Commitments
Goals
Practices
Establish an Organizational
Training Tactical Plan
• Organizational Training Tactical Plan
Establish Training Capability
• Training Materials and Supporting Artifacts
Typical Work Products
Copyright 2004, Carnegie Mellon University. All rights reserved.
130
Process Management (ML 3):
OT (3 of 3)
Organizational Training
Establish an
Organizational
Training Capability
Provide Necessary
Training
Deliver Training
Establish Training Records
Goals
• Delivered Training Course
• Training Records
• Training Updates to the Organizational Repository
Practices
Typical Work Products
Assess Training Effectiveness
Copyright 2004, Carnegie Mellon University. All rights reserved.
• Training-Effectiveness Surveys
• Training Program Performance Assessments
• Instructor Evaluation Forms
131
When Organizational Training
isn’t done well…..
Symptoms:
• Staff attending training courses they don’t need
• Staff avoiding training that is provided
• Inappropriately-skilled staff being assigned to tasks, often without
knowledge of the deficiency
• Staff aren’t released to attend training they do need
Why Should You Care? Because…..
• You compromise your competitive edge if staff are not appropriately
skilled for the tasks you’re competing for
• Staff who get frustrated at not getting the training they need may look
elsewhere for a job
• Customer confidence is eroded when they find out that
inappropriately-skilled staff are assigned to their project
• The productivity difference between highly skilled/unskilled staff (at
least in software) is documented at 27:11
1Capers
Jones, Software Quality & Productivity
Copyright 2004, Carnegie Mellon University. All rights reserved.
132