INFO6007 Chap.11 Integration Management and Change Control
Integration Management and Change Control
This chapter coordinates the project as one controlled system. A change request is defined, assessed across every affected plan, decided by the proper authority and implemented through consistent baseline updates. It also extends integration into organisational adoption, where current and future states, role impacts, communication, training and measurable use determine whether technical delivery creates value.
Integration checks that scope describes scheduled work, resources can perform it, cost funds it and risks and quality controls match the delivery approach. Decision and version records help teams identify the current authorised state. Impact assessment covers product, schedule, money, people, procurement, benefits and operations before an option is approved, rejected, deferred or exchanged.
After approval, affected artefacts and stakeholder messages must change together. Closure then confirms acceptance, ownership, contracts, records, finance and later benefits responsibility so unresolved work is not abandoned when the temporary project ends.
What this chapter covers
- 01
Project integration responsibilities
- 02
Change request definition
- 03
Cross plan impact analysis
- 04
Change authority and decisions
- 05
Baseline updates
- 06
Current and future state assessment
- 07
Adoption measures and benefits
- 08
Assess every change request across benefits, scope, schedule, cost, quality, risk, resources, procurement and operations
- 09
Keep impact analysis and recommendation separate from the authorised decision and from subsequent implementation
- 10
Update each affected baseline, configuration item, contract and stakeholder record after an approved integrated change
- 11
Distinguish raw work-performance data from contextual information and decision-ready reports when monitoring the plan
- 12
Close with formal acceptance, operational ownership, financial reconciliation, retrievable lessons and assigned benefits tracking
- 13
Preserve configuration identity and decision history so teams can distinguish authorised versions from informal work
Worked example · free
Assess biometric login
- +1Define requirement and acceptance evidence.
- +1Assess privacy, accessibility and supplier impact.
- +1Estimate schedule, cost and specialist work.
- +1Route options to the change authority.
- +1Update baselines and stakeholder communication.
Key terms
- Change request
- A recorded proposal to modify a deliverable, baseline, process, document or controlled condition.
- Impact assessment
- Analysis of consequences across scope, time, cost, quality, resources, risk, procurement, benefits and operations.
- Adoption measure
- Evidence that intended users and processes actually use the delivered change to produce outcomes.
Integration Management and Change Control FAQ
Why does change control examine every plan?
Project plans are connected. A product change can alter work, dependencies, cost, resources, risk, quality, contracts, training and support, so isolated approval creates baseline contradictions.
Who should approve a change?
The authority depends on defined thresholds and decision rights. The project manager may control minor changes, while baseline or strategic exceptions may require an authorised board or sponsor.
How is organisational change different?
Product change control protects baselines. Organisational change prepares people, roles, processes and culture for the new state and measures whether sustained adoption produces the intended benefits.
Exam move
Study integration by tracing one decision through the whole project system. Begin with the charter and ask how scope, schedule, cost, resources, risk, quality, procurement, communication, benefits and operations express the same authorised intent. Use version control so teams can identify the current requirement, baseline and decision record.
Capture lessons while their context is fresh and apply them during delivery instead of waiting for closure. For change control, define the requested output, reason, requester, urgency and acceptance evidence. Assess connected impacts and present options such as approve, reject, defer or exchange scope. Route the decision to the authority defined by thresholds.
Approval is incomplete until affected documents, contracts, risks, requirements and stakeholder communications are updated. Practise finding contradictions, such as a feature approved in scope but absent from schedule and budget, or a risk response that procurement has not funded. Then extend the analysis from product change to organisational adoption.
Describe current and future states, affected processes, roles, technology and culture. Plan communication, training and support by stakeholder need, and use adoption measures that show actual behaviour and outcome rather than installation. At closure, confirm accepted deliverables, unresolved items, operational ownership, contracts, records, finance and later benefits accountability.
Avoid both premature closure and indefinite project activity. On the notes sheet, keep a connected-baseline checklist and the request-assess-decide-update sequence. In a case answer, state the consequence across plans, the authorised option and the evidence that proves implementation. Integration is not a separate document; it is the consistency that allows every project control to describe one current state.
Working through Integration Management and Change Control in INFO6007? Sia is AskSia’s AI Project Management tutor — ask any INFO6007 Integration Management and Change Control question and get a clear, step-by-step explanation grounded in how INFO6007 is taught and assessed. Read this chapter free, then take your hardest questions to Sia.