If we set a product reliability goal of 99% reliable over two years in the requirements document, what are we supposed to do tomorrow? On the other hand, if our goal is to write 1,000 pages for the next great novel by the end of the year and we have no pages written so far, well, we should write a page or two tomorrow.
A good goal provides a vision, a measurable milestone, a target. What it lacks is what we do from now till achieving that goal. If the goal is 1,000 pages in 365 days, we may want to set up a process to write at least 3 pages per day.
So, given a reliability goal, what do we do tomorrow, next week, and each week between now and when the goal is due?
A Good Reliability Goal
In previous work, I’ve written about setting reliability goals, connecting the goal to customer expectations, technical capability, and business needs. Plus, have written about the four (five) parts of a complete goal, including Function(s), Environment, Duration, and Probability (and all four continue to get more difficult as customers expect more).
A well-stated reliability goal provides direction and a measurable target for the entire team. It provides a basis to compare progress and to help frame “is the design reliable enough yet” discussions.
This is all well and good, yet is it enough?
We may discuss building system models and apportion goals to various key elements of a product or system. We might discuss providing key vendors with specific goals for the elements they provide.
Yet, is that sufficient?
Set Your Personal Goals with a Focus on the Process
What do we, I mean you – the one that just got a clear good reliability goal stated, what do you do tomorrow?
Stating that you will begin work to achieve the goal is a start, yet what does that mean? Do you state task-related goals? Like you’ll organize an FMEA early in the process and a HALT with the first available prototype? Or, maybe you set the objective of doing at least 3 accelerated tests.
That rings a bit hollow, right?
Instead focus on the process that it takes to achieve a specified reliability of a product. Focus on understanding what you know, what you don’t know, and what you need to know.
You and your team may know about specific risks to the reliability goal, so what can you do to quantify those risks? Your team may suspect other hazards, so focus on what you need to know, and by when?
See the difference?
The idea is to select the tasks such that you can regularly gauge progress toward achieving the product’s reliability goal. This includes quantifying time to failure information that is available, creating experiments to discover new failure mechanisms, and to steadily populate what you know from what was the realm of what you didn’t know.
Your goal is to find the information necessary to understand failure mechanisms and time to failure patterns. It isn’t doing three rounds of FMEA. What if you only need one or maybe six? Three is arbitrary. Instead, focus your work, your personal goals on understanding and revealing how the product is likely to fail over time.
Ask for Help along the Way
Long gone are the days when one person can know a majority of the known knowledge. You may have mastered reliability statistics or product testing, maybe failure analysis or system reliability modeling, yet it is unlikely you have also mastered electrical, mechanical, and software engineering, not to mention human factors engineering, user interface design, industrial design, etc.
It takes a lot of knowledge from a wide range of disciplines to create a product for today’s markets. What you can do in support of your goal (focused on the process to create a reliable product) is to ask questions, to ask for help, to seek advice and guidance.
Keep in mind that you are not alone in the endeavor to create a reliable product. Even if you are a one-person startup. You have suppliers, investors, and potential customers all interested in you being successful. With a team, well, you have a team.
The process of asking questions and for help provides a means to marshal the available resources to focus on the process necessary to create a reliable product. Your questions can be about what is at risk, what is known, or unknown. Your questions may shift to what is needed to select suppliers or among design options, again with a focus on what is necessary to achieve the reliability goal.
The basic idea is an overall reliability goal establishes an objective, your question help to frame how to select the necessary tasks you and the team need in order to achieve the goal. You don’t know if both FMEA and HALT are necessary until you understand what is known and unknown with greater detail. It’s your questions that help reveal the information you need to plan the course of action for the coming day, week, month, etc.
Structure Your Goals to Achieve Your Project’s Goal
The organization or product development goal may be to achieve a specific level of reliability, or better. That is not a good goal for you such that is it too vague to guide what you need to do along the way.
Structure your goals to focus on the process. The process is about understanding the known and unknown reliability risks, and working to prioritize and mitigate those risks. The structure is framed by what decisions need to occur by what date. What information is necessary to make the best or right decisions. Then, consider what needs to happen to get the necessary information to the right people.
You need to sort out what you need to do, before setting out a list of tasks to accomplish. Make sense?
Leave a Reply