Designers, Where Do You Start?

I agree. Define the requirements first. Guard against requirements creep! (Guard against requirements, Creep?)

When I was an engineering manager, this always hung up the younger engineers, they were always overwhelmed.

I have a tendency to break it down.

The primary, is to establish a goal. i.e. what needs to get done. And keep my options open for as long as possible. When I have a satisfied initial concept. I look through out the process, I may skip around the development part, just due to concurrent engineering in the different areas that may have to get done.

Keep working on it, let it evolve until I am certian, I have a process or design that will perform to expectations. Then the work or I should say 'Time Investment' begins.

So I guess 'take a sip of coffee' isn't the right answer.

Well lets see what the project plan has to say,...... uhmmmmm, let's see heereee......... uhmmm,........ oh, here it is!

Step 189091109, Part B

Get Coffee and consume at a comfortable rate!

That's the Health Care Bill, isn't it?

Actually no one really knows, and they're afraid to ask for fear of looking stupid.

I use that and actually call it my master reference book. I use it for all occasions.

To decide an aurgument, to stop an aurgument, to start an aurgument,........

Plus I have to be careful. CR4 Gods shook their finger at me if I get political or religious.....

I still think my reply on Re: Caption This for 09/21/12 even though it was religious it had a sharp truthful humor.

As far as the healthcare bill......

-. --- / -... .----. --.. . .-. --- / ..--- ----- .---- ..---

Picture of the U.S. tax code publication.

Or the Males manual on understanding women!-)

Ah, it's exactly the right answer! (or tea, but wha'ever)
I start by thinking about the feasibility...there are plenty of requirements out there that just aren't feasible.
I then declare it can't be done... then I ponder for half an hour and go...
Ah, but maybe...
I then think about how quick I can get some sort of prototype or proving model going so I can have a look see applying the KrisDel^TM WAQAP approach (Wrong As Quick As Possible)
Then I design it and we all become millionaires loose interest before doing all the paperwork.
Or... if it's a bow I start by looking at my stash of seasoned timber
Del

I start with what this has to do. Get coffee and then sit and contemplate what all it will actually do. Then R&D of all parts, how to control the actions, power source, and in the end you end up with a piece of equipment. My first experience of a major let down was spending 1 year in bits and pieces of time nights and weekends designing production equipment to enhance the jobs the women were doing to make it safer for them. One day while at the Bridgeport 13 women were yelling at me in the middle of the day walking out the front door, due to what I was doing I really couldn't pay much attention to them. When I got done milling the piece. I went to see the Plant manager as to why a bunch of people left in the middle of the day yelling at me something. He laid them all off because my machines replaced them. I stopped making automated production equipment as I did not want to see anyone else laid off. That was not my plan. This was Aug 1984.

Scope document. What does the customer what it to do? Waht does he not want it to do. What can't I make it do. (If set for killing squibbles, it will leave cats along and vice versa).

When designing test plans, my first question is: What do you/we want to know?

Writing it down is important - as is getting the other party to sign it. Scope creep needs to be measureable too!

Remember

Scope Creep kills!

Just Say NO to Scope Creep!

Scope creep is easy to manage. I use the two-step process when a customer or senior staff member wants to initiate a change:

1. Impact analysis - inform customer/management that the release date may be delayed while the magnitude to the change request is determined and its impact to schedule.

2. After the impact analysis is complete and new schedules are determined, inform customer of the costs (both time and material) for the change. We usually add the caveat that any decision delay may further delay release.

Usually, the customer will drop the change request at that point or if they do accept the cost, then we both have a realistic understanding of the new schedule.

Never try to be the hero and pull a miracle out of your hat. If you do it once they expect it again and again because you have set a precedence. Much like training a dog.

It is easy, But it cannot be taken lightly and has to get addressed.

This may be a tangent but it is important.

From the experienced that I had, I would be called in to deal with a project, the customer would want to salvage it, but at times the best alternate was to kill it. Allot has to do with lack of performance, from a poorly conceived design foundation.

What I have seen, is when the engineer is the project manager.........e.i. project engineer. And this is on small manufacturing business $5-20 million/year shops. There is nothing wrong with that, but it is allot of responsibility, ot to be taken lightly.

The scope creep is unnoticeable, from just $25.00 to $100.00 upgrades. The idea is own this does not warrant my time to issue a costumer change notice for the price increase. That price has to include your time. From there, it escalates and the engineer who realizes he painted himself in a corner due to lack of communications. Bolts from the company before it hits the fan.

I have seen $1,000,000.00 OEM projects that had over $100,000.00 worth of verbal yet unapproved upgrades. When I walk into a situation like this, I can usually work out an agreement between customer and the manufacture.

What is difficult...... the term is more like impossible is when I see similar projects, but the project has no chance of performing. Those are very dark times for the company.

Had one company that had repeated projects of the like.

My alternative option was limited. which was land a good solid contract and unload the company. Which It happened, Its sad that the company came down to that. But you have to be careful and not take Scope Creep lightly as in the results of these cases.

And after pulling some of those companies projects out, I gain an adverse reputation in the industry. No matter how low a profile I kept. When a clients, customer saw me on the premises, they knew there was something wrong.

That's easy when you're working for paying customers. When the "customer" is internal and your boss, or boss's boss, they just go deaf when you make those points. The ones round here do anyway.

I've used the "don't set a precedent" argument with previous boss. He didn't heed me, and now we're all stuck with the expectation that we'll deliver "on time" when other departments have had the info for 3 to 6 months and now we're within a week of the due date they decide it's all too difficult....

/rant

I have seen this in a few companies and know that it is a wide spread problem.

I have personally led the charge for change in this regard. The stark fact is in the track record of the past. If the company is always struggling to to meet schedule and is chronically late, then there is a systemic problem. The other sign is lots of chronic overtime.

In all cases the company wants to do something and does not know where to get started. This is where getting management to first recognize they have a problem and then getting them to commit to change are the first steps.

The second set of steps is organizing a plan of action, which includes schedule fidelity. You must empower each engineer to draft a realistic schedule (for their set of tasks) and one that they will commit to. That is, if they state they will get this task completed by a specific time they are to be held to that date.

The schedule becomes engineering driven rather than management driven. This takes a little nervous commitment from management, but once they see the improved schedule fidelity it becomes much easier to sell and the company gets a reputation of meeting its commitments instead of being in a constant state of fire fighting.

The final step is anchoring that change into the culture of the company. If you do not diligently keep the change alive the company will drift right back into old habits and become disenchanted with the idea that the problem can ever be fixed. At that point people start jumping ships, and rightfully so.

Thanks for that...it put it in perspective.

My design goals.

1. Make it simple.

2. Make it easy to build.

3. Make it cost effective.

4, Make easy to operate.

5. Make it reliable.

On the smaller scale stuff I design, one problem is when the specification is dreamed up by someone who isn't the actual end user.
Mind it's tricky as it's hard to define the end user.
Taking a simple dosing unit designed to pump detergent and rinse aid into a commercial dishwasher in a kitchen.
Is the customer.
a) The distributor who sells the unit.
b) The installer who has to fit it.(probably yes)
c) The chemical supplier who pays for it (and the installation) and owns it.
d) The kitchen supervisor who just wants fit and forget.
They all have different requirements..
e) Or our salesman who wants something new and different and better and cheaper and pretty to offer.
Send your answers to the KrisDel Incinerator
Del

I have found this to be true only to have it verified as a standard understanding in project management.

You have three choices.

• Scope
• Schedule
• Cost

Then you pick 2 two of the (3) three that need to be followed, the one that gets left out suffers.

Oh yah, I wonder if the original poster thought maybe it wil consist of actual design.