UPI Study › Courses › Software Engineering › Free lessons › Lesson 14.7 Free with a free account
Handling Change in Projects: Planning and Key Components
Software Engineering · Chapter 14: Project Estimation, Configuration, and Change ControlSection 14.7 · lesson 92 of 1036 min · free with a free account
Free preview
Create a free account to keep watching
It takes a minute and costs nothing. Your free account unlocks all of Chapter 1 and 3 more lessons of Software Engineering.
Lesson complete
Earn the 3 college credits for Software Engineering
Enrolling adds a quiz after each lesson, the graded work and the official transcript. Recommended for credit by NCCRS.
Next lesson: Reusable Software at Scale: Component-Based Engineering Revisited →← Tracking Control Items and Procedures in ConfigurationNext lesson: Reusable Software at Scale: Component-Based Engineering Revisited →
In this lesson
Change will happen - the question is whether there's a defined way to handle it.
- Explain why undefined change puts a plan at risk
- Describe a change request's stages, from submission to outcome
- Explain the Change Control Board, and why it's cross-functional
- Identify what a change management plan must define
Transcript
Everything said in the video, section by section (710 words). Read along, or search it.
Project Estimation, Configuration, and Change Control
Handling Change in Projects: Planning and Key Components
Every real project gets requests to change something, after work is already underway. The question is never whether that happens. It is whether there is a defined way to handle it when it does.
Why Change Needs a Process
Quiet Accumulation
No real project runs exactly according to its original plan. New requirements surface, priorities shift, and problems appear that the original scope did not anticipate. Without a defined process, changes tend to accumulate quietly. A small adjustment agreed in a hallway conversation. Another slipped into a code review. None of them weighed against the plan as a whole. A change management process replaces that quiet accumulation with a deliberate, visible decision, every time.
The Change Request Lifecycle
From Submission to Outcome
A change request moves through a small number of stages, however large or small the change. First, it is formally submitted. Next comes an impact assessment. What would the change actually cost, in schedule, budget, and risk to other parts of the system? The Change Control Board then decides, based on that assessment, rather than on the request's description alone. And the decision has one of three outcomes. Approved, deferred, or rejected.
The Change Control Board
Who Decides - and Why a Group
A Change Control Board, or C C B, is the designated group with authority to approve, reject, or defer a change request. It exists because one person making that call alone tends to miss whatever they are not looking for. A developer alone might approve a change that looks technically simple, but quietly breaks the project's budget. A project manager alone might approve a change that fits the schedule, but introduces a technical risk nobody flagged. Bringing those perspectives together keeps any one blind spot from deciding the outcome.
Figure 2
Every Affected Area at the Table
A C C B typically draws representation from every area a change might affect. The development lead brings feasibility and technical impact. The Q A lead brings the risk to quality and testing. The project manager brings the cost, schedule, and scope impact. A customer or business representative brings business value and priority. And an operations representative brings the impact on the live, running system.
Think About It
Why 3 Outcomes, Not 2?
Think about this. Why does the board have three possible outcomes, instead of just approve or reject? Some changes are reasonable, but not urgent enough to justify disrupting current work right away. Deferring keeps a legitimate request from being lost, while still protecting the current plan. It avoids forcing an immediate yes or no, on something that does not actually need one.
Table 1
What a Change Management Plan Defines
A change management plan writes down, in advance, how change requests will be handled on a project. It defines the submission process, meaning how a request is raised, and what it must include. And the evaluation criteria, like cost, risk, and priority. It defines approval authority, meaning who sits on the board, and which kinds of change it can decide. It defines how a decision is communicated back to everyone it affects. And it keeps a change log, a running record of every request submitted, and its outcome.
Apply It
A Rejected Request Returns
Let's apply that. A change request that was already rejected resurfaces three months later, proposed again as if it were new. Nobody remembers it was considered. Which part of the plan would have prevented this? The change log. It records every request and its outcome. Checking it would have shown the request was already evaluated and rejected, along with the reasoning behind that decision.
Key Terms
The Vocabulary of This Section
Let's lock in the key terms. A change request is a formal submission asking that some part of a project's scope, design, or plan be changed, after work has already begun. An impact assessment evaluates what a proposed change would cost in schedule, budget, and risk, before a decision is made. A Change Control Board is the designated, cross-functional group with authority to approve, reject, or defer a change request. And a change management plan defines how requests are submitted, evaluated, approved, communicated, and logged.
Key Takeaways
What to Carry Forward
To pull this together. Change is inevitable on any real project. The real risk is change with no defined process, accumulating quietly. A change request moves through submission, impact assessment, and a board decision, with three possible outcomes. A cross-functional board keeps any one perspective's blind spot from deciding the outcome. A change management plan defines the submission process, evaluation criteria, approval authority, communication, and the change log. And the change log keeps rejected requests from quietly resurfacing.
About Software Engineering at UPI Study
Software Engineering (Computer Science 301) is a self-paced online course of 103 video lessons in 15 chapters, from process models and agile to requirements, design, user interfaces, reliability, security and project management. It carries a NCCRS credit recommendation for 3 semester credits.
Every lesson transcript is free on pages like this one, and the videos are free with a free UPI Study account. Enrolling adds a practice quiz after each lesson, the graded work and final exam that earn the credit, lifetime access, and an official transcript on completion. UPI Study has helped over 130,000 students with college credits. ACE and NCCRS have over 2,100 cooperating colleges that will consider accepting credits; the final decision is with the universities.
Enroll now → Course details Download the syllabus All Computer Science courses Every course with PRO →
Why take it here
Why students take Software Engineering with UPI Study
Where the credit goes
Universities that work with NCCRS
Software Engineering carries a NCCRS credit recommendation. These universities work with NCCRS; some are UPI Study's signed partners. ACE and NCCRS have over 2,100 cooperating colleges that will consider accepting credits; the final decision is with the universities.
Thomas Edison State UniversitySigned partner
University of the PeopleSigned partner
Charter Oak State CollegeSigned partner
Strayer UniversitySigned partner
Columbia Southern UniversitySigned partner
Indiana TechSigned partner
Penn StateWorks with NCCRS
Southern New Hampshire UniversityWorks with NCCRS
SUNYWorks with NCCRS
+many more cooperating universitiesFind my college →Find my college → Not listed? Ask Athena in the corner of this page, or book a 15-minute call.
FAQ
Questions students ask us
About Handling Change in Projects: Planning and Key Components
What are the stages of a change request in project management?
What is a Change Control Board and who sits on it?
Why is a change decided by a board instead of one person?
What should a change management plan include?
About the Software Engineering course
How many college credits is Software Engineering?
How much does Software Engineering cost and what is included?
Which universities accept UPI Study credits?
How long does Software Engineering take?
How are the exams done?
How do my credits reach my college?
Ready for the full course? Earn 3 credits in Software Engineering.
103 video lessons, a quiz after each one, and the graded work that earns the credit. Recommended for credit by NCCRS.
3 credits · NCCRSEnroll →