GERALT/PIXABAY

Engineers love to solve problems, especially technical ones. Unfortunately, challenges in communication and planning often result in poorly understood goals and objectives. The engineering team makes one thing while the managers and marketers want something else. That leaves everyone unsatisfied.

I will describe a very simply process that, when consistently applied, is extremely successful in generating consensus among stakeholders and driving the development of proof-of-concept devices. This process, outlined below, will help ensure the best possible outcome. While this discussion is focused on proof-of-concept devices, it works equally well, if not better, for process improvement activities.

Please keep in mind that each of these steps can be very simple if the answers are known and obvious. A few hours and a page or two of documentation suffices in many cases. The benefit of the investment of time is greater clarity of purpose and alignment of stakeholders. For a junior engineer with very senior stakeholders, this alignment can be crucial to success.

Simplified Proof of Concept Process

Having used this process consistently for about a decade, these steps are firmly fixed in my mind. Each step will be more fully described below, but once one is familiar with the process, an outline of the process steps is generally a sufficient reminder.

Hear Wehde discuss "Effective Prototype Development" at the MD&M Minneapolis Conference & Expo, November 8-9, 2017.

Process Steps

Identify Stakeholders

Often, we make the mistake of thinking that the person who asked us to perform a task is the only stakeholder and we look to that person for all direction related to the task. But often there are many people who have interest in the activity and its outcome. Identifying everyone with a vested interest in the outcome will help ensure that the project has the greatest chance of success. Don’t trust that the person who gave you the assignment will have taken the time to clearly define the project. This list of stakeholders will be used during each of the next three steps of the process.

Develop Problem Statement

Maybe your manager gives you well-defined problems with no ambiguity, but mine doesn’t. The problems I receive tend to be very challenging, otherwise I wouldn’t be getting them. In fact, my manager expects that I will figure out the important questions to ask and answer. If you want to be successful, you will too.

Informed discussion with each of the stakeholders allows us to clearly identify the problem to be solved. Often stakeholders at different levels of an organization or with varying experience levels with a given technology will have significantly different views of the problem. Thus, stakeholder agreement on the problem to be solved is a necessary step.

Determine Current State

While not always relevant, there is often an existing product or process that is deficient in some way. We are rarely called on to invent something entirely new—though in our industry, it is more common than in other fields. Identifying the current state allows us to analyze its strengths—that is, the features we want to keep. We can also identify its weaknesses, which often are articulated in the problem statement.

Document Stakeholder Needs

Having executed on the first three steps, we can memorialize the stakeholder needs we have identified through interviews and discussion into a succinct list which can be reviewed by the entire group. Often this leads to contradictions between the needs of various stakeholders, which can only be resolved through discussion and compromise.

Identify Requirements

While the stakeholder needs reflect their desires in language they understand, the requirements are written for the engineer developing the proof-of-concept device. These requirements drive the design and are used to develop the verification and validation activities required to establish the success of this project.

Perform Design

As a passionate and dedicated engineer, I want to spend as much of my time as possible designing things. New things, things that don’t exist, things that couldn’t even be imagined a few years ago. I have found that by religiously following the simplified proof-of-concept process I am able to minimize the time and effort spent on non-design activities.

Execute Verification and Validation

Finally, the ultimate step is to see if it works. The requirements written to drive the design are used to test functionality (verification), while an evaluation of the results versus the stakeholder needs (validation) establishes the overall success of the activity.

Summary

Next time you have a small project, be it a proof-of-concept device or a new process your manager wants developed, remember to follow these simple steps to gain alignment of purpose and to ensure that your time isn’t wasted developing something that doesn’t advance your organizational knowledge.