When working with a team creating a new system, I always ask, “what is the goal?” The answers often do not make much sense. The team using SMART reliability goals are astonishingly well-stated.
The difference that makes a goal, objective, or requirement practical and useful is summed up by SMART. A SMART goal is Specific, Measurable, Achievable, Relevant, and Time-bound. Let’s explore each element as related to a reliability goal.
Details matter. Saying we need to improve the reliability or that we need to be as good or better than the last project is too vague. Instead, include a few details, so all are clear on what we are trying to achieve.
For the function element, many summarize the primary function. Such as for a mobile phone, the primary function may be to provide portable communication. Then reference another document that details the full array of functional requirements. Likewise, for the environmental element, it is a good practice to have another document or set of documents that detail:
- frequency of use,
- and all other expected stressors.
This one is tricky for a low failure rate, long-lived, or complex products. It is often difficult to measure the reliability of a system. Yet, stating a goal includes details such as the probability of an item operating for a specific duration. If your product’s goal is to operate for one week on your lab’s benchtop, great, the challenge then is getting enough samples. Although most products have longer desired durations and many have relatively low failure rates, making life testing complex and expensive.
Other than testing to estimate system reliability, we can use modeling tools and other techniques to create a meaningful measure of a system’s reliability.
Achieving a reliability goal of 100% of units will fail within their first year of operation is possible and rather trivial to achieve. It is not a common objective. On the other hand, setting a goal that 100% of units will survive their first year of operation is technically not possible as there always is a finite chance of at least one unit failing over the duration.
100% reliable is not feasible despite sounding great on marketing collateral. Therefore, set a SMART reliability goal with a realistic chance for the team to achieve from technical, economic, and business points of view.
A goal always has a setting or context. The idea is to state why we want to achieve this goal. Where does this goal fit into our strategic business plan? For example, achieving a specific reliability goal may directly connect to the system’s profitability or safety.
Stating a reliability goal includes a duration, which is not the same as stating when we expect to achieve the goal. Set and state a deadline. This often means when do we need to have the measures the goal available for decisions that depend on having achieved the goal. For example, it is common for a development team to consider reliability information to decide if the system is ready to transition to production.
A SMART Reliability Goal
When drafting a reliability plan or being handed a reliability goal, check if the goal is fully stated and if all the elements of a SMART reliability goal are clear. Setting a goal is similar to making a request. Setting a target includes the expectation of cooperation and efforts toward it.
Stating goals clearly helps avoid confusion, working at cross purposes, and project delays. Stating a reliability goal using the SMART framework provides the team with an understandable, meaningful, and practical way to understand the goal.
For more information and examples, see the MindTools post titled SMART Goals.