use of cmmi in acquisition environments

7/30/2019 Use of Cmmi in Acquisition Environments

1/204

Pittsburgh, PA 15213-3890

Tutorial: Use of CMMI in Acquisition Environments - Page 1

Sponsored by the U.S. Department of Defense 2005 by Carnegie Mellon UniversityThis material is approved for public release.

Use of CMMI in Acquisition

Environments

Brian Gallagher

Lorraine Adams

SEPG

March 6, 2006

SM CMM Integration, IDEAL, and SCAMPI are service marks of Carnegie Mellon University. Capability Maturity Model, Capability Maturity Modeling, CMM, and CMMI are registered in the U.S. Patent and Trademark Office

by Carnegie Mellon University.


2/204

2005 by Carnegie Mellon University Tutorial: Use of CMMI in Acquisition Environments - Page 2

Tutorial AgendaIntroduction

Part 1: Using CMMI to Encourage Good Contractor

Practices

Part 2: Using CMMI-AM to Improve AcquisitionPractices


3/204


IntroductionLack of acquisition guidance is a major concern for projects involved in theacquisition and sustainmentof systems, including software-intensive systems.Over the past decade, much of the headquarters and field-level acquisition

guidance for systems and software acquisition and sustainmenthas beenrescinded, simplified, or reduced in scope such that only minimal acquisition-related guidance remains in many acquisition areas.

This reduction of guidance has occurred as system complexity and the

software contribution to overall system functionality rises to unprecedentedlevels.

Congressional- and DOD-level guidance continues to emphasize softwareacquisition process improvement, including the measurement of process

performance by acquisition organizations

The goal of this tutorial is to define effective and efficient acquisition practices,both directed internally toward the acquisition project and directed externallytoward the monitoring and control of the selected supplier(s). These practices

are intended to provide a basis for acquisition process discipline whilebalancing the need for agility.


4/204 2005 by Carnegie Mellon University Tutorial: Use of CMMI in Acquisition Environments - Page 4

Tutorial AgendaIntroduction

Part 1: Using CMMI to Encourage Good Contractor

Practices

Part 2: Using CMMI-AM to Improve AcquisitionPractices



Problem StatementMany DoD contractors claim high Maturity Levels (3 andabove) as measured by the Capability Maturity ModelIntegration, yet from the perspective of acquisition programmanagers on some high visibility individual programs, forvarious reasons, individual teams are not executing to the

level claimed in proposals.



Example Program

BackgroundLarge DoD program with multiple, geographically dispersedengineering locations.

Multi-contractor teams (10+) using different processes.

Several million lines of code.

Systems engineering challenges.Combination of legacy, re-use, COTS integration and newdevelopment.

All contractor sites are Maturity Level 3 or higher.18 months after contract award, the program office conducted aCMMI Class Bappraisal on the team.



Example Program

Appraisal Output

0

5

10

15

20

25

30

Project Mgmt Engineering

Processes

Process

Mgmt

Support

Processes

Number of Strengths Number of Weaknesses

Project Mgmt Processes

- Project Planning

- Project Monitoring & Control

- Integrated Project Mgmt

- Risk Management

Engineering Processes

- Requirements Mgmt

- Requirements Definition

- Technical Solution

- Product Integration

- Verification (Peer Reviews)

Support Processes- Measurement & Analysis

- Product and Process Quality

Assurance

- Configuration Mgmt

- Decision Analysis

Process Mgmt

- Organizational Process Focus

- Organizational Process Definition



Example Program

Issues Identified 1PROJECT MANAGEMENT

Lack of project plans or having onlyincomplete, conflicting or out of dateproject plans

Ineffective use of Integrated MasterSchedule as basis forplanning/tracking status acrossprogram

Undefined engineering andmanagement processes on program

Inability to track and manage actionsto closure

Inadequate cost estimation processes,

methods, data and tools Inadequate staffing and trainingproject personnel

Tracking dependencies between oracross teams not defined

Managing project data ad hoc Inability to proactively identify andmanage risks

ENGINEERING

Lack of understanding of theprograms requirements

Inability to trace requirements toarchitecture/design or to testplans/procedures

Poor linkage of functional andperformance requirements

Inconsistent requirementsmanagement at different levels

No criteria for makingarchitectural/design decisions amongalternatives

Not capturing entire technical datapackage (requirements, design anddesign rationale, test results, etc)

Efficiency of design process/methodsin question

Late definition of integration and testprocedures



Example Program

Issues Identified 2SUPPORT

Difficult to identify items in configuration management baselines

Lack of ability to manage individual versionsin incremental development

Inability to effectively managing changes to work products throughout lifecycle

Not conducting audits to establish/ensure integrity of baselines throughout

incremental engineering and developmentInefficient change management process (cycle time, volume of changes)

Roles/responsibilities of change control boards not defined

Quality Assurance audits of products and processes not consistent

QA involvement in system and software engineering processes not consistent

No metrics to manage engineering activities (outside of cost/schedule data)



Example Program

ResultsEarly and periodic Class B appraisals using CMMI identified risksto program success

Identified risks were assigned to contractor, to acquirer, or bothbased upon who was best able to mitigate them.

Many risks were managed jointly and cooperatively between the

contractor and the acquirer

Identification of and attention to risks early in the program lifecycle led to the ultimate success of the program.


11/204


High Maturity High MaturityOrganizations Projects

WHY?

Maturity Levels are goodindicators of organizationalpotential performance.

They describe how the nextproject will most likely performbased on a sampling ofexisting projects.

Maturity Levels reside at theorganizational level and arenotan indication of how an

individual project is performing.

XYZ Corp.

Division

A

Project1

Project2

Project3

Division

B

Division

N

?

Project5

Project6

Project7

Projectx

Projecty

Projectz

Project4

MLs usuallyapply HEREbased upon

appraisals ofTHESE

but yourproject isHERE or HERE


12/204


The Acquirers ConcernMY PROGRAM

ML = ???

Contractor AML = 5 Contractor BML = 3

Contractor CML = 4

PMOML = 2

During

source

selection:

How capable is acontractor team to

deliver anoperationalcapability?

Ongoing: How well is myprogram

performing?

Maturity Levels at the organizational level arenecessary but not sufficient to provide answers to

these questions at the program level.


13/204


Key QuestionsIs the appraisal of the contractors organizational

maturity relevant to my project?

Did the part of the organization executing my projectparticipate in the appraisal?

Did projects similar to mine participate in the appraisal?

Are the appraised processes routinely used by the partof the organization executing my project?

Are the appraised processes an integral part of the

project execution, or are they an overlay on the the realway the work gets done?

The BIG question: What processes will really

be used on MY project


14/204


Excerpt from Defense AcquisitionGuidebook Source Selection

4.2.5.2 Capability Reviews

Capability reviews are a useful tool

available during source selections to assessthe offerors' capability in selected criticalprocess areas. Capability reviews may be the

appropriate means for evaluating program-specific critical processes such as systemsengineering, software development,

configuration management, etc.


15/204


Getting the processes that you need1. Identify the characteristics of the processes that you need on

your project.

2. Include process evaluation as one of the source selectioncriteria.

3. Require the bidders to define in the proposal, the processes

and the process outputs that they intend to use on the project.4. During source selection, evaluate the bidders processes w.r.t.

the projects process needs using the SCAMPI method.

5. For the winning bidder, reference the proposed processes inthe contract.

6. During contract execution, evaluate the contractorcompliance with the proposed processes.


16/204


Step 1: Identify Process Needs 1

Self-assessment of project needs by the PMO

Based upon Guidelines for using CMMI in AcquisitionPrograms(draft)

CMMI Risk Worksheet Results

NotImportant Important Essential

1 2 3 4 5 6 7 8 9 10

Project Planning

1.Establish Estimates o o o o o o o o o

2.Develop a Project Plan o o o o o o o o o3.Obtain Commitment to the

Plan

o o o o o o o o o

Project Monitoring and Control

4.Monitor Project AgainstPlan o o o o


17/204


Step 1: Identify Process Needs 2

Example

Program is looking to select a Lead System Integrator for acomplex, multi-year, development effort

Program is concerned with the potential LSIs ability to:

- manage risk

- manage suppliers- plan and track the program

- build an integrated team

- develop an architecture

- integrate the various components

The program might want to explore the bidders proposedprocesses in these CMMI process areas: PP, PMC, IPM (with

IPPD), ISM, RD, IT, RSKM, PI


18/204


Step 2: Source Selection CriteriaDont just require organizational Maturity Levels

Include an evaluation of contractor-proposedprocesses as one of the factors for source selection.


19/204


Step 3: Require process proposals 1

RFP requires all bidders to propose the processes thatthey wil l use on this project.

Process proposals include

a description of the process

a list of the outputs / artifacts produced by the process.


20/204


Step 3: Require process proposals 2

RFP Language

L.X.X.X Product Development Capabilities

In support of the Management Factor evaluation, the Governmentintends to conduct an evaluation of the product development andmanagement capabilities of the offeror teamproposed for application on

this project. The evaluation will involve methods and procedures tailoredfrom the Software Engineering Institute (SEI) Standard CMMISM

Appraisal Method for Process Improvement (SCAMPISM) Class X*

Version 1.1 using Capability Maturity Model Integration (CMMISM) forSystems Engineering, Software Engineering, and Integrated Product and

Process Development (CMMI-SE/SW/IPPD), Version 1.1. The offerorshall provide the SCAMPI documentation described in Attachment A ofthis RFP to support this evaluation. This documentation shall be providedin the proposal and will not be included in the page count limitations forthe proposal.

*B or C depending on program needs


21/204


Step 4: Evaluate process proposals 1

Appraise the proposed processes using a SCAMPI-Cmethod.

SCAMPI-C is suitable for process appraisal based ondocument review.

Use an authorized Lead Appraiser with acquisitionexperience

Ensure the appraisal team is trained and experienced

Perform a gap analysis against the self-assessment ofproject needs established in Step 1.

Gaps represent process-related risks to the project.


22/204


Step 4: Evaluate process proposals 2

If the program is of sufficient size, duration, or

complexity, consider performing SCAMPI-Bs on thebidding teams .

Use the continuous representation, select 3 to 7

process areas based on program risk.Use an authorized Lead Appraiser with acquisitionexperience.

Ensure the team is trained and experienced.


23/204


Step 5: Contract proposed processesReference the proposed processes in the awarded

contract.

Dont tell the contractor what processes to use.

- That could shift performance liability to the PMO if theprocesses are found to be unsuitable for the project.

J ust tell the contractor to perform as proposed.


24/204


Step 6: Evaluate process compliance 1Excerpt from Defense Acquisition

Guidebook Contract Monitoring

4.2.5.3 Capability Appraisals

the program manager retains theright to independently evaluate theprocess capabil ities of the selected

team prior to or immediately aftercontract award. Periodicappraisals are encouraged as part of

contract process monitoring

activities. assessments are mostvaluable when they apply across thefull program team, and not just one

segment of the

organization

Monitor the production ofprocess-related artifacts

Perform one or moreSCAMPI-B appraisals onkey process areas toassess compliance to

proposed processes

Appraisal focus is oncontract monitoring, not

process improvement


25/204


Step 6: Evaluate process compliance 2

Contract Monitoring Guidelines

Dont appraise Maturity Levels

Use the SCAMPI-B method

Include the entire program team (prime, subs, and theacquisition program office)

Use the continuous representation, select process areasbased on program risk (selection may evolve during programlife).

Use an authorized Lead Appraiser

Ensure the team is trained and experienced

Include contractor members on the appraisal team

Use the results as the basis for collaborative risk mitigation

and process improvement across program team


26/204


Benefits of Using the SCAMPI Familyof Appraisal MethodsSCAMPI Class B and Class C appraisals are consistent with the

SCAMPI Class A Method (same steps, use of PIIs, etc.) and: are led by an authorized team lead require team training focus on areas of risk to the program without an artificial focus

on achieving Levels are repeatable follow a publicly vetted, documented, and easily accessible

method

In the absence of a repeatable method with clear expectations onthe part of the acquirer and contractor communities, homegrownmethods will emerge.


27/204


SummaryMaturity Levels alone do not provide the information anacquirer needs to determine:

How capable is a contractor team to deliver anoperational capability?

How well is my program performing?

Acquirers need a simple, actionable set of guidelines onhow to use the CMMI framework (models and appraisalmethods) to help reduce program risk.


28/204



Sponsored by the U.S. Department of Defense

2005 by Carnegie Mellon UniversityThis material is approved for public release.

Use of CMMI in Acquisition Environments

Part 2: Using CMMI-AM to Improve

Acquisition Practices

Brian Gallagher

Lorraine Adams

SEPG

March 6, 2006




29/204


Using CMMI-AM to Improve Acquisition

Practices- Contents

Module 1 Background

Tutorial information and background

Module 2 CMMI-AM and Project ManagementProject Management process areas, goals, andpractices

Module 3 CMMI-AM and EngineeringEngineering process areas, goals, and practices

Module 4 CMMI-AM and Support and Generic Practices

Support process areas, goals, and practices; andGeneric Practices

Module 5 Using CMMI-AM

Module 6 Summary and Conclusion


30/204





Using CMMI-AM to ImproveAcquisition Practices

Module 1:Background




31/204


Module 1 AgendaThe State of Acquisition Practices

Capability Maturity Model Integration


32/204


What is Acquisition

Question: What are the key

activit ies that youperform when youacquire systems?

Operational

Need


33/204


The State of Acquisition Practice 1The agencies assume the partnership arrangementabsolves them of all acquisition management

responsibilities

Virtually all (Air Force) software-intensive systems sufferfrom difficulties achieving cost, schedule, and

performance objectives.

I'd rather have it wrong than have it late. A senior manager (industry)

The bottom line is schedule. My promotions and raisesare based on meeting schedule first and foremost. A programmanager (government)

Lack of robust systems engineering practices identified

as crit ical factor in SBIRS-High problems. Lt. Gen. Brian A. Arnold,USAF, CDR, USAF/SMC


34/204


The State of Acquisition Practice 2Is There an Acquisition Crisis?

Investigation of one acquisit ion program showed:

System complexity and the programs lack of experience inprocuring major systems caused serious cost growth.

Program lacks systems engineering and program

management expertise. Absence of requirements stabilization process.

Program management does not enforce timely milestones,timelines, and deliverables.

Programs lack of process control made assessment oftechnical risk impossible.

Programs lack of short- and long-term budget tracking makescost assessment nearly impossible.

Program does not manage risk.


35/204


The State of Acquisition Practice 3Whats the Problem?

There are many. Among them,Evidence shows that an acquirers management

processes and practices and resultant decisions canhave a negative impact on the development processes

of the supplier

A mismatch in Acquirer/Supplier in terms of associatedprocess capability and maturity can have unpredictable

and even disastrous results.

And the challenges are increasing


36/204


Acquirer/Supplier Mismatch

Acqu

irer

Supplier

Mismatch

Mismatch

mature acquirer mentorslow maturity supplier

outcome not predictable

Immature | mature

acquirer | supplier

Customer encouragesshort cuts.

Matched

acquirer and supplierare both high maturity

highest probability ofsuccess

Disaster

no discipline

no processno product

Technical &Mgt Skill Low

Low

High

High


37/204


Complexity in Modern SystemsMany commercial products are the result of a complex mix ofsubcomponents engineered into a system

Most DoD weapon and information systems are at least thiscomplex


38/204


Weapon System Complexity

FCS Manned Ground Vehicle concept


39/204


System of Systems Complexity

DCGS - Worldwide

DCGS - Regional

Sun

Sun

Sun

DCGS - Forward

MIST/SATCOM GCS

NationalNationalMissionMissionPartnersPartners

ETPETPLOSLOS

KU SATCOMKU SATCOM

BLOSBLOS

PredatorPredator

AWACSAWACS

RJRJ

CommercialCommercialImageryImagery

JSTARSJSTARS

SIBRSIBR

NationalNational

INTINT

IBSIBS

Collection

TaskReceive

Process

Task

ReceiveProcess

Exploit

Disseminate

Execute

MCE

ISRM

AOCM3 IWPCM3 IWPC

ARGUSARGUS


40/204


KSLO

C

F/A-18C/D SMUG/RUG 14268K

F/A-18E/F17101K

F/A-18C/D XN-86629K

F/A-18 Night Attack3054k

F/A-18C/D 2130K F-14D416K F-14B 2866K

A-7E16K

F-14 80K

A-4 (ARBS) 16K

A-6E 64K

F/A-18A/B 943K

F-14B 364K

AV-8B NightAt tack 1780K

AV-8B Radar 3748K

AH-1 NTS 1000KAH-1 764KA-E SWIP 364KAV-8B 764K0

3000

6000

9000

12000

15000

18000

66 70 74 78 82 86 90 94 98 02

Aircraf t IOC, Year

EA-6B ICAP2BLK 89 2203K

E-A6B ICAP148K



06 10

JSFUAVsNCWInter-System

Operability

Increasing System Complexity


41/204


Module 1 AgendaThe State of Acquisition Practices

Capability Maturity Model Integration


42/204


What Can Be Done?

Based on the premise that

The quality of the product is governed largely

by the process used to create the product

We could improve the Suppliers process and practices

But the developers have a head start (CMMI-based improvement

programs are widespread)

We could improve the Acquirers processes and

practices by: increasing the visibility of the acquirers contribution to program

success

defining, implementing, measuring and evolving effective

acquisition processes and practices


43/204


How Do You Want to Work?

Random motion lots ofenergy, not much progress

No teamwork - each persongoes his own way

Frequent conflict

You never know where youllend up

Directed motion every stepbrings you closer to the goal

Coordinated efforts

Cooperation

Predictable results

Process can make the difference


44/204


S u n

S un

S un

Focus of CMMI

CMMI is applied here

SW-CMM is applied here


45/204


CMMI - Continuous SE/SW/IPPD/SS

Organizational ProcessFocus

Organizational ProcessDefinition

Organizational TrainingOrganizational Process

PerformanceOrganizational

Innovation andDeployment

Project PlanningProject Monitoring and

ControlSupplier Agreement Mgmt.Integrated Project Mgmt.Risk ManagementIntegrated TeamingIntegrated Supplier Mgmt

Quantitative Project Mgmt.

RequirementsManagement

RequirementsDevelopment

Technical SolutionProduct IntegrationVerificationValidation

ConfigurationMgmt.

Process andProduct QualityAssurance

Measurement &Analysis

Decision Analysis

and ResolutionOrganizational

Environment for

Integration

Causal Analysis

and Resolution

CMMI

Engineering SupportProcess

Management

Project

Management


46/204


Structure of CMMI1

For CMMI-SW/SE

22 ProcessAreas

157 Goals

539 Practices

PROCESS

AREA 1

PROCESS

AREA n

PROCESS

AREA 2

SpecificPractices

CapabilityLevels

GenericPractices

Specific

Goals

Generic

Goals


47/204


Perspectives on Maturity

ML 1

ML2

ML3

ML4

ML5

Staged

Organization-Focused. . . for an established set of process

areas across an organization

Process-Focused. . . for a single process area

or a set of process areas

PA PACL

0

CL1

CL2

CL3

CL

4

CL

5

PA

Continuous

ProcessA

reaCapab

ility

CONTRACTOR AND PROCESS


48/204


What Levels Tell Us

CONTRACTOR AND PROCESS

Levels are good indicators ofpotentialorganizational performance

They describe how the next project could performbased on a sampling of existing projects

Capability Levels and Maturity Levels reside at theorganizational level (corporation, major division)and are not an indication of how any individualproject is performing

Note: Sometimes a project is large enough to be considered an organizational uni t (e.g. JSF, C-17)


49/204


SummaryAcquisition is a challenging multi-disciplinary effortoccurring in a difficult environment, and demands for

greater capabilities and increasing complexity are adding tothis challenge.

Capable performance by BOTH the acquirer and the

supplier are essential to program success

A focus on PROCESS at the acquirer and at the suppliercan help.

CMMI is a proven and widely accepted processimprovement model

U i CMMI AM t I A i iti


50/204



Practices- Contents

Module 1 BackgroundTutorial information and background



Module 4 CMMI-AM and Support and Generic Practices

Support process areas, goals, and practices; andGeneric Practices



Pittsburgh PA 15213 3890


51/204





Introduction to the CMMIAcquisition Module

(CMMI-AM)



Module 2:CMMI-AM and

Project Management


52/204


Module 2 AgendaIntroduction to the CMMI Acquisition Module

Project Management Process Areas

Project Planning


Solicitation and Contract Monitoring

Integrated Project Management

Risk Management

Summary


53/204


Where Does Process Fit inAcquisition?

at the Project Management Office (PMO)

Management of internal PMO activitiesManagement of processes applied to projectOversight of contractors processesIntegration of contractors and PMO processes

at the ContractorManagement of internal contractor activitiesOversight of subcontractor processes

for integration of PMO, contractor, and

subcontractor processes

PMO AND PROCESS


54/204


Process and the Roles of the PMManage process within the PMO

Manage process applied to the project

Exercise oversight of the contractorsprocess management

Ensure integrationof contractor and

PMO processes

PM

ContractorPMO

Suppliers

PMO AND PROCESS


55/204


The PMO Management RoleThe PM is responsible for managing internal PMO

processes. The PM must take a hands-on approach to

Identify, define, and document process needs

Communicate and train the PMO staff

Support, track, measure,and review the PMOprocesses

PMO

PM

Direct

Responsi

bility

PMO AND PROCESS


56/204


Program Management RoleDefine the interface between the PMO and the

contractor using the RFP and negotiations

Project process requirementsProject metricsProject communication needsProject risk management needs

Manage the interface during

contract executionReal-time monitoring of

deliverablesKeep communication

channels clear & openDevelop trust with contractor

PM

ContractorPMO

Contract

CommunicationProgram Risk

PMO AND PROCESS


57/204


Contractor Oversight Role1

Process maturity of the contractor should be a

consideration in source selection

Obtain process definitions and commitments- J ust requiring a CMMI Maturity Level is NOT enough.

- You need to ensure that high-maturity processes are appliedto YOUR project

- Require your bidders to define the processes they will use intheir proposals

- Evaluate the proposedprocesses as a part of

source selection

- Reference the processesin the contract

Plan process integrationPM

ContractorPMO

Oversight

C t t O i ht R lPMO AND PROCESS


58/204


Contractor Oversight Role 2

After contract award, ensure that contracted process

commitments are kept

Committed processes are used by the project teamProcess artifacts are evidentProcess integration is effective and monitoredConsider periodic independent appraisals of key process areas

PM

ContractorPMO

Oversight

S b t t O i ht R lPMO AND PROCESS


59/204


Subcontractor Oversight Role

For many systems, the bulk of the work is done bysubcontractors

Primary responsibility for oversight of subcontractors lieswith the prime contractor

PMO role is to ensure that prime isproviding adequate oversight tosubcontractors

Ensure flowdown of projectprocess requirements

Ensure integration ofprime and subcontractorprocesses

PM

ContractorPMO

SuppliersIndirectO

versight

P I t ti R lPMO AND PROCESS


60/204


Process Integration Role

It is the PMOs responsibility to ensure PMO and

Contractor processes are compatible

Include any process must havesin the RFP- Consider specific compatibility with tools for risk,

requirements, schedule, etc. Ensure good communications with contractor(s) regarding

process incompatibilities Integration focus

needed throughoutproject

PM

ContractorPMO

ProcessIntegration

CMMI Acquisition Module (CMMI AM)


61/204


CMMI Acquisition Module (CMMI-AM)

Focuses on effective acquisition activities and practices thatare implemented by first-level acquisition projects (e.g.,

System Project Office/Program Manager)Acquisition practices drawn and summarized from existingsources of best practices:

- Software Acquisition Capability Maturity Model (SA-CMM)

- Capability Maturity Model Integration (CMMI)- FAA Integrated Capability Maturity Model (iCMM)- Section 804

Intended to be used in conjunction with the CMMI as anacquisition lensfor interpreting the CMMI in acquisitionenvironments

CMMI-AM a tool for the acquirer

CMMI AM Structure


62/204


CMMI-AM Structure

CMMI Acquisition ModuleV 1.1

Engineering SupportProject

Management

Project PlanningProject Monitor and

ControlIntegrated Project

Management

Risk ManagementSolicitation and

Contract Monitoring

Requirements ManagementRequirements DevelopmentVerificationValidation

Measurement andAnalysis

Decision Analysis andResolution

Transit ion to Operations

and Support

Key

New for CMMI-AM

Structure of CMMI AM


63/204


Structure of CMMI-AM 1

For CMMI-SW/SE

12 Process

Areas

28 Goals

246 Practices

PROCESS

AREA 1

PROCESS

AREA n

SpecificPractices

GenericPractices

SpecificGoals

PROCESS

AREA 2

plus 47 self-assessment questions

Module 2 Agenda


64/204


Module 2 Agenda

Introduction to the CMMI Acquisition Module


Project Planning




Risk Management

Summary


65/204


Project Management PAs

Project management process areas cover the projectmanagement activities related to planning, monitoring, andcontrolling the project.

Project Planning PPProject Monitoring and Control PMC

Solicitation and Contract Monitoring SCM

Integrated Project Management IPMRisk Management RSKM


66/204


Project PlanningThe purpose of project planning is to establish andmaintain plans that define project activit ies. Foracquisition:

Project planning starts by setting the acquisition strategy andis followed by planning the acquisition process in ever

increasing levels of detailAs the acquisition proceeds toward selection of a supplier,the suppliers planning process should be reviewed forsufficiency

The resulting plans should also be reviewed for consistencywith the system acquisition plans

The acquirers and developers project planning processesare continuous and the plans evolve to meet the projects

needs.

Purpose of Acquisition Planning


67/204


Purpose of Acquisition Planning

Guide program execution

From initiation through re-procurement and during post-

production supportSystems, subsystems, components, spares, and services

Minimize the time and cost of satisfying identified, validated

needs in a manner consistent with common sense andsound business practices

Planning evolves through an iterative process and becomes

increasingly more definitive in describing the relationship ofthe essential elements of a program

Paraphrased from DoD 5000 Interim Guidebook

Poor Project Planning


68/204


Poor Project Planning

Symptoms

Poor estimates lead to cost and schedule overruns.

An inability to discover deviations from undocumented plans. Resources are not available/applied when needed.

An inability to meet commitments.

Project failure.

Why should we care?

Customers dont trust acquirers or suppliers who waste theirresources (i.e., loss of future business).

No lessons learned for future projects means making the samemistakes on multiple projects.

Unhappy customers, employees, and stakeholders means ashort life for the business.

If you fail to plan, then you plan to fail.

Acquisition Strategy vs. Acquisition Plan


69/204


Acquisition Strategy vs. Acquisition Plan

Acquisition Strategy is high-level Top-level road map for program execution from program

initiation through post-production support.

ITERATIVE should be updatedLevel of detail changes as you go through the phasesAs per DoDI 5000.2 required for ALL programs at:

- Program Initiation for Ships

- Milestone B- Milestone C- Full-Rate Production Deployment Review

Acquisition Plan is typically for one phaseRequired by the Federal Acquisition Regulation (FAR)Focuses on specifics of the acquisitionConcerned with contract type, incentives, etc.

Acquisition Planning Cycle


70/204


Acquisition Planning Cycle

StakeholdersStakeholders

EvaluateIncremental

Progress

StakeholdersStakeholdersStakeholdersStakeholders

MS B

ExecuteAcquisition

Strategy

EvaluateIncremental

Progress

Execute

RefinedAcquisit ion

Strategy

ImproveProcess

ImproveProcess

RefineAcquisition Strategy

RefineAcquisit ion StrategyDevelop

Acquisit ion Strategy

Acq.Strategyv1.0

Acq.Strategyv2.0

TechDevelStrat

AoAPlan

Acquisition Planning Objectives


71/204


Acquisition Planning Objectives

Communicate!

Identify risks- Strategies for risk mitigation- Balance risks with cost, schedule and performance

Define expectations for all stakeholders- Role and responsibilities of all parties

Determine how to make your program executable withinbudget and schedule constraints- Expected program changes throughout lifecycle

Acquisition Strategy Elements


72/204


Acquisition Strategy Elements

Acquisition Approach

RequirementsRisk Management

Design ConsiderationsBusiness Strategy

Program ManagementSupport Strategy

From Interim Defense Acquisition Guidebook, 30 Oct 2002

Single-Step and Evolutionary Acquisition


73/204


g p y q

100%

Based on AF Program Manager Workshop presented by Mr Little

Single-Step

Time

Known increment

Deliverable Capability

100% of requirementsknown at start

100% of requirementsknown at start

Known increment

Partially

known

increment Unknown

increment

Only first incrementrequirements known at start

Incremental

Spiral

Known increment Known increment

User, developer, tester,

sustainer use and learn

Unknown

increment

Evolutionary Approach


74/204


Evolutionary Approach

CR TD SDD PD OS

B

Increment 2

Increment 3

A C

B C

B C

Increment 1

Adapted from dod5000.dau.mil

= Contractor Spiral

Development

= Contractor Incremental

Development

Acquisition & Development Methods


75/204


q p

= fielded system

Acquisition of a New Utility truck

Single Step Acquisit ion, Contractor Incremental Development

Increment 1 Hard to produce brakesIncrement 2 Easier to produce brakes

Inc 3 Develop new interfaces

Spiral 1 Prototype 1



Inc 2SW radios for existing interfaces

Increment 1- Interface 1

Increment 2- Interface 2

Inc 1 HW Upgrades

Single Step Development

Evolutionary Acquisit ion (Spiral), Contractor Mixed Development

Comms System

Program Drivers


76/204


g

What software and system issues might DRIVE

your acquisit ion strategy due to the risk they pose

to successful execution?Schedule Staffing

Funding Test Requirements

Requirements Stability User Support

External Interfaces Policy Mandates

Deployment Security

Interoperability (Programmaticand Developmental)

System ComplexityPrecedented / Unprecedented

Technology Maturity

Dealing with Drivers


77/204


g

Determine which present the highest risk exposure to yourprogram

Determine how the drivers will influence your acquisitionstrategy elements

Formulate strategies that you believe will deal with the

risks posed by the top drivers

Analyze the strategies to determine gaps and remaining

high risk areas

Acquisition Plan Contents


78/204


qAcquisition background and objectives

Statement of need Applicable conditions

Cost Capability or performance

Risks Trade-offsDelivery or performance-periodrequirements

Plan of action (sample)

Sources Competition

Source-selection procedures Acquisition considerations

Budgeting and funding Government-furnished property

Make or buy Inherently governmental functionsTest and evaluation Logistics considerations

Security considerations Contractor versus Governmentperformance

Project Planning


79/204


CMMI-AM Goals and Practices 1Specific Goal Specific Practice

EstablishEstimates

Estimate the Scope of the Project Establish Estimates of Work Product and Task

Attributes Define Project Life Cycle Determine Estimates of Effort and Cost

Develop a

Project Plan

Establish the Budget and Schedule

Identify Project Risks Plan for Data Management Plan for Project Resources Plan for Needed Knowledge and Skills Plan Stakeholder Involvement

Establish the Project PlanObtainCommitmentto the Plan

Review Plans that Affect the Project Reconcile Work and Resource Levels Obtain Plan Commitment

Project Planning


80/204


Goal 1: Establish Estimates 1Estimates of project planning parameters are

established and maintained

Establish a top-level WBS1 to estimate the scope of theproject

Defines tasks for the ENTIRE project, including efforts of:- The supplier - The acquirer- Other stakeholders (e.g., test community, users)

Based upon product architecture

Establish estimates of work product and task attributes

Provides a basis for cost and effort estimation

Software examples KSLOC, function points, # of objects, # ofinterfaces, data volume, etc.

1 See MIL-HDBK-881A ( http://dcarc.pae.osd.mil/881handbook/881A.pdf)

Project Planning


81/204


Goal 1: Establish Estimates 2Define the project life-cycle phases upon which to scope theplanning effort

Acquisition method- Single-Step - Evolutionary-incremental Evolutionary-spiral

Life Cycle phases- Development - Manufacturing - Verification - Training- Deployment - Operation - Support - Disposal

Estimate the project effort and cost for the work productsand tasks based on estimation rationale

Define estimation rationale

Estimate cost and effort for each work product and task

Consider independent review of estimates

Project Planning


82/204


Goal 2: Develop a Project Plan 1A project plan is established and maintained as thebasis for managing the project

Establish and maintain the projects budget and schedule Identify assumptions, constraints, major milestones

Identify task dependencies

Identify and analyze project risks

Involve stakeholders in identification of risk

Analyze impact, timeframe, and probability of occurrence

Plan for the management of project data

Create master list of data to be managed (formal and informal)- Identify needs for version control and configuration mgt

Define data content and formats

Establish requirements for security and information assurance

Project Planning


83/204


Goal 2: Develop a Project Plan 2Plan for necessary resources to perform the project Identify and plan for process requirements

Identify and plan for staffing requirements

Identify and plan for facilities and equipment requirements

Plan for knowledge and skills needed to perform theproject

Identify skills needed Assess available skills

Develop a plan to fill the gaps

Project Planning


84/204


Goal 2: Develop a Project Plan 3Plan the involvement of identified stakeholders Identify relevant stakeholders

Plan their involvement

Obtain commitments for involvement

Establish and maintain the overall project plan content

Captures all relevant planning items to enable communication

among the project team and stakeholders

May be comprised of multiple plans such as- Integrated Master Plan- Integrate Master Schedule

- Systems Engineering Management Plan- Software Development Plan

Must be maintained throughout the acquisition

Module 2 Agenda


85/204



Project Management Process AreasProject Planning




Risk Management

Summary


86/204


Project Monitoring and Control1The purpose of project monitoring and control is to provideunderstanding into the projects progress so that appropriate

corrective actions can be taken when the projectsperformance deviates significantly from the plan.

Project Monitoring and Control2


87/204


For Acquisition, monitoring and control functions aredirected within the acquisition project early in the processas the acquisition planning is performed and the strategy isdefined. As the acquisition process enfolds, monitoring andcontrol are essential to ensuring that appropriate resourcesare being applied and that the internal acquisition activitiesare progressing according to plan.

Once a supplier is selected and an award is made, the roleof monitoring and control becomes two fold, concerned withboth continuing to monitor and control internally while alsomonitoring and controlling the progress of the suppliersexecution under the suppliers project plan.

Poor Project Monitoring and Control


88/204


Symptoms

Lots of time is spent in meetings trying to discover projectstatus rather than reporting on it.

Data needed for management decisions is unavailable whenneeded.

Actions that should have been taken early arent identified untilits too late

Why should we care?

If you dont know whats going on, corrective action cant betaken early when its least expensive.

Lack of management insight/oversight makes project resultshighly unpredictable, even later in the project.

If your confidence in the status you give to your customer islow, they probably perceive it.


CMMI AM G l d P ti


89/204


CMMI-AM Goals and Practices

Specific Goal Specific Practice

Monitor ProjectAgainst Plan Monitor Project Planning Parameters Monitor Commitments Monitor Project Risks Monitor Data Management Monitor Stakeholder Involvement Conduct Progress Reviews Conduct Milestone Reviews

Manage CorrectiveAction to Closure

Analyze Issues Take Corrective Action Manage Corrective Action

Module 2 Agenda


90/204



Project Management Process AreasProject Planning




Risk Management

Summary



91/204


The purpose of Solicitation and Contract Monitoring is to preparea solicitation package that identifies the needs of a particularacquisition, to select a supplier who is best capable of satisfying

those needs, and to establish the process for monitoring thesupplier for the duration of the contract.

For Acquisition, the solicitation must comply with the applicable

federal, departmental, and service acquisition regulations andpolicies. The solicitation should address issues appropriate to theproduct domain or acquisition environment (e.g., supplier processevaluations, operational safety suitability and effectiveness,certifications, architecture evaluations, and interoperability). The

representatives responsible for these activities within the projector stakeholder organizations should be consulted for properinclusion of those activities into the solicitation and contractmonitoring process.

Poor Solicitation and Contract Monitoring


92/204


Symptoms

The solicitation package does not include theagreement/contractual requirements and proposal evaluation

criteria. The technical and management elements of proposals are not

properly evaluated to ensure that the requirements of theagreement/contract will be satisfied.

The selection official will not select suppliers who are qualified tosatisfy the agreement/contracts requirements for the projectsproducts..

Why Do We Care?

The project team will have insufficient insight into the suppliersactivities to ensure the effort is managed, controlled and complieswith contract requirements.

The project team and supplier team will be unable to maintain

ongoing communication and commitments.


CMMI AM Goals and Practices


93/204


CMMI-AM Goals and PracticesSpecific Goal Specific Practice

Prepare for theSolicitation

Designate a Selection Official Establish a Solicitation Package and Evaluation

Criteria Establish Cost and Schedule Estimates Validate the Solicitation Package

Select Suppliers Evaluate Proposals

Use Evaluation Results to Select SuppliersAward Contracts Establish an Understanding of the Contract and

Proposed Approach Establish Communications Processes and

Procedures

Coordinate Workwith Suppliers

Monitor Selected Supplier Processes Evaluate Selected Supplier Work Products Revise the Supplier Agreement or Relationship


Goal 1: Prepare for the Solicitation 1


94/204


Goal 1: Prepare for the Solicitation 1The project is prepared to conduct the solicitation

Designate a selection official responsible for making the

selection decisionEstablish and maintain a solicitation package that includesthe needs of the acquisit ion and corresponding proposalevaluation criteria

Define the required proposal content- Process descriptions and commitments

- Proposed development approach (e.g., processes, tasks,activities)

- Metrics to be provided to the PMO (including processmetrics)

- Appropriate plans (e.g., Integrated Mgt plan, SoftwareDevelopment Plan, risk Management Plan)


Goal 1: Prepare for the Solicitation 2


95/204


Goal 1: Prepare for the Solicitation 2Establish and maintain independently reviewed cost andschedule estimates for the products to be acquired

Reviewers should not be connected with the acquisition team

or the supplier

Validate the solicitation package with end users andpotential offerors to ensure the approach and cost andschedule estimates are realistic and can reasonably lead to a

usable product. In a competitive environment, ensure equal access to all

potential offerors. Provide a means for reviewers to offerclarifications of ambiguous capabilities.

In a sole source or change order environment, ensure thatrelevant stakeholders recognize the consequences ofproposed changes


Goal 2: Select Supplier


96/204


Goal 2: Select SupplierSuppliers are selected based on the solicitationpackage

Evaluate proposals according to the documented evaluationcriteria

In addition to evaluating the technical approach, evaluate- Management practices - Sufficiency of plans- Process capabilities - Domain experience- Cost - Schedule- Past Performance

Use proposal evaluation results as a basis to support

selection decisions


Goal 3: Award Contracts 1


97/204


Goal 3: Award Contracts 1Contracts are issued based on the needs of theacquisition and the suppliers proposed approaches

Establish and maintain a mutual understanding of thecontract with selected suppliers and end users based on theacquisition needs and the suppliers proposed approaches

Ensure that contractual commitments are made for factorscritical to project success (e.g., process execution, metricscollection and reporting)

Maintain mutual understanding for the duration of the contract


Goal 3: Award Contracts 2


98/204


Goal 3: Award ContractsEstablish and maintain communication processes andprocedures with suppliers that emphasize the needs,expectations, and measures of effectiveness to be used

throughout the acquisition Define ground rules for

- communication (e.g., data reported, frequency of reporting)

- key decision-making (e.g., rationale, documentation,acquirer involvement)

- conflict resolution

Monitor process deployment and effectiveness

Maintain open lines of communication


Goal 4: Coordinate Work 1


99/204


Goal 4: Coordinate WorkWork is coordinated with suppliers to ensure thecontract is executed properly

Monitor and evaluate selected processes used by thesupplier based on the suppliers documented processes

Adherence to plan

Timeliness of deployment

Effectiveness of processEvaluate selected supplier work products based ondocumented evaluation criteria

Define work products to be evaluated (may include interime

products) and evaluation criteria Ensure capacity and capability for timely and accurate

evaluation


Goal 4: Coordinate Work 2


100/204


Goal 4: Coordinate WorkRevise the supplier agreement or relationship, asappropriate, to reflect changes in conditions

Address shortfalls in both products and processes

Offer relief when needs evolve to invalidate processrequirements, documentation requirements, reportingrequirements, etc.

Module 2 Agenda


101/204




Project Planning




Risk Management

Summary



102/204


For Acquisition, integrated project management involvesestablishing project management processes consistent withand tailored from the organizations standard processes. This

includes higher level acquisition guidance, regulations,instructions, as well as local practices established to be usedacross various projects in the local organization. Establishingan integrated project management process incorporating andinvolving all stakeholders (executive level acquisition offices,

users, test organizations, developers, and associatedgovernment support organizations) is critical to thesuccessful development of the project.

Formal interfaces among project stakeholders take the form

of memorandums of understanding (MOUs), memorandumsof agreements (MOAs), contractual commitments, associatecontractor agreements and similar documents depending onthe nature of the interfaces and involved stakeholders.

Poor Integrated Project Mgt

S t


103/204


Symptoms

No defined processes for the project

Project estimates make no reference to prior projects

Plans do not reflect the way the project is executed

Project staff does not know what is in the project plans

Stakeholders are not identified and involved

Why do we care?

Without processes, performance is ad hoc

Without the history of prior projects, we may make the same

mistakes If execution doesnt follow the plans, what does it follow?

Uninvolved stakeholders can provide last-minute surprises

Lessons learned are not captured




104/204


CMMI AM Goals and PracticesSpecific Goal Specific Practice

Use the ProjectsDefined Process

Establish the Projects Defined Process Use Organizational Process Assets for Planning

Project Activities Integrate Plans

Manage the Project Using the Integrated Plans

Contribute to the Organizational

Process AssetsCoordinate andCollaborate withRelevant

Stakeholders

Manage Stakeholder Involvement Manage Dependencies Resolve Coordination Issues

Module 2 Agenda

I t d ti t th CMMI A i iti M d l


105/204




Project Planning




Risk ManagementSummary

Risk Management

Th f i k t i t id tif t ti l bl


106/204


The purpose of risk management is to identify potential problemsbefore they occur, so that risk-handling activities may be plannedand invoked as needed across the life of the product or project to

mitigate adverse impacts on achieving objectives.

For Acquisition, risk identification and estimation of probability ofoccurrence and impact, particularly for those risks involved inmeeting performance requirements, schedules, and cost targets,largely determines the acquisition strategy. The acquirer has a dualrole, first in assessing and managing overall project risks for theduration of the project, and second, in assessing and managing risksassociated with the performance of the supplier. As the acquisition

progresses to the selection of a supplier, the risk specific to thesuppliers technical and management approach becomes importantto the success of the acquisition.

Poor Risk Management

S t


107/204


Symptoms

Risks are being ignored.

Known risks to project staff are a surprise to management. Every time a new problem manifests, a new management

technique is tried.

Why should we care? The project may escape some of the bullets,but not all of

them.

No lessons learned for future projects means making the same

mistakes on multiple projects. Repeated project failures due to unforeseen (but predictable)

risks costs you and your organization.

Risk Management

CMMI-AM Goals and PracticesSpecific Goal Specific Practice


108/204



Prepare for RiskManagement

Determine Risk Sources and Categories

Define Risk Parameters

Establish a Risk Management Strategy

Identify andAnalyze Risks

Identify Risks Evaluate, Categorize, and Prioritize Risks

Mitigate Risks Develop Risk Mitigation Plans Implement Risk Mitigation Plans

Acquisition Risk Management 1

What Can Acquisit ion Program Offices Do? A Few Ideas


109/204



Start a risk management program on Day 1 of the program

Ensure that PMO staff have appropriate risk managementtraining

Use mult iple methods to identify risk sources:- periodic risk reporting - brainstorming- voluntary risk reporting - risk report forms- taxonomy-based questionnaire (TBQ) - TBQ interviews

Acquisition Risk Management 2



110/204



Add language to RFPs and contracts that specify how risks are

to be reported to the PMOEncourage decentralization of risk identification and analysis

following an organizationally defined process

Establish and maintain a schedule of joint risk reviews with allcontractors throughout the program, including joint prioritizationof the most important risks to the program

Find ways to reward contractors for early identification of

issues and risksDefine a process and criteria for escalating risks to the next

higher level

Module 2 Agenda



111/204




Project Planning




Risk ManagementSummary

Summary 1

PM roles include PMO management, project management,


112/204


PM roles include PMO management, project management,supplier oversight, indirect subcontractor oversight, and processintegration

CMMI-AM is a tool intended to help the acquirerachieve success

Development of a suitable acquisit ion strategy is a keycomponent of project planning

Principal goals ofProject Planning Establish estimates Develop a project plan Obtain commitment to the plan

Principal goals ofProject Monitoring and Control Monitor Project Against Plan Manage Corrective Action to Closure

Summary 2

Principal goals of Solicitation and Contract Monitoring


113/204


Principal goals ofSolicitation and Contract Monitoring Prepare for the Solicitation Select Suppliers

Award Contracts Coordinate Work with Suppliers

Principal goals ofIntegrated Project Management Use the Projects Defined Process

Coordinate and Collaborate with Relevant Stakeholders

Principal goals ofRisk Management Prepare for Risk Management Identify and Analyze Risks Mitigate Risks

CMMI


Practices- Contents


114/204

2005 by Carnegie Mellon University CMMI Acquisition Module - Page M3-1CMMI-AM and Engineering v0.1

Module 1 BackgroundTutorial information and background



Module 4 CMMI-AM and Support and Generic PracticesSupport process areas, goals, and practices; and

Generic Practices




CMMI

Using CMMI-AM to Improve


115/204

CMMI Acquisit ion Module - Page M3-2


2005 by Carnegie Mellon UniversityThis material is approved for public release. Distribution is limited by the Software Engineering Institute toattendees.

g pAcquisition Practices

Module 3:

CMMI-AM andEngineering



CMMI

Module 3 Agenda

Engineering Process Areas


116/204


g g

Requirements Development

Requirements Management

Verification

ValidationSummary

CMMI

PMO Role in Systems Engineering 1

Inherent PMO Responsibility:


117/204


Ensure technology readiness level is appropriate for programphase

Develop initial system requirements in conjunction withstakeholders and ensure continued involvement

Develop technical evaluation criteria and evaluate proposals

during source selection

Develop independent cost and schedule estimates for thetechnical effort

Ensure external interfaces are properly identified andmonitored

Ensure PMO has adequate systems engineering staff

CMMI

PMO Role in Systems Engineering 2

PMO responsibility in conjunction with your contractor:


118/204


p y j y

Ensure contractor development method is appropriate

Ensure contractors systems engineering processes areacceptable and being followed

Ensure compatible processes between prime and subcontractors and between the contractor team and the PMO

Review and approve systems engineering documentationEnsure systems engineering function is adequately integrated

with other areas such as logistics and test

Manage the top-level change control process

Perform technical evaluationsSystems Integration (if applicable)

Ensure end system meets requirements

CMMI

Module 3 Agenda



119/204


g g



Verification

ValidationSummary

CMMI

Requirements Development 1

The purpose of requirements development is to produce


120/204


p p q p pand analyze customer, product, and product-componentrequirements.

CMMI


The purpose of requirements development is to produce


121/204


and analyze customer, product, and product-componentrequirements.

For Acquisition, requirements development has twocontexts;

The amalgamation and coordination of the operationalrequirements (customer requirements) into a requirementsset that will define the scope and direction of the acquisition;

The allocation and extension of the customer requirements

and additional acquirer requirements (e.g., architecture,formal and informal reviews, reporting or data requirements)that become the basis of the processes utilized by thesuppliers organization.

CMMI


There is a continuous iteration of requirements down through


122/204


the multiple tiers of requirements documents associated with the

components of the system. For example, requirements flow from the stakeholders to the

system level to multiple subsystem levels and eventually to

either hardware or software component levels.The responsibility for developing requirements across the levels

is generally split between the acquirer and the supplier.

The acquirer is generally responsible for the higher level,starting with operational requirements and the supplier is

responsible for successive levels below that.

CMMI

Poor Requirements Development

Symptoms


123/204


Unstated requirements or poorly stated requirements lead toconfusion among staff and customers.

Design, implementation, and test work products inconsistentlyinterpret the requirements.

It takes a long time to get agreement on product design.

Why should we care?

Unusable products and unhappy customers

Wasted time and resources building the wrongproduct

Staff members get tired of rework because requirements havebeen re-interpreted yet again.

Excessive spending to satisfy customer expectations

CMMI

Requirements: Input or Output?


124/204


You RECEIVE requirements from your customerOperational needs

You DELIVER requirements to your supplierThrough the solicitation, SOW, SOO, and/or contract

Your job isTo ensure the quality of the inputsTo convert the inputs to the high-quality outputs

CMMI

Requirements Must be Balanced

Stakeholder Needs /


125/204


Adapted from COTS-Based Systems forProgram Managers

Marketplace

Stakeholder Needs /

Business Processes

Programmatics/

Risks

Architecture /

Design

Simultaneous

Defini tion &Tradeoffs

CMMI

Requirements Must Evolve

Accumulating knowledge

D


126/204


[EPIC 2002]

g g

Increasing stakeholder buy-in

Iteratively converging

decisions

Definition

& Trade

Offs

TIME

Stakeholders

Program

Market Design

Definition

& TradeOffs

CMMI




D l Eli it N d


127/204


DevelopCustomer

Requirements

Elicit Needs

Develop the Customer Requirements

DevelopProductRequirements

Establish Product and Product- ComponentRequirements

Allocate Product-Component Requirements

Identify Interface RequirementsAnalyze andValidateRequirements

Establish Operational Concepts and Scenarios

Establish a Definition of Required Functionality

Analyze Requirements

Analyze Requirements to Achieve Balance Validate Requirements with Comprehensive

Methods

CMMI

Module 3 Agenda



128/204




Verification

ValidationSummary

CMMI

Requirements Management 1

The purpose of requirements management is tomanage the requirements of the projects products and


129/204


manage the requirements of the project s products andproduct components and to identify inconsistencies

between those requirements and the projects plans andwork products.

For Acquisition, requirements management is applied to

the requirements that are received from therequirements development process.

CMMI

Requirements Management 2

During acquisition, requirements management includes

the direct manag

use of cmmi in acquisition environments

Documents