Because requirement should be an item of a project, and not a complete plroject.
It seems strange to me to transform a single requirement into a project.
IMO a project should contain several (upo to many) requirements.

Sorry, I clicked on Solved by mistake.

Here is how we work:
We have big projects:
1. MY PROJECT

We have sub projects:
1.1 REQUEST FOR CHANGE 1
1.2 REQUEST FOR CHANGE 2

- Each request (change or fix) come from our customers and is about ONE requirement. Example: change the color of the button.
- For this single request, we will have everything, from prestudy, to business requirements, to specs, to developments, to tests, to UAT and to deployment, etc.
- When the requirement is in prestudy, we study the feasibility and if or not it will become a real project, if we will cancel it or do it later when we have the budget. At this state, the requirement is a requirement, not a project (yet).
- When we validate the requirement, it becomes a single project (from specs to deployment).
- We have two workflows in parallel: a financial workflow (statuses quotation, contract, order, etc, to know at which state we are) for the requirement, and a project workflow (statuses prestudy, specs, etc) for the project.

So requirements and projects are linked as 1:1 in UML. I checked with projects manager, it will always be like that (except when initiating a new big project, which should be rare).

Thank you,

- Each request (change or fix) come from our customers and is about ONE requirement. Example: change the color of the button.

You really defined a project for a request to change the color of a button ?

When the requirement is in prestudy, we study the feasibility

And what is the requirement linked to ? (if not to a project)
How do you manage work spent on requirement feasibility study ? (if not inside a projet)

Really I thing you should manage your sub-projects as activitiies.
1) you can copy a requirement into an activity
2) an activity can be split into sub activities
3) Requirements and acitivites can belong to same main project
4) if you please, you can define some activity type called "project"
It really makes sense to me to define an activity (and not a project) to change the color of a button, and not a project.

I checked with projects manager

Do the project managers manage 1 and 1 only requirement ?

Yes, our suppliers invoice every little changes we ask them so it's a whole project. And I can't change the way they/we work as I have no influence on it.

Among other reasons, a Change Order is linked to every financial elements such as the Quotation, Order, Invoice, etc and we can't link and filter activities as easily and as intuitive as with projects.

Isn't adding Project to Copyable table a better way to solve this issue?

Isn't adding Project to Copyable table a better way to solve this issue?

It is not so easy as Project is the main entry point and key to manage access rights.
If may lead to more issues than solutions.
Your way to manage requirements and transform them into projects is very specific, so you should consider it as a specific evolution.
You can request for a quote to implement it throught the Contact form if you wish.

Well, so far, no issues on my instance.
I will keep Project in Copyable table only on my instance then.