Sponsored By

This method may help engineers begin working on projects when some product requirements are still being determined.

Perry Parendo

May 24, 2023

4 Min Read
NicoElNino/iStock/Getty Images Plus via Getty Images

As engineers, we just want to get to the fun stuff. We want to design and test stuff. We want to break a few things, too! To get to that point, we need to know what to do. Too often we as engineers are given product requirements, and we quickly get into engineering mode.

That is rarely the right thing to do. I expect you have had times when marketing provides those requirements as a wish list. As engineers, we know we can figure it out and make it happen. But at what cost? And I mean for our development schedule as well as for the product cost.

Usually, some requirements do not make sense. Or they are constantly changing. Plus, the customer doesn’t want to pay for it. As marketing or management determines these things, they want to change the game plan. This drives the engineering team crazy! Just tell us what to do, and let us go.

We need to learn to value the success of the product in the market, in addition to the success of our technical design capabilities. Both are important. Of course, this means we need to think about—gasp—doing “marketing’s job” of requirement review.

I know—that is not why we went to school. Yet, don’t we know what can work easily and the potential cost impact? Or better said, who else would know this besides us? I spent my corporate and consulting career asking these up-front requirements questions. It helped my design projects finish on schedule and also helped impress the customer and user.

Of course, it is impossible for everything to be known before we start a project. Some foolishly expect this and either delay the start or misdirect the design team. We can continuously evaluate the stability of our requirements through the project. This provides a balance between control and intelligent flexibility.

This can be addressed a couple of ways. First, if we really have no clue of what the value should be, we can show the requirement as a “TBD” or “To Be Determined.” The problem with this is a design can’t even begin work with this information. Instead, I prefer to use a “TBR” or “To Be Reviewed.” This means we guess at a target value but know there is some risk of it changing. The engineers can begin work, but they probably need to resolve the TBR before building expensive prototypes (though they could create less-expensive ones to help evaluate impact of the initial requirement guess).

Taking this a step further, we can continuously track and report (or our project manager can) the quantity of TBDs and TBRs that exist. As we progress, the TBDs may become a TBR. The TBRs will become “firm” and then approved requirements. However, if the number of TBDs and TBRs increases, this certainly indicates scope growth. This would lead to cost over-runs and project delays.

If a project is a new technology, the percent of TBDs and TBRs could be somewhat high. I’d suggest maybe firm requirements in the 70% range. However, for less extreme technology changes, the percentage of firm requirements is most likely above 90% yet would rarely be 100%.

Using this mindset, it can really change the engineer’s job. We ask questions so we know which requirements are stable, and which may change. It is similar to taking a college test and seeing some given information that does not look right to us. We ask the professor for clarification. Saves us time and ensures we do the problem correctly the first time. Same thing with our design project. We can clarify expectations. Some may call it pushing back on marketing, but that has a negative connotation to it. We really are just making sure we know what is being asked.

Have you been frustrated with requirements in your career? Have you attempted to use the method I presented above? Have you used a different method? I would be interested to hear about your experiences with handling requirements.

If you have NOT done this before, would you be willing to attempt it on the next project you do? When you do, let us know how it works out for you. I expect you will find it is powerful and you will want to do it on every project. Looking forward to hearing back from the design community about this vital activity!

About the Author(s)

Perry Parendo

Parendo began developing and seeing results from his Design Of Experiments (DOE) techniques at the General Motors Research Labs in 1986. His unique insight into DOE has saved time and money while solving complex problems during product and process development. This paved the way for him to lead multi-million dollar New Product Development (NPD) projects with international teams.

Parendo founded Perry’s Solutions LLC in 2006 to help organizations with critical product development activities. He has consulted in a wide range of industries such as consumer products, biomedical products, and heavy equipment. He is currently a regular columnist for Design News. He received his Mechanical Engineering degree from the University of Minnesota.

Sign up for the Design News Daily newsletter.

You May Also Like