How to Set a Realistic AI Project Timeline

At a retirement planning firm, the first working agent was live in the first week of the engagement. A prospect fills in a questionnaire before a first meeting, the agent reads it, summarizes the pain points in the vocabulary of the firm's own sales method, and writes a task to the advisor.

At a national wealth management firm with several hundred advisors, an advisor portal took twelve weeks of build time, after planning and product work that ran through the spring, and went to advisors as an MVP in mid-September.

One week and twelve weeks. Both are ours, both are from this year, and neither one answers the question I get on a first call.

To set a realistic AI project timeline, size each build by how many systems it touches and who has to accept it. One trigger writing to a record that already exists takes about a week. An application on data that has to be consolidated first takes a quarter. What sits between those two is decided by access, not by code.

What takes a week and what takes a quarter

Nearly everything we delivered this year falls into one of four tiers, and the tier is fixed before anyone writes code.

1. One trigger, one destination that already exists: about a week. The intake agent above is the shape. A form arrives, one model call reads it, one record gets written. Nothing had to be consolidated first, which is the only reason it was quick. The full story of that engagement has its own post.
2. A brief assembled from one system: a week or two. At the same firm, a job runs early each morning, reads the next forty-eight hours of meetings out of the CRM, pulls the account and the contact history, and writes a brief to the meeting record and the advisor's inbox. More moving parts than the intake agent, and the same single source underneath.
3. A generator over databases you have to build first: a month or more, then testing. For a grant consulting firm we built a packet generator that produces a complete application packet in one click. It was delivered in mid-July and has been in the client's hands for testing since. The build was the short part.
4. An application on a data platform, with a pilot at the end: a quarter, and that is fast. The advisor portal above. Planning through the spring, twelve weeks of build from the end of June, an MVP in mid-September, and an advisor pilot that started on 21 September. The firm's own data team had already built the lakehouse it sits on. Without that, add a quarter.

Discovery sits outside all four tiers and before them. At a multi-office law firm it was nineteen interviews over seven weeks before we proposed a single build. At a licensed apparel company it was about thirty interviews. Interview time is calendar time, and it belongs on the plan as its own line rather than inside the first build.

Where the time actually goes

What moves a date is almost never how hard the software is. In our work it is one of three things, and all three sit on the client's side of the table.

Access. A credential to a source system comes from a person who has a day job and good reason to be careful. In a regulated firm it is a security review with a real queue in front of it. We hit this with our own tooling: as the pilot above reached release, our product analytics had not yet cleared review. Without that data, a rollout decision for several hundred people gets made on impressions. That was our planning, not theirs, and the week to put a date on a review is the week the scope is written.

Data that has to agree before anything can read it. The rule we use: anything that needs data reconciled across more than two systems is a data project with an automation on the end of it. Price it as a quarter. If two systems disagree about what a customer is, nothing downstream of them can be estimated honestly, and the reconciliation is the project.

The person who accepts it. A build is finished when the person who does the work says it is right, and that person has a week of their own. One hour of their attention, three weeks out, is a date you do not control. Name them in the scope, ask their manager for the hour in writing, and put it in the calendar before the sprint starts.

How to write a date somebody can hold you to

One date for a whole program is a wish. Four dates, each owned by a named person, is a plan.

Write them in this order: the date access is granted, the date a user first sees working software on real data, the date a named person accepts it, and the date it is in daily use by everyone who should have it. The first and the third belong to the client. We own the second and the fourth with them.

That shape is also what keeps a pilot from running forever. A pilot with an acceptance date and a named signer ends in a decision; a pilot without one ends in another pilot, which is the whole argument of the one-page pilot plan.

And give the estimate a confidence that matches what you know. Before discovery, the honest answer to how long a build takes is a tier and a range, not a number. We quote about a week for tier one builds and we hit it, because that tier has nowhere to hide. Nobody should quote tier four before they have seen the data.

The test to run on your current plan

Take the build at the top of your list, find the date on it, and ask one question about that date: who on your side owns it.

If the answer is a builder, a vendor, or nobody, you are holding an estimate of the work rather than of the project. Access, a decision and a sign-off all come from inside your own company, and each is an hour out of a week that is already full.

So split that one date this week. Access granted. A user sees it working. A named person accepts it. In daily use across the team. Put a name next to each.

The date that slips is almost always the one nobody on your side ever owned.