1 PROJECT MANAGEMENT: spec/ initiation

Project (general concept)

A temporary endeavour undertaken to create a unique product, service or result, with a defined start and end — distinct from ongoing, repetitive business operations (business-as-usual). Needs managing because it involves coordinating limited time, cost and resources under uncertainty to achieve a specific goal.

Why does project success depend on how success is defined and monitored?

• Success must be agreed and defined UP FRONT (during initiation) so there is a baseline to monitor against — otherwise there's no fair way to judge progress or the final outcome.

• Also distinguish two levels: PROJECT success (on time/budget/scope — the iron triangle) vs PRODUCT/BUSINESS success (did the benefits actually materialise once in use). A project can hit one and miss the other.

Output (Deliverable)

The tangible thing the project physically produces (e.g. a working mobile app; a trained ML model).

Outcome

The change in behaviour, state or capability that results from people actually USING the output (e.g. staff adopt the app; energy usage falls).

Benefit

The measurable positive value gained from the outcome, usually tied to the business case (e.g. £2,000/month saved; higher satisfaction).

Objective

A specific, agreed target the project sets out to achieve — should be written SMART.

(Specific, Measurable, Achievable, Relevant, Time-bound)

Producing the output does not guarantee the objective is met if the outcome/benefit doesn't follow (e.g. building an app nobody adopts).

Exam trap: outputs disguised as objectives

Poorly-written objectives/user stories often just restate an OUTPUT (e.g. "build an app", "make the front-end user-friendly") instead of a measurable target linked to outcome/benefit. Past papers ask you to spot this and rewrite it properly — always check which of the four categories (output/outcome/benefit/objective) a given scenario statement really belongs to.

SMART Objectives

A framework for writing objectives so they are: Specific, Measurable, Achievable, Relevant, Time-bound. Common exam trap: forgetting Time-bound — an objective without a deadline is not fully SMART.

Worked SMART example

Bad: "Perform parameter-tuning to optimise the algorithm accuracy" (no metric, no deadline). SMART rewrite: "Increase recommendation click-through rate from 4% to 6% within 3 months, by tuning model hyperparameters." When rewriting vague objectives in an exam, invent a plausible number/date and STATE your assumption clearly — examiners give credit for reasonable, clearly-stated assumptions.

SMART Objective vs KPI vs User Story

SMART objective = a specific, one-off target set for the project (has a deadline).

KPI = an ongoing performance metric, often tracked after go-live, used to monitor whether benefits are being sustained.

User Story = requirement written from a stakeholder's perspective ("As a [user], I want… so that…"), useful for Agile/Scrum but doesn't have to be measurable/time-bound like SMART. Be ready to contrast these three formats and explain when each is appropriate.

MoSCoW Prioritisation

Prioritises requirements into: Must have (non-negotiable), Should have (important, workaround possible), Could have (desirable, low impact if dropped), Won't have (this time) (explicitly out of scope). Used when constraints are fixed (e.g. fixed deadline) — pairs with the iron triangle: if time is fixed, MoSCoW tells you which scope to drop first.

The Iron Triangle

The three core constraints — Time, Cost and Scope — trade off against each other, with Quality often shown as affected in the centre. Changing one constraint (e.g. less time) puts pressure on the others (e.g. more cost, less scope, or lower quality).

Why is the Iron Triangle useful to a Project Manager?

It forces explicit trade-off decisions and gives the PM a tool to communicate that stakeholder requests are never "free" — something else must give. It also supports structured negotiation when constraints change mid-project (e.g. scope creep, a moved deadline).

Using the Iron Triangle to compare suppliers/methodologies

A common exam pattern gives you 2-3 suppliers/methodologies (e.g. Waterfall = fixed scope, variable time/cost; Agile fixed-price = fixed time & cost, variable scope; FDD = pay-per-feature, variable cost & time). Use the iron triangle explicitly to state which constraint each option prioritises FIXING, and which constraint is left to flex as a result — this is the "apply it" answer examiners want, not just naming the triangle.

5 PMBOK Process Groups

Initiating, Planning, Executing, Monitoring & Controlling, Closing — the "WHEN" dimension; every PMBOK process falls into one of these five stages.

10 PMBOK Knowledge Areas

Integration, Scope, Schedule (Time), Cost, Quality, Resource, Communications, Risk, Procurement, Stakeholder — the "WHAT" dimension. You do NOT need to memorise the 49+ individual processes, just the KA/PG structure and roughly what each covers.

Mapping a scenario step to PMBOK (worked example)

"You've received a Project Mandate and must produce a Charter" → Knowledge Area: Integration Management. Process Group: Initiating. This mapping-a-scenario-step-to-KA/PG format is a very typical exam question — practise it for a few other steps too (e.g. building a risk register = Risk Management, Planning).

PMBOK vs PRINCE2 vs Waterfall — don't confuse them

• PMBOK is a broad, methodology-agnostic body of knowledge/toolkit spanning 10 KAs — it is NOT the same as Waterfall and can be applied iteratively.

• PRINCE2 is a prescriptive, process-based method with defined roles/stages. Business Case: in PMBOK it's an input used to develop the Charter (checked once at Initiation); in PRINCE2 it's a continuously reviewed theme, re-checked at every stage boundary (continued business justification) — the board can stop the project if it's no longer viable.

Project Mandate

A brief, high-level trigger document from senior management authorising a project idea to be investigated — produced before detailed planning.

Project Charter

• The formal document that authorises the project to PROCEED and gives the PM authority to apply resources. Produced in Initiating; authorised by the sponsor/project board — NOT the PM themselves.

Typical contents: high-level objectives/success criteria, named PM and authority level, key stakeholders/sponsor, high-level budget/timeline/assumptions, link to the business case.

Why does the Charter help ensure project success?

It gives the PM formal authority to act, creates a single agreed reference point for scope/objectives (reducing later disputes), and formally links the project back to its business case/justification.

Power/Interest Grid

Plots stakeholders by POWER (ability to influence) vs INTEREST (how much they care), giving 4 strategies:

[Keep Satisfied (high power, low interest) | Manage Closely (high power, high interest)]

[Monitor (low power, low interest) | Keep Informed (low power, high interest) ]

Why use the Power/Interest Grid rather than treating all stakeholders equally?

Engagement effort is limited, so it must be prioritised — e.g. a high-power/low-interest exec still needs enough communication to stay satisfied, or they could block the project later even without actively following it day-to-day.

Applying the grid to named stakeholders (exam pattern)

Past papers give short bios (e.g. a senior leader, an experienced lecturer, a student rep) and ask you to place + justify each. Power usually comes from seniority, budget control, or decision rights. Interest usually comes from how directly/day-to-day someone is affected. Always justify WHY, don't just label the quadrant.

Managing disengaged or resistant stakeholders

A stakeholder who seems disengaged in a meeting (e.g. checking emails) signals their perceived interest or the communication approach needs addressing — not that they should be ignored. Contrast this with a stakeholder who could actively resist/negatively influence the project (needs closer management/persuasion) vs one already positively engaged (needs to be kept informed and their support maintained, not taken for granted).

Why is the Iron Triangle used, and how does it help a PM make decisions?

It's used because time, cost and scope are physically linked — you cannot change one without pressuring the others, so the PM needs a shared mental model for that before problems arise. It helps decision-making by turning vague stakeholder pressure ("just add this feature", "can we hit an earlier date?") into an explicit trade-off conversation: the PM can say exactly which other constraint will move, and by roughly how much, instead of silently absorbing the request into unpaid overtime or hidden quality loss.

Implications of treating Time/Cost/Scope as fixed vs flexible

Fixing a constraint doesn't remove its cost — it just forces the pressure onto whichever constraint is left flexible.

• Fixed time + fixed scope → cost must flex (overtime, more staff).

• Fixed cost + fixed scope → time must flex (later delivery).

• Fixed time + fixed cost (e.g. an agile fixed-price contract) → scope/quality must flex instead.

The implication for a PM: before agreeing to fix two constraints, you must already know which one is being sacrificed — agreeing to "fix everything" just hides the trade-off rather than removing it.

Why might a well-written SMART objective still fail to deliver real business benefit?

SMART only checks that an objective is well-FORMED (specific, measurable, achievable, relevant, time-bound) — it doesn't check that hitting the target actually causes the intended outcome/benefit. E.g. "increase app downloads by 20% in 3 months" is fully SMART but could be hit via a marketing push with no lasting adoption, so the outcome (people actually using it) and benefit (reduced support calls, etc.) never materialise. This is the output/outcome/benefit/objective chain breaking further down the line — SMART protects against a badly-written target, not a badly-chosen one.

How does misjudging a stakeholder's position on the Power/Interest Grid create project risk?

Each quadrant implies a specific engagement effort level, so misjudging power or interest means applying the wrong level of engagement.

• Underestimating someone's POWER (treating a high-power stakeholder as low-power) means they're neglected until they unexpectedly block or derail the project later.

• Underestimating someone's INTEREST (treating a high-interest stakeholder as low-interest) means they're kept in the dark, get blindsided by decisions, and lose trust or become resistant.

Either error surfaces as a late-stage crisis rather than a problem the PM had visibility of early.

Why does PMBOK separate 'authorising' (mandate/charter) from 'planning' — what could go wrong if skipped?

Separating them ensures the project is formally justified and has a named, authorised PM with agreed high-level scope/objectives BEFORE detailed, resource-intensive planning work begins.

If this step were skipped (planning started straight from an informal idea), the project could invest significant planning effort into something:

• never properly authorised or funded,

• with no agreed success criteria to plan against,

• no clear decision-making authority if disputes arise, and

• no traceable link back to a business case

— making it far harder to justify or defend the project if challenged later.

A business case is …

the document that justifies why a project should go ahead — setting out the problem/opportunity, costs, expected benefits, and options considered, to show the investment is worth it.

PMBOK

The Project Management Body of Knowledge — a broad, methodology-agnostic framework published by the Project Management Institute (PMI), organised into 10 Knowledge Areas and 5 Process Groups, comprising 49+ individual processes each with defined inputs, tools/techniques, and outputs.

PRINCE2

PRojects IN Controlled Environments — a prescriptive, process-based project management method structured around 7 Principles (guiding obligations a project must all follow), 7 Themes/Practices (aspects continuously addressed throughout, e.g. Business Case, Risk, Quality), and 7 Processes (sequential stages guiding the PM through the project lifecycle, e.g. Starting up, Initiating, Closing).

A stakeholder is

any individual, group, or organisation that can affect, be affected by, or perceive itself to be affected by a project's decisions, activities, or outcomes.

How to manage stakeholders using power interest grid?

Manage Closely (High Power, High Interest)

• Regular one-to-one or small-group meetings, not just group updates

• Involve them directly in key decisions before they're finalised, not after

• Give them a seat at major milestone reviews / steering committee

• Escalate issues to them early, before they become crises

• Example: weekly steering committee briefing with the project sponsor

Keep Satisfied (High Power, Low Interest)

• Concise, infrequent updates — a short summary, not a detailed report they didn't ask for

• Flag only significant risks or decisions that need their sign-off

• Avoid over-communicating — too much detail here can actually irritate rather than reassure

• Make sure they feel informed enough that they wouldn't be blindsided if something went wrong

• Example: a one-page monthly exec summary rather than full project documentation

Keep Informed (Low Power, High Interest)

• Regular, more detailed updates — they want depth, even if they can't influence direction much

• Use them as a source of feedback/testing, since their interest often comes from being close to the work

• Newsletters, demo sessions, or open Q&A slots work well here

• Example: inviting them to Sprint Reviews so they see progress firsthand

Monitor (Low Power, Low Interest)

• Minimal effort — general, infrequent communication (e.g. a newsletter or public update)

• Don't ignore entirely — periodically check whether their power or interest has changed

• Avoid spending scarce PM time/attention here that's better used elsewhere

• Example: an occasional all-staff email, no dedicated engagement plan