Defining the Scope of a Consulting Project: Deliverables, Phases and Allocation of Responsibility

How a consulting engagement ends is largely settled before the work starts. Prepared after the proposal is evaluated and signed as an annex to the contract, the scope annex sets out which question the project answers, which deliverables it produces, which phases it runs through, and which work stays with the company and which with the consultant. In international practice the same annex goes by the name Statement of Work (SOW).

Once the scope of the consulting project is written into that annex, the document does two different jobs. For HR it is the day-to-day frame of the work: data requests, the interview timetable, approval steps and revision rounds all come from it. For senior management it is what the budget decision buys: it states which deliverable triggers payment and at which decision point the engagement continues. For the wider picture, our article on what management consulting covers sits ahead of this annex.

Through Which Sections Is the Scope of a Consulting Project Defined?

A scope annex that actually gets used contains the following sections:

→  Purpose and business rationale: the need behind the project and the decision it will inform once complete

→  In-scope and out-of-scope headings: which units, position groups and processes are included

→  Deliverable list and acceptance criteria: the format, scope and approver of each deliverable

→  Phase plan and decision points: the order and length of phases and the decision taken at the end of each

→  Allocation of responsibility: the consultant's work, the company's work and the joint work, set out separately

→  Inputs from the company: data, system access, the interview timetable and employee time

→  Change management and communication: rules for requests, approvals and reporting

The heading most often left out is the out-of-scope list. Where the annex does not say what the work excludes, requests arriving mid-project are treated as a natural part of it. Writing the out-of-scope list is not a way of closing the door on those requests; it ties them to a separate assessment and a separate plan. The list has a second use: it records what was discussed in the preparation session but kept out of the project, and that record feeds the next period's agenda.

When the annex is written matters too. It is not a copy of the proposal: it comes after the evaluation, following a preparation session in which the company's internal priorities and the state of its data become clear. Sitting in the contract annex makes the text equally binding on both sides and keeps it as the single reference throughout the project.

The consultant drafts the annex; on the company side HR and the sponsor read it. HR reads three lines in particular: the time asked of the company, the number of approval steps, and the revision rounds. Those three show what the work costs the company, and they rarely appear in the proposal.

Defining Deliverables and Acceptance Criteria

The section that decides the outcome is the definition of deliverables. "A report will be delivered" carries no measurable commitment. The defined version of the same deliverable holds four pieces of information: scope (how many positions, units or processes), format (document, template, system design, training session), approver, and the number of revision rounds.

An acceptance criterion is the condition a deliverable meets before it counts as delivered. In a job description exercise it reads like this: descriptions prepared for every position in scope, verified by the relevant managers, delivered in the final format HR has approved. With the criterion written down, the delivery conversation stops resting on personal judgement, and the question of who signs off does not wait until delivery day.

On the senior management side the value shows immediately. Where acceptance criteria are defined, a management meeting can see on one page which concrete deliverable the budget bought and which decision the work informs.

Writing down the number of revision rounds completes the section. For each deliverable, the annex states how many rounds of feedback are taken, how many days feedback takes to arrive, and who collects it. Gathered through one person and one file, conflicting comments do not get applied separately; with the timing defined, a deliverable waiting for sign-off does not hold up the project.

The sponsor's question in this section is short: which deliverable do I get, when, and for which decision? Where the delivery timetable lines up with the management meeting agenda, the decision can be taken before the engagement ends. On the HR side, the same timetable is what makes it possible to plan the data and interview time asked of the units.

Phasing and Decision Points

Consulting work is designed around four phases: diagnosis, design, pilot and rollout. Diagnosis gathers data on the current position and clarifies the need. Design produces the system, the document set and the rules. The pilot applies the design within a limited scope. Rollout takes it across the company.

A decision point closes each phase. It is the step where the parties assess whether the work continues as designed and record the answer in writing. Where diagnosis returns a different picture from the one expected, the design scope is updated here; without the decision point, the same update surfaces mid-project and outside the plan.

Tying payment to the phases makes those decision points count. When each phase has its own deliverable and its own acceptance criterion, progress is tracked on delivery rather than on time elapsed.

Phase durations go into the annex as well, though duration alone is not enough. Where a phase can only start once the company supplies something, the date of that input goes on the same line. If the effect of late data on the timetable is clear from the outset, the delay does not become an argument at the end of the project.

The pilot gets its own definition in the annex: which unit, how many positions, over what period, and which findings will update the design at the end. A pilot with a defined scope lets the rollout decision rest on data; without it, the pilot turns into an early start of company-wide implementation.

Responsibility, Change Management and Knowledge Transfer

The responsibility section covers four roles: a sponsor from senior management, HR as process owner inside the company, unit representatives, and the consultant team. For each deliverable the annex records which role prepares it, which gives input and which approves it. Setting up an internal project team is also what keeps the work inside the company; with no one to receive the knowledge, the deliverables end up in the archive unused.

The communication section sets the reporting rhythm. A short weekly status note, an assessment for the sponsor at the end of each phase, and a one-page summary at decision points make a sufficient set. With fixed headings, the status note moves the discussion from percentage complete to the decisions still open. Those headings usually run: completed, in progress, inputs awaited from the company, and items awaiting decision.

The change management section sets out how scope updates run. The standard flow is straightforward: the request comes in writing, its effect on time, deliverables and fee is calculated, and nothing is implemented before approval. With that flow defined, flexibility on scope becomes a manageable matter.

The closing section lists the documents, templates and training content to hand over. In structural transformation work this handover matters particularly: the position dictionary and mapping table produced when combining the organisational structure after a merger keep being used in later periods, provided they are delivered in a format the company can update. To see how we design consulting projects, you can look at our management consulting service.

At Kaan Böke Yönetim Danışmanlığı, we bring 35+ years of corporate experience and 25+ years of C-level leadership perspective to strategic, applicable solutions. To define the scope of a consulting project and design its phase plan in your company, get in touch.