when all else fails, read the directions!

[mobile_bob]

this is directed at the engineers of our group

from doing some reading it appears the big boys follow a certain chain of events
when they set out on a new project.

sort of a step by step from conception to completion of the project.

as diy'ers i think we can not only learn something from this discussion and development of a list here, but we ought to be able to apply it to the development
of some of our more complex projects.

so lets open this up and see where it goes?

bob g

[Jens]

A real man doesn't read (or ask) directions !

[BruceM]

I still follow the same procedure for home projects as for R&D management.  I do terribly miss having big budgets and staff of sharp young engineers!

1.  Research the design and or problem with priority given to highest risk areas or components.  The biggest risk is the area which is outside your knowledge and experience, so that you can't estimate risk, time, cost. Drill down there, or find an expert who can help. Long hours go here, until you can see your way through the entire project, without any serious "could bite me in the ass" unknowns.  If some part is too unclear, you should consider doing "exploratory" or rapid prototyping (quick and dirty kludge) work there as part of project planning.  

2. Develop a technical  plan for  the proposed solution.  For smaller home project this can be napkin sketch work.  

3. Plan the development process. (What to work on and in what order.)  In your proposed development schedule,  find a way to VERY early, work on the riskiest components, if necessary making parallel approaches so that if one approach doesn't pan out, another will. It is foolish to start working on the easy, known, well defined, low risk areas just because it's comfortable and you'll quickly have something to show towards "progress".  

Having clear milestones with demonstrable, visible progress is important in corporate or government projects, obviously, and it helps morale for personal projects.  But earliest, highest priority MUST go to sorting out the high risk areas.  Rapid prototyping is often valuable here, for both software and hardware- just "duct tape it" together, make sure it's going to work, then you can "throw that away" and do it right.

Computer hardware is cheap, and even more so at the microcontroller scale. Adding another processor to allow ease of development of a subsystem is almost always the right choice.  The design of the project should in a large part be oriented towards making it easier, and less risky, to develop.

4. Early integration of hardware and software is essential.  It can be a dangling mess that only shows the end to end operation, with virtually no real functionality in place.  The project should be designed so that critical pieces that need to interface should be able to be developed together, independently of the rest of the project.  Big projects where "integration" occurs late will always be a disaster, early integration with subsequent fleshing out of functionality is the ticket to success.


For small home hobby projects, much of this can be "in your head".
But I think the basic principles above apply.

[mobile_bob]

Jens:  sadly this is many times the case, and generally i get to do it twice
once without the instructions and again to get it right with the instructions.

Bruce: thank you for the input, this is exactly what i would like to see us establish
here.

i am not saying that we as a group have a problem, but having frequented other diy forums on other topics, there is a real need to set out some sort of procedure or step by step guide for folks to use in developing idea's

often times it seems that someone will come up with an idea, build it, do some shaky testing and return with equally shaky claims, then have bunches of other members all run off and try to replicate the project... this is fraught with many problems.
1. the original builder doesn't document things well...
2. other builders don't have enough info to replicated...
3. other builders take artistic license which adds yet another variable...
4. other builders use all sorts of testing using equally shaky procedures at worst...

then when everyone finds that the result is less than spectacular or a miserable failure they all write it off as "a bad idea", "impossible project" or some other negative, when the reality might have been quite different had there been some guidelines or step by step procedure list to work with from the start?

what i am thinking here is this,

we have a large group of folks of varied experience and interests, likely most of at least average intelligence more likely of above average.  we ought to be able to work together to produce any project we set our minds out to do within reasonable boundaries.  this does not mean we all have to work on the same carbon copy project, nor does it mean we can't or shouldn't. what it does mean is we ought to be able to put together a few guys to commit to a project of common interest and benefit, while also having others aid in the project not so much from a hardware standpoint but from all the other ancillary stuff.   we have engineers in the group that surely can oversee the math involved, other guys are excellent at sourcing parts, others are good at drawing up stuff to scale, still others are good at research, still others can be good at being a sounding board or devil's advocate to look for weak links in a plan,  we got puter programmers that can certainly work out coding issues, folks that are good at documentation, etc.

it just seems like a huge wasted opportunity to not at least take a look at our collective mental resource and talk about how we could do something of real significance?

this might be an impossible task, maybe as diy'er types we are for the most part type A kind of guys, and don't take well to working together at this level?

i don't know, but would like to talk about it.

it might be that this forum is not the venue for such a project?  maybe we take this to the somrad group and build it from there?

what do you guys think?

bob g

[sailawayrb]

1) Research - Learn as much about the subject as possible, particularly obstacles that others have encountered, "lessons learned", etc.

2) Concept Development - Brainstorm all possible solutions.

3) Feasibility - What is realistically possible, what is the cost to do it, what is the ROI?

4) Define Specific Design Requirements - Create general layout or drawing of product identifying the design parameters.

5) Preliminary Design Review - Select a concept to build.  Create preliminary layout and drawings with preliminary values of the design parameters defined.

6) Critical Design Review - Create detailed layout and drawings with the final values of the design parameters defined.  The preliminary values are finalized via engineering analysis process.

7) Build - Build a prototype of the product.

Test - Test the prototype to determine if design requirements have been met and determine if any changes need to be made.

9) Production - Select methods and materials to economically mass produce the product.

I pretty much follow all these steps for everything I design.  I find spacing the steps out with sufficient time and beer in between the steps results in the best design.

Bob B.

[Lloyd]

Hi Bob,

I posted a topic or white paper on this very subject.

Funny thing is it is very similar to BruceM's way of doing business.

Well maybe not so funny, it was also military based.

I look for it and post a link here.

Lloyd

Jens:  sadly this is many times the case, and generally i get to do it twice
once without the instructions and again to get it right with the instructions.

Bruce: thank you for the input, this is exactly what i would like to see us establish
here.

i am not saying that we as a group have a problem, but having frequented other diy forums on other topics, there is a real need to set out some sort of procedure or step by step guide for folks to use in developing idea's

often times it seems that someone will come up with an idea, build it, do some shaky testing and return with equally shaky claims, then have bunches of other members all run off and try to replicate the project... this is fraught with many problems.
1. the original builder doesn't document things well...
2. other builders don't have enough info to replicated...
3. other builders take artistic license which adds yet another variable...
4. other builders use all sorts of testing using equally shaky procedures at worst...

then when everyone finds that the result is less than spectacular or a miserable failure they all write it off as "a bad idea", "impossible project" or some other negative, when the reality might have been quite different had there been some guidelines or step by step procedure list to work with from the start?

what i am thinking here is this,

we have a large group of folks of varied experience and interests, likely most of at least average intelligence more likely of above average.  we ought to be able to work together to produce any project we set our minds out to do within reasonable boundaries.  this does not mean we all have to work on the same carbon copy project, nor does it mean we can't or shouldn't. what it does mean is we ought to be able to put together a few guys to commit to a project of common interest and benefit, while also having others aid in the project not so much from a hardware standpoint but from all the other ancillary stuff.   we have engineers in the group that surely can oversee the math involved, other guys are excellent at sourcing parts, others are good at drawing up stuff to scale, still others are good at research, still others can be good at being a sounding board or devil's advocate to look for weak links in a plan,  we got puter programmers that can certainly work out coding issues, folks that are good at documentation, etc.

it just seems like a huge wasted opportunity to not at least take a look at our collective mental resource and talk about how we could do something of real significance?

this might be an impossible task, maybe as diy'er types we are for the most part type A kind of guys, and don't take well to working together at this level?

i don't know, but would like to talk about it.

it might be that this forum is not the venue for such a project?  maybe we take this to the somrad group and build it from there?

what do you guys think?

bob g

[Lloyd]

Here is the link to the posting at Micro...gen,  http://www.microcogen.info/index.php?topic=125.msg32953#msg32953 and the link to the PDF http://www.ornl.gov/~webworks/cppr/y2001/rpt/113709.pdf

On target to how the big boys play, or a road map for how us little guy form a plan.

Lloyd

An excerpt:

The primary criteria and requirements for the proof-of-concept units were:
• 50, 60, & 400 Hz from single unit
• Reduce gen-set weight (up to 55%)
• Reduce gen-set volume
• Increase fuel efficiency
• Maximize flexibility
• Low acoustic signature (65 dBA at 7 m)
• Keep production costs low
• Maintain system reliability
• Meet aggressive proof-of-concept schedule

Hi Bob,

I posted a topic or white paper on this very subject.

Funny thing is it is very similar to BruceM's way of doing business.

Well maybe not so funny, it was also military based.

I look for it and post a link here.

Lloyd

Jens:  sadly this is many times the case, and generally i get to do it twice
once without the instructions and again to get it right with the instructions.

Bruce: thank you for the input, this is exactly what i would like to see us establish
here.

i am not saying that we as a group have a problem, but having frequented other diy forums on other topics, there is a real need to set out some sort of procedure or step by step guide for folks to use in developing idea's

often times it seems that someone will come up with an idea, build it, do some shaky testing and return with equally shaky claims, then have bunches of other members all run off and try to replicate the project... this is fraught with many problems.
1. the original builder doesn't document things well...
2. other builders don't have enough info to replicated...
3. other builders take artistic license which adds yet another variable...
4. other builders use all sorts of testing using equally shaky procedures at worst...

then when everyone finds that the result is less than spectacular or a miserable failure they all write it off as "a bad idea", "impossible project" or some other negative, when the reality might have been quite different had there been some guidelines or step by step procedure list to work with from the start?

what i am thinking here is this,

we have a large group of folks of varied experience and interests, likely most of at least average intelligence more likely of above average.  we ought to be able to work together to produce any project we set our minds out to do within reasonable boundaries.  this does not mean we all have to work on the same carbon copy project, nor does it mean we can't or shouldn't. what it does mean is we ought to be able to put together a few guys to commit to a project of common interest and benefit, while also having others aid in the project not so much from a hardware standpoint but from all the other ancillary stuff.   we have engineers in the group that surely can oversee the math involved, other guys are excellent at sourcing parts, others are good at drawing up stuff to scale, still others are good at research, still others can be good at being a sounding board or devil's advocate to look for weak links in a plan,  we got puter programmers that can certainly work out coding issues, folks that are good at documentation, etc.

it just seems like a huge wasted opportunity to not at least take a look at our collective mental resource and talk about how we could do something of real significance?

this might be an impossible task, maybe as diy'er types we are for the most part type A kind of guys, and don't take well to working together at this level?

i don't know, but would like to talk about it.

it might be that this forum is not the venue for such a project?  maybe we take this to the somrad group and build it from there?

what do you guys think?

bob g

[veggie]

1) Research - Learn as much about the subject as possible, particularly obstacles that others have encountered, "lessons learned", etc.

2) Concept Development - Brainstorm all possible solutions.

3) Feasibility - What is realistically possible, what is the cost to do it, what is the ROI?

4) Define Specific Design Requirements - Create general layout or drawing of product identifying the design parameters.

5) Preliminary Design Review - Select a concept to build.  Create preliminary layout and drawings with preliminary values of the design parameters defined.

6) Critical Design Review - Create detailed layout and drawings with the final values of the design parameters defined.  The preliminary values are finalized via engineering analysis process.

7) Build - Build a prototype of the product.

Test - Test the prototype to determine if design requirements have been met and determine if any changes need to be made.

9) Production - Select methods and materials to economically mass produce the product.

I pretty much follow all these steps for everything I design.  I find spacing the steps out with sufficient time and beer in between the steps results in the best design.

Bob B.

and in some cases...

6a - Simulate the system (can be a scaled down version or a full blown computer model of the working system)

veggie

[quinnf]

Interesting.  Bob's list would be recognized by anybody who works in product development in a pharmaceutical company.  Same methodology my employer uses when we begin development on a new drug product, or reformulation of an old one.  Everything is mapped out ahead of time with periodic decision points and probabilities of success built in to the development plan.  Only major difference is in building in the need to satisfy the regulatory authorities and conduct clinical trials on real live patients.


Quinn

[bschwartz]

Does anyone remember the scene from Apollo 13 where they needed to make the CO2 scrubber from one system fit into another incompatible system using spare bits laying around?

That is the type of engineering I enjoy.  How can I solve a problem with the stuff I already have laying around the scrap pile.

[veggie]

Does anyone remember the scene from Apollo 13 where they needed to make the CO2 scrubber from one system fit into another incompatible system using spare bits laying around?

That is the type of engineering I enjoy.  How can I solve a problem with the stuff I already have laying around the scrap pile.

Same here !    .....  and don't forget McGiever !  
He once made a laser from a ball point pen to cut through some chains. Awesome !   

veggie

[Mad_Labs]

this might be an impossible task, maybe as diy'er types we are for the most part type A kind of guys, and don't take well to working together at this level?

That's part of it. Another part is that it is less fun to document and more fun to push on.

Another part is such a diverse group is less likely to do things the same way, the software guys attack the problem with software and the hardware guys attack it with hardware. The engineers attack it with a pencil...

Me, I am not educated in any field and so am stumbling through and don't really have the experience to plan. Today for example I am working on designing a rack to hold 18 solar panels on a shipping container. I have very little steel building experience. I can't draw worth a darn and I wanted to get an idea of how I would do corners, attachments etc. So I too some steel and started cutting so I could see what it looked like. No way for me to plan, I needed to do.

Jonathan

[Tom Reed]

Funny, my trade is as a software developer and I prefer not to have any computer stuff on my generator or my transportation.