A Humanity AI PublicationStart a conversation →
Actually Useful

Practical dispatches on AI & automation, from someone who builds it

← All Posts

We Stopped Tracking Tasks. That's When It Started Working.

A development firm was drowning in a generic project tracker nobody trusted. The fix wasn't a better checklist. It was changing what we tracked at all. A case study.

Real StoriesBy Trey WoodwardNovember 5, 20267 min read

Here's a thing that sounds like progress but usually isn't: you buy a project-management tool, you load every task into it, and now you can "see everything."

Everything is in there. Every step, every to-do, every owner. And somehow you still can't answer the one question that matters when a partner calls: where does this deal actually stand right now?

A few weeks ago we wrote about a commercial real estate development firm buried in exactly that kind of tool, and how we used AI to cut a wall of false alarms down to a short morning brief. This is what happened next. The client came back with a bigger ask, and the fix turned out to be the opposite of what anyone expected. We didn't build them a better task list. We talked them out of tracking tasks at all.

The next ask

Quick recap if you missed the first round. Multiple projects running at once, each one a long, expensive, slow-moving thing with a lot of money riding on dates not slipping. All of it lived in an off-the-shelf tracker, and keeping that tracker accurate had quietly become a second job: updating statuses, re-typing dates whenever a contract changed, checking off a hundred little boxes. The payoff was a board that was almost always a little bit wrong.

The morning brief took the edge off the noise. But the team still had to feed the tracker underneath it. So the next ask was reasonable and completely understandable: "Can you build us something that keeps all of this up to date for us?" Automate the task tracking. Make the checklist maintain itself.

The actual problem

We started there. And the deeper we got into how these deals really move, the more we realized the task list wasn't the thing to automate. It was the thing to question.

A development deal doesn't actually behave like a checklist. It behaves like a sequence of phases. Due diligence, then design, then permitting, then construction, then handoff. What a person on that team genuinely needs to know is simple: which phase is each deal in, and what dates are coming at me that I can't afford to miss?

The hundreds of individual tasks underneath those phases were noise dressed up as control. You could check off forty of them and still be stuck, because the one thing you were actually waiting on was a permit from a city office that no amount of checkbox-ticking would move.

That was the shift. The problem was never that their tracker was missing features. The problem was that it was tracking the wrong unit. Tasks felt like the thing to measure because tasks are easy to list. But the work didn't live in the tasks. It lived in the phases and the dates.

Once we said that out loud, the whole project changed direction. We stopped asking "how do we keep this giant task list current?" and started asking "what are the few things that tell us where a deal truly stands, and can we get those without anyone having to type them in?"

What we built

Three ideas did most of the work.

Track phases, not to-dos. We rebuilt the system around the real stages a deal goes through. At a glance, you can see every deal and exactly what phase it's in, laid out on a timeline instead of buried in a list. When a milestone actually happens, like a permit coming through, the deal moves to its next phase and the timeline updates itself. The first time the client saw a milestone get checked and watched the whole deal jump forward on its own, the reaction was basically, wait, it already does that?

Let the documents keep the dates honest. In the first round, AI read the contracts to pull out the dates buried in them. This time we went a step further and made the documents the source of truth. Update the contract in their shared drive, and the key dates flow through to the deal overview automatically. Nobody re-keys anything. The thing you already have to maintain, the contract, becomes the thing that maintains everything else. This was the piece that got the biggest reaction.

Let each deal follow its own path. Here's the part that kills most rigid systems. No two of these deals are actually the same. One was built around a long contingency window and an extra outside-review step that none of the others had. Another needed a special approval before design could even begin. A system that forces every project down one identical set of stages either loses that reality or buries the team in exceptions. So we're building in the ability for a deal to carry its own custom phases without cluttering up the view of every other deal. That one's genuinely hard, and we're still working through the cleanest way to show deal-specific steps in a shared overview without confusing everyone. We're not going to pretend it's solved.

What we were careful about

A case study that's all wins is a sales brochure, so here's the honest part.

Same rule as the first round: the computer doesn't get the final say on status. When the system backfilled a long backlog of checklist items by reading old documents, it suggested four items on a test project were complete and flagged a fifth as not done, because an older environmental report was out of date. A person checked that against reality, and the system had it right. But a person checked. Auto-filled status is a strong first draft, not the last word, especially when a date drives a decision worth a lot of money.

We also left the old tool in place as a fallback instead of ripping it out. When they flip to the new system as their source of truth, the old one stays reachable for a while in case something looks off. And the cutover is deliberately not scheduled for a Friday, because nobody wants to discover a problem going into a weekend. That's not AI advice. That's just how you move a team onto something new without scaring them.

One honest limit worth naming: the system is very good at showing where a deal is. It is not the thing that decides whether a deal is in trouble. "On track" versus "behind" depends on buffer days and outside delays like planning and zoning that no two people define the same way. That's a judgment call, and it's staying with the humans. The software's job is to put the facts in front of them fast. Their job is to read the situation.

And this is a before-go-live story, so I'm not going to hand you a tidy percentage. As I write this, we're days from cutover, not months past it. What I can tell you is that the parts meant to run without babysitting are running, and the client's own gut check on a test deal came back accurate. The verdict that matters, whether the team actually trusts it enough to put the old tool away, is still ahead of us. Plenty of good software never gets used, and we'll know soon which side of that line this lands on.

The lesson you can borrow

You don't develop real estate, probably. Doesn't matter. The trap is the same in almost every business.

When a tracking tool becomes a chore your team resents and still doesn't answer "where do things stand," the instinct is to fix how you're using it. Add a view. Tighten the process. Make everyone update it more diligently. That almost never works, because the real problem is usually hiding one level down: you're tracking the wrong unit.

Ask yourself what actually tells you a job is moving. Is it the forty little tasks, or is it three or four real stages and a handful of dates? Most of the time it's the stages and the dates, and most of the time those dates already exist somewhere you're not looking, in a contract, an email, a signed document. The win isn't tracking more. It's tracking the few things that matter, dropping the upkeep you never needed, and letting the documents you already keep do the updating for you. Sometimes that means building around how your work actually behaves instead of bending a generic tool to fit.

Tracking everything is not the same as knowing where things stand.

Those are different jobs, and a pile of tasks is surprisingly good at hiding the difference.

If your team is spending more energy feeding a tracker than doing the work the tracker is supposed to watch, that gap is exactly the kind of thing we help businesses close at Humanity AI. Usually the answer isn't a bigger checklist. It's a smaller, sharper picture of what's actually going on.

Questions & Answers

Isn't abandoning task tracking risky? How do the small things not fall through?

They don't get abandoned, they get demoted. The small steps still exist underneath each phase, and the system can suggest when they're done by reading the documents. What changes is that nobody is forced to manually maintain a giant flat list as the main way of seeing the work. You manage by phase and date, and the detail is there when you need to open it up.

Why not just configure the off-the-shelf tool better?

You often can, up to a point. But a generic tool is built around a generic idea of work, usually a list of tasks with owners and due dates. When your real work is shaped differently, you spend your life bending the tool to fit, and it still fights you. Sometimes the honest move is to build around how your work actually behaves instead of how the software assumes it does.

What made the "documents drive the dates" part work?

The key realization was that the dates weren't missing, they were just trapped in the contracts and being copied by hand. Once the documents are treated as the source of truth, a human updating the contract is the only step, and everything downstream updates from it. The less re-typing a system requires, the more accurate it stays, because accuracy stops depending on someone remembering.

How long does something like this take?

Longer than a weekend and shorter than you'd fear, but the real answer is that the build wasn't the slow part. The slow part was figuring out what to track. Once we understood the work was about phases and dates rather than tasks, the tool followed fairly quickly. Rushing to build before you understand the work is how you get an expensive version of the thing you already hated.

Want to talk more?

Tell me what is on your mind and I will take a look. No pressure, no obligation, just a real conversation about your business.

Start a conversation →