Overview
After creating a project, you can update most of its settings including the name, stage, requirement detail level, systems, and categories. Understanding which settings can be changed and what impact those changes have helps you adapt projects as your needs evolve.
Accessing Project Settings
To edit project settings:
Navigate to your project
Click More, then Edit Project
Make your changes
Click Save changes
Editable Settings
Project Name
Can be changed: Yes
How to change:
Open project settings
Edit the project name field
Save
Impact of changing:
Requirement IDs may change - IDs include project name abbreviation
New requirements will use the new project name in their ID
Existing requirements keep their original IDs
Projects are searchable by the new name immediately
Best practice: Avoid changing project names mid-project if possible, as it can cause confusion with requirement IDs.
Project Stage
Can be changed: Yes, and encouraged as the project progresses
Available stages:
Discovery
Design
Build
Test
Deploy
Support
How to change:
Open project settings
Select new stage from dropdown
Save
Impact of changing:
No impact on requirements, files, or other data
Purely informational
Helps team members understand current project phase
Useful for reporting and project dashboards
Best practice: Update the stage as you move through the project lifecycle to keep project status current.
Requirement Detail Level
Can be changed: Yes
Options:
Broad Strokes - Fewer, high-level requirements
Balanced - Standard volume and detail for most projects
Granular - More requirements with greater detail and specificity
How to change:
Open project settings
Select new requirement detail level from dropdown
Save
Impact of changing:
Only affects NEW requirements created after the change
Existing requirements remain unchanged
NEW requirements will have different volume and detail:
Broad Strokes generates fewer, higher-level requirements
Balanced generates moderate volume with standard detail
Granular generates more requirements that are more detailed and atomic
AI Review criteria also change for new requirements:
Broad Strokes: Clear, Correct, Feasible
Balanced: Traceable, Unambiguous, Testable, Clear, Correct, Feasible
Granular: All Balanced criteria + Independent, Atomic, Implementation-Free
When to change:
Moving from sales to delivery discovery (Broad Strokes to Balanced)
Moving from general delivery discovery to implementation details (Balanced to Granular)
Downgrading if you realize the level is generating too many or overly-detailed requirements
Best practice: Change the requirement detail level when you transition between project phases, but understand existing requirements won't automatically update. If you process the same file again after changing levels, you'll get a different number and detail of requirements.
Systems (Source and Target)
Can be changed: Yes
How to change:
Open project settings
Edit source system (company and product name)
Edit target system (company and product name)
Save
Impact of changing:
No impact on existing requirements, files, or data
Useful for correcting typos or being more specific
Best practice: Update systems to be accurate and consistent with your organization's naming standards.
Non-Editable Settings
Project Type (Migration vs Enhancement)
The project type (whether it's a migration or enhancement) is set during creation and cannot be changed afterward.
Workaround:
If you need to change the project type, create a new project with the correct type
Export requirements from the old project
Upload them as documents to the new project
Delete the old project if needed
Project Creation Date
The creation date is set automatically and cannot be changed.
Viewing Project Information
Project Dashboard
The project dashboard typically shows:
Project name
Client name
Current stage
Current status
Systems (source and target)
Project contacts
Requirements summary information
Mapped Slack channels
Deleting Projects
How to Delete
Open project dashboard
Click More, then Delete Project
Confirm deletion (requires typing project name)
What Gets Deleted
Deleting a project permanently removes:
All requirements including acceptance criteria
All tasks (implementation tasks)
All uploaded files and documents
All citations and reference data
All conflict history
All project settings and configurations
What Is NOT Deleted
Client record - The client remains in your organization
Team members - User accounts are unaffected
Categories - Categories remain available for other projects
Integrations - Org-level integrations are not affected
Cannot Be Undone
Warning: Project deletion is permanent and cannot be reversed.
Before deleting:
Export any requirements you might need later
Download any important files
Confirm with stakeholders that the project should be deleted
Consider leaving inactive projects in place rather than deleting
Alternative to Deletion
If you want to preserve the project but mark it as complete:
Add "COMPLETE" or "ARCHIVED" to the project name
Change status to "Completed" or "Cancelled"
Since Glossa doesn't support archiving, this naming approach helps you identify inactive projects.
Best Practices
When to Edit Settings
Update stage regularly:
Move through Discovery → Design → Build → Test → Deploy → Support as the project progresses
Helps team understand current phase
Useful for project status reporting
Adjust requirement detail level at phase transitions:
Broad Strokes → Balanced when moving from sales to delivery discovery
Balanced → Granular when getting into detailed technical specs
Gives you appropriate quality criteria for each phase
Keep systems accurate:
Correct typos immediately
Update to be more specific as you learn more about the platforms
Maintain consistency across similar projects
What NOT to Change
Avoid changing:
Client mid-project - Causes ID confusion and meeting matching issues
Project name frequently - Makes requirements harder to track
Requirement level back and forth - Creates inconsistent quality expectations
Think carefully before deleting:
Projects can't be recovered
Consider leaving inactive projects visible but renamed to show they're complete
Managing Project Lifecycle
Early in project:
Fine to adjust settings as you learn more
Correct mistakes immediately
Set requirement level based on project phase
Mid-project:
Changes should be intentional and communicated to team
Changing requirement level affects new requirements only
Stage updates should reflect actual project progress
End of project:
Update stage to "Deploy" or "Support"
Consider renaming to "COMPLETE - [Project Name]"
Preserve the project for historical reference
Common Scenarios
Transitioning from Sales to Delivery
Initial setup (sales phase):
Stage: Discovery
Requirement Level: Broad Strokes
When deal closes:
Change Stage to Design
Change Requirement Level to Balanced
New requirements will have more stringent quality criteria
Going deeper:
Move stage to Build
Change Requirement Level to Granular if needed
Team now gets very detailed, atomic requirements
Correcting Mistakes
Wrong project type:
Can't fix - need to recreate project
Export requirements, create new project, import requirements
Typo in project name:
Fix immediately before many requirements are created
Later fixes may cause ID inconsistency but project still works
Multi-Phase Projects
Phase 1:
Project Name: "Client - System Implementation Phase 1"
Stage: Discovery → Design → Build → Test → Deploy → Support
Phase 2:
Create new project: "Client - System Implementation Phase 2"
Reuse categories from Phase 1
Reference Phase 1 requirements as needed
Alternative: Keep one project and use Categories to separate phases (e.g., "Phase 1 Features", "Phase 2 Features")
Troubleshooting
Changes didn't save
Make sure you clicked Save changes after making changes.
Check:
Refresh the page and verify changes persisted
Look for error messages that may have appeared
Ensure required fields are still filled in
Requirement IDs seem inconsistent
This happens when you change project or client names mid-project:
Older requirements use the old abbreviation
Newer requirements use the new abbreviation
This is expected behavior—IDs are set at requirement creation
Solution: This is cosmetic and doesn't break functionality. Accept the inconsistency or create a new project with the correct name.
Can't change project type
Project type (Migration vs Enhancement) is set at creation and can't be changed.
Solution: Create a new project with the correct type if this is critical.
Quality scores didn't update after changing requirement level
Requirement level changes only affect new requirements.
Solution:
Existing requirements keep their scores
You can manually re-run AI Review on individual requirements if needed
Or accept that existing requirements use the old criteria