What do you care about

In your role when you are told that you are being tasked to design a product what are the first 5 things that come to your mind that will be important for you to achieve?

  1. a good design brief

:slight_smile:

I think Yo’s comment covers most comments that will follow as a good design brief should contain everything you need to know, but still…

  • Product Users - very important and not necessarily just the end user (e.g. fitters could be involved depending on the product)

What aspect of this project is most likely to fail? Has that aspect been tested?

I read a quote last week that read something like, “Hundreds of hours of design work can save you a few hours of critical thinking.” Probably my best work is in a garbage can because someone didn’t bother asking the customer/distributor if they were willing to pay for the product. Another reason is that instead of quoting the titanium part that was likely to cost more than the whole product was supposed to, they had me go ahead and design in high detail the whole product before quotation. It makes me want to have a uni. management course, because this seems widespread.

How important is unit cost?
How important is the schedule?
How important are the specifications?

This is based on the project management triangle. Pick two: cost, schedule, scope. Most people ask for all three and that means that decision is going to be made by someone who isn’t qualified or doesn’t have the information to make the decision. Nothing makes a manager a bigger @ hole in my mind than pushing this key decision onto the design engineer or myself.

Who is this for?

For all the talk of controlling risks, I’ve never seen anything that can reduce risk more than actually describing your customer. Even better if you can bring them in during the process for testing. And yet, again, something rarely known to, or well described by design clients.

Who is this for?

I am doing a short presentation at one of the IDSA conf. and the overall message i will be delivering is that different disciplines within the development group have different pain point - and those pain points and those people are not necessarily driving it or looking at it in the same ways other.

And one must learn to understand what is causing this in order to function as a team and support each other - the age old “you can add that” (no why provided) But we gotta have that (no why provided)…

Does it solve a real problem?

Are the benefits intuitive?

Are competitors vulnerable?

Will it fit the company strategy?

Will it be profitable?

Nice.

We also do that in order to kill the project as soon as possible.

we try to do that but i am amazed at how many ZOMBIE projects we have roaming around…

Management in these parts understands zombie projects are a waste of resources. It’s nice. Nothing more demoralizing than beating a dead horse. Who wants to be on that project?

I’ve never heard the term zombie project, but so appropriate. Where I used to work sometimes they would say “we are going to push that a quarter” … which became understood to mean “we are going to cancel this project but didn’t want to say that so we will just let it die slowly… but you can keep working on it if you want”

Sorry to be snarky with my first response. I was feeling punchy. :slight_smile:

I always searched for a term for those projects, zombies definitely fits the bill for me too!