3 Things You Must Know Before You Discuss Intelligence Requirements With A Decisionmaker

One of the most important tasks of virtually all intelligence professionals is the ability to sit down with their organization's decisionmakers and get meaningful intelligence requirements from them.  Getting requirements that are too vague or poorly designed make the intelligence professional's life more difficult.  More importantly, bad requirements often lead to analysis that fails to meet the decisionmaker's real needs and can, in turn, lead to the organization's failure.

All that makes perfect sense, right?  Getting a good answer to a question implies that the question is clear, that I understand the question and that I have the ability to answer it.  If I ask you, "What time is the movie?" then you are well within your rights to ask me, "Which movie?"  Good requirements emerge from a conversation; they aren't dictated through a megaphone.

Outline of this post (Trying something new here.  Let me know in the comments if you like it!)

Having this kind of requirements discussion is much more difficult in the context of intelligence, however, and not only because the questions are usually much more complicated.  There are a number of reasons for these challenges:

• Chain of command.  Typically, intel officers work for the decisionmaker.  Even with the best of DM's, there is often a real reticence to poke at the requirement, to make suggestions about how to make it better or to question whether it is worth addressing at all.  While it is true that pushing the DM for clarity on his/her requirements statements is "just part of the job", it does not make the situation any less challenging. 
• Lack of understanding about intel.  Most decisionmakers rise up through operational channels.  This means that decisionmakers are usually much more comfortable with operational questions (I.E. What are we going to do with the resources under our control?) than with intelligence questions (I.E. What is happening that is critical to our success or failure but outside of our control?).  Even in the national security realm, where the intelligence function is typically much better understood than in law enforcement or corporations, there is often a lack of understanding or even a misunderstanding of how intelligence supports the organization's decisionmaking process.  
• Ops/Intel Conflation.  While there are good reasons to keep many operational discussions and intelligence discussions separate, that is not the way the decisionmaker is likely to think.  Responsible for integrating intelligence analysis with operational capabilities and constraints, decisionmakers are likely to conflate the two as they talk about requirements.  It is up to intelligence professionals to untangle them in such a way that they have a clear statement of their requirements. 
• Lack of decisionmaker clarity.  Decisionmakers don't know what they don't know and good decisionmakers worry about that - a lot.  Even when decisionmakers fully understand intel, it is possible for them to have only a vague notion of what they want or need.  Particularly with strategic-level concerns, good DMs will be constantly asking themselves, "What questions should I be asking right now?" and worrying about wasting time and energy chasing an irrelevant question down a rabbit hole.

With this as background there are three essential questions that intelligence professionals should ask and answer before they begin a discussion about requirements:

1. What does the organization do?  At first glance this seems ridiculous.  How could you work for an organization and not know what it does?  You'd be surprised.  Even small organizations often appear to do one thing but actually spend much of their time or make most of their money doing something entirely different.  When I was younger, for example, I worked for a company called Hargrove's Office Supplies.  You would be excused for thinking that we made our money selling office supplies.  In fact, Hargrove's made most of its money in those days selling and servicing business machines - a very different kind of business.  This problem becomes much more acute in large organizations with many moving parts.  It is worth the intelligence professional's time to get to know the organization it is supporting in some detail - everything from strategic plans to tactical practices.  While the intelligence professional will never be as knowledgeable as the operators running the organization, the more intel professionals knows about the goals and purposes of an organization, the more productive the requirements process will be.
2. What is the current strategy and situation of the organization?  If the first question is what does the organization do, then the second question should be "How does it do it?"  All organizations have a strategy (even if it is only an implicit one) and it is worth it to take time to consider what that strategy might be.  It is also worth thinking about the current situation in which the organization finds itself.  Is the organization winning or losing?  Successful and growing or failing and losing ground against its competitors? While the situation of the organization should not matter in terms of the analysis - it is what it is - understanding how an organization is doing helps understand where a requirement is coming from and gives insight into how to focus the answer.
3. Who is the decisionmaker?  This is another simple question with a complicated answer.  It is tempting to believe that the person or organization asking the question is the one who wants the answer.  That is not always the case.  Oftentimes, the real decisionmaker is one or more levels removed from the person asking the question of the intelligence unit.  In this case, it makes sense for the intelligence professionals to ask themselves what the the real decisionmaker wants.  In the accelerating pace of the intel world, it is entirely possible that the requirement has gone through an elaborate version of the kid's game Telephone and now bears no relationship to what the real decisionmaker wants.  Even if it does, it is still worth thinking about the kind of answer that will meet the needs of not only the gatekeeper but also of the decisionmaker behind the gate.  Finally, even if there is no gatekeeper, it is worth thinking about others who might not have asked the question but will be able to see the answer.  Almost nothing get done in a vacuum.  Even the most siloed of programs often have multiple members with different intelligence needs.  It is important, therefore, to consider who these second and third level audiences might be before crafting the requirement in order to provide clarity and prevent confusion and mission creep.

All this advice is great for when intel professionals have the luxury of actually meeting with the decisionmakers they support.  How do you deal with a situation that is entirely virtual or managed through an automated requirements management system like COLISEUM?  Don't worry, we will get to all of that later in the summer!