Operational Concept

1
Operational Concept
2
The Dreaded Operational Concept
Prototyping the Solution
3
Before You Can Write aGood Ops Concept
Define the problem
ID valid, true, and relevant issues which must be
addressed to solve the problem
ID capability gaps that result from the problem
associated issues
ID operational objectives impacted by the problem
ID operations impacted by the problem
ID high-level capabilities-based requirements
ID benchmarks for each operation
Explain/ demonstrate how proposed solution will
improve performance
4
Whats in An Ops Concept?
Prototyping the Solution

• Whats the warfighter pain?
• How will proposed solution alleviate warfighter
  the pain? Improve warfighter performance?
• Address major operational use cases in which
  proposed solution will be applied
• ID how solution will help achieve functional and
  Joint Operational Concepts
• Identify Families-of-Systems and/or
  System-of-Systems in which solution will be
  employed
• Explain high-level, implementation approach and
  considerations
• Spiral acquisition approach

5
Operational Concept Matrix
Prototyping the Solution
State purpose, goals, and overarching capability
in terms of warfighter benefits. (Why?)
Major Functional Areas
Sub-functions
Operations
System Types
WHAT?
WHO?
WHEN?
WHERE?
HOW?
- Threads to Operational Architecture, of
which the operational IER is a subset - Keeps
everybody working off of the same sheet of
music - Facilitates assessment of a
pre-existing Operational Concept. - Yields Ops
Concept, Testable and Measurable Requirements,
and KPPs
6
The Benefit of Using An Operational Concept Matrix
4. Identify test issues early in process
5. ID test issues early in the process
6. ID risks factors to program
1. Clearly identify warfighter issues
(interoperability others)
WHAT?
2. Establish what level tasks are in the
operational IER Matrix.
WHO?
4. Establish criticality essential to KPP
development
WHEN?
3. Establish whether or not operational IERs are
needed early in the process whether or not they
are Joint.
WHERE?
HOW?
7
Another Approach? Why?

• Simplicity
• Back to basics
• When youre up to your ass in alligators, it is
  sort of hard to remember that your main objective
  was to drain the swamp!
• A way to focus on what we really need to know NOW
• A way to leverage the architecture we already
  have
• With JCIDS we transitioned from silent movies to
  talkies
• The industry is still trying to understand how to
  leverage previously developed products
  (architecture, requirements documents, analytical
  methods) in a capabilities, mission-centric world
• Not all the players are going to be able to make
  the transition
• Speed
• Define today
• Refine tomorrow
• and the next day
• and the day after that

8
Some Definitions

• Joint Mission Threads
• A functional grouping of mission specific
  synchronized activities (material and
  non-material), tasks, their associated
  attributes, directed toward a common purpose (a
  comprehensive capability) that facilitates the
  interoperability and integration of joint forces
  while providing a consistently executable
  management tool to address the development,
  synchronization, monitoring, assessing and
  refining of a mission area across the DOTMLPF
  spectrum.
• Benchmarks
• A simplified set of scenario-based, sequential,
  warfighter tasks and activities, protocols,
  standards, attributes and associated architecture
  products that facilitates and streamlines
• Development revision of operational concepts,
• ID and assessment of FOSs/COIs/SOSs, and
• Integration of multiple related architecture
  products, Joint Concepts, and Joint Mission
  threads

9
Benchmark

• Product
• Simple
• Too complex and it wont be used
• Short
• 10 page max
• Contents
• Joint Narrative
• OV-1(s) and scenario(s)
• FOS/SOS Matrix
• An SV-5 on the side
• Mission threading from SPG to attributes
• Customers
• OPS analysts
• JCIDS documents approval authorities
• JCIDS document writers
• Architecture development
• Modeling and simulation

10
Example OV-1
Joint Vertical Heavy Lift
Task 9
Task 10
100-NM
Task 8
Task 6
Task 7
Task 5
LZ
250-NM
Task 6
Task 11
Task 4
50-NM
Task 3

• Focused Logistics/Sustainment
• Ship to Ship
• Ship to Shore
• Improved Site
• Unimproved Site
• High altitude LZ
• Land to Land
• Improved Site
• Unimproved Site

Task 2
100-NM
Task 1
11
The Requirement
Prototyping the Solution

• Basic statement
• The ability of who to do what under what set of
  conditions.
• The ability of the JTF to destroy mobile scud
  launchers in the Iraqi desert before they launch.
  
• Each DOTLPF area has a template set of
  requirements that pertain to it
• i.e. Training
• The ability to train ...
• The ability to assess training results...
• The ability to assess performance...
• Ability to assess competency...
• Ability to perform...
• etc.

12
Define the Family of Systems
SV-5 turned on its side
Family of Systems Matrix - Operational View
IER Sender/Receiver/Node Candidates

• Interoperability issues
• Connectivity
• Processing (network design)
• Protocols and standards
• Display
• DOTMLPF (for each command)
• Other in-theater drivers and barriers to
  interoperability

13
Strategy to Task Decomposition
The Operational Thin Lines for the Benchmark
14
Strategy to Task Decomposition
The Operational Thin Lines for the Benchmark
The JICs and task decomposition shouldnt
conflict with each other if both are developed
from a mission-centric perspective. The JII
Requirements Branch has been thinking in the
mission-centric, warfighter mode since we began
our 3170 training, so were actually a bit ahead
in our thinking.
15
Beyond Strategy to Task Analysis
Getting to the Real Value Added - DOTMLPF Analysis
16
Ops Analyst Uses

• Identify capabilities and capability gaps against
  the most common (benchmark) scenarios in Joint
  operations
• Perform gap analysis (operational, system,
  technical)
• The simplified integrated architecture templates
  in the benchmark should be
• Augmented,
• Toyed with,
• Added to,
• Challenged, and
• Used to compare and contrast other products.
• Flexible reference pointa conversation startera
  home base (point of departure) for
• integrated architecture development
• requirements development
• concept interpretation, and
• what if discussions.
• Benchmarks wont contain every exception,
  variant, or deviation from the norm but could be
  used as a point of departure to identify and
  create more tailored products when needed.

17
Document Approval Authority Uses

• Allows users to quickly see where the proposed
  capability fits
• Value added at the operational level
• A meaningful executive summary that should
  quickly make the case for warfighter features and
  benefits

18
JCIDS Document Writers

• Will allow referencing of benchmarks instead of
  developing concept of operations from scratch
• Reduce conflicting operations concepts for the
  same mission
• Every ops concept doesnt need to be a
  stand-alone essay.
• Sometimes multiple choice and matching are just
  fine to getting the point across.
• Describing how your systems improve warfighter or
  FOS/SOS performance in specific benchmarks would
  be easier than writing everything from scratch.
• Paint by number
• Our experience has shown that working through the
  benchmark process will help facilitate and
  streamline the document development process.

19
Architect Developer Uses

• Provides focus for efforts in integrated
  architecture development
• A baseline
• A way to
• Identify new architecture products
• Evaluate existing architecture products, and
• Assimilate existing architecture products into
  Joint operations and the common scenarios
  associated with them.
• The chicken wire

20
Modeling and Simulation

• Provide common operational scenarios and views
  for
• Animations which accompany Joint Doctrine pubs
  and Joint Operations
• Models of the operational environments inherent
  in Joint operations
• Add and apply scientific rigor to architecture
  products
• Create scenario-based simulations
• Analyze potential products against the
  capabilities and capability gaps in the benchmark
• ACTDs
• New ST
• RD products
• Make those MS products available to the JCIDS,
  JBMC2, and operational community

21
The Requirement
Prototyping the Solution
Formatting the Requirement

• The who is either a Combatant Commander, a
  JTFC, a Joint Component, a Service, an Agency, a
  Unit, a team, or an individual warfighter.
• The what could be a JMA, operation, task,
  activity, or event
• Operational requirements should be stated in
  terms of mission accomplishment - not in terms of
  physics. State the requirements, not how you
  think a developer or designer should meet the
  requirements. That will be addressed in the
  Performance Requirements.

22
The Requirement
Prototyping the Solution
Inherent Requirements - Doctrine

• Capability to develop doctrine
• Timeliness, accuracy, completeness, suitability,
  usability
• Capability to revise doctrine
• Timeliness, accuracy, completeness
• Capability to test new TTP and doctrine
• Timeliness, accuracy, repeatability, data
  integrity, suitability
• Capability to publish/articulate doctrine
• Timeliness, accuracy, suitability, usability
• Capability to develop TTP products for doctrine
• Timeliness, accuracy, suitability, usability
• Capability to develop new policy and instructions
  or revise existing policy and instructions to
  reflect new doctrine
• Timeliness, accuracy, suitability, usability
• Capability to revise operational architecture to
  reflect new doctrine
• Timeliness, accuracy, completeness
• Capability to review and revise operational
  concepts based on new doctrine
• Timeliness, accuracy, completeness
• Capability to train personnel on new doctrine
• See attributes for Training Requirements

23
The Requirement
Prototyping the Solution
Inherent Requirements - Training

• Capability to provide training
• Timeliness, completeness, accuracy,
  verifiability, availability, repeatability,
  interoperability
• Capability to establish recurring/remedial
  training program
• Timeliness, availability, repeatability
• Capability to demonstrate competency
• Mastery (skill), aptitude, performable,
  completeness
• Capability to measure competency
• Observability, accuracy, quantifiability
• Capability to monitor proficiency
• Observability, verifiability, completeness,
  recordability, accuracy, traceability
• Capability to establish/ascertain criteria in the
  field which constitute success
• Completeness, accuracy, availability

24
The Requirement
Prototyping the Solution
Inherent Requirements - Training

• Capability to of Force Com to provide training
  for new e-tac personnel
• Timeliness, completeness, accuracy,
  verifiability, availability, repeatability,
  interoperability
• Capability of Force Com to establish
  recurring/remedial training program for e-tac
  personnel
• Timeliness, availability, repeatability
• Ability of new e-tac personnel to demonstrate
  competency on Joint Fires (Air) procedures and
  systems
• Mastery (skill), aptitude, performable,
  completeness
• Capability to Force Com/unit commanders to
  measure competency of new e-tac personnel across
  services
• Observability, accuracy, quantifiability
• Capability to Joint /unit commanders to monitor
  proficiency of e-tac personnel under their
  command
• Observability, verifiability, completeness,
  recordability, accuracy, traceability
• Capability to Joint and service operational
  communities to establish/ascertain operational
  performance criteria for e-tac personnel which
  constitute success
• Completeness, accuracy, availability

25
Establish Performance Requirement
Prototyping the Solution
1
2
3
4
Re-format each Capability Gap derived from the
core issue as a Condition of Success (COS)
For each requirement/ COS pair, ID all attributes
which must be addressed for the COS to be
satisfied
Match each requirement with every COS which must
be satisfied in order to meet the requirement
For each COS/attribute pair, ID threshold and
objective performance levels
5
6
7
8
Repeat process for each COS/Attribute pair
attached to the requirement
For each unique attribute, determine most
stringent threshold and objective value
Re-evaluate PRs throughout the task decomposition
process
Check PRs for Operational Requirements for
consistency with Information Exchange Requirements
26
Cost of Failure
Prototyping the Solution
1
2
3
4
Determine whose performance is hindered if
requirement is not met.
Determine which services cannot be effectively
developed and/or delivered if requirement is not
met.
ID what products cannot be effectively developed
and/or delivered if requirement is not met.
ID which resources are threatened if requirement
is not met.
This process is especially helpful for
identifying KPPs and prioritizing requirements.
This analysis should be performed for each
capability gap and associated requirements.
5
ID Joint components are effected if the
requirement is not met.
6
7
8
9
ID service organizations/ units effected if the
requirement is not met.
Determine level of damage that could be sustained
if requirement is not met.
Associate each COF with categories establish for
current project.
Prioritize COFs.
27
Determine Risks
Prototyping the Solution
1
2
3
4
Determine major technical dependencies for each
requirement
Determine major programmatic dependencies for
each requirement
For each technical dependency, list drivers and
barriers to satisfying technical dependency
For each programmatic dependency, list drivers
and barriers to satisfying technical dependency
5
6
7
List other drivers and barriers (policy,
interoperab-ility, cost, etc.) for requirements
Assess probability of eliminating or mitigating
barriers
Develop risk management strategy
28
Domains Functions Systems
Family of Systems Matrix - Operational View
IER Sender/Receiver/Node Candidates

• Interoperability issues
• Connectivity
• Processing (network design)
• Protocols and standards
• Display
• DOTMLPF (for each command)
• Other in-theater drivers and barriers to
  interoperability