Standardize the component, not the project

What the paper develops

In one release portfolio I supported, teams reached finance testing with different scopes, calendars, and test needs. Yet each handoff needed an answer to the same readiness question. A full project plan could not move from team to team unchanged.

The same problem shows up after many projects. The files go into a shared folder. Another team copies them, changes what does not fit, and saves a new version. Soon there are several files with similar names, different rules, and no clear owner. The files survived. The lesson did not.

Rowe and Sikes's PMI paper says teams need to study lessons and act on them, not just store them. GAO found the same gap at NASA. The agency had a lessons system, but GAO found no assurance that later missions used what earlier teams had learned. A folder helps people find a file. It cannot decide which part of the work others should use.

The EPMO can help make that choice. It can find the small part of the work that teams can share, name where local choice still matters, and make sure an owner keeps it current.

Whole projects are hard to share. Sponsors, contracts, risks, and teams differ. Copying a full project brings those local choices with it. The next team must then follow a large template or quietly tear it apart.

Share a smaller part instead: an intake question, a decision record, a readiness check, or a handoff rule. Each has one job. Another team can test it without copying the whole project.

Say what must stay the same and what the next team may change. For a decision record, the decider and evidence may be required; a team may add fields for its own risks. Kirchmer's APQC report supports shared rules with valid local forms. The owner must keep both the common rule and its approved forms clear.

A useful file should not become a standard because one leader likes it or one project went well. Another team must show that it can use the same part. I call the five steps iterate, mature, canonize, lock, and monitor. These names mark choices about how much teams may depend on a component, not an industry scale or a promise of return.

Iterate means the first team can still change the idea quickly. Mature means another team tests what can travel. At canonize, the right owners approve the shared rule, its limits, and valid local forms. Lock gives changes a visible path. Monitor means the owner watches for workarounds, stale rules, and reasons to retire it.

Keep the review short enough to make a choice at the table. Ask seven questions:

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

Where did another team use it, and what changed in the work?

Who owns the rule and can approve, change, or retire it?

What must stay the same, and what may teams change?

How will people find the current version and ask for a change?

Which repeated workaround or failure will force a review?

What would show that the rule is no longer worth keeping?

Do not count downloads as proof. A team may attach the standard decision record, then make the real choice in a side meeting. Look for use at the point where the rule was meant to help.

Valid local differences belong in the shared rule. PMI-sponsored research on six large firms found a need for both firm rules and room to adapt. The practical step is to label each change so others know what it means.

An approved variant is a local form that repeats under a named circumstance while keeping the rule's purpose. A one-time exception needs an owner and an end point. A change to the shared core needs proof that the old rule no longer fits. Publish variants, watch exceptions that repeat, and send proposed core changes to the owner. Calling all three “local choice” hides what the organization needs to learn.

The EPMO guides the choice to share a rule. It does not write every rule or take every local choice away from the project. Experts keep control of the content. Project leads judge fit. Risk, finance, and other teams keep their own authority.

The EPMO can spot the same problem across projects and bring the right owners together. It can keep approved local forms and current versions visible. It should also let many useful local practices stay local. A shared rule takes real work to maintain.

Another team should be able to find the current rule, know what may change, reach its owner, and report when it fails. That is how project learning becomes useful to others without making every project look the same.