 |
| "Jeeves, I am fairly certain that is not what Prof. Wheaton had in mind when he said we need to constrain the requirement." |
I have already written about how to prepare for an intelligence requirements meeting and about how to deal with a virtual intelligence requirements environment.
You can also see the first four articles on things to think about when having a requirements meeting with a decisionmaker (DM) at the links below:
1. Does the DM really want intelligence?
2. What kind of intelligence is the DM looking for?
3. What are the DM's assumptions?
Today, I am writing part five and six of this six part epic discussing what intel professionals need to think about when they are actually in the meeting, talking to a decisionmaker about his or her requirements.
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:
- 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!
Next: Four Things You Must Do After A Requirements Meeting
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!
Next: Four Things You Must Do After A Requirements Meeting
