Project Governance and Access
The Project lifecycle
Every Project goes through a lifecycle: it is created for a purpose, used by a team, and eventually either continues in active use, becomes dormant, or is archived when the purpose is complete or superseded. Managing this lifecycle is a governance responsibility.
Unmanaged Projects create risk: orphaned Projects with outdated system prompts continue to shape user interactions. Projects owned by departed employees cannot be updated when policy changes. Projects with overlapping scope confuse users about which one to use.
Access model
Who can create a Project: by default, any Member can create a Project. This is useful for bottom-up innovation — teams discover their own use cases — but it requires monitoring.
Who can see a Project: only the Project's members plus organisation Admins. Members cannot see Projects they have not been added to. This means you can create a sensitive Project (e.g., one for the Executive team) and be confident that it is not visible to the rest of the organisation.
Organisation-wide Projects: Admins can create Projects that are visible to all members of the organisation. Use these sparingly for truly universal tools (e.g., a general writing assistant, a meeting notes helper).
Admin visibility: Admins can see all Projects in the Admin Console regardless of membership. This is their governance access — it does not mean Admins are active participants in every Project.
Assigning Project ownership
The person who creates a Project is its owner by default. As owner, they can:
- Edit system instructions and knowledge files
- Add and remove members
- Archive or delete the Project
- See all conversations within the Project (if this capability is available in your tier)
Best practice: make an Admin the owner of high-stakes Projects. If the creating member leaves and their account is deactivated, the Project becomes effectively orphaned — no one can edit it. Transferring ownership to an active Admin before departure prevents this.
To transfer ownership: in the Project settings, the current owner can change the owner to another member. Admins can also reassign ownership from the Admin Console.
For departmental Projects, consider a co-ownership model: the departmental lead owns the Project at the business level, and an Admin holds a backup ownership role.
Naming conventions
A consistent naming convention makes the Project landscape manageable as you scale. Recommended format:
[Team/Department] — [Use Case]
Examples:
Legal — Contract ReviewHR — Job Description DraftingFinance — Board Report WritingSales — Proposal DraftingIT — Incident Post-MortemsExecutive — Briefing Summaries
Within the Project, the description field should include: purpose, primary users, date created, and last reviewed date. This turns the description into a change log.
Avoid vague names: "Legal Tool", "HR AI", "Finance Helper" are not useful in an organisation with 30 Projects. Every Project name should tell an admin what it is for without opening it.
Access tiers for Projects
Design access based on the sensitivity of the use case:
Open to department (default): all members of the relevant department are added as members. Appropriate for most business productivity Projects.
Restricted to specific individuals: only named individuals are members. Appropriate for Projects dealing with sensitive matters: M&A analysis, executive compensation, disciplinary cases, confidential litigation.
Organisation-wide: all members of the organisation are members. Appropriate for universal tools. Use sparingly — every member sees this Project, which creates clutter if there are too many.
Admin-only: only admins are members. Appropriate for admin tooling Projects (e.g., a Project for drafting user communications) that do not need to be visible to general members.
The governance review cadence for Projects
Monthly:
- Open the Projects view in the Admin Console.
- Check for Projects created in the last 30 days that you are not aware of. Review their system prompts.
- Archive Projects that appear empty (created but never used).
Quarterly:
- Review all active Projects. Is the system prompt still accurate? Have policy changes occurred that require an update?
- Check for Projects owned by users who have left the organisation. Reassign ownership.
- Check for Projects with no active members. Archive or reassign.
- Check for Projects with overlapping scope. Consolidate where possible.
Annually:
- Full audit: every Project reviewed by its business owner. Is it still needed? Is the system prompt current? Are the knowledge files up to date?
Scenario: the Project audit
Six months after deploying Claude Enterprise, the IT admin at a media company runs her first Project audit. She finds:
- 34 Projects total, up from 12 at launch
- 8 Projects with no active members (created during testing, never used) → archived
- 3 Projects with the same name pattern ("Content Writing") owned by three different marketing managers → consolidated into one shared Project after a 30-minute meeting with the Marketing lead
- 2 Projects owned by departed employees → ownership transferred to the department admin
- 1 Project with a system prompt referencing the old brand guidelines (updated 3 months ago) → knowledge file updated
The audit took 2 hours. The result: 26 active, well-governed Projects instead of 34 inconsistently maintained ones.
Key takeaway
Project governance is the difference between a self-service tool that creates shadow IT and a managed platform that scales with the organisation. Naming conventions, ownership assignment, access tiers and a quarterly review cadence cost very little effort and prevent compounding problems.
📖 Official Documentation See this in practice in Anthropic’s live support docs: