Project Integration Management (KM-02) CPUT Study Notes

Project Integration Management is the Project Management Institute (PMI) knowledge area that deals with bringing all project pieces together: aligning strategy, integrating plans, managing changes, and ensuring the project delivers its intended outcomes. In a CPUT context, where students often struggle to connect processes across knowledge areas, Integration Management offers the “glue” that makes the whole system coherent—especially during planning, execution, and change control.

These exam notes focus on the CPUT KM-02 Project Management style of learning and emphasize the practical steps you can write in tests and assignments: how to produce an integrated project management plan, how to coordinate work, and how to manage changes using formal control systems. The guide also includes exam-friendly frameworks, examples, and mini-case scenarios you can adapt.

1. Understanding Project Integration Management in the CPUT KM-02 Context

1.1 What Integration Management Really Means (Beyond the Definition)

In PMI’s PMBOK® framing, Project Integration Management consists of processes that require trade-offs and coordination among competing requirements. The key idea is that project outcomes depend not only on doing activities correctly in isolation, but on integrating decisions across time, scope, cost, schedule, quality, resources, risk, procurement, and stakeholder needs.

In many CPUT exam questions (and in practical course work aligned with project planning and control modules), lecturers test whether you understand integration using questions like:

“How do you ensure that changes in scope do not break schedule and cost baselines?”
“Explain the outputs of integration processes and how they link to other knowledge areas.”
“Describe what you would do when plans conflict during execution.”

A common trap is treating integration as “everything everywhere at once.” A more correct exam answer is to show that Integration Management is a structured sequence of processes that produce and maintain documents/outputs used across the project lifecycle.

1.2 The Integration Management Processes (Core Exam View)

A clear way to answer most KM-02 style questions is to group integration processes into three phases: developing direction, executing and managing work, and controlling change.

Here’s the PMI-aligned set of Integration Management processes commonly tested:

Develop Project Charter
Develop Project Management Plan
Direct and Manage Project Work
Manage Project Knowledge
Monitor and Control Project Work
Perform Integrated Change Control
Close Project or Phase

Not all lecturers use the same numbering or labeling, but the concepts above are the typical “core.” In CPUT examinations, the expected competency is that you can:

Explain the purpose of each process,
Identify its inputs and outputs at high-level,
Link to what happens in other knowledge areas (schedule, cost, scope, risk, etc.),
Describe tools and techniques (integration registers, change logs, issue logs, meeting cadence, and so on).

1.3 Why Integration Is Critical: The “Connected System” View

Projects fail not only because plans are wrong, but because the organization reacts to problems in a fragmented way. Example fragmentation patterns you may be asked about:

The team updates the schedule due to delays but forgets to revise the budget baseline.
Risk mitigation actions are planned but are not integrated into the work breakdown structure (WBS) and resource plan.
Procurement decisions are made without considering quality requirements and inspection procedures.
Stakeholder concerns are handled informally, so change control is bypassed and baselines become meaningless.

Integration Management ensures the project behaves like a system rather than a collection of tasks. In the exam, you should argue:

Baselines exist for control (scope/time/cost),
Integration ensures consistency among baselines and plans,
Change control ensures controlled evolution, not chaotic drifting.

1.4 A CPUT-Style Mini-Scenario: Township Infrastructure Upgrade

Consider a hypothetical CPUT-aligned scenario:

A municipality hires a contractor to upgrade electrical distribution for a township. The project includes:

upgrading transformers,
installing new cables,
ensuring compliance with safety standards,
coordinating with local residents and municipal departments.

The same project needs integration between:

scope (what is built),
schedule (when work happens, considering access windows),
cost (materials and labour),
quality (testing and compliance),
risk (weather, delays in material supply),
stakeholder management (community engagement),
procurement (supplier lead times).

A failure of integration could look like this: the procurement team orders materials late, the schedule slips, the contractor requests additional funds for overtime, but scope statements were not reviewed—so the revised costs are not linked to a proper integrated change control outcome. The project then enters conflict: different teams argue different versions of “what the project is.”

Integration Management prevents this by forcing decisions through a coherent workflow.

1.5 Exam Strategy: How to Write Integration Answers in KM-02

When a question asks “Explain,” you usually score higher by structuring your answer in a way that shows:

Purpose (why the process exists),
What it produces (outputs),
What it depends on (inputs),
How it connects to other knowledge areas (integration),
How it is used to manage conflict and change.

A high-scoring answer often includes a mini-list of outputs and the logic of linking them. For example:

“Develop Project Management Plan” produces an integrated plan (or “project management plan” bundle),
That plan integrates subsidiary plans (schedule, cost, quality, risk, communications, procurement, etc.),
It establishes baselines for monitoring and control,
It feeds execution and control processes.

Keep your writing consistent: mention the outputs, then refer back to them when describing change control.

2. Developing the Charter and the Project Management Plan (Direction Setting)

2.1 Develop Project Charter: The Authorisation Document

The Project Charter is the project’s “startup authority.” In exam terms, it answers: Why does the project exist and who has the authority to do it?

A typical charter includes (at different depths depending on the module):

business need / problem statement,
project description (high level),
measurable objectives (often aligned with SMART logic),
high-level risks or assumptions,
summary milestones and budget level,
stakeholder summary,
assigned project manager and authority statement.

Why it matters for Integration Management

Integration starts with authority. Without a charter:

teams cannot justify resources,
stakeholders cannot agree on objectives,
change control loses credibility (because the baseline “reason” is unclear).

In a CPUT exam scenario, if you are asked what happens when the charter is weak, you can argue:

scope creep increases because objectives are unclear,
schedule and budget baselines are negotiated late,
disputes occur around whether changes are “in scope.”

2.2 Inputs to the Charter Process (Exam-Ready List)

When writing answers, you can mention typical charter inputs such as:

business case or feasibility study outputs,
agreements (internal or external),
enterprise environmental factors (organizational constraints),
organizational process assets (templates, historical info).

If a lecturer asks you to name likely inputs, your answer should show that charters are not created from thin air—they are derived from organizational strategy, operational needs, and existing records.

2.3 Charter Output and Stakeholder Commitment

The charter process results in:

the project charter itself,
a formal recognition of the project manager’s authority.

A subtle integration point often tested: stakeholder alignment.

Even if the charter is approved, integration requires that key stakeholders understand the objectives and high-level approach so they don’t block execution later. That links into communications planning and stakeholder engagement, but the authorization belongs to the charter stage.

2.4 Develop Project Management Plan: The “Integrated Blueprint”

After the charter, the project management plan is where integration becomes tangible. This plan is not a single document only—it is an integrated bundle that includes:

scope management plan,
schedule management plan,
cost management plan,
quality management plan,
resource management plan,
communications management plan,
risk management plan,
procurement management plan,
stakeholder engagement plan,
plus the baseline components needed for control.

Exam wording tip

You can write: “The project management plan includes subsidiary plans and establishes baselines used to measure performance.”

This one sentence can help you answer multiple questions because it connects planning with monitoring and control.

2.5 The Role of Baselines (Scope, Schedule, Cost) in Integration

Integration Management relies on baselines. In many exams, you might be asked what baselines are used for.

Scope baseline: the approved WBS and scope statement (often including acceptance criteria).
Schedule baseline: time-phased schedule model with milestones.
Cost baseline: time-phased cost budget.

These baselines are not just numbers—they are references for:

performance measurement,
change control evaluation,
progress reporting.

If integration is missing, baselines may diverge across departments, or updates may occur informally without record. That makes control impossible.

2.6 How Planning Inputs Become an Integrated Plan: A Practical Flow

A good integration explanation uses step logic, for example:

Use charter objectives to drive scope definition and WBS creation.
Use scope deliverables to derive activities and sequencing for schedule.
Convert schedule activities into resource estimates and cost budgets.
Build quality standards and acceptance criteria into deliverables.
Identify risks and integrate responses into work planning.
Define communication channels and stakeholder touchpoints.
Plan procurement based on what must be bought vs produced internally.
Assemble all into the integrated project management plan and baselines.

This flow is exam gold because it shows integration across knowledge areas rather than treating them separately.

2.7 CPUT KM-02 Example: “CPUT Lab Upgrade Project” Planning

Assume CPUT launches a project:

Upgrade 3 computer labs (Lab A, Lab B, Lab C),
Replace hardware,
Improve network connectivity,
Ensure uptime during semester blocks.

To build a project management plan, integration includes:

Scope: what exactly is replaced and what “done” means (acceptance criteria like functional testing, network speed benchmarks).
Schedule: sequencing around semester calendars (e.g., installation during recess periods).
Cost: hardware, labour, network services, and contingency.
Quality: configuration standards, security checks, and testing procedures.
Risk: supply delays, network incompatibilities, and downtime risk.
Procurement: vendor selection and lead times.
Stakeholder: lecturers, lab assistants, IT support, students.

If the risk plan says “supplier delays may occur,” integration requires that this mitigation is not merely a risk statement—it must be translated into:

buffer time in schedule,
alternative vendors in procurement plan,
escalation steps in issue/exception handling.

In an exam scenario, if asked “How does Integration Management integrate risk planning into the project plan?” you can answer: by embedding risk response work into the WBS/schedule, and reflecting cost impacts in the cost baseline and contingency.

2.8 Why Integrated Planning Reduces Change Chaos

Integrated planning reduces “false changes.” False changes happen when:

teams interpret requirements differently,
acceptance criteria are unclear,
procurement specs do not match quality standards,
schedule assumptions conflict with resource availability.

By integrating plans early, the project creates shared assumptions and documented decisions. Then integrated change control becomes easier: if a change is requested, the project can show its baseline context and evaluate impact accurately.

3. Directing and Managing Work + Managing Project Knowledge (Execution Integration)

3.1 Direct and Manage Project Work: Coordinating People and Deliverables

Once planning is complete, Direct and Manage Project Work is where integration meets reality. This process ensures project activities are executed according to the project management plan.

In exam answers, emphasize:

execution is not just doing tasks,
it includes coordinating resources, managing communications, resolving issues, and performing quality checks,
it ensures outputs of work are aligned with scope objectives and standards.

A typical scenario: the schedule says a deliverable should be complete by Week 6. Directing and managing work includes verifying:

progress status,
readiness of inputs,
resource availability,
constraints,
dependencies.

If dependencies slip, integration requires that you assess whether you should rebaseline or request an integrated change.

3.2 Integration During Execution: Consistency Across Subsidiary Plans

Execution needs integration among multiple subsidiary plans:

quality plan: ensure inspections and acceptance tests occur.
risk plan: ensure risk response actions are performed when triggers occur.
communications plan: ensure reporting cadence and stakeholder updates happen.
resource plan: ensure resource schedules are consistent with activity schedules.
procurement plan: ensure contracts and procurement deliverable timelines align with schedule milestones.

The exam often tests your ability to state how these plans influence work. Avoid vague answers like “monitoring happens.” Instead, connect specifics:

“quality audits are scheduled during installation and before acceptance”,
“risk responses are triggered and implemented based on risk indicators”,
“procurement deliveries are synchronized with installation activities.”

3.3 Manage Project Knowledge: Capturing and Reusing Learning

Manage Project Knowledge is a distinctive integration process. It ensures that knowledge gained is captured, analyzed, and reused to improve current or future project performance.

In exam contexts, lecturers may ask:

What does knowledge management do in a project?
Why is it part of Integration Management?
How do you capture lessons learned effectively?

Common knowledge inputs:

lessons learned,
project records,
risk and issue learnings,
performance measurement results.

Common knowledge outputs:

lessons learned repository,
knowledge base updates,
best practices and “what to do / what to avoid” guidelines.

Why knowledge is integration

Knowledge management is integration because it connects:

past decisions to current choices,
different teams’ experience into a shared project learning system,
future planning assumptions into better risk and schedule decisions.

Without knowledge management, a project repeats mistakes—creating recurring integration failures.

3.4 Case Study: Network Upgrade with Repeat Failure Pattern

Imagine Lab upgrade projects in a university environment. In Year 1, the team replaces routers and upgrades cabling. In Year 2, they repeat a similar upgrade but forget Year 1’s learning:

They once underestimated Wi-Fi channel interference in certain lab corners.
They once learned that vendor firmware required specific configuration settings.

If knowledge is not managed, Year 2 may encounter:

repeated delays during troubleshooting,
quality issues (performance below standard),
stakeholder frustration due to downtime.

Integration through “Manage Project Knowledge” would involve:

capturing the Year 1 issues in a lessons learned log,
updating configuration procedures in the quality management plan,
reflecting schedule contingency for firmware testing,
using procurement evaluation criteria to require relevant firmware compatibility.

In an exam, you can describe knowledge management as a cycle: capture → analyze → update plans → apply.

3.5 Tools and Techniques You Can Mention for Execution Integration

Although your course may not require deep tool listing, exam markers like credible tools/techniques. You can mention:

stakeholder meetings and alignment sessions,
performance reporting (status reports),
forecasting (EAC-type thinking, though you may not need formulas),
change request systems,
issue logs and resolution tracking,
quality audits and inspections.

Don’t overdo terminology—choose those that show integration: systems that link work output to plan requirements and change control.

3.6 Handling Conflicts During Execution: Integrated Resolution Logic

A frequent exam question: “During execution, schedule and cost estimates conflict. What do you do?”

A high scoring answer should show that you:

identify the source of the conflict (e.g., resource overtime, supplier delays),
assess impact on baselines (scope/time/cost),
determine whether it’s an exception you can handle within the management plan or whether it requires integrated change control,
prepare documentation (change request, revised estimates),
submit for review and approval through integrated change control,
once approved, update the plan and communicate changes.

This is integration in action: resolving conflict through controlled updates and stakeholder alignment rather than unilateral changes.

3.7 Mini-Scenario with Numbers: Procurement Delay and Overtime Decision

Suppose a project has:

a baseline cost of R 2,400,000 (you may treat it as a total, or mention cost baseline),
a milestone to receive equipment by Week 5.

A supplier delay is noticed on Day 10 of Week 4. Two options appear:

Option A: accept the delay and reschedule installation (pushes milestone).
Option B: hire overtime technicians to compress tasks later (increases cost but keeps milestone date).

Integration requires evaluating both:

schedule impact,
cost impact,
quality impact (overtime can increase rework risk),
risk response implications.

Then you decide whether the overtime plan is within contingency/management reserve or whether it triggers integrated change control. Even if you do not compute exact numbers in the exam, the logic must show integrated evaluation across knowledge areas.

4. Monitor and Control Project Work + Integrated Change Control (Keeping Control Integrated)

4.1 Monitor and Control Project Work: Measuring Performance Against Baselines

Monitor and Control Project Work ensures project performance is measured, monitored, and reviewed. It uses:

results of execution,
performance metrics,
comparison against baselines (scope, schedule, cost),
forecasting based on observed performance.

In exam answers, you can emphasize:

monitoring identifies variance,
controlling includes taking corrective or preventive actions,
output feeds into change control decisions.

A strong integration statement:

“Monitoring provides the information required to make integrated change decisions.”

This links directly to the next process: integrated change control.

4.2 What Counts as Performance Data (Exam-Friendly Examples)

Performance data may include:

completed work status vs planned,
schedule progress and milestone attainment,
cost expenditures vs cost baseline,
defect rates and quality compliance,
risk status and trigger occurrences,
procurement delivery status vs contract requirements,
stakeholder satisfaction indicators and communication effectiveness.

You should not restrict yourself to cost and schedule. Integration requires that performance is a broader concept: quality and risk are also measured and influence decisions.

4.3 Corrective vs Preventive Actions (Common Exam Differentiation)

In many project management courses, students confuse corrective and preventive actions. Use a simple rule:

Corrective actions respond to performance problems already present (variance exists).
Preventive actions respond to potential issues (variance may not yet exist but risk indicators suggest it might).

Example:

If inspection results show defects increasing, you take corrective action (fix the process and rework plan).
If vendor delivery delays are starting (early warning), you take preventive action (escalate, adjust procurement strategy, or set alternate delivery paths).

These actions must also be integrated into planning where needed and must be recorded.

4.4 Performance Reports and Forecasting: Decision Inputs for Change Control

In integrated project management, reporting is not just “informing.” Reports are decision inputs.

Typical reporting outputs include:

status reports,
progress updates,
forecasts (e.g., estimated completion scenarios),
variance analysis.

Your exam answer should state that these outputs become inputs to:

integrated change control,
issue resolution,
planning adjustments (if change is approved).

4.5 Perform Integrated Change Control: The Governance of Change

Integrated Change Control is the process that manages changes across all baselines and project components. It ensures:

changes are captured as requests,
analyzed for impact on scope, schedule, cost, quality, risk, and procurement,
reviewed by appropriate authority (change control board or other governance team),
approved/rejected,
implemented in a controlled manner,
communicated and documented.

This is often the highest-mark area in integration exam questions because it tests whether you can describe change governance—not only change ideas.

4.6 Change Request Types and What They Impact

When changes are requested, they might involve:

scope changes (new deliverables or removed requirements),
schedule changes (shifting milestones),
cost changes (budget revisions due to labour/material changes),
quality changes (updated standards, testing levels),
changes in risk responses (new mitigation actions),
procurement changes (contract modifications, supplier changes),
documentation changes (plans update).

Your answer should explain that integrated change control is the “single place” where decisions about impacts are made.

A common wrong approach: saying “change is handled by whoever caused it.” Instead, say changes are evaluated centrally to preserve consistency.

4.7 Change Control Board (CCB) and Decision Authority

Many organizations use a Change Control Board (CCB). In CPUT-style exam writing, you may describe the CCB as:

representatives from project management,
finance/cost control,
technical/quality stakeholders,
procurement,
sometimes senior management depending on project scale.

The core exam idea is decision authority and governance. If asked “who approves changes,” your answer should align with a governance structure (CCB or designated approver).

4.8 The Integrated Change Control Workflow (Write This Like an Algorithm)

To score well, present change control as a sequence:

Request change (via change request form, email workflow, or official log entry).
Register change request (record in change log with unique identifier).
Assess impacts on baselines and plans:
- scope impact,
- schedule impact,
- cost impact,
- quality impact,
- risk impact,
- procurement impact.
Review and evaluate using criteria:
- project objectives alignment,
- feasibility,
- cost-benefit rationale,
- risk and constraints.
Decide:
- approve,
- reject,
- request modification,
- defer (if needed).
Update documents and baselines if approved.
Implement change through execution adjustments.
Communicate decision to stakeholders.
Close change request and archive records.

This algorithm-like description is exactly what many examiners want: clarity and completeness.

4.9 Example: Curriculum Facility Upgrade Change

Scenario: CPUT is upgrading a classroom facility. Baseline assumptions include:

standard electrical requirements,
specific ceiling height and wiring configuration.

During installation, the contractor discovers:

existing wiring is non-compliant with the assumed electrical capacity.

A change request is made: update electrical system requirements and add additional circuit breakers.

Integrated change control analysis must cover:

scope: new electrical components and compliance testing.
schedule: additional procurement lead time and installation hours.
cost: additional materials, labour, possible overtime.
quality: updated inspection/testing requirements.
risk: electrical compliance risk reduces but schedule risk increases.
procurement: contract changes with supplier/vendor for extra materials.

The decision might approve the change if compliance is mandatory, but the project should also update baselines (especially schedule and cost). In exam terms: integration ensures changes do not break the control system.

4.10 Managing Change Without Losing Control: Counter-Arguments and Balance

A counter-argument sometimes raised by students: “Change control slows down delivery.”

Your exam response can be balanced:

Change control can appear slow, but it prevents:
- rework caused by inconsistent assumptions,
- cost and schedule chaos from informal changes,
- stakeholder disputes about “what was approved.”

Speed can be achieved by:

pre-defining thresholds for “minor changes” that can be handled under delegated authority,
maintaining a strong documentation and baseline discipline,
using fast-track evaluation processes for low-risk changes.

A good integration answer shows that governance can be efficient, not necessarily heavy.

4.11 Closing the Control Loop: How Outputs Feed Execution and Planning

Integrated change control produces outputs such as:

updated project management plan components,
updated baselines (if approved),
updated project documents,
lessons learned entries (sometimes at close or significant events).

These outputs then affect future monitoring and execution.

A critical integration point you should state explicitly in exams:

“Change control does not end with approval; it updates plans and baselines so monitoring and control remains meaningful.”

5. Closing the Project or Phase + Integration Lessons for CPUT Success

5.1 Close Project or Phase: Formal Completion and Verification

Closing ensures the project (or phase) is formally completed and that results are:

verified,
transitioned to operational ownership,
documented,
learned from.

In exams, close is often under-discussed, but integration requires that closure is not just administrative—it ensures alignment between planned deliverables and actual results.

A typical closure includes:

validating deliverables meet acceptance criteria,
obtaining formal sign-offs from stakeholders,
archiving project records,
releasing resources,
updating organizational process assets with lessons learned,
assessing whether objectives were achieved.

5.2 Closure in a University/CPUT-Like Environment: What Changes?

In many CPUT-related projects, closure can include:

final handover of equipment,
documentation handover to IT/maintenance teams,
training sessions for staff (lab assistants, lecturers),
final compliance testing.

If you are writing an exam answer about closure, mentioning operational transition is a strong integration point: the “project work” ends, but the “deliverable usage” begins.

5.3 Close Phase vs Close Project: Why It Matters

A project may have phases (design, procurement, installation, commissioning). Closing a phase ensures:

outputs of that phase are accepted,
approvals are recorded,
information is carried forward to the next phase.

If asked, you can describe:

closing a phase reduces the risk of carrying unresolved issues forward,
it strengthens the integration of future planning by confirming what’s already done.

5.4 Lessons Learned and Organizational Learning

Closure links directly to Manage Project Knowledge. During closure:

final lessons learned are documented,
best practices and failures are captured,
future projects benefit through organizational process assets.

This matters because integration knowledge is cumulative. Without knowledge transfer, each project becomes a new experiment—raising risk of repeating avoidable failures.

5.5 Integration Metrics That Are Useful at Close (Exam-Friendly)

Even if your module does not demand quantitative metrics, mentioning common closure-focused metrics can strengthen your answer:

deliverable acceptance rate (planned vs accepted),
defect resolution completion,
schedule variance (at a high level),
budget variance (at a high level),
stakeholder satisfaction feedback,
risk closure status (what risks were retired, what residual risks remain).

If you include numbers, keep them consistent. In this guide, examples are conceptual to avoid introducing inconsistent quantitative claims.

5.6 Example Closure: “Lab Upgrade Commissioning Completion”

Scenario: CPUT upgraded Lab A, Lab B, Lab C. During commissioning:

hardware functions verified,
network performance tested,
security access tested,
lecturers confirm readiness.

Closure activities include:

formal sign-off from IT manager and academic stakeholders,
handover of warranties, manuals, and configuration documentation,
final training for lab assistants,
archiving project documents and procurement records,
collecting lessons learned: e.g., “firmware test should be scheduled earlier,” “backup power planning needed.”

This closure step supports future projects through integrated knowledge.

5.7 Linking Integration Management to Other Knowledge Areas (Without Repetition)

A good final exam answer often demonstrates that Integration Management is not a separate “thing,” but a coordinator across the knowledge areas.

A concise mapping you can use in your writing:

Scope: integrated via charter objectives, WBS, and change control.
Schedule: integrated via plan baselines and impact analysis in change control.
Cost: integrated via cost baseline, contingency considerations, and approval governance.
Quality: integrated by ensuring acceptance criteria are embedded in the management plan and verified during execution/close.
Risk: integrated by translating risk responses into work and evaluating new risks during change control.
Procurement: integrated by ensuring contract requirements and lead times align with schedule and quality standards.
Stakeholders: integrated through communications and ensuring approvals are obtained for changes and acceptance.

The exam marker’s key question is: do you show how integration connects to everything else?

5.8 Integration Management “Common Exam Pitfalls” and How to Avoid Them

Use these as study checkpoints:

Treating integration as purely documentation
- Integration is about coordinated decisions and controlled changes, not only reports.
Explaining processes without linking inputs/outputs
- Always mention at least one input and output relationship.
Confusing corrective vs preventive actions
- Corrective fixes what is already wrong; preventive prevents likely issues.
Describing change requests without the approval workflow
- Integrated change control must include impact analysis and decision authority.
Ignoring closure
- Closure includes acceptance, handover, archiving, and lessons learned.

By addressing these pitfalls, your exam answers become more coherent and marker-friendly.

5.9 A Unified CPUT-Style “Integration Story” You Can Use in Essay Questions

When writing an essay, structure it as a story from start to finish:

Charter authorizes the project and defines purpose and objectives.
Project management plan integrates subsidiary plans and establishes baselines.
Execution directs and coordinates work according to the integrated plan.
Monitoring measures performance and generates decision information.
Integrated change control ensures any changes affecting baselines are evaluated and approved consistently.
Close verifies acceptance, hands over deliverables, archives records, and captures lessons learned.

This narrative arc mirrors PMI logic and aligns with CPUT teaching approaches: lifecycle thinking plus integration.

5.10 Final Exam Checklist for KM-02: What to Mention to Get Marks

Before you submit an exam answer, ensure you included:

Purpose of the integration process,
at least one output (project charter, project management plan, updated baselines, lessons learned, accepted deliverables),
at least one link to monitoring/change/knowledge,
a clear sequence when asked (especially for integrated change control),
a mention of stakeholders or governance (approval authority and communications).

Even if you cannot remember every input item, including these integration anchors typically earns partial credit.

Quick Reference: Integration Management “Glossary for Essays”

Project Charter: authorises the project; defines high-level objectives and authority.
Project Management Plan: integrated bundle of subsidiary plans + baselines for control.
Baselines: scope, schedule, and cost references for performance comparison.
Direct and Manage Project Work: coordinates execution in line with the integrated plan.
Manage Project Knowledge: captures, analyses, and reuses learning.
Monitor and Control Project Work: measures performance and takes corrective/preventive actions.
Integrated Change Control: governs changes by evaluating impacts and updating baselines/plans.
Close Project or Phase: verifies acceptance, hands over deliverables, archives records, and records lessons learned.

Conclusion

Project Integration Management is the exam-critical knowledge area because it ties together the entire project lifecycle. In CPUT KM-02 style questions, your marks rise when you demonstrate how integration processes create consistency: charters authorize, integrated plans align baselines, execution coordinates work, monitoring provides performance evidence, integrated change control governs baseline updates, and closure ensures verification and knowledge transfer. Mastering this “connected system” approach—especially the integrated change control logic and the lifecycle narrative—turns integration from a confusing topic into a repeatable, high-scoring method for project management exams.