Continue to Site

Eng-Tips is the largest engineering community on the Internet

Intelligent Work Forums for Engineering Professionals

  • Congratulations pierreick on being selected by the Eng-Tips community for having the most helpful posts in the forums last week. Way to Go!

Basic approach for product development in UK ? 2

Status
Not open for further replies.

Tobi_Witte

Mechanical
Jun 5, 2018
5
Hi,
i do a research and i am researching some methodlogies and approaches. So i have to research the product development in UK.
In germany we have the VDI 2221 and the model from Pahl and Beitz for product development. But what is the basis approach in UK for the development? Do they have one ? Because i do not find any. Hopefully you can help me. Thank you.
 
Replies continue below

Recommended for you

(Muffled laughter). I think it depends a lot on what industry you are thinking of. When I was working in the car industry there in the 80s the product development methodology seemed to be

1 design something
2 build it
3 break it
4 fix it
5 break it again
6 go to 1

Perhaps I am being unfair. Now globally we're committed to the product development V model, (not a particularly good article or diagram) start from requirements, break that down to the smallest level, build the car up from that low level. All loops are done at the same level so there's no surprises as you reach system integration level. In theory.


Cheers

Greg Locock


New here? Try reading these, they might help FAQ731-376
 
Thanks. So is there some Council which say thats the main model like it is in germany with the vdi ? I think in UK the organisation for this is the BSI, the british standards institution.
 
Hi

Good luck with the research. I followed Pugh (see the book 'Total design') during my study days. That is a good overview of a 'process to follow' in design engineering. If you read the book it may well reference some formal 'BS'XXXX' processes. Other pointers, the UK sometimes follows the old FPS. (Ford Production System so APQP & DFMEAs PPAP and so on...)

As Greg Locock mentioned the UK is far less regulated / standardised than Germany. Probably explains why we assemble stuff for German and Japanse and other foreign owned car companies, but we are quite technically innovative for the benefit of other countries most often.

BR

Rob.



Solid Edge; I-Deas 7 to 12; NX4 to NX8.5 / TeamCenter 9.1 & Ansys 14.5 / SW 2016 - 2018
 
@greglocock No they dont say how they have to work. But it is a guideline on which the most german companies are oriented. So thats a systematic approach on the development process.

Thanks for the answers. @robln the book of Pugh "Total Design" i also found. I have to read it.
 
If you look carefully, Greg's 6 steps listed originally is essentially embodied in the V-Model. The V-V arrow going back to the starting leg of the V is essentially "break it; fix it," particularly if you allow that failing objectives is "breaking it."

The big "V" is also dispersed as smaller "v"s located throughout the development process. In the canonical systems engineering process, verification and validation of the requirements themselves is one of the steps buried in the first leg of "V"

TTFN (ta ta for now)
I can do absolutely anything. I'm an expert! faq731-376 forum1529 Entire Forum list
 
So far as organisations go, INCOSE is starting to exert some influence in the UK.

A.
 
Aye but in the V model the left hand cascade is much better defined than the old way. Although, to pick a non random example, the target cascade for Austin Montego was the best I have ever seen.

It had to be better than the Audi model in every measurable characteristic (at about 80% of the cost). That's it. This is a brilliant move because you are working inside the design space that an existing product already has (ie it is already achievable). The alternative Pick'n'Mix approach (we have to be best in /class/ for every attribute) leads to disappointment because you are sampling local optima in the design space. I have seen the Montego approach used since and the product achieved market dominance (>50% segment sales) throughout its lifetime.





Cheers

Greg Locock


New here? Try reading these, they might help FAQ731-376
 
Dont tell the consultants but when you get past all the process jargon, fluff, ceremony, and other bs the various product development methodologies are largely the same.

Sorry but the thought of a country standardizing product development processes is rather comical. Usually within a given company there are multiples being practiced despite management decrees otherwise.
 
@CWB1 yep, that's the same i thought.

On my research i found the Designcouncil in UK. Could that be an institution who is reponsible for the design process in the product development with their methodolgy of the Double Diamond Methodlogy ?
 
I've worked in product and process development most of my 40+ year career and have observed Management efforts to standardize and document the product development process (PDP. There must always be an acronym involved, in order to appear "professional"). The desire is to be able to "manage" the process. In the end, the result is always the same. The only products that even attempt to follow "the process" are those products that no customer really wants. But "the process" forces people to work on it anyway, thus wasting time and resources until Management decide to abandon the effort as unsuccessful. Products that customers really want, do not follow "the process" because that would slow everything down by requiring many unnecessary tasks and approvals, which have priority over satisfying a customer need.
 
Yep, this sound legit. They want to find the one model who workes automatic, but like you say, thats the point i think it works most.
 
If you could write a process to do it that was cost effective and gave good results then I would write a computer program to do it and all the other engineers would be out of a job, we'd just have somebody telling the computer what the product is going to be, and a bunch of technicians and fabricators doing the rest. I could then buy a white Persian cat and a monocle and a tropical island with swimming pool full of sharks (laser beams optional).

Unfortunately for my retirement plans this post starts with "If".



Cheers

Greg Locock


New here? Try reading these, they might help FAQ731-376
 
Method #1 for fixing a problem found in the field: Get on with it. Call the technician over who knows something about the subject matter, point to the problem, get the tech to do whatever needs to be done to fix it, make some notes about what the omission was in the original design and what the fix was, send those to whoever's responsible for updating the documentation, then they can then take their sweet time with it while the folks in the field (including myself) can forge ahead with other matters.

Method #2 for fixing a problem found in the field: Can't do a thing without proper documentation. Email the designer with an explanation of the problem. Designer responds with a denial of the problem and that this was all taken care of in the design. Reply back with a photograph illustrating the problem. Wait for the designer to come up with a fix for the problem he didn't know he had. Twiddle one's thumbs for a while because the rest of us are stuck until it's fixed. Eventually the updated documentation comes through which the technicians in the field can obediently proceed with implementing.

Method #1 gets stuff done. Method #2 rigidly follows a process. Take your pick. I'm not saying one is always better than the other; there are certainly times when Method #2 has to be the way it is.
 
BrianPetersen,

Method #2 works fine when your designers are competent and professional and you trust them. This is a state you should be working towards. This is way more important than having a product development procedure.

Any design process should be worked out and maintained within the design department. I can think of no acceptable reason for higher management to impose a process.

--
JHG
 
Senior management need to buy into whatever process is selected because they'll be paying for it up-front.

In the V model, doing it properly needs an awful lot of test rigs and things that we didn't used to bother with, because at the bottom of the V you have to demonstrate that each sub-system meets its cascaded requirements. In fact the whole V model needs more people than the old way of doing things, I would estimate twice as many engineers for a given program. OTOH programs actually got cheaper at the same time, because it really encourages re-use, and needs fewer proto builds and cheaper protos. The old way was more fun. we used to Sketch X1s->Build X1s->Test X1s->Design an MP->build MPs-> test MPs->design an EP->build EPs->test EPs->design VP-> build VPs-> test VPs

In effect we designed 4 cars to get to VP. Now we build one X1. That's the only physical prototype we have until our only real proto build. We don't build many of them and then its straight into VP.




Cheers

Greg Locock


New here? Try reading these, they might help FAQ731-376
 
Management also needs buy-in into process to ensure its standardized across the organization. "Within the design dept" might work when your "dept" is <20 people, a small'ish team really. Within a company with multiple divisions you might have 5k engineers and draftsmen that need to be standardized.
 
Some years ago The management of a company I worked for showed us ( A group of designers and Engineers.) a film called " Working in Canyons.". It was criticizing the compartmenting of large corporations where a design team would get a project, work on it then hand it off to the next department, " Throw it over the Canyon rim.", without a clue as to what it was going to do, or its intended final fit and function, to another team who would do their bit and also " Throw it over." . The argument was that if department heads took the time and trouble to find out what the intended end use of the product was, a great many mis steps and re designs could be avoided.
Now I understand that in some defense industries this cannot be avoided, because of the nature of what they do.
But for general industry this should be a no brainer, but apparently it is not.
B.E.

You are judged not by what you know, but by what you can do.
 
We call them silos, same idea. The only military project I have worked on actually had a good handle on this because they took systems engineering seriously. I think it was written into the contract.

Cheers

Greg Locock


New here? Try reading these, they might help FAQ731-376
 
Status
Not open for further replies.

Part and Inventory Search

Sponsor