How much did this deliverable cost? The question that became a management instrument

The indicator nobody calculates

The debate about management quality almost always circles intangibles — leadership, culture, engagement. There is a quantitative alternative, and it is uncomfortably simple: compare what you forecast spending to produce a deliverable with what you actually spent.

Mapped cost

the estimate derived from mapping the process — labor, materials, equipment and every other input at each step. It is the number that serves as the basis for planning and allocating resources.

Actual cost

what was effectively invested to complete the deliverable — the labor and infrastructure genuinely allocated to it.

The smaller the gap between the two, the greater management's ability to forecast and control the factors that move cost. A wide gap points to failure: loose forecasting, rework, a decision bottleneck, scope that grew without anyone deciding it would.

Notice what is rare about this indicator: it does not ask you to judge the manager. It measures management by the residue it leaves in the numbers.

Why the arithmetic almost never closes

The cost of producing a deliverable in knowledge work rests on two pillars.

Labor

the sum of the hours worked by every professional involved in that deliverable. Qualification, experience and task complexity all feed into the hourly rate.

Infrastructure

everything the organization has to provide for the work to happen — office space, systems and software, technology infrastructure, power, water, cleaning, security, maintenance.

The two behave differently. Infrastructure is sensitive to working arrangements: remote work knocks out the share tied to physical space. Labor is not — an hour of someone's time costs what it costs, whether they are at home or in the next room.

And it is precisely on labor, the heavier pillar, that the arithmetic stalls. To attribute hours to a deliverable, the deliverable has to exist as an object — with a name, a deadline, a recipient and a requester — and each person has to have declared, before working, how much of their time goes to it. Without that, "how much did it cost" can only be answered by an accounting allocation at month-end, which is a polite way of saying nobody knows.

The 4Q1P method — What, How much, When, Who requested and For whom — exists to produce that definition. Out of it come the team's deliverables plan and the individual work plans, with each person's hours allocated to each deliverable. Clarity does not only serve alignment: it is the technical precondition of the calculation.

What the platform computes, and what it does not

In Y Managers, that allocation is not a separate report: it is the work plan.

Each plan covers a period and starts from the person's real capacity: business days are calculated automatically — weekdays in the period minus national holidays — and can be adjusted for vacation or part-time schedules. Availability in hours follows (hours per day × business days).

Across that availability you distribute effort % per deliverable: how much of the period's time goes to each one. Total effort is not capped at 100% — above 100.5% the number turns red as a warning, and nothing stops you from signing it that way. The system warns you; it does not pretend to know better than you do.

Not all work becomes a deliverable. Whatever consumes time without producing a deliverable goes into Other work, in three categories: support, advisory and training; management of teams and deliverables; other work not tied to deliverables. Without that drawer, the time that did not become a deliverable becomes measurement error — and cost per deliverable inflates or vanishes without explanation.

With working hours and compensation filled in — restricted data, entered only by Admin and HR — the Dashboard consolidates the organization live: budgeted hours and budgeted cost derived from planned effort, distribution by status, and the top 10 deliverables by hours and by cost, with a filter by team. The Deliverables list shows hours and planned finish, plus cost for those cleared to see figures.

It is worth stating what that number is not. It is budgeted labor cost, derived from planned effort. It is not actual cost tracked hour by hour, and it does not include the second pillar — infrastructure stays out of this arithmetic. It is the mapped side of the comparison, at far higher resolution than a month-end allocation. The actual side still requires the work to be recorded across the cycle.

Cost and salary figures, incidentally, are stripped on the server for members and assistants — it is not the screen doing the hiding; the number never leaves the server.

What changes when one of the workers is an AI

Here the arithmetic gains a property it never had.

An AI worker is hired from a gallery where every sample shows, before you click, what it does, the tools and integrations it uses and the monthly price. It receives a person's identity in the organization, with an AI tag: it appears on team screens, joins a team and gets a work plan like anyone else — without consuming a human user seat.

The work plan is not an accessory: it is what puts the worker on the team. Assigning it to the team and giving it direction are the same act. And the monthly seat price is materialized as that worker's cost basis at the moment of hiring — which is why effort consolidation can price it on the same ruler that prices a person.

Add the two ends together and you get something rare: a worker whose monthly cost is known before the period starts, allocated by declared effort to named deliverables. This is not an allocation estimate: it is the monthly seat price multiplied by the declared effort fraction, prorated to the plan's duration — a seven-day plan enters at 7/30 of the month's price. And the number appears separately (🤖), alongside human labor cost, never added to it.

Three details hold up the honesty of that number.

The canon is asymmetric. To enter a work plan, a deliverable must come from a signed, active deliverables plan. For a person, the exception goes through with a logged warning. For an AI worker, it is a hard block: the platform refuses. The practical cost consequence: there are no AI hours allocated to a deliverable nobody signed.

Consumption is measured, and absence is declared. Each worker displays a measured-cost badge — how much it consumed in the current month and over the last 7 days, with the number of runs. Until there is a measured run, the screen says "no measured activity yet" instead of showing zero — absence of measurement is not absence of work.

Management shows up as a line item. Orion, the AI manager, appears in the list with a line of its own. Management costs money, and that cost is apportioned into the workers' price instead of disappearing in a footnote.

The turn: when cheap gets cheaper, the useless surfaces

This is the point of the article, and it is not what most people expect from a conversation about automation.

When a deliverable becomes something an AI worker can execute, someone has to describe it precisely enough to delegate it: what it is, who requested it, where it goes, what counts as done. A good share of the portfolio does not survive that description. Not because the AI failed — because, forced to say who the thing serves, the organization discovers it does not know.

A useless, expensive deliverable is eliminated quickly; it hurts. A useless, cheap deliverable is immortal. Nobody schedules a meeting, gathers the stakeholders and faces the discomfort of killing a report that takes little work. The cost of questioning it exceeds the cost of continuing to produce it, and that — not conviction — is why it survives for years. Reports nobody reads, approvals nobody consults, spreadsheets that exist because they existed.

When execution gets cheaper, that calculus of convenience is exposed. The deliverable starts appearing in a list next to the others, with hours and cost attributed to it, with a named recipient and a signed plan behind it — and the question "who is this for?" becomes hard not to ask. In periodic reports, "deliverables at risk" and "automatable tasks" appear as a snapshot of the moment — today's figures, deliberately kept out of the comparative series.

The bigger gain from putting AI on the team, therefore, is not producing more cheaply. It is discovering that part of the portfolio existed only because questioning it was too expensive. That is cost reduction of a different order: you do not pay less for the same deliverable — you stop paying for an entire deliverable.

Automating a deliverable that should not exist is the worst possible outcome of this story: it comes out cheaper, runs faster, shows up in the charts as efficiency, and still serves no one. Automating an unoptimized process is paying to do the wrong thing faster.

The two levers, and what AI does to each

Cost and time reduction in producing deliverables comes from two sources: process optimization and management quality. Crossing them gives four scenarios.

Automation moves only the vertical axis. It optimizes the process; it does not repair management. An optimized process under inefficient management still delivers slowly: the bottleneck becomes the decision that never comes, the rework requested with no clear benefit, and the deliverable misaligned with the objective, consuming resources without generating value.

That is why the AI worker is not treated as a tool on the platform. It has a work plan, reports on each cycle and is assessed — and it never assesses its own cycle: the system refuses the attempt. The AI manager drafts the proposed assessment and it waits for your decision. Autonomous daily execution — the worker waking up and pulling the next task on its own — is being rolled out gradually, organization by organization.

Supervision does not disappear because part of the team is AI. It becomes cheaper to exercise, and harder to fake.

What the number does not say

Cost per deliverable measures efficiency, not value. A cheap, useless deliverable is still waste — just waste that looks good on the chart. Whoever answers for the outcome is the one who judges whether the thing should exist: "who is this for" is a human question.

And a small gap between mapped cost and actual cost is not always a sign of precise management. It may be a map loose enough to fit anything, or drawn after the fact. The indicator only holds when the estimate was made beforehand and signed — which is exactly why the plan locks the commitment at signature.

The question "how much did this deliverable cost" is not an accounting question. It is a manager's question. And the most useful answer it tends to give is not about money: it is about deliverables that should not exist.