Project Type Policies vs. Project Settings

Every project, when created, inherits its settings from the policies of the project type it belongs to. However, the project managers can override some of the project settings if allowed by the program type policies.

What Are Overridable Policies

If a project type policy set the option Allow project managers to override these settings to Yes, the policy is overridable. Project managers can edit the policy in their project settings.

All the policies except the Request Types policy can be set to be overridable.

How Project Type Policies Affect Project Settings

For projects that are already in progress, changing a project type policy or its override status has the following effects:

Changing an overridable policy to non-overridable will change that policy for projects in progress, switching their settings to match the new policy if settings were altered previously.
Changing a non-overridable policy to an overridable policy has no effect on projects in progress.
Making a change to a non-overridable policy changes the settings on projects in progress to match the new policy.
Making a change to an overridable policy has no effect on projects in progress.

In cases where changes to a project type will cause recalculation of data (such as changes to exception thresholds), these calculations are deferred.

Making Changes to Policies that Do Not Propagate

Certain policies do not propagate changes to existing projects, even if they are set to be non-overridable. These policies are:

Project Fields
Cost and Effort
Microsoft Project Integration
Work Plan Template (changes do propagate, but do not alter existing work plans)

If you want to make changes to a project type policy that does not propagate, follow the general procedure outlined below:

Identify a time when system activity is low.
On the project type, unlock the project policy.
Open existing projects and change the settings on each where allowed.
On the project type, lock the project policy.