When your project tool is the bottleneck:
improve, redesign, or add AI?

You're already on a tool, Monday, ClickUp, Teams, Procore, or something else, but it isn't delivering. Before you rip and replace, three diagnostic questions tell you which path actually fits.

Why your tool probably isn't the problem

The pattern: an SMB rolls out a project management tool. The first three months feel great. By month six, half the team is back in email. By month twelve, leadership starts whispering about replacing the tool with "something better."

Almost always, the tool is fine. What broke is one of three things:

• The configuration drifted. Custom fields piled up, workflows got modified by individual team members, board structure made sense for the original use case but not the current one.
• The underlying workflow was never quite right. The team digitized a broken process. The tool just made the broken process visible.
• Adoption never fully landed. Some people use it religiously, some use it occasionally, some never adopted it. The tool only works as well as the weakest link in the chain.

Replacing the tool fixes none of these. It resets the clock and gives you the same problems with new branding.

Three diagnostic questions

Before deciding which path to take, run through these three questions honestly:

1. Did this workflow ever work?

Was there ever a period, even on whiteboards or Excel, when the work moved through the process cleanly, predictably, and with reasonable visibility? If yes, you have a configuration or adoption problem. The shape of the workflow is fine, the tool just needs to reflect that shape better. If no, the workflow itself needs redesigning. No tool will fix a process that never worked in the first place.

2. Is the team actively avoiding the tool?

Watch what people do, not what they say in meetings. Are they updating status in the tool, or are they texting each other and updating later (or not at all)? Are decisions being made in the tool, or in side conversations the tool never sees? If avoidance is widespread, the tool is more painful than what it replaced. That is fixable, but it requires honest conversation about why.

3. Is the workflow itself stable, or still being figured out?

If the team is still actively iterating on what the workflow should even be (which steps, who owns what, what triggers what), AI integration is premature. AI works best when a workflow is mature and repeatable. If the workflow is still being figured out, AI just amplifies the wrong patterns faster.

Path 1: Improve the configuration

This is where most "broken tool" cases actually land. The workflow shape is right, the team has the basics, but the tool's configuration has drifted, gotten over-customized, or never got the second-pass tuning it needed. Symptoms:

• Boards or projects with too many custom fields, most of which nobody fills in
• Status options that overlap or are inconsistent across boards
• Missing automations that should exist (status reminders, escalations, due-date alerts)
• Reports that are slow to build because the underlying data isn't structured for reporting
• Manual work that the tool could do automatically if it were configured to

What this looks like in practice: 2 to 4 weeks of focused configuration work. Audit the current setup, kill the fields and views nobody uses, standardize statuses, add the 5 to 10 highest-leverage automations. The team will notice the difference in the first week. Cost is low, risk is low, results are fast.

When this is the right path: the workflow basically works, the team is using the tool, but it feels harder than it should be. This is the most common scenario by a wide margin.

Path 2: Redesign the underlying workflow

This is where the tool was deployed on top of a workflow that never quite worked. Configuring it more carefully will not help because the shape is wrong. Symptoms:

• Recurring "we never thought of that" cases that don't fit the existing flow
• Multiple teams interpreting the workflow differently
• Hand-offs that consistently get dropped between specific steps
• Status fields that don't match how work actually moves
• Frequent exception requests that suggest the rules don't fit reality

What this looks like in practice: 4 to 12 weeks. Map the workflow as it actually happens (not as it was supposed to happen). Identify the structural gaps. Design the new flow on a whiteboard or napkin. Pilot it with a small group. Iterate. Only then re-implement in the tool.

When this is the right path: when the diagnostic question above ("did this workflow ever work?") returns "no." The redesign is the real work; the tool implementation is the easy part once the design is right.

Path 3: Add AI to a workflow that already works

AI is an amplifier. If your workflow works, AI can make it faster, more accurate, and less manual. If your workflow does not work, AI just helps you do the wrong thing faster.

Good AI integration candidates have all three of these traits:

• Mature. The workflow has been running for months without major redesigns.
• Repeatable. The same shape of work moves through it many times per week.
• Bounded inputs. The data going in is reasonably consistent (forms, structured fields, recognizable document types).

Common high-leverage AI integrations on top of a working workflow:

• Drafting: first-pass proposals, customer responses, status updates, weekly reports.
• Extraction: pulling structured data from PDFs, invoices, or emails into the workflow automatically.
• Summarization: condensing long threads, meetings, or status histories into a paragraph.
• Routing: classifying incoming requests and sending them to the right queue.
• Quality checks: flagging outgoing documents that are missing required fields or unusual content.

What this looks like in practice: 4 to 8 weeks per use case. Pick the single highest-volume manual step, build an AI integration that handles 80 percent of cases automatically, route the 20 percent edge cases to a human. Measure. Expand only after the first one is genuinely earning its keep. See our AI implementation guide for the full pattern.

When this is the right path: when paths 1 and 2 are already done and you have a working workflow that has clear repetitive steps. Trying to add AI before the workflow works is the most common reason AI projects fail.

When to actually replace the tool

Tool replacement is rarely the right call. It is genuinely warranted in three cases:

1. Hard ceiling. The tool genuinely cannot do what you need it to do, and the workaround is more expensive than switching. This is real but rare. Most modern PM tools handle 95 percent of SMB use cases.

2. Compounding workarounds. You have so many workarounds, side spreadsheets, and out-of-tool processes that the cost of working around the tool's limits exceeds the cost of replacing it. By the time this is true, you usually know.

3. Failed adoption that cannot be recovered. The team has so deeply rejected the tool that no amount of reconfiguration will bring them back. Switching to a different tool is sometimes a way to restart the relationship. This is often a sign that the original rollout was rushed, not that the tool was wrong.

If none of these are true, fix the configuration or redesign the workflow first. Replacement is the longest, most expensive, and riskiest path.

How to decide

A simplified decision tree:

• Did this workflow ever work, even on paper? If no, redesign first (Path 2).
• Is the team avoiding the tool? If yes, find out why before doing anything else. Usually configuration (Path 1) or, less often, redesign (Path 2).
• Are paths 1 and 2 already done, and the workflow is mature and repeatable? Now you can think about AI (Path 3).
• Have you genuinely hit a hard ceiling on the tool? Then replacement is justified, but go in eyes open about cost and risk.

Benjamin Burns

Founder & CEO, Seraph Solutions LLC · 20+ years operator-side in manufacturing, defense, and federal program management.

PMP · LSS Black Belt · ITIL 4 · TS/SCI