General Engineering Introduction/Notebooks/Problem Writing

Engineering moves through playing, doing it first, designing (doing) and finally to problem solving.

An Open Engineering Notebook.

Issues

Before there are problems there are issues. Before issues, there are unknown pains, unknown improvements to the efficiency, productivity, and general quality of life. When an issue emerges, everyone begins to become aware of it. A language evolves that gives it a name. Consider farming. The issue emerged that a human can only accomplish so much during the day. The issue turned into a goal and was given words: "How can we produce more food with less human effort?" At this point it is still an issue because nobody owns the problem.

Ownership

Problems have an owner. Issues cause conversations. Engineers listen to issue conversations and try to turn them into problems like a lawyer tries to find clients or a doctor tries to find patients. Most people avoid issues and think engineers are a bit perverse, a bit insensitive, and should mind their own business. But then lawyers are searching for fights, and doctors try to get people to talk about their pain. Should engineers should stop trying to find problems?

Mature engineers know when they have taken on too much and need to leave issues alone for other engineers.

Non-engineers ignore and live with issues. They refuse to name them, and talk about them. They appear as nothing, holes, huge missing gaps in a narrative. Asking "why" leads to a competition of opinion, ownership of ideas and development of a "civil" dance around what an engineer sees as an issue.

Owning a problem does not mean the engineer is responsible for fixing it. Owning a problem means defining the problem without visualizing the solution. The goal is to find all the tension, all the frustration, all the fog and confusion and describe the problem in a way that inspires many solutions and leads to requirement discussions.

Learning to own the problem without even thinking about solutions is the opposite way most of us are raised. Most of us think of problem/solution pairs and want someone else to list them for us. Engineers don't create the problem/solution pairs. Technologists do. Problem/Solution pairing is the result of experience and expertise with existing equipment. This has nothing to do with engineering.

Project Problems

Problems can be large and involve hundreds of engineers. Ideally project problems start with the NAE Grand Challenges. Large problems are known by everyone, they define the project, they involve customers. Executives want to know and understand the big problem. Project problems are negotiated.

Projects without Problems

Projects are fun. But Do It Yourself (DIY) activities serve yourself. They live on top existing opportunity and materials. They use excess time and money. They are a spiritual exercise of personal art that is about me and my talent. They are narrative driven, not design driven. They are decoration of our lives. They rarely become profitable. They rarely improve the standard of living or expand the human species domain. Projects are about art, culture, civil behavior. They can be engineered.

Engineers turn projects into problems by figuring out how to do this project for everyone in the world .. or a DIY kit that anyone in the world could follow .. or jobs for other people in the world. The starting point is to turn "fun" into an issue. What is the pain, the gain, or the change? Where are standards? Where is best practice? Has it ever been engineered? An engineer will begin the "project" by discovering the project's problems. Engineers stay out of the blame game. A problem statement is negotiated, engineering requirements are documented, alternative designs are created, etc. There are business process that engineering projects/big problems go through. Mature engineers talk about the business process associated with “big” problems, because this is ultimately what determines success.

Requirements

Requirements are associated with the big problem. They define success. They don't visualize a working solution. Writing requirements means visualizing not a solution, but all solutions. It requires creative exhaustion. It is usually a task that involves not just the current team but all other interested engineers. It is usually accompanied by a presentation to a larger body of engineers.

Civil engineering requirements have a structure that is guided by law. The engineers that write the requirements should not actually conceive of solutions. Requirements capture all the existing context. They try to answer questions such as "what do we need to know?" or "what needs to happen?". The goal is to turn this into a list of number and descriptions of the numbers. The creative exhaustion does not mean the project needs to be done up front. It does not mean that conceive and design need to be done. The goal is to look at the project from a customer, executive point of view and exhaust this.

Writing requirements feels trying to climb confused, dim, foggy expectations. There is an urge to exhaust executives and customers with questions. But this can never occur. Any attempts are met with "This is what I am paying you to do." So instead an engineer thinks up requirements and presents these to the client. The client then signs off on the number descriptions.

During the conceive and design of a project, the requirements may be renegotiated. The result is an RFP (request for proposal). If the requirements are too specific, only one engineering firm in the world can do the project, everyone will be sued. If the requirements are so vague, then no engineering firms will bid on the project. If the requirements are too strong, just high ball bids will be received. If the requirements are too low, there will be lots of low ball bids.

Little Problems

A problem is not personal. Some students walk around saying '"My problem is "I am not good with cars." ' This is not an engineering problem. Personal fog or confusion may a personal problem, but it is not an engineering problem. An engineer never turns personal ignorance into a problem. If you don't know something, and there is not a tutorial that will teach you quickly, then it is the world's problem, not yours. Be an engineer. Solve the problem. Create a certification. Help the next engineers climb over the problem to another one and not re-discover your original discovery. America was discovered by Columbus because he wrote it down on paper. America existed outside tne world of verbal communication. If you can not write the problem down, then you are not engineering.

An engineering problem is outside of oneself. A little engineering problem is something one stumbles across, not something one plans. Engineering problems are discovered in the process of doing something. The unknown is an opportunity, not a problem. Engineers loose respect when turning things into problems that are personal.

Little engineering problems are those that can be discovered and solved by one engineer in an hour. Dealing with problems is what gives engineers the reputation of “fixing” things. In reality, engineers only fix what they are creating. Technicians are much better at fixing things in general. Engineering problem solving most of the time is not “fixing things.”

Little problems can grow by involving other team members. Enlarging a trivial problem can increase one's reputation if the problem is hard (outside of oneself, not associated with people), well defined and offered with no solutions. This kind of problem is food to engineers. The down side is that if the problem is trivial, problem enlargement can reduce reputation. If the solution is in another engineer's head and you haven't learned to respect that engineer (or talked to them), then your reputation goes down.

Frustration

When a technician/technologist gets frustrated, they have someone to blame .. the engineer. And technologist/expert is almost always right. There usually is a problem with the design. An engineer has no one to blame.

Engineers have an ethical and legal obligation to refine the problem solving process instead of blaming. This is what keeps engineers individually out of law suites. Projects are collections of problems that turn into the project requirements. Designs are solutions to the problems. Each of the potential solutions may need to be checked out.

Underneath all of this is a frustration and tension that an engineer has to deal with. The goal of an engineer is to learn to live with this frustration. The first step in engineering problem solving is learning to manage frustration.

Problem

The problem is the goal, not the means to the goal.

The problem are the symptom details, not what caused the symptom, not what the solutions might be.

The problem is the issue, the possibilities and the hope, not the pain of change.

The problem is form and function expectations, not specific material lists.

The problem is the description of input (unit test in programming projects), and the expected output, not the algorithm.

A problem can not be associated with your learning curve. Instead focus on these three things:

• All of us have a fog of uncertainty, frustration and limited skill.
• The goal is to know yourself ... know what you don't know
• Everyone experiences frustration, figure out how to be inspired by it.

If both your learning curve and uncertainty drive your problem writing, you will earn respect among engineers … but not among the rest of society.

The world has problems, not you. If you can not understand, it is the world's problem. Make it the world's problem.

Don't express your learning curve or uncertainty. Leave blanks during presentations that stimulate questions. Use the questions "Does anyone here know????" to explore the scope and scale of your inadequacies. Be prepared to learn in the moment if there is an answer. Hope that nobody else knows. Maybe nobody else has any ideas. Maybe the issue really is so edgy that you are really getting paid for doing something first for the world! Your adrenaline should start flowing! This is what makes engineering presentations so important!

The problem must be described in terms that earn respect of society. This means you are limited to a physical, process or system description that has nothing to do with yourself. Get excited!

Multiple Solutions

A problem is not an engineering problem until there are multiple solutions. Brainstorm all possible solutions. List them. You are not brainstorming unless there is more than one. Just name them. Don't try to flush out the details. Don't name trival ones like "give up", or vague ones like "find something else."

Listing one solution is not an engineering activity. Problem/Solution pairs are something technicians love to read, not engineers.

Don't talk about the solutions emerging in your head. Don't hang onto them. Write them down, and then wait for the next solution to appear in your brain. Go back to the tension of the problem. Repeat the problem in your mind. Then compare your list with your team mates. Vote. How many are identical to yours? How many are totally different? How are they similar? What is emerging?

Don't feel inadequate if you can not come up with solutions. Maybe the problem statement is not perfectly formed yet. Present problems to the class/other engineers. During the presentation solicit, encourage and record solutions from the audience (which will include your instructor). Don't present a trivial problem such as "where do I plug it in" and expect to gain engineering respect.

Outline what the software objectives are in terms of input and output (unit test). Solutions are algorithms ... different algorithms can perform the same unit test. Visualize algorithms. Name them. List them the names, don't write the solution until the test has been written.

Solutions don't have to be realistic but they have to be plausible.

Testing

There are three parts to testing. One is describing the test protocol.

The second is physically performing the test.

The third is analyzing the results and deciding whether to redefine the problem, perform another solution test or come up with another solution. If this is done right, a path or direction will emerge in the solutions. When this happens, an attempt needs to be made to look down the path to see if there is success at the end. Otherwise a lot of time/money can be wasted.

A technologist stops at the first that works. A technologist will use bubble gum, hay baling wire, soda cans, WD-40 and duct tape to solve most problems. Their goal is to fix, not explore all the possible ways to fix. Do not expect to get credit if the problem is announced solved after just one test. You can get credit if a single test results in a restatement of the problem and/or inspires more solution designs.

Problems can occur at any time. Normally they occur during doing (design). In all cases they will occur while or in the middle of Project Writing. In all cases they will occur while working on a project.

Problem Writing

Write about Small Problems, their Multiple Solutions, and Testing triplets to record problems in your notebook. Use the same outline to create a deliverable in the team project report. Write about the big problem in the Body and paraphrase in the executive summary.