9.2 Practical Project Management Tips That Work

Chapter 9.2 ← 9.0 Frequently Asked Questions

Practical Advice That Survives Contact With a Real Week

Most project advice is true and useless — it tells you to communicate clearly and manage risk, which you already knew. What follows is narrower on purpose: a short list of habits that are cheap to adopt, that hold up when the week goes sideways, and that you can start on Monday without asking anyone's permission.

Start with the habits that cost almost nothing

There is a rough trade-off behind every piece of project advice: how much effort it takes to adopt, against how much it actually changes. Plotting the common advice against those two axes sorts it quickly, and the sort is not what most people expect. The cheapest habits are usually the ones that matter most, and the expensive ceremonies are often the ones that quietly consume a team without moving anything.

Write the decision down the day it is made

Projects rarely argue about what was decided while the decision is fresh. They argue about it eleven weeks later, when the person who made it has moved on and three people remember three different versions. A decision log solves this so cheaply that its absence is hard to justify: one line per decision, with the date, the choice, who made it and the one-sentence reason.

The reason matters more than the choice. “We are using the existing payment provider” tells you nothing in November. “We are using the existing payment provider because switching needs a new contract and legal said six weeks” tells you exactly when the decision should be revisited — namely, when six weeks stops being a problem. Decisions without reasons cannot be reviewed; they can only be relitigated.

Where to put it does not matter much, as long as there is exactly one place and everyone knows it. A page in the project wiki works. A pinned document works. What does not work is the decision living in a chat thread, because chat has no memory anybody can search six months later with confidence.

Never let a task exist without a name on it

A task assigned to a team is assigned to nobody. This is not a comment about the team's character — it is how attention works. When four people can each see that a thing needs doing, each of them can also see three other people who could do it, and the cost of waiting is invisible while the cost of doing is not.

The fix is unglamorous: every open item has one named owner. The owner is not necessarily the person who does the work; the owner is the person who will be asked about it and who will feel mildly uncomfortable if it has not moved. Groups can do work. Only people own it.

The same rule at the end of meetings is the single highest-return habit in this entire tutorial. Before anyone leaves, say the actions out loud: who does what by when. Three fields. If you cannot fill all three for an item, you have not finished discussing it, and discovering that in the room is enormously cheaper than discovering it in a fortnight.

Say bad news early, while it is still small

Every project manager learns this the expensive way at least once. A task slips two days. You do not raise it, because two days is nothing and you expect to claw it back. Two days becomes a week. A week becomes the reason a downstream team misses their date. By the time it is unavoidable to mention, it is no longer a two-day slip — it is a two-day slip plus a month of you not mentioning it, and that second part is what people react to.

Raised early, a problem is information and the room is on your side. Raised late, the same problem is a surprise, and surprises make sponsors trust the reporter less — which makes the next report harder to believe, which makes the following surprise worse. The pattern compounds. Break it early and it never gets going.

Ask what would stop this, before you agree to a date

When someone gives you an estimate, the useful question is not “are you sure?” — that only invites padding or bravado. The useful question is what would have to be true for this to take twice as long? People answer that one honestly, because it is a question about the world rather than about their competence.

The answers are your risk register, arriving for free and phrased by the people closest to the work: if the test environment is not ready, if the client's data is as messy as last time, if I am pulled onto the other project again. Each of those is now something you can watch for, and half of them you can go and remove before they bite. This one question does more for a schedule than any estimation technique.

Plan to the level where more detail stops helping

There is a temptation, especially when you are anxious about a project, to plan your way out of the anxiety. It does not work, and it produces the specific failure in the bottom-right of the chart above: a plan so precise that reality invalidates it by Tuesday, and so laborious that nobody wants to update it, so it quietly becomes fiction that everyone still cites.

The workable rule is to plan the next few weeks in detail and the rest in outline, then fill in the detail as it approaches. Formally this is called rolling-wave planning, but the instinct is simpler: the further out something is, the less you know, and pretending otherwise is not rigour. A milestone six months away needs a name, an owner and a rough date. It does not need forty-one subtasks, all of which will be wrong.

The board is a mirror, not the method

Tools make work visible. They do not make it happen, and they do not make decisions. A project can have an immaculate board, colour-coded and fully groomed, and still be failing, because the board reflects whatever the team is actually doing — including drifting.

The useful test is whether the board changes anyone's behaviour. If the team looks at it and someone says “that column is getting long, what is stuck?” then it is doing its job. If the board is updated on Friday afternoon so that it looks right for a meeting, it has become a report, and reports do not run projects. When you notice this happening, the fix is almost never a new tool. It is usually a shorter, more regular look at the same one, together, with the people who own the items.

Ask the question you think is too obvious to ask

In most rooms, at least two other people do not understand the thing either, and everyone is waiting for someone else to admit it. As project manager you are in an unusually good position to be that person: nobody expects you to be the deepest expert on the technical detail, so “can you explain that in plain terms for me?” costs you almost nothing and routinely surfaces a genuine ambiguity that would otherwise have gone into the build.

A large share of project defects trace back to two people using the same word for two different things — “done”, “live”, “the customer”, “phase one”. Asking what a word means, out loud, at the moment it first gets used, is one of the highest-value things a project manager does and it never feels like work.

Protect the team's attention like it is the budget

The scarcest resource on most projects is not money or headcount. It is uninterrupted time from a small number of people who are also wanted by three other efforts. Every status meeting you call, every “quick question” you forward, every report you ask someone to write, is a withdrawal from that account.

So spend deliberately. Get status from the board rather than from a meeting where possible. Batch your questions instead of dripping them into someone's afternoon. Ask whether each recurring meeting still earns its place, and cancel one occasionally to find out. A project manager who reliably shortens meetings and absorbs interruptions is far more valuable to a delivery team than one who produces beautiful documents.

A workable weekly rhythm

None of the above needs a methodology. It fits into a week that looks roughly like this, and the whole thing costs perhaps ninety minutes.

• Monday, 20 minutes. Walk the board with the team. Not a status round — a look at what is stuck and who needs something from whom.
• Midweek, 30 minutes, unbooked. Go and unblock the two things you spotted on Monday. This is the actual job and it should have time in the calendar.
• Thursday, 15 minutes. Check the dates that matter against the plan. Anything moved? Anything you now know that your sponsor does not?
• Friday, 20 minutes. Write the short report: what moved, what is at risk, what you need a decision on. Update the decision log while the week is fresh.

Do that for a month and the difference is visible from outside. Not because any single item is clever, but because a project where decisions are recorded, owners are named and problems arrive early is a fundamentally different object from one where they are not.

How this looks in AB

Most of these habits map onto something concrete rather than onto discipline alone. In AB Projects, every task carries a single assignee field rather than a group, which makes the “one named owner” rule the default rather than something you have to enforce. Meeting actions can be created as tasks during the meeting itself, so the who / what / when leaves the room in written form instead of in people's memories.

The project wiki is the natural home for a decision log — one article, appended to, linked from the tasks it affects, and searchable long after the people involved have moved on. Comments on a task keep the reasoning attached to the work rather than scattered across chat, which is the difference between a decision you can review and one you can only argue about. And the board view gives you the ten-minute weekly walk without anyone preparing a status update for it, because the board is already the truth rather than a summary of it.

Terms used on this page

Decision log

A running record of the choices a project has made, each with a date, an owner and a short reason. It exists so that decisions can be reviewed later on their merits rather than reconstructed from memory. More →

Rolling-wave planning

Planning the near term in detail and the far term in outline, then adding detail as work approaches. It accepts that distant estimates are guesses rather than dressing them up as precision. More →

Risk register

The list of things that could go wrong, what each would cost, and what is being done in advance about the ones worth acting on. More →

Blocker

Anything that stops a piece of work progressing regardless of how much effort is applied to it — a missing decision, an unavailable environment, a dependency that has not arrived. More →

Sponsor

The senior person accountable for the project achieving its purpose, who owns the budget and is the escalation point for decisions beyond the project manager's authority. More →

Definition of done

The agreed, written standard a piece of work must meet before it counts as finished — the antidote to the word “done” meaning different things to different people. More →

Single source of truth

The one agreed place where the current state of the plan lives, so that disagreements are about the facts rather than about whose copy is newer. More →

Related reading