Handling Change in Projects: Planning and Key Components

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

← Tracking Control Items and Procedures in ConfigurationNext lesson: Reusable Software at Scale: Component-Based Engineering Revisited →

Earn 3 college credits for Software EngineeringRecommended for credit by NCCRS · Computer Science 301 · self-paced · one payment, lifetime access

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.

Compare: Software Engineering vs Systems Analysis

Why take it here

Why students take Software Engineering with UPI Study

How professional software gets builtSoftware Engineering covers how teams turn requirements into working, maintainable software: process models, agile, requirements, design, testing, reliability and project management. It is a core course in computer science and software degrees.
Credit at a fraction of the priceThe same 3 credits can cost $750 or more at a US college. Here it is one payment, self-paced, with lifetime access.
Finish your degree soonerTransfer credits reduce the courses you still owe, so you can graduate earlier or lighten a heavy semester.
Strengthen an applicationA completed college-level course on an official transcript shows admissions and scholarship committees you can do the work.
Study on your own scheduleNo start dates, no deadlines. Watch the lessons, practice, and take the final when you are ready.
130,000+students helped with college creditsACE and NCCRS have over 2,100 cooperating colleges that will consider accepting credits; the final decision is with the universities.

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.

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?
A change request moves through formal submission, an impact assessment, and a decision by the Change Control Board. The impact assessment estimates what the change would cost in schedule, budget, and risk to other parts of the system, and the board decides on that basis rather than on the request's description alone. The outcome is approved, deferred, or rejected.
What is a Change Control Board and who sits on it?
A Change Control Board (CCB) is the designated, cross-functional group with authority to approve, reject, or defer change requests. It typically includes the development lead for technical impact, the QA lead for quality and testing risk, the project manager for cost, schedule, and scope, a customer or business representative for value and priority, and an operations representative for the live system.
Why is a change decided by a board instead of one person?
A board brings several perspectives together so that no single blind spot decides the outcome. A developer alone might approve a technically simple change that quietly breaks the budget, while a project manager alone might approve a change that fits the schedule but adds unflagged technical risk. A cross-functional group is far more likely to catch both.
What should a change management plan include?
A change management plan defines how change requests are submitted and what they must include, the evaluation criteria such as cost, risk, and priority, and the approval authority, meaning who sits on the board and what it can decide. It also defines how decisions are communicated and keeps a change log, which stops rejected requests from resurfacing as if they were new.

About the Software Engineering course

How many college credits is Software Engineering?
Software Engineering (Computer Science 301) carries a NCCRS credit recommendation for 3 semester credits. ACE and NCCRS have over 2,100 cooperating colleges that will consider accepting credits; the final decision is with the universities.
How much does Software Engineering cost and what is included?
$250, paid once, with lifetime access: all 103 video lessons, a practice quiz after each, the graded work and final exam, and an official transcript when you finish. Students who want several courses choose UPI Study PRO instead.
Which universities accept UPI Study credits?
UPI Study has signed partner agreements with universities such as Thomas Edison State University, University of the People and Charter Oak State College, and works with universities such as Penn State, SNHU and SUNY. ACE and NCCRS have over 2,100 cooperating colleges that will consider accepting credits; the final decision is with the universities. Use "Find my college" on this page to check yours.
How long does Software Engineering take?
It is self-paced with no deadlines. The 103 lessons total about 11 hours of video; most students add reading and practice time and finish in a few weeks to a few months, on their own schedule.
How are the exams done?
Quizzes and assignments are online in the course. The final exam is taken online with proctoring; a person on the UPI Study team checks assignments, usually within two days.
How do my credits reach my college?
When the course shows 100% complete, request the official transcript from your dashboard. It is sent to the college you name, and you can send it to more than one. Check your college first with "Find my college" on this page, or ask Athena.

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.

Software Engineering
3 credits · NCCRS
Enroll →