There's no easy way to push your changes to other project areas that already have their own process since these other projects were setup to have their own process, not share one.

If you want multiple projects to share a single process, you could setup Process Sharing where you have a "master" project that provides the process to other areas that consume it. Changes to the master are automatically shared to the consuming projects.

I think the enhancement is the process sharing capability. The process isn't something that's "outside" of the project -- it's the blueprint for how the project runs. A project without a process is is just an empty container with no work item types, no workflows, etc. One way to think of it is: Project = Timeline + Team + Process. A Project Area can hold multiple Projects (defined that way), allowing them to share one or more of those components.

Once a Project Area has been setup to consume its Process from another, that association can be changed. So you could define a MasterProjectArea1.0 and have all of your projects consume their process from it. You can tweak it and have the changes picked up by the consumers. Then if you decide that you want to introduce some larger changes, you can create MasterProjectArea2.0 that starts with the 1.0 process and implements your improvements. When you're ready, you can change the consumer projects to get their shared process from the 2.0 master -- and you can let the consuming projects change at their own pace (the 1.0 Project Area is still there).

Obviously some care needs to be taken that you don't introduce breaking changes -- but that's true in any sort of "schema change" scenario. Is there something you are trying to accomplish that you don't think could be addressed with this mechanism? Because if there is, we can certainly make an Enhancement request for that.

I think the enhancement is the process sharing capability. The process isn't something that's "outside" of the project -- it's the blueprint for how the project runs. A project without a process is is just an empty container with no work item types, no workflows, etc. One way to think of it is: Project = Timeline + Team + Process. A Project Area can hold multiple Projects (defined that way), allowing them to share one or more of those components.

Once a Project Area has been setup to consume its Process from another, that association can be changed. So you could define a MasterProjectArea1.0 and have all of your projects consume their process from it. You can tweak it and have the changes picked up by the consumers. Then if you decide that you want to introduce some larger changes, you can create MasterProjectArea2.0 that starts with the 1.0 process and implements your improvements. When you're ready, you can change the consumer projects to get their shared process from the 2.0 master -- and you can let the consuming projects change at their own pace (the 1.0 Project Area is still there).

Obviously some care needs to be taken that you don't introduce breaking changes -- but that's true in any sort of "schema change" scenario. Is there something you are trying to accomplish that you don't think could be addressed with this mechanism? Because if there is, we can certainly make an Enhancement request for that.

Note that the ability to combine process fragments from several project areas has been requested in work item 65652. You might want to read over that work item and verify whether that is the direction you would be looking for.

Cheers,
Geoff