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.