When A Vague SOW Meets T&M: The AI Wake-Up Call

The core banking upgrade is in week 6 when the vendor sends an invoice that is 30 percent higher than forecast, and your finance partner flags that the time-and-materials contract will blow the quarterly cap unless something changes now. Procurement says the statement of work is too vague to dispute the hours. Legal says the contract language gives little leverage without defined acceptance criteria. The vendor says the extra work was implied. You are stuck between paying, pausing, or escalating, and each day you wait adds billable time and slips the next milestone. This course will build the judgment and artifacts that prevent this exact trap, starting with make-or-buy framing, contract type selection as risk allocation, a tighter SOW with measurable acceptance criteria, and AI-enabled ways to draft, monitor, and evidence performance without losing auditability.

How vague scope turns into paid hours

In the post-implementation review, the failure is not that the vendor did bad work. The failure is that nobody can prove what good work means. The SOW says deliver interface updates for upstream and downstream systems, but it does not list interfaces, message formats, environments, or what counts as done. The contract is time-and-materials or T&M, meaning you pay for effort and expenses rather than a fixed outcome. That can be appropriate when requirements are uncertain, but it also means ambiguity turns into billable hours unless you control scope, approvals, and acceptance.

Before you look at the timeline, predict where the first dispute will show up, invoice, change request, or milestone acceptance.

The overrun usually starts with a reasonable sounding clarification. The vendor asks whether the loan origination feed includes edge cases. The business says yes, of course. In a fixed-price contract, that yes would trigger a scope discussion before work starts. In T&M, the team often treats it as normal progress and the vendor starts logging hours. By week 3, the vendor submits change requests that read like discoveries rather than changes, and internal stakeholders sign them because the work feels necessary. By week 5, a milestone is missed because testing data was not ready, and the vendor bills time while waiting since the contract did not define buyer dependencies and stop-the-clock rules. The common PM mistake is trying to argue fairness instead of pointing to the SOW, acceptance criteria, and an approval trail. Fairness does not survive audit. Evidence does.

Where AI actually helps in the lifecycle

Once you feel the pain, the temptation is to buy an AI tool and hope it will catch problems automatically. The more reliable approach is to map where decisions happen in the vendor and contract lifecycle and decide what AI output would change those decisions. AI can help you read and compare documents, extract obligations, flag missing terms, and monitor performance signals. It cannot replace the contract’s definition of done, and it cannot sign approvals.

Match each lifecycle stage to the kind of AI output that would reduce cost creep or dispute risk.

In intake, AI can standardize requirements and turn messy request emails into a structured draft of scope and constraints. In diligence, it can summarize vendor responses and highlight gaps against a checklist, but the checklist still needs owners. In drafting, it can propose clauses and acceptance criteria candidates, yet Legal must approve language and Procurement must align commercial terms. In monitoring, it can extract deliverables, due dates, and approval requirements from the executed contract into a tracker, then compare invoices to timesheet rules and milestone evidence. In renewals, it can surface recurring disputes and quantify how often you paid for rework or waiting time. The heuristic is simple. Use AI where the bottleneck is reading, comparing, extracting, or spotting inconsistency. Do not use AI to decide risk appetite or to substitute for sign-off.

Banking constraints that change the playbook

In banking, vendor and contract management is also a control system. You have third-party risk management or TPRM requirements, data residency limits, audit trail needs, and model risk management or MRM if AI models influence decisions. These constraints do not block AI use. They shape what is allowed, what must be logged, and what must stay human-reviewed.

Choose where your project should land on key control settings before you deploy any AI into procurement or contract workflows.