One of the more overlooked elements of leadership is explained direction. This is where leaders take the time to describe (in a tailored, personal way) to everyone how their individual efforts directly contribute to organizational success.
The leader of course first needs to have a clear idea of what success is and a strategy to get there (otherwise how can they know how you or I are an important part of getting there?) People appreciate when leaders explain to them how their HR, design review, testing, and quality assurance efforts directly create value. This helps motivate, measure achievement, and all sorts of other good stuff.
On the other hand … simple comments embedded in the third hour of a CEO’s annual address like ‘reliability is important because we want to be known as an industry leader’ simply don’t cut it. It’s too loose, too vague, didn’t take long to think of, and is clearly not a priority.
So how can we address this when it comes to reliability? One approach is reliability allocation. This is where specific reliability goals are allocated to subsystem or component design teams that allow them to work in parallel and independently. There is an art to reliability allocation (please check out the "3 Ways to Do Reliability Allocation" webinar if you want to learn more) that revolves around giving 'harder' goals to 'simple' components, and 'easier' goals to 'complex' components.
Think you might be interested in this in your organization? Well here are some reasons why you should be.
Reason #1 is that you want to motivate good design decisions. Too many reliability strategies focus on a misguided principle of ‘monitoring’ system-level reliability performance during design and nothing else. It might be years after your first design decision that a system prototype gives you your first ‘reliability estimate.’ Too late to do something quickly and cheaply about poor performance. Reliability allocation provides direction from day one.
Reason #2 is that reliability allocation forces you to come up with a system reliability goal. Customers won’t always tell you what their expectations are. And even those that do are only telling you what level of unreliability they find ‘unacceptable.’
Reason #3 is perhaps the most important one. Reliability allocation gives you a reliability margin that eliminates production issues. How? As explained in the "3 Ways to Do Reliability Allocation" webinar, reliability allocation creates aspirational goals for each design team. You don’t know if a part of your system is going to be a ‘reliability star’ or ‘reliability problem child’ at the start of the design lifecycle.
Are you designing a laptop and the keyboard isn’t as reliable as you hoped? Well … because your power supply, screen, battery, and other design teams had aspirational goals, they now have the combined reliability performance to accommodate your problematic keyboard. All without any delays or additional funds needing to be expended.
Reason #4 is that reliability allocation helps you with redundancy. Do you need to have a redundant pump? Two pumps are more expensive, take up more space, involve more maintenance, and so on. Reliability allocation tells you if you need redundant components.
And finally, reason #5 is that allocated reliability goals help you work out if you are on track. Design team leaders often only really find out if their system is reliable when everything comes together. Why? Because they haven’t allocated reliability goals to design teams so that they are able to be assessed independently.
Hope is not a strategy.
So with these 5 awesome reasons for doing reliability allocation, why on earth would you ever consider not doing it? There is at least one reason.
The main purpose of reliability allocation is to provide direction and motivation to the design team from day one. Perhaps you shouldn’t do reliability allocation if there is already a mechanism to motivate people to make ‘good’ reliability decisions. A good example of this occurs in many organizations that rely heavily on failure mode and effects analyses (FMEAs) that inherently come up with a bunch of prioritized ideas to be incorporated into your system configuration from the start. Of course, it helps if your system is not overly complex – but this is where judgment is important!
And of course, FMEAs can be a great tool in organizations that choose to allocate reliability goals.
How does this gel with your experiences? We would love to know. Comments or requests will be greatly appreciated!