AfterDesk
EN
Apply

The toolkit

Project and task coordination

Coordination is the work of keeping other people's work moving: turning a goal into owned tasks with real dates, running a board that reflects reality, and telling a busy person the truth in ten seconds. This course covers dependencies, chasing, meeting notes, decision logs, risk, escalation, and the weekly rhythm that keeps a project honest.

9
lessons
~53
minutes
12
exam questions

Free · No paid tier · No certificate fee

After this course

Everything, and what is in it.

What coordination actually is

~6 min

The job in one sentence

Coordination is making sure that work other people are doing arrives, in the right order, before someone is waiting on it. You are not the person doing the design, the code, or the sales call. You are the person who knows what state each piece is in, who is waiting on what, and what will hurt if it slips. Most projects do not fail because someone lacked skill. They fail because two people each thought the other was handling something, or because a decision sat in an inbox for nine days and nobody noticed. Your value is that nothing sits unnoticed. Clients pay for that, because the alternative is a founder holding twelve threads in his head while also running a business.

You own the picture, not the work

You will rarely have authority over the people you coordinate. A developer does not report to you. A client's accountant does not answer to you. What you have instead is the clearest picture in the room and the habit of writing it down. That is more power than it sounds. When you can say that the launch page needs copy by Thursday because the developer blocked Friday for the build, the date stops being your opinion and becomes a fact everyone can see. Coordination without authority works when your picture is accurate, your updates are boring and regular, and you never surprise people. It stops working the moment the board says one thing and reality says another, because then everyone starts keeping private lists again.

Where projects actually die

Watch four failure points and you will catch most trouble early. Handoffs, where work leaves one person and nobody confirms the next person received it. Decisions, where everyone assumed a choice was made and nobody wrote it down. Waits, where a task is technically not late but has been sitting untouched for a week. Silence, where a person you depend on has not answered in days and you tell yourself no news is good news. None of these look dramatic on the day they start. They become a missed launch three weeks later. The whole craft is noticing them in the first week, while a two-minute message still fixes them.

Coordination on AfterDesk is different

Much of this course is about work you do for other clients, standing between several people and keeping them moving. On AfterDesk the shape is different, and it is worth being plain about it. Here an operator has already scoped and priced the task, and you never contact the client or anyone on their team. A coordination task in the pool is normally a deliverable about coordination: build the project plan, restructure the board, write the status report, produce the meeting notes and action list from a transcript. You produce the artifact, you note anything unclear for the operator, and you deliver. The thinking is the same. The chasing is not yours to do here.

Remember

  • Coordination is making other people's work arrive before someone is waiting on it.
  • You rarely have authority. An accurate written picture is what gives you weight.
  • Projects die at handoffs, unrecorded decisions, silent waits, and unanswered messages.
  • On AfterDesk you produce the coordination artifact; the operator handles all client contact.

Breaking a goal into tasks

~6 min

Start from the finished thing

Before you list a single task, write one sentence describing what exists at the end that does not exist now. A new pricing page, live, with three plans and a working checkout button. That sentence is your reference for every argument later. Without it, people add work that feels productive and nobody can say whether it belongs. With it, you can ask one question about any proposed piece of work: does this have to be true for that sentence to be true? If yes, it is a task. If no, it goes on a separate list called later. Write the sentence, then get the person who asked for the project to confirm it in writing. Half the scope arguments you will ever have are prevented right there.

A task is a verb and an owner

Write tasks as an action a specific person takes. Not pricing page, which is a topic. Write draft the copy for the three plan cards, Maria, Thursday 14 October. A topic cannot be finished. An action can. Three things belong on every task: what gets done, who does it, and when it is due. If any of the three is missing, the task is not real yet and will quietly rot. Avoid the word help. Maria helps with the launch is not a task, it is a feeling. If two people are genuinely involved, split it. Maria drafts, then Ben reviews. Two tasks, two owners, two dates, and a clear moment when the work passes from one hand to the other.

One owner, always

Every task gets exactly one name. Not the marketing team, not Maria and Ben. A task owned by two people is a task owned by nobody, and you will discover that on the day it was due. The owner is not necessarily the person doing all the work. They are the person who answers for it and who you talk to about it. If a client says the team will handle it, that is your cue to ask a polite question: who should I follow up with on this one? Nobody is offended by that question, and it saves you a week later. Write the name on the card, in the plan, and in the notes, so nobody has to remember it.

Size it so it can move

A task that takes three weeks tells you nothing until it is late. Break work into pieces that can plausibly be finished in a day or two. Small tasks give honest signal: when four of six are done, you know where you stand, whereas one large task sits at some invented percentage for a fortnight. There is a limit. Do not split so finely that maintaining the list costs more than the work. A useful test is whether you could tell, in one glance, that a piece is genuinely finished. If the answer needs a conversation, the piece is still too big, or the finish line has not been defined yet.

Say what done means

For every task that matters, write one line describing what finished looks like. Done for a research task might be fifteen companies in the sheet, each with name, website, contact email and source link, no blank cells. Done for a draft might be full text in the shared document, ready for review, no placeholders. This line takes twenty seconds to write and prevents the most common project argument, which is two people using the same word for different things. It also lets you check work without becoming the quality police. You are not judging taste. You are asking whether the thing you both agreed on is actually present.

Remember

  • Write one sentence naming what exists at the end. Every task must serve it.
  • A real task has an action, one owner, and a date. Missing any, it rots.
  • One name per task. Two owners means nobody owns it.
  • Break work into one or two day pieces so lateness shows early.
  • Write one line of what done means before the work starts.

Due dates and commitments

~6 min

A date you set is a wish

There is a real difference between a due date and a commitment. A due date is a number you typed into a board. A commitment is a specific person saying, in their own words, that they will deliver a specific thing by a specific day. Plans full of the first kind look organised and predict nothing. You can tell them apart with one question: did they say it, or did you? If you set the date and they merely did not object, you have a wish. Silence is not agreement, especially from someone senior, or from someone who was busy when you asked. Getting the words out of their mouth, in writing, is the highest value habit in this whole course.

How to ask for a real date

Do not ask can you do this by Friday, because the polite answer is yes and the true answer arrives on Monday. Ask when can you have this done, then stay quiet. If the date they give is too late, you now have a real conversation about priority or scope instead of a false agreement. Ask two follow up questions: what do you need from anyone else to hit that, and what would stop you. The first surfaces a dependency you did not know about. The second surfaces a risk while it is still cheap. Then repeat it back in one sentence so it is on the record. So you will send the draft by Thursday the ninth, once Ben sends the logo files.

Vague dates and time zones

Refuse vague dates gently. Next week, end of month and soon are not dates. Ask for a day, and write the calendar date beside the weekday, because Thursday means two different days in a long email thread. End of day is worse than it looks when you work nights and your client is on the other side of the world. Your end of day and theirs can be sixteen hours apart. Name the time zone, or name a moment that is unambiguous for both, such as before you start work on Tuesday. In every plan you keep, choose one time zone, write it at the top, and convert everything into it. Confusion about the clock has ruined more deadlines than laziness ever has.

Buffer belongs to the plan

People pad. Ask for two days and you get a five day estimate with three days of quiet insurance inside it, which you can neither see nor manage. It is healthier to take honest estimates and hold the buffer yourself, at the end of the chain, where you can watch how much is left. If the client needs the site live on the twentieth, plan to finish on the seventeenth and keep those three days as the project's cushion rather than sprinkling them invisibly. Say this out loud so nobody feels tricked. Give me your honest number, not a safe one, and I will hold the slack for all of us.

When a commitment slips

Commitments break. That is normal and not a moral failure. What matters is what happens next, and the rule you want everyone to know is simple: tell me the moment you know, not on the due date. A day of warning is often enough to reorder the work, while an unannounced miss costs everyone else their plan too. Model it yourself. When you are the one who will be late, send the message early, state the new date, and say what you did to limit the damage. People forgive slips they hear about in time. They stop trusting people who go quiet and hope.

Remember

  • A due date you typed is a wish. A commitment is words they said.
  • Ask when can you have this done, then stop talking.
  • Never accept next week. Ask for a date, and name the time zone.
  • Hold buffer at the end of the plan, not hidden inside each task.
  • Tell people the moment you know you will be late, not on the day.

Dependencies and the critical path

~6 min

What waits on what

A dependency is simply this. Task B cannot start, or cannot finish, until task A is done. The developer cannot build the page until the copy exists. The accountant cannot close the month until the bank statements are exported. Most schedule pain comes from dependencies nobody wrote down, so write them down. Beside each task, note what it is waiting for and who owns that. Then check the dates. If the thing you are waiting for is due the same day you need it, you have no room at all, and any small slip moves you. When you look at a plan for the first time, hunting for these waits is the fastest way to find where it is already broken.

The longest chain sets the date

Line your dependent tasks up end to end and one chain will be longer than the rest. That chain decides when the project can finish, and people call it the critical path. The term is worth knowing because clients use it, but the useful part is behavioural. Work on that chain is the work you protect. If something on it slips by a day, the whole project slips by a day, no matter how much other work you finished. Find the chain by starting at the finished thing and walking backwards, asking what had to happen immediately before this. When you reach the start, you have the spine of the plan and you know which tasks deserve your attention first.

Slack is where flexibility lives

Tasks that are not on the longest chain have slack. They could start late, or take longer, without moving the end date. That is genuinely useful information. It tells you where you can be relaxed, where to place work for the person who is stretched thin, and what you can safely postpone when something urgent lands. It also warns you about a trap. Push slack too far and a comfortable task quietly becomes critical, because no room is left. A weekly look at the plan should ask two questions. Is anything on the critical chain at risk, and has anything with slack used all of it up without me noticing.

The waits you do not control

The worst dependencies belong to other people: a client approval, a bank, a supplier, a legal review, a landlord. You cannot make these faster by working harder, so treat them differently. Start them as early as possible, even before you strictly need to. Ask up front how long they usually take and plan on the honest answer rather than the hopeful one. Give the other side everything they need in one message so there is no back and forth. Then track the wait visibly, with the date you asked and the date you were promised, because an approval sitting untouched for eleven days is a fact people respond to, while a feeling that it is taking a while is not.

Mapping it in a free spreadsheet

You do not need special software. In Google Sheets, use one row per task with columns for task, owner, start, days needed, due date and waiting on. Sort by due date and read the waiting on column from top to bottom. Anything waiting on a task with a later due date is an error you just found. If you want to see the chain, colour the cells of tasks that feed each other and follow the colour. Paid tools draw the arrows for you and are pleasant on large projects, but the thinking is identical, and a sheet you actually update beats a beautiful chart nobody has touched since the kickoff.

Remember

  • A dependency is one task that cannot start or finish until another is done.
  • The longest chain of dependent tasks sets the end date. Protect that chain.
  • Tasks off the chain have slack. Watch for slack quietly running out.
  • Start approvals and other people's waits early, and track how long they sit.
  • A sorted sheet with a waiting on column is enough to plan a small project.

Running a board that tells the truth

~6 min

Columns are a promise

Your columns should describe what actually happens to work here, not a generic template. For a content project that might be Brief, Writing, Review, Client approval, Published. The test of a column is that everyone agrees what it means for a card to be sitting in it. Keep the number small, because every extra column is another decision someone has to make when they move a card, and hesitation is how boards go stale. Two columns earn their place almost everywhere. Blocked, so waiting work is visible instead of hiding inside In progress, and Done, which means finished by the definition you wrote, not almost. If a card cannot be placed cleanly anywhere, the columns are wrong, not the card.

What belongs on a card

A card should let a stranger act without asking you anything. A title that is a verb, with a person's name. A due date. One line of what done means. Links to the files needed. The name of the thing it is waiting on, if any. Discussion stays in the card comments so the history sits with the work rather than in someone's private messages. Attachments matter more than people expect, because half the delay in small projects is somebody hunting for a file. If your card needs three paragraphs of explanation, either the task is too big or a decision has not been made yet, and you should fix that instead of writing more.

Blocked is a column, not a feeling

When someone cannot proceed, the card moves to Blocked and gains one line: what it is waiting for, who owns that, and since when. This is the single most valuable habit on a board. It converts a vague sense that things are slow into a short visible list that a decision maker can clear in one sitting. It also protects people, because a person sitting in Blocked is not idle or lazy, they are stopped, and now everyone can see the difference. Review the Blocked column first, every time you open the board, before anything else. The oldest card there is usually the most expensive thing in your project.

A stale board is worse than none

A board that reflects hope instead of reality is worse than no board, because people make decisions from it. Two habits keep it honest. First, you sweep it yourself on a fixed rhythm, at least twice a week, and anything that has not moved in five days gets a short direct question to its owner. Second, you make updating cheap for everyone else. Never ask someone for a status by message and then copy it onto the board yourself, because that teaches them the board is your hobby. Ask them to move the card, and thank them when they do. If people will not update it, use fewer columns and fewer cards until they will.

Free tools that are enough

The Trello free tier gives you boards, cards, checklists, due dates and attachments, which covers most small projects. The Notion free plan holds a board and the written material in one place. The Asana free tier supports task lists with owners and dates, and suits work that is a sequence rather than a flow. A Google Sheet is still a respectable choice, and often the right one when the client is not comfortable learning anything new. Choose what the client will actually open. A tool you love that they never look at gives you nothing. One rule holds across all of them: client project data lives only in the workspace they own or the one they told you to use.

Remember

  • Columns should describe what really happens, and be few enough to decide fast.
  • A card should let a stranger act: owner, date, done line, files, blocker.
  • Blocked is a column with a reason and a date, not a private feeling.
  • Sweep the board twice a week and question anything unmoved for five days.
  • Free Trello, Notion, Asana or a plain sheet all work. Pick what the client opens.

The status update people actually read

~5 min

Answer three questions in two lines

A busy person reading your update wants three things and will not scroll for them. Are we going to hit the date. What changed since last time. What do you need from me. Put those at the top, in that order, and put the detail underneath for the one reader in ten who wants it. The most common mistake is opening with a narrative of activity: this week I contacted the printer, followed up with Ben, and reorganised the folder. That tells the reader about your effort, not about their project. Effort belongs in a line at the bottom, if anywhere. Start with the answer, then the reason, then the evidence.

Use the status word plainly

Give the project one word and mean it: on track, at risk, or off track. On track means the agreed date still holds and nobody needs to do anything. At risk means something specific could move it, and you name what. Off track means the date has already moved, and you state the new one. Do not invent shades of green to soften bad news. A project that is at risk for three weeks and then suddenly off track destroys more trust than one that was honestly at risk from the start. If you find yourself writing mostly on track, stop, decide which of the three words is true, and write that instead.

Ask for exactly one thing

Most updates die because they ask for nothing, or ask for five things vaguely. Decide the single most valuable thing this reader can do, then ask for it with a date and a default. For example: I need your approval on the copy by Wednesday, and if I do not hear back I will proceed with version B so the build stays on schedule. That sentence gives them a decision, a deadline, and a way for their silence to still move the project forward. Do not bury the ask inside a paragraph. It goes on its own line, near the top, and it names the person if more than one is reading.

Same shape, same time, every week

Send it on the same day, at the same hour, in the same format, whether the news is good or bad. Predictability is most of the value. People stop asking for updates when they know one is coming, and they read yours quickly because the third line is always the same kind of line. Keep it short enough to read on a phone, roughly two hundred words, with any detail in a linked document instead of the message body. Never skip a week because nothing happened. Nothing happened is itself a status, and it usually means something is blocked, which is exactly what they need to know.

Remember

  • Open with the date, what changed, and what you need. Detail goes below.
  • Pick one word: on track, at risk, or off track. No softened shades.
  • Make one ask, with a date and a default if nobody replies.
  • Same day, same shape, every week, especially when the news is bad.

Chasing without nagging

~6 min

Track promises so memory does not

Keep one list of everything you are waiting on: what it is, who owes it, the date they gave, and the date you last asked. A sheet is fine. Without it you chase whoever you happen to remember at midnight, which means the loudest thread gets three messages and the quiet one is forgotten for a fortnight. With it, chasing becomes a ten minute routine at a fixed time rather than an anxiety you carry all day. It also changes how you sound. Someone who says I have you down for the supplier list, due Tuesday, last discussed on the fourth is not nagging. They are keeping the record, and people respond differently to that.

The first nudge is a service

Send the first reminder before the due date, not after, and make it a reminder rather than an accusation. One line, friendly, with everything they need attached. Quick note that the draft is due Thursday, the outline is in this document, tell me if the date is a problem. Half of all late work is not resistance, it is someone who lost the thread among forty other things, and your note rescues them. Never open with as per my previous email. Assume good faith for the first two contacts, because you are usually right, and because a relationship you burn on Tuesday still has to deliver on Friday.

Make the reply cheap

The easier you make it to answer, the faster answers come. Ask one question, not four. Offer options instead of open questions: can you still make Thursday, or should we move it to Monday. Attach the file rather than referring to it. Put the ask in the first line so it survives a phone preview. If you need a decision from someone senior, write it so the whole reply can be one word. Choose your moment too. A message that lands when someone starts their day gets read, while one that lands at the end of theirs gets postponed. If your night is their morning, that timing is an advantage you already have.

When to raise it, and to whom

Escalating is not telling on someone. It is asking a person with authority to unblock something that is costing the project. Do it after your own attempts have failed and before the damage lands, not the day after the deadline. Keep a clear order: a direct message, then a second one naming the consequence, then a mention in the status update everyone sees, then a private word with the person who can decide. Give one last chance before each step, and say so plainly. If I do not hear back by tomorrow I will flag this in Friday's update so the delay is visible. Most people move at that sentence.

Keep the tone flat and the facts exact

When you do raise it, describe the situation without adjectives. The logo files were due on the sixth. I asked on the fourth, the seventh and the eleventh. The build cannot start without them and the launch date is the twentieth. That paragraph is unanswerable because there is nothing in it to argue with. Compare it with Ben has been ignoring me for weeks, which invites a defence and turns a scheduling problem into a personal one. Never write anything about a person that you would not be comfortable having them read, because they usually do read it. Facts, dates, cost, and the decision you need. Nothing else.

Remember

  • Keep one list of what you are owed, by whom, and when you last asked.
  • Send the first nudge before the deadline, with everything they need attached.
  • One question, options instead of open ends, and the ask in the first line.
  • Escalate before the damage, after your own attempts, and warn people first.
  • State dates and costs without adjectives. Never write what you would not want read.

Meeting notes and decision logs

~6 min

Notes are for the people absent

Write notes for the person who was not in the room and has ninety seconds. That means no transcript. Capture three things: decisions made, actions agreed with an owner and a date, and open questions with the name of whoever will resolve them. Everything else is atmosphere. If a discussion went in circles for twenty minutes and landed nowhere, the note is one line saying no decision reached, to be settled by Maria before Friday, which is far more useful than four paragraphs of who said what. Write during the meeting, not after, because your memory of the exact date someone committed to is worse than you think.

Send them fast and invite correction

Send the notes the same day, ideally within the hour, while everyone can still recognise their own words. Speed is what makes notes authoritative. Whoever writes them first defines what happened. End with one line inviting correction, such as tell me by tomorrow if I have recorded anything wrongly. That sentence turns your notes from your version into the shared record, and it gives you cover, because a decision nobody corrected for a week is a decision. Put the actions in a short list at the top with names and dates, rather than buried in the discussion, so people find their own line in three seconds.

The decision log is separate and permanent

Keep a decision log apart from the notes. One running list with the date, the decision, who made it, and one line on why. It takes a minute per entry and it is the document clients thank you for months later, when somebody asks why we chose the cheaper supplier and nobody can remember. Reasons matter more than the decisions themselves, because circumstances change and you need to know whether the reason still holds. When a decision is reversed, do not edit the old entry. Add a new one saying what changed and why. A log you can trust is one where nothing is quietly rewritten.

What leaves the room

Meeting material is client data. Do not record without asking, and if you want to use a transcription or an AI tool, confirm in writing that the client permits it, because that content leaves their control the moment you upload it. On AfterDesk the rule is stricter and simpler. Client files never leave the task. You do not upload them to any third party service unless the brief tells you to, you do not keep copies after delivery, and you never use the notes or the board as a portfolio sample. Discretion is social as well. What someone said in frustration during a meeting does not belong in a note twelve people will read.

Remember

  • Capture decisions, actions with owners and dates, and open questions. Not a transcript.
  • Send notes the same day and invite corrections. The first written version becomes the record.
  • Keep a permanent decision log with dates and reasons. Never rewrite old entries.
  • Confirm permission in writing before recording or running client material through any tool.
  • On AfterDesk, client files never leave the task and are never portfolio samples.

Risks, escalation, and weekly rhythm

~6 min

A risk is not a problem yet

A risk is something that has not happened and would hurt if it did. An issue is something that has already happened. Keeping them apart matters because they need different responses. Risks get watched and prepared for. Issues get fixed and reported. Most teams keep no risk list at all, which means every risk is discovered on the day it becomes an issue. Yours can be five columns in a sheet: what could go wrong, how bad it would be, how likely it looks, what we would do about it, and who is watching it. If a risk cannot be described in one sentence, you do not understand it well enough to manage it yet.

Watch few risks, and watch them properly

Do not list forty risks, because nobody reads forty. Carry the three or four that would genuinely damage the project and review them every week. For each one, decide in advance what you would do, because a plan made calmly on Monday beats one made in panic on Thursday. Also decide the trigger, which is the observable thing that means this has stopped being a risk. If the supplier has not confirmed by the tenth, we order from the second supplier. Written triggers stop the slow drift where everybody can see trouble coming and nobody wants to be the one who calls it.

The shape of a good escalation

When you need help, send five short parts in this order. What is blocked, in one line. Since when, with the date. What it costs if it continues, in days or in money. The options you see, usually two or three with their trade-offs. What you recommend, and what you need from the reader. That last part is the one people forget, and without it your message reads as a complaint. Escalate early and small. A two day delay raised on day one is a scheduling question, while the same delay raised on day nine is a crisis with an audience.

The weekly rhythm

Projects stay honest on a rhythm, not on willpower. Pick a shape and keep it. Early in the week, review the board, confirm what is due, and send reminders for anything landing in the next few days. Midweek, check the blocked column and the risk list, and escalate anything that has not moved. Late in the week, sweep for stale cards, correct the plan so it matches reality, and send the status update. Then write down the one thing that must not slip next week. This costs about ninety minutes across a week and replaces the constant background worry that you have forgotten something.

What honesty costs and buys

The hardest moment in this work is the update where you have to write that the date has moved, or that you missed something. The instinct is to wait one more day in case it fixes itself. It rarely does, and the cost compounds while your credibility drains. Say it plainly, early, with what you are doing about it and without a paragraph of defence. Clients keep the people who tell them bad news in time, because that is the entire product they are buying: no surprises. Someone who reports a slipped date on Tuesday is worth more than someone whose projects look fine until the day they do not.

Remember

  • A risk has not happened yet. An issue has. Handle them differently.
  • Carry three or four real risks, each with a written trigger and a planned response.
  • Escalate with what is blocked, since when, the cost, the options, and your recommendation.
  • Keep a weekly rhythm: nudge early, check blockers midweek, sweep and report at the end.
  • Bad news delivered early is the product clients are actually buying.

Sit the exam

The courses are free. The work is real.

Twelve scenario questions. Pass at ten. Three attempts a day. The bar is the point.

No paid tier. No certificate fee. No upsell. Not now, not later.

Create a free account

You can start the first course tonight.

The curriculum

Everything, and what is in it.