 |
| An intel professional successfully gets everything he needs from a DM in a requirements briefing. Guess which one is the unicorn... |
I have already written about how to prepare for an intelligence requirements meeting and about how to deal with a virtual intelligence requirements environment. In this post, I pull all of those pieces together and outline the six things I think an intelligence professional needs to consider while discussing requirements with a decisionmaker (DM).
1. Does the DM really want intelligence?
It goes without saying that an organization's mission is going to drive its intel requirements. Whether the goal is to launch a new product line or take the next hill, decisionmakers need intel to help them think through the problem.
Unfortunately, DMs often conflate operational concerns ("What are we going to do?" kinds of questions) with intel concerns ("What is the other guy going to do?" kinds of questions). This is particularly true in a business environment where intelligence as a distinct function of business is a relatively new concept.
Good intelligence requirements are typically about something which is important to an organization's success or failure but which is also outside that organization's control. Good intelligence requirements are, in short, about the "other guy" - the enemy, the competitor, the criminal - or, at least, about the external environment.
Intelligence professionals need to be able to extract intelligence requirements from the broader conversation and play them back to the DM to confirm that both parties understand what needs to be done before they go to work.
 |
| "And what kind of intelligence would the gentleman prefer today?" |
There are two broad (and informal) categories of intelligence - descriptive and estimative. Descriptive intelligence is about explaining something that is relevant to the decision at hand. Estimative intelligence is about what that "something" is likely to do next. It is the difference between "Who is the president of Burkina Faso now?" and "Who is the next president of Burkina Faso likely to be?"
Estimative intelligence is obviously more valuable than descriptive intelligence. Estimative intelligence allows the DM and his or her operational staff to plan for the future, to be proactive instead of reactive. Surprisingly, though, DMs often forget to ask for estimates regarding issues they think will be relevant to their decisions. It is worth the intelligence professionals time, therefore, to look for places where an estimate might be useful and suggest it as an additional requirement.
While I am never one to look for more work, the truth is that descriptive intelligence is becoming easier and easier to find. The real value in having dedicated intel staff is in that staff's ability to make estimates. If all you do is what computers do well (IE describe) then you run the risk of being downsized or eliminated the next time there is a budget crunch.
 |
| "I challenge your assumptions, sir!" |
There are three kinds of assumptions intelligence professionals need to watch for in their DMs when discussing requirements:
- About the requirement
- About the answer to the requirement
- About the intel team
Consider this requirement: "Will the Chinese provide the equipment for the expansion of mobile cellphone services into rural Ghana?" The DM is clearly assuming that there is going to be an expansion of cellphone services. That doesn't make it a bad requirement but analysts should start by checking this assumption.
Note also that the DM did not frame the question as "Who is going to provide the equipment...". Rather, he or she highlighted the potential role of the Chinese. This kind of framing suggests that the DM thinks he or she already knows the answer to the requirement but just wants a "double check". Other interpretations are possible, of course, but it is worth noting if only so the intelligence professionals working the issue don't approach the problem with blinders on.
Finally, it is also important to think about the assumptions the DM has about the team working on the requirement. What does the DM see when he or she looks out at our team? Are we all young and eager? Old and grizzled? Does our reputation - good or bad - precede us? Finally, is the DM asking the "real" requirement or just what he or she thinks the team can handle? Not getting at the real questions the DM needs answered is a recipe for failure or, at least, the perception of failure, which is probably worse.
4. What does the DM mean when he/she/they say "x"?
 |
| "Hic sunt dracones!" |
"I'm worried about Europe. What moves are our competitors likely to make next?" This is a perfectly reasonable request from a decisionmaker. In fact, if you are in a competitive intelligence position for a larger corporation, you have likely heard something close to it.
While reasonable, it is the kind of requirements statement that is filled with dragons for the unwary. Not the least of these dragons is definitional. When the DM said "competitors" did he or she mean competitors that reside in Europe or competitors that sell in Europe or both? And what did he or she mean by "Europe"? Continental Europe, the EU, western Europe, something else?
Listening carefully for these common words that are actually being used in very specific ways or are, in a particular organization, technical terms is a critical aspect of a successful requirements meeting. If the intelligence professional has a long history with a particular decisionmaker then these terms of art may be common knowledge. Even in this case, however, it is worth confirming with the DM that everyone shares this understanding of these kinds of words.
That is why I consider it best practice to memorialize the requirement in writing after the meeting and to include (usually by way of footnote) any terms defined in the meeting. In addition, if certain terms weren't defined in the meeting but the intel professional feels the need to define them afterwards, I think it makes sense for the intel professional to make their best guess at what the DM meant but then draw specific attention to the intel professional's tentative definition of the term in question and to seek confirmation of that definition with the DM.
This may sound like a convoluted process, but, as I tell my students, not getting the requirement right is like building a house on the wrong piece of property. It doesn't matter how beautiful or elegant it is, if you build it on the wrong piece of property you will still have to tear it down and start all over again. The same holds true for a misunderstood intelligence requirement. Get the requirement wrong and it doesn't matter how good your answer is - you answered the wrong question!
While reasonable, it is the kind of requirements statement that is filled with dragons for the unwary. Not the least of these dragons is definitional. When the DM said "competitors" did he or she mean competitors that reside in Europe or competitors that sell in Europe or both? And what did he or she mean by "Europe"? Continental Europe, the EU, western Europe, something else?
Listening carefully for these common words that are actually being used in very specific ways or are, in a particular organization, technical terms is a critical aspect of a successful requirements meeting. If the intelligence professional has a long history with a particular decisionmaker then these terms of art may be common knowledge. Even in this case, however, it is worth confirming with the DM that everyone shares this understanding of these kinds of words.
That is why I consider it best practice to memorialize the requirement in writing after the meeting and to include (usually by way of footnote) any terms defined in the meeting. In addition, if certain terms weren't defined in the meeting but the intel professional feels the need to define them afterwards, I think it makes sense for the intel professional to make their best guess at what the DM meant but then draw specific attention to the intel professional's tentative definition of the term in question and to seek confirmation of that definition with the DM.
This may sound like a convoluted process, but, as I tell my students, not getting the requirement right is like building a house on the wrong piece of property. It doesn't matter how beautiful or elegant it is, if you build it on the wrong piece of property you will still have to tear it down and start all over again. The same holds true for a misunderstood intelligence requirement. Get the requirement wrong and it doesn't matter how good your answer is - you answered the wrong question!
5. What constraints is the DM willing to put on the requirement?
I once had a DM who was looking to expand his local business and asked for a nationwide study. His business was based on serving local customers and he did not have the resources to go nationwide and yet...
Decisionmakers are notoriously reluctant to put constraints on requirements. They worry that, if they do, just on the other side of whatever bright line they think they have drawn, there will be a perfect customer for their business, a critical fact that lets them make a foolproof plan to defeat the enemy, or the key piece of info that solves all their problems. I call this the "pot of gold" syndrome and it afflicts every decisionmaker.
This worry, of course, blinds these same decisionmakers to the inevitable problem this approach causes: Given the constant limitations on time and resources, trying to look everywhere makes it difficult for the intelligence unit to look anywhere in depth. Knowing the areas that are of genuine interest and can genuinely support the decisionmaker helps get the most out of the intelligence effort. Likewise, knowing where you don't need to look is equally helpful.
There are at least six different kinds of constraints that intelligence professionals need to address when engaged in a discussion about requirements:
 |
| "Jeeves, I am fairly certain that is not what Prof. Wheaton had in mind when he said we need to constrain the requirement." |
I once had a DM who was looking to expand his local business and asked for a nationwide study. His business was based on serving local customers and he did not have the resources to go nationwide and yet...
Decisionmakers are notoriously reluctant to put constraints on requirements. They worry that, if they do, just on the other side of whatever bright line they think they have drawn, there will be a perfect customer for their business, a critical fact that lets them make a foolproof plan to defeat the enemy, or the key piece of info that solves all their problems. I call this the "pot of gold" syndrome and it afflicts every decisionmaker.
This worry, of course, blinds these same decisionmakers to the inevitable problem this approach causes: Given the constant limitations on time and resources, trying to look everywhere makes it difficult for the intelligence unit to look anywhere in depth. Knowing the areas that are of genuine interest and can genuinely support the decisionmaker helps get the most out of the intelligence effort. Likewise, knowing where you don't need to look is equally helpful.
There are at least six different kinds of constraints that intelligence professionals need to address when engaged in a discussion about requirements:
- Geography. What are the limits to how far we need to look? Where can we draw lines on our maps? Geography is used loosely here, by the way. Understanding and constraining the "market landscape" or the "cyber landscape", for example, also fall within this guidance.
- Time. How far forward do you want us to look? Every problem has a "predictive horizon" beyond which it is hard to see. Moreover, you will likely see a good bit more detail with a good bit more confidence if you are looking one month out instead of 10 years out.
- Organizational units. At what level does the DM want the analysis? Am I looking at industries, companies or departments within companies? Countries, regions, or continents?
- Processes, functions. Are there certain processes or functions of the target that the DM cares more about than others? Are there processes or functions that we could ignore? For example, imagine a company that doesn't care how its competitor manages its HR but really wants to know about its supply chain.
- People. Which people in the target organization are most important to the DM (if any)? Are we looking at the government of a country or the president of a country? A competitor or the CEO of that competitor? Obviously, "both!" might be right answer but asking the question makes it clear to both the DM and the intel unit.
- Money. Are there amounts of money about which we do not care? Do you want me to try to look at every drug transaction or just the large ones? Is every act of bribery, no matter how trivial, really worth spending the time and energy on in a study of a country's level of corruption? Again, the answer in both cases may be "yes!" but without asking, the intel unit runs the risk of failing to provide the level of analysis the DM wants and will almost inevitably waste time analyzing issues that the DM cares little about.
6. What are the DM's priorities?
In any sort of robust requirements discussion, it is normal for many more requirements to emerge than the intelligence unit can handle. Rather than complain about all the work, a better way to handle this is to get the DM to state his/her priorities.
I have worked with hundreds of DMs and all of them understand resource constraints. Even with quality intel analysis, I have often seen teams disappoint a DM when they have to say, "We didn't have time/money/people to get to all of your requirements." I have never, however, seen a DM disappointed when that team can say, "We didn't have time/money/people to get to all of your requirements, but we were able to address your top 5 (or 10 or whatever) requirements."
The key to being able to address the top priorities, however, is knowing what they are. As with all constraints, DMs are typically hesitant to prioritize their questions. They may feel that they do not know enough to do so. They may also be worried that the intelligence unit will put on blinders such that they will only look at the priorities and forget to keep an eye out for unexpected threats and opportunities.
One of the keys here is to not make assumptions about priorities. Even if the DM sends the team a numbered list, it makes sense to go back and ask, "Are these in priority order?" Almost every time I have asked that question - forcing the DM to actively think about their priorities - I get changes to the order. Likewise, just because a DM talks a lot about a certain issue, do not assume that it is the top priority. It may just be the most recent thing that has come up or a new idea that the DM just had. Asking, "We have talked about X quite a bit. Is this where you would like us to focus?" is still important.
Priorities are an enormously powerful tool for an intelligence unit. They allow the unit to focus and to make tough decisions about what is relevant and what is not. Don't leave your requirements meeting without them!
In any sort of robust requirements discussion, it is normal for many more requirements to emerge than the intelligence unit can handle. Rather than complain about all the work, a better way to handle this is to get the DM to state his/her priorities.
I have worked with hundreds of DMs and all of them understand resource constraints. Even with quality intel analysis, I have often seen teams disappoint a DM when they have to say, "We didn't have time/money/people to get to all of your requirements." I have never, however, seen a DM disappointed when that team can say, "We didn't have time/money/people to get to all of your requirements, but we were able to address your top 5 (or 10 or whatever) requirements."
The key to being able to address the top priorities, however, is knowing what they are. As with all constraints, DMs are typically hesitant to prioritize their questions. They may feel that they do not know enough to do so. They may also be worried that the intelligence unit will put on blinders such that they will only look at the priorities and forget to keep an eye out for unexpected threats and opportunities.
One of the keys here is to not make assumptions about priorities. Even if the DM sends the team a numbered list, it makes sense to go back and ask, "Are these in priority order?" Almost every time I have asked that question - forcing the DM to actively think about their priorities - I get changes to the order. Likewise, just because a DM talks a lot about a certain issue, do not assume that it is the top priority. It may just be the most recent thing that has come up or a new idea that the DM just had. Asking, "We have talked about X quite a bit. Is this where you would like us to focus?" is still important.
Priorities are an enormously powerful tool for an intelligence unit. They allow the unit to focus and to make tough decisions about what is relevant and what is not. Don't leave your requirements meeting without them!
