General Engineering Introduction/Decisions

Decisions can be made consciously (engineering) or unconsciously (playing). An engineer looks for opportunities to make decisions. "Expediency", "using materials at hand", "do it with no money", "reduce to the absurd", and "keep it simple stupid" are all criteria that can be used to choose among options. Choosing merely one of these criteria and adopting the first solution found is playing. An engineer starts with a problem statement that is independent of all solutions and all selection criteria.

Engineers gain respect when they can talk transparently about their choices. When asked the question "Why did you choose that solution?" an engineer can talk for 15 minutes. Someone who has "played" mentions a selection criteria and then says something like "the solution is obvious" or "We couldn't do that, so we tried this ... and then we tried this ... and then this ... that didn't work .. so we tried this." A true engineer will interrupt and say "What didn't work?", "What are the symptoms?", "What are the details?", "Why isn't this turned into an engineering problem rather than something to be avoided?" Engineers loose respect when they litter any kind of documentation with vague references to problems that were avoided as a narrative of tries without any context stronger than sequence. It is a waste of time and money to play.

So when is documenting a decision process necessary? Turning everything into a formal, transparent, accountable decision making process would cripple, slow down and destroy most projects. Yet when an engineering company evolves a culture where no decisions are documented at all, managers will resort to pitting two engineering team against each other and hope that they come up with completely different solutions. And this is just so the manager can have some confidence that all alternatives, all possibilities, all respectable options have been explored. The decision process is necessary when other engineers will start questioning the process off the top of their mind or tip of their tongue.

Ultimately formal decision documentation results in clarification of the design process. It leads to greater efficiency, it captures the best context for further work in this new area, it clarifies the next step, it helps others buy into the process and stops the growth of "ownership" ego.

There are two decision documentation processes: "Decision Tree and Decision Matrix." A decision tree is not as strong but is not as expensive or time consuming. A decision matrix creates the most respect because it documents what is almost a consensus decision making process among stakeholders.

Decision Tree

Wikipedia's Decision Tree article is excellent. For the purposes of this course, use the decision tree to capture the dead ends, the places explored but abandoned, the possibilities that turned into a dense fog. It is a map of what was done. At a minimum it provides stimulus for a conversation among peers and sparks the intuition, enthusiasm and inspiration in other engineers that leads to an expansion of the tree.

A decision tree can show how a very general problem statement was reduced to something possible (a Conceive activity).

At a minimum decision tree can show how a particular design was chosen, the order in which decisions were made and what capture which options briefly appeared and were then abandoned.

Example Decision Matrix

Decision Matrix

The best way to turn opinions into numbers is a decision matrix.

What it is

A decision matrix captures peoples opinions that they have individually turned into numbers. It is used to expose the decision making process to the public in a logical manner. It sets the stage for capturing disagreement, resolving misunderstanding and documenting the opinions of a group of people, not just those on the engineering team.

When to use it

Use a decision matrix when there is a debate about whether customers need to be surveyed, when the client is worried, or when the team can not agree internally. It can be used when selecting

material

a design

a college to transfer to

which problem solution to test

Negotiate when to use it with your instructor.

How to use it

These are the steps:

Identify alternatives. Depending upon the team’s needs, these can be product/service features, process steps, projects, or potential solutions. List these across the top of the matrix.
Identify decision/selection criteria. These key criteria may come from a previously prepared affinity diagram or from a brainstorming activity. Make sure that everyone has a clear and common understanding of what the criteria mean.
Ensure that the criteria are written so that a high score for each criterion represents a favorable result and a low score represents an unfavorable result. List the criteria down the left side of the matrix.
Assign weights. If some decision criteria are more important than others, review and agree on appropriate weights to assign (e.g., 1, 2, 3). Design scoring system. Before rating the alternatives, the team must agree on a scoring system. Determine the scoring range (e.g., 1 to 5 or 1, 3, 5) and ensure that all team members have a common understanding of what high, medium, and low scores represent.
Collect data, rationalize outliers and through them out.
Look at the totals, averages and standard deviations.
Analyze the results.

Here is an example Decision Matrix Sspreadsheet