Visions in Bloom 1.3: when an idea becomes binding
Bloom 1.3 adds visions, a document type for the idea a product starts from, reviewed and approved like a specification.
Campaign week 5 · Bloom PLM 1.3 (coming)
Requirements rarely come from nowhere. They come from an idea someone wrote down: a direction for the product, a reason it exists, what success looks like. In most tools that idea lives in a slide deck, and the link between it and the requirements is lost the day the deck is filed.
A document type for the idea
Section titled “A document type for the idea”Bloom 1.3 adds visions, IDs such as PRJ-VIS-001. A vision is written in Bloom’s full document editor and goes through the same review and approval as a specification.
- Until it is approved, a vision shows as Idea.
- Once approved, it shows as Binding to everyone who can see that it was approved.
Linked like everything else
Section titled “Linked like everything else”Requirements and specifications derive from a vision; change requests and risks affect it; it refers to standards; its text takes tags like every other document. Baselines record visions in a section of their own, and visions come first in the project sidebar, the overview, the registry filter and the topology.
Who owns them
Section titled “Who owns them”A new built-in Visions policy belongs to the Product Owners group, and the existing read, review and administration policies cover visions as they cover specifications.
Why it matters
Section titled “Why it matters”When an auditor or a new team member asks why a requirement exists, the answer is one link away: the requirement derives from a vision that was reviewed, approved and is still binding. Bloom 1.3 is in development; follow the Bloom roadmap for the release.