Floburn.
Floburn Journal·Implementation

The two-week diagnostic: what an AI readiness assessment actually looks like.

Anatomy of Floburn's standard two-week diagnostic engagement. Stage check, current-state map, recommendations, scope for the build. Includes what we don't do.

By Floburn·May 13, 2026·6 min read

title: "The two-week diagnostic: what an AI readiness assessment actually looks like." dek: "Anatomy of Floburn's standard two-week diagnostic engagement. Stage check, current-state map, recommendations, scope for the build. Includes what we don't do." date: "2026-05-13" pillar: "implementation" author: "floburn" tags: ["diagnostic", "engagement-shape", "ai-readiness", "scoping"]

The first paid engagement on the Floburn side, almost every time, is a two-week diagnostic. It's the smallest unit of work we sell. Most engagements that turn into multi-month implementations start here. This post walks what's actually in it.

The diagnostic exists because every other shape of opening engagement has a hidden cost. A free assessment runs the risk of being too shallow to be useful; a scoped implementation requires assumptions about the operating environment that nobody on either side has tested yet. The two-week diagnostic is the work both sides need to do before anyone can responsibly scope an implementation.

It is a real engagement with a real fee — $11,500 when the work runs through outside counsel for compliance-touching engagements, $7,500 when it doesn't. It produces a real deliverable. If we don't do the build that follows, the deliverable still has value as an artifact — the client can hand it to a different vendor or run the implementation themselves. We won't say that's the better outcome for us; we will say the diagnostic is honest on its own terms.

Week 1: Discovery

Day 1–2 is stakeholder interviews. We talk to four to seven people, depending on company size. The mix is usually:

  • The owner or CEO, or whoever owns the budget for this engagement
  • The operational leader most affected by whatever AI is being considered
  • One or two people who actually do the work the AI would touch
  • The CFO or finance lead, where the engagement has a meaningful cost or risk dimension
  • IT or operations, where systems integration is in scope
  • Outside counsel where compliance is in scope

Each interview runs 45 to 60 minutes. The questions vary by role but converge on the same answers: what work are you doing, what's the bottleneck, what's already been tried, what's actually different about doing this now. We take notes, we don't record. The output is internal.

Day 3–4 is technical inventory. We map the relevant systems: HRIS, timekeeping, payroll, CRM, ticketing, data warehouse, the systems that produce or consume the data the AI would touch. We look at authentication patterns, API quality, data volumes, and the gaps between what the documentation says and what's actually in the database. Most of this is desk research from access the client provides.

Day 5 is baseline measurement. We pick the two or three metrics most relevant to the engagement, and we measure them at current state. This is sometimes a literal measurement (we sample 100 records, count something, divide by something else) and sometimes a documented estimate based on operator interviews. Either way, the baseline is in writing, with its methodology, before any AI work begins.

Week 2: Synthesis

Day 6–8 is the analysis. We sit with the discovery output and turn it into a current-state map. Where is this business on the Harness Map? What's the cliff this business is looking at? What's the operating constraint that has to be solved before the AI is helpful? What are the dependencies? What's the risk profile?

For compliance-touching engagements, Day 7 includes the outside counsel pre-implementation review. Counsel walks the proposed framework and the baseline measurement, raises questions, recommends adjustments. Floburn's principals work through counsel's notes. The framework that emerges has counsel's review reflected in it.

Day 9 is the recommendations draft. We write the assessment as a document, not a deck. It's structured as: what we found, what we recommend, what we don't recommend, what the implementation would cost and take, what we'd need from you. It's typically 8 to 15 pages, depending on the engagement scope.

Day 10 is the readout. We walk the assessment with the client's leadership team in a single meeting, 60 to 90 minutes. The document is sent ahead. The meeting is for questions, not for first reading. At the end of the meeting, the client has the document, the recommendations, and a scope for whatever the next phase would be if they want to proceed.

What's in the deliverable

Every two-week diagnostic produces the same shape of deliverable:

Section 1: Current state. Where the business is on the Harness Map. What systems are in play. What the baseline metrics look like. What the operating constraint is. This section is descriptive, not prescriptive.

Section 2: Recommendations. What we'd build, if we built. What we wouldn't. Why the things we wouldn't do are the things we wouldn't do. This section names the recommendations specifically — build X in 6 weeks; defer Y; don't do Z — and gives the reasoning per recommendation.

Section 3: Scope. If the recommendations point at a build, the scope of that build is documented at the level a client could take to another vendor. Sprints, deliverables, dependencies, integration list, cost band, timeline band. If the recommendations point at don't build, the scope section explains what to do instead.

Section 4: Risk register. What we think could go wrong, in priority order, with an honest assessment of each one. This is the section clients reread the most.

Section 5 (compliance engagements only): Counsel attribution. Named outside counsel reviewed the framework. The disclosure that counsel does not represent the client is included in writing.

What's not in the deliverable

The diagnostic is not a full implementation plan. It's not a build. It's not training. It's not a procurement-ready RFP. It's not a contract for ongoing work.

It is also not, despite the name, a readiness score. We don't grade clients on a 1–10 scale or claim to know with precision which Harness Map stage they're at — we make our best read and we say it's our best read. The point of the diagnostic isn't to sort companies into buckets. It's to give the leadership team a shared, written read on what's actually there to work with.

Why two weeks

Shorter than two weeks doesn't allow real measurement. The baseline measurement on Day 5 requires sampling, which requires sitting with the data, which takes a day. The synthesis in Week 2 requires sitting with the discovery output, which takes more than a day to do well.

Longer than two weeks invites scope creep. The diagnostic is not the implementation; if it bleeds past two weeks, it usually means we've started doing the implementation work without a signed scope. That's bad for both sides — the work goes uncompensated until the next contract, and the client gets work they hadn't budgeted for.

Two weeks is the smallest window that produces a real artifact. It's the largest window that doesn't pretend to be more than a diagnostic.

What the client commits to

The diagnostic asks for four things from the client side:

  1. Access. To systems, data, and people. Read-only is fine; we don't need write access during the diagnostic.
  2. Time. Four to seven stakeholder interviews of 45 to 60 minutes. The readout meeting at the end.
  3. The fee. $7,500 standard, $11,500 with counsel review. 50% on signature, 50% on readout day.
  4. An NDA. Mutual. We send DocuSign-routable templates if the client doesn't have one preferred.

That's the engagement. If you'd like to walk whether the diagnostic makes sense for your situation, the discovery call is the right first step. The discovery call is free, 30 minutes, and not a diagnostic — it's the conversation about whether the diagnostic fits.

More from the journal
Read the index
Working on something where this is relevant?
Book a discovery call