The status that was never true

Thursday, late morning. A project manager needs to know whether the payment integration will be ready for the release.

She asks the developer, who says it is done — code merged, tests passing, he moved on two days ago. She asks the tester, who says it has not started — it is not in the test environment, and nothing has been deployed there since Monday. She asks the platform engineer, who says it is blocked, because the configuration change it needs is waiting on a security review nobody has scheduled.

Three answers. Nobody is lying, nobody is confused, nobody is even being imprecise. All three answers are correct.

So she does what the tooling asks of her. She picks one. The board says In Progress, the weekly report says Amber, and the release meeting is told the integration is "on track with a dependency." Every one of those statements is less true than any of the three answers she was given — and each is now the official position.

This happens on every project, every week, everywhere. It is so ordinary that we have stopped noticing it is strange.

What went wrong is not what we think went wrong

The instinctive diagnosis is a discipline problem. The definition of Done is too loose, the board is not maintained, the handover is sloppy. Someone should tighten something.

Every project manager reading this has tried that fix. Most have tried it more than once. It does not work, for a reason that has nothing to do with discipline:

The developer's slice is real: the code exists and behaves. The tester's slice is real: no evidence has been produced. The engineer's slice is real: a gate is closed. There is no hidden fourth answer that reconciles them, and no meeting that would have surfaced "the truth" — because the thing we call status was never a property of the work. It was a property of the relationship between the work and whoever is looking at it.

A tighter definition of Done does not remove that. It moves the disagreement to a different word.

Two consequences, and they are not philosophical

Done is an event, not a column. An item does not sit in Done. It collapses into Done at a moment in time — when the last observer's slice agrees with everyone else's. A board that treats Done as a place where work rests is recording an opinion and presenting it as a fact.

The ambiguity is structural, so the only useful questions are how much of it there is and how long it lasts. Not "what is the status," which has no answer, but "how confident are we that this collapses by the date we care about" — which does.

That single substitution is the whole of it. A status is a claim about the present that is never quite true. A confidence is a claim about the future that can be checked afterwards.

And checked afterwards is the part that matters. Anyone can say 70%. What makes it worth more than "on track" is keeping score — which is why this framework is not simply a nicer vocabulary for hedging.

Why the framework you already have cannot fix this

This is not an argument that your framework is bad. Scrum, Kanban, SAFe and PMBOK are each good at what they were built for. The argument is narrower and, I think, harder to dismiss: all four are silent on the same thing.

Scrum is a framework for flow and feedback — a fixed cadence, protection from mid-sprint churn, four points where reality gets inspected. What it says about an individual item is: it is in the Sprint Backlog, or it meets the Definition of Done. Two states, binary, by design. The three answers from chapter 1 have nowhere to live.

Kanban is a framework for flow under constraint, and the most honest of the four about uncertainty, because it forecasts from measured throughput rather than estimates. But its unit of truth is still the card's position on the board — which is exactly the thing three observers disagree about.

SAFe scales coordination, and solves a real, hard problem reasonably well. What it does with confidence is aggregate it upward — and aggregating a quantity nobody measured accurately at the bottom does not improve it. It makes it look official.

PMBOK is the only one of the four that treats uncertainty as a first-class subject, and compensates with documentation and control. But its instrument is percent-complete against a baseline, and percent-complete is the most confidently false number in project management.

None of these is a failure of design. Each is a rational response to the constraint its authors faced. The point is what falls in the gap between all of them.

Three teams at 90% are not at 90%

Here is the arithmetic that lives in the gap. It takes ten seconds and it changes how you read every dashboard you will ever see again.

Three teams each hold one link of a chain. Each reports, honestly and accurately, 90% confidence in delivering their part.

0.90 × 0.90 × 0.90 = 0.729

The chain is at 73%. Not 90%. Add a fourth link and you are at 66%. A fifth, 59%. By the eighth, a thing every dashboard shows as near-certain is a coin flip with better manners.

Confidence along a dependency chain multiplies. It does not average, and it certainly does not take the maximum. Yet every status roll-up in common use effectively averages: eight green teams produce a green programme.

Two refinements worth knowing, because the naive version of this argument is easy to attack.

Not every dependency is a hard block. Some slips stop you dead; some cost you an afternoon. Multiplying everything as though it were a hard block makes the map cry wolf, and a map that cries wolf stops being read. The full framework weights each link by how strongly a slip actually propagates.

Paths share items, so do not multiply the paths together. Two delivery paths that both depend on the same integration are not independent; treating them as independent double-counts the same risk and produces a number so pessimistic nobody believes it. Take the weakest path instead. Being conservative and credible beats being alarming.

That is the first thing QIPM^™ does: it makes the 40-point gap visible before the quarter ends rather than after. The second thing is the next chapter — and it is the one you can do today.

The number almost nobody has measured

Here is a question with a real answer that your organisation almost certainly does not know:

Not delivering. Not planning. Not even meeting about the work. Specifically: producing, assembling, maintaining and defending information whose purpose is to inform someone outside the doing of the work.

Nearly every organisation tracks its licences and its cloud bill to two decimal places, and has never once put a number on this.

Why this is a cost, not just an annoyance

Measurement is not a window onto the project. It is an intervention in it, and it charges twice.

It consumes. Hours in reporting meetings, preparing for them, maintaining fields for other people's benefit, assembling decks, answering "quick questions" — all subtracted from the work being reported on. Preparation is usually the larger half, and it is almost never counted.

It distorts, which is worse. An item reported as on-track becomes harder to report as off-track — not through dishonesty, but because the act of observation converted an estimate into a commitment. The tighter and more frequent the observation, the more the work optimises for looking measurable rather than being finished. Anyone who has watched a team groom a board the night before a steering committee has seen this happen.

Neither cost appears in any budget. Both are paid out of delivery.

The exercise — 30 minutes, alone

You can do this alone — estimating it yourself is accurate enough, and waiting for a mandate to count something is how counting it gets postponed forever. Nothing here commits anyone to anything: it is a measurement, not a change.

List every observation whose purpose is to inform someone outside the team: recurring reporting meetings and their preparation, fields maintained for others, reports and decks, the standing "when will X be ready?" traffic, timesheets and periodic attestations. For each, estimate hours per occurrence, occurrences per week, and how many people are involved. Then add one column that matters more than it looks: who owns this? — the person who would notice if it stopped. Leave it blank when there isn't one.

hours/week       = h/occurrence × occurrences/week × people
Observation Load = total hours/week ÷ (team size × 40)

What the rest of QIPM^™ does with this

Three chapters in, you have two of the five laws — confidence multiplies along a chain, and observation is not free — plus one number about your own team. That is useful on its own, and you owe nobody anything for it.

The rest answers the question those two laws raise: if status is untrustworthy and measuring it is expensive, what do you actually do on Monday?

You publish confidence instead of status, and then you keep score. One number per item, one date it refers to, and a one-line record when it closes of what you claimed versus what happened. After about twenty items that record tells you something no retrospective ever has — not whether you delivered, but whether your 80% means 80%. In the ledger I keep, aggregate calibration looked flawless while the team was 20 points overconfident on third-party integrations and 15 points underconfident on its own internal APIs. Two real problems with opposite fixes, cancelling each other to almost exactly zero. Both invisible without the table.

You stop promising two things at once. Fix the scope or fix the date; you cannot fix both. Demanding both does not remove the uncertainty — it relocates it somewhere you can no longer see it, which is usually quality, or the team.

There is an obvious objection to all of this, and it is the right one to raise: what do I do when 45% is politically unacceptable? Every project manager has been in that room. The framework's answer is an order of operations rather than a slogan — track record first, then the band, then the choice — because a probability offered by someone with no record is a hedge, while the same figure offered by someone whose 70% has been 70% twenty times is a commitment. The Guide devotes a chapter to that conversation and to the fourteen other objections worth taking seriously.

And you let the machine do the observing. This is the part that is new rather than rearranged. Every agile framework was built around the assumption that measurement is expensive because humans perform it — and that assumption expired recently. A model can read your board, your commits and your CI results and propose each item's confidence without interrupting anyone. So the honest answer to chapter 3 is not "measure less." It is that measurement should stop costing human attention, because attention is now the scarce thing.

That is the framework: five laws, five one-page artifacts, one twenty-minute meeting, three metrics, no new roles and no new tools. It sits on top of whatever you already run. Keep your sprints, keep your board, keep SAFe if you have it.

One last thing, on the physics

QIPM^™ borrows structure from quantum mechanics. It is not quantum mechanics, it requires none, and it does not claim projects are quantum systems.

Some mappings are literal: a state as a probability distribution is statistics, not analogy, and confidence multiplying along a chain is exactly the arithmetic in chapter 2. Some are structural analogies, like the trade-off between scope precision and date precision. And some — superposition above all — are frankly metaphors: chapter 1 describes epistemic uncertainty, different observers holding different information, not quantum superposition.

The Guide prints that table on page three, before making any claim, because a framework about honest measurement should start by being precise about itself.

Status, który nigdy nie był prawdziwy

Czwartek, późny poranek. Project managerka musi wiedzieć, czy integracja płatności będzie gotowa na wydanie.

Pyta dewelopera, który mówi, że jest gotowe — kod zmergowany, testy przechodzą, dwa dni temu przeszedł do czegoś innego. Pyta testera, który mówi, że nie zaczęte — nie ma tego na środowisku testowym, a od poniedziałku nic tam nie zostało wdrożone. Pyta inżyniera platformy, który mówi, że jest zablokowane, bo zmiana konfiguracji czeka na przegląd bezpieczeństwa, którego nikt nie zaplanował.

Trzy odpowiedzi. Nikt nie kłamie, nikt się nie myli, nikt nawet nie jest nieprecyzyjny. Wszystkie trzy odpowiedzi są poprawne.

Robi więc to, o co prosi ją narzędzie. Wybiera jedną. Tablica mówi In Progress, tygodniowy raport mówi Amber, a na spotkaniu wydaniowym pada, że integracja jest „na torze, z zależnością". Każde z tych zdań jest mniej prawdziwe niż którakolwiek z trzech odpowiedzi, które usłyszała — i każde jest teraz oficjalnym stanowiskiem.

Dzieje się to w każdym projekcie, w każdym tygodniu, wszędzie. Jest tak zwyczajne, że przestaliśmy zauważać, jak dziwne jest.

To, co poszło źle, nie jest tym, co nam się wydaje

Odruchowa diagnoza to problem dyscypliny. Definition of Done jest za luźna, tablica nie jest utrzymywana, przekazanie jest niestaranne. Ktoś powinien coś przykręcić.

Każdy project manager, który to czyta, próbował tej naprawy. Większość próbowała więcej niż raz. Nie działa — z powodu, który nie ma nic wspólnego z dyscypliną:

Wycinek dewelopera jest realny: kod istnieje i działa. Wycinek testera jest realny: nie powstał żaden dowód. Wycinek inżyniera jest realny: brama jest zamknięta. Nie ma ukrytej czwartej odpowiedzi, która by je uzgodniła, ani spotkania, które wydobyłoby „prawdę" — bo to, co nazywamy statusem, nigdy nie było własnością pracy. Było własnością relacji między pracą a tym, kto na nią patrzy.

Ostrzejsza definicja Done tego nie usuwa. Przenosi spór na inne słowo.

Dwie konsekwencje i nie są filozoficzne

„Gotowe" to zdarzenie, nie kolumna. Pozycja nie siedzi w Done. Kolapsuje do Done w konkretnym momencie — kiedy wycinek ostatniego obserwatora zgadza się z pozostałymi. Tablica, która traktuje Done jako miejsce, gdzie praca odpoczywa, zapisuje opinię i podaje ją jako fakt.

Niejednoznaczność jest strukturalna, więc jedyne użyteczne pytania to: ile jej jest i jak długo trwa. Nie „jaki jest status", bo to pytanie nie ma odpowiedzi, ale „jak pewni jesteśmy, że to skolapsuje do daty, na której nam zależy" — bo to ma.

Ta jedna podmiana jest całością. Status to twierdzenie o teraźniejszości, które nigdy nie jest całkiem prawdziwe. Pewność to twierdzenie o przyszłości, które da się potem sprawdzić.

I sprawdzić potem jest tu częścią, która ma znaczenie. Każdy może powiedzieć 70%. Tym, co czyni to wartościowszym niż „jesteśmy na torze", jest prowadzenie rachunku — i dlatego ten framework nie jest po prostu ładniejszym słownictwem do wykręcania się.

Dlaczego framework, który już masz, tego nie naprawi

To nie jest argument, że Twój framework jest zły. Scrum, Kanban, SAFe i PMBOK są dobre w tym, do czego zostały zbudowane. Argument jest węższy i, jak sądzę, trudniej go odrzucić: wszystkie cztery milczą o tym samym.

Scrum jest frameworkiem przepływu i sprzężenia zwrotnego — stały rytm, ochrona przed zmianami w trakcie sprintu, cztery punkty, w których rzeczywistość jest inspekcjonowana. O pojedynczej pozycji mówi tyle: jest w Sprint Backlogu albo spełnia Definition of Done. Dwa stany, binarnie, z założenia. Trzy odpowiedzi z rozdziału 1 nie mają gdzie się podziać.

Kanban jest frameworkiem przepływu pod ograniczeniem i najuczciwszym z czterech wobec niepewności, bo prognozuje ze zmierzonej przepustowości, a nie z estymat. Ale jego jednostką prawdy nadal jest pozycja karty na tablicy — czyli dokładnie to, o co spierają się trzej obserwatorzy.

SAFe skaluje koordynację i rozwiązuje realny, trudny problem całkiem dobrze. Z pewnością robi to, że agreguje ją w górę — a agregowanie wielkości, której nikt nie zmierzył dokładnie na dole, jej nie poprawia. Sprawia, że wygląda oficjalnie.

PMBOK jest jedynym z czterech, który traktuje niepewność jako temat pierwszorzędny, i kompensuje ją dokumentacją oraz kontrolą. Ale jego instrumentem jest procent wykonania wobec baseline'u, a procent wykonania jest najbardziej pewną siebie fałszywą liczbą w zarządzaniu projektami.

Żaden z nich nie jest błędem projektowym. Każdy jest racjonalną odpowiedzią na ograniczenie, z którym mierzyli się jego autorzy. Rzecz w tym, co wpada w lukę pomiędzy nimi wszystkimi.

Trzy zespoły po 90% nie są na 90%

Oto arytmetyka, która mieszka w tej luce. Zajmuje dziesięć sekund i zmienia sposób, w jaki będziesz czytać każdy dashboard do końca życia.

Trzy zespoły trzymają po jednym ogniwie łańcucha. Każdy raportuje, uczciwie i trafnie, 90% pewności dowiezienia swojej części.

0,90 × 0,90 × 0,90 = 0,729

Łańcuch jest na 73%. Nie na 90%. Dodaj czwarte ogniwo i jesteś na 66%. Piąte — 59%. Przy ósmym rzecz, którą każdy dashboard pokazuje jako niemal pewną, jest rzutem monetą w lepszych manierach.

Pewność w łańcuchu zależności mnoży się. Nie uśrednia się i już zupełnie nie bierze maksimum. A jednak każde zwijanie statusów w powszechnym użyciu faktycznie uśrednia: osiem zielonych zespołów daje zielony program.

Dwa uściślenia warte znajomości, bo naiwną wersję tego argumentu łatwo zaatakować.

Nie każda zależność jest twardą blokadą. Niektóre poślizgi zatrzymują Cię w miejscu, inne kosztują popołudnie. Mnożenie wszystkiego jak twardej blokady sprawia, że mapa krzyczy „wilk", a mapa, która krzyczy „wilk", przestaje być czytana. Pełny framework waży każde ogniwo tym, jak silnie poślizg faktycznie się propaguje.

Ścieżki dzielą pozycje, więc nie mnóż ścieżek przez siebie. Dwie ścieżki dostawy, które obie zależą od tej samej integracji, nie są niezależne; traktowanie ich jako niezależnych liczy to samo ryzyko dwa razy i produkuje liczbę tak pesymistyczną, że nikt w nią nie wierzy. Weź zamiast tego najsłabszą ścieżkę. Być konserwatywnym i wiarygodnym bije bycie alarmującym.

To pierwsza rzecz, którą robi QIPM^™: czyni czterdziestopunktową lukę widoczną przed końcem kwartału, a nie po. Druga rzecz to następny rozdział — i jest tą, którą możesz zrobić dziś.

Liczba, której prawie nikt nie zmierzył

Oto pytanie z realną odpowiedzią, której Twoja organizacja prawie na pewno nie zna:

Nie na dostarczaniu. Nie na planowaniu. Nawet nie na spotkaniach o pracy. Konkretnie: na produkowaniu, składaniu, utrzymywaniu i obronie informacji, których celem jest poinformowanie kogoś spoza wykonywania tej pracy.

Niemal każda organizacja rozlicza licencje i rachunek za chmurę do dwóch miejsc po przecinku, a tej liczby nie policzyła ani razu.

Dlaczego to koszt, a nie tylko irytacja

Pomiar nie jest okienkiem na projekt. Jest ingerencją w projekt i pobiera opłatę dwa razy.

Zużywa. Godziny na spotkaniach raportowych, na przygotowaniu do nich, na utrzymywaniu pól dla dobra innych, na składaniu decków, na odpowiadaniu na „szybkie pytania" — wszystkie odjęte od pracy, o której się raportuje. Przygotowanie jest zwykle większą połową i prawie nigdy nie jest liczone.

Zniekształca, co jest gorsze. Pozycję zaraportowaną jako „na torze" trudniej potem zaraportować jako spóźnioną — nie przez nieuczciwość, ale bo akt obserwacji zamienił estymację w zobowiązanie. Im ciaśniejsza i częstsza obserwacja, tym bardziej praca optymalizuje się pod wyglądanie na mierzalną, a nie pod bycie skończoną. Każdy, kto widział zespół czeszący tablicę w noc przed komitetem sterującym, widział to na własne oczy.

Żaden z tych kosztów nie pojawia się w budżecie. Oba płaci dostarczanie.

Ćwiczenie — 30 minut, samodzielnie

Możesz to zrobić sam — samodzielne oszacowanie jest wystarczająco dokładne, a czekanie na mandat, żeby coś policzyć, jest sposobem, w jaki liczenie odkłada się na zawsze. Nic tu nikogo do niczego nie zobowiązuje: to pomiar, nie zmiana.

Wypisz każdą obserwację, której celem jest poinformowanie kogoś spoza zespołu: cykliczne spotkania raportowe i przygotowanie do nich, pola utrzymywane dla innych, raporty i decki, stały ruch „kiedy będzie gotowe X?", karty pracy i okresowe atestacje. Dla każdej oszacuj godziny na wystąpienie, wystąpienia na tydzień i liczbę zaangażowanych osób. Potem dodaj kolumnę, która znaczy więcej, niż wygląda: kto jest jej właścicielem? — osoba, która zauważyłaby, gdyby to zniknęło. Zostaw puste, jeśli takiej nie ma.

godziny/tydzień  = h/wystąpienie × wystąpienia/tydzień × osoby
Observation Load = suma godzin/tydzień ÷ (liczba osób × 40)

Co reszta QIPM^™ z tym robi

Po trzech rozdziałach masz dwa z pięciu praw — pewność mnoży się w łańcuchu, a obserwacja nie jest darmowa — plus jedną liczbę o własnym zespole. To jest użyteczne samo w sobie i nikomu nic za to nie jesteś winien.

Reszta odpowiada na pytanie, które te dwa prawa stawiają: jeśli status jest niegodny zaufania, a mierzenie go jest drogie, to co właściwie robisz w poniedziałek?

Publikujesz pewność zamiast statusu, a potem prowadzisz rachunek. Jedna liczba na pozycję, jedna data, do której się odnosi, i jedna linia zapisu przy zamknięciu: co obiecałeś, a co się stało. Po jakichś dwudziestu pozycjach ten zapis mówi Ci coś, czego nie powiedziała żadna retrospektywa — nie czy dowiozłeś, ale czy Twoje 80% znaczy 80%. W rejestrze, który prowadzę, kalibracja w agregacie wyglądała nienagannie, podczas gdy zespół był o 20 punktów zbyt pewny przy integracjach z zewnętrznymi dostawcami i o 15 punktów niedoszacowany przy własnych API wewnętrznych. Dwa realne problemy o przeciwnych lekarstwach, znoszące się niemal dokładnie do zera. Oba niewidoczne bez tej tabeli.

Przestajesz obiecywać dwie rzeczy naraz. Zamroź zakres albo zamroź datę; nie możesz obu. Żądanie obu nie usuwa niepewności — przenosi ją tam, gdzie nie da się jej zobaczyć, czyli zwykle w jakość albo w zespół.

Jest oczywisty zarzut wobec tego wszystkiego i jest właściwy do podniesienia: co robię, kiedy 45% jest politycznie nie do przyjęcia? Każdy project manager był w tym pokoju. Odpowiedzią frameworku jest kolejność działań, a nie hasło — najpierw historia trafień, potem pasmo, potem wybór — bo prawdopodobieństwo podane przez kogoś bez historii jest wykrętem, a ta sama liczba podana przez kogoś, czyje 70% było 70% dwadzieścia razy, jest zobowiązaniem. Guide poświęca rozdział tej rozmowie i czternastu innym zarzutom wartym poważnego traktowania.

I pozwalasz obserwować maszynie. To jest ta część, która jest nowa, a nie przestawiona. Każdy framework zwinny został zbudowany wokół założenia, że pomiar jest drogi, bo wykonują go ludzie — a to założenie niedawno straciło ważność. Model potrafi przeczytać Twoją tablicę, Twoje commity i wyniki CI, i zaproponować pewność każdej pozycji, nie przerywając nikomu pracy. Uczciwą odpowiedzią na rozdział 3 nie jest więc „mierz mniej". Jest nią to, że pomiar powinien przestać kosztować ludzką uwagę, bo uwaga jest teraz tym rzadkim zasobem.

To jest cały framework: pięć praw, pięć jednostronicowych artefaktów, jedno dwudziestominutowe spotkanie, trzy metryki, zero nowych ról i zero nowych narzędzi. Siada na wierzchu tego, co już prowadzisz. Zatrzymaj swoje sprinty, zatrzymaj tablicę, zatrzymaj SAFe, jeśli go masz.

Na koniec jedno, o fizyce

QIPM^™ pożycza strukturę z mechaniki kwantowej. Nie jest mechaniką kwantową, żadnej nie wymaga i nie twierdzi, że projekty są układami kwantowymi.

Część odwzorowań jest dosłowna: stan jako rozkład prawdopodobieństwa to statystyka, nie analogia, a pewność mnożąca się w łańcuchu to dokładnie arytmetyka z rozdziału 2. Część jest analogią strukturalną, jak kompromis między precyzją zakresu i precyzją daty. A część — superpozycja przede wszystkim — to szczerze mówiąc metafory: rozdział 1 opisuje niepewność epistemiczną, różnych obserwatorów trzymających różne informacje, a nie superpozycję kwantową.

Guide drukuje tę tabelę na trzeciej stronie, przed postawieniem jakiejkolwiek tezy, bo framework o uczciwym pomiarze powinien zacząć od precyzji wobec samego siebie.