How to Scope an HR Consulting Project

A consulting project should begin with a business decision

“We need help with HR” is a real concern, but it is not yet a consulting brief.

It can describe an organisation-design problem, a management-capability gap, a broken performance rhythm, an unclear people strategy or a function that has become too transactional for the business it supports. If those possibilities are placed into one broad scope, the engagement usually produces activity without a clear finish line.

An effective HR-consulting project starts by making the business decision explicit: what must operate differently, why it matters now and what the organisation must be able to sustain after the consultant leaves.

Quick answer

A strong HR-consulting brief contains seven elements:

1. the business outcome;

2. the problem evidence;

3. the boundaries of scope;

4. the decisions the project must enable;

5. the required deliverables and adoption evidence;

6. governance, ownership and access; and

7. knowledge transfer and exit criteria.

If the brief is defined mainly as workshops, interviews, policies or presentations, it describes activity—not value.

Step 1: state the business outcome

Begin with the operating result the project must support.

Weak objective:

Review our HR function and recommend improvements.

Stronger objective:

Create an HR operating model that gives business leaders one accountable service, clarifies decision rights and can support the planned increase in workforce and operating complexity over the next 18 months.

The stronger version does not prescribe the solution, but it gives the work a commercial direction.

Useful outcomes may include:

• reduce leadership dependency on informal people decisions;

• redesign roles and decision rights after a business-model change;

• create management systems that can operate across multiple business units;

• establish a scalable people function before a growth phase;

• align workforce capability with the strategic plan; or

• transfer a newly built HR operating model to an internal team.

Step 2: separate symptoms from evidence

High turnover, slow hiring, manager inconsistency and leadership frustration are symptoms. The project needs evidence that helps explain them.

Collect only what will inform the diagnostic:

• business strategy and operating priorities;

• organisation structure and role accountabilities;

• workforce and capability data;

• decision and approval flows;

• employee lifecycle and management processes;

• existing measures and recurring leadership reports;

• previous project outputs; and

• known constraints, dependencies and non-negotiables.

Do not ask the consultant to validate a preferred answer. The evidence should be allowed to change the problem statement.

Step 3: define what is inside and outside scope

Scope protects both depth and accountability.

For each workstream, specify:

• business units and populations included;

• processes and decisions included;

• interfaces with finance, technology, legal and operations;

• systems or data the consultant may need to examine;

• implementation responsibilities; and

• related topics intentionally excluded.

This is especially important when consulting sits beside recurring HR outsourcing. Project design and recurring delivery can reinforce each other, but they require different outcomes, ownership and commercial models.

Step 4: name the decisions the project must enable

A consulting project creates value when leadership can make and implement a better decision.

Examples include:

• approve a future organisation structure;

• decide which capabilities to build, hire or access externally;

• define the role of the internal HR function;

• select a management and performance model;

• sequence a transformation roadmap; or

• choose which activities should remain internal and which can be outsourced.

Record who owns each decision, the evidence required and the date by which it must be made. Without a decision owner, the consultant can deliver the work while the organisation remains unchanged.

Step 5: specify deliverables and adoption evidence

A deliverable is not complete because a file has been sent.

For each output, define:

• what it contains;

• who approves it;

• which decision or operating process uses it;

• who must be able to run it; and

• what evidence demonstrates adoption.

For example, an operating model may include service architecture, roles, decision rights, governance, measures, capability requirements and an implementation roadmap. Adoption evidence may include approved ownership, trained managers, a live operating cadence and the first completed review cycle.

The CIPD describes organisation design as a systems activity: changing one part of the organisation affects others. That is why a useful brief should not isolate structure from work, people, processes and governance.

Step 6: design project governance before kickoff

Consulting projects slow down when decisions are treated as meeting outcomes rather than assigned responsibilities.

Set four levels of governance:

Sponsor

Owns the business outcome, removes barriers and makes the major decisions.

Project owner

Runs the client-side work, coordinates access and keeps decisions moving.

Working group

Provides operational evidence, tests designs and prepares implementation.

Decision forum

Approves defined outputs against explicit criteria. It should not become a second project team.

Also define meeting cadence, escalation routes, decision turnaround, data access and the process for changing scope.

Step 7: plan knowledge transfer and exit from the beginning

The organisation should be stronger when the engagement ends—not merely better informed.

The UK Government's Consultancy Playbook is designed for public-sector commissioning, but one principle translates directly: consultancy should create better outcomes and value while transferring knowledge and skills to the client.

Translate that principle into the brief:

• Which client roles will work alongside the consultant?

• Which methods, models and decisions must they understand?

• What must the internal team be able to run independently?

• Which documentation and training are required?

• How will the project close without creating permanent dependency?

This is the difference between receiving recommendations and building capability.

A one-page HR-consulting brief

Use the following structure before requesting proposals.

1. Business context

What has changed, and why is action required now?

2. Required outcome

What must operate differently when the project is complete?

3. Evidence and hypotheses

What is known, and what still needs to be tested?

4. Scope and interfaces

What is included, excluded and dependent on other functions?

5. Decisions and deliverables

Which decisions must be made, and what outputs support them?

6. Governance and access

Who sponsors, decides, provides information and runs the work internally?

7. Adoption, transfer and exit

What must be operating, evidenced and owned by the client at closure?

8. Commercial parameters

State the desired timetable, procurement constraints, proposal format and how additional scope will be controlled.

How to compare proposals

Evaluate the proposed engagement, not only the firm.

Ask:

• Does the team understand the business outcome or simply repeat the request?

• Is the proposed method proportionate to the decision?

• Are senior practitioners present in delivery, not only the pitch?

• Does the plan connect diagnosis, design, implementation and adoption?

• Are client responsibilities explicit?

• Will the organisation retain capability at the end?

• Are assumptions, dependencies and exclusions visible?

Price becomes meaningful only after the work and accountability are comparable.

Five common scoping failures

1. Starting with the deliverable: requesting a policy, structure or framework before diagnosing the operating problem.

2. Buying activity: paying for workshops and interviews without defining the decision they support.

3. Leaving implementation unowned: assuming recommendations will naturally become behaviour.

4. Combining every people issue into one programme: creating a scope too broad for meaningful accountability.

5. Ignoring the exit: allowing the engagement to create dependence on the people who designed it.

Scope for a working result

Good HR consulting should connect judgement to implementation. The engagement needs enough diagnostic depth to identify the real problem, enough operating detail to build a practical answer and enough transfer to leave the client able to run it.

Before issuing a broad request for proposals, use the one-page brief to force the essential choices. If the organisation cannot yet name the outcome, decision owner or finish line, that clarification is the first piece of consulting work.

For workforce-demand and capability decisions, use the 12-month workforce-planning model. For a separate decision about provider selection, read how to choose an HR consultant.

Sources

• CIPD, Organisation design, updated 28 February 2025.

• UK Cabinet Office, The Consultancy Playbook and knowledge-transfer guidance.

Author: Mayank Sharma, Managing Partner, Element MEA. Last reviewed: 3 August 2026. Review cadence: quarterly.