Standardize the Component, Not the Project

What the paper develops

A project folder is evidence, not a standard

A successful project finishes and its documents enter a shared repository. Another team copies them, changes what does not fit, and saves a second version. Soon the organization has several files with similar names, uncertain owners, and conflicting rules. The artifacts survived. The learning did not become dependable.

PMI’s mature lessons-learned practice makes the missing work clear: capture is followed by analysis, retrieval, management action, and tracked follow-through. A GAO review of NASA reached the same boundary from the other direction. NASA had an agency-wide lessons system, yet the review found no assurance that lessons were being applied to later missions. Storage helps people find material. It cannot decide what the organization should rely on.

That decision belongs in the operating model. The EPMO can turn repeated project learning into a shared asset by promoting the smallest useful component, protecting the variation that context requires, and making the component’s lifecycle visible.

Promote the component that can travel

Whole projects are poor units of standardization. Their sponsors, technologies, contracts, risks, and delivery histories differ. Copying the whole project imports those local assumptions and produces a large template that teams must obey or quietly dismantle.

A reusable component is narrower. It may be an intake question that exposes whether a sponsor can name the outcome. It may be a decision record, source standard, readiness check, exception route, measure definition, or handoff rule. Each has one operating job and can be tested apart from the project that produced it.

The component needs a stable core and an explicit edge. The core states what must remain true. The edge states where local judgment begins. APQC’s process guidance supports context-driven variants alongside reference models and process governance. The standard is therefore the governed relationship between the shared core and its legitimate variants.

Promotion must be earned

A useful artifact should not become a standard because an executive likes it or one project went well. Promotion is a portfolio decision about whether another team should be able to rely on it. I use five states to manage that decision: iterate, mature, canonize, lock, and monitor.

Iterate keeps a new component close to the work while its purpose and limits are still being learned. Mature tests the core in another setting. Canonize publishes the supported core, owner, boundary, variants, and known limits. Lock places silent local edits under a visible change path. Monitor watches use, exceptions, workarounds, and obsolescence. These states are my governance framework, not an industry maturity scale or a promise of return.

Run a project-to-standard review

The review should stay small enough to make a decision at the table. Seven questions keep it honest:

Repeated component: What exact part of the work has appeared in more than one project?

Evidence of reuse: Where did another team use the core, and what changed at its intended operating point?

Owner: Who can judge the core, approve variants, publish change, and retire it?

Approved variants: What stays stable, where does local choice begin, and which differences are sanctioned?

Version path: How does a proposed change become part of the core, an approved variant, a rejection, or a request for more evidence?

Exception signal: Which repeated workaround, override, or failure forces review?

Retirement trigger: What would make the component obsolete, redundant, unsafe, or too costly to maintain?

Distribution is not evidence of reuse. Downloads and page views show exposure. The stronger evidence shows that the component entered the work at the intended point and changed a named ambiguity, handoff, or control condition. A project can attach a standard decision record while making the real choice in an unrecorded side meeting. The review must see that difference.

Variation is design data

Legitimate variation is part of the asset. PMI’s innovation-governance research describes the tension between rigor and flexibility and recommends governance tailored to context. The practical answer is to give each departure a status.

An approved variant repeats under a named condition and preserves the component’s purpose. An exception permits a bounded departure for one case, with an owner and a return condition. A proposed core change shows that the shared rule no longer handles the work it was meant to govern. Variants are published, exceptions are watched for recurrence, and core changes enter the version path. Treating all three as local customization would hide the signal that improves the component.

Keep the EPMO in its lane

The EPMO governs promotion; it does not author every component or pull every local choice upward. Subject-matter owners retain authority over the content. Project leaders retain responsibility for fit. Control functions keep their existing rights.

The EPMO is positioned to scan across projects, convene the promotion decision, keep the core and approved variants visible, and aggregate exception patterns that one project cannot see. It should also resist turning every useful local practice into an enterprise obligation. Maintenance is real work, and many candidates should remain local.

A shared component earns reliance when another team can use its stable core, select a valid variant, find the current version, reach an accountable owner, report an exception, and know when the asset should retire. That is organizational learning made inspectable — without pretending that every project should look the same.