Jul 6-12 · Projects are living entities. This week, we develop the professional rigor to handle change, analyze scope, and formally define the path forward for your final project.
Use the links below to jump to any section.
Every project you manage will change. Stakeholders will ask for more. Timelines will shift. New information will surface. The question is not whether change will happen - it is whether you are prepared to handle it with professional rigor.
Uncontrolled change that drains resources, derails timelines, and erodes team trust. The enemy of every project manager.
Intentional adaptation based on new information. Smart, value-driven change that strengthens the project outcome.
This week, you will learn to tell the difference - and respond like a professional.
In Range (Chapter 2), David Epstein distinguishes between two types of learning environments:
Rules are clear. Patterns repeat. Feedback is immediate and accurate. Chess, golf, and classical music training are examples. Practice leads directly to mastery.
Rules are unclear or incomplete. Patterns are not obvious. Feedback is delayed, inaccurate, or absent. This is where most professional work - including project management - actually happens.
"The rules of the game are often unclear or incomplete, there may or may not be repetitive patterns, and feedback is often delayed, inaccurate, or both." - David Epstein, Range
As project managers, we operate in wicked domains. We cannot rely on rote repetition. We must develop judgment, adaptability, and the ability to transfer knowledge across unfamiliar situations.
Not all change is bad - but not all change is good. The professional project manager must distinguish between two very different forces acting on a project.
The Chaos Agent
Scope creep is not a stakeholder problem - it is a leadership problem.
The Smart Adaptation
Scope discovery is how great project managers turn surprises into advantages.
The difference between the two is not the change itself - it is the process used to evaluate and implement it.
When a stakeholder requests a change, your job is not to say yes or no immediately. Your job is to analyze it. Project Management for the Unofficial Project Manager (Chapter 6) provides a formal set of questions every project leader should ask before accepting any change.
Understand the "why" behind the request. What problem is the stakeholder trying to solve? What outcome are they hoping to achieve?
Evaluate the benefit. Does this change improve the deliverable, serve the end user, or advance the project's core goals? If not, it may be scope creep.
Every change touches the Iron Triangle - Time, Quality, and Budget. Assess the real cost before committing. Something always gives.
Change must be formally authorized. Document the request, the analysis, and the decision. Verbal agreements are not project management.
Traditional project management treats change as a threat to be controlled. Agile thinking reframes change as a source of competitive advantage - if you have the discipline to manage it well.
"Welcome changing requirements, even late in development. Agile processes harness change for the customer's competitive advantage." - Kogon (2024)
Seeking input from stakeholders and adapting your deliverable is not a sign of weakness - it is the core practice of a project leader.
A change request in week 5 of a 6-week project can still be the right call - if it genuinely serves the end user and is properly analyzed.
You can only welcome change confidently when you have a formal process to evaluate it. Agility without structure is just chaos.
Getting feedback and adapting is not a detour from the project - it is the project.
David Epstein's Range argues that the most successful professionals in complex, modern fields are not narrow specialists - they are people with broad conceptual knowledge who can apply ideas across domains.
Epstein describes how scientists who had learned to think abstractly - to see patterns across domains - were far more effective than those who only relied on concrete, domain-specific experience. They could recognize a problem's structure even when the surface details were unfamiliar.
The ability to categorize problems - to ask "what kind of problem is this?" rather than "have I seen this exact problem before?" - is the hallmark of expert thinking in wicked environments. It allows you to apply the right framework even in novel situations.
You are not just learning Git, GitHub, or scope management. You are building a conceptual toolkit - a set of mental models that will transfer to every project, team, and technology you encounter throughout your career. The goal of this course is range.
This week's discussion asks you to think critically about how teams stay aligned - and why the structure of a meeting matters as much as its content.
Compare the Team Accountability Session described in PMUPM (Chapter 6) to a typical status meeting you have experienced or observed. In your initial post, address the following:
This exercise puts the PMUPM change analysis framework into practice. You will respond to a real stakeholder request - from your instructor - using a formal Markdown document.
In your project repository, create a new Markdown file named change-request.md.
Using the PMUPM framework, document the Proposed Change clearly and concisely.
Address three questions: What are the Reasons for this change? What Added Value does it provide? What is the Impact on Constraints (Time, Quality, Budget)?
Commit the file to your GitHub repository with a descriptive commit message. Submit the repository link in the assignment portal.
Write a clear, specific description of the requested feature. What exactly is being added to the site?
Why might the stakeholder want this? What need or goal is driving the request?
What is the benefit to the project or end user? How does it improve the deliverable?
Briefly estimate the impact on Time, Quality, and Budget. What does each constraint gain or lose?
# Change Request
## Proposed Change
[Your description here]
## Reasons for the Change
[Your reasoning here]
## How This Change Will Add Value
[Your analysis here]
## How This Change Will Affect the Constraints
- **Time:** [Your estimate]
- **Quality:** [Your estimate]
- **Budget:** [Your estimate]This is your most significant deliverable of the week. You will step into the role of project manager for your own final project (Project 03) and produce a formal Project Scope Statement - the foundational document that defines what your project is, what it will deliver, and how success will be measured.
Using the Project Scope Statement template from PMUPM Chapter 3, create a comprehensive scope document for your final project. This is not a rough draft - it is a professional artifact that will guide your work through the end of the semester.
Describe the project in clear, professional language. What is it? Who is it for? What problem does it solve?
List the specific, tangible outputs of the project. What will exist when the project is complete? Include the technical requirements, files and folders. List all mandatory repository files. See the "LOOKING AHEAD FOR PROJ 03" section below.
Explicitly define what this project will NOT include. This is as important as what it will include.
Document the Time, Quality, and Budget constraints. List any assumptions you are making about resources, tools, or stakeholder availability.
final-project-scope.md in your project repositoryYour GitHub repository must include the following files and structure for Project 03. These are required for your final submission.
project-03/
├── README.md ← Project homepage; must explain purpose and link to live URL and docs/ folder
├── index.html ← Main homepage of your website
├── about.html ← Second page, linked from your homepage
├── style.css ← External stylesheet linked to both HTML pages
└── docs/
├── scope.md ← Revised Project Scope Statement
├── plan.md ← TAME Risk Analysis & Task Schedule (PMUPM Ch. 4)
└── retrospective.md ← Final project reflection (PMUPM Ch. 7)All coursework is due by Sunday, July 13 at 11:59 PM Central Time. Use this checklist to track your progress throughout the week.
A final reminder: AI tools are powerful brainstorming partners - use them. But your final submissions must reflect your own authentic voice and critical thought. Your instructor is reading your work - not the machine's.
By Sunday night, when you have submitted Assignment 03 and wrapped up your Discussion 06 peer replies, take a moment to reflect on what you have accomplished this week.
You now have a formal framework for analyzing change requests - distinguishing scope creep from scope discovery and responding with professional rigor.
You understand the cadence of accountability - how structured team sessions create the feedback loops that keep projects on track in wicked environments.
You have produced a formal Project Scope Statement - the professional artifact that will anchor your work through the final weeks of the semester.
You are not just completing assignments. You are building the habits, frameworks, and professional instincts that will serve you throughout your career. That is the work of this course - and you are doing it.
The following sources support this week's readings, discussions, and assignments. Use them to deepen your understanding and strengthen your citations.
Range: Why Generalists Triumph in a Specialized World. Riverhead Books.
Focus this week: Chapter 2 - The Wicked Learning Environment
Project Management for the Unofficial Project Manager (Updated and Revised Edition). BenBella Books.
Focus this week: Chapter 6 - Managing Active Projects & the Project Change Request tool
The original 12 principles behind the Agile Manifesto - the foundation for this week's discussion of welcoming change. agilemanifesto.org
A concise, professional overview of scope creep, its causes, and how project managers prevent it. Useful background for Exercise 06. pmi.org
A practical, industry-standard guide to documenting change requests in professional project environments. Directly supports Exercise 06. atlassian.com/agile/project-management
An accessible explainer on the Time, Quality, and Budget constraints - the framework at the heart of your change request analysis this week. mindtools.com
You have scoped your final project. Next week, we begin the closeout phase - reflecting on what we built, documenting what we learned, and preparing to hand off our work like professionals.
Week 07 focuses on the final phase of the project lifecycle - closing out your work with intention, professionalism, and documentation.
You will learn how to conduct a formal retrospective - documenting lessons learned, celebrating wins, and identifying what you would do differently next time.
You will review a classmate's Project Scope Statement from this week, providing structured, professional feedback using a formal review framework.
Week 06: Managing Active Projects