Becoming a project manager

A project is a temporary, coordinated effort where intention is turned into action to deliver defined objectives within agreed constraints. It is different from business-as-usual (BAU (business as usual)) — the ongoing running of things. Building a customer portal is a project; answering customer calls every day is BAU.

A project manager (PM) is the person accountable for getting the project delivered — planning the work, coordinating people, tracking progress, managing risks and changes, and reporting honestly. Crucially, the PM does not do all the work personally; the PM makes sure the right work happens, in the right order, with the right people.

Every project balances four things — an iron square: scope, time, cost and benefits. Change one and the others must move: squeeze the time or the budget and either scope shrinks or the benefits are put at risk. Benefits are the corner beginners forget — hitting the date and budget means nothing if the result doesn't deliver the value that justified the project. A large part of the PM's job is managing these trade-offs openly, not pretending you can add scope for free. All four corners are baselined at Green Light, so a change to any of them — benefits included — goes through a Change Request that weighs the impact on the rest.

Why a square, not a triangle? The traditional “iron triangle” has three corners — scope, time and cost — with quality held as the tension in the middle. That keeps you honest about delivering the thing, but a project can hit all three and still fail: on time, on budget and in scope, yet unused, or the promised saving never lands. Adding benefits as the fourth corner makes the value the project exists for an explicit constraint you manage and protect, not an afterthought. Quality doesn't disappear — it becomes the standard the deliverable must meet to realise those benefits.

Projects move through stages, and naming the stage you're in tells you what to focus on: an idea, approval to start, delivery, go-live, then closure. Pre-project — just an idea; nothing committed. Approval (“Green Light”) — the business case is approved and the project is baselined (scope, time, cost and benefits agreed as the reference point). Delivery — the work itself. Post go-live — handover to the business and checking the benefits landed.

A stage gate is a decision point where someone checks it's still sensible to continue before more money is spent.

A stakeholder is anyone who affects, or is affected by, the project — not just your team. Map them by interest and influence: manage the powerful-and-interested closely, keep the powerful-but-less-interested satisfied, keep the interested-but-less-powerful informed, and lightly monitor the rest. Getting the right people involved too late is a classic cause of failure — revisit your map as the project moves.

Requirements are what the solution must do. Scope is the boundary — what's in, and what's out. Vague scope is the root of most project trouble, so write it explicitly as “in scope” and “out of scope”. Scope creep is scope quietly growing without more time or budget; you manage it with change control, so every change is a visible, deliberate decision.

A plan is not a list of dates — it's a sequence of dependent work. A milestone is a significant checkpoint (“design signed off”). A dependency is when one task can't start until another finishes.

The critical path is the chain of dependent tasks that sets the earliest possible finish date. If any task on it slips, the whole project slips. Tasks off it have float (slack). “Plan to the critical path” means focusing your attention and resources on the things that actually move the finish.

Three things make estimates manageable. First, estimate in ranges, not single numbers — “three to five weeks” is more honest than “four weeks”. Second, estimate the work, then lay it on the calendar around dependencies and real availability — a five-day task rarely takes five calendar days. Third, treat every estimate as a forecast that improves, and never quietly pad it — put contingency where everyone can see it. You are not expected to be right first time; you are expected to be honest about the uncertainty.

Five things are worth tracking, remembered as RAID (plus a couple more): Risk — something that might happen and would hurt the project. Assumption — something you're treating as true but haven't confirmed. Issue — something that has already happened and needs fixing now. Dependency — a reliance on someone or something outside your control. Constraint — a fixed limit you must work within.

Log these as you go — an un-logged risk is one nobody is managing. Score risks by impact and likelihood, and escalate the big ones early.

Every project hits problems — that is normal, not failure. What separates good delivery from bad is how early they surface. Run towards a problem: name it, log it, and work the smallest useful next step. Escalating is not admitting defeat — it is asking for a decision or help above your authority, in time to act. The rule of thumb: escalate when a problem threatens the scope, time, cost, benefits or a deliverable and you cannot resolve it within your remit. Late escalation is the expensive kind.

Governance is how decisions get made and who is accountable. The golden rule is one accountable owner per project — clear accountability beats decision-by-committee. Forums decide and clear the path; they don't redesign the work. Project Sponsor — senior person accountable; chairs the SteerCo. Business Owner — owns the benefits and accepts the deliverables. Project Manager — runs day-to-day delivery. Steering Committee — the governance forum that makes key decisions. PMO (Project Management Office) — support and governance across projects; at enterprise/portfolio scale it matures into an EPMO (Enterprise Project Management Office).

Projects stall when decisions don't get made, or get re-made because no one remembers the first one. Good decision-making has three parts: be clear who owns the decision (one person), give them the options and a recommendation, and record the decision with its date and reason. A decision that is not written down will be relitigated. In SSLM every decision gets an ID and lives in the Decisions log and the meeting Minutes.

Report status honestly and on a regular rhythm. Two signals do most of the work: RAG (Red / Amber / Green — the current position) and Trend (improving / stable / declining — the direction). The purpose of a report is to prompt a decision, not to look good. The most dangerous status is a “watermelon” — green on the outside, red on the inside. Always report the real colour, and the worst relevant status rather than a comfortable average.

Meetings absorb a lot of a PM's time, so make them earn it. Only hold one when you need live, back-and-forth judgement — otherwise a written update or quick message is better. For the meetings you do hold: name the purpose in one sentence, invite only people with a role, send pre-reading ahead, and end by reading back every action, owner and due date.

Once scope, time, cost and benefits are agreed (“baselined”) at Green Light, changes to them go through a change request — a small, traceable decision — rather than happening quietly. A change to the target benefits is a baseline change too: it's assessed for its impact on scope, time and cost, just as those are tested against whether the benefits still hold. This isn't bureaucracy for its own sake: it protects the plan, keeps trade-offs honest, and means anyone can later see what changed and why.

Waterfall does the work in sequence (design, then build, then test). Agile delivers in small increments and adjusts as it learns. Hybrid mixes the two. A value stream is continuous delivery at larger scale. As a beginner, use whichever your organisation already uses — the fundamentals here apply to all of them.

Every project is justified by benefits: money saved, time saved, better service, or an obligation met. Baseline them at the start — in the Business Case at Green Light — and capture the “before” number before you change anything, so there's something to measure against. If the expected benefits change during delivery, that's a Change Request: assess what it does to scope, time and cost. At closure you review the benefit position and hand the ongoing measurement to the Business Owner — most benefits land after the project closes, so realisation is checked post-go-live. A saving only counts if someone actually banks it — freed time that's never redeployed is a benefit on paper only.

“Done” has to mean the same thing to everyone, or you'll hand over something the business rejects. Agree up front what “good enough for the purpose” looks like — the acceptance criteria — and who signs it off. Quality is not gold-plating: it is meeting the agreed standard, no less and no more. When tempted to polish past the agreed bar, ask whether it serves the purpose or just your pride in the work.

You don't need to be a finance expert, but you do need three numbers: the budget (what was approved), the actuals (what has been spent — from the finance system, not memory), and the forecast (your best view of the final cost). Watching the gap between forecast and budget is how you avoid a nasty surprise. Any change to the budget goes through a Change Request, never a quiet edit.

Most of the people delivering your project do not report to you, so you lead by influence, not command. A few habits carry you far: be clear about what you need and why; make it easy for people to say yes; give credit generously and take responsibility when things slip; listen more than you talk; and manage up as well as down, so your sponsor is never surprised. When you must say no, explain the trade-off rather than simply refusing.

Closing a project is a deliberate sequence, not a fizzle-out: first review the benefit position and confirm the baseline is captured for ongoing tracking, then consolidate the lessons learned, then hand over cleanly with nothing left dangling for the business to trip over. Lessons aren't written at the end — they're captured in the Lessons Learned log throughout, because what's learnt in month two is forgotten by month nine, and many surface in the SteerCo and in dealings with other teams, vendors and clients. The best of them improve how the next project — and the PMO itself — works.