SEMP vs. PMP Conflict and Partnership

1
SEMP vs. PMPConflict and Partnership

• Francis Peter
• Manager, Systems and Programs
• Management Sciences, Inc.
• francis.peter_at_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

1. Scope
2. Applicable Documents
3. Technical Program Planning and Control
4. Systems Engineering Process
5. Engineering Specialty Integration
6. Notes

5
PMP Outline (example)

1. SCOPE
2. Applicable Documents
3. Program Structure (WBS)
4. Program Control Responsibilities
5. Program Activities
6. Personnel/Staffing
7. Contract Subcontract Management
8. 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
SEP Focus Areas

1. Program Requirements? Capabilities, CONOPS,
   KPPs? Statutory/regulatory? Specified/derived
   performance? Certifications? Design
   considerations
2. Technical Staffing/Organization? Technical
   authority ? Lead Systems Engineer? IPT
   coordination/organization? Organizational depth
3. 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 managers role in technical reviews?
  Risk management integration? Test and logistics
  integration? Contracting considerations

15
Presented by

• Francis Peter
• Manager, Systems and Programs
• Management Sciences, Inc.
• 6022 Constitution Ave, NE
• Albuquerque, NM 87110
• [phone]
• francis_peter_at_mgtsciences.com
• francis.peter_at_incose.org