CWM is not project management

An electrical supplies distributor, 240 people, three distribution centers. In March the company bought a good project management tool — board, due date, owner, dependency. In November, the operations director did the math: 38 active boards, of which 6 were actual projects. The other 32 were processes that repeat every week, forced into task lists that someone recreates by hand each cycle.

It wasn't a bad choice. It was a category mistake. The tool does very well what it sets out to do, and what it sets out to do is a small slice of a mid-size company's work.

01Project, process and operation are three different animals #

The PMBOK Guide, from the Project Management Institute, defines a project as a temporary endeavor undertaken to create a unique product, service or result. The two words carrying the weight are temporary and unique: there is a date when it ends, and what it produces isn't identical to the last one. An ERP rollout is a project. A store remodel is a project.

• Project — a start, an end and its own scope. Each one differs from the last. What matters to measure is schedule, scope and cost through delivery.
• Recurring process — the same path walked many times, with fixed stages, rules and owners. Purchasing, hiring, month-end close, credit approval. What matters to measure is cycle time, rework and where it stalls.
• Continuous operation — no instance that ends; a queue that never empties. Customer service, maintenance, shipping, support. What matters to measure is SLA attainment, queue volume and the aging of whatever is stuck.

A project tool represents the first case very well. In the other two it survives by workaround: someone duplicates a template board every Monday, someone pastes a document link into a card comment, someone exports to a spreadsheet because the report the board asked for doesn't exist there. Each of those workarounds is invisible work nobody counts — what Ohno would call office waste.

02Purchasing with two approvals #

The distributor has a simple rule: a purchase above R$ 15 mil goes through the area manager and finance; above R$ 80 mil, through the director as well. (This is a mid-size Brazilian company; the figures are in Brazilian reais and stay that way in every version of this article.) Three people, two conditions, one mandatory order. On a task board that becomes a card with three checkboxes and the hope that nobody ticks the third before the second.

What's missing isn't a field, it's an executable rule. In a collaborative work management platform, the request amount decides which approvals exist, each approval records who, when and with what comment, the supplier comes from a registry rather than the keyboard, and the invoice stays attached to the stage that required it. If finance sends it back, the request returns to a named stage — not to a comment asking someone to redo it.

03Onboarding that crosses HR, IT and the manager #

Rummler and Brache described in 1990 the problem that remains the most expensive one in mid-size companies: the work that matters happens in the white space of the org chart, between the boxes, and that is exactly where nobody owns it. Hiring someone is the perfect example.

1. HR collects documents, registers the contract and schedules the induction.
2. IT creates email, access, laptop and phone — and needs the exact role to grant the right permission.
3. The manager defines the scope of the first 30 days, who buddies with the new hire and which training comes first.
4. Facilities arranges the badge, the workstation and the uniform, where applicable.

Four teams, different lead times and one hard dependency: IT can't finish without HR's information, and the manager can't receive anyone without IT. A task board shows the boxes. A process shows the handoff between them — and the handoff is what runs late. A company that treats hiring as a designed process can answer, without asking anyone, how many hires are in flight and which stage slips most.

04SLA-driven service and month-end close #

The distributor's customer service takes roughly 900 tickets a month, with an SLA of 8 business hours for first response and 3 business days for resolution. That is neither a project nor a process with an end date: it's an operation. It needs a prioritized queue, a clock running per ticket, automatic escalation as the deadline approaches, and a dashboard showing what will breach today — not what breached last month.

Month-end close is the symmetric opposite: a process that repeats twelve times a year, always the same 40 stages, the same owners and a deadline that doesn't move. What the controller needs isn't to create 40 tasks every month; it's to trigger a template with due dates relative to the fifth business day and see, on day 3, who still hasn't delivered the reconciliation. It's the same reasoning as measuring variation instead of blaming people: if the same stage slips every month, the design is the problem, not the employee.

Want to see how this looks inside a real operation? Explore the platform.

05The document in the context of the work #

In almost every mid-size company, the document lives in a parallel drive. The proposal sits in a shared folder; the card that says 'send proposal' is on the board; the signed contract is in someone's inbox. Three places for one fact. When that person goes on holiday, the company discovers the information was never the company's.

Document in context means the text, the spreadsheet and the attachment belong to the stage that requires them, inherit that process's permissions and show up in the history of who changed what. This isn't convenience: it's the difference between knowledge that circulates and knowledge that evaporates when someone changes teams.

06Automation and agents inside the flow #

The last difference is the one that changes daily life most. In a project tool, automation usually moves cards and notifies people. In a well-designed process, automation executes: it checks the approval threshold, creates the request with the right supplier, chases the pending item on day three, escalates to the manager on day five. And the AI agent, where there is one, operates inside the same rule — with scope, permission and an audit trail, as discussed in what to delegate to an agent and what not to.

07When a project tool is enough #

Honesty is due here: if your company is an agency, a consultancy or a studio, where nearly all the work is a unique client deliverable, a good project tool may solve 90% of the problem — and swapping it for a whole platform would be cost without return. The signal that the category has changed is different: when recurring processes and operations take over most of the calendar, and the effort of keeping everything in sync starts competing with the work itself. That's the cost of coordinating rising until it becomes visible.

That bundle — planning, collaboration in context, content, automation, reporting and intelligent assistance — is what the market started calling Collaborative Work Management. The public definition came from Gartner, which published the Magic Quadrant for Collaborative Work Management on October 28, 2025. The proper attribution stands: GARTNER is a registered trademark of Gartner, Inc. and/or its affiliates; Gartner does not endorse any vendor described in its publications; the reference here is strictly to the category's market definition.

If you want to see this assembled, look at how the modules fit together, what agents execute inside a process and what changes by department. And before deciding, the next piece in this track is a checklist: how to evaluate a CWM platform.

A project is work that ends. A process is work that comes back. An operation is work that never stops. A mid-size company lives on all three at once — and choosing a tool as if only the first existed is why so many spreadsheets outlive the software that was supposed to retire them.