Publication date:
Publication from:
A manager opens a project card and sees: 68% complete, deadline in three weeks. Three weeks later, the project isn’t closed. Two weeks after that—still not closed. Yet none of the numbers were false: the percentage was calculated correctly, and the deadline was the one that had been agreed upon.
This is a common situation, and the explanation isn’t as obvious as it seems. It’s not a matter of poor reporting discipline, nor is it that someone was hiding problems. The point is that both metrics, by their very nature, describe intent rather than reality.
Intent Metrics and Process Metrics
Completion percentage and deadlines belong to the same class of metrics: they describe how a project should look relative to the initial plan. These are intent metrics. They’re useful for communicating with the client but are ineffective as management tools because they measure deviations from a decision made at a time when the least was known about the project.
There is another category of metrics—those that describe not the plan, but actual performance. How many times a task was sent back for revision. How consistently the team makes errors in its estimates, and in which direction. How much time was spent waiting rather than working. These metrics don’t compare reality to the plan—they show reality itself, and therefore can explain what a percentage cannot.
These two classes of metrics form the foundation of how SalesUp Project Management for Creatio works, available on the Creatio Marketplace since July 2022. The Gantt chart in it is what people usually expect to see first. But running in the background alongside it is a set of calculations tracking the history of status changes, which describes not the plan, but the mechanics of the team’s work.
Returns for Revision as a Quality Metric for Requirements
A metric that is rarely interpreted correctly is the number of times a task was already considered complete but was then returned for further work.
It is common to view this number as an assessment of the performer. Logically, frequent returns tend to indicate a flaw in the task description rather than in the execution. A task that was closed and reopened three times was usually described in a way that allowed for multiple interpretations—and each iteration was an attempt to guess which one was intended.
The value of this metric becomes apparent when viewed in aggregate. A single return means nothing. But when seen across dozens of tasks, a pattern emerges: a certain type of work, a certain type of client, or a certain stage of the project. This is already a diagnosis, and it’s addressed during the analysis phase, not the execution phase. That’s precisely why the number of revisions is included in the list of metrics that come standard with our product—not as an option for advanced users, but as a core metric.
The gap between the estimate and the actual result is a metric, not a fault
The second process metric is the difference between planned and actual time spent. It, too, is often misused, turning it into a tool for evaluating people.
Estimating labor costs is a forecast made under conditions of incomplete information, and it will always be inaccurate. The question isn’t whether there’s a discrepancy, but whether it’s random. When these differences accumulate over several months, it becomes clear just how chaotic they are: the discrepancy may turn out to be systematic for a certain type of task or a specific team and recur in roughly the same proportion.
This isn’t a reason for a post-mortem. It’s a correction factor that makes future planning more accurate—provided that the data is collected automatically and doesn’t depend on whether someone remembered to fill out a report at the end of the week.
A significant portion of project time isn’t spent—it’s waiting
The third metric is the most counterintuitive. It’s not the time spent performing the work, but the time a task spends in each individual state.
This figure challenges the conventional view of a project, in which delays are associated with slow execution. The calendar duration consists not only of work but also of waiting: a task awaits review, approval, the freeing up of resources, or a decision from a cross-functional team. This part isn’t visible in any summary report, because the report captures the result, not the pauses between results.
When a manager sees that a significant portion of the total time is spent on the review phase, the nature of the conversation with the team changes. It ceases to be a conversation about diligence and becomes a conversation about throughput—and that is a problem that has a solution.
Time without the context of the work calendar is just noise
There’s a technical condition without which the previous metric doesn’t work at all.
A task created on Friday at 6:00 PM and started on Monday at 10:00 AM had been waiting for 64 hours. According to the work calendar, it’s an hour or two, depending on the team’s schedule. The difference between these two figures isn’t just cosmetic: without taking the calendar into account, any response metric for distributed teams turns into noise, where weekends, holidays, and time zone differences completely drown out the signal.
For companies operating in multiple countries, this is the difference between a metric used to make decisions and a number that has to be explained out loud every time. That’s why, in our product, the duration spent in each status is tracked simultaneously across multiple dimensions, including calendar hours based on configured work calendars.
Why This Needs to Be Integrated with the Rest of Your Business Data
A standalone project tracker can collect all these metrics. What it can’t do is place them alongside the contract, the invoice, and the actual hourly rate.
This is where process metrics stop being back-office bookkeeping and start speaking the language of the business. The product allows you to calculate a project’s profitability and compare financial metrics in real time with the actual time spent on a task and its cost. This means that deviations in hours are interpreted as deviations in margin—not at the end of the quarter, after the data has been exported to a spreadsheet, but when you can still influence the outcome.
The set of metrics determines what the team discusses
Metrics don’t run a project—people do. But it is the set of metrics that sets the framework for the conversation at a status meeting.
Where only percentages and deadlines are measured, the conversation inevitably boils down to the question “why are we behind schedule?”—a question to which there is no constructive answer, because it’s focused on the past. Where you can see pull-through rates, gaps in estimates, and lead times, the conversation takes a different turn: it becomes concrete, with a clear point of focus for action.
This isn’t a question of the tool. The tool merely makes certain things visible or keeps them hidden. But the choice of what exactly the team sees is already a management decision, and it’s made long before the project starts falling behind schedule.
Most often, the request sounds like, ‘We need a Gantt chart.’ But two months after implementation, the team isn’t looking at it at all—they’re looking at how long a task has been on hold. A Gantt chart shows the plan. The status history shows what happened to it
— Mykyta Kalinichenko, Marketplace Leader, Sales’Up.
