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:

1. Rename “Project” to something more neutral, such as Workspace, so that it no longer conflicts with the PM²/PMBOK meaning.

2. 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.

3. 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.

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).