1 / 15

SEMP vs. PMP Conflict and Partnership

SEMP vs. PMP Conflict and Partnership. Francis Peter Manager, Systems and Programs Management Sciences, Inc. francis.peter@incose.org. Systems Engineering Management Plan (SEMP). Master document for program control of Systems Engineering Technical Elements

jana
Download Presentation

SEMP vs. PMP Conflict and Partnership

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  1. SEMP vs. PMPConflict and Partnership Francis Peter Manager, Systems and Programs Management Sciences, Inc. francis.peter@incose.org

  2. Systems Engineering Management Plan (SEMP) • Master document for program control of Systems Engineering Technical Elements • Defines SE Processes and Procedures used on the Program • Defines relationship of SE activities to other program activities • Includes Specialty Engineering Integration • Defines intermediate products including: • Specifications and Documents • Baselines • Checklists • Databases and other intermediate work elements

  3. Program Management Plan (PMP) • Master Planning document for Program • Includes Master/Integrated Schedule • Defines all Program Activities to be controlled • Includes Cost/Schedule Reporting and Program Control elements • Establishes Priorities • Includes or references sub plans/processes for specialty tasks • Controls the acquisition and development processes

  4. SEMP Outline • Scope • Applicable Documents • Technical Program Planning and Control • Systems Engineering Process • Engineering Specialty Integration • Notes

  5. PMP Outline (example) • SCOPE • Applicable Documents • Program Structure (WBS) • Program Control & Responsibilities • Program Activities • Personnel/Staffing • Contract & Subcontract Management • Other topics as needed

  6. SEMP and PMP • Are Living Documents – Update Regularly • Must be executable – Keep simple but complete • Exclude minutiae – Reference other Documents as required • Must be available to all personnel • Should be cross referenced when appropriate • Work together for a successful program

  7. PMP vs. SEMP • PMP is overall controlling plan • Includes many disciplines beyond SE • SEMP defines SE processes in relation to the PMP • Topic areas in each plan will overlap • SEMP defines SE specific areas of responsibility and methodology/processes to satisfy PMP

  8. Why a separate SEMP? • Including SEMP plus all other disciplines into the PMP is impractical • SEMP allows detailed emphasis of SE activities that are important to the Program • One stop reference for SE Staff • More easily updated as standalone doc • Must be linked closely to the PMP

  9. Tailoring the SEMP • How Complex is the Program? • For simpler Programs, depopulate unnecessary or low payback activities • How complete is the PMP? • Does PMP cover all specialty and sub-specialty practice areas? • SEMP must fill in or reference PMP for important elements • What standard processes exist in your Org? • Reference and define specific scope of applicability • Other major Program Elements that impact SE?

  10. SEMP Tailoring – Must Haves • Requirements Management Process • Baselines & Configuration Management • Program Reviews • Technical Performance Measures • System Verification • All of these elements must be accounted for between the SEMP and PMP

  11. PMP Tailoring – Must Haves • Program definition & WBS • Integrated/Master Schedule • Program Control: • Cost, Schedule, TPMs, Risk Analysis • Responsibility definition • People/Staffing & Org Structure (IPTs?) • Contract/Subcontract management

  12. Does your Organization have: • Standardized plan formats • Specification formats • Detailed process documentation If not: • Use other existing formats including • Military Standards • Classical formats Avoid “Not Invented Here” syndrome These are proven complete and workable

  13. References • INCOSE • http://www.incose.org/ProductsPubs/products/ • Defense Acquisition University (DAU) • https://acc.dau.mil/se • https://acc.dau.mil/pm • Ken Rigby, Rigby Publishing Ltd. • spark.airtime.co.uk/users/wysywig/semp.htm New Defense Acquisition Docs refer to SEP

  14. Program Requirements Capabilities, CONOPS, KPPs Statutory/regulatory Specified/derived performance Certifications Design considerations Technical Staffing/Organization Technical authority Lead Systems Engineer IPT coordination/organization Organizational depth Technical Baseline Management Who is responsible Definition of baselines Requirements traceability Specification tree and WBS link Technical maturity Technical Review Planning Event-driven reviews Management of reviews Technical authority chair Key stakeholder participation Peer participation Integration with Overall Management of the Program Linkage with other program plans Program manager’s role in technical reviews Risk management integration Test and logistics integration Contracting considerations SEP Focus Areas

  15. Presented by: Francis Peter Manager, Systems and Programs Management Sciences, Inc. 6022 Constitution Ave, NE Albuquerque, NM 87110 (505) 255-8611 francis_peter@mgtsciences.com francis.peter@incose.org

More Related