While working at HP as a failure analysis engineer, I was asked to join a new R&D project that needed a reliability engineer. My background was in Physics with little experience in reliability other than knowing that failures occur because reliability goals were not met. At HP, reliability engineers were integrated on each HP project by rotating many disciplines of engineering from various parts of the organization.
After a crash course in reliability principles and talking with many other reliability engineers at the HP site, I discovered that there were basic principles that formed the reliability engineer’s toolbox. Having these in my hip pocket, I went into my first R&D project meeting to see how I could contribute. The project engineers and management stated in no uncertain terms that the equipment being developed was still in deep research stages and they did not even know if it would work; much less worry about for how long (Otherwise, go away until we need you).
Thus my first task was to answer the question; ‘What reliability actions can be done in the early research stages of a project without any designs, parts or information about the project’? After many false starts, I discovered some early reliability-related actions that would to contribute to the project’s success and feed into the later stages when typical reliability tools were applied. This blog discusses these early reliability actions. They can be found in more detail in my book Reliability Engineering Insights along with all reliability tools that are useful during the entire project.
The two basic actions a reliability engineer can take early in a project are:
- Construct and implement a Functional Architecture of the system/sub-system, and
- Gain agreement with the project team on what reliability areas would be most beneficial for their system.
1. Functional Architecture
The Functional Architecture provides the common language between various sub-systems within the project by focusing on the function of each sub-system; not the physical structure. The functions would usually not change even though the hardware to achieve that function may evolve over time. This approach can help establish linkages within the system that allows each project team member to understand the dependencies between sub-systems. Steps to establish this Functional Architecture are critical for the reliability engineer to jump into the project with little background (more details can be found in my book ‘Reliability Engineering Insights – pages 22-25). These steps are:
- Talk with each project member about their specific responsibility and construct a map of low level functions that engineer is responsible for, showing all inputs and outputs.
- Verify with each project member that the functional map constructed describes the functions (not the hardware) within their sub-system and has all the linkages (inputs and outputs) expected.
- Form a high level functional diagram integrating all inputs from each project member (showing only the linkages between the main functions).
- Review with the project team the integrated high level functional diagram formed and go through the linkages together. Correct any errors and discuss any new linkages or assumptions uncovered between project sections. This step usually uncovers significant areas that the team did not realize were important.
- Gain agreement as to which functions are critical by voting and discussion. This helps the manager understand the dependencies and what is the critical path for project success from each team member’s point of view.
- Use the final Functional Architecture during project reviews to show the progress in reducing risk on all critical area. This step is also very useful in gaining visibility for the reliability engineer and helps when engineer job performance reviews are done.
2. Reliability Areas Most Beneficial on a Project
In my book ‘Reliability Engineering Insights’, I show all the major reliability core competencies/tools/skills that can be used on a project (throughout the development and implementations phases.) These are organized into a Reliability Foundation using three basic categories:
- Reliability Management,
- Design For Reliability, and
- Reliability Assessment (see pages 20-22).
Each core competency is described in detail in the book’s appendix with many references to well known authors in that discipline. When to use each tool is also shown on a timeline (page 22).
Once these two basic actions are completed, the reliability engineer should be integrated into the project team and have visibility at all levels of the organization. These two actions also establish many tasks for the reliability engineer to focus upon while the design is being developed and optimized.