|
Over the years, I have noticed that there is often a problem with the timing of safety efforts. Design engineers generally don't want the "help" of the safety team while they're still working out conceptual designs and proof-of-concept testing. Understandably, they want to be left alone to concentrate on the "real" problems of making the darned thing work; they don't want to be interrupted by outside considerations. In some ways, that makes sense. I'm sure that if I were in their boots, I would have the same desire. However, what happens then is that the idea finally comes out of the "skunk works" as a full-blown system, and everyone is in a huge rush to push it to market. Once that rush is on, there is very little time or desire to implement changes unless they're clearly going to turn into very big problems. Many of the "little" problems (those that probably won't result in death on a regular basis) are simply accepted by management rather than allowed to slip the shipping schedule.
I have been wondering if this is a problem of insufficient resources, or if it's a natural part of the design and development process. It does seem that we're often without the correct amount of resources because of the cyclical nature of most businesses. Nobody wants to keep trained safety engineers on the payroll if they aren't needed, and it takes too long to bring new ones up to speed once a new project gets underway. Even when there is what would appear to be adequate staffing, we're often not given sufficient calendar time to do the necessary research to adequately understand the nature of the problems presented by the system.
There always seem to be questions concerning how much system safety effort is enough and when that effort should be expended. I haven't found a clear-cut way to answer these questions in advance of getting embroiled in the project. Once we're doing the work, it usually becomes evident if we have too little, or enough, safety engineering support. Of course, by then it's usually too late to increase the staffing because of cost and schedule constraints. Some people have advocated estimating a percentage of the overall engineering budget. This makes some sense if the project is similar to another one where experience has been gained. However, if the project is a new idea or concept, then it's very difficult to accurately judge the effort that will be required, or when that effort will be needed.
Budgeting questions can be linked to issues like the project's risk, under the assumption that more safety effort is required for higher-risk (in the safety sense) projects. Another variable is undoubtedly the complexity of the system under development. The more complex it is, the harder it is to understand, and the more people it will require. The issue of complexity is often directly reflected in the size of the design engineering staff. The more complex the project, the more people will be required to do the work. Yet another variable has to do with the willingness of the design engineering staff to provide support and assistance to the safety engineers. The less supportive the rest of the project team is to the safety effort, the harder that effort becomes.
One approach is to budget using the best available guess, with a rather large contingency feature that allows the effort to change sizes to meet the actual demands of the program. This approach might work if there's enough calendar time to adjust the staffing as needed. However, system safety engineering requires an in-depth knowledge of the system, which takes time to learn. Therefore, even if the budget could be adjusted on-the-fly to meet the needs of the program, effective staffing usually cannot. This problem is exacerbated for projects that have a short development time because there may not be enough calendar time to allow an effective increase in staffing in the middle of the program.
It appears that there are only a few avenues available to solve the problem of getting adequate safety effort in a timely manner. One approach would be to staff the safety department early in the program with enough qualified people to handle the anticipated peak effort periods. This means that through much of the program, an "excess" staffing situation will occur. (I really can't imagine the luxury of working on a program with excess staffing.) This would result in higher costs than would be realized if the effort could be adjusted to fit the workload as needed. Because of this additional cost, it is rarely (if ever) the solution of choice. In fact, it appears that the normal approach to staffing to meet the variable need is to staff a little less than will be needed during the slow times. The assumption seems to be that the safety engineers will be able to stretch their efforts a little bit all of the time, and a lot during the peak periods. Of course, that cannot be accomplished, and the result is that the safety effort is usually seriously under-funded. My experience has been that we're expected to stretch beyond our limits all of the time, which becomes frustrating and exhausting after a while.
I wonder if it might not be better to redefine the role of the safety engineer to be more of a facilitator and technical resource, rather than the person who is responsible for making sure that adequate safety is incorporated into the system design. In actuality, the design engineers are responsible for the safety of the system. They are the ones who have the responsibility and authority to make changes to the design. Maybe the design engineers should be the ones that perform the hazard analyses, specify safety requirements (including those that are derived from the results of the hazard analyses) and follow applicable standards. Maybe safety's job is to train them on how to do the safety work, provide a resource to assist with the safety effort, and evaluate the engineer's safety efforts to determine whether they're complete and appropriate as part of the checks-and-balance system to ensure safety of the system.
This approach of clarifying that the safety effort is the responsibility of the design team will enhance the probability of necessary features being designed in from the beginning. Designers will be held responsible for identifying the problems and getting them fixed. As it is, they seem to feel that it's acceptable to get away with as much as possible because it's not their responsibility to identify and implement safety features; it's the safety department's responsibility to do so.
The approach of implementing system safety into the program will result in an increase in the design engineering effort because the design team will be doing some of the work that's currently being done by the safety engineers. However, it will probably result in a lowering of the overall program effort because safety problems will be more easily identified early. In this way, they can be fixed before they're incorporated into the design and need to be changed at a later, much more expensive time. The effort required for safety will not be increased; it will just be shifted.
Distributing the safety engineering effort into the design effort will require some additional upfront training of the engineers about what is needed and how it can be done. Since methods and techniques for identifying and controlling safety issues are seldom included in the formal training of engineers, this will be new material for most of them. Once the design team understands that they're being held responsible for safety (which has always been the case – they just tend to ignore it because management allows them to do that), they should be in a position to make significant positive impacts on the overall safety of the system. Of course, it will be necessary for management to increase the engineering budget to allow for the time and effort required to do this job, with the additional tasks.
In many cases, safety is considered to be a necessary evil, rather than a critical element of the design. However, it has always seemed to me that we safety engineers should be acting as a resource to support the engineering effort, rather than as policemen that appear to be obstructionists. I am getting tired of being a detective, trying to identify problems that are being glossed over, or hidden, by the designers. We should be working together in the process of developing an effective, safe system.
|
