Many times, projects experience 'scope creep' due to a lack of scope definition in the initiation phase of the project lifecycle. However, despite careful planning and alignment with stakeholders on the scope, changes to the scope may still arise. For example, after fully defining the project scope, a secondary VOC is performed with the key customers that brings up more developments to the project or the project sponsor wishes to add to the project objectives after the planning phase has begun due to different developments in the business. How do you manage scope changes as the project is progressing?
Scope Creep in my opinion is most definitely an ongoing problem as a project is shifted from the initializing process to the planning and executing process. Often times I believe while actually executing the project, a new and innovative process may be thought of and often times would be beneficial to implement, even though it was not originally planned to be take on. I believe to combat the problem of scope creep, it is good to have open communications between the project manager and all the working parts of the project and to allocate lag time during the beginning of the execution phase of a project. This is where the most amount deviations are possible from the original plan. From there, I believe there should be weekly meetings with the team to assess how the timeline is holding in practice, from which any addition to the scope is possible without deviating too much from the timeline. However if an addition is too ambitious or takes too long, the addition may be too futile to add and can be properly assessed when there is ample time to allocate.
I can imagine Scope Creep is quite frustrating to deal with and handle, not only for the team but also for the Project Manager. I think I'd like to express the whole ordeal in the analogy of a menu at a restaurant; if there are 200+ items on a menu at a restaurant, then the quality of each dish is diminished and not ensured. The reason for this is because the staff and chefs do not have an equivalent or adequate amount of practice and experience on each item of the menu. This is because some things get ordered more or less than others. We can compare this scenario to a person being a scope creep on a product development team. With the scope of a project becoming more extensive and expansive, this means that some areas of interest will inevitably lack attention, and attention to detail will essentially be lost. It is important to establish this in the very beginning, and stress to the team (whether you are leading in the project or not), that they should keep their scope concise in the amount of things they can realistically accomplish to the best of their ability. This way, when you are approaching the end of your deadline, instead of finishing up important tasks last minute, just to meet all requirements of the vast scope of the project, you can actually just touch up things here and there and pay more attention to the execution and overall finishing touches of your project (Which is far more ideal).
I've spent most of career, so far, working as apart of a R&D team and when it came time to lead the group I decided to implement 2 meetings a week to give upper management updates. When things would change from my end or theirs, we implemented an email chain for immediate discussions when we couldn't meet. This measure made it harder for "scope creeps" to highjack any situation that presented itself. All changes were mainly impacted by the availability of resources, so if the plan changed, then it was probably due to additional resources being verified and validated.
The most crucial step you can take to prevent scope creep is to write down all of your project's needs. You may specify the scope of your project by clearly defining the project requirements. Find out exactly what each stakeholder wants by using clear communication. However, scope creep can still arise in latter parts of the project. Resources may become unavailable or deadlines may have to be rearranged. Following a communication plan can help reduce the likelihood of scope creep. Being able to adapt and using innovative ideas so solve problems can eliminate the risk of scope creep.
This is a fantastic question, one that might be the focus of a couple case studies to thoroughly examine. I don't have much experience in the medical device industry, just 6 months in an ultrasound transducer manufacturing co-op before working in commodity polymers. But in both cases, we had change "risk" limits that demanded escalation in the company to discuss. Those risks could be financial, safety related, and/or quality related. An example of a "low risk" change would be a location change of a 240V outlet in a warehouse to be more ergonomic for workers. A "high risk" change would be an overall process unit change to accommodate a new technology or safety requirement for the company, which can risk worker safety and/or global product quality if not properly accommodated. I can't think of a better way to handle this, even though the onus of risk assessment and management is left to error-prone human calculation.
I've spent most of career, so far, working as a part of a R&D team and when it came time to lead the group, I decided to implement 2 meetings a week to give upper management updates. When things would change from my end or theirs, we implemented an email chain for immediate discussions when we couldn't meet. This measure made it harder for "scope creeps" to highjack any situation that presented itself. All changes were mainly impacted by the availability of resources, so if the plan changed, then it was probably due to additional resources being verified and validated.
This Approach in eliminating the Scope Creep seems to be very organized and efficient. My plan on how we can reduce the chances of the scope creep, creeping into our project, would be to limit the number of people who are in charge of sketching the scope of the product/Project or setting a time limit, only during which your change/initiative is entertained.
Constantly revisiting the original proposal and plans, so as to remind the team of what was planned originally, during the planning phase, might be a suggestion. [Open to discussion]
Scope creep is an important factor to look at while working on a project as it can happen at any point after the project starts. To avoid this, I think the scope of the project should be properly defined and documented so that other team members can know what is exactly needed and don't arise any new scope. I also think if priority of tasks will be defined, it will avoid scope creep. Not only in industry I think scope creep can occur in research area too and for that, the research project or thesis will get delayed.
Defining the scope is a key element that sets up the project. It can have a general idea and with more input from people in the project, it can become more defined and in many cases, it can change. Scope changes can throw off a schedule and mess with the slack allotted to certain tasks. It would be important for the project manager to be on the lookout for potential changes. Constant meetings with the members and stakeholders would be crucial in keeping up with the changes. It also seems very important that the members speak up about what is possible and what is not possible in the time frame given. Communication within each party determines how well the change can be accepted into the current plan and whether or not the time frame/budget would need to change.
