Project foundations (operational requirements, system requirements, design constraints, and software requirements) determine the scope of work to be accomplished in a project. I have seen situations where the project was constrained by scope and schedule. How do you manage requirements and prevent “scope creep?”
Scope creep is every project team’s nightmare. Scope creep happens when a project team is no longer capably of controlling the growth or changes defined in the scope. This is why is very important to define and have all the stakeholders understand and agree to the scope of the project, including what’s out of scope. We all do understand that there may be requirement and requested changes that may occur during the life cycle of the project. But the project team should have a well defined change control policy in place to help address such situations. Request changes should be well documented in a change control log which should then be reviewed and addressed by the change control team. Final decisions should be made on not just if the changes fall within scope but also the impact of the requirement and or requested change on the overall timeline and cost.
scope creep is the worst thing that can happen in a project. Although all things are inevitable, situations occur that are out of our control, we must know that there are risk involved, no matter how hard we try to keep the project within its deadlines. When you working within a project scope you have a set schedule that is provided within a budget. Everything you do within a project is accounted for based on you WBS (work breakdown structure). If something is added by the client, this will cost the project money. If the supplier/vendor/manufacturer is not on time with a shipment and the project has a deadline, this will create additional cost for the project. Once the scope, schedule and budget have been impacted you have a major problem.
Project Scope creep has many different names such as focus creep, feature creep, function creep, and requirement creep. Project scope creep in project management refers to uncontrolled changes or added objectives in a project’s scope. This phenomenon can occur when the scope of a project is not properly documented, defined, or controlled. It is generally considered a negative occurrence, and thus, should be avoided.
I do agree that Scope Creep can be a nightmare. If requirements change, I would evaluate the project and look at deadlines, deliverables, costs, etc. Most important is to evaluate how the change in requirements will affect the critical path aka the key indicator to determine if the project will be on schedule or will be late. If Scope Creep causes the critical path to change so the project will be late, I would call a meeting to look at options: Increase resources, cut back on features, adjust schedule for resource optimization, etc. Key is good communication and coordination. If stakeholders and sponsors understand and accept the consequences of their new requirements, then the project can be adjusted accordingly.
Scope creep is unavoidable, but it can be mitigated. By fully understanding the project vision and priorities of the stake holders then scope creep can be relegated. Having clear deliverables and milestones goes a long way in preventing scope creep.
Sometimes scope creep sneaks up on us and sometimes we simply don’t focus enough! Either way it is the same ending…. over schedule, over budget and quality may be greatly impacted! how often do you update the team on milestones and tasks? Do you hold regular meetings? What seems to be the best time for your team to meet?
Milestones and task updates should happen at every scheduled meeting. It should be included in the agenda with the expected completion date and a status. Meeting times should be defined and agreed on by the project team as part of the communication plan. Project team should decide on a date and time that works for the majority of the team members as a start. But the project team may have to change the times down the road so it works for the stakeholders that may be involved at that stage of the project.
Based on a study, one of the best times is Tuesday 3pm.
In most of the training sessions I attended, they recommend mid-morning meetings work best. At my current job, meeting occur anytime. In my experience, any meeting at the end of the day is worst and most likely to be cancelled or skipped.
Scope Creep is a possibility anytime you have people involved. So that is pretty much always. It is very likely that a project is planned out and ready to start work and the requirements change or like Villa stated the vendors are late or don’t have the part. Scope creep only becomes a problem when the customer is sitting around waiting for a deadline that has been blown out of the water. An article I read on projectmanager.com sums up five steps to help eliminate scope creep.
- The requirements must be documented. Especially if the requirements have changed. These notes are important to note that way everyone is on the same page.
- A change Control must be set up. This way changes are not just flying by the seat of the pants.
- Create a clear project schedule. This eliminates surprises.
- Verify the scope with stakeholders
- Talk with the project team
How does scope creep happen? Are we not managing to requirements? or are we managing to the customer?
Poor planning will eventually lead to a potential scope creep. Lack of knowledge of what you want and what it will take to get the job done and the absence of a well defined change control are the major causes of scope creep. There is no doubt that managing scope creep can be challenging but allowing it to spin out of control can be disastrous to the project as well. Every opportunity should be explored to help minimize if not eliminate uncontrollable situations. I also think managing the requirements is as important as managing the customer. Expectations should be set at the start of the project with all the stakeholders. poor planning has the biggest impact of scope creep. Knowing so much information from the beginning what the customer wants somehow can prevent some of the scope creep. But life is not perfect and customers wont really know what they really want until project start start to become reality. On the other hand, I think we are managing to the customer more that we should which I really do understand. Now a days, cash is hard to find so anything to save a project we will do. Sponsors do not grant extra funds that easily in scope creep cases so Brenda has a good point with proposing her disagreement.
To be brief the scope creep is a result of poor scope management. Any insufficient effort on the following listed processes will enhance the risk of scope creep while managing projects. But scope creep could be considered as one of the project risks and a contingency plan to be developed for any given risk of scope creep .The required budget could be set aside in project contingency if a scope creeps happens.
1) Not having a sufficient/practical scope management plan.
2) Unclear scope management process
3) Insufficient collect requirements process from stakeholders
4) unclear and not well completed WBS and work breakdown dictionary (the work breakdown structure can best be thought as an effective aid for stakeholders communication)
I addition, the process of verifying scope (the process of a progressive scope verification in compliance with the stakeholders requirements) and control scope is in most when preventing scope creep.
Scope creep usually is a combination of both, but when the customer becomes uncontrollable with changes scope creep becomes a huge factor. Without putting in boundries such as change control mechanisms the customer can change the requirements and scope of the project day to day so to speak. So managing to the customer is can get you in trouble once the requirements have been defined and agreed upon.
Scope creep can happen a number of ways. Below are some situations that can cause scope creep:
Poor Requirements Analysis: Customers don’t always know what they want
Not Involving the Users Early Enough: Thinking you know what the users want or need
Underestimating the Complexity of the Project: Nobody knows what to expect, there are no lessons learned and no one to ask.
Lack of Change Control: it is important to design a process to manage these changes
Gold Plating: This term is given to the practice of exceeding the scope of a project in the belief that value is being added
How can monitoring the project help to minimize this?
Controlling the scope of your project begins before the first line of code is written. Every development effort should have a corresponding project plan or project agreement, regardless of the situation. Even if you’re just one developer trying to make the boss happy, you’ll benefit greatly from documenting your efforts before you begin them. Use the following guidelines to set yourself up to successfully control the scope of your project:
1.Be sure you thoroughly understand the project vision. Meet with the project drivers and deliver an overview of the project as a whole for their review and comments.
2.Understand your priorities and the priorities of the project drivers. Make an ordered list for your review throughout the project duration. Items should include budget, deadline, feature delivery, customer satisfaction, and employee satisfaction. You’ll use this list to justify your scheduling decisions once the project has commenced.
3.Define your deliverables and have them approved by the project drivers. Deliverables should be general descriptions of functionality to be completed during the project.
4.Break the approved deliverables into actual work requirements. The requirements should be as detailed as necessary and can be completed using a simple spreadsheet. The larger your project, the more detail you should include. If your project spans more than a month or two, don’t forget to include time for software upgrades during development and always include time for ample documentation.
5.Break the project down into major and minor milestones and complete a generous project schedule to be approved by the project drivers. Minor milestones should not span more than a month. Whatever your method for determining task duration, leave room for error. When working with an unknown staff, I generally schedule 140 to 160 percent of the duration as expected to be delivered. If your schedule is tight, reevaluate your deliverables. Coming in under budget and ahead of schedule leaves room for additional enhancements.
6.Once a schedule has been created, assign resources and determine your critical path using a PERT Chart or Work Breakdown Structure. Microsoft Project will create this for you. Your critical path will change over the course of your project, so it’s important to evaluate it before development begins. Follow this map to determine which deliverables must be completed on time. In very large projects, I try not to define my phase specifics too early, but even a general plan will give you the backbone you need for successful delivery.
7.Expect that there will be scope creep. Implement Change Order forms early and educate the project drivers on your processes. A Change Order form will allow you to perform a cost-benefit analysis before scheduling (yes, I said scheduling) changes requested by the project drivers.