Introduction to the CMMI® Acquisition Module (CMMI-AM)

Introduction to the CMMI® Acquisition Module (CMMI-AM)
Module 2: CMMI-AM and Project Management STUDENT NOTES 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.

Agenda Introduction to the CMMI Acquisition Module
Project Management Process Areas Project Planning Project Monitoring and Control Solicitation and Contract Monitoring Integrated Project Management Risk Management Summary STUDENT NOTES

Where Does Process Fit in Acquisition?
… at the Project Management Office (PMO) Management of internal PMO activities Management of processes applied to project Oversight of contractors’ processes Integration of contractors’ and PMO processes … at the Contractor Management of internal contractor activities Oversight of subcontractor processes … for integration of PMO, contractor, and subcontractor processes STUDENT NOTES

Process and the Roles of the PM
PMO AND PROCESS Process and the Roles of the PM Manage process within the PMO Manage process applied to the project Exercise oversight of the contractors’ process management Ensure integration of contractor and PMO processes PM Contractor PMO Project Suppliers STUDENT NOTES INSTRUCTOR NOTES: The figure illustrates the project environment in which the PM exists. The PM operates in a multi-faceted environment consisting of The PMO The Project The contractor The contractor’s suppliers The PMs responsibility and authority vary, depending upon where in this environment the PM’s attention is focused. Within this environment, the PM has the responsibility to” Manage process within the PMO Manage process applied to the project Exercise oversight of the contractors’ process management Ensure integration of contractor and PMO processes

The PMO Management Role
PMO AND PROCESS The PMO Management Role The 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 PMO processes PMO PM Direct Responsibility STUDENT NOTES INSTRUCTOR NOTES: This slide focuses on the PMO (or SPO, JPO, etc.). The PM’s role is that of Manager, exercising “Hands on”, direction of staff and resources. From the PM perspective there are many processes that increase the likelihood of successful software acquisition. Example: Risk Management process PM perspective, he should have a RSKM process within the Program Office to: Identify risks Categorizes/prioritizes Identify mitigation actions Track risks and there associated mitigation actions Some acquisition reform initiatives make oversight of the contractor even more challenging (e.g., TSPR)

Program Management Role
PMO AND PROCESS Program Management Role Define the interface between the PMO and the contractor using the RFP and negotiations Project process requirements Project metrics Project communication needs Project risk management needs Manage the interface during contract execution Real-time monitoring of deliverables Keep communication channels clear & open Develop trust with contractor PM Contractor PMO Project Contract Communication Program Risk STUDENT NOTES INSTRUCTOR NOTES This chart indicates the area of intersection between PO and contractor: • described and defined by the program contract • characterized by communication channels between PO & contractor • the realm in which a PM is responsible for oversight of JOINT processes, such as a program level risk management system. Example: Risk Management process • It is the PM’s responsibility to make sure all Risk Management processes have an interface producing a combined (Acquirer, Developer and Supplier) Program Risk Management process that consolidates and categorizes (priority/severity nature) all risks of the program.

Contractor Oversight Role 1
PMO AND PROCESS Contractor Oversight Role 1 Process maturity of the contractor should be a consideration in source selection Obtain process definitions and commitments Just requiring a CMMI Maturity Level is NOT enough. You need to ensure that high-maturity processes are applied to YOUR project Require your bidders to define the processes they will use in their proposals Evaluate the proposed processes as a part of source selection Reference the processes in the contract Plan process integration PM Contractor PMO Project Oversight STUDENT NOTES INSTRUCTOR NOTES: This slide illustrates the PMs role toward the contractor. That is more HANDS OFF. Oversight is the focus rather than “hands on management”. Note that the PM is overseeing the contractor’s independent processes. NOT joint processes. Example: Risk Management process • There PM should insist on a comparable Risk Management process on the contractor side, focusing on development risk, and get periodic risk assessment reports

Contractor Oversight Role 2
PMO AND PROCESS Contractor Oversight Role 2 After contract award, ensure that contracted process commitments are kept Committed processes are used by the project team Process artifacts are evident Process integration is effective and monitored Consider periodic independent appraisals of key process areas PM Contractor PMO Project Oversight STUDENT NOTES INSTRUCTOR NOTES: This slide illustrates the PMs role toward the contractor. That is more HANDS OFF. Oversight is the focus rather than “hands on management”. Note that the PM is overseeing the contractor’s independent processes. NOT joint processes. Example: Risk Management process • There PM should insist on a comparable Risk Management process on the contractor side, focusing on development risk, and get periodic risk assessment reports

Subcontractor Oversight Role
PMO AND PROCESS Subcontractor Oversight Role For many systems, the bulk of the work is done by subcontractors Primary responsibility for oversight of subcontractors lies with the prime contractor PMO role is to ensure that prime is providing adequate oversight to subcontractors Ensure flowdown of project process requirements Ensure integration of prime and subcontractor processes PM Contractor PMO Project Suppliers Indirect Oversight STUDENT NOTES INSTRUCTOR NOTES Likewise the risks in the contractor’s suppliers– suppliers should manage their own risks, but the responsibility rests first with the contractor and then with the PM; so the role of monitor becomes critical. Note: Risk Management in this slide is managed by the PM as OVERSIGHT – performed indirectly through the contractor as he monitors his suppliers’ risk management. Supplier Management – Ultimately the contractor’s responsibility, but the PO needs to be aware if the contractor is capable of managing suppliers. • SA-CMM • SW-CMM - Software Supplier Management • CMMI – Supplier Sourcing and Integrated Supplier Management.

Process Integration Role
PMO AND PROCESS Process Integration Role It is the PMO’s responsibility to ensure PMO and Contractor processes are compatible Include any process “must haves” in the RFP Consider specific compatibility with tools for risk, requirements, schedule, etc. Ensure good communications with contractor(s) regarding process incompatibilities Integration focus needed throughout project PM Contractor PMO Project Process Integration STUDENT NOTES INSTRUCTOR NOTES: KEY POINT ● Integrating processes across your project team SUGGESTED SCRIPT ● This chart indicates the area of intersection between PO and contractor: ○ described and defined by the program contract ○ characterized by communication channels between PO & contractor ○ the realm in which a PM is responsible for oversight of JOINT processes, such as a program level risk management system. ● Example: Risk Management process ○ It is the PM’s responsibility to make sure all Risk Management processes have an interface producing a combined (Acquirer, Developer and Supplier) Program Risk Management process that consolidates and categorizes (priority/severity nature) all risks of the program. TRANSITION ● Process and your contractor

CMMI Acquisition Module (CMMI-AM)
Focuses on effective acquisition activities and practices that are implemented by first-level acquisition projects (e.g., System Project Office/Program Manager) Acquisition practices drawn and summarized from existing sources 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 an acquisition “lens” for interpreting the CMMI in acquisition environments STUDENT NOTES CMMI-AM – a tool for the acquirer

CMMI Acquisition Module V 1.1
CMMI-AM Structure CMMI Acquisition Module V 1.1 Project Management Engineering Support Project Planning Project Monitor and Control Integrated Project Management Risk Management Solicitation and Contract Monitoring Requirements Management Requirements Development Verification Validation Measurement and Analysis Decision Analysis and Resolution Transition to Operations and Support STUDENT NOTES INSTRUCTOR NOTES: Solicitation and Contract Monitoring: The purpose is to prepare a solicitation package that identifies the needs of a particular acquisition, to select a supplier who is best capable of satisfying those needs, and to provide leadership throughout the life of the acquisition to ensure those needs are met. Transition to Operations and Support: The purpose is to provide for the transition of the product to the end user and the eventual support organization and to accommodate lifecycle evolution. Eventual disposal of the product should be considered. Key New for CMMI-AM

… plus 47 self-assessment questions
Structure of CMMI-AM 1 For CMMI-SW/SE 12 Process Areas 28 Goals 246 Practices PROCESS AREA 1 PROCESS AREA 2 PROCESS AREA n Specific Goals Specific Practices Generic Practices STUDENT NOTES … plus 47 self-assessment questions

Project Management PAs
Project management process areas cover the project management activities related to planning, monitoring, and controlling the project Project Planning PP Project Monitoring and Control PMC Solicitation and Contract Monitoring SCM Integrated Project Management IPM Risk Management RSKM STUDENT NOTES

Project Planning The purpose of project planning is to establish and maintain plans that define project activities. For acquisition: Project planning starts by setting the acquisition strategy and is followed by planning the acquisition process in ever increasing levels of detail As the acquisition proceeds toward selection of a supplier, the supplier’s planning process should be reviewed for sufficiency The resulting plans should also be reviewed for consistency with the system acquisition plans The acquirer’s and developer’s project planning processes are continuous and the plans evolve to meet the project’s needs STUDENT NOTES

Purpose of Acquisition Planning
Guide program execution From initiation through re-procurement and during post-production support Systems, subsystems, components, spares, and services Minimize the time and cost of satisfying identified, validated needs in a manner consistent with common sense and sound business practices Planning evolves through an iterative process and becomes increasingly more definitive in describing the relationship of the essential elements of a program Paraphrased from DoD 5000 Interim Guidebook STUDENT NOTES

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 don’t trust acquirers or suppliers who waste their resources (i.e., loss of future business) No lessons learned for future projects means making the same mistakes on multiple projects Unhappy customers, employees, and stakeholders means a short life for the business STUDENT NOTES “If you fail to plan, then you plan to fail.”

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 updated Level of detail changes as you go through the phases As per DoDI required for ALL programs at: Program Initiation for Ships Milestone B Milestone C Full-Rate Production Deployment Review Acquisition Plan is typically for one phase Required by the Federal Acquisition Regulation (FAR) Focuses on specifics of the acquisition Concerned with contract type, incentives, etc. STUDENT NOTES Acquisition Strategy – Specific Documentation – Required for Milestones Acquisition Plan – Required by the FAR for each solicitation DODI – Department of Defense Instruction Acquisition Planning includes the Acquisition Strategy, Acquisition Plans and other documentation INSTRUCTOR NOTES: Do NOT confuse the Acquisition Plan document with the activity called Acquisition Planning

Acquisition Planning Cycle
Stakeholders Evaluate Incremental Progress MS B Execute Acquisition Strategy Execute Refined Acquisition Strategy Improve Process Refine Acquisition Strategy Develop Acquisition Strategy Acq. Strategy v1.0 Acq. Strategy v2.0 Tech Devel Strat AoA Plan STUDENT NOTES AoA = Analysis of Alternatives Tech Devel Strat = Technology Development Strategy Acq Strategy = Acquisition Strategy MS = Milestone B INSTRUCTOR NOTES: You will see this chart a few more times in this module – at this point I just want to give you a top-level view of the acquisition planning cycle – we’ll go into more detail in a few charts

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 within budget and schedule constraints Expected program changes throughout lifecycle STUDENT NOTES Software Importance: • Is the software the majority of the system • Reliance on software • How difficult is the software to develop INSTRUCTOR NOTES: The PRIMARY OBJECTIVE of the acquisition strategy is to COMMUNICATE your plan for the acquisition to the acquisition team • That includes your Program Office staff, your bidders and contractors, your PEO and all of your stakeholders When forming an acquisition strategy for SW intensive system you need to consider the SW aspect in all these objectives: • Risk Mitigation – Your risk mitigation strategies must include any SW risk issues – for example – if you are using COTS – what if the vendor changes the product – happened on a program and it caused a lot of rework to existing code • How much risk does SW add? How IMPORTANT is the software to the system? • Is the software the majority of the system – for example – a payroll system or a minor part – for example a chem-bio defense sensor where the sensor is the main technology and the SW simply averages and displays the readings? • Reliance on SW – Is this the flight control sw that is needed to fly the helicopter or is it part of a fire control system that has back-up iron sights? • How difficult is the SW to develop – Has this type of sw been developed before – for example – a targeting system for a tank or is the unprecedented – like FCS (Future Combat System) • {Draw Table} Issue: Risk if Yes Risk if No Majority of System ↑ ↓ Reliance on SW ↑ ↓ Difficult to Develop ↑ ↓ • An example illustrating “Majority of the System” and “Reliance on SW” – in a HUMV you could have sw that controls fuel to the engine. It is NOT a majority of the system – that would be the mechanical components – BUT – if the HUMV can’t operate without that SW – then there is a big RELIANCE on SW. Stakeholders can be different in a SW intensive system – if there is a large COTS component, that vendor could be a stakeholder – for example, MilPDS (Military Personnel Data System) is an Oracle based application and Oracle is a stakeholder in this program; Information Technology Acquisition Board (ITAB) – New 5000 for Major Automated Information Systems Executable – for spiral development you can have simultaneous need for Development and Sustainment funding – also more effort on the part of the contractor to concurrently work on requirements, design, and production activities – be sure this is affordable Because the strategy is so important, I’ll spend some time discussing this. The idea of difficulty of the software is embodied in the concept of precedented vs. unprecedented so we’ll take a look at that first

Acquisition Strategy Elements
Acquisition Approach Requirements Risk Management Design Considerations Business Strategy Program Management Support Strategy STUDENT NOTES This is just one way of looking at Acquisition Strategy Elements – based on the Interim Defense Acquisition Guidebook INSTRUCTOR NOTES: There are many elements or sub strategies that go into making up your overall acquisition strategy. One of the important elements to consider is the combination of your acquisition approach and your development method – since the new DoD 5000 has changed the landscape slightly, I’m going to talk about this one acquisition element for the next few slides From Interim Defense Acquisition Guidebook, 30 Oct 2002

Single-Step and Evolutionary Acquisition
100% of requirements known at start 100% ‘Deliverable’ Capability Single-Step 100% of requirements known at start Known increment Known increment Known increment Incremental Only first increment requirements known at start Partially known increment Spiral Known increment Unknown increment STUDENT NOTES There are two basic acquisition methods (called strategies) in DoDI – Single-Step and Evolutionary. INSTRUCTOR NOTES: BUILD – Single Step For the single step you start out knowing all the requirements and deliver 1 system that meets those requirements at the end of the development BUILD – Incremental In an incremental development you also start out knowing all the requirements at the start, but you plan to deliver systems that meet those requirements incrementally. The basic functionality of each increment is known at the beginning BUILD – Spiral In a spiral development you don’t know all the requirements at the start of the program. You need to be able to specify ALL the requirements for the first increment, but the future increments will not be fully planned at the start. As with incremental development, you deliver increments with increasing capabilities. NOTE: Your spirals should have well defined exit points – too often the spirals just keep on going and going and going – get caught in requirements creep Spiral Acquisition should be all about risk mitigation Unknown increment User, developer, tester, sustainer “use and learn” Time Based on AF Program Manager Workshop presented by Mr Little

Acquisition Method Method Req’ts Technology Schedule Comments Example
Single Step All known at start All Mature at start No need for early deployment Software requirements must also be stable New utility truck Evolutionary - Incremental Technology for first increment mature May be a need for early deployment Could have incremental software and single-step hardware Missile with improved range over 2-3 increments Evolutionary - Spiral Req’ts for first spiral known at start Technology for first spiral mature Spirals may also be for risk reduction – not deployment A communi-cation system with new interfaces yet to be defined STUDENT NOTES INSTRUCTOR NOTES: This is just another way to look at the differences in the acquisition strategies and development methods

Evolutionary Approach
B C CR TD SDD PD OS Increment 1 B C Increment 2 = Contractor Spiral Development B C STUDENT NOTES CR – Concept Refinement TD – Technology Development SDD – System Development and Demonstration PD – Production and Deployment OS – Operations and Support This comes from the DoD5000 web site – with the exception of the spirals. Each new increment is treated like a new program starting at milestone B. INSTRUCTOR NOTES: This comes from the DoD5000 web site, and provides a graphical view of the ACQUISITION PROCESS As far as I can tell – the only difference between SPIRAL ACQUISITION and INCREMENTAL ACQUISITION is whether or not you know all your program requirements at the beginning Lets not confuse ACQUISITION PROCESS with DEVELOPMENT PROCESS. • {Write on a flip chart:} Acquisition Strategy │ Development Strategy • this is to keep focus on the fact there are two separate issues animation – add contractor development process These spirals and bars represent the actual development process that might be carried out by your contactor As you can see, the ACQ method and the DEV’T method are not necessarily the same. You may need to reconcile software spirals with PDR / CDR types of reviews! = Contractor Incremental Development Increment 3 Adapted from dod5000.dau.mil

Evolutionary Approach (Space)
B C Pre KDP-A Phase A Study Phase Phase B Design Phase Phase C (Build, Test Launch) Increment 1 B C Increment 2 = Contractor Spiral Development B C STUDENT NOTES This comes from the NSS Space Acquisition Policy (small quantity acquisition) with the addition of the increments and spirals Each new increment may treated like a new program starting at milestone B for costs are over $150M. KDP – Key Decision Point ◊ - Review ∆ - Milestone INSTRUCTOR NOTES: Write on a flip chart: Acquisition Strategy │ Development Strategy – this is to keep focus on the fact there are two separate issues The main format comes from the NSS Space Acquisition Policy web site – we added the extra increments and the exception of the spirals. Each new increment is treated like a new program starting at milestone B – may need a new Defense Space Acquisition Board (DSAB) if >150M. For a production focused acquisition – such as terminals – Phase C – Build, Test, Deploy – is broken into two sub-phases – a System Demo sub-phase and a sub-phase for LRIP, IOT&E, FRP, FOT&E activities The Space Acquisition Regulation does discuss spiral acquisition, but doesn’t go into detail regarding spiral vs incremental In this slide, the spirals represent the actual development process that might be carried out by your contactor You may need to reconcile software spirals with PDR / CDR types of reviews! Acronyms: CR – Concept Refinement TD – Technology Development SDD – System Technology and Demonstration PD – Production and Deployment OS – Operations and Support = Contractor Incremental Development Increment 3 Adapted from NSS and dod5000.dau.mil

Acquisition & Development Methods
Single Step Acquisition, Contractor Incremental Development Acquisition of a New Utility truck Increment 1 – Hard to produce brakes Increment 2 – Easier to produce brakes Evolutionary Acquisition (Spiral), Contractor Mixed Development – Comms System Inc 1 – HW Upgrades Single Step Development Inc 2–SW radios for existing interfaces Increment 1- Interface 1 STUDENT NOTES The three development methods – single step (waterfall), incremental and spiral will be discussed in greater detail in the systems engineering module INSTRUCTOR NOTES: This shows some possible combinations between Acquisition methods and development methods BUILD – Incremental Acq #1 – Single Step Acquisition; Contractor – you know all the requirements up front, want 1 delivery; BUILD – Incremental Dev’t The Contractor decides to do incremental development • Initial production with brakes that are hard to produce • Later production with brakes that are easier to produce Now lets look at an Evolutionary / Spiral Acquisition BUILD – Spiral Acq #2 – Evolutionary Acq – Spiral – you don’t know all the requirements up front, but you do know the requirements for the first increment BUILD – Waterfall Dev’t The Contractor uses a single step (waterfall) development method for the first acquisition spiral The contractor uses incremental dev’t for the second acquisition spiral BUILD – Spiral Dev’t The Contractor uses spiral dev’t for the third acquisition spiral Spiral Dev’t will be discussed in greater detail in the systems engineering module. Increment 2- Interface 2 Inc 3 – Develop new interfaces Spiral 1 – Prototype 1 Spiral 2 – Prototype 2 = fielded system Spiral 3 – Prototype 3

Program Drivers What software and system issues might DRIVE your acquisition 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 (Programmatic and Developmental) System Complexity Precedented / Unprecedented Technology Maturity STUDENT NOTES Drivers are EXTERNAL influences that will impact your program risk INSTRUCTOR NOTES: These are only SOME of the Drivers your program may face. You need to identify and understand the Drivers on your program in order to help reduce the risk posed by the Drivers. There may also be interactions between the Drivers, for example, unstable requirements will influence overall cost. Next we’ll look at what we’ll do with these Drivers (Note: You DO NOT have to read all of these, pick a few that you feel are important) • Schedule – how does SW influence schedule – is it on the critical path? • Funding – What % of your program cost is SW – how confident are you in the sw cost estimates? • Requirements Stability – how stable are your SW RELATED requirements • If HW requirements are stable and SW are not – you may want to divide this into 2 drivers • External Interfaces – how many interfaces are SW related and how difficult are these? • Deployment – Does the system need different SW for different sites? • Technology Maturity – are the SW applications you are developing mature? • Staffing – do you have enough staff in the PMO with the proper SW experience? • Test Requirements – do you need a special environment to perform SW test? • User Support – are you users available and supportive of the sw development effort? • Security – what type of security does the SW have to provide? • Policy Mandates – does the SW have to follow DII COE (Defense Information Infrastructure Common Operating Environment )? • System Complexity – Is the SW development unprecedented? Funding – from Defense Science Board/AF Scientific Advisory Board Joint Task Force On Acquisition of National Security Space Programs - May 2003 – “The space acquisition system is strongly biased to produce unrealistically low cost estimates throughout the acquisition process. These estimates lead to unrealistic budgets and unexecutable programs.”

Dealing with Drivers Determine which present the highest risk exposure to your program Determine how the drivers will influence your acquisition strategy 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 STUDENT NOTES INSTRUCTOR NOTES: Once you have identified the Drivers that may impact your program, the next task is to determine which pose the highest risk. This is often a judgment call, but if you aren’t sure about the risk, it is best to continue to track the impact of that particular Driver. Next, we’ll briefly discuss the Drivers impact your acquisition strategy elements.

Drivers Example – Requirements Stability 1
REQUIREMENTS ARE: Well defined, stable Incomplete, volatile Acquisition Approach Could consider single step Would need to use evolutionary acquisition Requirements: Management Can baseline the system at the start of the program Must establish baseline for each increment Risk: Mitigation Risk mitigation still needed Robust risk mitigation with PMO oversight Design: Interoperability Should be able to produce stable ICDs Will need tight configuration control of ICDs Driver / Risk Exposure Strategy Element STUDENT NOTES ICD = Interface Control Document (or Drawing) These are things that the PM has to reason about in the context of his/her program You would need to determine where your program falls in this continuum INSTRUCTOR NOTES: Key Point: You need to determine how your drivers interact with your strategy elements. You would want to construct a chart like this for each driver Suggested Script: Remember – there are 2 different elements – DRIVERS (such as requirements stability) – which will impact your STRATEY ELEMENTS (such as Acquisition Approach and Staffing) You would want to do something like this for all your drivers so you can understand the impacts Walk through the chart Transition: The rest of the acquisition strategy elements are on the next chart

Drivers Example – Requirements Stability 2
REQUIREMENTS ARE: Well defined, stable Incomplete, volatile Business: Competition May be able to use sole source if applicable More competition provides more ideas Program Mgm’t: PMO Staffing Less staffing may be acceptable Will need staff to deal with requirements changes and spiral development Support: Source Depot could be used or CLS negotiated with development CLS may be needed until all increments fielded Driver / Risk Exposure Strategy Element STUDENT NOTES ICD = Interface Control Document (or Drawing) These are things that the PM has to reason about in the context of his/her program You would need to determine where your program falls in this continuum INSTRUCTOR NOTES: Key Point: You need to determine how your drivers interact with your strategy elements. You would want to construct a chart like this for each driver Suggested Script: Remember – there are 2 different elements – DRIVERS (such as requirements stability) – which will impact your STRATEY ELEMENTS (such as Acquisition Approach and Staffing) You would want to do something like this for all your drivers so you can understand the impacts Walk through the chart Transition: The rest of the acquisition strategy elements are on the next chart

Acquisition Strategy Development
CONFLICT Acquisition Strategy Development Due to the incomplete requirements, you would prefer an evolutionary acquisition. You prefer multiple solicitation phases, with competition. Due to the tight schedule, you want to limit the total number of solicitation phases. You also would prefer a single step acquisition. Due to the level of technology maturity, especially of the ability to track fired munitions, you will encourage competition, and prefer evolutionary acquisition. Because you know you have limited funding, you want to limit the number of parallel contracts over the life of the program. You would prefer well-defined development phases instead of a spiral development, and limited testing. Because you are deploying to multiple sites, you would at least start out with contractor logistic support (CLS). You would prefer single step acquisition. STUDENT NOTES This is one way to start to look at Drivers and how they might impact the acquisition strategy Note: If a single step acquisition is APPROPRIATE, it can take less time and cost less, BUT, if it is not appropriate, it will end up costing more and taking longer INSTRUCTOR NOTES: One way to look at the impact of Drivers on the acquisition strategy elements is to form a series of statements like the ones above. animation – incomplete requirements The first driver that we may look at is INCOMPLETE REQUIREMENTS. This drives us to think about strategies such as • Evolutionary Acquisition – to refine our requirements as we learn more • Multiple Solicitation Phases – to accomplish multiple fieldings of our product and gather user feedback to define future fieldings • Lots of competition – to maximize our input of new ideas animation – tight schedule The second driver that we may look at is TIGHT SCHEDULE. This drives us to think about strategies such as • Single Step Acquisition – to minimize the time to operations • Minimum Solicitation Phases – to minimize the time to operations animation – conflict Just with these two drivers, we have a conflict in our ACQUISITION METHOD strategy element animation – conflict 2 We also have a conflict with our Solicitation strategy element animation – driver animation – driver animation – driver As we add more drivers, the conflicts mount Next we’ll show you another method that once again makes use of the slider bar technique BACKUP May want to write on board something like: • Schedule --- limit solicitation single step • Req’ts -----Spiral ---Multiple solicitation ----competition • Multiple Sites ----CLS • etc. – and then circle the ones that are in opposition

How Do I Get To a Top-Level Strategy?
Look at your top 2-3 drivers Try to develop 2-3 strategies you think might work well for the risks posed by those drivers – you must consider the software risks! Consider: Number and timing of solicitations Number of contracts for each phase Sourcing – development or COTS Integration with other programs Any tailoring of phases Deployment and support strategies STUDENT NOTES COTS = Commercial Off The Shelf This example is looking at the Top Level Strategy – at the very beginning of the program – prior to Concept Development INSTRUCTOR NOTES: This is just an example. This course is not meant to teach you how to develop and acquisition strategy – this will show how software should influence this activity

Example Acquisition Strategy (Simplified)
Driver 1 - Incomplete Requirements Driver 2 - Schedule COMPETITION: Full and Open Downselect B A C SDD PD TD OS CR Increment 1 CLS Response: Use Evolutionary Acquisition Full and Open Competition Multiple contracts for CR Limit solicitation phases – downselect after CR Use two Increments only Use CLS Increment 2 B C STUDENT NOTES CLS = Contractor Logistic Support CR – Concept Refinement TD – Technology Development SDD – System Development and Demonstration PD – Production and Deployment OS – Operations and Support CLS – Contractor Logistics Support COTS – Commercial Off The Shelf ∆ - Milestone ◊ - Review In general – you would formulate more than 1 strategy and compare and contrast them to help develop the best strategy INSTRUCTOR NOTES: We will be using three simple strategies to look at how we can use slider bars to help develop our acquisition strategy For this strategy you will have 1 solicitation phase – one contractor will be selected to perform Concept Refinement, Technology Development, System Design and Development and on through production operations and support. You will encourage spiral development and will use a spiral acquisition with at least two deliverable increments There may be more than one increment B C Increment 3

You are here…. Middle of Concept Refinement
Both contractors have uncovered more requirements challenges than expected – software requirements are unstable May not meet PMO exit criteria for requirements stability at end of Concept Refinement phase Lab efforts on technology to support tracking fired ammunition are not progressing as fast as hoped; communications software is challenging Schedule requirement is still tight Funding is still minimally acceptable What might you do to refine your acquisition strategy? STUDENT NOTES

B A C SDD PD TD OS CR Increment 1 COMPETITION: Full and Open Downselect CLS Response: Change to a full and open competition at the start of TD Let 2 contracts for TD to continue requirements definition with downselect at SDD Let 2-3 Small Business Innovative Research and Development contracts for technology development Continue with 2 increments and CLS Increment 2 B C STUDENT NOTES CLS = Contractor Logistic Support CR – Concept Refinement TD – Technology Development SDD – System Development and Demonstration PD – Production and Deployment OS – Operations and Support CLS – Contractor Logistics Support COTS – Commercial Off The Shelf ∆ - Milestone ◊ - Review In general – you would formulate more than 1 strategy and compare and contrast them to help develop the best strategy INSTRUCTOR NOTES: We will be using three simple strategies to look at how we can use slider bars to help develop our acquisition strategy For this strategy you will have 1 solicitation phase – one contractor will be selected to perform Concept Refinement, Technology Development, System Design and Development and on through production operations and support. You will encourage spiral development and will use a spiral acquisition with at least two deliverable increments There may be more than one increment Impact May need to deal with schedule increase Will reduce funds for SDD and PD Should increase requirements stability Should increase technology maturity

You are here…. Middle of Technology Definition
Technology development phase is going well Requirements are becoming more stable SBIR contracts are developing good ideas, but technology may not be ready for second increment Clear that the software architecture will be of critical importance Schedule requirement is still tight Funding is still minimally acceptable What might you do to refine your acquisition strategy? STUDENT NOTES SBIR = Small Business Innovative Research

B A C SDD PD TD OS CR Increment 1 COMPETITION: Full and Open Downselect CLS Response: Continue with downselect at SDD Continue with 1 SBIR contract Include Architecture Evaluation early in SDD Add third increment to allow immature technology to mature before later insertion Increment 2 B C STUDENT NOTES CLS = Contractor Logistic Support CR – Concept Refinement TD – Technology Development SDD – System Development and Demonstration PD – Production and Deployment OS – Operations and Support CLS – Contractor Logistics Support COTS – Commercial Off The Shelf ∆ - Milestone ◊ - Review In general – you would formulate more than 1 strategy and compare and contrast them to help develop the best strategy INSTRUCTOR NOTES: We will be using three simple strategies to look at how we can use slider bars to help develop our acquisition strategy For this strategy you will have 1 solicitation phase – one contractor will be selected to perform Concept Refinement, Technology Development, System Design and Development and on through production operations and support. You will encourage spiral development and will use a spiral acquisition with at least two deliverable increments There may be more than one increment B C Increment 3

Acquisition Strategy – Final Thoughts
You should develop more than one strategy early on – compare them keeping in mind progam risks You should evaluate your strategies against your drivers and important acquisition elements Should be a TEAM effort – need experts in systems, software, contracts, etc. This is HARD WORK – especially in software intensive systems! STUDENT NOTES INSTRUCTOR NOTES: We aren’t going to show you how to evaluate the strategies against the drivers – but you would at least want to look at all your important drivers and strategy elements and determine where your high risk areas are Unbounded Optimism is NOT an acquisition strategy

Acquisition Plan Contents
Acquisition background and objectives Statement of need Applicable conditions Cost Capability or performance Risks Trade-offs Delivery or performance-period requirements Plan of action (sample) Sources Competition Source-selection procedures Acquisition considerations Budgeting and funding Government-furnished property Make or buy Inherently governmental functions Test and evaluation Logistics considerations Security considerations Contractor versus Government performance STUDENT NOTES This is from the Federal Acquisition Regulation (FAR) Contents of written acquisition plans INSTRUCTOR NOTES: Statement of Need: Summarize the technical and contractual history of the acquisition – be sure to include any pertinent SW specifics Applicable Conditions: State all significant conditions affecting the acquisition, such as- • Requirements for compatibility with existing or future systems or programs; and • Any known cost, schedule, and capability or performance constraints. Cost: Include Life-cycle costs, design to cost, should cost analysis – be sure to include software related design, maintenance and support costs Capability or Performance: Specify the performance characteristics of the supplies or the performance standards of the services being acquired and how they are related to the need Delivery or performance period requirements: Describe the basis for establishing delivery or performance-period requirements - Including SW performance requirements; Provide reasons for any urgency if it results in concurrency of development and production or for not providing for full and open competition Trade-offs: Expected consequences of trade-offs among the various cost, capability or performance, and schedule goals – Include SW related trades Risks: Technical, cost, and schedule risks and efforts are to reduce risk and the consequences of failure to achieve goals – Include SW Risks Acquisition Streamlining: Industry participation by using draft solicitations; timeframe for identifying those specifications and standards, that will be mandatory Sources: Possible sources of supplies/ services to meet the need – Consider SW needs Competition: how competition will be sought, promoted, sustained – SW should influence this Source Selection Procedures: Timing for submission & eval of proposals; relationship of evaluation factors to the attainment of the acquisition objectives Acquisition Considerations: contract type selection; multiyear contracting, options, or other special contracting methods; Rationale if a performance-based contract will not be used Budgeting and funding: Include budget estimates, explain how they were derived, and discuss the schedule for obtaining adequate funds at the time they are required Contractor vs. Gov’t Perf: A 76 Related – will this be competed to government facilities (mainly depot related) Inherently governmental functions – OFPP Policy Letter activities that require either the exercise of discretion in applying Government authority or the making of value judgments in making decisions for the Government ; After award, agencies must play an active, informed role in contract administration to ensure contractors comply with the terms of the contract Test and Evaluation: describe the test program of the contractor and the Government – Include SW test Logistics Consideration: Assumptions determining contractor or organic support; reliability, maintainability, and quality assurance requirements, including any planned use of warranties; requirements for contractor data including data rights; Standardization concepts – SW plays a large role in all of these! Security Considerations: For acquisitions dealing with classified matters, discuss how adequate security will be established, maintained, and monitored – Including SW GFP: Indicate any property to be furnished to contractors – including SW provided to the contractor

Project Planning CMMI-AM Goals and Practices 1
Specific Goal Specific Practice Establish Estimates 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 Plan Obtain Commitment to the Plan Review Plans that Affect the Project Reconcile Work and Resource Levels Obtain Plan Commitment STUDENT NOTES

Project Planning Goal 1: Establish Estimates 1
Estimates of project planning parameters are established and maintained Establish a top-level WBS1 to estimate the scope of the project 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, # of interfaces, data volume, etc. STUDENT NOTES 1 See MIL-HDBK-881A ( )

Project Planning Goal 1: Establish Estimates 2
Define the project life-cycle phases upon which to scope the planning 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 products and tasks based on estimation rationale Define estimation rationale Estimate cost and effort for each work product and task Consider independent review of estimates STUDENT NOTES

Project Planning Goal 2: Develop a Project Plan 1
A project plan is established and maintained as the basis for managing the project Establish and maintain the project’s 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 mgm’t Define data content and formats Establish requirements for security and information assurance STUDENT NOTES

Plan 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 the project Identify skills needed Assess available skills Develop a plan to fill the gaps STUDENT NOTES

Plan 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 STUDENT NOTES

Project Monitoring and Control 1
The purpose of project monitoring and control is to provide understanding into the project’s progress so that appropriate corrective actions can be taken when the project’s performance deviates significantly from the plan. STUDENT NOTES

Project Monitoring and Control 2
For Acquisition, monitoring and control functions are directed within the acquisition project early in the process as the acquisition planning is performed and the strategy is defined. As the acquisition process enfolds, monitoring and control are essential to ensuring that appropriate resources are being applied and that the internal acquisition activities are progressing according to plan. Once a supplier is selected and an award is made, the role of monitoring and control becomes two fold, concerned with both continuing to monitor and control internally while also monitoring and controlling the progress of the supplier’s execution under the supplier’s project plan. STUDENT NOTES

Poor Project Monitoring and Control…
Symptoms Lots of time is 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 aren’t identified until it’s too late Why should we care? 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 it STUDENT NOTES

Project Monitoring and Control CMMI-AM Goals and Practices
Specific Goal Specific Practice Monitor Project Against Plan Monitor Project Planning Parameters Monitor Commitments Monitor Project Risks Monitor Data Management Monitor Stakeholder Involvement Conduct Progress Reviews Conduct Milestone Reviews Manage Corrective Action to Closure Analyze Issues Take Corrective Action Manage Corrective Action STUDENT NOTES

Project Monitoring and Control Goal 1: Monitor Planning Parameters 1
Actual performance and progress of the project are monitored against the project plan Monitor the actual values of the project planning parameters against the project plan Progress against schedule Cost and expended effort Attributes of work products and tasks Resources provided and used Monitor commitments against those identified in the project plan Periodic and documented review of commitments (e.g. outstanding purchase orders) STUDENT NOTES

Project Monitoring and Control Goal 1: Monitor Planning Parameters 2
Monitor risks against those identified in the project plan Monitor the management of project data against the project plan Monitor stakeholder involvement against the project plan Periodically review the project’s progress, performance, and issues Review the accomplishment and results of the project at selected project milestones STUDENT NOTES

Project Monitoring and Control Goal 2: Manage Corrective Action
Corrective actions are managed to closure when the project’s performance or results deviate significantly from the plan Collect and analyze the issues and determine the corrective actions necessary to address the issues Acquirer’s issues and corrective actions are managed independently of the suppliers’ Define schedule and responsibility for corrective actions Maintain documentation of issues and actions Take corrective action on identified issues Monitor corrective action schedule and effectiveness Manage corrective actions to closure Document resolution of issue STUDENT NOTES

Solicitation and Contract Monitoring
The purpose of Solicitation and Contract Monitoring is to prepare a solicitation package that identifies the needs of a particular acquisition, to select a supplier who is best capable of satisfying those needs, and to establish the process for monitoring the supplier for the duration of the contract. For Acquisition, the solicitation must comply with the applicable federal, departmental, and service acquisition regulations and policies. The solicitation should address issues appropriate to the product domain or acquisition environment (e.g., supplier process evaluations, operational safety suitability and effectiveness, certifications, architecture evaluations, and interoperability). The representatives responsible for these activities within the project or stakeholder organizations should be consulted for proper inclusion of those activities into the solicitation and contract monitoring process. STUDENT NOTES

Poor Solicitation and Contract Monitoring…
Symptoms The solicitation package does not include the agreement/ contractual requirements and proposal evaluation criteria The technical and management elements of proposals are not properly evaluated to ensure that the requirements of the agreement/contract will be satisfied The selection official will not select suppliers who are qualified to satisfy the agreement/contract’s requirements for the project’s products Why Do We Care? The project team will have insufficient insight into the supplier’s activities to ensure the effort is managed, controlled, and complies with contract requirements The project team and supplier team will be unable to maintain ongoing communication and commitments STUDENT NOTES

Solicitation and Contract Monitoring CMMI-AM Goals and Practices
Specific Goal Specific Practice Prepare for the Solicitation 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 Suppliers Award Contracts Establish an Understanding of the Contract and Proposed Approach Establish Communications Processes and Procedures Coordinate Work with Suppliers Monitor Selected Supplier Processes Evaluate Selected Supplier Work Products Revise the Supplier Agreement or Relationship STUDENT NOTES

The project is prepared to conduct the solicitation
Solicitation and Contract Monitoring Goal 1: Prepare for the Solicitation 1 The project is prepared to conduct the solicitation Designate a selection official responsible for making the selection decision Establish and maintain a solicitation package that includes the needs of the acquisition and corresponding proposal evaluation 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 process metrics) Appropriate plans (e.g., Integrated Mgm’t Plan, Software Development Plan, risk Management Plan) STUDENT NOTES

Solicitation and Contract Monitoring Goal 1: Prepare for the Solicitation 2
Establish and maintain independently reviewed cost and schedule 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 and potential offerors to ensure the approach and cost and schedule 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 offer clarifications of ambiguous capabilities. In a sole source or change order environment, ensure that relevant stakeholders recognize the consequences of proposed changes STUDENT NOTES

Solicitation and Contract Monitoring Goal 2: Select Supplier
Suppliers are selected based on the solicitation package Evaluate proposals according to the documented evaluation criteria 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 STUDENT NOTES

Solicitation and Contract Monitoring Goal 3: Award Contracts 1
Contracts are issued based on the needs of the acquisition and the suppliers’ proposed approaches Establish and maintain a mutual understanding of the contract with selected suppliers and end users based on the acquisition needs and the suppliers’ proposed approaches Ensure that contractual commitments are made for factors critical to project success (e.g., process execution, metrics collection and reporting) Maintain mutual understanding for the duration of the contract STUDENT NOTES

Solicitation and Contract Monitoring Goal 3: Award Contracts 2
Establish and maintain communication processes and procedures 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 STUDENT NOTES

Solicitation and Contract Monitoring Goal 4: Coordinate Work 1
Work is coordinated with suppliers to ensure the contract is executed properly Monitor and evaluate selected processes used by the supplier based on the supplier’s documented processes Adherence to plan Timeliness of deployment Effectiveness of process Evaluate selected supplier work products based on documented evaluation criteria Define work products to be evaluated (may include interime products) and evaluation criteria Ensure capacity and capability for timely and accurate evaluation STUDENT NOTES

Solicitation and Contract Monitoring Goal 4: Coordinate Work 2
Revise the supplier agreement or relationship, as appropriate, to reflect changes in conditions Address shortfalls in both products and processes Offer relief when needs evolve to invalidate process requirements, documentation requirements, reporting requirements, etc. STUDENT NOTES

Integrated Project Management
For Acquisition, integrated project management involves establishing project management processes consistent with and tailored from the organizations standard processes. This includes higher level acquisition guidance, regulations, instructions, as well as local practices established to be used across various projects in the local organization. Establishing an integrated project management process incorporating and involving all stakeholders (executive level acquisition offices, users, test organizations, developers, and associated government support organizations) is critical to the successful development of the project. Formal interfaces among project stakeholders take the form of memorandums of understanding (MOUs), memorandums of agreements (MOAs), contractual commitments, associate contractor agreements and similar documents depending on the nature of the interfaces and involved stakeholders. STUDENT NOTES

Poor Integrated Project Mgm’t …
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 doesn’t follow the plans, what does it follow? Uninvolved stakeholders can provide last-minute surprises Lessons learned are not captured STUDENT NOTES

Integrated Project Management CMMI-AM Goals and Practices
Specific Goal Specific Practice Use the Project’s Defined Process Establish the Project’s Defined Process Use Organizational Process Assets for Planning Project Activities Integrate Plans Manage the Project Using the Integrated Plans Contribute to the Organizational Process Assets Coordinate and Collaborate with Relevant Stakeholders Manage Stakeholder Involvement Manage Dependencies Resolve Coordination Issues STUDENT NOTES

Integrated Project Management Goal 1: Use the Defined Processes 1
The project is conducted using a defined process that is tailored from the organization’s set of standard processes Establish and maintain the projects defined process Based upon DoD Acquisition Framework ( and other inputs from the Service or Component Use the organizational process assets and measurement repository for estimating and planning the project’s activities Use processes that have been effective on prior projects Base your estimates upon prior actuals, not prior estimates Integrate the project plan and other plans that affect the project to describe the project’s defined process The project plan is not an overlay, it is THE WAY you execute the project STUDENT NOTES

Integrated Project Management Goal 1: Use the Defined Processes 2
Manage the project using the project plan, and other plans that affect the project, and the project’s defined process Plan your work and work your plan Contribute work products, measures, and documented experiences to the organizational process assets Helpful for the next project STUDENT NOTES

Integrated Project Management Goal 2: Coordinate & Collaborate
Coordination and collaboration of the project with relevant stakeholders are conducted Manage the involvement of the relevant stakeholders in the project Encourage stakeholder involvement Participate with relevant stakeholders to identify, negotiate, and track critical dependencies Identify critical activities dependent upon stakeholder involvement Negotiate stakeholder involvement Obtain commitments Resolve issue with relevant stakeholders Document resolution STUDENT NOTES

Risk Management 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. For Acquisition, risk identification and estimation of probability of occurrence and impact, particularly for those risks involved in meeting performance requirements, schedules, and cost targets, largely determines the acquisition strategy. The acquirer has a dual role, first in assessing and managing overall project risks for the duration of the project, and second, in assessing and managing risks associated with the performance of the supplier. As the acquisition progresses to the selection of a supplier, the risk specific to the supplier’s technical and management approach becomes important to the success of the acquisition. STUDENT NOTES

Poor Risk Management … Symptoms Why should we care?
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 STUDENT NOTES

What Makes Software-Intensive System Acquisition “Riskier”?
Computer software and hardware technology is evolving faster than any other Few program managers — the key decision-makers — have in-depth understanding of software technology Software project management, particularly task duration and effort estimation, is still immature Reuse has potential benefits but also potentially complicates the development process Software misconceptions: “you can fix any design shortfalls in software” and “software is free” STUDENT NOTES INSTRUCTOR NOTES: Key Point • software adds a new set of risks to a project Suggested Script: • Computer software and hardware technology continues to evolving quickly • User expectations can develop faster than the design • Software systems are complex just because they can be • Few PMs have in-depth understanding of software technology • This is not surprising. Many PMs come from a hardware background • Software project management remains immature • You remember that we discussed this in the Introduction • Reuse can save time and cost, but also complicates development efforts • COTS & GOTS particularly • Complicates the development process -e.g., bugs, documentation, long-term support • You can fix any design shortfalls in software” and “Software is free” • Maybe you can fix it in the software. Maybe you can’t. In either case, it won’t be free. Transition • So what do we do about software risk?

RSKM Principles Defining principles Sustaining Principles
Forward-looking view Shared product vision Global Perspective Sustaining Principles  Integrated Management  Teamwork  Continuous Process FORWARD- LOOKING VIEW Continuous Process Integrated Management Open Communication STUDENT NOTES INSTRUCTOR NOTES: Key Point • A Continuous Risk Management process is needed Suggested Script: • Listing Risks is not enough. Risks must be managed. • A Continuous Risk Management Process (CRM) provides a disciplined environment for proactive decision-making to: • Assess continuously what could go wrong • Determine which risks are important to deal with • Implement strategies to deal with those risks • The benefits of a CRM program: • Prevents problems before they occur • Improves product quality • Enables better use of resources • Promotes teamwork • Principles of CRM • Three principles define how a project sees and manages risk • Forward-looking view – looks past today’s crisis to prevent tomorrow’s. • Shared product vision – develops a common understanding of the objectives of the project, and focuses on results-oriented approach to achieve those objectives • Global perspective – pushes team members to look beyond their parochial interests to address the issues that are most important TO THE PROJECT. • Three principles define how a project sustains a CRM process • Integrated management – CRM should not be an auxiliary task performed to meet someone else’s expectations. It should integrated into the project management and decision-making process, and should be a way of life for the project • Teamwork – Risk management is a team sport. Cooperation and communication throughout the project team are essential • Continuous Process – CRM cannot be allowed to become “Shelfware”. There is NO specific time in a project when risk management is performed. It starts when the project starts, and ends when the project ends. Transition • So how does CRM work? SHARED PRODUCT VISION Teamwork GLOBAL PERSPECTIVE

Widely disseminate data and feedback
RSKM Paradigm Control Track Plan Analyze Identify Communicate Identify – Look for risks BEFORE they become problems Analyze – Extract decision- making information Plan – Translate into decisions and mitigating actions Track – Monitor risk indicators and mitigation plans Control – Correct deviations from mitigation plans 1 STUDENT NOTES Identify - Generate statements of risk and context Analyze - Determine the attributes (i.e., impact, probability, timeframe), classification, and priority of each risk Plan - Decide who “owns” the risk. Decide what we can do about it. Plan our mitigation strategy Tracking - acquire data about the status of the risk and the risk mitigation plans, compile it into meaningful results, and report on the status and progress of the risk management. Control -analyze the reported data to identify deviations from plans, decide on actions to be taken, and execute the plans Communicate – ensure the project personnel understand the risks, mitigation strategies, decision processes, and constraints References Dorofee, Walker, Alberts, Higuera, Murphy, & Williams; Continuous Risk Management Guidebook. Pittsburgh, PA: Software Engineering Institute, 1996 SEI Continuous Risk Management Course INSTRUCTOR NOTES: Key Point • Continuous Risk Management Process Suggested Script • The SEI Continuous Risk Management process is a cycle of five steps animation – Identify • In the Identify phase we capture a statement of risk and its context • Risks and context may be captured using methods such as • Brainstorming • Periodic risk reporting • Project profile questions • Risk forms • Taxonomy-based questionnaires (TBQ) • TBQ interviews • Voluntary risk reporting animation – Analyze • In the Analysis phase we determine the attributes, classification, and priority of each risk • Risks attributes include • Impact • Probability • Timeframe • Risk exposure (RE) = Probability x Impact • Risks may be classified to create a set of interrelated risks • May provide a different perspective • Commonly classified by • RISK SOURCE – Shows major sources of project risk • RISK IMPACT – Shows major effects of project risk • Risks are prioritized based upon project needs animation – Plan • In the Plan phase, we develop actions to mitigate the risk. • We decide who “owns” the risk. Possible dispositions include: • Keep it – if its your responsibility to deal with it • Delegate it – if responsibility is not yours, but remains within your organization • Transfer it – if responsibility lies outside of your organization • We decide what we can do about it • Research it – if you don’t know enough about it • Accept it – if you can live with it • Mitigate it – if you can’t live with it, and can act on it • Watch it – if you can’t live with it, and can’t act on it • We plan our mitigation strategy animation – Track • In the Tracking phase, • we Acquire data about the status of the risk and the risk mitigation plans • we Compile the data into meaningful results • we Report on the status and progress of the risk management. • In the Control phase, we review the reported data to identify deviations from plan, decide on corrective actions, and execute them Transition • Lets look at a RISK STATEMENT Communicate! Widely disseminate data and feedback 1 Van Scoy, Software Development Risk: Opportunity, Not Problem. SEI, 1992

The SEI “Risk Statement”
A “standard” format for risk statements provides: Clarity Consistency A basis for future risk processing Context Source Condition Consequence Risk Statement STUDENT NOTES INSTRUCTOR NOTES Key Point • Definition of a RISK STATEMENT Suggested Script • The first step is to identify the risk with a RISK STATEMENT animation – Characteristics • Characteristics of a risk statement • Clarity • Consistency • A basis for future processing animation – CONDITION • Starts with a statement of the initial condition • Specific • Based upon fact, not conjecture animation - CONSEQUENCE • Continues with the consequences of the occurrence animation – RISK STATEMENT • This constitutes the basic RISK STATEMENT animation - CONTEXT • Sometimes the brief risk statement cannot convey an unambiguous understanding of the risk. Often, additional descriptive information is needed to place the risk in CONTEXT. To ensure clarity, a CONTEXT statement is added to capture additional information regarding the circumstances, events, and interrelationships in the project that may affect the risk. • A good CONTEXT statement captures the WHAT, WHERE, HOW, and WHY of the risk animation – SOURCE • It may be possible to identify the root-cause of the risk. Identifying this SOURCE enables you to see relationships between risks arising from common sources, and may give you a “soft-spot” to attack with your risk management plans. animation – RISK ATTRIBUTES • The resulting risk statement is fact-based, actionable, and brief Transition •Lets look at some examples BACKUP Example: Condition: there is water on the floor Consequence: someone could slip and fall Context: this occurs every time it rains. The water is in a high traffic area of the hallway. The hallway is a tile floor, not carpeted. Source: Roof leak ? Water is being tracked in by pedestrians ? NOTE: Based upon an investigation of the SOURCE, different mitigation strategies could be developed; e.g. roof leak >> place bucket >> fix roof tracked in >> install absorbent mat at door A good risk statement is: Fact-based Actionable Brief

Sample Risk Statements
Good example: This module must be coded in Java, but we don’t have enough Java programmers; the module may not be completed on time Bad example: Unclear requirements may increase costs Not a fact-based condition Not specific Not actionable Condition Consequence STUDENT NOTES

Risk Management CMMI-AM Goals and Practices
Specific Goal Specific Practice Prepare for Risk Management Determine Risk Sources and Categories Define Risk Parameters Establish a Risk Management Strategy Identify and Analyze Risks Identify Risks Evaluate, Categorize, and Prioritize Risks Mitigate Risks Develop Risk Mitigation Plans Implement Risk Mitigation Plans STUDENT NOTES

Risk Management Goal 1: Prepare for Risk Management
Preparation for risk management is conducted Determine risk sources and categories Risk sources and categories may include Uncertain requirements - Unprecedented efforts Unfeasible design - Schedule / cost constraints Technology immaturity - Staffing and skill issues Define the parameters used to analyze and categorize risks and the parameters used to control the risk management effort Probability of occurrence (e.g., 5-level, High/Medium/Low) Impact (e.g., 5-level, Catastrophic/Critical/Marginal/Negligible) Timeframe (e.g., Near/Midterm/Far, 30/90/360 days) Management Action Threshold Establish and maintain the strategy to be used for risk management STUDENT NOTES

Risk Management Goal 2: Identify and Analyze Risks
Risks are identified and analyzed to determine their relative importance Identify and document risks Typical risk identification methods include Brainstorming - Periodic risk reporting TBQ1 questionnaire - TBQ interview Voluntary risk reporting Evaluate and categorize each identified risk using the defined risk categories and parameters, and determine its relative priority Analyze probability of occurrence, impact, timeframe Prioritize Comparison risk ranking - Multi-voting Pareto Top N STUDENT NOTES 1 Taxonomy-based questionnaire, available at

Risk Management Goal 3: Mitigate Risks
Risks are handled and mitigated, where appropriate, to reduce adverse impacts on achieving objectives Develop a risk mitigation plan for the most important risks to the project, as defined by the risk management strategy Disposition ALL identified risks “Keep”, “Delegate”, or “Transfer” it “Research”, “Accept”, “Mitigate”, or “Watch” it Monitor the status of each risk periodically and implement the risk mitigation plan as appropriate Continuously monitor status of both risk and mitigation plan Maintain risk database Identify new risks, close invalid risks Use Risk Management as a means of controlling your project STUDENT NOTES

Acquisition Risk Management 1
What Can Acquisition Program Offices Do? — A Few Ideas Start a risk management program on Day 1 of the program Ensure that PMO staff have appropriate risk management training Use multiple methods to identify risk sources: Periodic risk reporting - Brainstorming Voluntary risk reporting - Risk report forms Taxonomy-based questionnaire (TBQ) - TBQ interviews STUDENT NOTES

Acquisition Risk Management 2
What Can Acquisition Program Offices Do? — A Few Ideas Add language to RFPs and contracts that specify how risks are to be reported to the PMO Encourage decentralization of risk identification and analysis following an organizationally defined process Establish and maintain a schedule of joint risk reviews with all contractors throughout the program, including joint prioritization of the most important risks to the program Find ways to reward contractors for early identification of issues and risks Define a process and criteria for escalating risks to the next higher level STUDENT NOTES

Summary 1 PM roles include PMO management, project management, supplier oversight, indirect subcontractor oversight, and process integration CMMI-AM is a tool intended to help the acquirer achieve success Development of a suitable acquisition strategy is a key component of project planning Principal goals of Project Planning Establish estimates Develop a project plan Obtain commitment to the plan Principal goals of Project Monitoring and Control Monitor Project Against Plan Manage Corrective Action to Closure STUDENT NOTES

Summary 2 Principal goals of Solicitation and Contract Monitoring
Prepare for the Solicitation Select Suppliers Award Contracts Coordinate Work with Suppliers Principal goals of Integrated Project Management Use the Project’s Defined Process Coordinate and Collaborate with Relevant Stakeholders Principal goals of Risk Management Prepare for Risk Management Identify and Analyze Risks Mitigate Risks STUDENT NOTES

Introduction to the CMMI® Acquisition Module (CMMI-AM)

Similar presentations

Presentation on theme: "Introduction to the CMMI® Acquisition Module (CMMI-AM)"— Presentation transcript:

Similar presentations

About project

Feedback

Log in

Auth with social network:

Introduction to the CMMI® Acquisition Module (CMMI-AM)

Similar presentations

Presentation on theme: "Introduction to the CMMI® Acquisition Module (CMMI-AM)"— Presentation transcript:

Similar presentations

About project

Feedback