Scope Creep of a Different Kind
By Literal Thinking
Scope creep is often the bane of every project manager’s existence. High on project managers’ hate lists are the project sponsors, business process owners, and end users who seem to think that there is no time limit to the introduction of new requirements. This, while at the same time querying why the project takes so long to finish and costs so much to complete.
However, there are some project managers who not only tolerate, but sometimes even spearhead and encourage, scope creep. This typically happens when a project manager also wears the account management or business development hat. So while their project management side may want to complete the project on time, scope, and budget; their account management or business development side aims for more revenue and continuous work.
Take the case of Simon, who was enterprise applications manager of a large multinational firm. Read the Complete Article
How Should the Project Manager Deal with Scope Creep?
By Kuntal Thakore
Every project has (or should have) a set of deliverables, an assigned budget, and an expected closure time. There are agreed upon requirements and tasks to complete prior to the closure of project. These constitute the scope of the project. Any amount of variation in the scope of project can affect the schedule, budget and in turn the success of project.
Scoping is the separation between what is included in and what is excluded from project. Scope creep occurs when the line is moved – usually outwards. Thus what was excluded is now included, making a project in most cases larger.
According to the PMBOK Version 4, scope creep is defined as adding features and functionality (project scope) without addressing the effects on time, costs, and resources, or without customer approval. This phenomenon can occur when the scope of a project is not properly defined, documented, or controlled. Read the Complete Article
Managing Project Scope (#30 in the Hut Introduction to Project Management)
By JISC infoNet
In any project there are likely to be changes to the original plan during the course of the project. The changes may arise due to:
- The business case altering
- The need to find a way round a problem
- Identifying a better way to meet your objectives
- The scope of the project altering
- Somebody thinking the change is a good idea
A Change Control mechanism is necessary to ensure that such changes are handled in a managed and controlled way in order to keep the project on track. Without formal procedures in place the project runs the risk of ‘Scope Creep’.
Scope creep is an ever present risk in most projects. It is a particular issue in software development projects where it is always tempting to add a few extra changes as benefits become clear during the progress of the project. Read the Complete Article
How to Control Changes to The Project (#5 in the series How to Control a Project)
By Michael D. Taylor
Changes to the project management plan are inevitable. Rarely does a project manager finish a project with the same project management plan established at the Final Planning Review. If a project manager does not have a formal process for reviewing, evaluating, and approving any such changes the resulting impact will be uncontrolled scope creep.
Why Control Changes?
Uncontrolled changes will create confusion, and confusion will erode commitment to the project. Product quality, overall morale and general loss of interest will most likely take place when a project manager cannot control changes to the project management plan. The project manager’s upward spiral in career advancement may also be dampened when key stakeholders see ineptness in managing project changes. If changes are not managed properly the project manager will experience unacceptable schedule slips, significant cost overruns, and reduced product quality. Read the Complete Article
How to Recover from Unacceptable Variances Arising from the Project Plan (#4 in the series How to Control a Project)
By Michael D. Taylor
When an unacceptable variance from the project management plan arises the project manager needs to ensure that a corrective action plan is established. Even though the primary responsibility for the plan falls on the individual who “owns” the variance, the project manager needs to provide support as a solution facilitator.
Avoiding cost growth and schedule completion delays is paramount which means that any resources needed for correction are within the approved scope of the project. Every effort should be made to first develop “soft” recovery plans that do not require additional costs to the project. If that is not possible, then “hard” recovery plans, that do require additional costs or extensions to the project completion date, should be considered. Obviously, prevention of large variances is superior to experiencing these kinds of project impacts. Read the Complete Article
Go/No-Go Control – Project Control Techniques (#2 in the series How to Control a Project)
By Michael D. Taylor
Having a project management plan will not always ensure having effective project control. Without a control process the project manager will often resort to an improper use of institutional authority to embarrass, or intimidate a project member whose performance is unsatisfactory. As a result the project member will learn to prevent disclosure of any problems. This then creates another problem in that the project manager is not being made fully aware of deviations from the project plan. Taylor’s Law1 states that “the earlier a problem is disclosed, the easier it is to manage.” When project problems are hidden from the project manager they often grow to the point where they become untenable.
Meredith and Mantel offer three methods of control, these are:
Another technique for maintaining project control is the go/no-go method. Read the Complete Article
Project Change Management Tips
By Dave Nielsen
There are two knowledge areas that will determine how well the product you build will satisfy the needs it was built to meet. The first is requirements management, or scope management. The way in which you capture requirements initially, and trace them throughout the design and build process will have a profound impact on how well your product meets your customer’s needs. The second is change management. The needs your product will meet are not static so engaging in a project which can’t support changes to the original requirements is doomed to failure.
Changing needs are not the only source of change. It’s very common for stakeholders and business analysts to learn more about satisfying business needs as they define other needs. Let me give you an example. Let’s say you’re building an e-store (a commercial web site) and you need a means of alerting your customer to a sale you’re conducting on a subset of your products. Read the Complete Article
The Positive Side of Scope Creep
By Meade Rubenstein
You often hear complaints from developers and project managers about scope creep in a project. This is often pointed to as the #1 cause of project failure or delay…how could those dastardly sponsors add more…why didn’t they know this a year ago when we started this project….well the truth of the matter is – scope creep is usually justified and the root cause of it is poor planning. What? How could I say that? Let’s look at some reasons for scope creep:
Read the Complete Article
- Missing work – the actual #1 cause of project failure according to Capers Jones. Either through incomplete business requirements or project definition something that needed to get done was missed. Adding the MIA1 element back in is not scope creep, but scope discovery. Better planning and requirement reviews would uncover these issues.
- Delayed project delivery – sometimes delayed project delivery is caused by priority changes or productivity issues (to aggressive in the planning phase), regardless, a delay in delivery means more time for external or internal business changes, resulting from a change to the project…scope creep?
Preventing Scope Inflation
By Barry Otterholt
Scope inflation is what happens when work grows beyond the minimum required to get the job done. It results in cost and schedule overruns, quality compromises, and disengaged project staff. It follows a common pattern, and so it can be predicted. More importantly, since it can be predicted, it can be prevented. Here’s how it works.
At the start of a project, conflicting biases are not evident, but they exist. The customer, who you represent as a project manager, is eager to get the changes this project promises to deliver. They know if they don’t get them now, the window of opportunity may be gone. The solution-provider, often a vendor you’ve contracted with, is eager to get the project done, on time and within budget. They know if they miss the schedule or go over budget, their reputation will suffer in the marketplace. They also know they could lose money on the deal, which would not help their career advancement within their company. Read the Complete Article
Managing Scope in Project Management
By John Filicetti
After the basics of managing the schedule, managing scope is the most important activity required to control a project. Many project failures are not caused by problems with estimating or team skill sets, but by the project team working on major and minor deliverables that were not part of the original project definition or business requirements. Even if you have good scope management procedures in place, there are still two major areas of scope change management that must be understood to be successful—understanding who the customer is and scope creep.
Best Practice: Ensure that the sponsor approves scope change requests
In general, the project sponsor on the customer side is the person funding the project. While there is usually just one sponsor, a large project could have many stakeholders, or people who are impacted by the project. Requests for scope changes will most often come from stakeholders—many of whom may be managers in their own right. Read the Complete Article