Key takeaways
- We opened a build's project board to answer one question, how far along is this, and it said 6 of 47 items done. The real figure was 28 of 47.
- Every module with any finished work at all reported exactly one item complete, whatever the true number was.
- Three modules were one hundred percent finished and each of them read as one item done.
- A module with nothing finished reported zero, correctly, which is the detail that made the whole board look believable instead of obviously broken.
- The status word beside each module is worse. It is set by hand, nothing ever updates it, so every module still said backlog including the finished ones.
The question was an ordinary one. A CRM build had been running for a while and somebody needed to know how far through it was before anyone promised a date.
That build lives on a project board, cut into modules. Data model, pipelines, estimates, calendars, workflows, intake, and the rest. Each module holds its work items, and each module reports how many of them are finished. So the answer should be a ten second lookup, which is the entire reason a board like that exists.
It said 6 of 47. A project that had been worked on for weeks sitting at about an eighth of the way through. That reads as stalled, and stalled is the kind of answer that changes what somebody says on a call the next morning.
The number that was always one
It was wrong, and it was wrong in a very specific way. Every module that had any completed work at all reported exactly one item complete. Not roughly one. Exactly one, every time, whatever the real count happened to be.
The data model module held seven items and all seven were done. It reported one. Pipelines, four items, all four done, reported one. Estimates, six of six done, reported one. Workflows had nine items with seven finished and reported one. Foundation, five items with two done, one. Intake, five with two done, one again.
Add those the way the board adds them and you get six. Count the actual cards and you get twenty eight. The build was most of the way through its early phases, and the summary said it had barely begun.
Why nobody caught it sooner
This is the part worth keeping, because the fault survived on being plausible rather than on being hidden.
A module with no completed work reported zero. Correctly. So the board was never nonsense. It was showing zeros and ones, and a board full of zeros and ones looks exactly like a build in its first fortnight. If every module had reported one, including the empty ones, somebody would have spotted it inside a minute and gone looking.
A wrong number is easy to catch when it looks wrong. This one always erred in the same direction, always understating, and always by an amount that matched what an early stage build is supposed to look like. It was never surprising, so it was never questioned.
There is a habit in that worth naming. We check numbers hardest when they are good news. A figure that says you are further behind than you thought gets believed immediately, because it feels like the responsible thing to accept.
The word beside it was worse
Each module also carries a status. Backlog, in progress, completed. Reading a board, that label is the first thing your eye lands on, because it is a word and the rest is arithmetic.
All nine modules read backlog. Including the three that were one hundred percent finished.
That field is set by hand. Nothing in the system ever writes to it, and nobody had ever set it, so every module was still reporting the value it was created with. It was not stale. Stale would mean it had once been right. It had never carried any information at all.
The two of them together are the real problem. A count that always understates, sitting beside a word that never moves, both agreeing that nothing has happened. Two independent-looking signals telling you the same wrong thing, which is exactly how a reader gets confident.
What we do now
Nothing clever, which is usually the sign of the right fix. Any report over that board pulls the raw work items and the list of states they can be in, matches each item to its state, and groups them by module itself. Then it counts.
Same answer for whether a module has started. We do not read the label. We look at whether any of its items have moved.
It costs two extra calls and a few lines of grouping, and it produces numbers that match what you see when you open the board and look at the cards with your own eyes. That last bit is the actual test. When a summary and the records underneath it disagree, believe the records, then go and find out what the summary is really counting.
What this means for your business
A summary field is only as good as the thing that writes it, and most of the time you have no idea what that is or when it last ran.
This shows up everywhere in the tools small businesses run on. A pipeline value that only counts opportunities somebody remembered to give a close date. A campaign dashboard reporting sends where you read deliveries. A lead count that quietly leaves out anyone who unsubscribed. None of those are lying. Each is answering a slightly different question from the one you asked, and the number looks identical either way.
Three things worth doing this week. Take the one number you quote most often about your business and find out what it actually counts, by opening the records and counting them yourself once. Check any field that is a word rather than a number, because words like active, won or complete are usually set by a person and then never touched again. And when a report tells you something is worse than you expected, verify it with the same energy you would give good news.
For a marketing automation San Jose business running a CRM, the version of this you almost certainly have is a stage that somebody moves cards into and nobody ever moves them out of. The board says the work is sitting there. The work finished in June.
Want this built for you
We build reporting that counts the underlying records rather than repeating a summary, so the number you quote is one you can defend. Start at optechsol.llc.