Change control board (CCB): members, charter and process

Published 22 October 2026

A change control board (CCB) is the person or group with the authority to decide which changes to the agreed requirements are accepted, rejected or deferred — and to accept what each one costs. On a large programme it is a committee. On a small client project it can be the client’s product owner, advised by the supplier’s delivery lead. Below are who sits on one, what it decides, a CCB charter template with a filled-in example, how a meeting runs, how a CCB differs from a change advisory board and a product owner, and when it gets too heavy.

To keep the inevitable changes from throwing your project into chaos, someone has to make the decisions about which changes to accept and which to reject. The industry-standard term for these decision makers is the change control board, and every project needs one.

— Karl Wiegers, The Change Control Board

What a change control board is

Wiegers’ definition: “The CCB is the body of people, be it one individual or a diverse group, who decides which proposed requirement changes and newly suggested features to accept for inclusion in the product.” The software configuration management side of the SWEBOK Guide calls it a configuration control board, and adds: “In smaller projects, this authority may reside with the leader or an assigned individual rather than a multi-person board” (SWEBOK Guide V4.0a).

Most projects have one already, under another name: the people whose yes makes a change happen. “Most projects already have some de facto group that makes change decisions; establishing a CCB formalizes this group’s composition and authority and defines its operating procedures,” Wiegers writes.

The board decides; it does not analyse. The impact of each request is worked out before the meeting — in a change impact analysis — and the board sees the result. In Wiegers’ words, “the CCB needs only the summary of analysis results.” Where the board sits in the whole process is in requirements change management.

Who sits on a change control board

Wiegers suggests drawing members from the areas a change can affect: project management, product management or business analysis, testing, customer representatives, user documentation, technical support. Then he narrows it: “Keep the CCB as small as possible so that the group can respond promptly and efficiently to change requests.” Not everyone decides: “Only a subset of these people actually need to participate in making the change decisions, although all must be informed of decisions that affect their work.”

On a client project, the client has to be on the board: the client pays for the change and accepts its dates. The board also needs someone who can say yes to the cost. One commenter’s version: “The key to this though is having a responsible sponsor who can both take responsibility for approving the baseline requirements set and for making decisions on the costs/timescales/benefits for requested changes” (r/projectmanagement, 2019).

What a change control board decides

• Accept, reject or defer each request — with the reason written down, so that “why did we say no to that?” has an answer months later.
• When an accepted change is built. “The CCB gives each approved change a priority level or target implementation date, or it allocates the change to a specific build or release number” (A Change Control Process Description).
• What gives. “The CCB balances the anticipated benefits against the estimated impact of accepting a proposed change.” A change that adds work takes time, money or another feature with it; Wiegers: “Before accepting a significant requirement change, renegotiate commitments with management and customers to accommodate the change.” One team’s rule: “if they wanted something new done ‘right now’ they had to choose something of roughly the same scope to be removed” (Hacker News, 2024).
• What goes up a level. “If the estimated cost or schedule impact exceeds the established thresholds for this level of CCB, refer the change to management or to a higher-level CCB.”

Wiegers adds that a CCB also decides which reported defects to correct, and when.

Change control board charter template

“A charter describes the CCB’s purpose, scope of authority, membership, operating procedures, and decision-making process,” Wiegers writes. Copy it into a document; square brackets are yours to fill in.

CHANGE CONTROL BOARD CHARTER
Project:   [name]
Version:   [x.y], [date]

1. PURPOSE
Decide which changes to the agreed
requirements are accepted, rejected
or deferred, and what each costs.

2. AUTHORITY
Decides:    changes up to [n] days or
            [amount]
Escalates:  anything larger, or that
            moves [milestone], to
            [sponsor]
Also:       [defects; other agreed
            documents]

3. MEMBERS
Chair:      [name, role]
Decide:     [names, roles]
Advise:     [names, roles]: impact,
            cost, dates
Informed:   [who hears every
            decision]

4. DECISION RULE
Quorum:     [who must take part]
Rule:       [who decides after the
            advice; tie-break]
Record:     decision, reason, date,
            in the decision log

5. MEETINGS
Regular:    [weekly / each sprint],
            [length]
Agenda:     every request received
            since the last meeting
Special:    [when an urgent request
            arrives]

6. FAST PATH
Changes under [n] hours that move no
date: [who] decides by email, and
records it the same way.

7. AFTER A DECISION
[who] updates the request, tells the
requester and everyone affected, and
updates the requirements version.

AGREED BY
Client:    [name, role]  [date]
Supplier:  [name, role]  [date]

The decision rule is the part most charters leave out. Wiegers lists what it has to settle: the quorum; “Whether voting, consensus, consultative decision making, or some other decision rule is used”; “Whether the CCB Chair may overrule the CCB’s collective decision”; and “Whether a higher level of CCB or someone else must ratify the decision.”

Change control board example

The customer portal from the other templates on this site, where customers see and pay their company’s invoices. The client’s three leads decide, each in their own area; the supplier advises.

CHANGE CONTROL BOARD CHARTER
Project:   Customer portal
Version:   1.0, 28 January

2. AUTHORITY
Decides:    changes up to 10 days or
            10,000 EUR
Escalates:  anything larger, or that
            moves the phase 1 go-live,
            to the finance director
            (sponsor)

3. MEMBERS
Chair:      product owner (client)
Decide:     finance lead: payments
            and invoices; head of
            sales: sign-in and
            notifications; product
            owner: everything else
Advise:     delivery lead: impact,
            cost, dates; tech lead
Informed:   testers, accounts team

4. DECISION RULE
The member who owns the area decides
after the delivery lead's impact
summary. The product owner breaks a
tie.

5. MEETINGS
Weekly, Tuesday, 30 minutes.

6. FAST PATH
Under 4 hours, no date moves: product
owner and delivery lead, by email.

Its decisions over the first five months, from the change request log and the decision log:

None of the five needed the sponsor: CR-10, the largest, was nine days and 7,200 EUR, and came after phase 1 was live. Each decision has a date, a name and a reason, and each approved one produced a new version of the requirements.

How a change control board meeting runs

1. The agenda is the list of new requests. “A list of recently submitted change proposals generated from the tool can serve as the agenda for a change control board meeting” (Using Change Control Tools).
2. For each request, the impact summary: what it touches, what it costs, which dates move, and the options — as asked, smaller, or later.
3. The owner of the area decides under the charter’s rule: accept, reject or defer, and for an accepted change, the release.
4. The decision is recorded with its reason, in the decision log and on the request.
5. Everyone affected is told. Wiegers: “inform the affected people expeditiously so they can properly process the change.” That includes the requester when the answer is no.
6. Old requests are closed. “Change requests that remain unresolved for a long time suggest that your change management process isn’t working well.”

Between meetings, small changes take the fast path, and urgent ones get a special meeting.

CCB vs change advisory board vs product owner

The change-advisory board belongs to IT service management: it reviews changes to systems in production, not to requirements. Searching “change control board” turns up both — the difference is in change control vs change management.

The Scrum Guide gives the backlog to one person: “The Product Owner is one person, not a committee” and “Those wanting to change the Product Backlog can do so by trying to convince the Product Owner” (Scrum Guide, 2020). For reordering the backlog, the product owner is the board, and asking for more is out of place: one answer calls formal change requests for backlog refinement “the antithesis of agility” (Project Management Stack Exchange, 2014). A change to what a client signed and paid for is different. Its price and dates still need the client’s yes — and on an agency project the product owner is often on the supplier’s side.

When a change control board is too heavy

“To some people, the term ‘change control board’ conjures an image of wasteful bureaucratic overhead,” Wiegers concedes. Asked whether extensive change control procedures are common, the accepted answer on Stack Exchange was: “It’s actually EXTREMELY common in Government/Aerospace/Health industries,” and “Most of the time they are a hindrance to innovation and the ability to adapt and change quickly” (Stack Exchange, 2011).

The signs: requests wait weeks for a meeting, meetings fail for lack of a quorum, and people start agreeing changes in the corridor instead. The cure is in the charter — fewer members, a higher threshold for the full board, and a fast path. Wiegers’ standard: “The CCB should be no larger and no more formal than necessary to ensure that the right people make good business decisions about every requested modification.”

A light board still does its main job, which is to make each request a decision with a cost. One commenter on what happens when a request has to go to the board: “Shuts 80% of that down immediately, the other 20% typically is a worthwhile change” (r/projectmanagement, 2021). And if no board is named, the decisions still get made. “Someone’s going to make all those decisions anyway,” as Wiegers puts it.

Where Specroot fits

This is the problem Specroot works on: each change kept with its request, its impact, who decided and why, and the version of the requirements it produced — so that a board’s decision is a record, not the memory of a meeting. Specroot for agencies and consultancies.