Your PM System Doesn’t Look Like Your Agency

Agencies, your project management system isn’t broken. It just doesn’t look like you.

That’s the root misdiagnosis inside almost every agency I’ve walked into. The owner thinks the tool is the problem. The ops lead thinks it’s adoption. The project managers think it’s training. Everyone’s right about the symptom. Nobody’s right about the cause.

PM consultants come in and reinforce the misdiagnosis. They talk workflow optimization, automation, systemization. Those are all good things. They’re also the wrong thing to lead with. You can optimize a workflow that doesn’t reflect how your team actually ships work, and all you’ve done is systemize the wrong behavior faster.

What’s missing from most PM implementations is any reflection of the work you sell and the way your team delivers it.

What “looks like you” actually means

A system that looks like you is one where your team opens a project and immediately recognizes what they’re looking at.

The sections mirror the phases your team actually works in, not the phases someone’s template book prescribed. The task names use the language your team speaks in the Monday standup. The custom fields are the ones that come up in your SOWs, not a generic priority-owner-due-date triple that could belong to any business in any industry. The views are the ones your PMs would build themselves if they had six hours to spare.

When a system looks like you, onboarding collapses. New hires orient in days instead of weeks, because the system is a map of the business they just joined. Senior PMs stop maintaining shadow spreadsheets, because the real system already answers what they built workarounds for. Clients ask fewer status questions, because the work is visible in a shape that mirrors what they thought they were buying.

When it doesn’t look like you, every interaction with the system is translation work. Your team is constantly converting between the tool’s mental model and the one they actually use. That overhead never shows up on a line item. It shows up as friction, disengagement, and quiet workarounds.

The proof of concept move

Here’s the move I use on every engagement.

Before we touch any active project, I build a proof of concept inside the agency’s PM tool. Fictional client. Realistic SOW. Real structure. It’s how I show agencies what “looks like you” looks like before we roll out to live work.

The POC is a decoy, and that’s the point. Nobody’s retainer is on the line. We can argue about whether “Discovery” or “Immersion” is the right name for the first phase without anyone feeling like their current project is getting blown up. We can debate whether the reporting rollup should be by client or by deliverable type without it touching a real deadline.

That argument, the one about language and structure with no live client attached, is the most valuable conversation in the whole engagement. It’s the moment the team’s implicit model of how they work becomes explicit. You cannot systemize something you haven’t made explicit.

I’ve yet to meet an agency where the POC debate didn’t surface at least three structural assumptions nobody had articulated before.

The five-step revamp

Audit the current state. Where work lives, how decisions get made, where the gaps show up. Not “what tool are you on,” which is a surface question. The real audit is about where information leaks, where handoffs break, and where the same argument keeps happening because nobody wrote the resolution down.

Build a proof of concept. Fictional client, real products, real goals, a project plan that mirrors how you scope your best accounts. Not your worst, not your average. Your best. The POC should look like the version of your work you’d want every engagement to feel like.

Work through the trade-offs together. No system is perfect and every decision is a compromise. Some teams want per-client templates and some want per-deliverable; both work, neither is right in the abstract. The question is which compromise your team can live with. Have that argument in the POC, not six months into live operation.

Pilot on one real engagement. Pick a client where the relationship is healthy, the stakes are moderate, and your team has enough slack to run the new system in parallel. You’ll learn more in two weeks of real use than in two months of hypotheticals.

Install documentation, training, and refinement. No system survives contact with reality. The rollout ends when the team has operated inside it long enough to surface edge cases, and those edge cases have been resolved inside the system rather than worked around outside it.

The reframe

Project management isn’t actually about managing projects.

The PM tool is a collaboration surface. Its job is to give your team the right space to communicate, calibrate, and coordinate on the work, in a language and a shape they already speak.

When the tool doesn’t reflect the team, it gets in the way of the work. When it does, it amplifies what the team can do. Same tool, same features, completely different outcomes. The variable is how closely the system looks like you.

So if your PM implementation feels broken, try a different question before you try a different tool. Does this look like us? If the answer is no, you don’t need workflow optimization. You need a system that reflects the business you already built.