Project Management

Project management is the discipline of planning, executing, and closing a bounded piece of work — distinct from ongoing operations by having a defined start, end, and specific deliverable. This skill covers the core concepts common across methodologies; Agile Principles covers the agile-specific reasoning where a project is delivered iteratively.

The scope/schedule/cost triangle

Classically: scope, schedule (time), and cost are interdependent — fixing two determines the third, and quality suffers if all three are squeezed at once ("pick two"). A scope change request that isn't paired with a schedule/cost/quality conversation is the single most common way a project quietly fails: the work grows, nothing else adjusts, and the team absorbs the difference until it can't.

Core artifacts

• Charter — the document that authorizes a project: its purpose, objectives, sponsor, high-level scope, and success criteria. Exists so everyone can point to one place answering "why are we doing this."
• Work Breakdown Structure (WBS) — decomposes the deliverable into smaller, estimable, assignable pieces. The test of a good WBS item: can one person or small team estimate and own it without further breakdown?
• Schedule / critical path — the critical path is the longest chain of dependent tasks determining the minimum project duration; a delay on a critical-path task delays the whole project, while slack on a non-critical task doesn't (yet). Knowing which tasks are actually on the critical path — not just which look urgent — is what critical-path analysis is for.
• RAID log (Risks, Assumptions, Issues, Dependencies) — a single running list distinguishing what might go wrong (risk, not yet happened) from what has gone wrong (issue), what's being taken on faith (assumption), and what the project needs from outside itself (dependency). Conflating these categories is a common reason a status report reads as noise rather than signal.
• Status update — see Ways of Working for the general communication principles (headline first, acknowledge changes explicitly, a dedicated section for worries) that apply directly to project status reporting.

Risk management, briefly

For each identified risk: probability (how likely), impact (how bad if it happens), and a response — mitigate (reduce probability/impact), transfer (insurance, a contract clause, a third party), accept (do nothing, usually because cost of response exceeds expected impact), or avoid (change the plan so the risk no longer applies). A risk register that lists risks but never assigns an owner or a response is a list, not risk management.

Waterfall, agile, and hybrid delivery

• Waterfall — sequential phases (requirements → design → build → test → deploy), each substantially complete before the next starts. Favors predictability and up-front clarity; costly to absorb a late-discovered requirement change since it usually means re-entering an earlier phase.
• Agile (Scrum, Kanban, XP, …) — iterative delivery of working increments, welcoming change even late (see Agile Principles). Favors adaptability; needs a customer/product owner engaged throughout, not just at the start and end.
• Hybrid — common in practice: agile delivery inside a waterfall-style governance wrapper (fixed overall budget/deadline set up front, iterative execution within it), or a phased rollout where each phase is itself run iteratively. Neither purity is a virtue in itself — the right choice depends on how much the requirements are actually expected to change and how costly a late pivot would be.

Stakeholder management

Map stakeholders by influence and interest: high-influence/ high-interest stakeholders need active engagement and real input into decisions; high-influence/low-interest need to be kept satisfied with concise, infrequent updates; low-influence/high-interest need to be kept informed; low-influence/low-interest need minimal monitoring. Treating every stakeholder the same way — flooding the low-interest with detail, or under-communicating with the high-influence — is a common, avoidable cause of late-stage surprises ("nobody told me this was happening").

Common pitfalls

• Padding estimates without saying so — hidden buffers erode trust once discovered and make the schedule harder to reason about; if a buffer is needed, make it an explicit, visible contingency line, not a silent inflation of every task estimate.
• A RAID log nobody reviews — logging a risk is not managing it; a review cadence and an owner per item is what turns the log into an actual control rather than paperwork.
• Treating scope creep as a series of small favors — each individual addition looks minor; the cumulative effect on schedule/cost is what actually damages the project, which is why each addition needs to be logged and traded off, not just absorbed.
• Confusing activity with progress — a burned-down schedule or a full sprint doesn't mean value was delivered; tie status to the agreed deliverables/acceptance criteria, not to effort expended.
• Choosing a methodology as an identity rather than a fit — "we do Scrum" or "we do PRINCE2" as an unexamined default, rather than picking based on how volatile the requirements actually are and how the organization actually governs funding.

Learn more

• PMI: A Guide to the Project Management Body of Knowledge (PMBOK) — the widely-referenced (paid) standard.
• PRINCE2 — a widely-used structured, phase-gated methodology, common in UK/government contexts.
• Agile Principles — the reasoning behind iterative delivery specifically.
• Ways of Working — communication and team-operating norms that apply directly to running a project.