The contract is signed and the sales handover call went well. Then the kick-off meeting starts. The client’s operations director expects every branch to be trained. Your consultant assumes the client will clean its own customer data. The salesperson remembers promising “something live before year end”. Nobody is wrong on purpose. Each person is working from a different version of the same engagement.
A project charter for professional services work exists to catch that problem before it becomes rework, a write-off or a strained relationship. In short: a client-engagement charter is a short document, approved by the people with authority, that states the outcome, how success will be evidenced, what is in and out of scope, what each party must provide, and who can decide what. Write it in the first week of delivery, from the signed commercial documents and a working session with the client. It is only useful if it exposes and settles the disagreements, so do not treat it as a signature-collecting exercise.
This guide gives you a six-step process, a completed hypothetical example and a one-page worksheet you can use on your next engagement.
What does a project charter do in professional services work?
In an internal project, the charter mainly authorises work and resources. In client work, it has a harder job: it turns what the sales process implied into what delivery will actually do. It does three things:
- Authorises delivery. It confirms that the engagement has started, who leads it on each side, and what they may commit to without going back to the sponsor.
- Makes the boundary visible. Outcome, scope, exclusions, client obligations and assumptions sit on one page where both parties can challenge them.
- Sets decision rights. When scope, dates or priorities are contested later, everyone already knows who decides and how.
The existing project charter documentation covers the standard components. This article also refines who needs to approve a charter, and it concentrates on what changes when there is a client, a contract and a delivery team with commercial targets.
Charter, statement of work, business case and plan: which does what?
Much confusion comes from asking one document to do another’s job. Keep them separate and consistent.
| Document | Question it answers | Usually owned by | What it should not do |
|---|---|---|---|
| Business case | Why is this worth doing, compared with the alternatives? | Client sponsor | Specify delivery tasks |
| Statement of work or contract | What is being bought, at what price and on what terms? | Commercial owners on both sides | Hold working assumptions that will change weekly |
| Project charter | What outcome are we delivering, within what boundaries, and who decides? | Delivery lead, approved by the sponsor | Override or quietly renegotiate the contract |
| Project plan | Who does what, when, in what order? | Delivery lead and team | Redefine the outcome or scope |
The Association for Project Management describes the business case as the justification for the work and says the sponsor owns the business case. In a client engagement, that business case often belongs to the client and may never be shown to you. Your charter should still restate the outcome it is meant to achieve. If you cannot write that sentence, ask before you plan.
How to write a project charter for a client engagement in six steps
Block roughly a week. The drafting is quick; the conversations take the time.
Step 1: Reconcile the sales handover. Owner: delivery lead. Put the proposal, statement of work, sales notes and any client emails side by side. List every place where they disagree or are silent: scope items, dates, who supplies what, how acceptance works. Decision point: each contradiction is either resolved by the commercial owner or carried into the working session as an open question.
Step 2: Write the outcome and the success evidence. Owner: delivery lead with the client sponsor. Describe the business result in one or two sentences, then the evidence that will show it has been achieved. Avoid percentage targets unless a baseline exists. If there is no baseline, make measuring one an early deliverable and agree the target once the data exists.
Step 3: Draw the boundary. Owner: delivery lead. List deliverables, then exclusions: anything a reasonable person on either side might assume is included. Add client obligations explicitly, with an owner and a date. A client obligation without a date is a wish, not a dependency.
Step 4: Name assumptions, dependencies and the few risks that matter now. Owner: delivery lead; each item gets its own owner. Write assumptions as testable statements with a date by which they will be confirmed. Record the three to five risks that could change the commitment. Detailed risk identification comes later; the charter only needs the ones that affect whether to proceed.
Step 5: Set decision rights. Owner: delivery lead, confirmed by the client sponsor and the delivery firm’s accountable lead. Name who approves the charter, who approves changes, who accepts deliverables and who resolves disputes. Separate these from the people who merely need to know.
Step 6: Hold the charter working session, then approve. Owner: delivery lead chairs; client sponsor decides. Walk through the draft with the sponsor, the client process owner and your lead consultant. Spend the time on the open questions, not on reading the document aloud. Decision point: the sponsor either approves, approves with named conditions, or sends specific sections back. Record the version, the date and the next review point.
Who approves, who contributes and who just receives the charter?
A common instruction is that everyone on the distribution list must sign. That confuses receiving a document with having authority over it. Approval authority depends on the organisation and the engagement, so agree it explicitly.
| Role | Typical people | What they do with the charter |
|---|---|---|
| Approver | Client sponsor; delivery firm’s engagement lead or director | Accepts the outcome, boundaries and decision rights; can authorise changes |
| Contributor | Client process owner, lead consultant, client IT or finance contact | Reviews and corrects the sections they know; raises disagreements before approval |
| Recipient | Wider project team, account manager, client department heads | Reads the approved version; raises questions through the delivery lead |
One person may hold several roles in a small firm. That is fine, provided each decision still has one named owner.
Worked example: a completed client-engagement charter
Hypothetical example: Kestrel Advisory, a 20-person business consultancy, has been engaged by Harbourline Freight, a regional logistics company, to redesign how new business customers are onboarded. New accounts pass between sales, credit control and operations, and Harbourline’s managers say customers wait too long for their first collection. The statement of work covers discovery, process design and implementation support.
| Section | Kestrel’s completed entry |
|---|---|
| Purpose | Redesign new-customer onboarding so accounts move from signed contract to first collection with fewer handoffs and less rework |
| Outcome | Sales, credit and operations use one agreed onboarding process, with clear ownership at each handoff |
| Success evidence | Baseline of current onboarding time and rework measured in weeks 1–3; target agreed with the sponsor at Milestone 1; new process used for all new accounts for four consecutive weeks |
| In scope | Current-state mapping; future process design; handoff checklists and role descriptions; training for onboarding staff at head office; four weeks of implementation support |
| Excluded | Changes to the CRM or finance system; cleaning customer data (Kestrel identifies the problems, Harbourline fixes them); training at branch depots; credit policy changes; recruitment |
| Client obligations | Process owner (Head of Customer Operations) available two half-days per week; sample of 30 recent onboarding records supplied by the end of week 2; duplicate and incomplete customer records cleaned by Harbourline’s data owner before go-live (week 10) |
| Milestones | M1 current state and baseline agreed (week 4); M2 future process approved (week 8); M3 go-live (week 10); M4 support ends (week 14) |
| Budget basis | Fixed fee for discovery and design; implementation support on time and materials up to the cap in the statement of work |
| Sponsor | Harbourline Chief Operating Officer |
| Delivery lead | Kestrel engagement manager |
| Approval rights | COO approves the charter, scope changes and M2; Head of Customer Operations accepts deliverables; any change to fee or cap goes through a variation to the statement of work, approved by the Kestrel director and accepted by the COO |
| Key risks and assumptions | Onboarding records are complete enough to measure a baseline (confirm by week 2); credit team available for design workshops during month-end (at risk) |
| Next review | At M1, or sooner if an approved change affects scope, dates or the fee |
Note what is not in it. There is no promise to “halve onboarding time”. There is no baseline yet, so promising a percentage would be a guess dressed up as a commitment.
The difficult exception. In the working session, Harbourline’s sales director says the salesperson promised CRM automation of the onboarding checklist, and that he will not support the project without it. The statement of work does not mention CRM changes.
The engagement manager does not argue about the promise. She says the charter will record it as an open disagreement and puts three options to the COO, who holds the decision: keep CRM changes excluded and log them as a candidate for a later phase; include a scoped CRM configuration with a revised fee and M3 date; or include only a specification of the CRM changes for Harbourline’s own administrator. The COO chooses the third option. Because the specification work is not in the statement of work, the Kestrel director and the COO agree a small variation to the statement of work to cover it: the director approves it for Kestrel and the COO accepts it for Harbourline. The charter does not set the fee itself. It moves to version 1.1, recording the decision, the date, the approver and the variation reference. The sales director may still be unhappy, but the disagreement now has an owner and a decision on record instead of a rumour.
The same method outside software and process work. An engineering consultancy producing a design pack would use the same headings. The outcome is an approved design; success evidence is acceptance by the client’s engineer; client obligations include site survey access and existing drawings; exclusions might cover planning submissions or construction supervision.
The one-page project charter worksheet
Copy this into your own template. The right-hand column is the test to apply before you ask for approval.
| Section | What to write | Ready for approval when |
|---|---|---|
| Purpose | One sentence on why the client is doing this | The client sponsor would describe it the same way |
| Outcome | The business result, not the activity | It can be true or false at the end |
| Success evidence | How you and the client will know the outcome was achieved | Any target has a baseline, or measuring one is a deliverable |
| Scope and exclusions | Deliverables, then anything someone might assume is included | Every contradiction from the sales handover is resolved or listed |
| Client obligations | What the client provides, by whom and by when | Each has a named owner and a date |
| Milestones | Three to six high-level milestones with target dates | Each ends in a decision or an accepted deliverable |
| Budget basis | Fixed fee, time and materials, cap or mix, referring to the contract | It matches the statement of work |
| Sponsor and delivery lead | Named people on each side | Both have agreed to the role |
| Approval rights | Who approves the charter, changes, deliverables and fee changes | No decision has two owners or none |
| Risks and assumptions | The few that could change the commitment, each with an owner | Assumptions have a date to confirm them |
| Next review | Date or trigger for the next review | It falls before the first major decision |
How to keep the charter current when things change
A charter that is never updated becomes a record of what you once believed. The APM defines change control as the process through which requests to change the approved baseline are captured, evaluated and then approved, rejected or deferred. The charter tells everyone where that decision sits.
In practice, give the charter a version number and a short change log: what changed, why, on whose approval and on what date. Update it when an approved change alters the outcome, boundaries, budget basis, milestones or decision rights. Minor plan adjustments belong in the plan, not the charter. Review it at each phase gate even if nothing appears to have changed.
Where a project charter falls short
A charter cannot create authority that nobody has. If the client sponsor will not make decisions, a signed document will not change that; escalate the governance problem instead. Nor does a charter replace the contract, legal review or a statement of work. It should refer to them, not restate them.
For a two-week piece of work, a half-page version is enough. Do not build the full worksheet for work that takes less time than the charter process itself.
The common failure mode is the charter as formality. The delivery lead writes it alone from the proposal, sends it to fifteen people for signature, collects some replies and files it. The disagreements it should have exposed stay hidden until the first review of a deliverable. If your charter session produced no disagreement at all, check whether the right people were in the room.
Keeping the charter connected to the work
Once approved, the charter is most useful where the team works every day, not in a shared folder. In Chronodesk project management, you can keep the charter and specifications in the project’s built-in wiki, record the charter’s risks in the project’s own risk register, and log time against tasks so actual effort can be tracked against the budget. The method above still does the real work. Software keeps the record visible, but it will not settle who decides.
Your next step
Before your next kick-off, spend an hour on Step 1: put the proposal, statement of work and sales notes side by side and list the contradictions. That list is the agenda for your charter working session. For the underlying principle, read why good project management is really about reducing uncertainty, and for the wider context of running client work, see project management for professional services.
Frequently asked questions
What is the difference between a project charter and a statement of work?
The statement of work is the commercial document: it sets out what the client is buying, the price and the contractual terms. The charter is the working agreement that authorises delivery, explains the outcome in business terms and names who can decide what. It should be consistent with the statement of work and never quietly contradict it.
Who should sign a project charter for a client project?
Only the people who hold authority over what the charter commits: usually the client sponsor and the delivery firm’s accountable lead, sometimes a client budget holder as well. Contributors review the sections that affect them, and everyone else receives the approved version. Collecting signatures from every recipient slows approval without adding accountability.
How long should a project charter be?
For most client engagements, the core fits on one or two pages, with supporting detail linked rather than pasted in. If the charter needs ten pages to describe the outcome, the engagement is probably still unclear. A short charter that settles the disagreements is more useful than a long one nobody rereads.
Does a project charter replace the contract?
No. The contract still governs price, liability and payment. The charter’s harder job is covering what the statement of work leaves unsaid, such as who supplies test data or how many review rounds a deliverable gets. Record those points in the charter as working agreements, and if one affects cost or risk, ask the commercial owners whether it needs a formal variation.
When should a project charter be updated?
After any approved change that touches what the charter commits, and at each phase gate. The delivery lead owns the change log and makes the edits, but never approves their own changes. Keep the charter and its log in one place both sides can open, such as the project workspace, not as attachments in email threads, so nobody works from an old version.