Survival Planning--More Than Just Gear and a "To Do" List, by Ray

A lot of people tend to approach survival planning as a simple exercise in gathering stuff and making a "to do" list. Having the right supplies and equipment is important, as is prior planning. But there may be a way to optimize your post collapse/disaster actions. I'd like to talk about the concept of the decision making aspects of survival. Decision making is the "Why" that joins the "What" (As in "Here's what we're going to do...") to the "How" (As in "...and here's how.") All the gear and knowledge in the world do you no good if you don't think your actions through before you act. Right up front, I'd like to acknowledge that a large part of these thoughts are drawn from various decision-making training that I've been exposed to, not the least of which is the OODA Loop, conceived by Col. John Boyd. The simple fact is decision making is a skill, and not one that naturally occurs for most people. But it is one that can be learned. The ability to calmly and objectively make the best decision in a given circumstance is largely the cultivated skill of learning to quickly sift through data in a systematic way in order to evaluate the available options.

Your plan is really a string of objectives, culminating with a desired end state; safely at your retreat, family accounted for and well, property secured. Decision making is critical in determining what actions to take to move you closer to a particular sub-objective or your ultimate goal. All decisions are based on the probability of a favorable outcome, but that probability is rarely, if ever, 100%. Even a slam-dunk, no-brainer decision has some slight chance of failure. The validity of a choice can be measured as those choices with the highest probability of a positive outcome, but even those have a tangible risk of turning out badly, and thus not being ultimately "correct." Poker players call it getting "cracked", when a strong, high probability hand is still beaten by the luck of the draw. A decision maker should understand that no decision is guaranteed to produce a positive result. Setting the expectation for yourself that even well thought-out decisions will be 100% successful is the road to disappointment and frustration. This is because decisions have variable dimensions, most of which are beyond the average person's ability to control or even be fully aware of. The validity of a given choice is a function of the available data, context, and time. A valid decision is the best one you can make, right now, with the available information. Five minutes (heck, 30 seconds) from now a different choice may be better. But realize you will never have perfect, complete, and timely data, and that's assuming that no one else is actively interacting with the situation, changing it and invalidating your information, or actively generating/feeding disinformation in some form. You will bring some level of bias to you we interpret the given dataset, as do your information sources; this works against our being able to form the proper context for a decision. And all factors are in flux, changing constantly; and implementing a choice once made takes some measure of time, making the clock an enemy. A good decision making process has to exist in the here and now, and be forward looking. You must avoid self recrimination and the tendency to doubt after something bad has happened; past choices are in the past, and useful only for how they inform future decisions. Focus on your goal, and how you get from your present location/situation (the here and now) to there (your future goal.)

The point of a decision is to generate a course of action. The objective validity (or lack thereof) is measured by the actions facility to meeting your desired end state – your ultimate goal. Decisions should be framed in terms of the what/why/how of the chosen action;
* What action do you think you need to take?
* Why are you taking this action?
* How (exactly) do you intend to accomplish this action?
Systematically examining your choices with the same criteria will let you determine their relative validity. Define the choices; state their goals and success or failure conditions, and reasonable prediction of the consequences of either. Is the objective critical or merely preferable/optional? How does it advance your larger goal? Do you have the means to accomplish it, and do those means require external help, or "a bit of luck"? What can go wrong? Once you've got answers for those questions, congratulations, you've just done simple risk analysis. Large and complex courses of action should be broken down to simpler action components to make them easier to analyze. It really should never be left at "…then we'll head to the retreat…"; that action has tons of smaller actions and tasks that need to be accomplished to make it happen. Addressing that as a whole is almost guaranteed to under analyze one of those components, thus jeopardizing the overall chances of success. Part and parcel with a decision (part of the "How") is the subdivision into logical action/decision chunks and delegating, communicating, or performing the required sub-task/making a required subordinate choice as quickly as possible. A seasoned decision maker may look like they're making snap choices, but a good one has just internalized and sped up the pace at which the decision loop occurs.

Weighing the long list of variables can make for complex decisions. However, you can take a few shortcuts by using what I'll call "filters" or rules of thumb. Think of these as decision constants; chunks of the equation where the math's already been done. There are reasons why these are the case, and it's interesting to learn the reasoning behind them, but for our discussion, it suffices to say that these are truisms that generally hold up pretty well. A few of my favorites are:

1.) Decisions where the outcome leaves you more future options are generally preferred over those with less.
2.) A decision that can be implemented now is generally preferred over a decision that requires you to wait.
3.) A solution that's proactive is generally preferred to one that is reactive.
4.) Equipment fails.
5.) New data is worth more than old data, old data is worth more than conjecture, and conjecture is worth more than sentiment.

You can build additional ones based on your experience and observations, which again is where past decisions inform future ones. If you've got options that seem equal, run them through your list of filters and use them to break the ties. Over time you should be looking to develop a feel for the exceptions to those truisms and build your own, which is what separates great decision makers from good ones. (But beware laziness here; there's a knife edge between a good rule of thumb and a lazy or bad habit that just hasn't bitten you yet.) Having them in your bag of tricks really speeds up your ability to evaluate options and get to a valid choice.

Routines or processes are similarly useful for simplifying, speeding, and eliminating redundancies in your decision making cycle. At the granular level, for a decision that can be immediately implemented once made, preset (and tested) routines mean that the "How" is already answered. A process that anticipates the possible consequences of the actions it proscribes and addresses them is even better, since it effectively 'multiplies' a decision and frees up a decision maker's bandwidth. For example, you could decide that in the case of a bug-out situation, you need to get the car loaded as soon as possible, and stage your supplies in an area where loading will be easier. That's fine. But when you're on the side of the road, unloading and digging for some vital piece of kit that was buried during the loading process, you've now got another set of choices that needs to be managed, and decisions that need to be made because of a fairly foreseeable outcome. The process could be proofed/practiced and perhaps fleshed out to not only what and where, but how and why; anticipating what supplies will need to be at hand and which probably won't, using this info to create a loading inventory and order. And taken one step further, this prompts you to containerize your supplies and label them with contents or loading order; now someone else ("Come here son...") can be assigned to do this job with little to no input from you other than the loading order. Even if an hour's worth of work now only hastens your departure by 30 minutes in some future time of crisis, that's a reasonable trade off. The vehicle gets loaded quicker, you get to make better/other use of your pre-departure time (since you're not the one loading the car), you are on the road quicker, and you arrive at your destination quicker. The one decision has been multiplied, enhancing multiple steps in your plan of action.

And realistically, beyond the granular level, you also want to devote some thought to encapsulating groups of processes within procedures. Define success and failure conditions, when it's time to try something else or what to do next. This branching logic is more complex than a "by rote" routine, and requires more work up front, but the simple fact is canned strings of actions can't adequately respond to changing real world conditions. Defining procedures and communicating them to your family/group makes for greater speed in going from decision to execution, while still giving you the flexibility to modify your course of action midstream. It also allows for greater autonomy, allowing you to delegate decisions (or entire branches of the decision tree), which means people who are closer to the the current situation are free to act on new data without having to report back. Going back to the bug-out situation example, predefining a fueling procedure might encompass processes to effect a quick and safe fuel stop under pre-, intra-, and post collapse scenarios for the driver alone, driver and passenger, and so on, out to the capacity of the vehicle, and what to do if none of those scenarios is possible. The base procedure and it's variations are built on the logic of criticality and minimizing risk. A vehicle with no driver is sculpture, so a driver is critical; during a stop is when you're most vulnerable, so you want to get moving again as quickly as possible. An individual is significantly more vulnerable than a pair or group, so you never want to get separated or have a member isolated if possible. All the variations are "best fits" to those criteria with the available bodies. For instance, with us, in a typical full four-passenger vehicle situation, once stopped, the driver stays where they are, someone else fuels, another person gets out to provide eyes/security for the fueler, the last person is extra eyes for the driver. Once fueled the vehicle is immediately restarted, the two people outside go to pay and the vehicle moves to support/retrieve the other two. (If you can't pay at the pump). With three people, the driver's extra eyes are eliminated. With five people, the extra person stays in the vehicle, except in intra or post scenarios where the odds of having to go inside are greater and the odds of needing extra muscle/firepower is more likely. And so on. It may seem excessive, and maybe it is. But ultimately, once the basic idea is communicated, it's just a flexible, simple, and easy to execute procedure to get in and out of a gas station quickly that scales from everyday stops all the way up to worst case scenario with a couple of choices and some communication on your part. And no procedure is complete without an exception alternative, what to do when the process has obviously failed or something you didn't anticipate occurs. Programmers call this an "if else" clause and it's always a good practice to include them in decision trees since it accounts for the possibility of a result/condition that the programmer didn't anticipate. Never assume that you thought of everything, because it's almost guaranteed that you didn't.

We've barely scratched the surface, but the foregoing is a good start. This stuff isn't profound, we all do it every day, yet rarely do we take a systematic approach or verbosely examine why we make decisions a certain way. The problem is that without ever examining your thought process during non-critical times, even if it generally works, you have no idea why it works. Luck, blind chance, the support and forbearance of others; day to day life in most of our normal existences is fairly forgiving and tolerant of simple mistakes and occasional bad choices. But when the Schumer has really and truly hit the fan, the margin for error goes way down. When every choice may truly be life and death is a hard time to start learning how to make good decisions, and one would expect that the lessons will hurt. One shouldn't focus on obsessive micromanagement or anal-retentive over-planning. Just give some thought to how you make choices, and maybe look for ways to optimize that area.