Set a Consulting Project Working Agreement Before Friction Starts

Many consulting projects do not stall because the team lacks expertise. They stall because nobody agreed on how the work will run.

Feedback arrives through three different channels. A weekly meeting becomes a status meeting, a working session, and a decision forum at once. The client assumes the consultant will chase approvals; the consultant assumes the sponsor will. By the time someone names the problem, momentum has already slipped.

A project working agreement prevents that drift. It is a short, shared record of the routines that keep the engagement moving. It does not replace a contract or project plan. It makes the day-to-day rules explicit.

Agree on the purpose and the people in the room

Start with the outcome the project is meant to produce and the decisions required to get there. Then name the people who play distinct roles:

• the executive sponsor who removes barriers
• the client lead who makes day-to-day choices
• the subject-matter contributors who provide inputs
• the consultant who owns the agreed work
• the people who must be consulted or kept informed

Do not rely on job titles alone. “Operations” is not an owner. Write down the person who can accept a deliverable, approve a change, or provide a required data set.

The UK Government's project guidance treats clear roles, governance, and accountability as core project controls. A working agreement is a practical way to establish those controls at the start of a smaller engagement.

Give every meeting one job

Meetings become expensive when their purpose changes without warning. Define the recurring sessions before the calendar fills up.

Set the default length and cadence. More important, state what each meeting will not do. A weekly check-in is not the place to reopen an approved scope decision unless a new risk makes that necessary.

Send a short agenda before the meeting and record actions, owners, and dates afterward. If there is no decision or action to capture, question whether the meeting should happen.

Decide how feedback becomes usable

“Please send feedback by Friday” is not a feedback process. It leaves open who can comment, whose view carries weight, and what happens when two reviewers disagree.

Write the answers into the agreement:

1. Which deliverables require review?

2. Who consolidates client feedback into one response?

3. What is the review window?

4. Who can approve the final version?

5. How will a late review affect the next milestone?

Ask the client to nominate one person to consolidate feedback. A consultant can work from one prioritized list. They cannot reliably reconcile competing comments scattered across email, chat, and a shared document.

Make decisions and escalation visible

Not every issue deserves sponsor attention. But every unresolved issue needs a path.

Use three levels:

• Working level: the client lead and consultant resolve routine questions.
• Project level: the client lead brings trade-offs involving time, scope, or dependencies to the project forum.
• Sponsor level: the sponsor decides when a barrier crosses teams, changes the intended outcome, or cannot be resolved within the agreed time.

For each escalation, record the decision needed, options, recommendation, decision owner, and date the answer is required. Include the impact of waiting. This makes escalation a tool for progress rather than a vague sign that something has gone wrong.

Set response expectations without pretending everyone is always available

Clients and consultants have other work. A useful agreement recognizes that reality.

Set reasonable response windows for routine questions, feedback, and urgent blockers. For example, a client lead might acknowledge a standard request within one business day and consolidate feedback within three business days. The right timing depends on the engagement; the important part is that it is agreed rather than assumed.

Pair each response expectation with a fallback. If the primary contact is unavailable, who can answer? If a decision is late, does the team continue with a stated assumption, pause the dependent task, or take the issue to the sponsor?

That protects the client from surprises and protects the consultant from silently absorbing avoidable delays.

Review the agreement when the project changes

The agreement should fit on one or two pages, and it should change when the way of working changes. Review it after kickoff, after a major scope change, or when the team keeps encountering the same friction.

Ask three questions:

1. Which routine is helping the work move faster?

2. Where are decisions or feedback still getting stuck?

3. What one rule should we clarify before the next milestone?

Update the agreement and share the new version with everyone affected. A working agreement only works when the team can find it and use it.

Start the engagement with fewer assumptions

You do not need a heavy governance manual to run a disciplined consulting project. You need clear rules for the moments that most often create friction: meetings, feedback, decisions, and escalation.

Create the working agreement in the kickoff, confirm it with the client lead, and use it in the first weekly check-in. That one habit makes it easier for good work to stay moving when the project gets busy.

Sources

• UK Government guidelines for managing projects
• Project Management Institute: Project governance