If I was to start a company that worked on a world-scale, the worst thing to form is an organic structured organization, in my opinion. A company working globally needs to have a rigid structure so everything can run smoothly and avoid a mess. Organic structures are more for smaller companies, I believe. According to the link given above, the…[Read more]

In my company, I work in a project-based/matrix-based combination of an organization. There are multiple projects going on at a time and each project has it’s team. However, the teams are made up of staff from different departments (R&D, regulatory, marketing, tech leads) who also are part of at least one other project for their respective role.…[Read more]

In my opinion, I think a major mistake would be to assume that one is only looking for extreme and catastrophic risks and therefore overlooking risks that are also important. For example, there are risks due to safety that one may overlook and cause issues in the long run. There are business related risks that can be overlooked because one may be…[Read more]

It is important to distinguish the types of risks you are analyzing. For example, there are risks that impact business, those that impact manufacturing, and the obvious risks with the device itself. A risk may be considered “high” level because it has a great impact on the business, but not necessarily manufacturing. The factors that determine…[Read more]

I agree – There comes a point where the company has done their part by putting warnings on labels and the customer who is using the device is responsible for following those instructions. For that to happen, it is expected that the user is trained to the proper handling and use prior to using it during surgery, for example. As many have said,…[Read more]

Deepthi, yes it is a common practice to keep these inputs and specs in an excel spreadsheet as part of the Design Requirements Matrix (DRM). This document may even be a live document that can only be seen by those on the design team and can be modified accordingly. In my recent experience, the DRM for a specific project has been posted on…[Read more]

As we have learned and many have already mentioned, verification tests come about from the design specifications in the DSD. Each specification can have a test linked to it and will be explored during verification. However, not all specifications have to undergo design verification. Based on my experience, in the earlier stages, the quality…[Read more]

I’ve realized several things about Gantt charts in the industry. The plan laid out by Gantt chart should be followed as close as possible, especially since projects have deadlines to be met. However, one has to consider there will be setbacks and there will always be problems that cause dates to be pushed back or become more flexible. In my…[Read more]

There are major differences between design verification and design validation. For one thing, validation always occurs after verification, and in some case may not be required at all. Verification tests the specifications of the device separately, while the validation stage tests the device as a whole to see if it meets user needs. Each design…[Read more]

When developing an inputs document for a new product it may be a challenge to obtain or come up with the inputs and specifications. As mentioned in the lecture, R&D engineers may help support this by performing development tests or engineering studies. By experimenting, an engineer can come up with specs for mechanical inputs, such as torque,…[Read more]

I agree that there exists an advantage to have the entire design process documented in a DHF versus a snapshot of the design process with the Design Dossier or Tech File. For one thing, we are able to see every aspect of the product from start to finish. It is the proof that the product was designed to be safe, meets user needs and requirements,…[Read more]