Running Projects in Parallel

Most AI adoption frameworks lead with portfolio thinking. They construct elaborate matrices for balancing risk and reward, structured investment categories, and a portfolio shape the leadership team is asked to commit to before any actual projects have been run. This framework deliberately does the opposite. Portfolio thinking is held back at the start, on purpose. It only becomes useful once enough projects are running to have a portfolio worth thinking about.

This chapter explains why portfolio thinking is deferred, when it should be introduced, what the portfolio review actually looks like in practice, and what portfolio thinking is not.

Why portfolio thinking is deferred

The framework’s bias toward motion sits at the heart of this. Getting projects running matters more, in the early phases of an AI adoption effort, than balancing them. An organization with one project does not have a portfolio. It has a project. An organization with two projects has two projects. Trying to apply portfolio discipline at this scale produces premature optimization — the team spends time arguing about whether the project mix is balanced when there isn’t enough actual evidence to know what the right balance even looks like.

There is a more substantive reason as well. The right portfolio shape depends on what the organization learns from running projects. The first project teaches you what your data quality is actually like. The second teaches you whether your governance can keep up. The third teaches you whether the cultural envelope you sketched on the canvas matches the cultural envelope that holds up under real outputs. By the time three or four projects have run, the organization knows enough to make portfolio decisions on the basis of evidence rather than theory. Before that point, portfolio thinking is just a more elaborate form of advance planning, with all the same problems Chapter 1 named.

This is also why the framework’s early phase, detailed in Chapter 18, is not about constructing a balanced portfolio. It is about getting two or three projects in motion. The portfolio shape will emerge from what those projects reveal.

When it kicks in

Portfolio thinking becomes useful at roughly the three-project mark, and necessary at the four-project mark. Before three: you are running projects, learning, hardening canvases. At three: comparison across canvases starts to produce signal. At four: trade-offs become unavoidable, because each new project consumes capacity that another project could have used.

The signal that portfolio thinking has become necessary is usually a specific kind of conversation that starts happening on its own. Someone notices that two projects are competing for the same data source. Someone else notices that three projects all need the same person’s attention. A leader asks, “what would we do if we could only run two of these instead of four?” These are portfolio questions. When they start arising, the framework has crossed the threshold where structured portfolio review needs to exist.

Before this threshold, attempts to formalize portfolio review tend to feel hollow. After it, the absence of portfolio review starts to produce decision drift — projects competing for resources without anyone making explicit calls about how the trade-offs should be resolved.

The portfolio review

The operational form of portfolio thinking in this framework is the portfolio review. On a regular cadence (specified in Part V), the people responsible for the active project canvases — the AI Enablement Lead, project sponsors, members of The Forge — sit together and look across the full set of projects. This is the gardener walking the rows: deciding what to feed, what to prune, what to transplant, and what to pull out entirely.

The review covers four things.

Status across canvases. Each project’s canvas gets a brief status read — what has hardened, what has changed, what is approaching graduation. The point is not to relitigate each project but to make the full set legible at a glance. The canvas is the artifact that makes this possible. Without it, status reads tend to drift into anecdote; with it, the conversation stays on what the evidence actually says.

Portfolio shape against strategy. The active set of projects gets compared against the priorities in the Strategic Loop. Are we still working on the things we said we cared about? Has the strategy shifted in a way that makes some projects less relevant? Are there strategic priorities that have no project working on them? This is where strategy and projects re-anchor to each other.

Trade-offs and capacity. Where there are competing demands — for the same data, the same person’s time, the same governance attention — the review is the venue where those conflicts get resolved explicitly. Some projects accelerate. Some are slowed deliberately. Some are paused. This is harder to do than it sounds, because the natural pull is to keep everything running at low intensity rather than make the call to focus. The review’s job is to force the call.

Patterns surfacing for policy. This is the review’s most important function for the framework as a whole. When the same readiness gap, the same risk question, or the same governance bottleneck shows up across multiple canvases, that recurrence is the signal that a pattern has moved into candidacy for the policy layer. The review names these patterns out loud and either escalates them or files them for the next review’s tracking. Without this step, patterns surface invisibly — the policy layer never gets the input it needs to fill in.

The review’s outputs are short and explicit. Which projects continue. Which graduate. Which shut down. What gets escalated to the Strategic Loop for revision of the mental model. What gets handed to the policy layer as a candidate for hardening. A portfolio review that ends without these explicit outputs has not actually been a portfolio review — it has been a status update with extra slides.

What portfolio thinking is not

It is worth naming what this framework does not mean by portfolio thinking, because the term arrives loaded with adjacent disciplines that bring their own assumptions.

It is not a prioritization mechanism for selecting projects. That work happens in the Strategic Loop, in Chapters 5 and 6. By the time a project is on the canvas, it has already cleared a strategic alignment test. Portfolio thinking is about how a set of already-selected projects should be balanced and resourced — not about which projects to start.

It is not a comprehensive portfolio management discipline imported from product or finance. The framework deliberately keeps portfolio thinking light. There are no portfolio investment categories with target allocations, no balanced scorecards, no mandatory genre mix. The active project set should reflect what the organization is actually trying to learn and accomplish; trying to force genre balance produces theater.

It is not a justification for slowing down. The most common abuse of portfolio thinking is to use it as a reason not to start a new project — “we need to think about the portfolio implications first.” The framework’s posture here is the opposite. New projects are added when there is strategic pull and capacity available. Portfolio thinking sharpens trade-offs that already exist; it does not prevent new motion.

From projects to policy

The portfolio review is also the structural connection between Part III and Part IV. The patterns that surface in portfolio reviews are the inputs that fill in the Global Policy Layer. A pattern that shows up in one project is the project’s problem to solve. A pattern that shows up across three projects, surfaced in a portfolio review, is a candidate for hardening.

Part IV takes up what happens to those patterns once they are surfaced — how they cross from project-level concern to organization-level rule or standing function, who decides when that crossing happens, and what kinds of policy actually emerge as the layer fills in.