I have never worked for a medical device development company however, this topic is intuitive. This can be applied to any company and not just medical devices. Google and Amazon have become companies that I am sure to have gone way out of the scope they originally intended in their project charter. You Amazon being a middleman distributor, to becoming a monopoly on selling goods but, now services. In terms of medical devices, one way to prevent scope creep is to have meetings i.e(status meetings) for an overview of the project i.e(status, timelines, scope) and progress of the project. To also have a clear line of communication every week to know if what being done is in-line with the scope of the project as well.

I have not worked for a medical device development company either. When it comes to scope creep I think the ways it can occur are very different and there are countless ways where it can't be prevented. In the example that was mentioned in the lecture, when there isn't enough money to have your device do as much as you want, could be prevented during the planning phase. Costs should be researched to where you have a pretty good estimation of what your device will do. Of course there will be some rare cases where those costs won't be accurately known until the time you need them.
There will also be scope creep that can't be prevented in cases where new regulations and new customer demands come up. You can do all the proper research for the scope you have but if there are things out of your control that come up down the line you will need to adapt and adjust.

I have not worked for a medical device company . But i worked for a drug company for 2 years. Scope creep can occur, in my case we had to start all over again. We used to make Morphine control drug. It was a new drug that we started. We did our verification and validation and submitted to FDA. Planning and execution phase all went well. And FDA approved our submission. Production line started producing in buck. When we started to sell that product. We were not able sell the drug as expected. It was because the drug was bitter due to the control substance. We arranged a meeting how to resolved this issue. we came with a coating material that will prevent this bitter taste. It took us almost two years to resolve this issue and bring it back on production.

A good way to prevent scope creep is to gather inputs from the customer early on in the project and lock down the scope as early as possible. I agree with cdj24 that in some cases scope creep can be unavoidable, especially considering that the medical device market is very dynamic and the scope may have to be adjusted in order for the product that you are developing to be competitive in the market once it is released. In these instances, I think it is very important that the company has a very thorough scope management plan where they can assess the proposed changes in scope, consider the timeline adjustments and business impacts, and make an informed decision whether or not it makes sense to adjust the scope. I think often the scope is adjusted hastily without putting much thought into the actual impact to the project.

Scope creep mainly occurs when the interference comes from upper management. They see that a product is capable of A and B and then they ask if C is possible and push for it.
I think that a better way of preventing scope creep is possibly to turn the new ideas into their own projects, instead of just adding them onto the first ones. However, one large drawback to that is that it would cost much more money.
Although it's impossible to completely get rid of scope creep (because ideas come when they come), it can be lessened by realizing that communication must be free and immediate from the beginning of the project.

There are some methods to avoid scope creep. One method is to understand the clients or customers vision of the project. What does the client require? As we learned we need to clarify the goals and objectives in the initial planning phase. The team should set a high level schedule and a list of deliverables for each task. These should be broken down into variety of task. If its complex, the harder it will be to avoid scope creep. I also feel like the team should identify any milestones within the project. The team should keep track and see if there is any changes that need to be made.

So for this particular example to plan on selling a medical device in US and then decide in executing phase to sell in Japan, this would be a big scope creep in my opinion. I agree with the comments above, but I also think a major concern would be patent protection. When you want to commercialize a medical device you file a provisional patent then you have a year to make any adjustments including adding data to support your device from a clinical trial, other drawings, etc. After a year your provisional patent will "convert" to a PCT (Patent Cooperation Treaty) application which is also known as the worldwide application. Once you convert your patent to a PCT application then you have up to 2 and half years to decide which countries to file in; U.S., EU, Japan, etc. So you need to make sure if you want to be able to exclude others from selling your product in a country, that you have intellectual property protection and this again should be determined earlier on than the executing phase. So you should now when you covert to PCT which countries you want to file on (which countries you plan to sell your product). This stage of patent protection can become very costly, its a lot more expensive to file in other countries like Japan, China, EU, Australia etc than just a U.S. application. Your patent portfolio could end up costing around $100k if you file in multiple countries in prosecution because you need legal counsel to translate the applications into the other languages and prosecution is a lot of back and forth with countries and counsel on office actions.

Overall its important not only to have a development and commercialization timeline, but in parallel to have a IP timeline and make sure that those are working in parallel.

One way to prevent scope creep is to have regularly scheduled check-ins with all team members to make sure that they are all working on things that are in-scope for the project. This could be a quick web meeting, over the phone, or in person but it would help ensure that the team is staying within the scope of the project and things that are out of scope are being avoided.

One thing that we need to remember is that successful project execution is not always the end goal, from a corporations standpoint, the end goal is the best way to secure financial revenue and fulfill the commitments made to make that money. In some of the cases listed above the project can be scrapped altogether and a new more encompassing scope project can begin. In this case the original data collected and analyzed is not lost and depending on what phase of the project you are on, you may be able to continue with the old project task but simply adding in more tasks to supplement the new requirements. In this case you will "finish" the original project on time and be part way through the "second project" that was mushed together with the original.
Take the example above about the product being in the US and Japan, if you had already entered the execution phase of the project then continue with the execution for the US since there is no logical way upper-management will delay the release of a product in one country so they can release it in two simultaneously. The rate critical step in this case will be Japan.
Scope creep isn't always a bad thing so long as your metric isn't the number of perfectly executed under budget ahead of schedule projects you have completed (that is important though right :3). The one to be cautious about is tunnel visioning on the new components of the scope and overlooking/diverting your attention from the original components of the project assuming that that is already taken care of.

In my opinion a good way to avoid scope creep is to have a highly efficient planing stage prior to the submission of a final scope statement. Make the most out of each meeting and get all ideas on the table, try to think ahead about what is a feasible outcome for your product and really try to hone in on the aspects that are to be focused on and what is to be excluded. Once the scope statement is developed and well thought out, build a work breakdown structure and dictionary that sets boundaries for each persons duties. It might also be a good idea to have the scope written out on a white board in the meeting room for all future meetings so that it is always in the back of your team's mind when they are navigating through future stages. As a project manager do not be afraid to site the scope statement as a reason for why a certain team member's idea is being shot down, "Hey that's a great idea John, but how can we keep that idea within the lines of our scope?" it is better that they understand that this is the reason why it can't be done so they don't get discouraged from contributing in the future.

The most effective way of addressing scope creep is to determine its origin/source in a way that not only resolves its conflicts, but also prevents them from resurfacing. One main cause of scope creep is a lack of communication between executives and project teams. Executives hire project teams to essentially do the work for them, however if the executives put too much faith into a project team, then it is likely that the project may deviate from what was initially intended. This can be addressed by having a project's sponsors elaborate their desired details for design in a technically-written document while also maintaining consistent communication with the project team throughout its design phases. The overall cause of scope creep seems to be a lack of planning prior to initiating a design process. Starting a project early may seem as though costs are being cut since a shorter project duration correlates to exerting less time and money, but it may likely come at a greater expense down the road, possibly even during the project's final phases.

The design process for medical devices can take several years for a project team to accomplish, therefore every member on the team cannot be expected to stay committed to a project. Is developing a protocol that accounts for losses in personnel considered to be a way that prevents scope creep, or is that another general form of risk management? What if a client abruptly alters their expectations of a product, is that considered scope creep and what can be done to reach a solution in that event?

Reference:
Larson, R. & Larson, E. (2009). Top five causes of scope creep ... and what to do about them. Paper presented at PMI® Global Congress 2009—North America, Orlando, FL. Newtown Square, PA: Project Management Institute.

I can see how this could be a common problem in industry, especially when Project Managers get requests from stakeholders not directly involved in planning or executing the project. One day you are on track, have a budget established, and have a product on its way towards being released. Then upper management all of a sudden makes a request which they do not realize how much work it would actually entail. Releasing something internationally sounds like it could be its own project entirely, not just some add-on. There are biological differences, regulatory differences, and supply chain differences among other things when attempting to supply your product to a different country. My company produces a certain product line for Japan which has completely different dimensions than the US product line simply due to the fact that Japanese people have different body structures. Also in the European Union they have different medical device regulations than the FDA in America. Best option for something like this would be for the Project Manager to attempt to say "no" to this type of scope change, and recommend an entirely different project for this.

Scope creep can often be a problem faced in the medical device industry. How much noise it creates can differ however depending on who is being affected by the drift. In one of my experiences, part of my team was involved in discontinuing product codes from being available to be purchased by customers since they were obsolete products. Requestors would come to us with a list of product codes that needed to be discontinued and the team would work on that process which was one that was fairly extensive and time consuming. Many times, because of the time it would take, would then come back to the team with more codes that needed to be discontinued, tacking it on (scope drift) to the original ones. This would cause immense delays in fulfilling requests as the list just kept on growing and growing (or in some worse cases, codes were discontinued and then requestors came and said not to discontinue). The delays became such a nuisance that our team decided to strictly deal with the initial scope of the request, and that any additions to the scope would need to be a new, separate request that would be dealt with after.

So in context of this example, one of the most effective ways to prevent scope drift is to be firm on working on the initial scope of the project.

I would say the longer that the scope remains unfinalized, the higher the chances of there being scope creep. The needs of the customer should be specified earlier on, and communication between both parties should express understanding that the design and needs of the customer are being properly understood, as well as the intentions of the product. It's key to know what sort of applications the device might be used for in order to get a better design. The scope should be solidified as early in the planning stage as possible. I'm not sure if contracts are made, but if possible then the contract should outline an acceptable time window during which the scope can be changed if needed. If the scope changes too late into the project there will be major setbacks and possible losses. Whereas if a contract lays out the rules then it can save a lot of trouble later on in the project timeline.