What you are describing sounds to me a bit like scope creep which is a big problem projects can run into. You can feel like you are just trying to improve the project but you dont want the project to become more than your team can handle. Going outside of the customer needs may be acceptable unless you then start to conflict with those needs.
What you are describing sounds to me a bit like scope creep which is a big problem projects can run into. You can feel like you are just trying to improve the project but you dont want the project to become more than your team can handle. Going outside of the customer needs may be acceptable unless you then start to conflict with those needs.
I'm certain that projects start out with more inputs based on specifications and customer needs than what is required, particularly due to companies wanting their product to be safe and the best in the market. I believe that over time the inputs may be decreased primarily due to the time and financial costs to the company to run the verification and validation tests. This is why during the initial design input meeting it is important to have a member from each department so only inputs that are needed and are within scope of the project are included.
I think over-validation can definitely occur in the device development process. A prime example would be when I was working on my capstone project, we were discussing the development of an application to accompany our device. One of our team members wanted to put many different conditions onto the application design, and over that would have made for a rather solid application. The issue was that none of us working on the project had had nay experience in app development and the idea our teammate was proposing, while being a good one for those hat professionally develop applications, would have been too difficult for novices like us to develop. As such, I think over-validation is most prominent when you don't account for your resources and experience at hand. Additionally, when occurring within a company, over-validating a project for the sake of the client will put financial strain on the company in charge of development, and that is not plausible when the final product, while satisfying the customer has a rather large budget.
Totally agree on how industry deadlines can limit the number of inputs! From my own experience in school projects, we had to prioritize essential features to keep on schedule. In a real industry setting, I imagine it’s even more pressing, with deadlines and budget constraints making it tough to go beyond the basics. Curious to hear if others have seen the same in their jobs!
It is possible that teams log additional design inputs beyond the requirements for different reasons, including predictive measures, future risk prevention, or preparing for later iterations of the product. The goal is typically to meet the essential inputs for verification and validation, but adding extras can be useful in light of changing user needs or regulatory updates. When it comes to advancing beyond initial user needs, this goal must be carefully balanced with scope creep. If the team has strong reason to believe that adding a feature or improvement would increase the product's market appeal or effectiveness, then it may be reasonable to expand beyond the customer needs. However, in regulated industries, any significant deviation from defined user needs typically requires documented justifications, additional risk assessments, and possibly even revalidation to ensure continued compliance. Thinking ahead and accounting for these new inputs can set a product apart from anything else on the market, but it is important to keep up with compliance and user requirements.
I find that over-validation does occur in many instances, but there should be a balance of wanting to do better and over-validation. Each company should have a baseline of what the company is expected to do, but I also believe there should be a maximum of overachieving and a minimum of underachieving. Underachieving makes clients become bored or sees products as outdated. Overachieving makes customers overwhelmed and potentially worried about a lower quality product. There is always a 'sweet-spot' of what new version of the product that the customer will be drawn to. It is kind of like the new phones that come out every year, some people think getting a new phone every year is worth it, while some don't and think it is too frequent.
While it is certainly possible to overdue it, I think logging more inputs then you think you will need is a smarter way to go then just logging the bare minimum. If failures start to occur in the device and none of the minimum required inputs you logged can be found to be the cause, having extra sources of information can help find the cause of failure and help to avoid long redesigns.
I would think of it as a multifunctional device. Usually, you would not expect a vacuum robot that is small and can also mop the floor to be as good in vaccuming the floor like a simple vacuum cleaner. Same, thing here: i think moderate amount of inputs is needed to focus on the main desired functions instead of coming up with too much inputs to try to cover everything. Miscellaneous inputs can digress the plan for device development, incur extra costs to validate the functions that is originally not the primary target of the device.
In my opinion I do believe that over-validation can happen easily as companies want to make sure their product is proper. I do though feel like teams want to secure the goal with as little work as possible in the end, kind of like the idea 'less work; more pay' can be very enticing to workers. I also do believe that companies can advance past the user's needs to deliver a better product as they can beat competitors if they are trying for the lesser of the updated version. It could be quite profitable.
I don’t think that there is ever a time when a team decides to log more inputs for predictive measures. If they did that, they would have to log more outputs. If the team has more ideas of possible risks, they would most likely address those while testing. I also think that a project can advance past user needs, but that is where the balance of verification and validation comes in. As long as the project addresses the intended user needs, there is no reason to overcomplicate the project.
I was thinking about this too! From what Dr. Simon explained, design verification is all about making sure our design outputs match the design inputs, and design validation checks that those inputs truly support the user's needs. I do think teams sometimes add more inputs than necessary, especially if they anticipate future requirements or want to improve usability. But from what I understand, if a project goes too far beyond user needs, it might fail validation because it’s no longer directly tied to what users actually asked for. So I think it’s okay to innovate ahead, as long as those added features are documented and still clearly connected to user needs and safety.
Ok so I think this could go both ways. I think over validation can be strategically beneficial at times as a proactive measure in case of any future regulations that need to be addressed. however, the other side of it comes from the risks, where overdesigning the product might add unnecessary designs that won't improve the outcome of success. It's definitely possible for a project to advance user needs but it needs to be strategic and intentional. advancing beyond user needs might mean that validation is no longer applicable since it can't confirm the product's intended purpose. So in short, I think over validation can be both a good and bad thing, whereas advancing beyond user needs might seem a little too risky.
As a kind of predictive planning, engineering teams frequently decide to record extra inputs in order to foresee future design modifications, regulatory comments, or new user requirements. This proactive approach can facilitate verification and validation, but if too many non-essential inputs are added, it runs the risk of overcomplicating the design history file (DHF). Too many inputs might lead to confusion or needless testing, therefore I believe it's critical to strike a balance between thoroughness and concentration. It's also intriguing that you brought up exceeding user requirements. Regulatory agencies like the FDA stress that design validation must show the product satisfies intended use and user needs, not necessarily that it surpasses them, even though innovation is frequently encouraged. Going beyond demands that have been verified could lead to concerns regarding performance characteristics or untested claims. Do you believe that trying to go above and beyond what users require could result in unforeseen risks like usability problems or noncompliance with the initial design plan? Or do you think that innovation in a cutthroat medical device industry requires breaching such boundaries?
