BUSI 414 Week 3 Paper Part 2: Outline and Annotated Bibliography Example

Containing Scope Creep: An Outline and Annotated Bibliography on Scope Definition and Integrated Change Control

Topic and Thesis

Topic: scope creep and its control in project management. Thesis: Scope creep is less a failure of discipline during execution than a failure of definition at the start; projects that invest in clear requirements, a stable scope baseline and a working integrated change control process prevent most uncontrolled growth, while still allowing the changes that add value.

Outline

• I. Introduction: a hospital scheduling system that grew by forty requests after kickoff; thesis.
• II. What scope creep is: the PMBOK Guide's definition; scope creep compared with approved change; why the distinction matters.
• III. Causes: unclear requirements, stakeholder pressure, optimism in estimates and weak sponsorship; evidence from research on project risks and megaprojects.
• IV. Prevention through definition: requirements, a scope statement, a WBS and the resulting scope baseline; research linking requirements definition to success.
• V. Control through integrated change control: change requests, impact analysis, the change control board and configuration management.
• VI. Agile approaches: fixed time and cost with flexible scope; research on agile project success; when each approach fits.
• VII. Measuring the result: success beyond efficiency; why some approved changes increase value.
• VIII. A biblical perspective: counting the cost and keeping one's word.
• IX. Recommendations and conclusion.

Annotated Bibliography

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

This edited handbook gathers chapters by experienced practitioners and researchers on each stage of project work, from initiation and scope through execution, control and closure. Dinsmore and Cabanis-Brewin (2014) present the material as practical guidance rather than research findings, which makes it useful for describing how organizations actually manage requirements and changes. Its practitioner voice complements the PMBOK Guide's process view. It will support sections IV and V, especially the practical steps of building a scope baseline and running change reviews.

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

Dvir et al. (2003) analyzed over one hundred defense development projects to see which planning activities went with success. They found that defining requirements and developing technical specifications were positively related to success measures, while the level of formal planning procedures and tools showed little relationship. The sample comes from one sector, which limits generalization, but the finding directly supports the thesis that definition matters more than procedure. It is the central evidence for section IV, and its distinction between substantive and procedural planning will help the paper explain why a thick project plan can coexist with poorly understood requirements.

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

Flyvbjerg (2014) summarizes evidence that megaprojects habitually overrun their budgets and timelines and underdeliver on benefits, and attributes the pattern largely to optimism bias and strategic misrepresentation in early estimates. He recommends outside-view techniques such as reference class forecasting. Although the article concerns megaprojects, its explanation of how early commitments are made on unrealistic scopes and estimates applies to smaller projects. It will support section III on causes, particularly the point that pressure to win approval encourages sponsors to understate scope at the start, which then reappears as creep later.

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

Using a Delphi study of experienced software project managers in three countries, Keil et al. (1998) ranked the risks managers saw as most serious and grouped them into a framework by how much control the project manager has over each. Misunderstood requirements, failure to manage end-user expectations and changing scope and objectives ranked among the top risks. The study is older and limited to software, but it remains widely cited and maps closely onto the causes of scope creep. It will support section III.

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

The PMBOK Guide's chapters on integration and scope management define the processes the paper examines, including collecting requirements, defining scope, creating the work breakdown structure, validating and controlling scope, and performing integrated change control. The Project Management Institute (2017) defines scope creep as the uncontrolled expansion of product or project scope without adjustments to time, cost and resources. As the profession's standard, it provides the authoritative definitions for sections II, IV and V, though it describes processes rather than testing them.

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 and Pinto (2015) analyzed survey responses covering over a thousand projects in many industries and found that greater use of agile methods was associated with higher project efficiency and stakeholder satisfaction. Their large, cross-industry sample strengthens the finding, though the data are self-reported. The study supports section VI, which argues that agile approaches control scope differently, by fixing time and cost and treating scope as the variable, rather than by preventing change.

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

Serrador and Turner (2015) tested how strongly meeting time, budget and scope goals relates to overall project success, using survey data on a large set of projects. They found a meaningful correlation, but efficiency explained only part of overall success, with stakeholder satisfaction closely tied to it. The finding supports section VII, which argues that some approved changes that cost time and money still increase a project's value, so the goal is control rather than zero change.

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

Shenhar et al. (2001) proposed four dimensions of success, covering efficiency, customer impact, business results and readiness for the future, which become visible over different time frames. Their study of more than a hundred projects supports treating success broadly. The article complements Serrador and Turner (2015) in section VII and gives the paper a framework for judging when a scope change is worth its cost. A change that delays a project by a month can still be the best decision the team made, if it is the reason customers use what was built.

Closing Note

Every section of the outline has support. The PMBOK Guide and the AMA Handbook supply definitions and practice for sections II, IV and V; Keil et al. (1998) and Flyvbjerg (2014) explain causes in section III; Dvir et al. (2003) provide the key evidence for section IV; Serrador and Pinto (2015) support section VI; and Serrador and Turner (2015) with Shenhar et al. (2001) support section VII. Before drafting Part 3, I plan to add one or two recent studies on change control boards and to apply the instructor's feedback on this outline. I will also look for a case that illustrates a change control board at work, so that section V can show the process as well as describe it.