Project Management

1. ProjectManagement Draft: 24 October 2012

2. Expectations This course is designed to introduce how Program and Project Managers conduct business under the BES Directorate Systems Engineering Process (SEP) This course will not teach you everything you need to know to be an effective Program/Project Manager This course does not replace structured DAU course studies in the Program Management or Systems Engineering disciplines

3. Training Objectives Define Program and Project Management Review Key Elements of the Systems Engineering Process (SEP) Describe Key Project Management Functions Describe Common Post Implementation Actions

4. Introductions • Please tell the class about yourself… • Name • Program or Project Assignment? • Assigned Role? • What do you hope to learn from this class?

5. What is a Program? Program Defined: A group of related projects (more than one) managed in a coordinated way to obtain benefits and control not available from managing them individually. The intent is to improve organizational performance. Program Management is the application of knowledge, skills and techniques to manage a group of related projects effectively and efficiently. It typically involves the need to identify and manage cross-project dependencies like risks, issues, requirements, design, integration, implementation, and/or customer support.

6. What is a Project? Project Defined: A project is a temporary group activity designed to produce a unique product, service or result. A project is temporary in that it has a defined beginning and end in time, and therefore defined scope and resources. For example, the development of software releases are projects, not programs. Each must be expertly managed to deliver the right functionality (performance), on-time, and within budget. Project Management is the application of knowledge, skills and techniques to execute projects effectively and efficiently. In the SEP, we tend to use Project Management (Manager) and Program Management (Manager) interchangeably – but they are different. This training will focus on PROJECT Management.

7. What is the SEP? • Role-based technical and managerial frameworks for applying methods, tools, and people to the acquisition, development, and sustainment of information technology programs/projects • Step-by-step procedural guidance at the global, phase, and work product levels; includes comprehensive entry and exit criteria • Built-in systems engineering to reduce risk and avoid potential programmatic shortfalls • Tailorable to accommodate the unique characteristics of individual programs • A resource that provides guides, forms, templates, procedures, reference materials, and checklists to assist program teams in every step of acquisition lifecycle management

8. Where is the SEP?https://acc.dau.mil/BES Open to .mil & .com users "Supporting the BES Program Executive Office within the Air Force Life Cycle Management Center" Login Not Required!

9. SEP Foundation • DOD, AF, MAJCOM and other HHQ publications • DODI 5000.02 • AFI 63-1201 and Supplements, 63-101 and Supplements • Defense Acquisition Guidebook • Process area AFIs and T.O.s (PM, T&E, ORM, Requirements, etc.) • Business Capability Lifecycle (BCL) Interim Guidance Memo • Public Law (e.g., NDAA, Clinger-Cohen Act) • IEEE and Military Standards • SEI’s Capability Maturity Model Integration® (CMMI®) • Best Commercial Practices • Lessons Learned

10. Capability Maturity Model Integration® (CMMI®) • Product of the Software Engineering Institute (SEI) • A Federally Funded Research and Development Center (FFRDC) • CMMI® is based on: • Documented, repeatable processes • Process measurements which assist in decision-making • Disciplined organizational behaviors • CMMI® is focused on: • Systems/Software Engineering • Repeatable, measurable processes • Integrated Product and Process Development • Supplier Sourcing

11. CMMI® Substance • Levels of capability maturity coincide with levels of process definition, measurement, and decision-making criteria • Focuses on elements of essential best practices and processes from various bodies of knowledge • Not a radical new approach—they describe common sense, efficient, proven ways of doing business • Presents a minimum set of recommended practices and leverage points proven to enhance organizational maturity and project capability • Defines the expectation (“what”)… • …without overly constraining implementation (“how”)

12. SEP Roles • Each member of your team should have at least one SEP role • SEP refers to specific roles when describing who implements procedures and steps • Specific training is suggested for each role • Use ETMS to record training requirements (may also use Individual Development Plan (IDPs)) • Each role has associated responsibilities documented in all SEP procedures • Roles include Program Manager, Configuration Manager, Requirements Manager, Functional Analyst, Developer, Lead Engineer etc. SEP Reference: SEP Roles and Project Organization Guide (SWGD035)

13. Process Discussion • What is a process? • … a series of actions or operations leading to a particular end • Why do we need a process for software acquisition and program management? • It is estimated that approximately 20% of projects are completed on time/within budget – with the “right” functionality • Why does it seem so difficult for our organization to employ a process? • Needless activity; no value? • Costs too much? • Takes too much time? • Lack of understanding?

14. Benefits of a Standardized Process • Provides project teams a structured process that supports delivery of mission-ready and sustainable products • Assists in satisfying customer and user requirements • Delivers repeatable processes • Provides the structure and rigor to satisfy AF SEAM requirements • Helps reduce program/project risk • Guides teams through DoD, AF, AFMC, Center and statutory directives, instructions and life cycle policies; centralized location for current policy, guidance, and governance • Ensures verification and validation of product(s); higher quality project documentation/artifacts – better deliverables • Provide a mechanism to capture organizational experience to make program/project teams more effective (Lessons Learned)

15. SEP Process Areas (Global Disciplines)

16. SEP Process Areas(Global Disciplines) • Configuration Management • Decision Analysis and Resolution • Measurement and Analysis • Organizational Process Definition • Process/Product Quality Assurance • Project Monitoring and Control • Requirements Development • Requirements Management • Risk Management • Supplier Agreement Management • Training • Verification and Validation PEO Capability Delivery Support Policy Process Artifacts Systems Engineering Process Performed regularly throughout the lifecycle of the program –event driven, not schedule driven

17. Configuration Management • SEP Configuration Management • Purpose: To establish and maintain integrity of work products using configuration identification, configuration control, configuration status accounting, and configuration audits • Goals: • Establish Baselines • Identify Configuration Items (CIs) • Establish CM System • Create or Release Baselines • Track and Control Changes • Track Change Requests and Control CIs • Establish Integrity • Establish CM Records • Perform Configuration Audits SEP Reference: Configuration Management Process Area

18. Decision Analysis and Resolution • Purpose: To analyze possible decisions using a formal process that evaluates identified alternatives against established or derived criteria • Goal: • Evaluate alternatives • Establish guidelines for decision analysis • Establish evaluation criteria • Identify alternative solutions • Select evaluation methods • Eliminate inferior alternatives • Select solutions SEP Reference: Decision Analysis and Resolution Procedure (DAPR001)

19. Measurement and Analysis • Purpose: To develop and sustain a measurement capability that is used to support project and system performance information needs • Goals: • Align M&A Activities • Establish Organizational Measurement Objectives • Specify Measures • Specify Data Collection and Storage • Specify Analysis Procedures • Provide Measurement Results • Collect Measurement Data • Analyze Measurement Data • Store Data and Results • Communicate Results SEP Reference: Measurement and Analysis Procedure (MAPR001)

20. Organizational ProcessDefinition • Purpose: To establish and maintain a usable set of organizational process assets and work environment; primary process area for SEP maintenance • Goal: Establish Organizational Process Assets • Establish standard processes • Establish lifecycle model descriptions • Establish tailoring guidelines • Establish organization’s measurement repository • Establish organization’s process asset library (our SEP) • Establish work environment standards SEP Reference: Organizational Process Definition Process Area

21. Process & Product Quality Assurance • Purpose: To provide staff and management objective insight into processes and associated work products • Goals • Objectively evaluate: • Processes for effectiveness and efficiency • Work products and services to satisfy needs • Provide objective insight • Ensure resolution of nonconformance/noncompliance issues • Establish and maintain records • Conduct trend analysis SEP Reference: Product/Process Quality Assurance Process Area

22. Project Monitoring and Control • Purpose: To provide an understanding of program’s progress so appropriate corrective actions can be taken when performance deviates significantly from the plan • Goals • Monitor project against plan • Monitor project planning parameters • Monitor commitments • Monitor project risks • Monitor data management • Monitor stakeholder involvement • Conduct progress, technical and milestone reviews • Manage corrective actions to closure • Analyze issues • Apply appropriate corrective actions • Manage results of corrective actions SEP Reference: Project Monitoring and Control Process Area

23. Requirements Development • SEP Requirements Development & Management • Purpose: To produce and verify customer, product and product component requirements • Goals: • Develop customer requirements • Elicit needs • Develop and verify customer requirements • Develop product requirements • Determine product and product component requirements • Allocate product component requirements • Identify interface requirements • Analyze and validate requirements • Establish operational concepts and scenarios • Establish a definition of required functionality • Analyze requirements • Validate requirements SEP Reference: Requirements Development Process Area

24. Requirements Management • SEP Requirements Development & Management • Purpose: To manage the requirements of the project’s products and product components and identify inconsistencies between those requirements and the project’s plans and work products • Goal: Manage requirements • Obtain an understanding of requirements • Obtain commitment to requirements • Manage requirement changes • Maintain bi-directional traceability of requirements • Identify inconsistencies between project products and requirements SEP Reference: Requirements Management Process Area

25. Risk Management • Purpose: To identify potential problems before they occur so risk-handling activities may be planned and applied as needed across the life of the product or project to mitigate adverse impacts on achieving objectives • Goals: • Prepare for risk management • Determine risk sources • Define risk parameters • Establish risk management strategy • Identify and analyze risks • Identify risks • Evaluate, categorize, and prioritize risks • Mitigate risks • Develop risk mitigation plans • Implement risk mitigation plans SEP Reference: Risk Management Procedure (RMPR001)

26. Supplier Agreement Management • Purpose: To manage acquisition of products and services from suppliers • Goals: • Establish supplier agreements • Determine acquisition types • Select suppliers • Establish supplier agreements • Satisfy supplier agreements • Execute the supplier agreement • Monitor selected supplier processes • Evaluate selected supplier work products and services • Accept the acquired products and services SEP Reference: Supplier Agreement Management Process Area

27. Training • Purpose: To develop people’s skills and knowledge so they can perform their roles effectively and efficiently • Goals: • Establish organizational training capability based on needs • Determine strategic training needs; define which are the responsibility of organization and which are project-specific • Establish an organizational training plan • Establish project training requirements • Determine tactical training needs within the project • Plan and provide necessary training • Schedule and conduct training • Assess training effectiveness • Establish and maintain training records SEP Reference: Training Process Area

28. Verification • SEP Integrated Developmental Test & Evaluation • Purpose: To ensure selected work products meet specified requirements…“Did we build ‘it’ right?” • Goals: • Prepare for verification • Select work products for verification • Establish verification environment • Establish verification procedures and criteria • Perform peer reviews • Prepare for peer reviews • Conduct peer reviews • Analyze peer review data • Verify selected work products • Perform verification • Analyze verification results SEP Reference: Verification and Validation Process Area

29. Validation • SEP Integrated Developmental Test & Evaluation • Purpose: To demonstrate that a product or product component fulfills its intended use when placed in its intended environment…“Did we build the ‘right’ thing?” • Goals: • Prepare for validation • Select products for validation • Establish the validation environment • Establish validation procedures and criteria • Validate product or product components • Perform validation • Analyze validation results SEP Reference: Verification and Validation Process Area

30. Process Areas "Supporting the BES Program Executive Office within the Air Force Life Cycle Management Center"

31. SEP Process Frameworks & Workflows

32. SEP Process Frameworks MAIS Programs / ACAT Programs Operational Programs / Non-ACAT Programs

33. SEP ProcessWorkflows Detailed Processes Master Process Flow

34. The Non-5000.02 Framework Specifically designed for smaller IT programs; typically used as the framework for operational programs (applies to most) Less stringent overall process requirements than the full DoDI 5000.02 framework Tailorable to meet unique execution requirements at the program level

35. Define Need Phase • Entry Criteria: Program enters this phase after a need is identified by a customer or functional sponsor • Purpose: Describe the capability need and develop functional requirements and product requirements; analyze best acquisition strategy and solution • The phase culminates at Define Need Review (DNR) (MANDATORY) • Document completion of the phase in the Review Decision Memorandum Template (RVTM001) SEP Reference: Define Need Phase Procedure (RDPR015)

36. Design Phase • Entry Criteria: Program enters this phase after successful completion of the Define Need Review (DNR) • Purpose: Design one or more system solutions consistent with acquisition strategy and defined requirements • Validate designs through formal Preliminary Design Review (PDR) and Critical Design Review (CDR) • Phase culminates at Design Review (DR) (MANDATORY) • Document completion of the phase in the Review Decision Memorandum Template (RVTM001) SEP Reference: Design Phase Procedure (RDPR016)

37. Build and Test Phase • Entry Criteria: Program enters phase after successful Design Review (DR) • Purpose: • Development of code or configuration of components • Testing and final review and approval for the system • Integrated Developmental Test & Evaluation (IDT&E) • Operational Test and Evaluation (OT&E) if required • Phase culminates at Field Readiness Review (FRR) (MANDATORY) • Document completion of the phase in the Review Decision Memorandum Template (RVTM001) SEP Reference: Build & Test Phase Procedure (SW5PR011)

38. Release and Support Phase • Entry Criteria: Program enters phase after successful Field Readiness Review (FRR) and product implementation • Purpose: • Implement the system • Prepare site(s) • Conduct training • Operations Support and Sustainment • In-Service Reviews (ISR) SEP Reference: Release & Support Phase Procedure (SW8PR005) NOTE:Completion of this phase will return the project back to the Define Need Phase for the next release

39. The DoDI 5000.02 Framework Specifically designed for Major Automated Information System (MAIS); not used as the framework for operational programs Very stringent processes required for ACAT programs Tailorable to meet unique execution requirements at the program level (tailored by phase, not framework)

40. Materiel Solution Analysis Phase • Entry Criteria: Materiel Development Decision (MDD) • Purpose: Assess potential materiel solutions and satisfy phase-specific entrance criteria for next milestone • The Milestone Decision Authority (MDA) decision to begin this phase does not constitute program initiation of a new acquisition program • Entrance criterion: An MDA-approved Initial Capabilities Document (ICD) • Exit criterion: Acquisition Decision Memorandum signed by MDA (Milestone A) SEP Reference: Materiel Solution Analysis Phase Procedure (RDPR014)

41. Technology Development Phase • Entry Criteria: The program enters this phase at Milestone A • Purpose: Reduce technology risk and determine appropriate set of technologies to be integrated into a full system; demonstrate critical technology elements (CTEs) • Entering the TD phase does not initiate a new acquisition program • Multiple demonstrations may occur before reaching a proposed solution; the Technology Development Strategy (TDS) must be reviewed, updated, and approved to support follow-on increments • Exit criterion: Acquisition Decision Memorandum signed by MDA (Milestone B) SEP Reference: Technology Development Phase Procedure (RDPR008)

42. Engineering & Manufacturing Development (EMD) Phase • Entry Criteria: the program enters this phase at Milestone B • This equates to initiation of a formal acquisition program • Purpose: • Develop a system or an increment of capability • Complete full system integration • Entrance to EMD depends on: • Approved requirements and funding; technology maturity • MDA-approved acquisition strategy • An approved Capability Development Document (CDD) • Must include Key Performance Parameters (KPPs) • An approved Test and Evaluation Master Plan (TEMP)

43. EMD Phase (Cont’d) • Two major efforts within EMD: • Integrated System Design (functional allocation, design) • System Capability & Manufacturing Process Demonstration (construction, testing); Integrated Developmental Test and Evaluation (IDT&E) • EMD effectively integrates acquisition, engineering, and manufacturing development processes with T&E • Exit criterion: Verified Product Baseline; Milestone C Decision SEP Reference: Engineering & Manufacturing Development Phase Procedure (SDPR002)

44. Production and Deployment Phase • Entry Criteria: The program enters this phase at Milestone C • This indicates the MDA has committed to production • Purpose: To achieve an operational capability that satisfies mission needs • Effectiveness and suitability of the system determined through Operational Test and Evaluation (OT&E) SEP Reference: Production and Deployment Phase Procedure (PDPR004)

45. Operations and Support Phase • Entry Criteria: the program enters this phase after Full Deployment Decision Review (FDDR) • Purpose: Execute program support to meet performance requirements and sustain system over its life cycle • Divided into two sets of activities: • Sustainment: Management and support activities to sustain system; includes modifications and improvements to update and maintain required levels of operational capability • In-Service Reviews (ISR) • Disposal: At the end of a system's useful life, it must be decommissioned and disposed of in accordance with all policies, legal and regulatory requirements SEP Reference: Operations and Support Phase Procedure (OSPR001)

46. Project Tailoring & Waivers

47. Project Tailoring • All projects have unique characteristics that must be considered • One consideration is that all parts of the SEP may not need to be accomplished (or re-accomplished) • Tailoring is process flexibility to address project-unique execution that deviates from the standard process • Tailoring must be balanced with standards, objectives and strategies of the program and be based on risk to the project • Lack of resources is NOT authorization for tailoring SEP Reference: SEP Tailoring Guide (PDGD007)

48. Tailoring Worksheet (TWS) Description • Roadmap of required documentation, products and associated processes used to meet capability delivery commitments • Agreement between the PM and LE/CE on processes and artifacts that will be accomplished; SEPG coordinates • Contractors should not sign; elevate to the next level • A TWS is NOT release specific…it is a lifecycle plan that can aid in identifying programmatic and engineering requirements • SEP Tailoring Worksheet determines which framework, processes and products are to be completed by the project • If a product or activity is tailored out or down, it must be justified and approved • Tailoring up (in) is authorized and encouraged

49. Which TWS Template? • 5000.02 Framework – ACAT I and Oversight Programs: • Depends on Acquisition Phase (MDA Direction) • Materiel Solution Phase: SWTM034 • Technology Development Phase: SWTM039 • Engineering and Manufacturing Development or the Production & Deployment Phase: SWTM040 • Operations and Support: SWTM052 • Non-5000 Framework (Non-ACAT): • New Starts: SWTM051 • Operational Systems: SWTM052

50. When is a TWS Required? • A TWS is required for every project identified on the PPL, unless exempted or granted a waiver • A new TWS is required every two years and when: • A project changes the development or acquisition strategy • Policy mandates drive additional products/processes • Policy changes reduce products/processes • Types of tailoring: • Altering product content • Dividing products/processes into smaller items • Changing order, flow, or format of products • Eliminating a product/process • Adding a new product/process