Project KVN and False Friends

Project K — what this work requires that the workspace alone does not

Workspace K covers the standing capability assumption. Project K adds whatever is specific to this project — the customer's particular history, the dependencies that are unusual, the stack pieces this project touches that no other project does, the integrations the project will live inside.

A good project K is short — one to three sentences — and adds only what the workspace K does not already say. If the workspace K already covers the stack, the project K does not need to repeat it. The project K should add: 'this project also requires familiarity with the customer's existing Salesforce schema, their hand-coded reporting layer in Looker, and the SOC 2 controls they specifically need us to inherit.' That is information the workspace K could not have given.

The practical test: a new contributor joining the project reads the workspace K plus the project K and can plausibly ramp on the work. Anything they would need but isn't in either is missing.

Project V — the outcome at project scope

Project V is the answer to 'what does this project ship?' Specific enough that you could write the project's close-out memo from it.

A good project V names the customer (or internal stakeholder), the value, and the scope. 'So Globex's operations team can see their fulfillment delays in real time, with drill-down to the contributing factors, before their next exec review on Sep 30.' Customer named, value named, scope (drill-down with contributing factors) named, deadline named where it exists.

A bad project V is task-list-shaped. 'Build the operations dashboard with the following features.' This is a description of the work, not the outcome. It tells you what is being made; it does not tell you what 'good' looks like. When mid-project decisions come up, a task-list V cannot adjudicate; an outcome-shaped V can.

Project N — the per-project nos

Project N inherits the workspace nos and adds project-specific ones. Most projects need three to five.

Common shapes: 'We will not add features the customer's current contract does not cover; out-of-scope asks go to the AE.' 'We will not optimize for performance until we have proven the core flow works at all.' 'We will not invest in the existing Looker layer; this project replaces it.'

The project N is also where the team writes the specific things it has already agreed not to relitigate. Decisions made early in the project ('we are going with React Query, not SWR') do not need to be revisited every time someone new joins. Put them in the project N — not as decisions, exactly, but as 'we are not relitigating this' — and the conversation stops happening.

Project N is harder to write at kickoff than mid-project. The negations that turn out to matter are usually discovered after the team has been doing the work for a week. Schedule a project-N revisit two weeks in.

False friends — the under-discussed field

Kavanah's project charter has a field most users skip: false_friends. It lists other projects (in this workspace or in adjacent ones) that look similar and are not. The field exists because the most common form of project drift is not 'we did the wrong thing'; it is 'we did a thing that turned out to belong to a different project.'

If you are building the customer dashboard for Globex, its false friends might be: 'the customer dashboard for Acme,' 'the internal admin dashboard,' 'the prior customer dashboard we sunset last year.' Each of those projects had different constraints, different stakeholders, different patterns. Without explicit naming, work bleeds across — the team imports a pattern from the Acme dashboard that does not apply to Globex, or pulls a constraint from the internal admin that nobody asked for in the customer-facing build.

False friends works as a Negation accelerant. When a candidate task arrives, the agent (and the triaging human) can check it against the false-friends list — 'are we sure this isn't the kind of work that belongs to the false-friend project?' Many candidates that would otherwise have been accepted get redirected to where they actually belong.

The charter check, at three points

Kickoff. The project does not start until K, V, N, and false_friends are written. The discipline of writing them is itself the kickoff — it forces the conversation that would otherwise happen in pieces over the first sprint.

Mid-project. Two weeks in, revisit. The N especially is going to have been wrong; you have learned things. Add the negations the work surfaced.

Close. Read the project V back and write the close-out memo against it. If the project did not ship the V, do not move the goalposts in retrospect — name the gap. The pattern of gap-naming compounds: future projects' V's get more honest because past project V's were closed against honestly.