In a recent article titled Gaps in ICS Doctrine and Documents my colleague Tim Riecker points out the lack of cohesive doctrine in the Incident Management System. He writes that while we have some basic guidance in documents such as the National Incident Management System document and the National Qualification System, there is a lack of definition of key concepts, inclusion of contemporary practices, and continuity from doctrine into supporting documents and training.
As is usually the case, I agree with Tim completely on his assessment. Further, his article sparked some ideas about why this is the case. I suggest that it comes down to three factors: the use of consultants to develop much of our guidance documents, the project managers who oversee their work and our own lack of involvement in the process.
Before you think I’m going to hammer on consultants, let me remind you that I have been a consultant for over twenty years and have been fortunate to work with exceptional individual consultants and with several reputable firms. The issue is not necessarily the consultants but the government’s system of breaking initiatives into multiple projects. This means that frequently consultants are called on to build on work done by a previous consulting team, whether they agree with the previous approach or not. Often you find yourself working on a project that might affect or be affected by one handled by another consulting team without knowing that project exists. There is also the problem with changes to the project management team where the new project manager may want to take things in a different direction or chooses not to accept your advice on how best to achieve the project goals.
As a consultant I usually perform one of two roles. I may be part of a team as a subject matter expert because of my knowledge of an issue or possession of a specific technical skill. As a solo consultant, I am what is known as a process consultant. I guide clients through the development of policies and procedures to achieve their desired goals. Understanding this will help you understand why we are weak in the development of ICS doctrine.
As I’ve pointed out in the past, we can define three very broad categories when dealing with disaster response planning: strategic, operational, and tactical. Strategy provides the overall context in which other plans function. The operational level translates strategy into action by coordinating the resources needed to achieve goals and objectives. The tactical level is where the actual provision of services takes place. In terms of emergency response, the tactical level is the on-scene response, the operational the emergency operations center, and the strategic the Multiagency Coordination Group or policy group. Problems arise when you mix up the roles of the various levels in plans or guidance documents.
If we look at documents such as the National Response Framework, these are strategic documents. They establish the operational context that will drive the development of supporting plans and documents. They deal with concepts rather than specifics. For a process consultant, this is the type of project we love. While it can be complex and challenging depending on the stakeholders involved, the methodology and end product are similar to previous projects.
Jumping ahead to the purely tactical, we have an excellent example in the National Qualification System. This type of project is also one that consultants enjoy because a lot of the work is repetitive and can be done by entry-level consultants or clerical staff with work laid out and verified by subject matter experts. Like strategic projects, the work can be complex and sometimes tedious but is well within the capabilities of consulting teams and plays to their strengths.
The operational becomes more problematic, however. A strategic document is by nature a “one size fits all” document. The same can be said of a tactical document like the NQS where the intent is to standardize the requirements for anyone filling a specific position. An operational document does not share this “one size fits all” trait. It must be generic enough to provide for the standardization called for in NIMS yet flexible enough to allow modifications to adapt to local circumstances. Developing these documents usually involves significant input from subject matter experts, which increases the cost and complexity of the project. It is no wonder then that we see a gap within operational guidance.
Given these limitations on consultants, the role of the program managers overseeing their work becomes extremely important. However, one cannot assume that these program managers always have sufficient knowledge and experience to guide these complex programs. Practical field experience in emergency management is not a qualification a position in FEMA. There are exceptions, of course, and this is not intended to denigrate the hard work done of these projects by agency staff who are forced to learn on the job. It is instead an acknowledgement of problems in the system.
How do we correct this? Actually, the approach that FEMA uses is a good one - ask those who will use the product. FEMA releases draft documents for public comments. However, my experience is that many emergency managers are not signed up to receive notifications and those that do are frequently too busy to take the time to read and comment on drafts. We need to do better at pushing back on proposed guidance or doctrine that do not tally with our practical experience.
More importantly, we need to recognize that much of what we assume is doctrine is, in fact, guidance. Many existing documents provide principles rather specific direction and provide a degree of flexibility in following those principles. Slavishly conforming to a guidance document to the detriment of your ability to adequately respond to a crisis does no one any good.
