Miner,

A new design project is usually the result of an identified need for it.  Your starting point is gathering information.

Target Sales Price for the product
Target Market Introduction Date
Physical Requirements and Product Features
Estimated Market Potential or Sales Volume
Expected lifecycle

Get the above information in writing as you may need to frequently refer to it as the project progresses.  It may also be used to keep the project within a reasonable scope lest you fall victim to "feature creep" or some other insidious project killer.

Your market introduction date helps you to determine the time "available" for project completion.  Sales price - typical margins should give you a good handle on overall product cost.  The rest of the information gives you basic design requirements with which to work.

Talk with the designers of other products/projects similar in scope/scale.  They should be able to help you get a feel for the initial outlines for project schedule and costs.  Your manufacturing experience will start coming in handy here as you work the inital schedules.  You may need to re-establish timelines based upon the types of effort needed and available resources.

Get going on design concepts.  Communicate with customers, marketing, suppliers, service, and manufacturing.  All can be useful sources of information.  Brainstorming should be free flowing ideas and no critiques.  Save that for the design review(s).

Do some designs.  First try to satisfy performance requirements and then refine from there.  You will likely have multiple design reviews (dependent upon complexity) to narrow down the prototype(s) to the design targeted for production.  Do a Failure Modes and Effects Analysis (FMEA) on the design and on the anticipated production processes.

This is a starting point.  Above all, communicate!  You will need to effectively work with most of the organization.  Your success or failure depends on it.

Regards

The most valuable asset a design engineer can have is what you already have, a background in manufacturing or service.

The nature of the design world requires changes in product specifications, etc from concept to completion. However, many discussions should take place about the proposed product with whoever is wanting this product. This may include the end user and/or your engineering manager and/or the sales/marketing department. Even if sales is not involved, a good feel for what they would like (based on customer feedback) is important. I have seen time and time again product design/proto time increase significantly due to lack of proper specifications up front. Although, there will always be changes you can minimize them with thorough discussions with everyone on the expected functions and especially the 'cool' features.
Someone mentioned before that a session on ideas should be just that an exchange of ideas. Do not let someone critique the suggestion as this will only lead to no suggestions. I have seen this before on many occasions. Do not invite those that feel they need to dismiss a suggestion or idea at this meeting. Leave the arrogance outside the meeting room.
Your background will help a lot in the design world. A lot of design engineers don't have this experience so you have something to offer that they don't.

Look at what other people have done, why they did it like that, what's good about it, and finally what's wrong with it. If you can do that you're half way there.

Maybe we should start a new thread on brainstorming - suffice to say I'm not a big fan.

I'm sure people have covered these points, but in my opinion these are the big hitters:

/Always/ go and ask the person who is handling the warranty for the previous model, or similar products, what goes wrong.

Engineers are not typical users, try and get real world input.

Trade-offs in the design process are very tricky- there are formalised approaches, but they are built on very shaky foundations. It is rather irritating to see weeks of technical analysis reduced to a subjective '++' in a grid on a whiteboard!

Talk. Talk to your draftie, talk to your manager, talk to the manufacturing guys, talk to the users, talk to the testing people. I found being a design engineer exhausting, not from the technical side, which was a doddle, but from the necessity to communicate continuously.

Schedule early, keep it updated and accessible.

Get your modelling/prototyping done as soon as possible.

Good luck, the feeling you get when 'your' first product finally hits the street is addictive.

Cheers

Greg Locock

Take a good long look at the equipment that you never have to fix.  There is something to learn by studying what works.

Look at old equipment.  The older the better.  Very often you will find very elegant and now forgotten design solutions.

If you ask someone why something is done a certain way and the answer is "We always do it like that.", find someone else to ask.  If you get the same answer, figure out the real reason they always do it like that for yourself.

Trust your experience.

If you can define it, you can design it.

When designing, take the time to digest the issues thoroughly.  Time spent "front loading" your design process with study and understanding might delay the start of "laying lead" (or virtual CAD lead), but it will nearly always save time at the tail end by eliminating fixes and redesigns.

All this machinery making modern music can still be open-hearted.

In my MBA studies we covered a lot of case studies on problem solving methods.

The main lesson was never to jump to formulating a solution to any problem before you have finished defining the problem.

One case study that I remember, involved a textile mill that in the late 1940’s would periodically start spinning thread that was black instead of white. Several iterations of fixes were proposed, implemented and found unsatisfactory. Some of these solutions cost significant amounts of money.

The final solution came when someone analyzed the black colour and found it to be soot. The final fix was to ask the railway crews to park somewhere other than under the air intake when they stopped the coal fired locomotives for their lunch breaks.

Like the tick said, always fully define the problem before you start to design the fix.

Rick Kitson MBA P.Eng

Construction Project Management
From conception to completion
www.kitsonengineering.com

I've been through two design processes now, and in both cases, the biggest headache has been the fixtures.  The first was a set of moulds for curing carbon-fibre parts in an autoclave.  Some moulds worked perfectly every time.  Some degraded in performance very quickly, and others were so bad, they had to be remade for every part.  Fortunately I only needed four runs.  The bad moulds were products of a bad suggestion at the outset of the project.

The second design project suffered from welding fixtures that were quickly done in the prototyping phase.  We figured they would do well in production, but interchangeability of assembled parts just wasn't there.  We've remade the fixtures now, but there are still half a dozen products out there that you can't switch out for new ones (without drilling out some holes).  So far, nobody's come back needing replacements...

My advice:
1 A prototype is only a prototype.  The tooling should be considered a prototype, too.  Re-using the same tooling for production should cautiously be considered (depending on the product, of course).

2 Criticizm is essential when a project begins, but don't let anyone use it to stop the creativity.  If that's what's happening, then only half your problem is the nay-sayers.  The other half are the wimps that can't defend their ideas.
If you're a project leader, then you should also be concerned with keeping track of the discussion to prevent ANY ideas from being brushed aside without proper consideration.  The "brainstorming" technique where nobody is allowed to critique doesn't have much credibility when compared to an honest discussion, IMO.

STF

I would add that a design engineer must have a good idea on how the assembly would be assembled by workmen. It may sound stupid, but I have seen some really impressive design that were very difficult to assemble.

Also, a good design engineer must be able to see objects in his/her head, before even drawing the first line.

On a last point, I think he/she must also have a solid capacity to see things in space. Most of the design work in done with CAD programs nowadays, which simplify our work, but still, you need to understand how things are when you look at your monitor. This skill becomes obviously a requirement when you draw in 2D

Cyril Guichard
Mechanical Engineer

Thanks all for the good suggestions so far...please feel free to keep them coming as long as there is discussion to be had.

Strangely enough, I already do a significant number of these things as part of my current job.  It may be difficult to find out why someone did something in the middle of a project, but try to find a piece of puzzling history on a 7 year old product...you have to get pretty good at reading a drawing (and in most cases the history tree in a solid model) to try and decipher the design intent. (if you ever want to see a good set of mechanical designs, take apart an old tape player...the inner workings of those machines can be very interesting)

Rick - the case that you are talking about is actually very common.  I have personally worked on several problems that involved outside influences like that...one of my first questions is always "how is their environment?"

Greg - if you would like to start a new thread on brainstorming, please do so, but I would be interested to hear your views...why are you against it and what do you propose to do instead.  I am also not a fan of "thinking outside the box, touchy feely, not based in reality" brainstorming, but I have not found a good model of an alternative design concept discussion.

Miner

Personlly, to build on your experience in mfg, I'd take a look at books/courses on DFM/DFA (Design for Mfg/Assy) and, if appropriate, DFSS (Design for Six Sigma).

A lot of it is common (?) sense but I've found it helpful to see some things concisely stated which I've only had a general sense of.

Also, don't disregard human factors. I'm amazed at how often I find things where the designer evidently never considered that a human hand holding a wrench might someday need access to spaces.

As stated above, define, define, define. Then get buy-in from the stake-holders early on. I've seen too many design projects that fail because the requirements continue to evolve after the design work has begun.

Good comunication is probably at the top of my list, however -
One point possibly missed by these replies is that managing a design project is largely about managing risk through continual decision making. Minimising 'time to market' for a defined deliverable and fixed resourse is always a challange.

Identify all project risks - likelyhood and consequence. Remember that a low risk which has no work around is proably worse than a recognised higher risk where alternatives are known, waiting if needed.

Evaluate time and cost required to mitigate the most significant. The mitigating action could be anything from building hardware, testing, changing design, changing specifications, starting other projects - or sometimes lots of talking.

Then decide which risks to take and which to reduce.  
This should be an almost continuous process.

GE had an interesting publication entitled "Lessons Learned." It was a frank discussion of design failures and how they were fixed. This was made available to all personnel in the company. I found it very instructive. It served several functions: showed designs that were problems; showed solutions that worked; exhibited the "company" style of design solutions.

Every organization could benefit from this kind of book.

Each system or subsystem we design has a system binder. It includes the FMEA for that system, the design verification procedure, and the lessons learned from designing previous similar systems. In theory these lessons learned get included into the FMEA for the next time we redesign that subsystem.

Anyone can make a mistake once, the crime is not learning from it.

Cheers

Greg Locock