Your Reliability Engineering Professional Development Site
A listing in reverse chronological order of articles by:
In my last article, we reviewed a proposed Product Life Cycle process, which starts with a “Define” phase. In the “Define” phase, we are defining the project as well as the product.
We previously discussed the ‘technical leg’ of this process with the market analysis, identifying customer needs, product requirements, verification and validation, etc. [Read more…]
In my previous article we covered the advantages of a phase and gate structure for new product development. Now we can discuss some proposed phase names for a new product development or product life cycle (PLC) process.
An organization may have an existing PLC process ‘baked-in’ to their culture and process documentation. Accordingly, there’s a wide range of PLC phase names, all of which are likely acceptable and based on solid reasoning.
Hi Ash,
What are your best tips for safeguarding your job, but also rise to the top to score your dream position?
As a recent graduate, I have this fear that if the economy turns or my company starts doing poorly that I’ll be the first one cut. What can you do to be indispensable at work?
Thanks,
Erica, New York
In previous articles we defined an element of lean as a phase and gate structure for new product development. This assumes a waterfall approach to the project (versus agile product development).
A new product life cycle phase gate structure might entail, for example: “Definition, Concept, Design, Verification, Qualification, Production and End-of-Life”. (Your organization might decide on different phase names.)
There’s an apparent contradiction in using a waterfall project approach and calling it lean project management, however. A goal of any lean process is to work toward ‘single piece’ or continuous flow: agile product development is more like ‘single piece flow’ of information, versus waterfall which is more like ‘batch processing’ of information.
My last article covered a scalable model for lean product development depending on the number of projects and technical objectives.
Let’s start with the foundational elements from this model:
In this article, I answer one engineer’s questions regarding how to squash his nerves with a job offer negotiation. His question specifically asks about salary negotiation. However, as you’ll read in tip #6 below, it is better to focus on the whole package and consider other aspects of the offer that might be more important to you. [Read more…]
Think this was written about the elusive Sasquatch? Loch Ness monster, maybe? What about the abominable snowman?
Nope, nope, and nope. This was referring to good engineering managers.
In his opinion piece, Juan Pablo Dellarroquelle argues that engineers that are good at their jobs have little incentive to move into a managerial role because they are already influential leaders in an individual contributor role.
Alternatively, he argues, engineers who are weak technically are promoted to managers because of their organizational skills.
While this may be the case in some circumstances, in general – I disagree. [Read more…]
In my previous article we established the lean product development goal statement as:
We then derived high-level objectives as follows:
In my previous article, we established some high-level objectives for lean product development as follows:
Hi Ash,
Several managers at my company have told me they think I should pursue getting my Professional Engineer license. While I am not opposed to getting it, I am just not sure it will be worth it.
What do you think?
Thanks,
-Anonymous, Cincinnati, OH
In my last article the high level goal of lean product development was established as follows:
Develop products that maximize customer value and minimize product cost, in the least amount of time, and at the least amount of product development cost.
Let’s analyze this goal statement and establish some high-level objectives. [Read more…]
Lean product development might mean different things to different organizations, but let’s start with the 5 principles of lean manufacturing and see how it can be applied to the product development process. [Read more…]
Hey Ash,
I have a question about whether I should stay in my current engineering job or pursue other options.I work for an engineering firm that does contract work for other companies. We have recently lost a big contract. With this lull, I have been told that much of my work over the next several months will basically be document control.
As a new engineer, I am concerned that I will be missing out on valuable experience if I am not working on strong engineering projects.
So my question is, should I stick it out or look for another job?
Thanks,
-Anonymous
One of several reasons for emphasizing product requirements includes enabling modeling and simulations of designs, as well as ensuring adequate verification and validation testing.
Recall the fundamental framing of a requirement as:
Note the framing (within the requirement) of a mathematical and/or experimental relationship where “Y” is the output as a function of “(x)” as the input….Y = f(x) or as a function of multiple inputs Y = f (x1, x2, x3…xn). Let’s expand on this for a moment:
While previous articles focused on requirements writing, another element of products requirements is design constraints.
A design constraint might not be a requirement in the purest sense, but must be accommodated in product requirements (and, ideally, identified as such). Design constraints almost always make their way into product requirements.
Let’s use a simple example whereby a specific housing material is specified (a polyester thermoplastic elastomer).
The requirement might simply be: “The housing material shall be made of a polyester thermoplastic elastomer”. The PRD is then provided to the designer, essentially telling him he must use this material.