Project Management & Team Coordination

When the day-to-day becomes a project

A project isn't reserved for big companies: it's simply a dated goal that doesn't fit in the routine. Onboarding nine clients, migrating software, organizing the archives, preparing tax season — Marc's firm lives on projects without calling them that, and therefore manages them like day-to-day work: from memory, out loud, with a "we'll see". The predictable result: forgotten steps, badly distributed workloads, and three weeks of final stress that a little anticipation would have avoided.

Project management has a bad reputation among small teams — complicated charts, heavy tools, meetings about meetings. Forget all that: what you need fits in four elements, all delegable. A plan that breaks the goal into dated, assigned tasks; a light tracking that detects delays before they hurt; regular communication to the team and the client; and a memory of the project that outlives the people. The previous chapters gave you each brick; this one assembles them.

From fuzzy to plan: the breakdown

Everything starts with turning the fuzzy goal ("onboard the nine files before the end of June") into a concrete plan. Describe the goal, the available team, the calendar constraints and what you know of the work to be done, then ask for the breakdown: phases, tasks, dependencies ("we don't configure before receiving the documents"), workload estimates and a proposed assignment. You won't approve everything — that's the point: a proposed plan gets critiqued in twenty minutes, where a plan to create from scratch gets postponed for two weeks.

Help me plan a project. Context: accounting firm, 4 people (me, my business partner, an experienced colleague, a junior arriving next month). Goal: onboard 9 new tradesperson client files before June 30, without degrading service to existing clients.
What each onboarding involves: document collection, creating the file in our software, taking over the accounting history, first client meeting, training the client on digital document submission.
Constraints: May 1 to 15 is blocked by tax deadlines; the junior won't be autonomous until after 2 weeks.
Produce:
1. A breakdown into phases with dated milestones
2. The task list per phase, with dependencies, workload estimate and proposed assignment
3. The 3 main schedule risks and a countermeasure for each
Format: a one-page summary plan, I want to be able to critique it point by point.

PROJECT — Onboarding 9 tradesperson files — deadline 06/30

Phase 1 — Collection (04/15 → 04/30) — milestone: 9 complete document files
  - Standard welcome email + document list ............ junior (reviewed: Marc)
  - D+7 reminders per chap. 5 workflow ................ junior
Phase 2 — Setup (05/02 → 05/25, excl. 05/01-15) — milestone: 9 files created
  - Software creation + history takeover .............. experienced colleague
  - Quality control by sample (chap. 4) ............... partner
Phase 3 — Launch (05/26 → 06/27) — milestone: 9 kickoff meetings done
  - Kickoff meetings .................................. Marc + partner
  - Digital submission training ....................... junior

Risks: late documents / May overload / junior not autonomous
Countermeasures: auto reminder D+7 / phase 2 shifted off deadlines / 2-week pairing

flowchart LR
  O["Fuzzy goal with deadline"] --> PL["Plan: phases, milestones, assignments"]
  PL --> EX["Execution by the team"]
  EX --> PT["Written weekly check-in in 3 questions"]
  PT --> SY["Summary and delay detection"]
  SY --> AR["Decisions by Marc"]
  AR --> EX
  SY --> CC["Monthly client communication"]

Tracking without status meetings

The plan then lives at the rhythm of a written progress check-in — the anti-meeting ritual from chapter 7, project edition. Every Friday, each person answers three questions in writing: what did I finish, what is in progress, what is blocking me. Five minutes per person. You paste the answers and the plan, and ask for the summary: progress per phase, gaps versus the milestones, blockages to arbitrate, and the two or three decisions that fall to you. On Monday, ten minutes of discussion suffice — only about the decisions, never about information gathering.

Here is the onboarding project plan: <paste the plan>.
And here are the team's written weekly check-ins this week: <paste the 4 answers: finished / in progress / blocked>.
Produce the progress summary:
1. Status per phase: ahead / on time / late, with the why in one line
2. The milestones at risk in the next 15 days
3. The reported blockages and, for each, a proposed solution
4. The 2-3 decisions that belong to me this week, phrased as closed questions
End with the 5-line paragraph I'll send the team: factual, encouraging, no corporate-speak.

Communicating: the team, the client, the rhythm

A project well managed but badly narrated ends up worrying everyone. Two regular communications suffice, both derived from the same weekly summary — the single-source principle from chapter 3. To the team: the Friday paragraph, factual and short, showing progress and naming difficulties without dramatizing them. To the group's clients: a reassuring monthly update — where things stand, what awaits them next month, what we need from them. The client who knows where their file is going doesn't call to ask: proactive communication is also a time saver.

Keep the chapter 3 drift rule in mind: both communications start from the same summary, so the facts in them are identical — only the angle and the level of detail change. A client from the group who runs into a team member must hear the same story as in their monthly email. A project's narrative consistency is accumulated trust.

Onboarding the new hire with living documentation

The junior arrives in the middle of the project — a classic, dreaded situation: all the knowledge is in people's heads, and every question she asks interrupts someone. The countermeasure already exists in your library: workflow checklists (chapter 5), document templates (chapter 3), monitoring and triage briefs. Ask for the assembly of an onboarding path: order these resources from simplest to most complex, generate for each a one-page "why we do it this way" explanation, and produce a first-week program with real tasks of increasing difficulty, each backed by the matching checklist.

The effect is twofold. The junior becomes productive in days rather than weeks, because she executes proven workflows instead of reinventing — the document reminder she sends in week 1 comes out as well calibrated as Marc's; the chapter 5 leveling promise comes true. And the firm discovers the holes in its documentation: every question from the new hire the library can't answer is a page to add. Onboarding a newcomer becomes the best audit of your system.

Handling the unexpected: when the plan meets reality

No plan survives contact with the field intact — and that's normal: a plan isn't for predicting, it's for detecting gaps early. Three weeks after launch, two tradespeople still haven't sent their documents despite the reminders, and the experienced colleague is out for a week. Rather than panic or improvise, Marc submits the situation to the plan: "here are the two gaps, propose three rescheduling scenarios with their consequences on the final milestone". In two minutes he gets what would have taken him an evening to build: shift phase 2 by a week, move two files to the partner, or accept a final milestone on July 7 — with, for each scenario, what to communicate and to whom.

It's the same principle as iteration in chapter 1, applied to steering: you don't redo the plan from scratch, you evolve it while keeping its full history. And every rescheduling is traced — dated version, reason for the change — so the end-of-project review almost writes itself: what was planned, what happened, what we'll remember for the next one. That retrospective, filed in the library, is the gift today's project gives to next year's project.

The pitfalls of the assisted project manager

First pitfall: the plan that's too pretty. A generated breakdown is always optimistic — it knows neither the tradespeople unreachable during building season nor the fatigue of May; systematically confront it with the field and keep margin on the milestones. Second pitfall: theatrical check-ins. If the Friday write-ups become communication exercises ("all good"), the summary will no longer detect anything; the team rule must be clear — a blockage reported early is help requested, never a fault confessed. Third pitfall: delegating the decisions. The summary proposes, the closed questions accelerate, but shifting a milestone, reassigning a person or calling an unhappy client — that's you. A project remains a matter of humans who trust each other; the tooling removes the friction, not the responsibility.