This is not an IT project

A project structure carries an end date and a closed scope. Value from AI appears only in the continuous adaptation of a process, so the project finishes roughly in the week the work properly begins, and it leaves a working system with no owner. The decision is made before the start, not after the pilot. Either you name the person who on day 400 answers for that result out of their own profit and loss account (P&L), or you accept that on day 400 no such person will exist. There is no third option.

Project mode and product mode

Start with a distinction that most companies never put on paper, though it decides the outcome. Sriram Narayan set it out in Products over Projects (martinfowler.com, 2018) as the difference between project mode and product mode, and broke it into six dimensions. Each of those dimensions behaves differently after the day of handover.

The last row is where the whole thing breaks. A project counts as successful when it delivered the declared scope on the declared date for the declared money. Narayan notes that project mode usually has no mechanism at all for verifying actual benefits after delivery. Bad faith plays no part in it. There is nobody to do the checking and no budget to do it from, because the organisational unit created for the work stopped existing on the day the acceptance certificate was signed.

Mik Kersten described the other half of this arrangement in Project to Product (IT Revolution, 2018). Project management funds milestones against a scope defined up front, so every new need requires a new project to be chartered. It looks like administrative friction. It is in fact a throttle setting on adaptation: if changing a process requires a fresh budget request, the system learns at the speed of an investment committee that meets once a quarter. Kersten builds this on client experience rather than a controlled study. I therefore treat his frame as a model, not as evidence. A model is enough, because everything that follows can be derived from first principles.

Conway's law and the disbandment date

Melvin E. Conway put his observation into print in How Do Committees Invent? (Datamation, April 1968). It reads: any organisation that designs a system will produce a design whose structure is a copy of that organisation's communication structure. It is usually quoted in microservice arguments. Yet Conway's law answers directly why an AI initiative dies inside a project structure, and it does so without a single failure statistic.

Take it apart. A project team is a communication organisation with one unusual property: its founding document contains the date on which it will be dissolved. If an organisation imprints its shape on the system, then a system built by an organisation with a dissolution date inherits that date. It does not inherit that in code. It inherits it in who understands why the code looks the way it does, and in who has the authority and the money to change it. Once the team is disbanded, no organisation exists whose shape matches the shape of the system. That is what the ownerlessness consists of.

Conway himself quoted a corollary he attributed to Brooks: since the first design is almost never the best one, the system concept will have to change anyway. Organisational flexibility is therefore a condition of effective design. It is the organisation that has to be flexible, not the architecture. A project organisation is flexible up to the day of handover and not one day longer.

Forty years later somebody measured it. Nagappan and co-authors presented The Influence of Organizational Structure on Software Quality at ICSE 2008. The material covered 3,404 Windows Vista binaries and over 50 million lines of code worked on by several thousand engineers. The authors built eight metrics describing the organisation alone, without looking into the code, and tested how well they predicted a component's proneness to failure.

Organisational metrics beat every classical code metric. For our subject the interesting one is the second of them, which the authors call NOEE: the number of engineers who worked on a component and left the company before the release date. Their rationale is explicitly about knowledge transfer — whoever inherits the component knows neither the reasoning behind the design decisions nor the reason for particular fixes. Somebody priced the dispersal of a team and showed that it is visible in defects. And in a project, the dispersal of the team is scheduled from the first day.

Two caveats, because without them the number claims too much. This is one product in one company, a predictive model on historical data rather than a causal experiment, and the authors themselves flag limited external validity. Conway's law has not been proved causally by this. My claim is smaller and large enough: where somebody took the trouble to measure, the shape of the organisation turned out to be a better predictor of system quality than the system itself.

Four things that die at the project boundary

Now the specifics. The day of handover cuts four things at once, and every one of them is needed only after that day.

The owner goes missing. What disappears is not a job title but accountability for the outcome. The model passes into the care of IT operations, which answers for service availability, not for whether the customer service team actually shortened its response time. Nobody has it in their annual objectives. Nobody loses a bonus when quality falls from 91% to 74%, because nobody reports that number to any governing body. The project sponsor, who could have asked, already has the next project in the calendar.

The budget goes missing, and it is the one that matters. In 2015 Sculley's team at Google presented Hidden Technical Debt in Machine Learning Systems at NIPS. The most reproduced figure in that paper shows machine learning (ML) code as a small box inside a real-world ML system. Everything else is taken up by data collection, feature extraction, serving infrastructure, configuration management, monitoring, analysis tools and resource management. The authors also name the CACE principle, changing anything changes everything: in a learning system every change to an input changes the behaviour of the whole, because the model has no modular boundaries to respect. Put two things side by side. Technical debt is by definition not repaid during the build; it is repaid during operation. The project funds the build and ends before the first instalment falls due, and CACE says that in this system there are no cheap small fixes made in passing. Post-warranty care performed "within routine maintenance" is, in ML systems, an accounting fiction. The maintenance contract signed alongside the project usually covers service availability and incident repair, not retraining the model on fresh data or revising a decision threshold after a regulation changes. Neither line item is in it.

The loop that learns from mistakes goes missing. A model put into production does not stand still, because the world underneath it moves. Vela and co-authors measured this in Temporal quality degradation in AI models (Scientific Reports, 2022). They took 32 datasets from four domains: weather, hospital operations, flight delays and stock prices. Four standard algorithms gave 128 model–dataset combinations on that material. Temporal degradation appeared in 91% of them. The shape of the phenomenon matters more than the percentage: a model could hold its quality for a long time and then collapse abruptly. A flat chart across a year is no proof that things are fine. The authors treat this ageing as a phenomenon distinct from data drift and recommend continuous error measurement with an automatic alarm once a threshold is crossed. They add that unreflective continuous retraining carries costs of its own. They studied classical predictive models, not large language models, so what I carry over to generative models is the mechanism, not the figure of 91%. That is enough for the organisational conclusion: somebody has to be looking at that chart on day 400, and the team was disbanded on day 120. The learning loop also needs somebody who reviews, every month, the cases where the system got it wrong, and who, on that basis, may change both the model and the procedure around it. A project buys no such person.

The mandate to change the process goes missing. This is the deepest of the four losses and the one least often named. A project manager receives a mandate over a tool: deliver the system, train the users, close the budget. He does not receive a mandate to abolish an approval step, push a decision one level down, or tell the sales director that his quoting process no longer makes sense in its current shape. The RAND report The Root Causes of Failure for Artificial Intelligence Projects (2024) puts first on its list the divergence between what the project optimises for and what the organisation actually needs. That is precisely the mandate gap, described from the technical team's side. The fourth cause on their list is more literal still: under-investment in deployment infrastructure, which leaves the pilot with nowhere to live.

That report deserves a methodological note, because a number circulates around it that does not mean what everyone thinks it means. RAND opens with the sentence that by some estimates more than 80% of AI projects fail, twice the rate of projects without AI. That is somebody else's estimate, introduced with the phrase "by some estimates", and not a figure RAND computed. The authors' own contribution is a qualitative analysis of 65 interviews with practitioners who had at least five years of experience building models. A purposive sample, no statistical representativeness, zero projects counted. Anyone who writes "RAND found that 80% of AI projects fail" is quoting gossip from an opening paragraph.

What the data says about who succeeds

Two surveys enter here, on condition that we do not mistake them for an audit.

Gartner surveyed 782 infrastructure and operations (I&O) leaders in November and December 2025 and published the results on 7 April 2026. As reported, 28% of AI use cases in that area fully succeed and 20% end in failure. The unit of analysis is a single use case in IT infrastructure and operations, not a project and not a company, and the ROI assessment is the respondent's own self-report. What interests me here is not the percentage but the attribution. Among those who succeeded, success is attributed to integrating AI with existing workflows and systems, and to full backing from the business side. Not to model quality. Gartner turns this into a recommendation: join AI to the business at the execution stage, not at planning alone. That sentence describes the difference between a project mandate and a process owner's mandate.

McKinsey's 2025 edition of The State of AI asked 1,993 respondents in roughly 105 countries. The result that matters for this thesis: 21% of organisations using generative AI say they have fundamentally redesigned at least some workflows. Four-fifths, then, are laying AI over the process they found. Of some twenty-five organisational practices examined, it is fundamental process redesign that shows the strongest relationship with AI's impact on operating profit (EBIT). I treat that as a strongly suggestive hypothesis, not as proof. It is a correlation drawn from self-reports, and companies able to redesign their own process may simply be better managed at everything at once. With that caveat the picture is consistent with the derivation: the largest identified lever sits in territory where a project manager has no authority.

I am not, however, building this essay on any failure rate, and not out of rhetorical caution. Magne Jørgensen and Kjetil Moløkken-Østvold took apart the Standish Group's CHAOS reports, the most-cited statistic on IT project failure. They found an undisclosed research design and unspecified sampling criteria. The definitions of success turned out to be unstable, so those numbers are unfit for comparison. The same doubt applies to the fresher numbers circulating around AI. An argument about structure has to stand on a mechanism rather than an indicator, because an indicator can be demolished in a single paragraph.

The decisive test: day 400

Now the procedure. Before the start you want to know whether what you have in front of you is a project or a change to the operating model. Do not ask about technology or the size of the budget; both answer a different question. Ask three questions about day 400, counting from the start — a moment long after the project has closed. That date falls outside the warranty period and outside the sponsor's bonus cycle, which is to say in the place where the organisation has already forgotten why it began.

Question one: who owns this on day 400? Not the sponsor and not the IT-side custodian of the system. It has to be a person with a first and last name who answers for whether the thing still produces a result. If the answer is "operations", "the data team" or "we will settle that after go-live", you have the answer to the whole test.

Question two: whose P&L does this result sit in? An owner without their own P&L is a reviewer, not an owner. The benefit from AI almost always shows up in a business unit's accounts and the cost in IT's, and that asymmetry manufactures ownerlessness all by itself. If you cannot point to the line where benefit and cost meet in one person, you have not built ownership.

Question three: what happens on the day the model degrades? The answer must contain a numeric threshold, the name of the person the alarm goes to, and the budget that pays for retraining or withdrawal. Missing any one of the three means the customer will be the one who notices the degradation.

Notice what the test does not contain. There is no question about model quality or about choice of vendor. I write about that separately in The ROI is not in the model; here the practical consequence is enough: the ownership test is settled entirely outside the technical layer.

If you have fewer than three answers in the right-hand column, you are running a project and you will get a project's result, whatever the business case says.

Moving the line from build to run

One operation follows from the test, and a finance director understands it without translation. Industry summaries citing Gartner data put maintenance at roughly two-thirds of the IT budget, with the remainder going to growth and transformation. No single citable study sits behind that [TO BE COMPLETED: source for the two-thirds share of the IT budget]. I take the proportion as an order of magnitude. What matters is the split itself, because a transformation line has an end date by definition and a maintenance line does not. Moving an AI initiative from build to run is not an organisational metaphor; it is a specific change of row in the budget. That change has two effects. The cost becomes recurring, and it lands in a unit that has an owner. The project, meanwhile, loses the right to close the subject with an acceptance certificate.

In practice this means a handful of very mundane moves. Name the owner before the first line of code and write the thing into their objectives before they have seen a demo. Plan the second- and third-year budget together with the first, in the same request, because a request split in two never gets its second half. Define a business-outcome measure rather than a technical one, and take the baseline before the start so that on day 400 there is something to compare against. Establish who has the right to change the process, and check whether that person sits in the same reporting line as the system owner. When those two roles sit in different lines, a working model changes nothing in the result.

Where the legislator has already settled it

For some use cases the debate about operating mode is closed, and not by a consultant's opinion. The AI Act, that is Regulation (EU) 2024/1689, imposes on the provider of a high-risk AI system two obligations that amount in substance to a prohibition on treating deployment as a project.

Article 72 requires a post-market monitoring system to be established and documented. That system must actively and systematically collect data on the performance of the AI system throughout its lifetime. The provider documents and analyses the data collected so as to be able to evaluate continuous compliance with the requirements. The monitoring plan is part of the technical documentation. Article 17 goes further and requires a documented quality management system covering the entire life cycle, from design through post-market monitoring, with change-control and continuous-improvement processes.

Read as an organisational document rather than a legal one, this sets out two requirements: a permanent owner and permanent measurement. Both cost money in every year, so both pull a permanent line into the budget. A structure with a closing date satisfies neither condition. In those use cases, treating deployment as a project stops being ineffective and becomes unlawful.

The boundary of this argument is sharp, however, and it has to be held. Both provisions bind the provider of a high-risk system within the meaning of the regulation. The sentence "the law requires continuous monitoring of every AI deployment" is simply untrue, and it must not be used as an argument inside a company rolling out an assistant that searches internal documentation. For the remaining cases the value of these provisions is different. The legislator has described the minimum shape of an organisation that keeps a working model alive, in language that gets through an investment committee. You may copy that template voluntarily.

When it really is an IT project

The strongest objection to this whole thesis is not "projects work". It is more uncomfortable than that: in practice the sentence "this is not an IT project" is often a request to be excused from discipline rather than a diagnosis.

Bent Flyvbjerg and Dan Gardner reported in How Big Things Get Done (2023) results from a database of more than 16,000 large ventures built and curated by Flyvbjerg. Of those, 8.5% come in on budget and on schedule at once. Add delivery of the promised benefits to the two conditions and 0.5% remain. The authors call this the iron law of megaprojects and point to optimism bias and to strategic misrepresentation, that is deliberately understating costs and overstating benefits so that the venture gets started at all. The benefits data there comes from a markedly narrower subset than the cost and schedule data, so the 0.5% stands on a thinner base than the 8.5%. I treat it that way.

What matters is the prescription they draw from it. It does not read "abolish projects". It reads "think slow, act fast", and standing beside it is the case for building modular. Both demand still more discipline before the start and a still shorter execution window. If the biggest killer of large ventures is a falsified business case and a scope that spreads, then a programme with no end date and no reckoning is not the cure for that disease. It is the disease in pure form, with better vocabulary. A transformation programme that reports progress in slides every quarter and never reports an outcome will survive inside a company longer than a failed project, because it has no gate at which it could fail.

To that add a classification argument, which honestly closes the scope of the thesis. Some AI initiatives really are IT projects. Replacing an optical character recognition engine with a language model has a finite scope and a clear acceptance criterion. So does switching to a cheaper API vendor, or moving recommendations onto a newer version of a library. Work like that happens inside a system that already has an owner and already sits in the maintenance line. Elevating such a swap to the rank of an operating-model change costs two quarters of alignment and buys nothing. Narayan himself draws this distinction. In construction, project mode makes sense because the skills of building and of operating genuinely differ; in software they differ less, so separating build from run costs more than it returns. Product mode is therefore not universally better; it is the right mode for work that has no natural end, and a classification error is expensive in both directions.

So where does the boundary run? It runs where the mandate runs. If an initiative requires changing somebody's process, moving a decision between roles, or changing what people are paid a bonus for, no project manager can deliver it, and a project structure is a classification error. If an initiative touches nobody's process and has an owner from the day before the start, run it as a project, set hard gates and close it on time. The test for that is one sentence long: check whether the initiative's success requires somebody outside the delivery team to start working differently.

Both disciplines at once

The worst thing you can do with this distinction is turn it into a slogan and stop setting gates. So hold both tools at once. Hold to account as a project whatever has an end, and hand whatever has no end to somebody who on day 400 loses a bonus when the chart turns down. If you cannot give that name today, you are building something nobody will take over.

Sources

1. primaryMelvin E. Conway, How Do Committees Invent?, Datamation, April 1968 — the canonical formulation of Conway's law and the corollary on organisational flexibility attributed to Brooks.
2. primaryNagappan, Murphy, Basili, The Influence of Organizational Structure on Software Quality: An Empirical Case Study, ICSE 2008 — 3,404 Windows Vista binaries; organisational metrics, NOEE among them; a correlational case study, limited external validity flagged by the authors.
3. primarySriram Narayan, Products over Projects, martinfowler.com, 20 February 2018 — six dimensions of the difference between project and product mode; no mechanism for verifying benefits after delivery; the author's own distinction regarding work of finite scope.
4. primarySculley et al., Hidden Technical Debt in Machine Learning Systems, NIPS 2015 — the share of ML code in a real-world system, the CACE principle, debt repaid in operation.
5. primaryVela, Sharp, Zhang, Nguyen, Hoang, Pianykh, Temporal quality degradation in AI models, Scientific Reports, 2022 — model ageing as a phenomenon distinct from data drift; 128 model–dataset combinations, degradation in 91%; classical predictive models, not language models.
6. primaryRyseff, De Bruhl, Newberry, The Root Causes of Failure for Artificial Intelligence Projects and How They Can Succeed, RAND RR-A2680-1, 2024 — a qualitative study, 65 interviews; the "more than 80%" figure is somebody else's estimate quoted in the report, not a RAND finding.
7. primaryRegulation (EU) 2024/1689 of the European Parliament and of the Council (the Artificial Intelligence Act), Art. 17 and Art. 72 — a quality management system covering the whole life cycle and post-market monitoring; obligations of the provider of a high-risk system.
8. primaryJørgensen, Moløkken-Østvold, critique of the Standish Group CHAOS reports [TO BE COMPLETED: title of the paper, journal and year] — undisclosed research design, unspecified sampling criteria and unstable definitions of success; IT project failure statistics are unfit for comparison.
9. secondaryGartner, press release of 7 April 2026 on a survey of 782 infrastructure and operations (I&O) leaders conducted in November and December 2025 — 28% of use cases fully successful, 20% failed; respondent self-report, the unit of analysis is a use case in I&O. Figures taken from press coverage, because Gartner's newsroom does not make the release available for automated retrieval (as of 12 September 2026).
10. secondaryMcKinsey / QuantumBlack, The State of AI, 2025 edition, n = 1,993 — 21% of organisations report fundamental redesign of some workflows; the strongest relationship of that practice with EBIT impact; self-report survey, correlation.
11. secondaryMik Kersten, Project to Product: How to Survive and Thrive in the Age of Digital Disruption with the Flow Framework, IT Revolution, 2018 — milestone funding against scope defined up front; a practical frame based on the author's experience.
12. secondaryBent Flyvbjerg, Dan Gardner, How Big Things Get Done, 2023 — the iron law of megaprojects, 8.5% and 0.5%, optimism bias and strategic misrepresentation; the author's own database, benefits data on a narrower subset.

Struktura projektowa ma wpisaną datę końca i zamknięty zakres. Wartość z AI powstaje dopiero w ciągłej adaptacji procesu, więc projekt kończy się mniej więcej w tygodniu, w którym praca zaczyna się na dobre, i zostawia działający system bez właściciela. Decyzja zapada przed startem, nie po pilotażu. Albo nazywasz osobę, która w dniu 400 odpowiada za ten wynik swoim rachunkiem zysków i strat (P&L), albo godzisz się, że w dniu 400 takiej osoby nie będzie. Trzeciej możliwości nie ma.

Tryb projektowy i tryb produktowy

Zacznijmy od rozróżnienia, które w większości firm nie istnieje na papierze, choć rozstrzyga o wyniku. Sriram Narayan opisał je w Products over Projects (martinfowler.com, 2018) jako różnicę między trybem projektowym a produktowym, i rozłożył na sześć wymiarów. Każdy z tych wymiarów zachowuje się inaczej po dniu odbioru.

Ostatni wiersz jest tym, na którym cała sprawa się łamie. Projekt uznaje się za udany, gdy dowiózł zadeklarowany zakres w zadeklarowanym terminie za zadeklarowane pieniądze. Narayan zauważa przy tym, że w trybie projektowym zwykle nie ma w ogóle mechanizmu weryfikacji rzeczywistych korzyści po dostawie. Zła wola nie ma z tym nic wspólnego. Sprawdzać nie ma kto i nie ma z jakiego budżetu, bo jednostka organizacyjna powołana do tej pracy przestała istnieć w dniu podpisania protokołu.

Drugą połowę tego układu opisał Mik Kersten w Project to Product (IT Revolution, 2018). Zarządzanie projektowe finansuje kamienie milowe przy zakresie zdefiniowanym z góry, więc każda nowa potrzeba wymaga powołania nowego projektu. Wygląda to na uciążliwość administracyjną. Jest ustawieniem przepustowości adaptacji: jeśli zmiana procesu wymaga nowego wniosku budżetowego, tempo uczenia się systemu równa się tempu komitetu inwestycyjnego, który obraduje raz na kwartał. Kersten opiera to na doświadczeniu z klientami, nie na badaniu kontrolowanym, więc traktuję jego ramę jako model, nie jako dowód. Model wystarczy, bo dalej da się go wyprowadzić od pierwszych zasad.

Prawo Conwaya i data rozwiązania zespołu

Melvin E. Conway sformułował swoją obserwację w artykule How Do Committees Invent? (Datamation, kwiecień 1968). Brzmi ona tak: każda organizacja projektująca system wytworzy projekt, którego struktura jest kopią struktury komunikacyjnej tej organizacji. Zwykle cytuje się to w sporach o mikroserwisy. Tymczasem prawo Conwaya odpowiada wprost na pytanie, dlaczego inicjatywa AI ginie w strukturze projektowej, i robi to bez jednej liczby o porażkach.

Rozłóżmy to na czynniki. Zespół projektowy jest organizacją komunikacyjną o jednej niezwykłej właściwości: ma datę rozwiązania wpisaną w akt założycielski. Skoro organizacja odciska swój kształt w systemie, to system zbudowany przez organizację z datą rozwiązania dziedziczy tę datę. Nie dziedziczy jej w kodzie. Dziedziczy ją w tym, kto rozumie, dlaczego kod wygląda tak, a nie inaczej, oraz w tym, kto ma prawo i pieniądze, żeby go zmienić. Po rozwiązaniu zespołu nie istnieje już żadna organizacja o kształcie odpowiadającym kształtowi systemu. To jest ta bezpańskość.

Sam Conway cytował korolarz przypisywany Brooksowi: skoro pierwszy projekt prawie nigdy nie jest najlepszy, koncepcja systemu i tak będzie musiała się zmieniać, a zatem elastyczność organizacji jest warunkiem skutecznego projektowania. Elastyczna ma być organizacja, nie architektura. Organizacja projektowa jest elastyczna do dnia odbioru i ani dnia dłużej.

Czterdzieści lat później ktoś to zmierzył. Nagappan i współautorzy opublikowali na konferencji ICSE 2008 studium The Influence of Organizational Structure on Software Quality. Materiał obejmował 3404 binaria Windows Visty i ponad 50 milionów linii kodu, nad którymi pracowało kilka tysięcy inżynierów. Autorzy zbudowali osiem metryk opisujących wyłącznie organizację, bez zaglądania do kodu, i sprawdzili, jak dobrze przewidują podatność komponentu na awarie.

Metryki organizacyjne pobiły wszystkie klasyczne metryki kodu. Dla naszego tematu najciekawsza jest druga z nich, nazwana przez autorów NOEE, czyli liczba inżynierów, którzy pracowali przy danym komponencie i odeszli z firmy przed dniem wydania. Uzasadnienie autorów jest wprost o transferze wiedzy: ten, kto przejmie komponent, nie zna uzasadnienia decyzji projektowych ani powodu konkretnych poprawek. Ktoś policzył cenę rozejścia się zespołu i pokazał, że widać ją w awariach. A rozejście się zespołu jest w projekcie zaplanowane od pierwszego dnia.

Dwa zastrzeżenia, bo bez nich ta liczba jest za mocna. To studium jednego produktu w jednej firmie, model predykcyjny na danych historycznych, a nie eksperyment przyczynowy; sami autorzy zgłaszają ograniczoną trafność zewnętrzną. Prawo Conwaya nie zostało tym dowiedzione przyczynowo. Twierdzę mniej i wystarczająco dużo: tam, gdzie ktoś zadał sobie trud pomiaru, kształt organizacji okazał się lepszym predyktorem jakości systemu niż sam system.

Cztery rzeczy, które giną na granicy projektu

Teraz konkretnie. Dzień odbioru przecina cztery rzeczy naraz, a każda z nich jest potrzebna dopiero po tym dniu.

Ginie właściciel. Nie znika stanowisko, tylko odpowiedzialność za wynik. Model trafia pod opiekę utrzymania IT, które odpowiada za dostępność usługi, a nie za to, czy dział obsługi klienta rzeczywiście skrócił czas reakcji. Nikt nie ma tej rzeczy w celach rocznych. Nikt nie traci premii, gdy jakość spada z 91% do 74%, bo nikt tej liczby nie raportuje na żadne ciało kolegialne. Sponsor projektu, który mógłby o to zapytać, ma już w harmonogramie następny projekt.

Ginie budżet, i to ten właściwy. W 2015 roku zespół Sculleya z Google opublikował na konferencji NIPS pracę Hidden Technical Debt in Machine Learning Systems. Najczęściej reprodukowany rysunek z tej pracy pokazuje kod uczenia maszynowego (ML) jako mały prostokąt w rzeczywistym systemie ML. Całą resztę zajmują zbieranie danych, ekstrakcja cech, infrastruktura serwująca, zarządzanie konfiguracją, monitoring, narzędzia analityczne i zarządzanie zasobami. Autorzy nazywają też zasadę CACE, czyli changing anything changes everything: w systemie uczącym się każda zmiana wejścia zmienia zachowanie całości, bo model nie ma granic modularnych, które można by uszanować. Zestawmy dwie rzeczy. Dług techniczny z definicji nie jest spłacany przy budowie, tylko przy utrzymaniu. Projekt finansuje budowę i kończy się przed pierwszą ratą, a zasada CACE mówi, że w tym systemie nie ma tanich drobnych poprawek robionych przy okazji. Opieka pogwarancyjna wykonywana „w ramach bieżącego utrzymania” jest w systemach ML fikcją księgową. Umowa utrzymaniowa, którą podpisano razem z projektem, obejmuje zwykle dostępność usługi i naprawę awarii, a nie ponowne trenowanie modelu na świeżych danych ani rewizję progu decyzyjnego po zmianie regulacji. Tych dwóch pozycji w niej nie ma.

Ginie pętla uczenia się z błędów. Model postawiony w produkcji nie stoi w miejscu, bo świat pod nim się przesuwa. Vela i współautorzy zmierzyli to w pracy Temporal quality degradation in AI models (Scientific Reports, 2022). Wzięli 32 zbiory danych z czterech dziedzin: pogodę, operacje szpitalne, opóźnienia lotów i kursy akcji. Cztery standardowe algorytmy dały na tym materiale 128 kombinacji model–zbiór. Degradację czasową zaobserwowali w 91% z nich. Ważniejszy od odsetka jest kształt zjawiska: model potrafił trzymać jakość długo, a potem załamać się nagle, więc płaski wykres przez rok nie jest dowodem, że jest dobrze. Autorzy traktują to starzenie jako zjawisko odrębne od dryfu danych i zalecają stały pomiar błędu z automatycznym alarmem po przekroczeniu progu. Zastrzegają przy tym, że bezrefleksyjne ciągłe dotrenowywanie ma własne koszty. Badali klasyczne modele predykcyjne, nie duże modele językowe, więc na modele generatywne przenoszę mechanizm, a nie liczbę 91%. To wystarczy do wniosku organizacyjnego: ktoś musi patrzeć na ten wykres w dniu 400, a zespół rozwiązano w dniu 120. Pętla uczenia wymaga przy tym kogoś, kto co miesiąc ogląda przypadki, w których system się pomylił, i ma prawo zmienić na tej podstawie zarówno model, jak i procedurę wokół niego. Projekt nie kupuje takiej osoby.

Ginie mandat do zmiany procesu. To jest najgłębsza z tych czterech strat i najrzadziej nazywana. Kierownik projektu dostaje mandat na narzędzie: ma dowieźć system, przeszkolić użytkowników i zamknąć budżet. Nie dostaje mandatu na to, żeby zlikwidować etap akceptacji, przenieść decyzję o poziom niżej albo powiedzieć dyrektorowi sprzedaży, że jego proces ofertowania nie ma już sensu w dotychczasowym kształcie. Raport RAND The Root Causes of Failure for Artificial Intelligence Projects (2024) stawia na pierwszym miejscu rozjazd między tym, co projekt optymalizuje, a tym, czego organizacja naprawdę potrzebuje. To jest właśnie luka mandatu, opisana od strony zespołu technicznego. Czwarta przyczyna z ich listy brzmi jeszcze dosłowniej: niedoinwestowanie infrastruktury wdrożeniowej, przez które pilotaż nie ma gdzie zamieszkać.

Przy tym raporcie należy się uwaga metodologiczna, bo krąży wokół niego liczba, która nie znaczy tego, co wszyscy myślą. RAND otwiera raport zdaniem, że według niektórych szacunków upada ponad 80% projektów AI, czyli dwa razy częściej niż projekty bez AI. To jest cytowany cudzy szacunek, wprowadzony formułą „by some estimates”, a nie wynik policzony przez RAND. Własnym wkładem autorów jest analiza jakościowa 65 wywiadów z praktykami mającymi co najmniej pięć lat doświadczenia w budowie modeli. Próba celowa, brak reprezentatywności statystycznej, zero policzonych projektów. Kto pisze „RAND ustalił, że upada 80% projektów AI”, cytuje plotkę z akapitu wstępnego.

Co mówią dane o tym, komu się udaje

Wchodzą tu dwa badania ankietowe, pod warunkiem że nie bierzemy ich za audyt.

Gartner przepytał 782 liderów infrastruktury i operacji (I&O) w listopadzie i grudniu 2025, a wyniki opublikował 7 kwietnia 2026. Jak podano, w pełni udaje się 28% zastosowań AI w tym obszarze, a 20% kończy się porażką. Jednostką analizy jest pojedyncze zastosowanie w infrastrukturze i operacjach IT, nie projekt i nie firma, a ocenę ROI wystawia sam respondent. Interesuje mnie tu nie odsetek, tylko atrybucja. Wśród tych, którym się udało, sukces przypisywany jest integracji AI z istniejącymi przepływami pracy i systemami oraz pełnemu poparciu strony biznesowej. Nie jakości modelu. Gartner formułuje z tego zalecenie, żeby łączyć AI z biznesem na etapie wykonania, a nie wyłącznie planowania, i to zdanie jest w gruncie rzeczy opisem różnicy między mandatem projektowym a mandatem właściciela procesu.

McKinsey w edycji The State of AI z 2025 roku zapytał 1993 respondentów z około 105 krajów. Wynik istotny dla tej tezy: 21% organizacji korzystających z generatywnej AI deklaruje, że fundamentalnie przeprojektowało przynajmniej część przepływów pracy. Cztery piąte nakłada więc AI na proces, który zastało. Spośród około dwudziestu pięciu badanych cech organizacyjnych to właśnie fundamentalne przeprojektowanie procesów wykazuje najsilniejszy związek z wpływem AI na wynik operacyjny (EBIT). Traktuję to jako hipotezę o dużej sile sugestii, nie jako dowód. Jest to korelacja z samooceny, a firmy zdolne przeprojektować własny proces mogą być po prostu lepiej zarządzane we wszystkim naraz. Z tym zastrzeżeniem obraz jest spójny z wyprowadzeniem: największa zidentyfikowana dźwignia leży w obszarze, do którego kierownik projektu nie ma uprawnień.

Nie buduję jednak tego eseju na żadnym odsetku porażek, i nie z ostrożności retorycznej. Magne Jørgensen i Kjetil Moløkken-Østvold rozebrali raporty CHAOS Standish Group, czyli najczęściej cytowaną statystykę niepowodzeń projektów IT. Znaleźli nieujawniony plan badania i nieopisane kryteria doboru próby. Definicje sukcesu okazały się chwiejne, więc te liczby nie nadają się do porównań. Ta sama wątpliwość dotyczy świeższych liczb krążących wokół AI. Argument o strukturze musi stać na mechanizmie, a nie na wskaźniku, bo wskaźnik da się podważyć w jednym akapicie.

Test rozstrzygający: dzień 400

Przejdźmy do procedury. Chcesz przed startem wiedzieć, czy masz przed sobą projekt, czy zmianę modelu operacyjnego. Nie pytaj o technologię ani o wielkość budżetu, bo oba odpowiadają na inne pytanie. Zadaj trzy pytania o dzień 400, licząc od startu, czyli o moment dawno po zamknięciu projektu. Ta data leży poza okresem gwarancji i poza cyklem premiowym sponsora, czyli w miejscu, w którym organizacja zdążyła już zapomnieć, po co w ogóle zaczynano.

Pytanie pierwsze: kto w dniu 400 jest właścicielem? Nie sponsorem, nie opiekunem systemu ze strony IT, tylko osobą z imieniem i nazwiskiem, która odpowiada za to, czy ta rzecz nadal daje wynik. Jeśli odpowiedź brzmi „utrzymanie”, „zespół danych” albo „to będzie ustalone po wdrożeniu”, masz odpowiedź na cały test.

Pytanie drugie: w czyim rachunku wyników siedzi ten wynik? Właściciel bez własnego P&L jest recenzentem, nie właścicielem. Korzyść z AI prawie zawsze pojawia się w rachunku jednostki biznesowej, a koszt w rachunku IT, i ta asymetria sama w sobie generuje bezpańskość. Jeżeli nie umiesz wskazać linii, w której korzyść i koszt spotykają się u jednej osoby, nie zbudowałeś własności.

Pytanie trzecie: co się dzieje w dniu, w którym model się zdegraduje? Odpowiedź musi zawierać próg liczbowy, nazwisko osoby, do której idzie alarm, i budżet, z którego opłaci się dotrenowanie albo wycofanie. Brak któregokolwiek z tych trzech elementów oznacza, że degradację zauważy klient.

Zauważmy, czego w tym teście nie ma. Nie ma pytania o jakość modelu ani o wybór dostawcy. Piszę o tym osobno w ROI nie siedzi w modelu; tutaj wystarczy konsekwencja praktyczna: test na własność rozstrzyga się w całości poza warstwą techniczną.

Jeżeli w prawej kolumnie masz mniej niż trzy odpowiedzi, prowadzisz projekt i dostaniesz wynik projektu, niezależnie od tego, co napisano w uzasadnieniu biznesowym.

Przeniesienie z budowy na utrzymanie

Z testu wynika jedna operacja, którą dyrektor finansowy rozumie bez tłumaczenia. Zestawienia branżowe powołujące się na dane Gartnera podają, że firmy wydają rzędu dwóch trzecich budżetu IT na utrzymanie, a resztę na wzrost i transformację. Nie stoi za tym jedno cytowalne badanie [DO UZUPEŁNIENIA: źródło proporcji dwóch trzecich budżetu IT], więc biorę tę proporcję jako rząd wielkości. Ważny jest sam podział, bo linia transformacji ma z definicji datę końca, a linia utrzymania jej nie ma. Przeniesienie inicjatywy AI z budowy na utrzymanie nie jest metaforą organizacyjną, tylko konkretną zmianą wiersza w budżecie. Ta zmiana ma dwa skutki. Koszt staje się powtarzalny i ląduje w jednostce, która ma swojego właściciela. Projekt traci przy tym prawo do zamknięcia tematu protokołem odbioru.

W praktyce oznacza to kilka bardzo przyziemnych ruchów. Nazwij właściciela przed pierwszą linijką kodu i wpisz mu tę rzecz do celów, zanim zobaczy demo. Zaplanuj budżet drugiego i trzeciego roku razem z budżetem pierwszego, w tym samym wniosku, bo wniosek rozbity na dwa nigdy nie dostanie drugiej części. Zdefiniuj miarę wyniku biznesowego, nie miarę techniczną, i zmierz ją przed startem, żeby w dniu 400 było z czym porównywać. Ustal, kto ma prawo zmienić proces, i sprawdź, czy ta osoba siedzi w tym samym pionie co właściciel systemu. Gdy te dwie role siedzą w różnych pionach, działający model nie zmienia niczego w wyniku.

Gdzie ustawodawca już to rozstrzygnął

Dla części zastosowań dyskusja o trybie pracy jest zamknięta, i to nie opinią konsultanta. Akt o sztucznej inteligencji, czyli rozporządzenie UE 2024/1689, nakłada na dostawcę systemu AI wysokiego ryzyka dwa obowiązki, które są w istocie zakazem traktowania wdrożenia jako projektu.

Artykuł 72 wymaga ustanowienia i udokumentowania systemu monitorowania po wprowadzeniu do obrotu. Ten system ma przez cały cykl życia aktywnie i systematycznie zbierać dane o działaniu systemu AI. Zebrane dane dostawca dokumentuje i analizuje, żeby móc oceniać ciągłą zgodność z wymogami. Plan monitorowania jest elementem dokumentacji technicznej. Artykuł 17 idzie dalej i wymaga udokumentowanego systemu zarządzania jakością obejmującego cały cykl życia, od projektowania po monitorowanie po wprowadzeniu do obrotu, z procesami kontroli zmian i ciągłego doskonalenia.

Czytając to jak dokument organizacyjny, a nie prawniczy, widzimy dwa wymagania: stałego właściciela i stały pomiar. Jedno i drugie kosztuje w każdym roku, więc pociąga za sobą stałą linię w budżecie. Struktura z datą zamknięcia nie spełnia żadnego z tych warunków. W tych zastosowaniach traktowanie wdrożenia jako projektu przestaje być nieskuteczne i staje się niezgodne z prawem.

Granica tego argumentu jest jednak ostra i trzeba ją trzymać. Oba przepisy wiążą dostawcę systemu wysokiego ryzyka w rozumieniu rozporządzenia. Zdanie „prawo wymaga stałego monitorowania każdego wdrożenia AI” jest po prostu nieprawdziwe i nie wolno go używać jako argumentu w firmie, która wdraża asystenta do wyszukiwania w dokumentacji wewnętrznej. Wartość tych przepisów dla pozostałych przypadków jest inna: ustawodawca opisał minimalny kształt organizacji, która utrzymuje działający model, i zrobił to językiem, który przechodzi przez komitet inwestycyjny. Ten szablon możesz skopiować dobrowolnie.

Kiedy to jednak jest projekt IT

Najsilniejszy zarzut wobec całej tej tezy nie brzmi „projekty działają”. Jest niewygodniejszy: zdanie „to nie jest projekt IT” bywa w praktyce wnioskiem o zwolnienie z dyscypliny, a nie diagnozą.

Bent Flyvbjerg i Dan Gardner opisali w How Big Things Get Done (2023) wyniki z bazy ponad 16 tysięcy dużych przedsięwzięć zbudowanej i kurowanej przez Flyvbjerga. W budżecie i harmonogramie jednocześnie mieści się 8,5% z nich. Gdy do tych dwóch warunków dołożyć dowiezienie obiecanych korzyści, zostaje 0,5%. Autorzy nazywają to żelaznym prawem megaprojektów, a jako przyczyny wskazują skrzywienie optymizmu oraz strategiczne zafałszowanie, czyli celowe zaniżanie kosztów i zawyżanie korzyści po to, żeby przedsięwzięcie w ogóle ruszyło. Dane o korzyściach pochodzą tam z wyraźnie węższego podzbioru niż dane o koszcie i czasie, więc liczba 0,5% stoi na cieńszej podstawie niż 8,5% i tak ją traktuję.

Rzecz w tym, jaką receptę z tego wyprowadzają. Nie brzmi ona „znieście projekty”. Brzmi „myśl wolno, działaj szybko”, a obok niej stoi postulat budowania modularnego. Obie domagają się jeszcze więcej dyscypliny przed startem i jeszcze krótszego okna wykonania. Jeżeli największym zabójcą dużych przedsięwzięć jest zafałszowane uzasadnienie i rozlewający się zakres, to program bez daty końca i bez rozliczenia nie jest lekarstwem na tę chorobę. Jest tą chorobą w postaci czystej, z lepszym słownictwem. Program transformacji, który co kwartał raportuje postęp w slajdach i nigdy nie raportuje wyniku, przeżyje w firmie dłużej niż nieudany projekt, bo nie ma bramki, na której mógłby polec.

Do tego dochodzi argument klasyfikacyjny, który uczciwie zamyka zakres tezy. Część inicjatyw AI naprawdę jest projektami IT. Wymiana silnika optycznego rozpoznawania znaków na model językowy ma skończony zakres i jasne kryterium odbioru. Tak samo podmiana dostawcy API na tańszego albo przepięcie rekomendacji na nowszą wersję biblioteki. Takie prace dzieją się w systemie, który już ma właściciela i już siedzi w linii utrzymania. Podnoszenie takiej wymiany do rangi zmiany modelu operacyjnego kosztuje dwa kwartały uzgodnień i nie kupuje niczego. Sam Narayan robi to rozróżnienie: w budownictwie tryb projektowy ma sens, bo kompetencje budowania i utrzymywania naprawdę się różnią, a w oprogramowaniu różnią się mniej, więc rozdział budowy i utrzymania kosztuje więcej, niż daje. Tryb produktowy nie jest zatem uniwersalnie lepszy; jest właściwy dla pracy, która nie ma naturalnego końca, a błąd klasyfikacji kosztuje w obie strony.

Gdzie zatem przebiega granica? Przebiega tam, gdzie przebiega mandat. Jeżeli inicjatywa wymaga zmiany czyjegoś procesu, przesunięcia decyzji między stanowiskami albo zmiany tego, za co ludzie dostają premię, żaden kierownik projektu nie ma uprawnień, żeby to dowieźć, i struktura projektowa jest błędem klasyfikacji. Jeżeli inicjatywa nie rusza niczyjego procesu i ma właściciela z dnia przed startem, prowadź ją jak projekt, postaw twarde bramki i zamknij ją w terminie. Test na to jest jednozdaniowy: sprawdź, czy sukces inicjatywy wymaga, żeby ktoś poza zespołem wdrożeniowym zaczął pracować inaczej.

Obie dyscypliny naraz

Najgorsze, co można zrobić z tym rozróżnieniem, to zamienić je w hasło i przestać stawiać bramki. Trzymaj więc oba narzędzia naraz: rozliczaj jak projekt to, co ma koniec, a to, co końca nie ma, oddaj komuś, kto w dniu 400 straci premię, gdy wykres pójdzie w dół. Jeśli nie umiesz dziś podać tego nazwiska, budujesz coś, czego nikt nie przejmie.

Bibliografia

1. primaryMelvin E. Conway, How Do Committees Invent?, Datamation, kwiecień 1968 — sformułowanie kanoniczne prawa Conwaya oraz korolarz o elastyczności organizacji przypisywany Brooksowi.
2. primaryNagappan, Murphy, Basili, The Influence of Organizational Structure on Software Quality: An Empirical Case Study, ICSE 2008 — 3404 binaria Windows Visty; metryki organizacyjne, w tym NOEE; studium przypadku korelacyjne, ograniczona trafność zewnętrzna zgłoszona przez autorów.
3. primarySriram Narayan, Products over Projects, martinfowler.com, 20 lutego 2018 — sześć wymiarów różnicy między trybem projektowym a produktowym; brak mechanizmu weryfikacji korzyści po dostawie; własne rozróżnienie autora co do prac o skończonym zakresie.
4. primarySculley i in., Hidden Technical Debt in Machine Learning Systems, NIPS 2015 — udział kodu ML w rzeczywistym systemie, zasada CACE, dług spłacany w utrzymaniu.
5. primaryVela, Sharp, Zhang, Nguyen, Hoang, Pianykh, Temporal quality degradation in AI models, Scientific Reports, 2022 — starzenie modeli jako zjawisko odrębne od dryfu danych; 128 kombinacji model–zbiór, degradacja w 91%; klasyczne modele predykcyjne, nie modele językowe.
6. primaryRyseff, De Bruhl, Newberry, The Root Causes of Failure for Artificial Intelligence Projects and How They Can Succeed, RAND RR-A2680-1, 2024 — badanie jakościowe, 65 wywiadów; liczba „ponad 80%” jest w tym raporcie cytowanym cudzym szacunkiem, nie wynikiem RAND.
7. primaryRozporządzenie Parlamentu Europejskiego i Rady (UE) 2024/1689 (akt w sprawie sztucznej inteligencji), art. 17 i art. 72 — system zarządzania jakością obejmujący cały cykl życia oraz monitorowanie po wprowadzeniu do obrotu; obowiązki dostawcy systemu wysokiego ryzyka.
8. primaryJørgensen, Moløkken-Østvold, krytyka raportów CHAOS Standish Group [DO UZUPEŁNIENIA: tytuł pracy, czasopismo i rok] — nieujawniony plan badania, nieopisane kryteria doboru i chwiejne definicje sukcesu; statystyki niepowodzeń projektów IT nie nadają się do porównań.
9. secondaryGartner, komunikat prasowy z 7 kwietnia 2026 o badaniu 782 liderów infrastruktury i operacji (I&O) przeprowadzonym w listopadzie i grudniu 2025 — 28% zastosowań w pełni udanych, 20% nieudanych; samoocena respondentów, jednostką analizy jest zastosowanie w I&O. Liczby za relacjami prasowymi, ponieważ newsroom Gartnera nie udostępnia komunikatu do pobrania automatycznego (stan na 12 września 2026).
10. secondaryMcKinsey / QuantumBlack, The State of AI, edycja 2025, n = 1993 — 21% organizacji deklaruje fundamentalne przeprojektowanie części przepływów pracy; najsilniejszy związek tej cechy z wpływem na EBIT; ankieta samoopisowa, korelacja.
11. secondaryMik Kersten, Project to Product: How to Survive and Thrive in the Age of Digital Disruption with the Flow Framework, IT Revolution, 2018 — finansowanie kamieni milowych przy zakresie zdefiniowanym z góry; rama praktyczna oparta na doświadczeniu autora.
12. secondaryBent Flyvbjerg, Dan Gardner, How Big Things Get Done, 2023 — żelazne prawo megaprojektów, 8,5% i 0,5%, skrzywienie optymizmu i strategiczne zafałszowanie; baza własna autora, dane o korzyściach na węższym podzbiorze.