Enterprise change management
Forge scales by growing shared knowledge and Versonas before adding coordination layers. Treat rollout as operating-model change backed by repo evidence, not as a big-bang process replacement. Full multi-team patterns: scaling ForgeSDLC.
Rollout options
| Pattern | When to use |
|---|---|
| Single-team pilot | Prove flow, decision quality, and release evidence before wider mandate |
| Product-line pilot | Several teams share Blueprints; cross-team Versonas for shared components |
| Center of excellence | Maintains blueprint forks, training, and scorecard definitions—without becoming a bottleneck for every Spark |
In all cases: shared Blueprint repository (or aligned forks), consistent terminology, and milestone-level reviews for alignment without duplicating every team ceremony.
Pilot design
- Scope: one product or value stream with real delivery pressure—not a sandbox forever
- Duration: long enough for one full calibration cycle (see adoption playbook phases)
- Success signals: fewer blocked Sparks without clear owners, faster Versona decisions when invoked, release artifacts traceable to work-unit IDs, reduced status-only meetings
- Non-goals for v1: replacing portfolio tooling, certifying the whole org, or adopting every discipline blueprint on day one
Coexistence with existing frameworks
Forge is designed to coexist with common enterprise frames; discipline blueprints and journals supply evidence mapped to those expectations. Summary (expanded in scaling):
| Framework | Integration idea |
|---|---|
| TOGAF | Architecture blueprints and ADRs align with architecture repository practices |
| ITIL | Change management expectations reflected in DevOps / release readiness Versona gates |
| ISO 27001 | Security blueprint controls and session records support control evidence |
| CMMI | Policy in Blueprints plus forge journals can map to process-area evidence |
Details and audit posture: governance and evidence pack.
Governance and evidence mapping
- Controls → blueprint sections — which discipline file satisfies which organizational requirement
- Decisions → Ember Log / ADR / directive — directional and cross-cutting choices are named and linkable
- Release → Assay Gate and artifacts — readiness tied to criteria and IDs, not slide decks alone
Use the artifacts before/after page when translating existing templates.
Sample adoption scorecard (business-facing)
| Theme | Example measures |
|---|---|
| Flow | Lead time to done for Sparks; blocked time with reason codes |
| Quality | Defects escaped vs caught pre-release; test linkage to acceptance criteria |
| Decision velocity | Time from “decision needed” to logged outcome in Versona / huddle |
| Evidence | Releases with traceable IDs; Assay Gate completeness |
| Blueprint coverage | Disciplines invoked in the last quarter vs roadmap risk areas |
| Ceremony ROI | Sync and retro time vs removal of status-only meetings |
Adjust weights to your regulated context; avoid velocity theater as the headline metric.
Next: Sponsors hub · Executive overview · Blueprints handbook