Focusing Intelligence part 2
Building SORs
And Moses sent them to spy out the land of Canaan, and
said unto them, Get you up this way southward, and go up into the mountain: And see the land, what it is; and the people that
dwelleth therein, whether they be strong or weak, few or many; And what the land is that they dwell in, whether it be good or bad; and what cities they be that they dwell in, whether in tents, or in strong holds; And what the land is, whether it be fat or lean, whether there be wood therein, or not. And be ye of good courage, and bring of the fruit of the land. Now the time was the time of the firstripe grapes. Numbers 13: 17-20 |
And thus the First Manual on collection management outlines what is required to conduct efficient intelligence collection: a statement of Who is going, Where you want them to go, What you want them to look for when they get there, and When the collection will take place. Extensive Research & Development in the 3500 years since Moses issued the above has yielded the following stupendous breakthrough: formulation of the acronym "SOR" - meaning "Specific Order or Request" - to describe the above narrative. In short, the SOR is a tool that tells a collectors the specific details of what needs to be collected.
Before getting into the dirty details of SOR formulation, here is a quick review of "Focusing Intelligence Part 1" for those who have joined MICA since March... and for those with poor reading retention.
Focused Intelligence is “Intelligence required
to support decision making related to battle planning and execution”.
The relationship of focused intelligence to the Military Decision Making Process (MDMP) is...
Unknowns Beget Commanders Critical Information Requirements
(CCIR) to Focus Intelligence Preparation of the
Battlefield (IPB) which
Drives Wargamimg which Produces Decision Points (DPs) and
High Payoff Targets (HPTs) each
Requiring Priority Intelligence Requirements (PIR) which become Essential Tasks for
Collectors and Analysts.
This article will cover the mechanics of converting PIR
into those "Essential Tasks" through the construction of SORs. It will also present an improved categorical
structure that makes it easy to automate this entire process. An MS Access database demonstrating this
structure is available online.
Before we get into the details, lets first cover the meaning of that "R" word...
"Request"!
This is not an outgrowth of the "Consideration Of Others" training.
Simply put, if your organization cannot order a unit to gather combat information, then you must request they do so. Remember that you may be required to use their format in submitting your request. The Who-What-Where-When components of the SOR remain intact... just add a "Please Help" in there someplace.
One last word about Requests: they might be denied. As soon as you realize that a Request is critical to answering a PIR you must tell the commander! Assuming that the PIR is truly a Priority Intelligence Requirement, he will work command channels to ensure that the Requested unit provides assistance.
Toolbox
SORs are not constructed out of thin air, but are assembled using a number of very useful tools. I'll refer to these throughout the rest of the article, so you might want to memorize this part. Don't worry, it's not classified and it will not be necessary to cut your head off and lock it in a Class 3 Safe when we are through. Included below are the Doctrinal Definitions of these tools, followed by my Useful Definition. "Useful" because it eliminates doctrinal ambiguity, omits tutorial instructions, and enables an efficient, logical, rigorous approach leading to an automated solution.
Tool |
Book
Definition |
Useful
Definition |
IR - Information Requirement |
(1) Those items of information
regarding the enemy and his environment which need to be collected and
processed in order to meet the intelligence requirements of a commander. (FM
101-5-1 dtd Sept 97) (2) An intelligence
requirement of lower priority than
the PIR of lowest priority. (FM
34-130, dtd Nov 93) & (FM 34-1, dtd Jan 94) |
Those
items of information regarding friendly, enemy, and the environment which
need to be collected and processed in order to meet the planning requirements
of a commander. Change: Can be both Red and Blue! Just like CCIR! |
IR - Intelligence Requirement |
(1) A requirement for
intelligence to fill a gap in the command's knowledge and understanding of
the battlefield or threat forces. Intelligence requirements are designed to
reduce the uncertainties associated with successful completion of a specific
friendly course of action; a change in the course of action usually leads to
a change in intelligence requirements. Intelligence requirements that support
decisions which affect the overall mission accomplishment (such as choice of
a course of action, branch, or sequel) are designated as priority
intelligence requirements. Less important intelligence requirements are
designated as information requirements. (FM 34-130, dtd Nov 93). (2) Intelligence gaps that
must be filled in order to reduce the uncertainties associated with the
successful execution of a specific friendly COA. Each is linked to a specific enemy action that requires a
friendly response. Each must be situational templated and wargamed. Your
wargaming will dictate which IRs become Priority Intelligence Requirements
(PIR) as the mission runs its course. (FM 34-8, dtd Sep 92) |
Intelligence
gaps that must be filled in order to reduce the uncertainties associated with
the successful execution of a specific friendly COA. Each must be linked to a specific enemy
action that requires a friendly response, ask a single question, and be valid
for a specific time interval. Change: FM 34-130 plus a specific format and minus the tutorial on creating them. |
PIR - Priority Intelligence Requirement |
(1) Those intelligence
requirements for which the commander has an anticipated and stated priority
in his task of planning and decision making. (FM 101-5-1, Sept 97) (2) An intelligence
requirement associated with a
decision that will affect the overall success of the command's mission. PIR
are a subset of intelligence requirements of a higher priority than
information requirements . PIR are prioritized among themselves and may
change in priority over the course of the operation's conduct. (FM 34-130,
dtd Nov 93) (3) Those Intelligence
Requirements (IRs) for which a commander has an anticipated and stated
priority in his task of planning and decision making. Wargaming will dictate
which IRs become PIRs as the mission runs its course. (FM 34-8, dtd Sep 92) |
An
Intelligence Requirement associated
with a decision that will affect the overall success of the command's mission
planning or mission execution. Change: FM 34-130 minus that "Information Requirement" nonsense and the tutorial. |
SIR - Specific Information Requirement |
Specific
information requirements describe the information required to answer all or
part of an intelligence requirement. A complete SIR describes the information
required, the location where the required information can be collected, and
the time during which it can be collected. Generally, each intelligence
requirement generates sets of SIR.
(FM 34-130, dtd Nov 93) |
The information required to answer all or part of an intelligence requirement. Change: Eliminated the tutorial and the requirement to associate it with a location. |
NAI - Named Area of Interest |
(1) A point or area along a
particular avenue of approach through which enemy activity is expected to
occur. Activity or lack of activity
within an NAI will help confirm or deny a particular enemy course of
action. (FM 101-5-1 Sept 97) (2) The geographical area
where information that will satisfy a specific information requirement can be
collected. NAI are usually selected to capture indications of threat courses
of action but also may be related to conditions of the battlefield. (FM
34-130, dtd Nov 93) (3) An area on the ground
which, when observed, will either confirm or deny an enemy course of action.
(FM 34-8, dtd Sep 92) |
The area where information that will satisfy a Specific Information
Requirement can be collected. Change: "Area" can be geographic, or more like an "area of study". Bottom Line: it is where you go to get the information. The tutorial is omitted, and the NAI is associated with an SOR rather than an SIR, IR, indicator, or enemy course of action. |
SOR - Specific Order or Request |
The
order or request that generates planning and execution of a collection
mission or analysis of data base information. SORs sent to subordinate
commands are orders. SORs sent to other commands are requests. SORs often use
system-specific message formats but also include standard military operations
and fragmentary orders. (FM 34-130, dtd Nov 93) |
Change: Tutorial omitted. |
Indicator |
Positive
or negative evidence of threat activity or any characteristic of the AO which
points toward threat vulnerabilities or the adoption or rejection by the
threat of a particular capability, or which may influence the commander's
selection of a COA. Indicators may
result from previous actions or from threat failure to take action.(FM 34-1,
dtd Jan 94) |
Positive
or negative evidence of an Event. Change: Introduction of the term "Event", and the tutorial omitted. |
Event |
An
activity, capability, course of action, vulnerability, intention, or
characteristic of the Area of Interest. The generic name for whatever an "Indicator" is
indicating positive or negative evidence of!! |
|
LTIOV - Latest Time Information of Value |
The
time by which information must be delivered to the requestor in order to
provide decision makers with timely intelligence. Sometimes the LTIOV is the
expected time of a decision anticipated during staff wargaming and planning.
If someone other than the decision maker must first process the information,
the LTIOV is earlier than the time associated with the decision point. The
time difference accounts for delays in processing and communicating the final
intelligence to the decision maker. (FM 34-130, dtd Nov 93) |
No
Change. However, the opposite concept
is the newly-introduced "ETWEC"... |
ETWEC |
Earliest Time We Even Care. I coined this term because sometimes it doesn't do us any good to find out things too early. |
Relationships between the
Tools
Now that we have
working definitions of the terms, it is important to establish the
relationships between the terms.
The concept of specifically defining relationships is almost totally
absent from US Army Doctrine, yet the relationships are what permit the
transition from a fuzzy art to a precise science.
Defining
Relationships
A great software tool to automate this process is the MS Access Relational Database Management System (RDBMS), so let's look at the three relationships possible in a relational database.
A One-To-One relationship...
is when you have two lists, and every item in the First List
is related to just ONE item in the Second List, and every item in the Second
List is related to just ONE item in the First List. For example, a List of Soldiers and a List of Social Security
Numbers. Each Soldier has only ONE SSN,
and each SSN belongs to only ONE Soldier.
A One-To-Many relationship...
is when each item in the First List can be related to many
items in the Second List... but each item in the Second List is related to just
ONE item in the First List. For
example, a List of Companies within the 101st MI BN, and a List of Soldiers
assigned to the 101st MI BN. One
company will have many soldiers, but each soldier will be assigned to just ONE
company.
A Many-To-Many relationship...
is when each item in the First List can be related to many items
in the Second List, and each item in the Second List can be related to many
items in the First List. For example, a
List of Soldiers and a List of Deployments.
Each Soldier can participate in MANY Deployments, and each Deployment
will require MANY Soldiers.
Relating the Tools
Intelligence Requirements become Priority
Intelligence Requirements while they are assigned to trigger a
Decision Point (DP) or a critical High Payoff Target (HPT). Each DP or HPT must be triggered by just ONE
PIR in order to avoid confusion.
However, a PIR can be used to trigger more than one DP or HPT. For example, the PIR that triggers the DP to
send the Attack Helicopters into EA KILL might provide sufficient intelligence
to trigger the DP that will reposition the reserve.
PIRs (and IRs) are broken down into Specific Information Requirements (SIR) when they can't be answered by a single collector looking at a single NAI. For example, at the National Training Center it is possible for a commander to position himself so that he can SEE when the lead enemy tank battalion comes through the pass, so the PIR "When will the lead enemy tank battalion clear The Pass?" doesn't need a set of SIRs. However, if the PIR is "Will the lead enemy tank battalion use This Pass or That Pass?", the set of SIRs would be: 1) "Will the lead enemy tank battalion use This Pass?", and 2) "Will the lead enemy tank battalion use That Pass?".
A PIR can (and usually does) have several related SIRs. However, an SIR can be related
to more than one PIR when both PIR share an Indicator! For example, you create a PIR to determine
when the next MI Captains Career Course is starting, and one SIR is to watch
the Class 6 store for a 20% increase in the sales of Guinness Stout Beer. A you create a second PIR to determine
when the Allied Officers Basic Course is starting. Because there will be 3 Irish officers attending that course, the
same SIR applies.
Named Areas of Interest (NAIs) are created to focus
collection on a specific spot. Doctrinally,
the NAI is a component of the SIR. But
sometimes it is useful to relate the NAI to a Collector. For example, a Long Range Surveillance team
is already deployed, observing an NAI that is useful for the coming
battle. To allow for this possibility,
I have related the NAI directly to the SOR.
An SOR can have only one NAI, but an NAI may be included in many SORs.
Traditionally, NAIs are geographic points or areas, but there are additional techniques that can be very useful. For instance:
a. Linear, as in a line the enemy must cross, or a path the enemy might follow.
b. Spatial, as in a box the enemy might fly or swim through.
c. Relative, for instance 5 km behind the lead element.
d. The population of ethnic Kazars.
e. At IP address 127.0.0.0
g.. Within a specific SIPRNET database
Those last three NAIs probably look a bit weird to those
folks who do all their training at the NTC or within a BCTP command post
exercise! However, NAIs are a
means to an end, and that end is construction of a set of SORs. Note again the definition of an SOR:
"The order or request that generates planning and execution of a
collection mission or analysis of data base information." This is a useful definition, and very
insightful to have been included in the 1993 Collection Management FM!
The Specific Order or Request (SOR) = SIR + NAI + Collector + Start-Stop
times. For instance, Scout Team 1
moves to where it can see NAI 4 (The Pass) during the specified time period in
order to answer the SIR "When will the tank battalion clear The
Pass?". The relationship between
the SOR and it's three components are One-To-Many: each SOR is related to just
ONE SIR, ONE NAI, and ONE Collector.
But a Collector, NAI, or SIR can be related to many SORs... how many
depends on the specific collector, NAI or SIR.
The Start - Stop times for collection are part of the SOR itself. The Stop Time is the Latest Time Intelligence Of Value (LTIOV) minus whatever time you determine must be spent analyzing the information. So if it will take you 30 minutes, and the LTIOV is 2230 hrs, then Stop Time will be 2200 hrs. Collecting after the Stop Time will produce information that cannot be transformed into Intelligence in time to effect a decision. The Start Time is computed the same way: the Earliest Time We Even Care (ETWEC) minus analysis time. So if ETWEC is 0900 and analysis time is 30 minutes, then Start Time is 0830 hrs.
What? You want to know why I came up with that non-doctrinal, irreverent ETWEC concept?! It is logical that if you can receive information too late to do any good, you can also receive it too early to do any good.
For example, an enemy brigade is expected to cross an international border to conduct a raid. You are permitted to attack that force once it crosses, but not before. The force consists of motorized infantry protected by ten SA-15s, very lethal antiaircraft weapon systems. The commander wants the SA-15s located, and at that time will dedicate all artillery to their destruction. Great! You know where they are right now! They are sitting in the Karl Marx Motor Pool just across the border! Nice... but who cares? The decision won't be made until AFTER they cross the border. If you had unlimited collectors and analysts you might keep a 24-hour watch on them. But face it, you have MANY other PIRs and IRs to answer, and just can't afford it.
But What About...
Events and
Indicators.
The relationship between Event and Indicator is similar to
that between PIR and SIR. One Event can
be related to many Indicators, and one Indicator can be related to many
Events.
For instance, the Event "Start of MI Captains Career Course" might have indicators like "Clothing Sales Store Crowded", "Classroom Parking Lots Full", and "Shortage of High Quality Beer". Note that some of these might be indicators of some other Event, for instance the start of the Pre-Command Course. An analyst can assign a probability to an indicator to help determine which Event is being Indicated. For example, a "Shortage Of High Quality Beer" is a Very Good indicator that the highly paid Colonels of the Pre-Command Course are in town; in fact, confirming this indicator gives us a 75% probability that the Pre-Command Course IS starting! But for the lower-paid Captains, confirming this Indicator only gives us a 35% probability that the MI Captains Career Course has started.
While PIR-SIR sets are very much associated with the current
situation, Event-Indicator sets are closely related to a Threat Model or Doctrinal
Template. They are generic, and ideally
are created far in advance of the mission.
Ancient Field Manuals (from before 1991) often had Indicator Lists for
such Events as "Enemy Offense", "Enemy Defense",
"Nuclear Attack, etc. To use
them, they must be related to the current mission and its intelligence needs:
an Event can be related to many PIR, but a PIR is related to only one
Event.
This
restriction maintains the focus of the PIR.
An Indicator can be related to many SIRs, and each SIR can
be related to many Indicators.
Remember that this is not a flow chart, a PERT diagram, or any type of process map. It is a Relationship Diagram, and specifies the relationships between the different categories of information that we call PIRs, SIRs, SORs, and so on. Visualize each of the above categories as a separate spreadsheet, or table of information. Because we have related these tables, we can insert or extract information any way we choose.
This demonstrates the power of the Relational Database over the simple spreadsheet solutions found in our doctrine! Specifically, the database doesn't care how you build the SOR. For example...
1. You can build the SOR from scratch by combining one SIR and one NAI and one Collector.
2. You can first pair Collectors with the NAIs they are currently observing, and then assign each pair one or more SIRs.
3. You can pair SIRs with the Collectors best suited to gather that type of information, and then assign the pair to one or more NAIs predicted in the Event Template.
4. You can pair SIRs with the NAIs per the predictions within the Event Template, and then assign each pair the Collector best suited to collect that information.
5. You can do all four of these techniques at the same time! Start by pairing deployed collectors with their NAIs. Then pair SIRs to NAIs per the Event Template. Then take a couple SIRs that clearly require specific collectors and pair those. Then switch to the "Build From Scratch" view to fill in the blanks.
The database doesn't care. Because the tables are specifically related, the information flows to the appropriate place in the appropriate table, and pressing the Report button causes it to flow back out to produce your Collection Plan!
This isn't theory... the Demo Database that accompanies this article does it.
Exhale - Inhale
Never forget that the purpose of all the above is to produce Intelligence that is useful for battle planning and decision making. You mentally digested the Intelligence Requirements of your unit and exhaled a bunch of Collection and Analysis requirements in the form of SORs. Throughout the Collection and Analysis process you will inhale combat information that must be mentally digested and converted into the Intelligence that was Required for a Decision. The "exhaled" structure of SORs will determine the quality and appropriateness of the information you will later "inhale". Ask the wrong questions of the wrong people and you might be able to create the answer to the PIR... eventually!
Therefore the entire process of Focusing Intelligence, with its vast array of automated tools must itself be focused on the act of Intelligence Production.
But...
Before we can discuss the mechanics of Intelligence Production, we need to look at how intelligence is actually used. Since the purpose of intelligence is to support decision making related to battle planning and execution, the next article will address the nature of decision making, its relationship to Intelligence Consumption, and an initial approach to the formulation of an Intelligence Consumption Rate.
Copyright 2001, The S2 Company, all rights reserved.