How Not to do FDSC
Abstract
Chris and Adam discuss FDSC. This may only mean something to you if you have experience in ‘military’ equipment. It stands for Failure Definition and Scoring Criteria. And it is used to remove subjectivity in classifying what sort of failure it is. Unless the military customer decides to change these during development. And this causes issues for all. If you want to hear more about what happens when you ‘shift the goal posts’ during development, then listen to this podcast!
Key Points
Join Chris and Adam as they discuss Failure Definition and Scoring Criteria – or FDSC. This is a matrix of what military customers typically use to define what different types of failures ‘mean.’ That is, which failures are ‘critical,’ which failures are ‘safety’ and so on. But there is a problem with how military customers use the FDSC. They often believe that they have the ‘right’ to change the FDSC throughout the development of a new vehicle or weapon system. But … there are problems with this.
Some of these issues are discussed below:
- The customer’s job is to make it easy for the manufacturer to design a ‘good’ vehicle or weapon system. If you change your mind years after the design effort commences, you can’t then expect those designers to somehow guess that you were going to do this. So you can’t
- As Adam says it, the ‘tar and feather’ rule prevails. That is, if you change the requirements throughout the design or development process, you need to be accountable for a consequence. And pay the bill for changing a design.
- Changing anything – including failures – needs to be a risk and resource based decision. You might actually save the day by changing the use case or requirements. But this needs to take into consideration the cost and risk of doing so. You should expect that you need to pay a premium for doing this.
- Adversarial relationships tend to accompany this behavior. Customers, manufacturers and suppliers don’t see themselves as partners in scenarios where requirements change without any understanding of the cost that should be paid.
- Subjective definitions from the start. This is fraught with danger.
- Not trying to ‘get’ the user. If your product is very reliable, but it requires the user to do things that they simply will not do, then the product needs to change.
Enjoy an episode of Speaking of Reliability. Where you can join friends as they discuss reliability topics. Join us as we discuss topics ranging from design for reliability techniques, to field data analysis approaches.
- Social:
- Link:
- Embed:
Show Notes
Leave a Reply