> For the complete documentation index, see [llms.txt](https://portavi.gitbook.io/portavi-docs/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://portavi.gitbook.io/portavi-docs/governance/change-requests.md). # Change requests A change request is a proposal to alter something that was agreed on a project or programme: its scope, its finish date, its budget, its resourcing, or something else. It is raised, decided, and then applied, and the register keeps the whole trail: what was asked, why, what it would cost, who approved it, and whether it happened. Change requests are part of the **Change management** feature. A PMO manager switches it on under **Settings → Features**; it is off to start for workspaces created before it existed.
## The register **Governance → Change requests** lists every request in the workspace, grouped by programme and project, with a card above the tabs counting those awaiting a decision, approved, applied, rejected and still in draft. PMO managers can open a request here to decide or apply it; executives read. ## On a project or programme The **Changes** tab on a project or programme page is where requests are raised and worked. Its owner, an owner higher up (the programme's or portfolio's) and any PMO manager can raise one; executives can read. A request carries: * **Title** and **kind**: scope, schedule, budget, resourcing or other. * For a **schedule** request, the **proposed finish date**; for a **budget** request, the **proposed budget total**. The form shows the current value, the baseline and the tolerance beside it, and the card reads *from → to* forever, because the values at submission are captured with the request. * **Reason** and **what changes**. **Save draft** keeps it private to you until you **Submit for decision**. A draft can be edited or deleted; a submitted request can be withdrawn until it is decided. ## Who decides The workspace's **change control** policy (**Settings → Change control**) names the approvers: * **Parent component owners**: for a project, its programme's owner, plus the portfolio's owner when that programme sits in a portfolio; for a programme, its portfolio's owner. * **Any PMO manager**: one PMO manager's approval is enough. * **Both**: the parent owners and one PMO manager must all approve. A submitted request holds one slot per approver role, so the list always names every role that was consulted; when one person holds several of them, their single decision settles all of their slots. It is approved when every slot is approved and rejected the moment one approver rejects. A component with no parent owner falls back to any PMO manager, so nothing waits for nobody. If the person who raised the request is one of its approvers, their slots are approved the moment they submit: raising it is their approval. That covers a named owner slot they hold, and the PMO slot when they are a PMO manager, so under the *Any PMO manager* policy a PMO manager's own request is approved as it is submitted. Each approver may leave a note. If a programme or portfolio changes owner while a request is waiting, the undecided slot for that role moves to the new owner, who is notified as if the request had just been submitted (and who approves it on the spot if they raised it). Decisions already given stay with the person who gave them. A role left with no owner loses its slot, and a request left with none gains the open PMO slot. Approvers are notified when a request is submitted, and see it under **Change requests** in **My Focus**, marked overdue after seven days. The raiser and the component's owner are notified of the decision. Approving or rejecting also logs a decision in the [Decisions log](/portavi-docs/governance/decisions-log.md), with *Change request* as its source. ## Applying a change Approval does not edit anything. The owner or a PMO manager presses **Apply change**: * A **schedule** or **budget** request writes its proposed value to the component and makes it the new baseline. * A **scope**, **resourcing** or **other** request records who applied it and when, with an optional note and a link to where the change happened, since the change itself lives in your project management tool. Approved requests waiting to be applied appear in **My Focus** for the owner. Applied and approved requests appear in the project status report and the programme executive summary under **Approved changes**. ## Tolerances and baselines Every project and programme carries a **baseline finish date** and a **baseline budget**: the values it was created with, reset each time a schedule or budget change is applied. The change control policy sets a **date tolerance** in days and a **budget tolerance** as a percentage, with an optional absolute cap. Editing a finish date or budget from the edit form is compared against the baseline, not the current value, so several small edits cannot creep past the limit. Within tolerance the edit saves as usual. Beyond it, the edit form does not save that field; it opens a change request pre-filled with the proposed value, its kind fixed to schedule or budget, and the rest of the edit is saved. The date suggestions ribbon follows the same rule: when the finish date it suggests is within tolerance its button sets the date as before; beyond tolerance the button reads **Raise a change request** and opens one pre-filled with the suggested date and the ribbon's own wording as the reason. While a schedule or budget request is submitted or approved, that field is **locked** in the edit form, the date suggestions ribbon stays hidden for the component, and no second request of the same kind can be submitted. Apply or withdraw the request to release it. ## When a feature is switched off Switching **Change management** off rejects every open request with a note naming who switched it off and when; nothing is deleted, locks are released and baselines stay. Switching **Budgeting & EVM** off does the same for budget requests only. The feature toggle warns how many pending requests this affects before you confirm. Switching a feature back on reopens nothing; the rejected requests stay in the register with their reason.