Tom Briggs is a former CIA clandestine case officer with an excellent book to his credit, Cash on Delivery: CIA Special Operations During the Secret War in Laos (Rosebank Press, 2009). Before joining CIA he was the Acting Provost Marshal (sheriff) for 25,000 US personnel operating in Cam Ranh Bay, Viet-Nam.
Robert,
As I hope you remember, I started my time in info technology in requirements after many years in operations. I learned that when you ask someone what his requirements are he most often begins to include his solutions, e.g. we need a computer database to help us keep weapons from being smuggled into this country. My response was you don't know if you need a computer until you tell me what data you have, what data you might be able to collect but are not collecting, and what questions you want to ask that the data might be able to help you answer. It was hard to keep them off solutions and focused on what they knew and what they wanted to know. As I read Part IV, 01 Requirements Definition, I thought of my experience and wondered whether the definitions were being simplified to their very basics. A colleague and I wrote the very first requirements for automating the DO. When the IBM programmers with the contract read them they sneered and said, ‘these are high level requirements, we need to have the requirements that tell us exactly how to build the automated system'. My colleague and I said, if you don't understand the high level requirements, how can you begin to write the specific requirements? Thus, the first specific things that were developed for the automated DO system were faulty in many ways. The programmers excluded my colleague and I from their deliberations as THEY wrote the specific requirements, and no one in management thought there was anything wrong with that.
My colleague was the one who named the highest level requirements. He called one ‘author'. He didn't say we needed to write cables, or memos or whatever, he said we needed a computer based author capability and proceeded to outline in general the authoring needs. I don't remember the other 4 or 5 categories but they were similar.
So, I wonder if we really ‘assign' requirements to humint or osint or techint? Should we have ‘high level' requirements from policy makers or military commanders and then figure out which int can collect on them, or, let them all collect and see whose information is the most relevant and useful? I am talking mostly about operations, but except for acquisition of which I know not much, I think I am also talking to strategy and policy.
I read through your ‘conversation' once and the above represents the one thing I wanted to say right away. There are other things to say, but I can't do it in well ‘fell swoop' as you often do. I need to rest to read your ‘conversation' again and see what else I might add.
Almost any problem you can name in the intel community begins with bad management. Even if you have an excellent manager, it is only until he moves on, and the odds are good he will be replaced with a much lesser manager. I guess I tend to have a negative attitude.
That's all for now.
-Tom
Phi Beta Iota: Emphasis added. What has become clear over the past 40 years is that the US intelligence community is no longer managed, it is “clerked.” Managers are poorly educated, out of touch with reality, and more or less operating on automatic pilot folllowing predecessor models. “This is what we have always done.” Along the way nuances are lost, the ability to do original thinking is lost, and we end up with a bureaucracy whose primary purpose is to perpetuate itself and ideally to expand so the top clerks can get yet one more promotion. No one is actually focused on outcomes — on being so compellingly relevant to strategy, policy, acquisition, and operations that they cannot be ignored as they are now.
