Nothing stays built.
Change is the job.
A project plan is a first draft, not a contract with the future. Requirements shift, environments move, bugs surface, and someone always wants "one more feature." This chapter is the control room: how to let change in without letting it wreck the project — from the change request paper trail, through maintenance and architecture evolution, to shipping, migrating, and — if it all goes sideways — recovering.
Software change is inevitable — plan for it, don't fight it
A key problem for organizations is implementing and managing change to their current projects and legacy systems.
New requirements
Emerge while the software is under development or already being used.
Business environment
The environment the software operates in changes over time.
Errors & risk
Errors must be repaired and risks mitigated as they're discovered.
New equipment
New hardware/equipment must be accommodated by the system.
Performance
Performance or reliability may have to be improved.
A process, not a favor — every change gets the same treatment
Integrated Change Control is a process concerned with project change requests, carried out from project inception through completion. All changes must be carefully controlled to maintain the integrity and consistency of the project plan.
Integrated Change Control
scope · cost · schedule · qualityRecognizes that projects will often require changes to the established project plan. It encompasses all aspects of change to the project:
- Reviewing and approving requested changes
- Managing the changes when they actually occur
- Controlling elements of the project management plan (scope, cost, budget, schedule, and quality) in response to changes
- Controlling changes to requirements, design, code and documentation
Items placed under change/version control: code (product source), documents (requirements, design, test plans, user guides), plans & databases (e.g. MS Project), test scripts, infrastructure scripts, and the software development plan and other process documents.
Queue & ECO
Request is queued for action; an Engineering Change Order (ECO) is generated.
Assign
Individuals are assigned to the affected configuration objects.
Check-out & change
Objects are checked out and the change is made.
Audit
The change is audited.
Baseline
A new baseline is established.
SQA & check-in
If it's a Software Configuration Item (SCI), perform SQA & testing, then check-in the changed objects.
2. Rebuild the appropriate version — include all changes in the release, review/audit the change, perform Verification & Validation (testing).
3. Distribute the new version.
A formally chartered gatekeeper, not a rubber stamp
Change Control Board (CCB)
structure · process · triageIn some projects, the Integrated Change Control process includes a change control board (CCB) — a formally chartered group responsible for reviewing, evaluating, approving, delaying, or rejecting changes to the project, and for recording and communicating such decisions.
CCM (Critical Chain Method): changes require adjustments to buffers. Same responses to change are needed, but the schedule impact may be less severe than in CPM.
Creeping requirements — as a % of the original scope — climb steeply with project size: from roughly 1–2% at 10 function points up to ~50% at 100,000 function points. Bigger project, proportionally more requirements creep.
Agile still controls change — it just doesn't use a CCB
Integrated Change Control, agile style
continuous backlog managementThe agile change control process is not controlled by a change review board and the project manager. Instead:
- Product changes are owned and managed by the customer
- Process changes are owned by the team
- The project manager facilitates collaborative discussion of changes between the customer and the team
| Feature | Plan-Driven Methodologies | Adaptive (Agile) Methodologies |
|---|---|---|
| Change Control Approach | Formal and structured | Informal and flexible |
| Change Management Plan | Well-defined and documented | Limited or no plan |
| Change Control Board (CCB) | Formal, defined roles & responsibilities | Informal, flexible roles & responsibilities |
| Change Request Process | Formal, strict procedures | Informal, flexible procedures |
| Change Impact Analysis | Thorough and detailed | Limited or none |
| Change Implementation | After CCB approval | Quickly and frequently |
| Documented Changes | Well-documented and tracked | May not be documented or tracked |
| Change Communication | Formal and structured plan | Informal and flexible plan |
| PM Approach Emphasizes | Predictability and control | Flexibility and adaptability |
| Best Applicability | Well-defined requirements, stable environment | Changing requirements, uncertain environment |
Three ways software evolves — and they can combine
Software maintenance
Changes made in response to changed requirements, but the fundamental software structure is stable.
Architectural transformation
The system's architecture is modified — generally from a centralized architecture to a distributed one.
Software re-engineering
No new functionality is added; the system is restructured and reorganized to facilitate future changes.
Eight laws describing how large systems age
Applicability has not yet been firmly established. The laws are generally applicable to large, tailored systems developed by large organizations — it's unclear how they should be modified for shrink-wrapped products, systems built heavily from COTS components, small organizations, or medium-sized systems.
Theme 1 — Change dynamics
| Law | Description |
|---|---|
| Continuing change | A program must change or become progressively less useful. |
| Continuing growth | Functionality has to continually increase to maintain user satisfaction. |
Theme 2 — Structural decay
| Law | Description |
|---|---|
| Increasing complexity | As a program changes, its structure becomes more complex; extra resources are required. |
| Declining quality | Quality appears to decline unless the system is actively adapted to its changing environment. |
Theme 3 — System regularity
| Law | Description |
|---|---|
| Large program evolution | System attributes (e.g. size, time between releases) are ~invariant for each system release. |
| Organizational stability | A program's rate of development is ~constant. |
| Conservation of familiarity | The incremental change in each release is ~constant. |
| Feedback system | Evolution processes involve feedback systems for product improvement. |
Modifying a program after it's put into use
Maintenance does not normally involve major changes to the system's architecture. Changes are implemented by modifying existing components and adding new components to the system.
Maintenance to repair software faults — changing a system to correct deficiencies in the way it meets its requirements.
Maintenance to adapt software to a different operating environment — changing a system so it operates in a different environment (computer, OS, etc.) from its initial implementation.
Maintenance to add to or modify the system's functionality — modifying the system to satisfy new requirements.
- Team stability — costs drop if the same staff stay involved over time
- Contractual responsibility — developers may have no contractual duty to maintain, so no incentive to design for future change
- Staff skills — maintenance staff are often inexperienced with limited domain knowledge
- Program age & structure — as programs age their structure degrades, making them harder to understand and change
Guessing where the next fire will start
Maintenance prediction assesses which parts of the system may cause problems and have high maintenance costs. Change acceptance depends on the maintainability of the affected components — and implementing changes degrades the system, reducing its maintainability further. It's a feedback loop: maintenance costs depend on the number of changes, and the cost of change depends on maintainability.
Predicting maintainability: What parts of the system will be most expensive to maintain?
Predicting maintenance costs: What will be the lifetime maintenance costs of this system? What will it cost to maintain over the next year?
Predictions of maintainability can be made by assessing component complexity. Studies show most maintenance effort is spent on a relatively small number of system components. Complexity depends on: complexity of control structures, complexity of data structures, and procedure/module size.
Predicting the number of changes requires understanding the relationship between a system and its environment. Tightly coupled systems require changes whenever the environment changes. Influencing factors: number and complexity of system interfaces, number of inherently volatile requirements, and the business processes where the system is used.
Process measurements assess maintainability directly: number of requests for corrective maintenance, average time for impact analysis, average time to implement a change request, and number of outstanding change requests. If any or all of these are increasing, this may indicate a decline in maintainability.
From centralized mainframe to distributed client-server
There's an ongoing need to convert many legacy systems from a centralized architecture to a client-server architecture.
- Hardware costs — servers are cheaper than mainframes
- User interface expectations — users expect graphical user interfaces (CLI → GUI)
- Distributed access — users want to access the system from different, geographically separated computers
Ideally, for distribution there should be a clear separation between the user interface, the system services, and the system data management. In practice, these are usually intermingled in older legacy systems — layers bleed into each other, making a clean split hard.
| Distribution factor | Why it matters |
|---|---|
| Business importance | Returns on distributing a legacy system depend on its importance to the business and how long it will remain important. More cost-effective if it supports stable business processes. |
| System age | The older the system, the harder it is to modify its architecture — previous changes have already degraded the structure. |
| System structure | The more modular the system, the easier to change the architecture. If UI, data management, and application logic are closely intertwined, it's difficult to separate functions for migration. |
| Hardware procurement policies | Distribution may be necessary if there's a company policy to replace expensive mainframes with cheaper servers. |
Getting a finished change out the door — for real
"Other Aspects" of change management: roll-out, training, documentation, migration, and maintenance & support.
Packaging (if commercial product), marketing collateral, security mechanisms (if commercial), and licensing (plan + mechanism).
Scripts, uninstall support (if not web-based). If you need to install software (e.g. on PCs), don't underestimate the time this takes to develop or the importance of a "first impression." If it's custom software you're reselling, installation at the client site is often a "mini-project" in itself.
TrainingOften more than just end-users: users, sales & marketing staff, system operators, maintenance engineers (possibly), sales engineers (possibly), and (technical) support staff.
Moving users from the old system to the new
Migration is the process of moving from the old application/system to the new one. It requires a Migration Plan, a Back-out Plan, and a Data Conversion strategy.
Migration Plan
the "includes" checklistIncludes: description of the environment (computers, DBs, interfaces), description of existing data needed, description of operational constraints (e.g. when can we move to the new system — weekends only? last week of the month only?), a list of affected organizations and contacts, and a plan of steps to be taken. Also answer: does it require a service interruption (and when)? Is training needed? Is there a help-desk — and do they have scripts or new material?
Flash-Cut
Straight-move / immediate replacement. Fastest approach, but you still want a back-out plan and it requires strong planning and testing. Example: a new corporate-wide calendar system.
Parallel Operation
Mitigates risk — runs parallel to either the existing manual or system process. The "cut" happens once the new system is "burned-in." Multiple variations exist; often paired with an "adoption period" (compare: telephone industry rolling out new area codes).
Staged migration
Replace one part of the existing system at a time, rather than all at once.
- Level of business disruption
- Degree of latitude in the "production" date
- How much internal opposition to the system exists (higher → longer adjustment period)
- Your comfort level with system quality (questionable → mitigate risk)
Criteria: what conditions must be met prior? Responsibility: who decides? Operations: who "owns" it once it's live? Rehearsals are sometimes used.
Most systems need this step, and most PMs forget it. The data is often more valuable than the system itself. Cover: data sources (where from, does it need modification on the way in, is it accurate?), process controls (all at once? how do you guarantee correctness?), and completion (how are exceptions handled? backups? can you restart?).
The end of a project is its own management problem
Seems simple — often isn't. Potential issues: last-minute change requests ("one more feature"), disputes over fulfillment of all requirements (often "interpretation" issues), keeping the team motivated, and a difficult transition into maintenance.
The maintenance phaseSometimes called the "No respect" phase — less glamorous, lower enthusiasm, pressure to fix "production" problems quickly. Software can become "hacked"/"patchwork" over time; finding a support & test platform can be difficult — often the forgotten child until fixes are needed. Configuration control is very important here (fixing the "right" version; tracking branches). Project management isn't always carried over, and the team is often smaller — not a dedicated team, drawn from developers with other main tasks. Contracts matter too: often a "labor hours" (time & materials) contract, or a "maintenance contract" charging a percentage of the software license fee (e.g. 20% of original cost per year); internal/IS projects usually draw from an annual/monthly corporate maintenance budget.
Project Recovery — saving a "drowning project"
4 step groupsThree overall approaches: cut the size of the software, increase process productivity, or slip the schedule and proceed with damage control. This is an opportunity for decisive leadership action — not a time to "just cut corners." Be realistic, not foolish. Timing is politically important: not too early, not too late.
- First: assess the situation (is there a hard deadline? what's negotiable?); don't repeat what's already been done; ask the team what needs to happen.
- People: restore morale (even "sacrifice a sacred cow" — dress code, off-site, catered meals), clean up personnel problems, focus people's time by removing non-essential work, reassign tasks and responsibilities.
- Process: fix classic mistakes (inadequate design, shortchanged activities); create "miniature milestones" (small — day-scale, binary, exhaustive — they boost morale by showing progress); track progress meticulously; recalibrate after a short time; manage risk painstakingly.
- Product: stabilize the requirements; raise the bar on change requests; trim the feature set (determine priorities, cut the low ones); "take out the garbage" (find error-prone modules, re-design them); get to a known, stable state and build from there.
The whole chapter, one scannable pass
| Topic | Key fact |
|---|---|
| Integrated Change Control | Formal process from inception → completion; covers scope, cost, budget, schedule, quality, and requirements/design/code/docs |
| RFC vs ECO | RFC = the initial request for change. ECO = generated only after CCB approval, to queue the work |
| CCB | Formally chartered group: reviews, evaluates, approves/delays/rejects, records & communicates decisions |
| CPM vs CCM impact | CPM: critical-path changes hit hardest. CCM: changes require buffer adjustments, usually less severe |
| Agile change control | No CCB — Product changes owned by customer, Process changes owned by team, PM facilitates; maps to "continuous backlog management" |
| 3 change strategies | Maintenance (stable structure) · Architectural transformation (centralized→distributed) · Re-engineering (restructure, no new functionality) |
| Lehman's Laws | 8 laws about how large systems age — applicable mainly to large, tailored systems in large orgs; applicability not firmly established elsewhere |
| 3 maintenance types | Corrective (fix faults) · Adaptive (new environment) · Perfective (new/changed functionality) — 17% / 18% / 65% of effort |
| Maintenance cost | Usually 2×–100× development cost; rises over time as structure degrades |
| Prediction | Predict system changes, maintainability, and costs; rising process metrics (impact-analysis time, outstanding requests) signal declining maintainability |
| Architecture evolution | Centralized → client-server, driven by hardware cost, GUI expectations, distributed access |
| 3 migration strategies | Flash-Cut (fast, risky) · Parallel Operation (both run, safer) · Staged (piece by piece) |
| Back-out plan | Keep old system available >1 day; set a fallback time limit (e.g. 3 hrs); mgmt wants sooner, tech wants "one more fix" |
| Project recovery | 3 approaches: cut software size, increase process productivity, or slip schedule + damage control |
Where students actually lose points
Six confusions that show up constantly on exams for this chapter.
Click a question to reveal the answer
Quick self-check — no reload needed, just click.
Scenario-to-concept drills
Realistic exam-style prompts grounded directly in the deck — work out your answer before checking.