- The Requirement
for a Systems Engineering Plan (SEP)
- Q: Who directed and where
is the requirement or policy?
- A: The requirement for the SEP is now found in DoDI 5000.02, Operation of the Defense Acquisition System, Enclosure 3 (Systems Engineering). The Acting Under Secretary
of Defense for Acquisition, Technology, and Logistics,
issued the original policy in a USD(AT&L) systems
engineering policy memorandum, dated Feb 20, 2004,
requiring:
"All programs responding to a capabilities or
requirements document, regardless of acquisition category,
shall employ a robust systems engineering (SE) approach
that balances total system performance and total ownership
costs within the family-of-systems, system-of-systems
context. Programs shall develop a Systems Engineering
Plan (SEP) for Milestone Decision Authority (MDA) approval
in conjunction with each Milestone review, and integrated
with the Acquisition Strategy. This plan shall describe
the program's overall technical approach, including
processes, resources, metrics, and applicable performance
incentives. It shall also detail the timing, conduct,
and success criteria of technical reviews."
- Q: Does the SEP requirement
apply to AIS and MAIS programs?
- A: Yes, DoD Instruction 5134.16, Deputy Assistant Secretary of Defense for Systems Engineering (DASD(SE)), August 19, 2011, states, "The DASD(SE) shall: (a) develop policies and guidance for ...(3) The development of systems engineering plans (SEPs) for MDAPs and MAIS programs in accordance with Reference (a) [Section 139b of title 10, United States Code] and Reference (c) [DoD Instruction 5000.02, Operation of the Defense Acquisition System, December 8, 2008; Note: An updated version of DoDI 5000.02 is now available.]. The title ‘SEP’ will be applied to the document referred to in section 102 of Reference (a) as the ‘systems engineering master plan.’"
- Q: Why does my program need
to write a SEP; the next milestone (MS) is not for many
years? [This answer addresses the requirement for MS
A, B, and C.]
- A: The SEP is required because it
captures the program's overall technical approach and
integration to program planning required to achieve
the next MS. A good SEP captures and shares a roadmap
of the technical execution of your program. Program
personnel should use the SEP as a reference to access
information relative to the program. The SEP should
be continuously updated as plans are solidified or
modified, activities move from plans to historical
facts, known risks are mitigated or significantly change,
new risks are identified, new tools and technologies
are adopted, and as a myriad of other factors cause
an adjustment to the way the program technical activities
should best be managed.
- Q: How does the SEP benefit post-Milestone (MS) C programs?
- A: Following MS C, the SEP should be maintained as a living document throughout the system life cycle. In accordance with DoDD 5000.01, the program manager, as the total life cycle systems manager, is responsible for effective and timely acquisition and sustainment of the system throughout its life cycle. Systems engineering continues through production, fielding, deployment, and sustainment. Manufacturers will propose changes through Engineering Change Proposals, and users will introduce new requirements that must be analyzed as part of the SE process. The program manager is responsible for providing the needed product support capability to maintain the readiness, sustainment, and operational capability of a system. Effective sustainment of a system during operations and support includes a multidisciplined effort to: collect and triage all service use information, analyze root causes of problems, assess suitability and effectiveness trends, develop solutions, and manage the fielded system configuration and associated processes. Thus, the need for technical planning to ensure the application of a disciplined systems engineering approach continues beyond MS C.
- SEP Approval/Approval
Procedures
- Q: How often do we need to
update and resubmit the SEP?
- A. SE planning should be kept current throughout the acquisition life cycle. For ACAT I programs, ODASD(SE) expects to approve SEP updates to support milestone reviews (e.g., Milestone (MS) A, B, and C) and program restructures; the PEO can approve SEP updates to support SE technical reviews and program changes that impact the technical strategy.
- Q: Who is the approval official
for the SEP?
- A: SEPs for MDAP (ID and IC) and MAIS (IAM and IAC) programs are approved by the Deputy Assistant Secretary of Defense for Systems Engineering. For all other SEPs, the Component Acquisition Executives have set their own SEP approval policies.
- Q: What are the signature
blocks for OSD approval?
- For all SEPs, the SEP signature block should be:
[Name of Milestone Decision Authority (MDA)]
[MDA Signature Block]
- Q: What is the relationship
between the CAE SE, PEO SE, PM SE, and ODASD(SE) staff?
- A: Organizationally, senior Component
SE representatives participate with the Office of the Deputy Assistant Secretary of Defense for Systems Engineering within the Office of the Assistant Secretary of Defense for Research and Engineering at the Systems Engineering (SE) Forum. The Forum
was established in response to the dictum in the USD(AT&L) systems
engineering policy memorandum dated Feb 20, 2004 and re-confirmed in DoD Instruction 5134.16, Deputy Assistant Secretary of Defense for Systems Engineering (DASD(SE)), August 19, 2011.
The Forum meets regularly (initial meeting was April
22, 2004) to discuss SE revitalization and develop
collaborative SE guidance. Programmatically, program
managers are encouraged to establish a Systems Engineering
(SE) IPT to perform the technical planning necessary
to develop a comprehensive SEP. The SE IPT should include
all of the program's engineering resources and stakeholders.
- Q: What is the timeframe
for OSD to approve our SEP?
- A: Formal SEP submissions for staff
approvals should be completed within 6 weeks from receipt
of the document. Early involvement and participation
in Systems Engineering (SE) IPTs, as well as reviews
of draft SEPs, should reduce turn-around time and rework.
- Q: Why is the SEP a "living" document?
- A: A good SEP provides a roadmap to
the technical execution of a program. Program personnel
should use the SEP as a reference to understand the
overall technical approach to a program. A SEP should
be continuously updated as plans are solidified or
modified, activities move from plans to historical
facts, known risks are mitigated or significantly changed,
new risks are identified, new tools and technologies
are adopted, and as a myriad of other factors cause
an adjustment to the program's overall technical approach.
- Q: If the SEP is a living
document, do I need to get it re-signed by OSD after
every change?
- A: No, SEP changes should be tracked
and kept under local configuration control, and do
not require resubmittal to the MDA for approval. It
is recommended that a courtesy copy be made available
when major changes are made, so that the cognizant
approving organization is kept current on the program's
systems engineering plans, and is available to assist
if requested. However, SEP updates are required as
formal submission to the Milestone Decision Authority
(MDA) prior to each Milestone review, or if there are
major program changes between scheduled Milestone reviews.
- Q: Can we get feedback from
the Office of the Deputy Assistant Secretary of Defense for Systems Engineering on SEPs submitted?
- A: As part of its support role, the Major Program Support Directorate within ODASD(SE) provides feedback for out-of-cycle
draft SEPs directly to the requesting organization.
If a program manager sends a draft SEP for review,
the program manager will get a direct response. If
a Component Acquisition Executive (CAE) provides a
SEP for approval, the response is provided to that
CAE.
- Q: Whom do I contact to start
early informal dialogue and coordination?
- A: Contact the Program Support Team
Lead (PSTL) in ODASD(SE)'s Major Program Support (MPS) Directorate whose portfolio includes your program or type
of program. MPS program support teams are organized
around product lines. There are currently PSTLs
focused on the following product lines: Fixed Wing
Aircraft; Rotary Wing Aircraft; Missiles and Unmanned
Aircraft; Land Combat Systems; Ships; Command, Control,
Intelligence, Surveillance, and Reconnaissance (C2ISR);
Business Systems; and Communications Systems. You may
contact these teams through the following address: osd.sep@mail.mil.
- SEP Development/Format
- Q: Do you have an example
of a good SEP?
- A: No. A number of SEPs are candidate examples, but we believe there are strong reasons for not providing examples:
**Programs in different domains and different Services/Agencies will use different processes.
**Any given SEP is an operating plan for how that program will execute its systems engineering. How one program executes its systems engineering may differ greatly from how another program will execute its systems engineering. This could depend on many factors including the program's scope, acquisition strategy,
risk, life cycle phase, etc. Without knowing these underlying influences, the technical planning in one SEP may or may not apply to another program.
We advise you to check with your Program Executive Office (PEO) or equivalent. At that level, you should be able to see a SEP that most closely meets your needs.
- Q: How much detail is needed?
- A: Only as much detail as is required
to convey to program stakeholders what the operational
plan is for the technical management of the program.
There should be sufficient detail for the reader to
understand who does what, when, how, and where—and
what control mechanisms are used to manage it all.
- Q: Do we need an SE IPT to "work" the
development of our SEP?
- A: Program managers are encouraged
to establish a Systems Engineering (SE) Integrated Product Team (IPT) to perform
the technical planning necessary to develop a comprehensive
SEP. The SE IPT should include all of the program's
engineering resources and stakeholders.
- Q: If the SEP or an update
is required at each milestone, what is the expected content
for each milestone?
- A: For the first SEP submittal, the
content should focus on a plan of action for how the
program office intends to manage its technical efforts
for the life cycle phase following the milestone (MS).
Past SE activities should be briefly addressed to demonstrate
how you got to this point. Long-term planning considerations
for future phases should be briefly covered. For example,
if approaching MS B, the plan should summarize systems
engineering activities used in selection and refinement
of the material concept, maturation of enabling technologies,
and the status of the systems engineering products
that are in place to support the milestone decision.
It would then provide detailed discussions of the systems
engineering activities planned for the system development
and demonstration (SDD). Finally, it should address
production, deployment, operations, and support considerations
to the extent these phases are influencing systems
engineering in the SDD phase (See the SEP Outline for more details). For
a resubmittal, the content should include an update
of the plan of action for program technical planning.
For example, assuming the schedule has changed since
the last submitted SEP and more details have come available
regarding technical reviews, etc., this information
would be updated accordingly.
- Q: How many pages should
the SEP be?
- A: SEP length will vary by program
scope, maturity, and risk. It should cover the overall
technical planning effort for the program and may cite
subordinate plans when the program determines that
additional planning detail is required.
- Q: How should related documents
be referenced vice including everything in the SEP?
- A: Summarize the referenced material
in the SEP, discussing all linkages and specifics of
how other documents support the SEP. The referenced
material should become part of the overall SEP, included
as attachments, annexes, hyperlinks, or as a minimum,
mapped under a single configuration control scheme
so that all information will be maintained current
and remain consistent with the program's overarching
technical planning.
- Q: Can we use existing related,
relevant documentation rather than redeveloping or reformatting
existing documentation?
- A: Existing documentation can be used
to the extent it captures relevant systems engineering
technical planning. For example, the program may have
a contractor's plan for technical planning. However,
it generally does not include the Government program
manager's plan for technical management of the program.
We have also found that the prime contractor's technical
plans are often weak in flowing down systems engineering
processes and requirements to subcontractors and vendors.
Follow the guidelines provided in the question above
regarding referencing other documents, as to proper
referencing and maintaining the supporting information.
- SEP/SEMP Relationship
- Q: What is the difference
between the SEP and the SEMP?
- A: In the USD(AT&L) systems
engineering policy memorandum, dated Feb 20,
2004, and subsequent DoD 5000.02 update, we chose to call the document a "Systems
Engineering Plan (SEP)." Systems Engineering
Management Plan (SEMP) is a term used
previously in DoD and more common with industry. As long as the content is adequate we have
no preference regarding the title.
- Q: Do I need both a SEP and
SEMP, or can they be combined into one document?
- A: This question assumes the SEP is
a "government" product and that the SEMP
is a "contractor" document; however, this
is not a valid distinction. The decision
to combine the program office's technical planning
with the contractor's technical planning is an individual
program decision based on resource limitations and
other factors unique to the situation. If you choose
to have one document, it must capture the technical
planning for the entire program. If you choose to have
two documents, for example, a "SEP" for the
program office responsibilities and a "SEMP" for
the contractor effort, the two documents must have
a common systems engineering thread, linking the technical
planning from the program office down to the lowest
level supplier. We expect a
program to have a "shared vision" of the
overall technical planning effort, regardless of how
many documents contain that shared vision.
- Q: Is the contractor SEMP
adequate to meet the requirement?
- A: A contractor's systems engineering
plan is acceptable only if it addresses the overall
program's systems engineering technical approach across
the government, prime, and sub-contractor domains.
Prime contractor systems engineering plans typically
only address the technical planning associated with
the prime contractor's effort, and do not necessarily
encompass the entire technical effort associated with
a program, such as requirements trade space for which
the government retains authority, government furnished
equipment, integrated developmental and operational
test requirements and planning, etc. We have also found
that prime contractor's documents do not adequately
flow down the systems engineering process and requirements
to subcontractors and vendors. However, if your program
has an existing contractor systems engineering plan,
you may cross reference that technical planning to
the overall technical planning for the program described
in the SEP.
- SEP Technical
Issues
- Q: Where do I find the statutory
and regulatory requirements for my program? How do I
know if I have found them all?
- A: DoDI 5000.02, Operation of the Defense Acquisition System is the primary reference and starting
point for these types of requirements. Service-unique
or commodity-oriented related requirements should
also be addressed. However, simply providing a listing
of these requirements in the SEP is not sufficient.
The technical planning for the program, as documented
in the program's SEP, should include discussion of
how the program plans to interpret, apply, and comply
with these kinds of requirements from a technical
perspective. Also key in the SEP is discussion of
how these requirements will be integrated with other
requirements (e.g., KPPs, specified and derived requirements)
in an integrated framework to ensure requirements
traceability throughout development, test, and evaluation.
- Q: Most, if not all, programs
employ requirements
management (RM) tools (e.g. Dynamic Object Oriented
Requirements System (DOORS) or similar RM tools) to provide
requirements management and traceability for stakeholder,
statutory, regulatory, and derived requirements. Why
must this tool be described in detail again in the SEP
rather than referenced?
- A: Specifics about any particular
tool can be referenced and need not be described in
detail in the SEP. What should be discussed in detail
is how the tool will be used to manage requirements
as they are iteratively and recursively analyzed, traded,
decomposed, and allocated across the system. How the
program will ensure requirements traceability (both
up and down the system) should also be discussed in
detail.
- Q: How do we get the contractor
to support the added SEP workload if they are already
under contract and have no funding slack?
- A: It is expected that most, if not
all, industry best practices include technical planning
as part of their overall engineering and technical
effort. It is this planning that is envisioned as being
captured in the SEP. If the contractor has not conducted
technical planning or has not captured it in written
form, then there are likely more serious issues on
the program beyond "added SEP workload."
- Q: What is the definition
of technical baseline referenced in the Defense Acquisition
Guidebook and the SEP Outline?
- A: Virtually all industry best practices
and systems engineering standards include establishment
and control (configuration management) of system instantiations
during development. These instantiations could include
logical solution representations and physical solution
representations at various levels of the system hierarchy—functional
and allocated baselines. During development, establishment
and multi-disciplined review of these baselines is
a key element of event-driven technical reviews. Ultimately,
the technical baseline evolves to include a product
baseline that addresses the build-to specifications
and drawings together with the associated production
and support processes.
The specific definitions found in DAG Chapter 4 follow:
** Technical baseline: The technical baseline (including the functional, allocated and product baselines) established at the conclusion of certain technical reviews inform all other program activity. Accurate baselines and disciplined reviews serve to integrate and synchronize the system as it matures, which facilitates more effective milestone decisions and ultimately provides better warfighting capability for less money. The technical baseline provides an accurate and controlled basis for:
- Managing change
- Cost estimates, which inform the PPBE process and ultimately the Acquisition Program Baseline (APB)
- Program technical plans and schedules, which also inform the APB
- Contracting activity
- Test and Evaluation efforts
- Risk analysis and risk balancing
- Reports to acquisition executives and Congress
** Functional baseline: Describes the system’s performance (functional, interoperability, and interface characteristics) and the verification required to demonstrate the achievement of those specified characteristics. It is directly traceable to the operational requirements contained in the Initial Capabilities Document (ICD) and draft Capability Development Document (CDD). The Program Manager establishes Government control of the functional baseline at the SFR and verifies it through Functional Configuration Audits (FCA) leading up to the system level FCA or the System Verification Review (SVR).
** Allocated baseline: Describes the functional and interface characteristics for all system elements (allocated and derived from the higher-level product structure hierarchy) and the verification required to demonstrate achievement of those specified characteristics. The allocated baseline for each lower-level system element (hardware and software) is usually established and put under configuration control at the system element Preliminary Design Review (PDR). This process is repeated for each system element and culminates in the complete allocated baseline at the system-level PDR. The Program Manager then verifies the allocated baseline at the system level Functional Configuration Audit (FCA) and/or System Verification Review (SVR).
** Product Baseline: Describes the detailed design for production, fielding/deployment, and operations and support. The product baseline prescribes all necessary physical (form, fit, and function) characteristics and selected functional characteristics designated for production acceptance testing and production test requirements. It is traceable to the system performance requirements contained in the Capability Development Document (CDD). The initial product baseline includes "build-to" specifications for hardware (product, process, material specifications, engineering drawings, and other related data) and software (software module design - "code-to" specifications). The initial system element product baseline is established and placed under configuration control at the system element Critical Design Review (CDR) and verified later at the Physical Configuration Audit (PCA).
- Q: How should the program
office describe their technical reviews when they are
using agile software development methods?
- A: To be of value in determining the
technical maturity of a system, technical
reviews must be event driven. Event-driven reviews
are not only required by DoD policy, but are also a
fundamental part of most industry best practices. Programs
using any development method should ensure that method
provides for event-driven technical reviews (that is,
reviews having entry and exit criteria quantifiable
in technical baseline completion terms). Methods that
do not have such provisions, while seemingly "agile," often
lack the ability to measure technical maturity to objective
measures.
- Q: If we truly convert to
non-schedule driven milestones, how do we manage against
contractor burn rates, fixed budgets, and iron schedules
in the acquisition program baseline (APB)?
-
A: The purpose of event-based technical
reviews is to provide an objective measure of
technical maturity to provide the sound, technical
basis against which to manage technical progress
achieved at the cost and schedule. It is expected
that having this insight to technical maturity against
objective measures, the program will be better able
to understand the true implications of contractor
burn rates, fixed budgets, and iron schedules.
- Q: Are PEOs, CAEs/SAEs, and
OSD really signed up to the idea that schedule is malleable?
- A: Knowledge of schedule, isolated
from the understanding of technical maturity (maturity
of the technical baseline) at a point in time, is not
viewed as good systems engineering or program management.
Schedule is no more malleable than maturity of the
technical baseline, hence the emphasis (and policy)
for event-based technical reviews.
- Q: Do you have a rule of
thumb based on historical evidence, regarding the time
between technical reviews?
- A. The time between technical reviews
is wholly dependent on the scope and risk of a program
and how a program lays out its technical baseline approach.
Functionally complex programs will generally require
more time to evolve their technical baseline—reviewed
at a system functional review (SFR). Programs having
many configuration items (CIs) will have a more complex
system decomposition and allocation, requiring more
time to achieve the entry criteria to meet multiple
preliminary design reviews (PDRs) and will require
more time to get to build-to (or code-to) specifications
(product baseline) for those CIs' critical design reviews
(CDRs).
- Q: Is there an example of
how Earned Value Management can take advantage of good
systems engineering planning?
- A: Too often, systems engineering
is viewed as not having a defined "product." This
results in systems engineering being reflected as level
of effort (LOE) in many Earned Value Management (EVM)
plans and cost accounts. Good systems engineering planning,
including the identification and management of the
technical baselines (functional baseline, allocated
baseline, and product baseline) should call out specific
systems engineering products in the form of these baselines.
When aligned to the system work breakdown structure
(WBS), the technical baselines should be the basis
for earned value cost accounts and provide a product-driven
view of managing systems engineering costs (and value).
Additionally, when the maturity of these technical
baselines are entry criteria for event-based technical
reviews, earned value can provide critical insight
to technical progress against accumulated cost and
schedule measures.
- Q: How should the SEP be
used to help with development of a program's Integrated
Master Plan/Integrated Master Schedule or Single Acquisition
Management Plan?
- A: Sound technical planning, including
systems engineering best practices, should be the basis
for a strong program plan and schedule. From this standpoint,
a program's SEP would serve as a key input to planning
and scheduling of overall program activities in the Integrated
Master Plan/Integrated Master Schedule (IMP/IMS) or
Single Acquisition Management Plan (SAMP). An example
of this relationship of systems engineering to program
planning is the definition of the program's critical
path. While a program's critical path is defined in
the IMS, many of the key events that comprise that
critical path would be derived from the detailed technical
planning found in the SEP.
|
