Running a Training Business in Asana, Monday or Trello: Where Project-Management Tools Break

Asana, Monday, Trello and ClickUp are good tools for managing projects, and a training business is not a project. They work for scheduling training up to roughly twenty sessions a month, and they break after that for a specific reason: a training session is not a task. It has an instructor with availability and qualifications, a client, a room, seats, a price and an invoice attached, and a project-management tool models none of that. Most training companies running on a PM tool are doing so because they do not know a training management system exists.

I know this because I did it. When DevelopIntelligence was small, our delivery schedule lived in a project tool with one board per client and one card per class. It was cheap, everyone already understood it, and it was genuinely better than the spreadsheet it replaced. It was also the thing that, two years later, had three people spending Friday afternoons reconciling cards against instructor emails and invoices. This piece is for anyone at that stage: a fair account of what these tools do well, a specific account of where they fail for training delivery, and a rough sense of when the switch pays for itself.

What Asana, Monday and Trello get right

It would be easy to write this as a takedown. It would also be wrong. Project management software for training companies is popular because it solves real problems, and it solves them well.

• Ownership is unambiguous. Every card has one assignee and one due date. When a class is a card, someone owns getting it delivered, and that alone is an upgrade on a shared inbox.
• Timelines are visible. Gantt and calendar views make a month of deliveries legible to someone who was not in the planning meeting.
• Templates cut setup time.A “new public course” template with its pre-course, delivery and follow-up subtasks means nobody forgets to send joining instructions.
• They are cheap and familiar. Your team already knows the tool, the free or low tier covers a small operation, and there is no implementation project. That is a real advantage, not a consolation prize.
• They are flexible. Custom fields, automations and integrations let a determined ops person model almost anything. That flexibility is exactly what keeps people on the tool longer than they should stay.

If you are running a handful of courses a month for one or two clients, stop reading and go back to your board. Nothing below applies to you yet.

Where project management tools break for training delivery

Every failure below traces back to the same root cause. A PM tool has one primary object, the task, and everything else is a field hanging off it. Training delivery has at least six objects that matter independently: the session, the instructor, the learner, the client, the venue and the invoice. When you flatten all of that into a card, the relationships between them are the first thing to disappear.

A session is not a task

A task is done or not done. A session has a capacity of twelve, nine registered, two on a waitlist, a client purchase order number, an instructor day rate, a venue booking, a materials shipment and an invoice that triggers on completion. You can add custom fields for all of that. What you cannot do is make the tool understand that when seat ten fills, the waitlist should move, or that when the session closes, the invoice should exist. The card holds the data. It does not act on it.

No instructor availability or conflict detection

This is the failure that costs the most. Asana does not know that Priya is already teaching in Manchester on the 14th when you drop a second card on her for London. It does not know she has not renewed the vendor accreditation the course requires. It does not know she asked for the 15th off. Someone has to know all three, and that someone is usually a coordinator with a very good memory and a growing sense of dread. Every double-booking I have seen at a training company running on a PM tool came from this gap.

Reschedules do not cascade

The client moves the session by a week. In a PM tool you drag the card, and then you: email the nine learners, tell the instructor and check she is free, rebook the room, update the pay record because her rate for that week is different, and change the invoice date. Five manual steps, each of which can be forgotten, for one very common event. Reschedules are not exceptions in training delivery. They are the normal texture of the work.

No registration or waitlist

Learners register through a form, an email or a client's spreadsheet. Someone pastes names into the card description. When a learner cancels, someone edits the description and remembers, or does not, to tell the first person on the waitlist. There is no confirmation, no joining email, no capacity check, and no learner record that persists after the card is archived.

No per-session margin

Because the card does not hold price and cost as first-class numbers, you cannot ask the tool which courses make money. Most training companies on a PM tool discover their margin quarterly, from the accountant, in aggregate. Knowing that the two-day cloud course earns 40 percent and the leadership workshop earns 8 percent changes what you sell. A board cannot tell you that.

No qualification or expiry tracking

Instructor accreditations expire. Learner certifications expire. Clients ask for proof of both. A PM tool has no concept of a credential with a date on it, so this ends up in yet another spreadsheet, maintained by the same person reconciling the cards.

The one-board-per-client sprawl

This is how it always ends. Each client gets a board, because their sessions need to be viewed together. Then each instructor needs a view across boards, so you build a portfolio or a dashboard. Then finance needs everything invoiceable this month, so you add a tag and a filter. Eighteen months in, you have forty boards, a set of automations nobody dares edit, and one person who understands how it fits together. When she leaves, the system leaves with her.

PM tool vs TMS: the same jobs, side by side

None of the middle column is a criticism of the tools. They are doing exactly what they were designed to do. The right column is what training management software was designed to do instead, and the difference is not features. It is which object sits at the centre.

The tipping point

People ask for a number, so here are the rough thresholds at which I have watched a PM tool go from fine to expensive. Any one of them is a signal; two together is a decision.

• Around twenty sessions a month. Below that, a coordinator can hold the schedule in her head and the board is a record. Above it, the board becomes the thing she is checking against her head, and the two drift.
• Ten or more instructors. Especially contractors. Availability, rates and qualifications across ten people is where conflict detection stops being a nice-to-have and starts being the difference between a delivered class and an apology.
• More than one client at once.The moment two clients' sessions compete for the same instructor or the same week, the one-board-per-client model has to be cross-referenced by hand.
• Any invoicing per session. If you bill per delivery rather than on an annual retainer, every session card is also a billing event, and a PM tool has no idea. Re-keying session details into an invoicing tool is the most common hidden cost I find when I talk to training companies about how they manage a training schedule in Asana.

A useful test: count the hours per week spent moving information between the PM tool and anything else (email, calendar, invoicing, spreadsheets). At most training companies past these thresholds it is ten to fifteen hours a week, which is a part-time salary spent on being the integration layer.

Keep Asana for what it is good at

Switching to a TMS does not mean cancelling Asana. It means giving it back the job it is good at. Internal projects, a new curriculum build, the website refresh, the conference plan, the quarterly sales push: these are projects, with tasks and owners and dependencies, and a PM tool is the right home for them. Content development in particular fits well: a course build has milestones, reviewers and a launch date, and it does not have seats or an invoice.

The TMS sits alongside and owns delivery: the catalog, the instructors, the sessions, the learners, the clients and the money. The line between them is simple. If it has an instructor and learners attached, it lives in the TMS. If it is work your own team is doing, it lives in the PM tool. In TryTami the delivery side starts with scheduling that checks availability and qualifications at booking time, and the registration, billing and reporting hang off the same session record, so a reschedule is one action rather than five.

PSA tools are the other wrong turn

Once a training company decides the PM tool is not enough, the next instinct is often a professional services automation platform, because PSA tools understand billable people, utilization and invoicing. That is closer, but it models consultants on engagements, not instructors on sessions with learners in seats. Registration, capacity, certification and the client-facing training record are still missing, and you inherit a timesheet culture your instructors will hate. We cover that comparison properly in PSA vs TMS for training companies.

See what your board looks like as a training schedule

If you recognise the Friday-afternoon reconciliation, the fastest way to judge whether a TMS is worth it is to bring your real board to a demo. We will take a month of your sessions, load them, and show you what happens when an instructor is double-booked, a client moves a date, or a class closes and needs invoicing. Book a demo and bring the messiest month you have.