UPI Study › Courses › Project Management › Free lessons › Lesson 8.7 Free with a free account
Change Management Planning and Component Integration
Project Management · Chapter 8: Driving Project ExecutionSection 8.7 · lesson 50 of 7313 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 Project Management.
Lesson complete
Earn the 3 college credits for Project Management
Enrolling adds a quiz after each lesson, the graded work and the official transcript. Recommended for credit by NCCRS.
Next lesson: Risk and Issue Management During Project Execution →← Quality Management Processes and Performance MetricsNext lesson: Risk and Issue Management During Project Execution →
In this lesson
Controlling changes to the baseline and integrating components that fit together.
- Distinguish a change from an error correction or an in-baseline adjustment
- Describe the six steps of change control and the role of a change control board
- Explain how configuration management keeps everyone working on the current version
- Explain how interface agreements and staged integration testing help components fit
Free study notes
Get this lesson's notes by email
The key points and 4 practice questions with answers, in your inbox. One email, free.
One email. Unsubscribe in one click.
Transcript
Everything said in the video, section by section (1,856 words). Read along, or search it.
Opening Case
A Small Request in the Hallway
A small request in a hallway. A developer happy to fit it in. What could go wrong? Priya is in week nine of a twenty-week build of a new scheduling system for Willowbrook Community Clinics, a made-up clinic network. Daniel, who heads the billing office, stops her in the hallway. Could the system add a weekly report, of patients who missed two or more appointments in the last thirty days? It sounds small, and Marcus, the developer, offers to squeeze it in around his other work. Should Priya just let him? Hold that question. By the end of this lesson, you'll see what she did, and why.
Definition
What Counts as a Change
Change is normal. Once work begins, people learn what the plan couldn't contain: a requester sees an early version, a supplier moves a date, or an estimate proves too hopeful. A change is any alteration to what the approved baselines say: scope, schedule, cost, or another approved element. Not everything that alters a deliverable is a change. An error correction brings a deliverable back in line with what the baseline already requires, like fixing a calculation that disagrees with the approved spec. An in-baseline adjustment rearranges work within existing approvals, like swapping two tasks, while every baseline value stays correct. The test: would the approved baseline have to read differently afterward? If so, it's a change. But if an error comes from an ambiguous requirement, deciding what it meant is itself a change.
Why It Matters
The Quiet Harm of Uncontrolled Change
Uncontrolled change does harm without any figures. Each unrecorded addition takes time, money and attention committed elsewhere, so it shows up as a quiet loss. The people who approved the plan no longer know what's being built. Changes interact: two small edits to the same screen can contradict each other. And when the baseline moves silently, comparing progress with it measures nothing, because the yardstick changed without anyone saying so. The aim isn't to refuse change. It's to make sure every change is chosen knowingly, by someone with authority, with its effects seen together, and then recorded.
Quick Check
A Missing Phone Number on Letters
Quick check. The approved specification says reminder letters show the clinic's phone number. The letters Marcus built leave it off. Is adding the number a change, an error correction, or an in-baseline adjustment? Pause, and decide. An error correction. The baseline already requires the phone number, so the fix restores conformity, and the baseline stays true. It's handled inside normal work. It isn't a change, because nothing in the baseline has to read differently. And it isn't just rearranging tasks: the letters fall short of what was approved.
Six Steps
From Request Through Communication
Integrated change control reviews every proposed change, decides on it, and manages its effect on the whole plan, so scope is never approved without seeing schedule, cost, quality, risk and resources. It runs in six steps. First, the request: a written proposal to alter a baseline. A hallway chat isn't one. The manager turns it into one, numbers it, logs it, and screens it. Second, impact analysis: what the change would do to scope, schedule, cost, quality, risk and resources, built with the people who'd do the work, in numbers, with the assumptions shown. Third, review by the change control board. Fourth, its decision. Fifth, the baseline update: new versions of every affected document, keeping the old ones as history. Sixth, communication: the requester, the team, the sponsor, and anyone whose work depends on the changed item. A change approved but never communicated hasn't changed what anyone does.
Impact Analysis
Pricing the Missed-Appointment Report
So Priya doesn't let Marcus absorb it. She asks Daniel for a written request, and with Marcus, she builds the impact analysis. These are made-up numbers. Effort: two days of design, four of build, and two of testing. Eight person-days, at four hundred fifty dollars a day: thirty-six hundred dollars. That's three percent of the hundred-and-twenty-thousand-dollar baseline budget, so the revised budget would be a hundred twenty-three thousand, six hundred dollars. Schedule: Marcus does all of it, so his task grows by eight working days. It has only three days to spare, so the finish moves eight minus three: five working days later. On a hundred-day baseline, that's a hundred and five days: twenty-one weeks, not twenty. Quality and risk: one extra test cycle, and a small risk of incomplete dates in the migrated data. And she offers options, so the board isn't stuck with everything or nothing: approve now, defer until after go-live at the same cost with no date effect, or reject.
Change Control Board
Members, Decision Rights and Thresholds
A change control board is a defined group with authority to approve, reject or defer change requests. It exists because a change trades one thing for another, and the people who'd feel the effects are rarely in one role. It also protects the manager from refusing senior colleagues alone. Typical members: the sponsor, who holds the budget and objectives; the project manager, who presents the analysis; a customer or user representative; a technical lead; quality; and, with a contract, finance or purchasing. On a small project, the board may be two people meeting for twenty minutes. Decision rights say who may decide what, and thresholds move decisions upward. Here, Priya may approve up to two thousand dollars with no date movement. The board decides up to fifteen thousand dollars or ten working days, and Helen, the sponsor, anything beyond. Good thresholds combine measures, and count cumulative effect, so big requests can't be sliced under them. Daniel's request costs thirty-six hundred dollars and moves the date, so it's over Priya's limit, but within the board's.
Two Views
Central Board or Control Near the Work
How much authority should a board hold? One side says centralize. Only a body that sees every request can spot two that collide, or many small approvals draining a budget. The other says push control to the people nearest the work. They have the best information, waiting for a meeting delays work whose value is falling, and short adaptive cycles can reprioritize safely. Whether central review costs more delay than the errors it prevents is a factual question, likely answered differently in different settings. Who ought to hold authority over the baseline is a question of values. This course takes no side. Thresholds are one way to place the dividing line.
Board Decisions
Approve, Reject, Defer or Ask for More
The board can reach four decisions, each with its own record. Approve, in full or with changes: record who decided, when, the approved effects, and any conditions. It triggers the baseline update. Reject: give the reason, in terms of objectives and the impact analysis. A bare refusal teaches nothing, and invites the same request again. Defer: give the reason, the date or event when it returns, and who brings it back. A deferral with no date is a rejection that hasn't been admitted. Request more information: list exactly what's missing, who supplies it, and by when. And every outcome goes in the log, rejections included. For Daniel's report, the board approves, on one condition: the billing office funds the thirty-six hundred dollars, because its staff spend hours each week building that list by hand.
Plan and Log
The Change Management Plan and Change Log
All of this is set out in the change management plan, part of the project management plan. It holds five things. The process, step by step. The roles: who may submit, who analyzes, who sits on the board, and who updates baselines. The thresholds. The forms and logs, and where they're kept. And the timing: how fast requests are acknowledged, how long analysis may take, how often the board meets, and how urgent requests are handled between meetings. It's written before execution, because requests arrive in the first weeks, and rules invented mid-argument get shaped by that argument. The plan is itself under control. A change request form makes every request supply the same information. The change log is the running register: number, requester, description, impacts, decision, date, and whether the baseline was updated. That last column lets anyone check the records agree. A yes beside a rejection, or a no beside an approval, signals an error.
Configuration Management
Keeping Everyone on the Current Version
Decisions only help if everyone then works on the current version. Configuration management identifies the items to control, records which version of each is current, and makes changes to them orderly. Identification: each configuration item, like the requirements document, the test plan, or the database design, gets a unique name and a version number. Version control: one authoritative copy in one agreed place, each revision numbered and kept. People don't work from private copies. Status accounting: recording each item's current version and state, draft, approved or under change, with its history. Which requirements are we building to? It answers in one place. Change control decides whether a change may be made. Configuration management makes sure the right versions change, for everyone. The board's approval was change control. Issuing version one point two, and retiring one point one, is configuration management.
Integration
Interfaces and Staged Integration Testing
Finally, the parts have to fit. A deliverable is usually built from components, and an interface is where two of them exchange something: data, a signal, or a physical connection. An interface agreement states exactly what crosses it: which items, in what format and units, when, what happens on errors, and which side owns each part. Parts can each pass their own specs, and still fail together. Say the pharmacy module counts single tablets, but the stock database expects boxes of twelve. The stock ends up wrong twelvefold. So integration happens in stages, one or two components at a time, starting with those others depend on, so a fault traces to the newest addition. Integration testing checks combined components against their interface agreements. A component test checks one part against its own spec, and passing it doesn't imply passing integration. The order is component tests, then staged integration and integration tests, then the offer for approval.
Quick Check
Check-In Times an Hour Off
Quick check. The check-in kiosk and the scheduling system each pass all their own tests. Joined together, every check-in time shows up an hour off. Which check would have caught it first? Pause, and decide. An integration test, run against an interface agreement that states the time zone. Each part does what its own spec says, so component tests pass. A configuration audit checks versions and records, not how two parts behave together.
Case Resolved
Why the Request Should Not Be Squeezed In
Back to the hallway request. Should Priya have let Marcus squeeze it in? No. His task had three spare days. Eight days of work would have used them up, and pushed the finish later, without anyone agreeing to it. Instead, after the board approved, she issued requirements version one point two, the new budget and the new finish week, and withdrew version one point one as current. She logged the request with the baseline marked updated, and told Daniel, Marcus, the quality lead and Helen the same day. The trade-off: a week of delay and a visible meeting. In exchange, the project's records still describe its work.
Key Takeaways
One Route for Every Change
To recap: a change alters what the baseline says. Error corrections and in-baseline adjustments don't. Every change follows the same route: request, impact analysis, board review, decision, baseline update, and communication. Thresholds decide who decides, and every outcome is logged, rejections included. Configuration management keeps everyone on the current version. Integrate components in stages, and test them against their interface agreements before offering the whole for approval.
About Project Management at UPI Study
Project Management (Business 230) is a self-paced online course of 73 video lessons in 12 chapters, from starting and defining a project to planning, budgets, scheduling tools, proposals, contracts, execution, monitoring, closure, teams and certification. 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 Business courses Every course with PRO →
Why take it here
Why students take Project Management with UPI Study
Where the credit goes
Universities that work with NCCRS
Project Management 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 Change Management Planning and Component Integration
What is integrated change control in project management?
What does a change control board do?
Is fixing a deliverable that does not match its specification a change request?
What is the difference between change control and configuration management?
About the Project Management course
How many college credits is Project Management?
How much does Project Management cost and what is included?
Which universities accept UPI Study credits?
How long does Project Management take?
How are the exams done?
How do my credits reach my college?
Ready for the full course? Earn 3 credits in Project Management.
73 video lessons, a quiz after each one, and the graded work that earns the credit. Recommended for credit by NCCRS.
3 credits · NCCRSEnroll →