Added by Christophe GESCHÉ 18 days ago
In OpenProject, the term Project is used to describe what is essentially a workspace that contains tasks, wiki, members, and configuration.
However, in project management methodologies such as PM², PMBOK, or PMP, the word project has a very specific meaning: a temporary endeavor with phases, governance, and deliverables.
This creates a conceptual conflict in organizations like mine, where we need to manage different kinds of workspaces:
real PM²/PMBOK projects
construction sites (chantiers)
products
services
internal activities
etc.
All of these are “projects” in OpenProject, even though they are not projects in the project‑management sense.
This leads to confusion for users and makes onboarding more difficult.
What I would like to achieve is:
Rename “Project” to something more neutral, such as Workspace, so that it no longer conflicts with the PM²/PMBOK meaning.
Create different “types of workspaces”, such as:
Project
Product
Service
Construction site
Activity
Each type would ideally have its own metadata (custom fields), modules, and configuration.
Use templates to simulate this, but ideally with a clearer distinction in the UI.
Is there a recommended way to implement this?
Is there any plan to support “project types” or a more flexible naming of the workspace entity?
Any guidance or best practices would be appreciated.
Replies (2)
I am currently exploring what can be done locally using the existing OpenProject features (templates, custom fields, text overrides, etc.).
I am still learning the platform, so I may be missing some best practices.
However, if this topic gives ideas for improving OpenProject in the future, I would be very interested in contributing, testing, or helping refine the concept of workspace types or more flexible naming.
Any guidance or feedback is welcome.
-----------------
OpenProject does not currently support “project types” in the sense of PM²/PMBOK, and the system uses the word Project for all workspace containers.
However, it is possible to achieve most of the desired behavior through a combination of existing features.
Here is the approach that works well:
1. Rename “Project” to a neutral term (e.g., Workspace)
OpenProject allows overriding interface text through the Custom Text / I18n settings.
By replacing “Project” and “Projects” with “Workspace” and “Workspaces”, the UI becomes much clearer for users who distinguish between operational workspaces and formal PM²/PMBOK projects.
2. Use Project Templates to simulate “types of workspaces”
You can create templates such as:
PM² Project
Construction Site
Product
Service
Internal Activity
Each template can define:
which custom fields are active
which modules are enabled
which work package types are available
predefined folder or task structures
default roles and members
This effectively creates different workspace types, even though OpenProject does not label them as such.
3. Add a custom field “Workspace Type”
To classify and filter workspaces, you can add a mandatory custom field with values like:
Project
Product
Service
Construction
Activity
This helps with reporting, filtering, and portfolio organization.
4. Organize workspaces in a clear hierarchy
For example:
Portfolio
Projects
Construction
Products
Services
Internal Activities
This makes navigation easier and reinforces the distinction between workspace categories.
Conclusion
While OpenProject does not natively support project types or renaming the core entity, combining:
custom text overrides
project templates
custom fields
a clear hierarchy
provides a practical and effective solution that removes ambiguity and supports multiple workspace categories.
Hi everyone,
I agree - not everything in OpenProject is a project. There will be two new things in 2026:
Space
Project types
Construction project
Scrum project
Organizational project
...
On top of that we work on nested groups to bring the organization structure such as (Division -> Department -> Team).