First of all you need to think about the reason for any change, also if the change is essential or no?. If the change will add improvement to the project or or improvement for the device ?
To evaluate a change request, you need to find the answer for the following questions:
Is there a work-around, or is this change necessary for the overall success of the project?
Does this change require an increasing the project budget? How much extra or less?
Will this delay the project end date?
Is it routine change with little or no impact on project?
Finally if you have the answer for those questions, you will definitely can approve or reject the change request.

Merzkrashed makes a lot of good points. I think something else we would need to consider is the stockholders/team and customers/venders. Will your team agree with the decisions? Do they agree on the change but not the plan of action? You should also consider the customers and the venders. Will your change get the product out sooner or later? Will it increase or decrease the risk or efficiency of the products interaction with the customer?

I believe it is important to assess the change from a patient impact point of view. Any small design change can have rather large implications to sterility, packaging, or even biocompatibility. These types of changes should be heavily considered and observed from those standpoints and generally, there are SMEs that will assess the change from those standpoints if it is applicable.

I agree with previously made points. Design changes can affect several parts of the product and can create several moving parts that the project manager and team need to be aware of. First I would agree with merzkrashed is you need to evaluate the design change, if it is necessary or if there are other options. Then you'd need to consider what those options are and what they affect, so the schedule, budget, registrations, etc. I agree with f-dot, I think keeping in mind about your vendor or your partner's position is also important, so how is this design change occurring, who is supplying/implementing the change, does the current vendor have the capability/equipment for this change and if not figuring out a new supplier, and what other parts does it affect. Then these changes will need to have validation checks to ensure the change is beneficial before approving and accepting the change. So this is where I would agree with aij5, revalidating for efficacy/accuracy, sterility, packaging/environmental testing, biocompatibility, etc. All of these extra tests need to be considered in the schedule and budget. Documents also must be updated to reflect any of the changes being made for traceability for not only the company itself, but for auditing purposes as well.

I think Changing any part of the project can have a great effect. When you take this discussion you have to take in consideration the effect. that could be budget, the timing of the project, etc. So, you have to calculate the benefits vs risk and is it worth it to do such a change. And is it gonna add to the project, is it gonna help to meet the required target?

I have mentioned some of the points that need to be considered while evaluation of a change request according to me.
1. A request to make a change to the project is received
2. Update the change log
3. Assess the priority of the change request
4. Assess the change
5. Decide the course of action: approve or reject the change request

When every one of the means of a change administration handled, following stage is to assign the undertakings to the correct asset to get the change made. This could be to designers, analyzers, engineers or any other individual who is affected by the work. It's best to clarify the method of reasoning for the change in the meantime rather than simply doling out the tasks. Individuals tend to work all the more successfully on the off chance that they know why they are accomplishing something, so set aside the opportunity to set the new work in setting and clarify the benefits of the change on the development solution overall.

When handling changes it must always be considered that no change is as simple as it seems at first. When correcting a simple aspect of a bills of materials it could turn in to a design change and could affect other linked projects. Very rarely is a project a linear structure but or of a branching structure. When one aspect of the branch is changed it could result in changing the rest of the branches as well. This could mean working with other teams or even at times working with other locations. Changes should never occur just to assign work but rather out of a necessity to the good of the projects.

For a change request, it is also very important to look at the other documents that would be affects such as the SOP's. For instance, if the name of the product is being changed, you need to have a change order for every single document that has the name of the previous document. You must get the change request approved, get it released and train all the departments in need so that there is no miscommunication.

The first step is identifying the type of change being requested. It can be to the BOM, Labeling, paperwork, testing procedures, storing procedures, sterilization procedures, disposing procedure, packaging, etc. Depending on the type of change requested the factors to consider will obviously change. some of the changes may come from revised standards, in which case its not a matter of whether to change or not but how to best incorporate the new requirements into the project at hand(if possible or the project may be shut down).
In terms of changes that can affect the patient end, it will never get to that point because any major changes to the approved device need to be reported to the FDA and only after they say that the changes are acceptable can you go through with it. You may even have to start a new project and have a "new" product with a 510k comparing it to your old product if the changes are that huge ie. adding collagen to the tissue part of a bandage would make it a new product even though they are both bandages.
With how severe the repercussions of releasing a faulty product, shut down of all distribution and potential recall within 24 or 48 hours of discovery, any changes that could potentially affect the products reliability will either directly be shot down or go through serious testing.
Depending on the actual content of the change and how that change is related to the project you are working on, the change may be rejected or accepted but assigned as a task to someone outside of the project you are working on as it is outside the scope of the project.

Medical device manufacturers make changes to the existing products most of the time but changing in the project will have some effects. The things that should be looked for while evaluating a change request is that is there a change necessary for the overall success of the project. The change required could be small or big if the change is big then it will affect the whole project output. Will the change add or alter the product requirements. Will the change delay the project end date so enacting this change will now make more sense than delaying it will the delay end up costing the project more money in the end. Will the change in the project would produce better device resulting in better performance and end user is satisfied using this device.

One of the most important things to take into account when dealing with a change in a project is what importance of the change is. Is it something that MUST happen (FDA regulation, critical business reason,etc.) or can it be done as outlined in the scope of another project? Like mentioned in some other threads, scope creep can be a very real problem in projects and cause immense delays should a PM decide to implement every little change that comes their way (increasing the amount of work done out of scope). Therefore, the importance and urgency of a change request must be evaluated in a way that balances those things that MUST happen with the timeline and initial scope of the project.

Change in the project can give benefits or else may give major risk in the project. If the project is completed and in the last stage certain changes is made, firstly the due date of the project will gets affected and gets delayed. Gradually, the Budget also gets affected.

There are many factors that must be considered when evaluating a project change request. One such factor would be if the change would alter the business requirements. In other words, does the project try to produce results that the business or company requires? In addition, if the project change would require additional funding that cannot be satisfied, then this would be a determining factor as to whether the project change can be approved or not because if sufficient funds cannot be allocated, then the change is simply not feasible. Does the change the postpone the project end date? Have all of the stakeholders in this project been notified of this and have they been considered? Are they willing to approve the change request? These are additional questions that must be taken into account because it's important to know who will be impacted and how. How much money will each person lose? One more important factor is if this change request is the only solution to solve the problem at hand. Are you sure that there isn't a work-around for the project that could've solved the issue? In order to ensure that you make the right decision, these are some of the questions that one must ask while evaluating the request.

Uncontrolled change is one of the biggest foes of a project manager. That's why a solid change management process can be a project manager's best friend. Putting this kind of process in place enables you to deliver what the customer has requested, in the timeline required, and within the agreed-upon budget. Without change control, the project scope becomes a moving target and you are at risk of missing one or more of your project success factors. The ability to manage and control change, particularly that of project scope, is a key to reaching goals and a typical performance indicator for a project manager. Project change is inevitable and you must be prepared to deal with it when — not if — it happens. One challenge for project managers is balancing the need to control project change while avoiding undue bureaucracy. The question is: Where is the tipping point? Because every project is unique, the point at which change control stops adding value and turns into red tape will vary from project to project. Some of your stakeholders, or even your project team members, may feel that putting change control in place is your way of avoiding the dreaded scope creep, and that you are unwilling to be flexible and do what is best for your customer and the business. It's important to dispel this perception. Let them know that what you are doing is exactly the opposite: you are implementing an efficient process for consistently evaluating requested changes. If making the alteration is deemed a good idea, then you'll have processes in place to respond when needed. To help you respond quickly, a project change management plan describes what happens when deviations occur. It's not intended to prevent change; rather, its purpose is to outline a process that makes clear how change will be communicated, how decisions will be made, and how the project will adapt accordingly.