Focusing Intelligence Pt 2

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)	The order or request that generates planning and execution of a collection mission or analysis of data base information. 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.

The Author