Run a Change Control Board

A Change Control Board (CCB) gives baseline changes the same discipline that proposals get: a scope, schedule, or budget change is written up as a change request, reviewed by the right people, and only counts as done when someone marks it implemented.

Set up the board

1. Open Organization Settings, go to the Governance tab, then the CCB section.

2. Add the people who should sit on the board. CCB members can review any change request in the organization, regardless of their role on the project it belongs to, which is exactly what makes them a board rather than another project approver.

Adding and removing CCB members requires the governance manage permission, Owner and Admin by default.

File a change request

Change requests live on the project. Open the project and go to the Change Requests tab, then select New Change Request.

• Choose a type: scope, schedule, budget, resource, or other.
• Describe the change and, where known, its impact: schedule impact in days and budget impact in the project’s currency.
• Set the Approval threshold, the percentage of reviewers who must approve (51% by default).
• Optionally name designated reviewers for this specific request, in addition to the standing board.

Any project member can file a request against their own project; details and impact fields stay editable only while the request is a draft.

The lifecycle

A change request moves through Draft, then Submitted when you select Submit for Review, then Under Review once reviews start, and ends in Approved or Rejected. An approved request is finished with Mark Implemented once the change has actually been made, by a project owner or manager or a CCB member, so the record reflects reality, not intent.

The requester (or a project manager) can select Withdraw at any point before a decision, taking the request out of play without deleting its history.

How decisions are reached

Eligible reviewers are project owners and managers, CCB members, and any designated reviewers on the request. Each casts an approve or reject decision, with comments. The request is approved once approvals reach the threshold; when designated reviewers are named, the threshold is measured against the whole panel. It is rejected only when every panel reviewer rejects, anything in between stays Under Review. The requester is notified in-app and by email when the decision lands.

Note

You cannot review your own change request, even if your project role would otherwise make you eligible. One person cannot be both the proposer and the approver, that is the whole point of a board.

Best practices

1. Keep the CCB small, 3 to 5 standing members. The point of a board is cross-cutting visibility, not bureaucratic gridlock. Three plus a Finance designated-reviewer pattern works well; ten members means every change waits on everyone.
2. Add designated reviewers per request type. A $2k scope change doesn’t need the whole CCB; a $200k budget change does. Use the “designated reviewers on this request” field to pull the right experts in without requiring the entire board.
3. Treat the threshold as a policy, not a default. 51% works for most decisions; raise it to 67% or higher for change types your org has burned on before (budget changes, schedule slips). The threshold is configurable per request, use that power.
4. Require an impact estimate on every request. Schedule impact in days and budget impact in currency aren’t legally required, but they’re what transforms “I want to change X” into a reviewable decision. Reviewers who don’t see the numbers default to “no”.
5. Mark Implemented promptly once changes are applied. The record only reflects reality when you close it. A list of approved-but-never- implemented changes is a sign the team treats CCB as a formality, not a discipline.

Troubleshooting / common pitfalls

• My change request can’t find reviewers. Check the CCB roster in Org Settings; if empty, there’s no standing board, and you need to designate reviewers explicitly on the request. Project owners and managers can also review by default.
• I’m a CCB member but can’t see the project’s change requests. Two causes: (a) the project itself isn’t shared with you (CCB membership lets you REVIEW change requests on any project, but project access controls what you can SEE); (b) the CCB roster wasn’t refreshed on the project, try refreshing.
• My threshold won’t trigger approval. The math: approvals/total ≥ threshold%. If 2 of 3 reviewers approve, that’s 67%; a threshold of 67% triggers, 68% doesn’t. Confirm the actual configured value.
• A deactivated board member is blocking my request. Deactivated reviewers are skipped from the threshold automatically. If the request still won’t approve, refresh, the count may be stale.
• I want to review my own change request. You can’t, by design. The rule prevents proposer- approver collapse. If you’re the only person on the project capable of reviewing, ask the org Owner to designate a CCB-equivalent reviewer for this request.

How this combines with other features

• CCB + Baseline. The most useful CCB pattern: capture a baseline at project approval; any change to baseline-recorded values (dates, budget, scope) routes through CCB. The baseline is the “what we agreed to” reference. See Capture and compare baselines.
• CCB + Audit log. Every CCB decision , approval, rejection, implementation, withdrawal , writes to the audit log. Useful for compliance audits and post-mortem retrospectives. See Read audit logs.
• CCB + Member deactivation. Deactivated members are skipped from CCB quorum. Onplana doesn’t auto-remove them from the roster; an admin should clean up periodically.
• CCB + Workflow automation. A workflow that auto-flags overdue change requests (e.g., “submitted but no decision in 7 days”) helps the team see when CCB is the bottleneck. See Build a workflow.

Coming from another tool

Tool	Mapping
MS Project Online Change Request workflow	Direct concept; same review-and-implement cycle
ServiceNow Change Management	ServiceNow’s CAB ≈ Onplana CCB; same pattern
Spreadsheet change log	Onplana adds first-class workflow + audit log
Smartsheet Change Requests	Similar
Jira “Change” issue type	Closest analog; Jira lacks the multi-reviewer threshold model

FAQs

Who can see the CCB roster? The people who can manage it, Owner and Admin by default. Everyone else encounters the board through the review flow on their own change requests.

Can a Portfolio Manager administer the board? Not by default. CCB membership follows the governance manage permission, so an owner can extend it to Portfolio Managers through the permission matrix if your organization wants that.

What if a board member leaves or is deactivated? Deactivated reviewers stop counting toward the threshold, so a request is never stuck waiting on someone who can no longer sign in.

Can a change request affect more than one project? No, change requests are scoped to one project. Cross-project changes need separate requests per project, ideally referencing each other in the description.

Do change requests integrate with project baselines? Yes, most CCB use is around baseline-recorded values (dates, budget, scope). An approved change is the moment to capture a NEW baseline reflecting the change. See Capture and compare baselines.

Is there a way to require CCB approval automatically? Not natively, CCB is invoked when someone files a request. To enforce it, an org policy could require workflow automations to flag baseline-deviating changes without an approved CR.

What happens if my change request is rejected? The request is final; the work doesn’t happen. You can file a new request addressing the rejection comments, usually with a different framing, scope, or threshold.

Related

• From proposal to governed project, how projects acquire baselines that CCB then protects
• Capture and compare baselines, the reference CCB measures against
• Read audit logs, CCB decisions live here