Programs run better when artifacts have fixed homes and clear owners. The workstream charter drafted in week two, revised in week four, and emailed again after a week-six steering committee discussion illustrates the pattern: two weeks later a scope question comes up, three people pull up three different versions, and nobody is sure which one is current. The organization has SharePoint or Google Drive or Confluence; the problem is that nobody established where the charter lives and who maintains it. The charter followed the decisions into email instead of the decisions flowing back to the charter.
Artifact Drift Follows the Path of Least Resistance
Program artifacts end up in email and meeting notes because that path requires the least effort. A VP raises a scope question during a status meeting; the program lead answers it, and the answer changes the charter’s scope boundary. The change is captured in meeting notes, which go out via email. The charter document doesn’t get updated because nobody’s job is to update it in that moment, and nobody’s rhythm includes checking whether recent decisions have changed the current version.
Over weeks, the gap between the document and the actual program widens. The charter says one thing and the emails say another; the meeting notes split the difference. When a new team member joins and asks for the charter, they receive a document that is several decision cycles behind reality. The downstream cost is misalignment that surfaces slowly and expensively:
- Two workstreams overlap on a deliverable because the scope boundary shifted in an email one lead didn’t receive, or a dependency commitment changes in a meeting while the dependent workstream is still planning against the original.
- A stakeholder reviews the charter, assumes it’s current, and escalates a concern that was resolved three weeks ago.
This is what happens when alignment breaks down because nobody truly agreed on how decisions get recorded.
A Naming Convention and a Maintenance Rhythm Solve the Problem
The fix is structural, and it maps to two steps in how we architect programs.
When the consulting team builds out program architecture, we establish what artifacts exist and where each one lives. This is a simple registry: the charter lives here, the risk register and decision log live here. Each artifact has a single, named location with no ambiguity about where to find the current version. This is part of eliminating the ambiguity about where artifacts live, and artifact location is one of the things that must become visible.
When we design the operating model, we establish who maintains each artifact and how often it’s updated. The workstream lead owns the charter; it’s reviewed as part of the biweekly workstream review. If a meeting decision changes the charter’s scope, the workstream lead updates the document within forty-eight hours, and the update is noted in the next status report. The same structure applies to every program artifact: decision logs, risk registers, dependency maps, constraints calendars, and rollout plans.
Artifacts Belong in Named Locations, Not Inboxes
Email is a communication channel, not a document management system. An artifact that lives in email has no version control and no owner; it’s just threads to search through, inferring which message supersedes which.
The charter is a particularly costly artifact to lose track of because it defines scope and ownership. When a scope question arises and nobody can point to a current, authoritative document, the question becomes a negotiation: two workstream leads debate boundaries, and the debate consumes meeting time and leadership attention that should be directed at execution.
A charter in a named location, with a named owner and a defined update cadence, eliminates that category of friction. The scope question gets answered by opening the document. If the document is wrong, the owner updates it, and the update is visible to everyone because the document lives in one place. Understanding what a good workstream charter looks like is the first step; intake changes everything about how early that structure gets established.
