Pixabay/ CC0

Introduction

This section will describe the process that an engineering design team uses to move a project, from acceptance of the initial objective, through understanding the project requirements and development of the specifications to the conceptualization, preliminary design, and final design stages.

Overview

It can be argued that the key aspect of an engineering education is to teach you how to think in a manner which is efficient for solving problems.  No engineering class can teach you all of the skills that you might need for whatever industry you may end up in, or expose you to all of the types of problems that you might need to solve.  Rather, an engineering education teaches you how to look at problems, evaluate them, and come up with a solution process that will meet the requirements.  Consider this conundrum: What do you do, when you have no idea what to do?

The processes which will be discussed could be considered applicable even if your team is given a challenge for which none of your members has any experience.  In fact, it is possible no one anywhere has previously solved a challenge quite like the one you and your team face. 

Designing things for various uses is one of the challenges that engineers face, and this section is intended to help you synthesize various aspects of engineering during the design of a component, subsystem, or system, and then address them all in a solution process.  This process is generally referred to as The Design Process. 

Different businesses may use different design processes.  The process used may be a function of the particular industry in which the design is occurring, the requirements of the end customer, and/or the history of the engineering organization performing the work. This section will examine a list of steps that might comprise a generic design process, and could easily be tailored so as to fit any particular industry.

Objectives, Requirements, Specifications

A design engineer’s task usually begins when a problem or a need is identified.  This may occur because something has failed, or is recognized as not working as efficiently as would be desired.   It may also occur because someone has recognized a void in the marketplace that presents an opportunity for a new product to be produced and sold.  Or it may occur because of a technology breakthrough that opens the door to a previously unexploited market.  Regardless of how things arise, the objective of the design engineer is to solve the identified problem or meet the identified need.

Pixabay/ CC0

The engineer is faced with how to exploit this opportunity by coming up with a solution to the problem which is both feasible and cost effective and determining a way to produce that solution.   In order to do this, the design engineer or the engineering design team must assess the problem/opportunity and determine the requirements for a solution.

It may be that a customer has come to the design team with a concept already in mind, and that customer may even have already dictated the requirements and specifications that must be met by any possible solution.  In this case, the design team must first understand the goals and objectives of the bespoke project, and synthesize the top-level requirements and specifications so that the needs of the customer are thoroughly understood.  The design team may then add second-level requirements and specifications that the customer did not originally address.  These would be further limitations that the design team chooses to place upon their solution based on their experience, capabilities, resources, etc. 

It may otherwise be the case that a problem or need has been brought to the design team, with no preconceived solution in mind.  In this case the design team must evaluate the problem that needs solved, and to create their own requirements and specifications that would enclose the envelope that encompasses the possible designs that could meet the need and solve the problem.  This is frequently referred to as the Design Space of the problem.  These become the top-level requirements for the project.  The second-level requirements are then developed, again based upon the limitations previously mentioned such as experience, capability and resources.   Following this, the design team must Brainstorm possible solutions, thinking of as many possible approaches to solving the problem as possible.  Brainstorming involves open-ended thinking that produces a wide range of possible solution approaches that meet the requirements which have been developed.  At this initial stage, the team should not consider any suggested solution as a “bad” idea, but rather, should simply let the creative thought process produce as many potential solutions as possible. 

Once this list of solutions is produced, the team begins the process of evaluation and down-select, eliminating the least feasible solutions until only the best one remains.  The design process then continues as delineated in the Design Process steps of the following topic.

The Design Process

While different organizations may use different design process steps, the ones listed below encompass the most commonly used activities.

1. Assess team skills and get to know each other – This is particularly important if the design team has never met previously, or never worked together as a team. It is not necessary if the team is established and has worked as a team before.  It is important, as the process goes on, that team members know who can be relied upon for what tasks.  Therefore, this is a key first stage for any new team.

2. Develop preliminary schedule – Based upon the time constraints of the project, such as when the required solution is to be implemented or when the customer expects delivery, the team should create a preliminary project schedule. Doing this at the beginning allows the team to assess how much time can be allocated to each step of the design process.  How this schedule is created and tracked throughout the design process will be discussed in a subsequent section.

3. Study first level design requirements – These may be provided by the customer, or they may have to be developed by the design team as they evaluate the problem or need which is to be met by the solution they are tasked with delivering.

4. Derive second level requirements - These are controlled by the design team, and are developed based upon experience, capabilities, resources, etc.

5. Brainstorm concepts – Design team members allow their creativity to free-roam, producing as many possible solution approaches as possible. No attempt to evaluate them is made at this time, only to make as complete a list of possible solutions as the team can collectively think of.

6. Make team assignments – It is now time to begin evaluating the concepts that arose during brainstorming. Individual design team members should be tasked with further evaluation of various concepts relative to how well they can meet the first and second level requires and how practical they are.  It is good to know individual team member strengths and capabilities (as determined in step 1) to efficiently distribute the work load across the various team members.

7. Evaluate/eliminate concepts – Individual design team members perform their assigned evaluations, and return as a group to discuss. Solutions which are not feasible or which do not meet requirements, are readily eliminated, based upon the consensus of the entire team.  This becomes an iterative process, as some solutions are eliminated, and further evaluation may be required for those that remain on the list.

8. Down-select to one concept – Ultimately, the goal of the design team is to reduce the long list of brainstormed solutions down to the single most practical solution, and that is the one that will be designed. This should include a preliminary examination of the selected solution to ensure that it can fit within the available resources and meet the project specifications and requirements.

9. Concept Readiness Review – This review goes by different names in different industries. However its purpose is always to examine the general concept that has been selected by the design team during the previous stages, and to present that concept, and the rationale that supports it, to a team of reviewers which may include representatives of the customer, of your company’s management, and experts in the field.  Topics to be covered in the review should include:

• Design objective
• Design requirements
• Selected concept
• Discussion of why the selected concept is a good choice
• Discussion of any noteworthy aspects of unselected concepts and why they were not selected
• Risk assessment
• Preliminary cost assessment
• Schedule and go-forward plan

10. Evaluate Risks – It is never too early to begin evaluating the risks to success of the project. The earlier that a potential risk is identified and is resolved, the easier it is to find a way to eliminate, or mitigate the risk. The simplest approach is to simply brainstorm all the potential failures that could befall the project, and then evaluate each of them to determine how likely they are to occur and how damaging they would be if they did.  A thorough and methodical approach to technical risk evaluation and management is the best approach, and a sample approach will be presented in a subsequent section.

11. Work on the preliminary design – Having received approval to proceed, following the concept review, the design team should now begin consideration of the following questions, once again assigning appropriate individuals to their consideration:

• Patent search – Will the design run afoul of patent laws and existing patents?
• Market research – How will the proposed solution fit in the marketplace? Will it be marketable at the cost that is expected to be required for production?  Is there a viable marketing strategy to get customers to buy the product?
• Cost and schedule analysis – How much will the product cost to produce? Where is the team relative to the preliminary schedule developed earlier, and do adjustments need to be made?
• Concept development – What are the steps required in order for the project to advance from the concept to a preliminary design which must be completed to take the project to the next level?

12. Analyse preliminary design – Technical evaluation of the preliminary design will be required to assess preliminary configuration, parts sizing, materials, etc. This may take the form of hand calculations or may involve preliminary computer modelling.

13. Preliminary design drawings/sketches – The actual configuration of the bits that will comprise the solution need to be developed as sketches and then preliminary drawings or models.

14. Refine/Modify design as necessary – As the design effort progresses, it will be recognized that there are changes required in order to make the design work, or to optimize the result.

15. Update risks, budget and schedule - The changes mentioned in step 14 must be incorporated into the design and their impacts on cost, scheduled and risk must be considered.

16. Preliminary Design Review - This review goes by different names in different industries. However its purpose is always to examine how the concept has evolved as it is designed and evaluated. The results at this intermediate stage are presented to a team of reviewers which may include representatives of the customer, of your company’s management, and experts in the field.  The purpose is to gain an approval to continuing the process to its ultimate conclusion.  Topics to be covered in the review should include:

• Design objective
• Design requirements
• Review of general concept
• Discussion of the development of the design
• Presentation of all analyses
• Discuss any problems that have been, or need to be, overcome
• Risk management update
• Cost update
• Schedule update

17. Evaluate critiques from review – The reviewers will likely have questions and/or suggestions arising from the review. These need to be examined and evaluated by the design team.

18. Continue detail design development – The design team needs to take the project from the approved preliminary design to a finished design that is capable of being produced.

19. Continue detail analysis - A thorough analysis of the detailed components must be conducted using computer modeling, finite element analysis, component prototyping and testing. Depending on the project, this may include an assessment of material stress, component dynamics, thermodynamics, heat transfer, wear capability, part tolerances, et cetera.

20. Produce detail drawings - This includes producing 3D models or 2D drawings capable of being used in the manufacturing and assembly process.

21. Critical Design Review - This review goes by different names in different industries. However its purpose is always to examine how the final design has been developed and evaluated. The results at this critical stage are presented to a team of reviewers which may include representatives of the customer, of your company’s management, and experts in the field.  The purpose is to gain final approval to continuing the process to its ultimate conclusion.  Topics to be covered in the review should include:

• Design objective
• Design requirements
• Design concept
• Design details
• Analysis details
• Updated cost
• Updated schedule
• Risk management update
• Concluding statements and recommendations

22. Prepare final report and documentation – The project is never finished until the documentation is complete. The members of the design team may well be moved on to other tasks. There needs to be a complete record of the design, the rationale and analysis which supported it, so that in the future when a problem occurs, or when a subsequent change is desired, the engineers assigned to the project can pick up where the previous design team concluded.

Understanding the Requirements and Constraints

The engineering design team must consider many constraints when taking on a project.  This topic will discuss technical, financial, schedule, legal, social, and ethical constraints that may be faced.

Engineering designs are solutions to open-ended problems.  In the real world, most problems that you solve will be open-ended problems for which there is not just ONE solution.  Rather, there are a multiplicity of possible solutions, and it may not be obvious which (or even if) one single solution is the best.  The greatest challenge you face is when there are multiple paths to a variety of multiple solutions, and YOU have to propose the one you think is optimum.

What is the best solution?  Simply put, the best solution is the simplest, least expensive design that meets all the project requirements and constraints.

You can always design it with more bells and whistles.  You can always design it to be more complicated and impressive.  You can always make your design more glorious and more expensive.  But why would you want to over-design it to exceed the requirements with more complexity than required and more expense than necessary?

The best solution is the simplest, least expensive design that meets the project requirements, including all financial, schedule, social, legal and ethical constraints

Some types of constraints:

Defining the Specifications

Once the design team thoroughly understands the objectives, requirements and constraints, they must develop a very well defined set of design goals which is called the ‘design specification’ for a project. This specifies the details of the approach that the team has chosen as a solution for the project.

The specifications of any design project should be reviewed almost continuously.

• This is done to ensure that the evolving design is, in fact, meeting the intent of the project.
• As the design project moves downstream the specifications can become more and more detailed, or refined.
• At the beginning of the design process they might be referred to as ‘target specifications’.
• By the end of the process they have solidified into specifications for manufacturing and/or purchase.

Having, and continually monitoring the specifications will screen out unsatisfactory design steps. Designs that pass all of the tests in the specifications should meet all the goals set for satisfactory solution.

There are two types of specifications:

• Performance specifications: describe the basic functional requirements of the product and set out the basic parameters from which the design can be developed. They are based on the need the product is intended to satisfy and an evaluation of the likely risk and consequences of failure.
• Product specifications: define conditions under which the components of the designs are purchased or manufactured. Material properties are an important part of ‘Product specifications’.

The specifications should be documented in a “design specification” report which clearly and accurately describes the technical requirements for items, materials and services including the procedures by which it will be determined that the requirements have been met. The time saved through correct language documented in the form of a specification greatly decreases the cost of a project.

Serial Versus Concurrent Design Process

Traditionally, engineering design was conducted in a Serial Design Process.  That is, steps in the process all occurred sequentially.  The initial design concept was passed to a designer, who took the concept to a detailed design.  This design was then passed to engineers who performed the stress, thermal and dynamic analyses.  If one of them found a problem with the design, it was sent back to the designer, who had to make changes.  Once the changes were made, the design was passed back to the analysts, who again performed their work on it.  If any of them found a problem, then it went through this loop again.  Then the design went to prototyping and testing, if any problems were found there, it had to be sent all the way back to the designer, and then again to the analysts.  After these iterations were finished, the design was passed over to the manufacturing regime.  Here the manufacturing engineers began the process of determining how to manufacture the component.  If they found any problems that kept the component from being easily manufactured, the design was sent all the way back to the beginning for a redesign.  This then led to it being routed through the analysis process again, then prototyping and back to manufacturing.  This same process occurred with the purchasing department and any external vendors. 

More recently, engineering businesses have moved toward an improved process called the Concurrent Design Process.  In this approach, a team is formed which contains experts in design, all analysis areas, prototyping and test, manufacturing, and even purchasing.  This team is often called an Integrated Product Team.  The members of this team work closely together, such that when a concept is to be developed, the analysts are working alongside the designer, examining the design as it evolves and suggesting how problems can be anticipated and avoided.  Similarly, the manufacturing engineer is now involved from the beginning and can make recommendations throughout the process that improve the manufacturability of the design.  By having all aspects of the design process represented on the team, the efficiency of the design process is greatly improved and the time required to bring a product to production can be greatly reduced.

Throughout many industries, this change has been occurring in recent years.  Two changes were required in order for this improvement in process to come about.   The first change was cultural.  The design and manufacturing sides of a company must stop looking at each other as separate and realize that only by working together can they significantly improve their company’s ability to compete with new products.  The second thing that was needed for concurrent engineering to work was an improvement in technology.  Specifically, what made this possible was the ability to quickly and efficiently create 3D models of new designs and the ability to quickly mesh these into Finite Element Models and produce stress, dynamics, and heat transfer results.  Technology that lets models be built, analysed, modified, and re-analysed in a matter of hours, not days or weeks, makes it possible for analysis and design to actually occur simultaneously.  Fortunately, the technology is in hand, and the Concurrent Engineering process is saving many companies both time and money.

The following diagram shows how the Serial Engineering Process works.  It is easy to understand how this process became very time consuming.

The Concurrent Design Process, is diagrammed here:

Case Study

The following is a case study example provided by an engineer who spent quite a few years as a dynamics analyst in a company that designed and built gas turbine engines for aeroplanes and industrial power generation.  This is his story of concurrent versus serial engineering.

“When I first joined the company, I was part of the dynamics analysis group.  We performed the vibration analysis of engine components and analysed the system dynamic characteristics of entire engines and their installations.  A job would come to me when a designer suddenly appeared in my doorway with drawings under his arm.  He would lay them out on my desk and explain to me what his design was for and go over all the aspects of it.  Then he would go away and leave me to work on it for a few weeks, laying out a model, inputting the model to the computer, and running the necessary analyses to ensure that it worked.  I probably would not see the designer again during that time.  I knew, through experience, that somewhere else in the building was a stress analyst, and a heat transfer analyst doing exactly the same things I was.  But unless we bumped into each other in the lunch room, we never even spoke to each other.  In fact, we might not even know each other.  When I finished my modelling and analysis, I would call the designer and show him my results.  Perhaps everything looked fine from my stand point.  But just as likely, there were issues that had arisen that might force him to modify his design.  If so, he would go away and make the changes, then return with a new version and we would repeat the process.  Of course, even if my analysis had gone well, if the results coming from the stress or heat transfer analysts did not look so good, the designer still had to make changes, and if those changes could in any way effect my results, then he had to bring the new version back to me to be analysed again.

This would go on and on until the designer, and all the independent analysts were happy.  We would all document our results and the finished design would be sent across the street to the manufacturing plant.   You would have thought that “across the street” was like crossing the Grand Canyon.  No one from our side ever went there.  And all I knew about the manufacturing side of the company, was that folks on my side claimed that manufacturing couldn’t do anything right, and was incapable of making a decent part.  At least, that was what I would hear from the designers, who were always dissatisfied with the quality of the parts produced and/or the rejection rate on parts failing inspection.

Once, I had to attend a meeting on the other side of the street, and all I heard from the denizens of that world were how awful the designs were, and how the designers and analysts kept coming up with parts that couldn’t be made.  No one on either side of the street would really talk to the other side.  We lived and operated in separate worlds.  We lived in the world of Serial Engineering.  Each person did their little job and then passed it on to someone else.  And if anything went wrong, then the process backed up and started over again.  And a typical design could take up to ten years to get from concept to production.

During my years with the company, I saw a huge change in approach and philosophy.  By the time I had been there 15 years, we had begun to work more closely with the designers, keeping in touch everyday so that they knew what was going on with our analysis and could begin thinking about changes and iterating on them with us as we went along.   They would also come to us early with their concept and we would help formulate the preliminary configurations, avoiding any immediately obvious missteps.  By the time I left the company, I led an Integrated Product Team.  I had designers, analysts, graphics experts, a manufacturing engineer, and even a purchasing agent on the team.  We all worked in the same room, with no walls or barriers, and everyone knew what everyone else was doing at all times.  So our manufacturing engineer was always looking at what was being designed, pointing out what aspects would be difficult to make in the manufacturing shop, and steering the design toward a result that would be easy and efficient to produce.  Our purchasing agent was constantly working between our designers and our outside vendors, virtually bringing the vendors into the team.   Designs were developed while analyses of those designs were going on at the exact same time.  During my last assignment, we brought an entire design from concept to hardware in 13 months.” 

Putting Things in Perspective

Summary

• The engineering design process is the route by which a design engineer, or an engineering design team plots its course through the challenges involved in developing a solution to a design problem. The process involves a number of aspects which have been delineated in this module, beginning with team member assessments and preliminary scheduling, then moving on to requirements capture and brainstorming of concepts which will be evaluated to down-select to a single approach.  That concept then proceeds through design and evaluation, utilizing a process which evaluates numerous aspects of the design and is reviewed on multiple occasions, leading to a result which should meet all of the objectives and requirements within all of the constraints.
• Requirements specify what a project will accomplish in order to be considered a success
• Constraints define limitations which cannot be exceeded, and therefore limit the solution options.
• The design space is defined by the requirements and constraints and defines the boundaries within which possible solutions must be developed.
• Specifications define how the design team has chosen to meet the objectives of the project, within the design space.

References & Bibliography

Dym, C. & Little, P. (2009). Engineering Design, 3^rd edition.  Hoboken, NJ, USA: Wiley.

Horenstein, M. (2002).  Design Concepts for Engineers, 4^th Edition. \Upper Saddle River, NJ, USA: Prentice.

Meredith, J. & Mantel, S. (2012).   Project Management, 8^th edition. Hoboken, NJ, USA: Wiley.