BUSI 414 Week 7 Paper Part 3: Research Paper Example

Containing Scope Creep: Why Projects Grow and How Definition and Change Control Keep Them on Course

Introduction

A regional hospital approved a project to replace its outpatient appointment scheduling system within nine months and a fixed budget. By the third month, department heads had submitted forty requests for additional features, from text reminders to links with the billing system. Each request seemed reasonable, and many were approved informally in hallway conversations. The project finished seven months late and well over budget, and the scheduling staff found the final system harder to use than the one it replaced.

The pattern is familiar enough to have a name: scope creep. This paper examines why it happens and how projects contain it. Its argument is that most scope creep begins before execution, when the scope is defined loosely, rather than during it through a lapse of discipline. A project that spends early effort on precise requirements, holds to a scope baseline and runs a real change control process stops most unplanned growth without blocking the changes worth making.

What Scope Creep Is

In the PMBOK Guide's definition, scope creep is product or project scope that grows without control and without matching changes to the schedule, budget and resources (Project Management Institute, 2017). The definition turns on the word uncontrolled. Scope changes in almost every project as stakeholders learn more, and an approved change, analyzed for its effects and accompanied by a revised schedule and budget, is not scope creep. Creep occurs when work is added without that analysis, so the project carries more work under the same constraints.

The distinction matters because the remedy is not to forbid change. A project that refuses every change can deliver exactly what was specified and still fail its users. The goal is to ensure that every change is a decision, made by someone with authority, in full view of its costs. Dinsmore and Cabanis-Brewin (2014) make the same point from practice: scope is managed by making change visible, not by pretending it will not occur.

Why Scope Creeps

Research identifies several sources of uncontrolled growth. The first is unclear requirements. When Keil et al. (1998) had veteran software project managers in Finland, Hong Kong and the United States rank the threats they feared most, requirements that were misunderstood, user expectations left unmanaged and shifting scope and objectives all placed near the top of the list. When requirements are vague, later requests are not really new; they are the requirements that were never captured, surfacing as changes.

The second source is optimism and pressure in early estimates. Flyvbjerg (2014) documented that big projects habitually overrun their budgets and schedules and attributed the pattern to optimism bias and to strategic misrepresentation, in which project champions understate costs and scope to win approval. A project approved on a narrow scope that everyone privately expects to grow has scope creep built into its business case.

The third source is stakeholders adding work during execution. Assaf and Al-Hejji (2006), surveying owners, contractors and consultants on large construction projects, found change orders by the owner during construction among the delay causes respondents named most often. The hospital's department heads played the same role. Without a process for weighing their requests, each one was judged on its merits alone, never against the schedule and budget it consumed.

Weak sponsorship ties these causes together. A sponsor who does not engage with the project cannot make the trade-off decisions that change requires, so changes are either approved by default or argued over by the team. In the hospital case, no one with authority over the whole project heard the forty requests together.

The Cost of Uncontrolled Growth

Scope creep is expensive in ways a project budget does not show at first. Each added feature consumes design, building and testing time, but it also adds integration work, because the new piece must work with everything already built, and it adds risk, because work done late in a project is done under time pressure. A modest request can therefore cost far more than its own effort.

A simple illustration shows the effect. Suppose the hospital's original scope required 6,000 hours of work over nine months, about 667 hours a month. If forty requests averaging 60 hours each were absorbed without adjusting the plan, they would add 2,400 hours, an increase of 40 percent. Even before counting the extra integration and testing they require, that is nearly four additional months of work at the original pace. The project team experiences this as constant overtime and slipping milestones; the sponsor experiences it as a project that is somehow always late.

Scope creep also damages the relationships a project depends on. Davis (2014), reviewing research on how different stakeholder groups judge project success, found that senior managers, project teams and the people who receive a project's outputs often weigh success differently. When scope grows informally, each group forms different expectations about what the project will deliver, and the gap between those expectations becomes visible only at the end, when it is hardest to close.

Prevention Through Definition

If unclear requirements are the root cause, definition is the first defense. The Project Management Institute (2017) describes a sequence of scope processes: collecting requirements from stakeholders, defining a detailed scope statement, and creating a work breakdown structure that decomposes all the work into manageable packages. Together these form the scope baseline against which every later change is measured.

Research supports investing in this early work. In a study of over a hundred defense development projects, Dvir et al. (2003) found that success rose with the effort put into defining requirements and writing technical specifications, but not with the amount of formal planning procedure a team followed. The finding is striking: what mattered was not how elaborate the plan was but how well the team understood what it was building. A thick plan built on thin requirements simply schedules the arguments that will happen later.

For the hospital, better definition would have meant interviewing scheduling staff and department heads before setting the scope, asking specifically about reminders, billing links and reporting. Some requests would have been included in the baseline; others would have been deferred to a second phase by explicit decision. Either way, they would not have arrived later as surprises.

Definition also continues after the baseline is set. The Project Management Institute (2017) recommends a requirements traceability matrix, which links each requirement to its source, the business objective it serves and the deliverables and tests that satisfy it. Traceability makes it easier to tell a genuine change from a clarification and to see which deliverables a change would affect. When a department head later asks for a feature, the team can check whether it traces to an approved requirement or represents new scope.

Control Through Integrated Change Control

Definition reduces creep but cannot eliminate change, so projects also need a way to handle requests. The Project Management Institute (2017) places this in the integrated change control process. Every change request is documented, analyzed for its effects on scope, schedule, cost, quality and risk, and approved or rejected by someone with authority, often a change control board. Approved changes update the baseline and the plan; rejected ones are recorded with the reason.

The process works because it makes trade-offs explicit. A department head asking for text reminders sees that the feature will add three weeks and a certain cost, and the sponsor decides whether the benefit is worth it. Dinsmore and Cabanis-Brewin (2014) note that the discipline of writing requests down and reviewing them on a schedule also filters out many casual requests that would have been accepted in conversation.

Integrated change control is called integrated for a reason. A scope change rarely affects scope alone; it shifts the schedule, the budget, the resources and often the risks. Treating each change as a decision about the whole project, not just about a feature, is what keeps the baseline meaningful.

Consider how the process would have handled one of the hospital's requests, a link between scheduling and billing so that copayments could be collected at check-in. The request would be written up with its business reason. The team would estimate the work, perhaps 300 hours, and identify its effects: a dependency on the billing vendor, new testing with the finance department and a three-week delay to the launch. The sponsor and change control board would then decide among three options: approve it and move the launch date, approve it for a second release, or reject it. Any of those choices is legitimate; what matters is that someone with authority made it knowing the cost.

Agile Approaches to Scope

Agile methods take a different approach. Instead of fixing scope and estimating time and cost, they typically fix time and cost through short iterations and let scope vary, with the product owner reprioritizing the backlog as the team and stakeholders learn. Change is expected and absorbed at the start of each iteration rather than routed through a formal board.

The table compares the two approaches.

Evidence suggests the approach can work well. Across more than 1,000 projects, Serrador and Pinto (2015) found that the more a team used agile methods, the better it tended to score on efficiency and on how satisfied stakeholders were. Agile does not abolish scope control, however; it relocates it. A product owner who adds items without removing others, or who extends iterations, produces creep in a new form. The choice between approaches should follow the project's uncertainty: the hospital's billing interface, with fixed external requirements, suited a predictive approach, while the patient-facing screens might have benefited from short iterations with scheduling staff.

Many organizations now combine the two. The Project Management Institute (2017) acknowledges adaptive and hybrid life cycles alongside predictive ones, and a hybrid project might set a predictive baseline for its infrastructure and integrations while developing user-facing features in iterations. The hospital could have fixed the scope of its data migration and billing link through a change control board while giving a product owner from the scheduling office a backlog of screen and workflow features, reprioritized every two weeks within a fixed budget. Each part of the project would then be governed by the approach that fits its uncertainty, and the boundary between them would itself be part of the scope baseline.

Judging Whether a Change Was Worth It

Because some changes add value, the measure of scope management is not the number of changes but their effect on success. Shenhar et al. (2001) described four facets of success, from efficiency and customer impact to business results and future readiness, and that they become visible over different time frames. Serrador and Turner (2015) found that efficiency, meeting time and budget, correlated with overall success but explained only part of it.

These findings give the change control board a better question than whether a change is in scope. The question is whether its effect on customer impact or business success justifies its effect on efficiency. A change that adds a month but makes the system usable for scheduling staff may be the best decision a project makes, while one that adds a feature few will use is creep even if it is formally approved.

Limits of the Argument

The thesis that definition prevents most scope creep has limits. Some projects face requirements that cannot be known in advance, such as new products whose users do not yet exist or research efforts whose results shape the next step. For them, heavy early definition may be wasted effort, which is one reason agile methods emerged. The evidence reviewed here also comes largely from surveys and project samples in particular sectors, such as defense development and construction, so its findings are strongest for projects that resemble those settings.

Change control has costs as well. A board that meets monthly and demands extensive analysis for every small request can slow a project and frustrate stakeholders, who may then bypass the process. Dinsmore and Cabanis-Brewin (2014) suggest scaling the process to the request, with minor changes approved by the project manager within set limits and only significant ones going to the board. The aim is proportion: enough control to make trade-offs visible, not so much that the process becomes its own source of delay.

A Biblical Perspective

Jesus asked who would start building a tower without first sitting down to estimate whether he could afford to finish it (English Standard Version Bible, 2001/2016, Luke 14:28). The builder in the parable is mocked not for building but for starting without knowing what the work would require. Defining scope before committing resources is a form of this counsel, and so is analyzing each change before accepting it.

Scripture also values keeping one's word. Jesus taught, "Let what you say be simply 'Yes' or 'No'" (Matthew 5:37). A project manager who agrees informally to every request, then misses the commitments already made, says yes too easily. Honest change control, telling stakeholders what a request will cost before agreeing to it, lets a team keep its word.

Recommendations

Four recommendations follow. First, invest in requirements before setting the baseline, interviewing the people who will use the result and documenting what is deferred as well as what is included. Second, establish integrated change control from the first day, with a simple request form, a regular review and a sponsor who makes decisions. Third, match the approach to uncertainty, using agile iterations where requirements are evolving and a predictive baseline where they are fixed. Fourth, judge changes by their effect on success, not only on efficiency, and record the reasoning so the project can learn from it.

Each recommendation has a practical first step. For requirements, the project manager can hold structured sessions with each user group and publish a list of what is in scope, what is deferred and what is excluded, asking stakeholders to confirm it. For change control, a one-page request form and a fixed weekly review time are enough to start. For matching the approach, the team can classify each major deliverable by how well its requirements are understood. For judging changes, the change log can include a short note on the benefit expected from each approved change, which can be checked after delivery. None of these steps requires new software or a large budget; they require a sponsor willing to make decisions and a project manager willing to ask for them.

Conclusion

Scope creep grows from vague requirements, optimistic estimates, stakeholder requests that bypass decision makers and sponsors who do not engage. Research shows that defining requirements well matters more to success than elaborate planning procedures, and that efficiency is only part of what makes a project succeed. Projects contain scope creep by defining carefully, controlling change through an integrated process or agile iterations, and judging each change by its value. The hospital's forty requests did not have to sink its project; handled through definition and change control, many could have made it better.

References

Assaf, S. A., & Al-Hejji, S. (2006). Causes of delay in large construction projects. International Journal of Project Management, 24(4), 349-357. https://doi.org/10.1016/j.ijproman.2005.11.010

Davis, K. (2014). Different stakeholder groups and their perceptions of project success. International Journal of Project Management, 32(2), 189-201. https://doi.org/10.1016/j.ijproman.2013.02.006

Dinsmore, P. C., & Cabanis-Brewin, J. (Eds.). (2014). The AMA handbook of project management (4th ed.). AMACOM.

Dvir, D., Raz, T., & Shenhar, A. J. (2003). An empirical analysis of the relationship between project planning and project success. International Journal of Project Management, 21(2), 89-95. https://doi.org/10.1016/S0263-7863(02)00012-1

English Standard Version Bible. (2016). Crossway. (Original work published 2001)

Flyvbjerg, B. (2014). What you should know about megaprojects and why: An overview. Project Management Journal, 45(2), 6-19. https://doi.org/10.1002/pmj.21409

Keil, M., Cule, P. E., Lyytinen, K., & Schmidt, R. C. (1998). A framework for identifying software project risks. Communications of the ACM, 41(11), 76-83. https://doi.org/10.1145/287831.287843

Project Management Institute. (2017). A guide to the project management body of knowledge (PMBOK guide) (6th ed.).

Serrador, P., & Pinto, J. K. (2015). Does Agile work? A quantitative analysis of agile project success. International Journal of Project Management, 33(5), 1040-1051. https://doi.org/10.1016/j.ijproman.2015.01.006

Serrador, P., & Turner, R. (2015). The relationship between project success and project efficiency. Project Management Journal, 46(1), 30-39. https://doi.org/10.1002/pmj.21468

Shenhar, A. J., Dvir, D., Levy, O., & Maltz, A. C. (2001). Project success: A multidimensional strategic concept. Long Range Planning, 34(6), 699-725. https://doi.org/10.1016/S0024-6301(01)00097-8