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.
