CMMI FOR SMALL BUSINESS PILOT – ASI KICKOFF MEETING

CMMI FOR SMALL BUSINESS PILOT – ASI KICKOFF MEETING
SuZ Garcia, SEI Sandra L. Cepeda, SEI Visiting Scientist/CSSA July, 2003

Topics Introductions Context CMMI Overview Business Issues Analysis
Path Forward

CMMI OVERVIEW

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

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

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

SEI Capability Maturity Model (CMM) Evolution in a Nutshell
Software CMM initially developed by the Software Engineering Institute (circa ) 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 See backup slides for more information on the SEI

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.

Why CMMI : Multiple discipline-specific models have a common core
Example Lines of Business Include: IT Consulting Sys Arch, Engin & Delivery Enterprise Integration Data Center Operation IT Infrastructure Management Applications Management SETA Functional Process Outsourcing SEI CMMI Core SW SW CMM Core SE SE Discipline SECM SW Discipline Core Processes IPPD-CMM Core IPPD IPPD Discipline Other CMM’s

What do we typically do when problems arise?
Ignorance is bliss AIIEEE! Denial 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

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.

CMMI Scope & Coverage Total Product Life Cycle 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

CMMI In A Nutshell Two Representations Per CMMI Model
Staged Process Areas (SE/SW/IPPD/SS) 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) 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) Organizational Process Performance (OPP) Quantitative Project Management (QPM) Organizational Innovation & Deployment (OID) Causal Analysis and Resolution (CAR) Continuous PA Capability Process ML5 ML4 ML3 ML2 ML 1 Organization Process Management OPF, OPD, OT, OPP, OID Maturity Level 5 OID, CAR Maturity Level 4 OPP, QPM Project Management PP, PMC, SAM, ISM, IPM, RSKM, QPM, IT Support CM, PPQA, MA, CAR, DAR, OEI Maturity Level 3 RD, TS, PI, VER, VAL, OPF, OPD, OT, IPM, RSKM, DAR, OEI, IT, ISM Maturity Level 2 REQM, PP, PMC, MA, PPQA, CM, SAM Engineering REQM, RD, TS, PI, VER, VAL Two Representations Per CMMI Model One Appraisal Method (SCAMPI) Copyright 2003, CSSA, Inc. Used with permission.

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

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

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

Business Case for Using CMMI

Notional Business Case for CMMI
Reduced Development/ Maintenance Costs Improved Productivity Less Rework Increased Revenue/Profitability Improved Customer Satisfaction Reduced Post-Release Defects Measurable Improvements of Reliability and Quality Repeat Business Increased Product Sales Reduced Cycle Time Improved Process Performance Enhanced Time-to-Market Performance Bonuses for Early Delivery Improved Professional Staff Improved Employee Morale Increased Developer and Maintainer Confidence Reduced Employee Turnover and Retraining Costs Improved Competitive Advantage Better Products – Not Just Software – Out Sooner And Cheaper Copyright 2003, CSSA, Inc. Used with permission.

Building on the Legacy of SW-CMM Success
Current ROI Value to Programs (DACS, 1999) 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 21:1 Improvements From Adopting SW-CMM (SEI, 1994) -39% 5 10 15 20 25 30 35 40 +35% Savings vs. cost of software process improvement (median) 5:1 Post-Release Defect Reports Productivity -19% Percentage Improvement Time to Market Annual Medians Expect Even Higher ROI For CMMI

The Entire Supply Chain Is or Will Be Involved in CMMI
Improve Integration of Products and Services May Require Organizational Maturity or Process Capability in RFP, Implicitly or Explicitly May Use Organizational Maturity or Process Capability As a Discriminator DoD Customers Associate Contractors Suppliers Will Use Organizational Maturity or Process Capability to Advise Customers Will Use Organizational Maturity or Process Capability to Competitive Advantage 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

CMMI Adoption

Planned CMMI Adoption Life Cycle

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

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

The Bottom Line Without constant vigilance, steady pressure, and active visible support, the will melt down

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

Model Representations
Staged …for a pre-defined set of process areas across an organization Continuous …for a single process area or set of process areas CL5 Maturity Level 5 OID, CAR Optimizing: Focus on Process Improvement 5 CL4 Maturity Level 4 OPP, QPM 4 Quantitatively Managed: Process Measured and Controlled CL3 Maturity Level 3 RD, TS, PI, VER, VAL, OPF, OPD, OT, IPM, RSKM, DAR, OEI, IT, ISM Defined: Process Characterized for the Organization and Is Proactive 3 Process Area Capability CL2 Maturity Level 2 REQM, PP, PMC, MA, PPQA, CM, SAM Managed: Process Characterized for Projects and Is Often Reactive Add Maturity Level 1 on Staged side USE TITLE STYLE THROUGHOUT 2 CL1 (Initial) CL0 (Incomplete) Maturity Level 1 Initial: Process Unpredictable, Poorly Controlled, and Reactive PA PA PA z y x Essentially the Same Content but Organized in a Different Way. Copyright 2003, CSSA, Inc. Used with permission.

CMMI Model Structure Continuous Staged Clean up lines and borders
Maturity Levels (1-5) Process Area 1 Process Area N Process Area 1 Process Area N Process Area 2 Process Area 2 Generic Goals (2-3) Specific Goals Generic Goals (1-5) Specific Goals Common Features Commitment To Perform Ability To Perform Directing Implementation Verification Clean up lines and borders Common Features in one line Capability Levels (0-5) Generic Practices ( ) Specific Practices Generic Practices (1.1, , ) 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

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) Process Areas 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 Innovation & Deployment (OID) Organizational Process Performance (OPP) Organizational Process Focus (OPF) Organizational Process Definition (OPD) Organizational 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) Move REQM (Engineering on Continuous side) to the top of Engineering

CMMI Model Structure Continuous Staged Maturity Levels Process Area 1
(1-5) Process Area 1 Process Area N Process Area 1 Process Area N Process Area 2 Process Area 2 Generic Goals (2-3) Specific Goals Generic Goals (1-5) Specific Goals Common Features Commitment To Perform Ability To Perform Directing Implementation Verification Capability Levels (0-5) Generic Practices ( ) Specific Practices Generic Practices (1.1, , ) 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

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

CMMI Model Structure Continuous Staged
Maturity Levels (1-5) Process Area 1 Process Area N Process Area 1 Process Area N Process Area 2 Process Area 2 Generic Goals (2-3) Specific Goals Generic Goals (1-5) Specific Goals Common Features Commitment To Perform Ability To Perform Directing Implementation Verification Highlight Generic Goals and Generic Practices on Continuous side Capability Levels (0-5) Generic Practices ( ) Specific Practices Generic Practices (1.1, , ) Specific Practices

What Is Institutionalization?
Institutionalization involves implementing practices that Ensure processes can be communicated about (they are defined, documented, understood) Ensure the processes are effective, repeatable and lasting Provide needed infrastructure support Enable organizational learning to improve the process

Why is Institutionalization Important?
Without institutionalization Process improvement may not relate to business goals Processes will not be executed or managed consistently The processes will not survive staff or leadership changes The organization will find itself continuously “reinventing the wheel” Commitment to provide resources or infrastructure to support or improve the processes will be missing or insufficient Historical data will not be useful to support future projects

Realizing Institutionalization In CMMI Models
Continuous representation The basis for institutionalization is established via the Capability Level 2 generic practices This basis is extended in the Capability Level 3, 4 and 5 generic practices Staged representation Institutionalization is the primary focus of the common features The Common Features correspond to the Capability Level 2 and 3 generic 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

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

Generic Goals And Practices
CL 1 CL 2 CL3 CL4 CL5 Level Generic Goals Generic Practices Common Features Mapping GG1: Achieve Specific Goals GP 1.1: Perform Base Practices GG2: Institutionalize a Managed Process Commitment to Perform 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 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 Ability to Perform ML 2 ML 3 ML 4 ML 5 Directing Implementation Verifying Implementation Swap Generic Practices and Generic Goals Headings No colored letters on first chart First Return Should give me CL on the left Second Return Should give me ML on the Left – Remember, ML 2 is the same as CL2 but ML 3 covers both CL 2 and CL 2 Third return should give me Common Features Mapping on the right and colored letters Clean up borders on the RHS GG3: Institutionalize a Defined Process GP 3.1: Establish a Defined Process GP 3.2: Collect Improvement Information GP 3.1: Establish a Defined Process GP 3.2: Collect Improvement Information GG4: Institutionalize a Quantitatively Managed Process GP 4.1: Establish Quantitative Objectives for the Process GP 4.2: Stabilize Subprocess Performance 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.

Improving Maturity Levels (Staged Representation)
ML5 Optimizing 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 Defect Prevention; Proactive Improvement; Innovative Technology Insertion and Deployment ML4 Quantitatively Managed 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 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 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 ML3 Defined Same as previous 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 GP 2.1- GP 2.10 applied to all process areas in ML 2 All SP’s for the ML 2 Process Areas ML2 Managed ML1 Initial Process Is Unpredictable

Improving A Process Area (Continuous Representation)
GP1.1 through GP5.2 CL1+CL2*+CL3* SPs CL5 Optimizing Defect Prevention; Proactive Improvement; Innovative Technology Insertion and Deployment GP1.1 through GP4.2 CL1+CL2*+CL3* SPs CL4 Quantitatively Managed Measure Process Performance; Stabilize Process; Control Charts; Deal With Causes of Special Variations GP1.1 through GP3.2 CL1+CL2*+CL3* SPs CL3 Defined Project’s Process Is Tailored From Organization’s Standard Processes; Understand Process Qualitatively; Process Contributes to the Organization’s Assets GP1.1 through GP2.10 CL1 + CL2* SPs CL2 Managed 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 Use different color for RHS text Clean up title Use regular color and remove shadow from both sides GP1.1 CL1 (base) SPs CL1 Performed Perform the Work No GPs or SPs exist CL0 Incomplete Not Performed, Incomplete * Advanced practices exist only in the Engineering PAs.

Required Components in CMMI
Staged Continuous Maturity Levels (1-5) Process Area 1 Process Area N Process Area 1 Process Area N Process Area 2 Process Area 2 Generic Goals (2-3) Specific Goals Generic Goals (1-5) Specific Goals Common Features Commitment To Perform Ability To Perform Directing Implementation Verification Highlight Generic Goals and Generic Practices on Continuous side Capability Levels (0-5) These model components Are essential to achieving process improvement in a given Process Area Are used in appraisals to determine Process Area Capability Generic Practices ( ) Specific Practices Generic Practices (1.1, , ) Specific Practices

Expected Components in CMMI
Staged Continuous Maturity Levels (1-5) Process Area 1 Process Area N Process Area 1 Process Area N Process Area 2 Process Area 2 Generic Goals (2-3) Specific Goals Generic Goals (1-5) Specific Goals These model components Explain what will typically be done to cover the scope of the process and its goals Are meant to guide model users and help appraisers Allow acceptable alternatives Common Features Commitment To Perform Ability To Perform Directing Implementation Verification Highlight Generic Goals and Generic Practices on Continuous side Capability Levels (0-5) Generic Practices ( ) Specific Practices Generic Practices (1.1, , ) Specific Practices

Informative Model Components
Everything else is informative These model components provide details about the model

PROCESS AREA CONTENTS AND RELATED BUSINESS ISSUES

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 Commitments to the project plan are established and maintained CHANGES FOR ALL PROCESS AREA CHARTS Move key to bottom Bold everything Move Process Area Block down Remove () from key and make font 9 point and icons smaller and make line on last icon thicker Check Process Area Block font in ALL Process Area blocks – some of them (like Supplier Agreement Management) are NOT Tahoma. Make consistent. Remove some of the white shadow behind the Process Area titles. The white shows up too much. Also, make sure that the top of the Process Area title does not go beyond the box border Jana, the bullets in the Work products at the bottom are too close to the text Jana, the Practices that have three lines are very hard to read. Please add space between the lines. Jana, in general these charts are hard to read. (I just tested them on the laptop projector). Anything you can do, in addition to what we discussed this morning, to make them more readable would be great. Even if the size of the icons has to change to accommodate larger text, that would be OK. You may want to do one chart, call me on my cell phone and it to me so that I can review it before you apply the changes to the other charts.

Project Planning Establish Estimates Develop a Project Plan Obtain Commitment To the Plan Estimate the Scope of The Project Task Descriptions • Work Package Descriptions • WBS CHANGES FOR ALL PROCESS AREA CHARTS Move key to bottom Bold everything Move Process Area Block down Remove () from key and make font 9 point and icons smaller and make line on last icon thicker Check Process Area Block font in ALL Process Area blocks – some of them (like Supplier Agreement Management) are NOT Tahoma. Make consistent. Remove some of the white shadow behind the Process Area titles. The white shows up too much. Also, make sure that the top of the Process Area title does not go beyond the box border Jana, the bullets in the Work products at the bottom are too close to the text Jana, the Practices that have three lines are very hard to read. Please add space between the lines. Jana, in general these charts are hard to read. (I just tested them on the laptop projector). Anything you can do, in addition to what we discussed this morning, to make them more readable would be great. Even if the size of the icons has to change to accommodate larger text, that would be OK. You may want to do one chart, call me on my cell phone and it to me so that I can review it before you apply the changes to the other charts. Establish Estimates of Work Product & Task Attributes Technical Approach • Size and Complexity of Tasks and Work Products • Estimating Models Define Project Life Cycle Project Life-Cycle Phases Goals Practices Typical Work Products Determine Estimates of Effort & Cost Estimation Rationale • Project Effort Estimates • Project Cost Estimates

Project Planning Establish Estimates Develop a Project Plan Obtain Commitment To the Plan Establish the Budget & Schedule Project Schedules • Schedule Dependencies • Project Budget Identify Project Risks Identified Risks • Risk Impacts and Probability of Occurrence • Risk Priorities Data Management Plan • Master List of Managed Data • Data Content and Format Description Plan for Data Management CHANGES FOR ALL PROCESS AREA CHARTS Move key to bottom Bold everything Move Process Area Block down Remove () from key and make font 9 point and icons smaller and make line on last icon thicker Check Process Area Block font in ALL Process Area blocks – some of them (like Supplier Agreement Management) are NOT Tahoma. Make consistent. Remove some of the white shadow behind the Process Area titles. The white shows up too much. Also, make sure that the top of the Process Area title does not go beyond the box border Jana, the bullets in the Work products at the bottom are too close to the text Jana, the Practices that have three lines are very hard to read. Please add space between the lines. Jana, in general these charts are hard to read. (I just tested them on the laptop projector). Anything you can do, in addition to what we discussed this morning, to make them more readable would be great. Even if the size of the icons has to change to accommodate larger text, that would be OK. You may want to do one chart, call me on my cell phone and it to me so that I can review it before you apply the changes to the other charts. 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) Goals Practices Typical Work Products Plan Stakeholder Involvement Stakeholder Involvement Plan Establish the Project Plan Overall Project Plan

Project Planning Establish Estimates Develop a Project Plan Obtain Commitment To the Plan Review Plans That Affect The Project Record of the Reviews of Plans that Affect the Project CHANGES FOR ALL PROCESS AREA CHARTS Move key to bottom Bold everything Move Process Area Block down Remove () from key and make font 9 point and icons smaller and make line on last icon thicker Check Process Area Block font in ALL Process Area blocks – some of them (like Supplier Agreement Management) are NOT Tahoma. Make consistent. Remove some of the white shadow behind the Process Area titles. The white shows up too much. Also, make sure that the top of the Process Area title does not go beyond the box border Jana, the bullets in the Work products at the bottom are too close to the text Jana, the Practices that have three lines are very hard to read. Please add space between the lines. Jana, in general these charts are hard to read. (I just tested them on the laptop projector). Anything you can do, in addition to what we discussed this morning, to make them more readable would be great. Even if the size of the icons has to change to accommodate larger text, that would be OK. You may want to do one chart, call me on my cell phone and it to me so that I can review it before you apply the changes to the other charts. Revised Methods and Corresponding Estimating Parameters • Renegotiated Budgets • Revised Schedules Reconcile Work and Resource Levels Goals Practices Typical Work Products Obtain Plan Commitment Documented Requests for Commitments • Documented Commitments

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!

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 Corrective Actions are Managed to Closure When the Project’s Performance or Results Deviate Significantly From the Plan Same here: The purpose of Project Monitoring and Control is to 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.

Project Management (ML 2): PMC (2 of 3)
Project Monitoring & Control Monitor Project Against Plan Manage Corrective Action to Closure Monitor Project Planning Parameters Records of Project Performance • Records of Significant Deviations Monitor Commitments Records of Commitment Reviews Monitor Project Risks Records of Project Risk Monitoring Same here: The purpose of Project Monitoring and Control is to 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. Monitor Data Management Records of Data Management Monitor Stakeholder Involvement Records of Stakeholder Involvement Goals Practices Typical Work Products Conduct Progress Reviews Documented Project Review Results Conduct Milestone Reviews Documented Milestone Review Results

Project Management (ML 2): PMC (3 of 3)
Project Monitoring & Control Monitor Project Against Plan Manage Corrective Action to Closure Same here: The purpose of Project Monitoring and Control is to 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. Analyze Issues List of Issues Needing Corrective Actions Take Corrective Action Corrective Action Plan Goals Practices Typical Work Products Manage Corrective Action Corrective Action Results

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!

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 Agreements With the Suppliers are Satisfied by Both the Project and the Supplier

Establish Supplier Agreements Satisfy Supplier Agreements Determine Acquisition Type List of the Acquisition Types That Will be Used for All Products and Product Components to be Acquired Select Suppliers List of Candidate Suppliers • Preferred Supplier List • Rationale for Selection of Suppliers Statements of Work • Contracts • Memoranda of Agreement Establish Supplier Agreements Goals Practices Typical Work Products

Establish Supplier Agreements Satisfy Supplier Agreements Trade Studies • Price Lists • Evaluation Criteria Review COTS Products Supplier Progress Reports and Performance Measures • Supplier Review Materials and Reports • Action items tracked to Closure Execute the Supplier Agreement Accept the Acquired Product Acceptance Test Procedures • Acceptance Test Results • Discrepancy Reports or Corrective Action Plans Goals Practices Typical Work Products Transition Products Transition Plans • Training Reports • Support and Maintenance Reports

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

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 Coordination and Collaboration of the Project With Relevant Stakeholders is Conducted This one too: The purpose of Integrated Project Management is to 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.

Organization’s Measurement Organization’s Process Asset Library
Interaction Between OPD and IPM Life-Cycle Model Descriptions Organization’s Measurement Repository Organization’s Set of Standard Processes Process Architectures Organization’s Process Asset Library Organizational Assets Tailoring Guidelines OPD IPM Project Environment Project A’s Defined Process Project B’s Defined Process Project C’s Defined Process Exercise Using the diagram entitled “Synergistic Relationships” as a template, diagram the synergism between the following PA’s: CAR, OID, OPD Reviews Reviews Project A’s Project Plan Project B’s Project Plan Project C’s Project Plan

Use the Project’s Defined Process Coordinate and Collaborate With Relevant Stakeholders Establish the Project’s Defined Process The Project’s Defined Process Use Organizational Process Assets for Planning Project Activities Project Estimates • Project Plans This one too: The purpose of Integrated Project Management is to 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. Integrate Plans 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 Goals Practices Typical Work Products Manage the Project Using the Integrated Plans 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)

Use the Project’s Defined Process Coordinate and Collaborate With Relevant Stakeholders 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 Manage Stakeholder Involvement This one too: The purpose of Integrated Project Management is to 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. Manage Dependencies Defects, Issues, and Action Items Resulting From Reviews With Relevant Stakeholders • Critical Dependencies • Commitments to Address Critical Dependencies Goals Practices Typical Work Products Resolve Coordination Issues Relevant Stakeholder Coordination Issues • Status of Relevant Stakeholder Coordination Issues

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

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 Risks are Handled and Mitigated, Where Appropriate, to Reduce Adverse Impacts on Achieving Objectives This one too: The purpose of Risk Management is to 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.

Risk Management Prepare for Risk Management Identify and Analyze Risks Mitigate Risks Determine Risk Sources and Categories Risk Source Lists (external and internal) • Risk Categories List This one too: The purpose of Risk Management is to 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. Define Risk Parameters Risk Evaluation, Categorization, and Prioritization Criteria • Risk Management Requirements (control and approval levels, reassessment intervals, etc.) Establish a Risk Management Strategy Project Risk Management Strategy Goals Practices Typical Work Products

Risk Management Prepare for Risk Management Identify and Analyze Risks Mitigate Risks Identify Risks List of Identified Risks, Including the Context, Conditions, and Consequences of Risk Occurrence This one too: The purpose of Risk Management is to 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. Evaluate, Categorize, and Prioritize Risks List of Risks, With a Priority Assigned to Each Risk Goals Practices Typical Work Products

Risk Management Prepare for Risk Management Identify and Analyze Risks Mitigate Risks Develop Risk Mitigation Plans Documented Handling Options for Each Identified Risk • Risk Mitigation Plans This one too: The purpose of Risk Management is to 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. Implement 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

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

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 Work is Coordinated With Suppliers to Ensure the Supplier Agreement is Executed Appropriately This one too: The purpose of Integrated Supplier Management is to proactively identify sources of products that may be used to satisfy the project’s requirements and to manage selected suppliers while maintaining a cooperative project-supplier relationship.

Analyze and Select Sources of Products Coordinate Work With Suppliers List of Potential Sources of Products That Might be Acquired • Market Studies • Trade Studies Analyze Potential Sources of Products This one too: The purpose of Integrated Supplier Management is to proactively identify sources of products that may be used to satisfy the project’s requirements and to manage selected suppliers while maintaining a cooperative project-supplier relationship. Evaluate and Determine Sources of Products Analysis and Evaluation Reports • Revised List of Product Sources Goals Practices Typical Work Products

Analyze and Select Sources of Products Coordinate Work With Suppliers Monitor Selected Supplier Processes List of Processes Selected for Monitoring • Activity Reports • Performance Reports This one too: The purpose of Integrated Supplier Management is to proactively identify sources of products that may be used to satisfy the project’s requirements and to manage selected suppliers while maintaining a cooperative project-supplier relationship. 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 Goals Practices Typical Work Products

Configuration Management
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 Integrity of Baselines is Established and Maintained Added text to the Process Area Block. Please make the block bigger.

Support (ML 2): CM (2 of 4) Configuration Management Establish Baselines Track and Control Changes Establish Integrity Identify Configuration Items Identified Configuration Items Added text to the Process Area Block. Please make the block bigger. Establish a Configuration Management System Configuration Management System With Controlled Work Products • Configuration Management System Access Control Procedures • Change Request Database Create or Release Baselines Baselines • Description of Baselines Goals Practices Typical Work Products

Support (ML 2): CM (3 of 4) Configuration Management Establish Baselines Track and Control Changes Establish Integrity Track Change Requests Change Requests Added text to the Process Area Block. Please make the block bigger. Control Configuration Items Revision History of Configuration Items • Archives of the Baselines Goals Practices Typical Work Products

Support (ML 2): (4 of 4) Configuration Management Establish Baselines Track and Control Changes Establish Integrity Revision History of Configuration Items • Change Log • Copy of the Change Requests Establish Configuration Management Records Added text to the Process Area Block. Please make the block bigger. Perform Configuration Audits Configuration Audit Results • Action Items Goals Practices Typical Work Products

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!

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 Noncompliance Issues are Objectively Tracked and Communicated, and resolution is ensured

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

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 Corrective Action Reports • Evaluation Reports • Quality Trends Establish Records Evaluation Logs • Quality Assurance Reports • Status Reports of Corrective Actions Goals Practices Typical Work Products

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

Measurement & Analysis
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 Measurement Results That Address Identified Information Needs and Objectives are Provided

Support (ML 2): MA (2 of 3) Measurement & Analysis Align Measurement and Analysis Activities Provide Measurement Results Establish Measurement Objectives Measurement Objectives Specify Measures Specifications of Base and Derived Measures Specify Data Collection and Storage Procedures Data Collection and Storage Procedures • Data Collection Tools Goals Practices Typical Work Products Specify Analysis Procedures Analysis Specification and Procedures • Data Analysis Tools

Support (ML 2): MA (3 of 3) Measurement & Analysis Align Measurement and Analysis Activities Provide Measurement Results Collect Measurement Data Base and Derived Measurement Data Sets • Results of Data Integrity Tests Analyze Measurement Data Analysis Results and Draft Reports Store Data and Results Stored Data Inventory Goals Practices Typical Work Products Communicate Results Delivered Reports and Related Analysis Results • Contextual Information or Guidance to Aid in the Interpretation of Analysis Results

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

Decision Analysis & Resolution
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

Decision Analysis & Resolution
Support (ML 3): DAR (2 of 2) Decision Analysis & Resolution Evaluate Alternatives Establish Guidelines for Decision Analysis Guidelines for When to Apply a Formal Evaluation Process Establish Evaluation Criteria Documented Evaluation Criteria • Rankings of Criteria Importance Identify Alternative Solutions Identified Alternatives Select Evaluation Methods Selected Evaluation Methods Goals Practices Typical Work Products Evaluate Alternatives Evaluation Results Select Solutions Recommended Solutions to Address Significant Issues

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

The Engineering Process Areas
REQM Requirements Product and product component requirements Alternative solutions RD TS Product components PI Product Customer Require- ments Product components, work products, verification and validation reports Ver Val Customer needs

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 1. Need the full purpose as follows: 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.

Engineering (ML 2): REQM (2 of 2)
Requirements Management Manage Requirements List of Criteria for Distinguishing Appropriate Requirements Providers • Criteria for Evaluation and Acceptance of Requirements • Results of Analysis Against Criteria Obtain an Understanding of Requirements Obtain Commitment to Requirements Requirements Impact Assessments • Documented Commitments to Requirements and Requirements Changes 1. Need the full purpose as follows: 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. Manage Requirements Changes Requirements Status • Requirements Database • Requirements Decision Database Goals Practices Typical Work Products Maintain Bidirectional Traceability of Requirements Requirements Traceability Matrix • Requirements Tracking System Identify Inconsistencies Between Project Work and Requirements Documentation of Inconsistencies Including Sources, Conditions, and Rationale • Corrective Actions

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

Engineering (ML 3): RD (1 of 4) Requirements Development
Purpose: Produce and Analyze Customer, Product, and Product-component Requirements. Shareholder Needs, Expectations, Constraints, and Interfaces are Collected and Translated Into Customer Requirements Customer Requirements are Refined and Elaborated to Develop Product and Product-Component Requirements The Requirements are Analyzed and Validated, and a Definition of Required Functionality is Developed

Develop Customer Requirements Develop Product Requirements Analyze and Validate Requirements Collect Stakeholder Needs Elicit Needs Goals Practices Typical Work Products Continuous Representation Only Develop the Customer Requirements Customer Requirements • Customer Constraints on the Conduct of Verification • Customer Constraints on the Conduct of Validation

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 Identify Interface Requirements Goals Practices Typical Work Products Interface Requirements

Develop Customer Requirements Develop Product Requirements Analyze and Validate Requirements Operational Concept • Product Installation, Operational, Maintenance, and Support Concepts • Disposal Concepts Establish Operational Concepts and Scenarios Establish a Definition of Required Functionality Functional Architecture • Activity Diagrams and Use Cases • Object-Oriented Analysis With Services Identified Analyze Requirements Requirements Defects Reports • Proposed Requirements Changes to Resolve Defects • Key Requirements Goals Practices Typical Work Products Continuous Representation Only Analyze Requirements to Achieve Balance Assessment of Risks Related to Requirements Validate Requirements Results of Requirements Validation Validate Requirements With Comprehensive Methods Record of Analysis Methods and Results

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

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 Product Components, and Associated Support Documentation, are Implemented From Their Designs Need to update purpose as follows: design, develop, and implement solutions to requirements. Solutions, designs, and implementations encompass products, product components, and product-related lifecycle processes

Technical Solution Select Product-Component Solutions Develop the Design Implement the Product Design Develop Alternative Solutions and Selection Criteria Alternative Solutions • Selection Criteria Develop Detailed Alternative Solutions and Selection Criteria Alternative Solution Screening Criteria • Evaluations of New Technologies • Alternative Solutions Need to update purpose as follows: design, develop, and implement solutions to requirements. Solutions, designs, and implementations encompass products, product components, and product-related lifecycle processes Evolve Operational Concepts and Scenarios Product-Component Operational Concepts, Scenarios, and Environments for All Product-Related Life-Cycle Processes • Timeline Analyses of Product-Component Interactions • Use Cases Select Product-component Solutions 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

Technical Solution Select Product-Component Solutions Develop the Design Implement the Product Design Design the Product or Product Component Product Architecture • Product-Component Designs Establish a Technical Data Package Technical Data Package Need to update purpose as follows: design, develop, and implement solutions to requirements. Solutions, designs, and implementations encompass products, product components, and product-related lifecycle processes Establish Interface Descriptions Interface Design • Interface Design Documents Goals Practices Typical Work Products Continuous Representation Only Design Interfaces Using Criteria Interface Design Specifications • Interface Control Documents • Interface Specification Criteria Perform Make, Buy, or Reuse Analyses Criteria for Design and Product-Component Reuse • Make-or-Buy Analyses • Guidelines for Choosing COTS Product Components

Technical Solution Select Product-Component Solutions Develop the Design Implement the Product Design Implement the Design Implemented Design Need to update purpose as follows: design, develop, and implement solutions to requirements. Solutions, designs, and implementations encompass products, product components, and product-related lifecycle processes Develop Product Support Documentation End-User Training Materials • User’s Manual • Operator’s Manual Goals Practices Typical Work Products

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

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 Verified Product components are Assembled and the Integrated, Verified, and Validated Product is Delivered Second practice of last goal, “Assemble” is to close to the border of the box. Please bulletize last typical work product I added

Product Integration Prepare for Product Integration Ensure Interface Compatibility Assemble Product Components and Deliver the Product Determine Integration Sequence Product Integration Sequence • Rationale for Selecting or Rejecting Integration Sequences Second practice of last goal, “Assemble” is to close to the border of the box. Please bulletize last typical work product I added Establish the Product Integration Environment Verified Environment for Product Integration • Support Documentation for the Product Integration Environment Establish Product Integration Procedures and Criteria Product Integration Procedures • Product Integration Criteria Goals Practices Typical Work Products

Product Integration Prepare for Product Integration Ensure Interface Compatibility Assemble Product Components and Deliver the Product Categories of Interfaces • List of Interfaces Per Category • Mapping of the Interfaces to the Product Components and Product Integration Environment Review Interface Descriptions for Completeness Second practice of last goal, “Assemble” is to close to the border of the box. Please bulletize last typical work product I added 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 Manage Interfaces Goals Practices Typical Work Products

Product Integration Prepare for Product Integration Ensure Interface Compatibility Assemble Product Components and Deliver the Product Confirm Readiness of Product Components for Integration Acceptance Documents for the Received Product Components • Delivery Receipts • Checked Packing Lists Second practice of last goal, “Assemble” is to close to the border of the box. Please bulletize last typical work product I added Assemble Product Components Assembled Product or Product Components Goals Practices Typical Work Products Evaluate Assembled Product Components Exception Reports • Interface Evaluation Reports • Product Integration Summary Reports Package and Deliver the Product or Product Component Packaged Product or Product Components • Delivery Documentation

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

Verification Versus Validation
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?

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 Selected Work Products are Verified Against Their Specified Requirements

Verification Prepare for Verification Perform Peer Reviews Verify Selected Work Products 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 Goals Practices Typical Work Products

Verification Prepare for Verification Perform Peer Reviews Verify Selected Work Products Prepare for Peer Reviews Peer Review Schedule • Peer Review Checklist • Entry and Exit Criteria for Work Products Conduct Peer Reviews Peer Review Results • Peer Review Issues • Peer Review Data Goals Practices Typical Work Products Analyze Peer Review Data Peer Review Data • Peer Review Action Items

Verification Prepare for Verification Perform Peer Reviews Verify Selected Work Products Perform Verification 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 Goals Practices Typical Work Products Analyze Verification Results and Identify Corrective Action

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

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 The Product or Product Components are Validated to Ensure That They are Suitable for Use in Their Intended Operating Environment

Validation Prepare for Validation Validate Product or Product Components Select Products for Validation 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

Validation Prepare for Validation Validate Product or Product Components Perform Validation Validation Reports • Validation Results • Validation Cross-Reference Matrix Analyze Validation Results Validation Deficiency Reports • Validation Issues • Procedure Change Request Goals Practices Typical Work Products

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

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 Improvements are Planned and Implemented, Organizational Process Assets are Deployed, and Process-Related Experiences are Incorporated Into the Organizational Process Assets Jana, the last practice box (RHS) is very hard to read. Need to leave more space between the lines

Organizational Process Focus
Determine Process Improvement Opportunities Establish Organizational Process Needs Appraise the Organization’s Processes Identify the Organization’s Process Improvements Establish Process Action Plans Plan and implement process improvement Implement Process Action Plans “OPD” Organization’s Process Assets Deploy Organizational Process Assets

Process Management (ML 3): OPF (2 of 3)
Organizational Process Focus Determine Process Improvement Opportunities Plan and Implement Process Improvement Activities Establish Organizational Process Needs Organization’s Process Needs and Objectives Jana, the last practice box (RHS) is very hard to read. Need to leave more space between the lines Appraise the Organization’s Processes 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 Goals Practices Typical Work Products Identify the Organization's Process Improvements Analysis of Candidate Process Improvements • Identification of Improvements for the Organization’s Processes

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 Organization’s Approved Process Action Plans Jana, the last practice box (RHS) is very hard to read. Need to leave more space between the lines Implement 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 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 Deploy Organizational Process Assets Incorporate Process-related Experiences Into the Organizational Process Assets Process Improvement Proposals • Process Lessons Learned • Measurements on the Organizational Process Assets

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

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

Process Management (ML 3): OPD (2 of 2)
Organizational Process Definition Establish Organizational Process Assets Establish Standard Processes 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 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) Goals Practices Typical Work Products Establish the Organization’s Measurement Repository 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 Establish the Organization’s Process Asset Library

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

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 Training Necessary for Individuals to Perform Their Roles Effectively is Provided

Establish an Organizational Training Capability Provide Necessary Training Establish the Strategic Training Needs Training Needs • Assessment Analysis Determine Which Training Needs Are the Responsibility of the Organization Common Project and Support Group Training Needs • Training Commitments Goals Practices Typical Work Products Establish an Organizational Training Tactical Plan Organizational Training Tactical Plan Establish Training Capability Training Materials and Supporting Artifacts

Establish an Organizational Training Capability Provide Necessary Training Deliver Training Delivered Training Course Establish Training Records Training Records • Training Updates to the Organizational Repository Goals Practices Typical Work Products Assess Training Effectiveness Training-Effectiveness Surveys • Training Program Performance Assessments • Instructor Evaluation Forms

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

CMMI FOR SMALL BUSINESS PILOT – ASI KICKOFF MEETING

Similar presentations

Presentation on theme: "CMMI FOR SMALL BUSINESS PILOT – ASI KICKOFF MEETING"— Presentation transcript:

Similar presentations

About project

Feedback

Log in

Auth with social network:

CMMI FOR SMALL BUSINESS PILOT – ASI KICKOFF MEETING

Similar presentations

Presentation on theme: "CMMI FOR SMALL BUSINESS PILOT – ASI KICKOFF MEETING"— Presentation transcript:

Similar presentations

About project

Feedback