UNIT 1 — EXAM CHEAT SHEET

Principles of Project Management

1.1 Introduction

This unit covers the core principles, strategies, structures, and lifecycles needed to plan and run projects cost-
effectively from start to finish.

1.2 Project Management Principles and Concepts

Project management is the process of planning, organising, leading and controlling tasks to achieve project
objectives on time and within budget — with one person (the project manager) fully accountable for success.

1.2.1 Pre-requisites for a Project

Conditions that must be in place before a project can begin successfully.

• Clear start and end date — every project needs defined boundaries to manage budgets and resources
properly.
• Defined objectives and deliverables — the project must have a specific, unique outcome that sets it
apart from day-to-day operations.
• Executive support — senior leadership must visibly back the project and give the PM authority to make
decisions.
• Competent team — the PM and team members must have the skills and qualifications required for the
project.
• Management information systems — proper tracking and control systems must be in place from the
start.

1.2.2 What is a Project?

A temporary, unique effort to create a specific product or service within limited time and resources.
KEY ATTRIBUTES EVERY PROJECT SHARES
• Clearly defined objective — everyone knows what the project must deliver.
• Interdependent tasks — activities depend on each other and must be done in sequence.
• Limited lifespan — it has a fixed start and end date, not ongoing like operations.
• A sponsor/customer — someone owns the project and will benefit from its outcome.
• Inherent risk — uncertainty exists because no two projects are exactly alike.
• Balanced constraints — quality, scope, cost and time are all equally important.
TYPES OF PROJECTS (9 TYPES BY YOUKER)
• Administrative — involves process or system changes, e.g. switching accounting methods; requires
careful change management and staff training.
• Construction — buildings, roads, bridges; cost is the primary constraint and health and safety laws are
critical.
• Computer software development — scope changes frequently as technology evolves; requires careful
management of technical staff.
• Design of plans — engineering or architectural projects that evolve as they unfold; high analytical skill
required.
• Equipment/system installation — e.g. installing telecoms equipment; needs a contingency plan for
unexpected downtime.
 • Event or relocation — fixed completion date that cannot move; e.g. a campus move must be done before
classes begin.
• Maintenance of process industries — time is critical as downtime affects operations; stakeholders must
be informed in advance.
• New product development — scope changes are common; requires understanding of market demand
and may take years to complete.
• Research — evolves over time; includes feasibility studies, environmental impact assessments, and long-
term medical research.
MAIN PARTICIPANTS IN A PROJECT
• Project Sponsor — senior executive who owns the project, bears the greatest risk, secures funding, and
approves the project charter and scope. Acts as the link between the project and senior management.
• Project Manager — the person assigned to lead the team and is fully responsible for achieving the
project's goals; reports to the sponsor and manages both upward and downward in the organisation.
• Project Team — all the people who carry out the work on the project; composition changes based on the
skills needed at each stage; team leaders report to the PM.
• Project Management Office (PMO) — the internal body that sets and maintains project standards,
templates, documentation, guidance, and metrics across all projects in the organisation.
• Stakeholders — anyone who has an interest in or is affected by the project, including end users, clients,
suppliers, creditors, community members, and the project team's own families.
• Steering Committee — senior executives or board members who approve project proposals, allocate
budgets, and ensure projects align with the organisation's overall strategic direction.

1.3 What is Project Management?

Applying five management functions to deliver a project successfully to all stakeholders.

• Planning — setting objectives and deciding how to achieve them before work begins.
• Organising — assigning tasks and resources to the right people in the right structure.
• Staffing — recruiting and selecting the right people for the project team.
• Leading — motivating, guiding and directing the team to work toward the project goal.
• Controlling — comparing actual progress to the plan and correcting any deviations.

1.3.1 Project Constraints (Quadruple)

Every project is pulled in four directions at once — balancing all four is the PM's core challenge.

• Scope — all the work that needs to be done; when all deliverables are complete, the project is done.
• Time — the project must finish by a set deadline; missing it can result in fines or lost future work.
• Cost — the budget covers people, materials and equipment; the goal is to stay within it while maintaining
quality.
• Quality — the standard agreed with the client; too high raises costs, too low means the client won't accept
the result.

1.3.2 Other Constraints

Beyond the quadruple constraints, these additional factors can limit or affect a project.

• Customer satisfaction — keeping the client happy is essential; they control future funding and loyalty.
• Resource constraints — people, tools, equipment and materials are all limited and must be carefully
managed.
• Risks — risks can be positive (opportunities) or negative (threats); both must be planned for.
• Stakeholders — people affected by the project must be identified and kept engaged throughout.
 1.4 Project Environment

The context surrounding a project shapes how it runs — a PM must understand and adapt to these factors.

• Cultural and social — people, demographics, and education levels affect team dynamics and stakeholder
expectations.
• Political and international — different countries have different laws and cultural influences that impact
the project.
• Physical environment — factors like time zones matter especially in international or distributed project
teams.

1.5 Project Organisation, Context and Strategy

Before starting, a PM must analyse the organisation and align the project to its strategy using PMI's four-step
model.

• Step 1 — Understand what type of organisation the project will be run in.
• Step 2 — Assess the organisation's maturity — how sophisticated are its processes and standards?
• Step 3 — Choose the correct project configuration (structure and tools) for this specific project.
• Step 4 — Apply good governance — make sure the project is properly overseen and controlled
throughout.

1.6 Project Management and Organisational Structures

How an organisation is structured determines how much authority the PM has and how resources are
controlled. Three main structures exist.

1.6.1 Functional Organisation

Traditional top-down hierarchy where departments run independently and the PM has very limited authority —
must seek approval from functional managers for decisions.
ADVANTAGES
• Stable — employees stay in their departments, reducing disruption and improving continuity.
• Less costly — uses internal staff rather than expensive external consultants.
• Expertise shared — skilled employees can contribute to multiple projects across the organisation.
DISADVANTAGES
• PM has little control — must get approval from functional managers before acting, which slows things
down.
• Project work is secondary — employees prioritise functional duties over project tasks, reducing quality
and focus.
• Poor communication — silo mentalities and bureaucracy hinder open project communication.

1.6.2 Pure Project Organisation

The PM has full authority and budget control; the entire team is dedicated solely to the project with no functional
distractions.
ADVANTAGES
• Fast and flexible — autonomous team focused on one goal with no functional distractions.
• Clear accountability — the PM owns all decisions and is fully responsible for outcomes.
• Strong communication — focused team means information flows faster and more efficiently.
DISADVANTAGES
• Expensive — resources are duplicated across projects and staff may be kept on even when idle.
• No post-project role — team members have no functional department to return to when the project ends.
• Project overrides organisation — the project can take on its own agenda and lose sight of overall
business goals.

1.6.3 Matrix Organisation

A hybrid — staff report to both a functional manager and a PM simultaneously. Authority balance varies across
three forms.

• Weak matrix — functional manager holds more power; PM plays a coordination role with limited authority.
• Strong matrix — PM holds more power; similar to a pure project structure in terms of control.
• Balanced matrix — power is shared equally between the PM and functional manager.
ADVANTAGES
• Flexible — draws the best elements from both functional and pure project structures.
• Post-project security — employees remain affiliated to their functional department and have a role after
project completion.
• Resource availability — resources can be sourced from both inside and outside the organisation.
DISADVANTAGES
• Dual reporting conflict — employees juggle two bosses which causes stress, confusion and competing
priorities.
• Slow — employees must fulfil both functional and project duties simultaneously, reducing speed.
• Accountability confusion — unclear who has final say can slow decision-making and weaken control.

1.6.4 Ideal Project Organisation

There is no universal best structure — the right choice depends on the specific project's needs. Key factors to
consider:

• Project scope — what needs to be delivered and how complex it is.

• Project size and duration — larger and longer projects need more formal structures.
• Risk level — higher risk projects benefit from structures with stronger PM authority.
• Company culture and resources — the organisation's norms, budget, and available staff all influence
the choice.

1.7 Projects in Organisations

Projects affect organisations in multiple ways — the PM must evaluate the impact of the project on the
organisation and vice versa across three spheres.

1.7.1 The Three Spheres Model

Every project must be assessed through three lenses to understand its full impact on the organisation.

• Business sphere — will the project generate financial value or a positive return? Consider the Triple
Bottom Line: economic, social, and environmental impact. If a project only costs money with no clear
benefit, it should not proceed.
• Technology sphere — is the technology actually justified? Technology should be a means to an end — it
must improve efficiency or generate cash flow, not just be impressive or new.
 • Organisational sphere — how will people be affected? Employees often resist change due to past bad
experiences or fear of the unknown — the PM must manage this through communication and transition
planning.

1.7.2 Legal, Ethics and Professionalism

PMs must ensure the project is conducted ethically and in full compliance with relevant laws and standards
throughout its lifecycle.

• Legal compliance — contracts, procurement, and labour law must all be followed correctly throughout the
project.
• Health and safety — especially critical in industries like construction where workers face physical risk.
• Data security and privacy — stakeholder information must be protected and systems secured against
breaches.
• Ethics and professionalism — PMs must act with integrity, avoid conflicts of interest, and continuously
develop their professional skills.

1.8 Introduction to Knowledge Areas and Project Lifecycle

Projects follow a structured lifecycle from concept to closure, guided by 10 PMBOK knowledge areas grouped
into 5 process groups.

1.8.1 PMBOK — Knowledge Areas and Process Groups

The PMBOK is a global PM standard — not a rigid methodology, but a flexible set of best practices
organisations can adapt. It defines 10 knowledge areas:

• Integration Management — coordinating all parts of the project so they work together as one unified
effort.
• Scope Management — defining exactly what is and isn't included in the project to prevent uncontrolled
expansion.
• Time Management — scheduling tasks efficiently so the project is completed within the agreed
timeframe.
• Cost Management — planning and controlling the budget so the project stays profitable and within
financial limits.
• Quality Management — ensuring the project output meets the agreed standard — not too high, not too
low.
• Resource Management — managing people and other resources effectively, since people are less
predictable than machines.
• Communications Management — making sure the right information reaches the right stakeholders at the
right time.
• Risk Management — identifying, analysing, and planning responses to both threats and opportunities on
the project.
• Procurement Management — managing suppliers, contractors and vendors to get the best value for the
project.
• Stakeholder Management — identifying everyone impacted by the project and keeping them
appropriately engaged.
5 PROCESS GROUPS
• Initiating — formally authorise the project and identify all stakeholders.
• Planning — develop the full project plan covering scope, schedule, budget, risks and communication.
• Executing — carry out the work defined in the project management plan.
• Monitoring and Controlling — track progress against the plan and manage any changes — runs in
parallel with Executing.
• Closing — hand over deliverables, close contracts, and formally end the project.
 1.8.2 The Project Life Cycle and Selection Methods

Every project passes through four stages and must be selected using financial or non-financial methods before
it can proceed.
FOUR LIFECYCLE STAGES
• Stage 1 — Initiating and Defining — the project idea is approved at senior level, the PM is appointed,
and the team is assembled based on the skills required.
• Stage 2 — Planning — detailed objectives, schedules, budgets, resources, and risks are all identified and
documented before work begins.
• Stage 3 — Executing and Controlling — the work is implemented while the PM monitors progress and
corrects any deviations from the plan.
• Stage 4 — Delivering and Closing — deliverables are handed over to the client, lessons learned are
recorded, resources are released, and the project is formally closed.
PROJECT SELECTION METHODS
• Payback Analysis — measures how long it takes to recover the money invested. Formula: Payback =
Initial Investment / Net Annual Cash Inflows. Shorter payback = better. Limitation: ignores the time value of
money and any cash flows generated after the payback point.
• Net Present Value (NPV) — calculates the value of all future cash flows in today's money, then subtracts
the initial cost. Rule: NPV >= 0 means accept the project; NPV < 0 means reject it. When choosing
between two projects, pick the one with the higher NPV.
• Internal Rate of Return (IRR) — finds the percentage return the project will generate. If the IRR is above
the organisation's required hurdle rate (e.g. 15%), the project is viable. Uses the same formula as NPV but
solves for the discount rate instead of the value.
• Weighted Scorecard — a non-financial method that scores and ranks projects based on both financial
and qualitative criteria such as strategic fit, risk level, and resource availability — useful when numbers
alone don't tell the full story.

1.9 Summary

Projects are the most efficient way to manage change in organisations — understanding PM concepts,
structures, constraints, and lifecycles is the foundation for everything that follows in this module.
Unit 2:

UNIT 2 — EXAM CHEAT SHEET

Project Integration Management

2.1 Introduction

Unit 2 is about how a PM ties all parts of a project together — from creating the charter that kicks off the project,
to writing the plan, executing the work, controlling changes, and closing down.

2.2 What is Project Integration Management?

Project Integration Management means making sure all the different parts of a project — people, tasks, plans,
and processes — work together smoothly toward one goal. Think of it like an orchestra conductor: each
musician plays their own part, but the conductor ensures everything plays together in harmony.

5 LEVELS OF INTEGRATION
• Process integration — making sure all project tasks and workflows are coordinated and do not conflict
with each other. Example: ensuring procurement happens before the installation team needs the
equipment.
• Skills integration — combining both hard skills (scheduling, budgeting) and soft skills (leadership,
communication) to meet the triple constraints of time, cost and scope.
• Strategic integration — ensuring the project's goals align with the organisation's broader strategy.
Example: a company expanding into new markets only approves IT projects that support that goal.
• Context integration — staying aware of external developments that could affect the project, such as new
technologies, regulations, or market trends.
• Complexity integration — carefully managing the interactions between people and processes, since
projects are complex by nature and small changes in one area can ripple into others.

2.3 Project Charter

The Project Charter is the official document that formally starts a project. It appoints the PM, gives them the
authority to use organisational resources, and provides a high-level overview of what the project is, why it
exists, and what it will cost.

• Think of it as the project's birth certificate — without it, the project does not officially exist. —
• Written during the Initiating Phase — falls under the Integration Knowledge Area. Usually the PM writes
it on behalf of the sponsor.

Section 1 Project Title

• Purpose — Gives the project a name so everyone refers to it consistently.

• Why it matters — Some organisations use code names to protect the idea and create team identity
before launch.
• Example — "Project Phoenix" — the internal name for a company's new e-commerce platform before it
goes public.

Section 2 Purpose / Justification (Business Case)

• Purpose — Explains WHY this project needs to exist — what problem it solves or opportunity it captures.
• Why it matters — Decision-makers need to understand the business reason before approving budget and
resources.
• Example — "Customer complaints about slow checkout have increased by 40% — a new payment
system will reduce cart abandonment and increase revenue."

Section 3 High-Level Description (Scope Statement)

• Purpose — A brief overview of WHAT the project will produce or deliver — describes the end result.
• Why it matters — Sets shared expectations early so everyone agrees on what is being built before
detailed planning begins.
• Example — "Deliver a fully functional mobile banking app for Android and iOS with login, balance view,
and payment features."

Section 4 What the Project Must Deliver (Scope of Work)

• Purpose — Expands on the Scope Statement — describes HOW the work will be done to achieve the
deliverables.
• Why it matters — Provides enough detail for the PM to begin planning tasks and assigning resources.
• Example — "Design UI, develop backend API, integrate with existing banking system, conduct security
testing, and deploy to app stores."

Section 5 High-Level Budget Estimate

• Purpose — A rough estimate of what the project will cost, based on past experience or similar projects.
• Why it matters — Helps the organisation decide if the project is financially viable before committing fully
— not a detailed budget, just a high-level sense check.
• Example — "Estimated total project cost: R850,000 based on a similar app delivered in 2022."

Section 6 Project Duration

• Purpose — An estimate of how long the project will take from start to finish.
• Why it matters — Organisations need this to plan cash flow, allocate staff, and schedule other dependent
projects around it.
• Example — "Estimated duration: 9 months — start 1 March, target launch 30 November."

Section 7 Critical Milestones

• Purpose — Key checkpoints or deadlines that must be hit during the project — they are non-negotiable
anchor points.
• Why it matters — Milestones keep the project on track and allow stakeholders to measure progress at
key stages.
• Example — "App prototype complete by 30 May | Security testing sign-off by 31 October | App store
submission by 15 November." Missing 31 October means the launch date cannot be met.

Section 8 Potential Risks

• Purpose — A list of things that could go wrong (or present opportunities) during the project.
• Why it matters — Decision-makers need to be aware of risks before approving the project so they can
make informed choices and forces early risk thinking.
• Example — "Risk: key developer may leave mid-project. Risk: integration with legacy banking system
may take longer than estimated. Risk: app store approval may be delayed."
 Section 9 Stakeholders

• Purpose — A list of all people or groups who will be affected by or have an interest in the project.
• Why it matters — Identifying stakeholders early ensures no important party is left out of communication or
decision-making, which could cause problems later.
• Example — "Sponsor: CFO | End users: Bank customers | IT department | Compliance/Legal team | App
store platforms (Apple/Google) | Marketing team."

Section 10 Criteria for Success

• Purpose — Defines exactly what done and successful looks like — the measurable standards the project
must meet to be signed off.
• Why it matters — Without agreed success criteria, the sponsor and PM may disagree at closure on
whether the project was a success. This prevents disputes.
• Example — "App delivered on time and within budget | Achieves 4-star app store rating within 30 days |
Reduces checkout time by at least 20% | Zero critical security vulnerabilities at launch."

Section 11 PM's Level of Authority

• Purpose — Clearly states how much power the PM has to make decisions about scope, time, cost, and
quality without needing further approval.
• Why it matters — Without this, the PM may be challenged or overruled at key moments, causing delays
and disputes about who can approve what.
• Example — "The PM may approve budget variations up to R10,000 without sponsor sign-off. Any scope
changes must be submitted via a formal change request to the sponsor."

2.4 Developing a Project Plan

The Project Plan is a single master document that combines all smaller plans into one. It expands on the Project
Charter and becomes the blueprint for how the project will be executed, monitored, and controlled. It is a live
document — updated throughout the project as things change.

THE 6 COMPONENTS OF A PROJECT PLAN

• Resource-Constrained Schedule — the master schedule combining scope, cost, and time data — the
backbone of the project plan. Example: a Gantt chart showing all tasks, who owns them, and when they
must be done.
• Communication Plan — documents who needs what information, when they need it, and how it will be
delivered. Example: weekly status reports emailed to the sponsor every Friday at 4pm.
• Quality Plan — defines the quality standards deliverables must meet and the processes to ensure
compliance. Example: all software must pass a code review before being merged into the main build.
• Human Resource (HR) Plan — documents team roles, responsibilities, required skills, reporting lines,
and training needs. Also covers how staff transition in and out of the project. Example: the lead developer
reports to the PM and will return to the IT department after go-live.
• Procurement Plan — documents how suppliers and contractors will be selected, managed, and paid.
Example: three quotes required for any purchase over R5,000; all vendors evaluated on price, quality, and
delivery time.
• Risk Response Plan — documents identified risks, their likelihood, impact, and planned responses.
Becomes the Risk Register used throughout the project lifecycle. Example: if the key developer leaves, a
weekly handover document ensures another developer can take over immediately.

2.5 Direct and Manage Project Work

This is where the actual work happens — the PM takes the approved project plan and leads the team in
executing it. Covers day-to-day management of tasks, resources, and any approved changes during the
Executing phase.

KEY POINTS
• What the PM does here — assigns tasks, removes blockers, ensures deliverables are being produced
according to plan, and implements any approved changes.
• Runs during — the Executing phase of the project lifecycle.
• Example — the PM holds daily standups, tracks who is working on what, and escalates when a developer
is stuck waiting for compliance sign-off — keeping the project moving forward.

2.6 Monitor and Control Project Work

This process runs at the same time as execution — while the team is doing the work, the PM is simultaneously
tracking progress, comparing it to the plan, and reporting to stakeholders. Think of it as the project's early
warning system.

KEY POINTS
• What it tracks — is the project on schedule? Is it within budget? Is quality being maintained? Are
forecasts still accurate?
• Runs in parallel — with the Executing phase — it does not wait until the end to check progress.
• Example — the PM checks a weekly report and notices a task planned for 5 days has taken 7 with no sign
of completion — they immediately investigate and adjust schedule or resources before it affects a
milestone.

2.7 Perform Integrated Change Control

A formal process for reviewing, approving or rejecting any changes to the project. All change requests — no
matter how small — must go through this process to prevent uncontrolled scope creep. Verbal change requests
are never acceptable — everything must be documented.

THE 6-STEP CHANGE CONTROL PROCESS

• Step 1 — Evaluate performance — continuously compare actual project progress against the Scope
Baseline to detect problems or gaps early.
• Step 2 — Identify the need for change — four triggers exist: project is off plan (corrective action), project
is heading off plan (preventative action), a deliverable is wrong (defect repair), or new ideas arise
(updates).
• Step 3 — Generate a Change Request — any team member or stakeholder can raise a change, but it
must be submitted on a formal Change Request Form documenting the proposed change, justification,
and impact on scope, cost, time, and quality.
• Step 4 — Submit to sponsor or Change Control Board (CCB) — the request is reviewed by the
sponsor/client or by a CCB — a group of senior people who meet regularly to approve or reject change
requests across all projects.
• Step 5 — Change is accepted or rejected — if approved, it moves forward for implementation. If
rejected, it is still recorded for reference. It may also be sent back for revision and resubmission.
• Step 6 — Update the Baseline Plan and implement — once approved, the project plan is updated to
reflect the change, the PM communicates it to the team, and the updated plan becomes the new baseline.

CHANGE REQUEST FORM CAPTURES

• Project name, reference number, who raised it and the date. —
• Description of the proposed change and its justification. —
• Impact on scope, cost, time, quality, and risks — and impact if NOT implemented. —
• Approval signature and follow-up confirmation that the plan and documentation were updated. —
 2.8 Project Closure

Project Closure is the final phase — it formally ends the project once all deliverables have been accepted. It is
often neglected but is just as important as every other phase, because it protects the organisation's knowledge
and frees up resources for the next project.

WHAT HAPPENS DURING CLOSURE

• Record and archive all project documents — contracts, plans, reports, and decisions are stored so the
organisation can reference them in future projects.
• Make final payments — all outstanding invoices to suppliers and contractors are settled and contracts
are formally closed.
• Release resources — team members are reassigned to new projects or return to their departments;
equipment and software licences are returned or cancelled.
• Capture lessons learned — what went well and what went wrong is documented. Example: integration
testing took twice as long as planned — future projects should allocate more time for this phase.
• Write the formal project review report — a written summary of the project's performance against its
original scope, budget, timeline, and quality criteria.

2.9 Summary

Project Integration Management ensures all processes, people, and plans work together as one. From the
charter that starts it, to the plan that guides it, to change control that protects it, and closure that ends it —
integration is what keeps a project from falling apart.