AI won't make your COTS implementation faster

I don't think AI will make your processes go faster, published this week by Frederick Vanbrabant, made an argument that will be familiar to anyone who has spent time in delivery. AI will not make your development process faster because in most projects the bottleneck is not in development. When AI handles the development work, scoping tends to expand to compensate, because AI needs precise specifications to produce anything useful. The bottleneck moves upstream rather than disappearing.

In the realistic AI scenario Vanbrabant models, the project takes 148 days, three more than the original 143, and longer than without AI at all. The explanation sits in what Goldratt called the theory of constraints, not project constraints (scope, schedule, budget) but the constraint in a production system: the single step that limits the throughput of everything else. Eliyahu Goldratt introduced the idea in 1984 through a business novel about a failing manufacturing plant where one overloaded machine was setting the pace for the entire facility. Speed up any other machine and nothing changes; only the constraint matters. The original project runs to 143 days: 70 days of software development and 73 days of everything surrounding it, including scoping, legal review, exploration, documentation, deployment and hyper-care. Development and non-development time are roughly equal before AI enters. In the AI-optimistic scenario, development drops from 70 days to 3. In the realistic scenario, documentation alone expands from 5 days to 40, because AI needs precise specifications before it can produce anything useful, and those have to be written explicitly rather than worked out inside the development iteration. A feature request like "send mail to user once sale is completed" requires interpretation on every edge case. Who is the sender? What triggers the retry? What counts as a completed sale? AI can execute once those decisions are made, but it cannot make them.

The post is written as a software development article, but the pattern it describes runs directly into the delivery context most enterprise and government PMs work in. The mainstream of enterprise IT is not bespoke builds; it is buying and configuring products that already exist. COTS implementations account for most of the programme work in large organisations, and in that context development is rarely the constraint to begin with. The constraint is requirements, not in the abstract but in the specific work of deciding how an existing product gets configured, extended and worked around to fit how the organisation actually operates. In COTS delivery, slow build times used to provide a buffer; you could negotiate requirements gaps with the vendor as the project progressed. As AI accelerates the build, that buffer disappears.

That difference matters for how you think about requirements. With a bespoke system you are shaping what gets built, working directly with the development team. With COTS, the product already exists and in most cases you are not directly influencing its functionality. Your requirements work is about defining what the system needs to do for your organisation.

In a COTS implementation, requirements need to drive configuration decisions and document the gap between how the product works and how the organisation works. The workflow states a COTS product supports may not, and often do not, map cleanly to the business states the organisation actually operates in. Where the business has states that sit outside the application's model, the requirements work is to document that gap, decide how to handle it and ensure the configuration reflects the decision. Getting field labels right matters for training and user error rates. The cost is a different magnitude from getting the state-model mapping wrong. Where the product's state model does not match how the organisation actually operates, users run into problems every time they use it that renaming fields will not fix. The tech debt that builds up in poorly configured COTS systems (repurposed fields, relabelled columns, workarounds baked into the configuration) often traces back to requirements that were not precise enough about how the product needed to map to the business.

COTS systems do not address every requirement, and some processes remain out of system, managed through notes, paper records or adjacent tools. When nobody has documented which processes sit outside the system, trainers default to covering the software. Users leave training knowing how to navigate screens but not knowing what to do when their workflow diverges from what the system supports. Those gaps do not surface until go-live, when people fill them with the same workarounds the implementation was supposed to replace. Change management is the work of getting the organisation to the new way of working, including the processes the system does not cover. Without requirements that define that boundary, neither trainers nor change managers know what they are responsible for.

You only have so much testing time. In a COTS implementation, that means your focus needs to be on the delta (the configuration, the customisation, the integrations with manual processes and the elements that sit outside the system) rather than verifying that the base product works. The vendor's existing customer base has already done that. The larger and more established the product, the more confident you can be that core functionality is sound; your testing effort belongs on what makes your implementation different from everyone else's. Requirements that are precise enough to define the delta give your testers something to focus on. With generic requirements, the real problems stay invisible while tests confirm the system runs. Without requirements specific enough to define what was agreed, there is no solid basis for verifying what vendors actually deliver.

What AI can now do is produce requirements that are well-structured, draw on patterns from other implementations and cover the standard categories. What it will not do on its own is understand that your organisation's workflow has states the application does not model, or that integrations with other systems have timing constraints the standard approach does not account for. That knowledge is held by the SMEs who live in the workflow and the PM who has spent time understanding the gap between the product and the organisation.

What AI does well is reasoning about requirements, identifying inconsistencies, generating test cases and checking completeness across a large body of documentation. What it cannot supply is accountable business context. Getting requirements right in a COTS implementation means working out what the system can and cannot do in relation to how this organisation operates, and that involves negotiation, not just analysis. The people who know which processes sit inside the product, which sit outside it and why those decisions were made are the SMEs and the PM. A PM who has implemented similar systems before brings better priors about where the gaps typically appear. AI brings better document coverage. The work that gets missed tends to fall between the two.

Goldratt's plant manager eventually saved his factory, not by buying faster machines, but by identifying which machine was the constraint and organising everything else around it. In a COTS implementation, that machine has always been requirements. Resolve the product-to-organisation fit questions before configuration locks them in. That is the work AI cannot do for you.