All posts

The big rules of project management, seen by a PM

June 12, 2026

A project rarely goes off track all at once, it slips: a vague deliverable, an untreated risk, a skipped review. The rules that make a project predictable.

Gestion de projetPlanningMéthode
The big rules of project management, seen by a PM

We imagine the project manager as someone who “follows” a plan. That’s incorrect. A good PM doesn’t follow, they anticipate: they lock in the scope, manage the charge and budget, address risks before they become problems, and communicate on a regular rhythm. The rest is just a tool. A project rarely goes off the rails all at once. It slips, and the delay becomes structural.

framing before running

It all starts with a clear scope. Before the first task, you need a starting contract: objectives, milestones, deliverables, and their valuation. This is the role of a technical and financial proposal, not a vague estimate but a real breakdown of the work. A project that starts without a locked-in scope doesn’t slip up: it was never framed.

planning at the right granularity

The most common mistake is to detail everything from the start. You waste time updating tasks whose content you don’t know, the data becomes unreadable, and you can’t see the risks. The opposite rule applies: detail the current phase finely, stay high-level on the next one, add detail as the view becomes clearer. The planning follows the project, it doesn’t guess it six months in advance.

The structure depends on the project’s topology. A simple sequential project is organized into groups (spec, design, prod, validation). A complex project puts detail into dedicated work packages, connected to groups by integration tasks and milestones. A center of expertise is managed by sprints.

two levels of planning, not one

One tool is not enough. You need a high-level plan (like MS Project) that carries the vision, decisions, and impacts, and a daily plan (a planner, a weekly review) that goes into the tasks of the day. The first answers “where is the project going”, the second answers “what are we doing this week”. Confusing them means either getting lost in details or piloting blindly.

meaningful milestones

Not all milestones are equal. The ones that matter are project milestones (design reviews, prototype availability) and client milestones (deliveries, demonstrations, Go/No-Go). These are the ones that pace progress, because they unlock the next steps and commit. A readable plan highlights these milestones rather than drowning the pilot in a thousand micro-tasks.

managing charge and budget, with a margin

A plan is not a promise, it’s a reference against which you measure reality. The discipline is to follow the gap between planned and actual, on both charge and budget, and to react early. Technical reflex helps: knowing whether a task is driven by duration, effort, or resources changes how a modification propagates. Adding resources to a task doesn’t always speed it up, and a PM who doesn’t master this is lying to themselves about their deadlines.

risk is routine, not a document

Risk management is not done once at the start of the project to fill a box. It’s a living register: you identify, evaluate criticality, define a mitigation plan, and review regularly. A risk treated when it’s still small costs a decision. The same risk ignored becomes a problem, and an ignored problem becomes the delay that everyone sees too late.

communicating on a rhythm, and telling the truth

Piloting is done at a fixed pace: a weekly update where you state the actual progress, not the desired progress. And above all, honest reporting. A plan that turns red early is infinitely better than a green one that lies: the first gives time to act, the second turns an alert into a crisis. The courage to report bad news on time is a PM skill, not an admission of weakness.

the seven rules, in one sentence each

  1. No project without a locked-in scope.
  2. Detail the present, sketch the future.
  3. Two levels of planning: vision and daily.
  4. Highlight the milestones that unlock.
  5. Manage the actual gap against planned, react early.
  6. Treat risk while it’s still small.
  7. Fixed rhythm, honest reporting.

Nothing spectacular here, and it’s not specific to hardware: these rules apply to any project with stakes. The job is not to fill a plan, but to make it reliable. It’s less flashy than a stroke of genius, and much more effective.