I agree with other stating that it the scope should be clarified in the beginning of the project but also throughout the project because as stated by ks629 someone might want to sell the product oversea. The company needs enough time for change preferable before the product is ready to be released in the origin country because if the decision to change at the end, the company will might have to start from scratch due to the other country regulation and other policy. They need meetings because the change will elongate the project making both sides lose money, if they new from the start or during the project it wouldn't cost them as much if they decide change at the end. I never worked in a medical industry but I think if there is more communication there wouldn't be last minutes changes. I also think they should have consider in expanding to another country just in case because they would have been prepared if there is going to be a change, they would have known the regulation and other policy before the change in decision.
In my opinion, scope creep can be prevented by taking the time and initiative to form a well-defined and researched scope with increased input from project members during the initiation of the project. This can mitigate delays later in the project because it allows for the creation of a work breakdown structure and schedule that considers the tasks required of that defined scope. Additionally, potential changes to the scope later in the project can be managed by requiring approval by management as well as a justification to the added benefit it provides to the project. Personally, I have witnessed scope creep while working as a researcher at a lab on campus to develop a system to measure gait using IMU sensors. From my experience, the addition of new requirements to the project resulted in the occurrence of unexpected consequences that delayed the project. For instance, the added requirement to use a different microcontroller to increase the sampling rate resulted in one of the previously selected electrical components not being compatible with the new microcontroller.
As many of my classmates have mentioned, to avoid scope creep is to set a very particular/ specific objective that narrows down the scope of the task. I have also noticed that setting tight schedules with set deliverables can allow the project to run as intended and avoid creation of tasks unrelated to the project. In my workplace, I have seen a project set with a scope to address an issue end up eventually addressing a global issue that came to be very overwhelming for the owners of the project. It is very important for project managers, especially when working in a global company, to set a scope and “lock” in the scope so that it does not become a project that addresses a larger issue. When it leads to such, the project becomes unmanageable for a smaller team to execute, and resulting in a failed project, costing a company their time and money.
Scope creep is a problem because it makes can delay a project by making the scope larger than what was originally in the project plan. To prevent this, there would need to be a system for making changes to the project scope called Scope Change Control and the project manager would need to make sure that the project team keeps their efforts within scope. An example of undesired scope creep is when a project team member thinks a new technology could improve a product already in development. Even though this effort has good intentions, implementing this new technology could require that the project return to the planning phase. This would put the project on hold and stall it indefinitely until more research was done.
I believe that creating a well-defined, specified scope will help prevent scope creep. Although the project scope should not be too “narrow”, it is important to limit how expansive a project can be. More than this, by taking plenty of input from the project team in the beginning stages of a project, a scope that is both detailed and manageable can be created. This can help to prevent scope creep, as every aspect of the project is based on this initial, well-defined scope. However, there will always be cases in which scope creep is not preventable, especially if higher management wants to add onto a current project. This happened quite frequently in a research lab I was involved with. I would start a project with a clear objective, and then my advisor would ask me to adjust the project or attempt to add more features to the project I was working on. Obviously, within a research lab, these changes in the scope could be handled with minimal effect on schedule and cost, but I am sure that within industry, small changes in the scope could have major impacts on the overall project. It would be great to hear of examples from industry if anyone would like to share.
Scope creep can occur due to the indications a system encompasses. If a system is originally chartered for adult patients, but pediatric indications are a must have later on, then the scope increases due to the new regulations or product specific considerations must be made. Another situation I've seen occur is having a project that spans a few product lines that includes some, but not all the instruments from each system. One set of instruments was clearly out of scope during the planning phase, but was re-added back in due to the saleability of the system with the added scope. As long as the project manager is able to understand which path each added item can follow (or have a justification for the addition of the item without too much extra human capital needed to include the items), then scope creep doesn't hinder the project too much. It does stress the team when you move further out of the discovery phase, so its always best to make sure one can easily adapt when adopting an item originally out of scope.
Scope creep is what happens when changes are made to the scope of a project without any control. Naturally, changes occur to projects always. It is that very rare project that ends up delivering exactly what was asked for on the first day. However, without there being some control over the changes, a project manager has small chance of keeping on top of the work and managing the project effectively.Generally, scope creep is when new requirements are added after the project has started. Often these changes are not properly reviewed. The project team is expected to deliver them with the same resources and in the same time as the original scope. On the other hand, one could end up with a project with lots of approved, considered changes, that never ends because every time one thinks that he or she may have finished a new requirement arrives in the inbox and then have to make more changes. Some better ways to prevent the scope creeps would be to document the processes, setup the change control processes, setup a clear project schedule and verify the project with the stakeholders.
In every industry or company where a project is carried out, there is always a probability of a scope creep. This can occur when the scope of a project is not properly defined, documented, or controlled. It is generally considered harmful. It can affect any fixed scope project which leads to wasting money, decreasing satisfaction, and causing the expected project value to not be met. It is a very common thing, as it can happen both intentionally and unintentionally, stemming from any number of the people involved in a project either by the project team members, project managers or even the project sponsors or management themselves.
Change on projects is inevitable, so the possibility for scope creep is also inevitable. That does not mean it cannot be avoided. The main causes of Scope creep are: Ambiguous Scope Definition, Scope and Requirements Not Managed, Inconsistent Process for Collecting Product Requirements, Lack of Sponsorship and Stakeholder Involvement, Project Length. But when there is a set and strict standard, we can avoid the above by following these steps: Define the scope, Log the changes, Re-baseline, request more funding and/or resources, watch for signs, Set Priorities, Avoid the traps
It is useful to look at your project and identify who could be causing scope creep. This can help you to identify it early and determine your approach to solving the issue.
We all need to be careful about dealing with increasing or changing scope to avoid nasty surprises.
Reference: PMBOK GUIDE
OK I’m just gonna flat out and say it. If you don’t have a project scope statement In place from the beginning not only will scope creep sit in, it should be an expectation. Had a manager once set up a timeline that was completely unrealistic and expect the project to come out exactly the way he planned it. Then there’s conversations that are being had outside of the team that are in direct conflict with the task at hand which makes the project even more difficult to complete. I had a manager working multiple projects at the same time with the same team members over a span of 48 hours and never thought to consider when the workers were going to sleep. I was a lot younger and could go on one hour sleep back then but in no way shape or form can I do that now. Scope creep had definitely set in! Management never communicated that was the plan in the first place, I don’t believe anybody on the team would’ve agreed to that. Let’s just say that company is no longer in business.
In the lecture, Professor Simon mentions scope creep. Scope creep is when there is project work being done or considered that is outside the original agreed upon scope of the project. An example might be that the original scope was to sell a Medical Device in the US. Then someone comes back and wants the product to also be available in Japan. This requires addtional work from product development (additional testing), regulatory, supply chain and more. This extra work can end up delaying the original goal of releasing a product in the US. I have actually seen this very similar example several times in my current position. What are some ways to prevent scope creep? Do you have any examples of scope creep in your work?
I think one plausible way to prevent scope creep is to have a period of time, which would include an initial meeting and subsequent follow-up meetings, to discuss and consider all of the aspects that might be desired. Essentially, it is brainstorming. Focusing on the ultimate goal would also be helpful. Doing this will encourage those involved to be very decisive about what they really want to see in the project. I do not have a typical example of scope creep because my work is as a classroom teacher, but one thing does come to mind. I had my lesson plans complete for the week after spring break. The week before spring break I was informed that I would have to miss class after spring break. This might not seem like a big deal, but it was because my students were going to engage in a lab that would last about four days. They would not be able to do the lab alone, so I had to reschedule the lab for another week and rework plans for the week after spring break. No money was lost, but plenty of time was.
@llefevre Wow! That certainly sounds like a mess. Although I am certain you knew the way things should have been handled, for anyone who may not have known, the example set at the company served as a good teacher. I agree with you that the focus of the project should be stated. Without proper focus, things will always be quite scattered. That would have to lead a pretty chaotic situation. I am not surprised that business is no more.
This is a very typical situation in the medical devices field. The ideal solution for this issue is to spend more time in the research/initiation phase in order to gather all the information needed to launch the project. For the example you gave, the marketing team should have spent more time to understand the need for that medical device in Japan and that there is a huge market for it, causing more profit that can be presented to the business to support the business case. Also other functions would need to be aligned; operations would have to confirm that they have the capabilities to support additional volume for Japan, regulatory has to confirm the impact and timeline for Japan's registration. The team has to come together to do enough research to make sure they cover all possible and feasible markets before kicking off the project or at least before starting Design Verification since anything after that would cause a huge delay. Any scope creep after Design Verification would cause delays since some tests might be re-executed to match Japan's regulations or requirements. Those delays are hard to be avoided even if tasks can be executed in parallel, because there is an additional registration now to be planned, more requirements to meet, more operational tasks to support the volume and of course new labeling for Japan. To be prepared for any scope creep, the team has to come up with a mitigation plan to minimize the possibility of that happening, including performing enough research and highlighting the tasks that can be performed in parallel to save time as a worst case. Another example that I see all the time is related to labeling/graphics update; often times there are sustaining updates to graphics on medical devices and often times some new changes come up while the project has been kicked off already or some changes would be left out. The problem here is basically the lack of review from the reviewers across all functions since those changes were not flagged earlier, which would cause delays to the project in order to create new graphics with all changes. Of course this case is not as impactful as the example you mentioned but it still follows the same concept of scope creep.
Scope creep is a real "thing" in the federal government, I guess it depends heavily upon the agency in which you work for. Scope creep in my opinion is when you are given additional tasks so much so where it takes you away from the particular duties for which you were hired for- most specifically what your performance duties state. So, I do have an example of scope creep. Currently, I am a Group Practice Manager for the Department of Orthopedics. I am what's called a 301 series, so my "specific duties" include understanding the service line and patient access to care. What is the standard in public and private practices and compare the measurables to ensure that my military physicians are providing quality care and that they are competitive with their peers out in the civilian community. There is a lot of reading, quantifying, quality control, writing contracts for equipment, ensuring that a standard of quality of care is met and that is reflected in deliverables that show my physicians' products in a measurable format. Now, my example of scope creep, because I am very efficient (which just comes with time, learning the position, and completing projects) I was asked to assist my COL by being his part-time secretary. THAT is a scope creep, secretarial work and analyzing of medical practices are two completely different scoops of practices. Where one may see that positions rely heavily on data programs, Window-based applications, as well as Department of Defense specific data portals, they are nowhere near the same as far as job duties go.
