Capability Projects

Not every project in this framework is an operational AI implementation. Some exist to build the capacity of the organization to use AI — workshops, communities of practice, internal forums, fluency programs. These are capability projects. They are projects in their own right and run through the same canvas as any other initiative, with the same readiness, roadmap, and risk sections. They are also, in the early stages of an AI adoption effort, often the projects that produce the most leverage.

This chapter explains why capability projects belong on the canvas, what makes them distinctive, and the particular logic by which they should be built — a logic of pull, not push.

Why capability projects are projects

Most organizations treat training as something that runs in parallel to operational work — disconnected from where the actual learning happens. The default mode is push: curriculum gets designed and shipped out, often by L&D teams that know the push model is suboptimal but are constrained by organizational expectations to operate that way. Some people show up. Few of them apply what they learned. The organization concludes that AI training is hard and moves on.

This framework treats capability building differently. It is not a parallel function that runs alongside the AI adoption effort. It is part of it. The forums, workshops, meetups, and programs that build AI fluency are individual projects, each one running through the same canvas as a customer support automation or a pricing optimization. Each has a readiness section (who is running it, who it is for, what fluency level it is starting from). Each has a roadmap (the pilot offering, graduation criteria, KPIs that evolve from experiential to operational). Each has a risk section (what could go wrong, who is involved, what is the stance if this works very well, what is the oversight).

Treating capability work this way has two effects. First, it gets evaluated against the strategy with the same discipline as everything else — capability projects need a strategic anchor too, even though their anchor is usually some version of “the organization needs to develop fluency in X to do anything useful with AI.” Second, it gets the same kind of structured learning loop. A capability project that runs without graduation criteria drifts the same way an operational project does. A capability project that does not track experiential KPIs early ends up measured on attendance, which is a coverage metric, not an evidence metric.

There is also a path question worth flagging. An emergent discovery — someone tinkering in their domain finds something interesting — that does not yet have a clear operational strategic tie can enter through the capability-project pathway. Its strategic relevance becomes “we need to learn how AI handles this kind of work.” That gives weak-but-promising emergents a legitimate way in without diluting the strategic-alignment test for operational projects.

Build community, let demand pull

The most distinctive thing about capability projects is the order in which they should be built. The temptation is to design a curriculum first, push it out, and hope for adoption. The pattern that actually works is the reverse.

Capability development in this framework follows a pull model. The organization invests first in the lightest-weight, broadest forms of community — forums, channels, newsletters, places where people can show up and ask questions and share what they have tried. These are cheap. They are not framed as “training.” They are framed as conversation. The point is to make AI a thing people are talking about, with each other, in a way that surfaces curiosity and friction and surprise.

As community heat builds, demand for next-level offerings starts to surface. Some people in the forum want to actually meet, share what they are working on, see what others are doing — that demand is what makes meetups sensible. The meetup is justified not because the L&D team wanted to run one, but because there were people asking for it.

As meetups produce regular conversations and visible artifacts, a subset of attendees start asking for something more structured. They have specific things they want to learn. They want skill-building, not just conversation. That demand is what makes workshops sensible. A workshop with no underlying meetup demand will be poorly attended; a workshop with strong meetup demand will be oversubscribed.

As workshop graduates start asking for sustained engagement — cohorts, longer programs, multi-week development — that demand is what makes programs sensible. A program built without prior workshop demand is curriculum hoping for an audience. A program built on top of workshop demand is a structured response to people who have already shown they want it.

Each step up the chain is justified by the demand from the step below. This is what the framework means by pull. Under this model, the L&D team — partnering with the AI Enablement Lead — does not decide what the organization needs to learn and then push it. They watch the community, listen for the demand to thicken, and stand up the next-level offering when the pull is strong enough to sustain it.

The signal that an organization has gotten this wrong is a workshop or program that nobody attends, attended grudgingly, or attended out of obligation. That is curriculum pushed without underlying pull. The remedy is to back up — strengthen the layer below, let the demand build, try the next-level offering again later.

The same canvas, applied differently

Capability projects use the same canvas as operational projects, but the answers in each section have a particular character.

Readiness. The People dimension covers who is facilitating the offering and who it is for; trust and capacity matter as much as skills. Data is usually less prominent (capability projects rarely depend on internal data sources), but is not absent — sometimes a workshop uses internal artifacts as material. Culture and governance matter for the standard reasons. Incentives are interesting: the question is whether anyone in the organization is rewarded for capability building working, or whether it remains a “nice to have” that nobody is materially on the hook for.

Roadmap. The pilot phase is the first cohort, the first meetup, the first issue of the newsletter. The graduation criteria specify what would justify continuing, expanding, or shutting it down — sustained attendance, repeat participation, demand for next-level offerings, qualitative shifts in how AI shows up in adjacent operational projects. The KPIs evolve from experiential (did this feel useful, did people stay engaged, what did they ask for next) to operational (number of facilitators trained, number of cross-functional collaborations seeded, downstream operational projects that traced back to this work).

Risk. The four day-one questions still apply. What could go wrong is mostly second-order: the wrong fluency gets built, people learn habits the organization does not actually want at scale, the offering becomes a place where misinformation about AI capabilities propagates. Whose data is involved is usually limited but not zero — internal artifacts may surface things that need to be handled carefully. Ethical stance if this works too well is worth taking seriously: what happens if everyone in the organization becomes fluent — does the organization need to redesign roles, redistribute work, change who makes decisions? Autonomy and oversight is usually less applicable, but worth considering if any part of the offering runs autonomously (an AI-facilitated forum, for instance).

Capability projects feed the policy layer

Like any other project in this framework, capability projects feed the Global Policy Layer. The patterns that emerge are some of the most important the organization will absorb.

When the same fluency gap shows up across multiple operational projects and multiple cohorts, that gap belongs to the organization. It becomes a candidate for the L&D function to take on as a standing offering — not a one-time workshop, but a permanent capability the organization maintains. The L&D function’s approach to AI fluency takes shape based on what these projects reveal: which fluencies turned out to matter, which forms of community produced the strongest pull, which kinds of program graduates produced the strongest downstream operational results.

The L&D function in an organization running this framework operates differently as a result. The push-based default gives way to a pull-based one, content shifts from anticipated to evidenced, and the standing offerings reflect what the framework’s projects have actually surfaced. The function is not replaced; it absorbs new responsibilities into its existing craft, in partnership with the AI Enablement Lead.

The next chapter takes up the question of how all of this — operational projects and capability projects — works together when more than one project is in flight at the same time.