The Myth of the Gut Feel Decision Maker

What is meant by the term "gut feel decision?" Is this some form of decision making completely separate from other forms? We never have all the information we need to make a decision. At some point, we summon our courage and move forward. Gut feel decision making exists on the same continuum as any other decision process. It is a decision made with very little information, but requiring somewhat more courage. Generally, people who make these decisions are keenly aware of the cost of not deciding. They understand the need to move forward. They may be willing to absorb the cost of changing direction when new information becomes available. They know that larger success is built upon a series of smaller successes and failures.

Unfortunately, this style of decision making looks very similar to hubris. We occasionally see decision makers who have been successful in a previous endeavor, and are using the confidence gained by their experience irrationally. Rather than evaluate their current alternatives as carefully as time permits, they recall a previous experience where they made the right call under duress. These people have concluded that they have a knack for making tough decisions, and plunge forward.

Externally, hubristic decision making looks very similar to a competent decision making process. Even if a competent decision maker claims that a gut feel decision is being made, when pressed, they will be able to explain their rationale. A hubristic decision maker can not rationally explain their decision.

Triage and Tyranny

I recently worked on a design project for a large vendor of aerospace components. We were on a tight schedule. I requested the vendor's drawing format as an IGES file so I could complete the documentation. This request would require ten minutes of some one's time to fulfill. I received the files five weeks after my request.

There are people in many large organizations who perform mundane tasks. These jobs do not require significant training, but the people filling these positions are often overworked. Additionally, these employees have no sense of a bigger picture. They find it difficult to prioritize their work. Since they cannot possibly complete all of their tasks, they create a form of triage to help them with priorities. The system is very simple. The employee does not complete any task that originated from outside their own department. The person making the request has three choices:


1) Forgo any benefit derived by the completion of the task.

2) Find another way to complete the task.

3) Contact the employee's manager and force the issue.

Most often, the requestor chooses to continue their project with their request unfulfilled. The employee who has ignored the request learns that most requests are unimportant, and can be ignored. The poor service provides a local benefit for the requestor. She can use the lack of results as a rationale for her schedule slipping. The material benefit of the results is irrelevant.

If the results are critical to the completion of some task, the requestor will have to call the department manager and make a special arrangement. The employee now springs into action. He explains that he did not complete the task because he is overworked, but he will make this task a priority. From a local perspective, everybody is happy. The manager gets to manage and make things happen. The manager's employee gets to solve a crisis, while at the same time receiving recognition for being overworked. The requestor gets the results she needs, and can use the delay story with her manager if needed.

But does this make sense globally? Absolutely not. Where there is no system or policy to determine how workers will make decisions, an ad-hoc system will develop. In this case, the passage of time sorts out the important tasks from the unimportant tasks. In project work, we cannot afford to do this. We would like as much information as possible to reduce our uncertainty. But if obtaining this information requires us to wait, we may choose to forgo the information, and accept the risk resulting from its absence. And we've added one more item to the list of things we may face in firefighting mode later on.

When is a Project Completed?

From an engineer's perspective, a project is completed when the uncertainty is zero. Obviously, we cannot quantify uncertainty, but it is useful to discuss the concept in the abstract. We can usually define uncertainty as unknowns which will have a material impact on our project.

A project engineer should endeavor to reduce uncertainty wherever possible. We can visualize a graph with uncertainty approaching zero in a generally linear fashion. Projects rarely transpire in this way, which is why firefighting is so commonplace. The appearance of substantial uncertainty at the end of projects is a problem with many causes. Future essays will deal with the ways project teams trip themselves up by failing to reduce uncertainty.