How Is the Need Defined Before a Consulting Project?

The outcome of a consulting project usually depends less on how the project is run than on how the need was defined at the outset. Our field observation shows that in most projects that fail to deliver the expected result, the underlying issue is not the consultant's method but a need definition that does not match the actual problem. The organisation describes a symptom, the proposal is built on that symptom, and when the project ends the visible indicator has changed while the structure beneath it has not. Defining the need is therefore not the first phase of a project but its precondition.

Not every consulting project run inside an organisation is an HR project. Some are owned directly by HR. In others, ownership sits with a different function and HR is responsible only for the people component. In a third group, HR is not involved at all. Who prepares the need definition, and within what scope, is determined by this distinction. This article sets out how the need is defined, what the brief document should contain, and how scope and success criteria are established, from an HR perspective.

Who Owns the Project and Who Defines the Need?

The scope of the need definition is set by project ownership. The first step is therefore not describing the problem but identifying the project owner. Ownership appears in three forms, and HR's area of responsibility differs in each.

The first group consists of projects owned directly by HR: workforce norm studies, job evaluation and pay structure, succession planning, performance systems, competency models and exit interview systems. In these projects HR defines the need, HR prepares the brief, and HR is the consultant's counterpart inside the organisation.

The second group consists of projects owned by another function that nevertheless affect the people structure. In an AI adoption programme the project owner is Information Technology; in an ERP migration it is IT and Finance; in a new plant investment it is Production. HR does not own these projects. Job descriptions for changing roles, the required competency set, the training plan, headcount impact and the adaptation process fall to HR. The need definition here is prepared in two layers: the owning function defines the technical need, HR defines the need related to the people component.

The third group consists of projects in which HR has no role. In areas such as supplier restructuring, product development or financial reorganisation, the need definition sits outside HR's scope unless there is a direct effect on the organisational structure. When this distinction is not made at the start, HR is held accountable for deliverables outside its own domain.

In projects HR owns or where it is responsible for the people component, the second step is to translate the request into the organisation's system headings. Consulting requests are usually expressed in outcome language: low engagement, managers seen as insufficient, lengthening time-to-hire, or a performance system that does not function. These statements describe a request but do not constitute a need definition.

The same symptom can stem from different structural causes. A longer time-to-hire may be a sourcing issue, but it may equally result from unclear job descriptions, pay positioning or a slow decision mechanism. A proposal prepared before establishing which cause applies addresses the first statement rather than the actual need. Defining the need is therefore not correspondence but preliminary work.

Preliminary Analysis: From Symptom to Structural Cause

Preliminary analysis begins with a review of existing data and existing systems. Turnover rate, internal promotion rate, the distribution of performance ratings, training records, how current job descriptions are, and how far the organisation chart matches actual structure provide the first indicators for most problem headings. The data already exists inside the organisation; preliminary analysis brings it together around a single question.

The second step is a limited number of structured interviews. Short interviews with five to ten people clarify how the area indicated by the data appears in practice. These are not a research study; the aim is to determine at which level and in which process the problem arises.

The third step is producing an inventory of existing systems. Which systems are in place, which are based on a written document and which are actually applied are listed. In headings that require structural change, this inventory is the primary input for defining project scope. In multi-component processes such as cultural integration after mergers and acquisitions, the preliminary analysis phase directly determines project duration and resource requirements.

Where ownership sits with another function, preliminary analysis runs in parallel with that function's technical assessment and covers only the people component. HR's output in this case is not a standalone brief but a section added to the main brief document. Limiting the scope in this way makes it clear at proposal stage which heading falls to whom.

The duration of preliminary analysis varies with organisational size, but for most headings it can be completed in two to four weeks. A short internal report at the end allows the findings to be shared with the manager who raised the request and agreement to be reached on the problem definition. Moving to the proposal stage without that agreement produces divergent internal expectations when proposals are evaluated.

Consulting Project: Contents of the Brief Document

The output of preliminary analysis is the brief document shared with consulting firms. It raises proposal quality and allows proposals from different firms to be compared on the same basis. A comprehensive brief covers the following headings:

•     The owning function and HR's role in the project (process owner, owner of the people component, or stakeholder)

•     A data-based summary of the current situation

•     Definition of the problem to be solved and its observed effects

•     Areas excluded from scope

•     Units, levels and locations covered by the project

•     Expected outputs and delivery format

•     Success criteria and how they will be measured

•     Timeline and the internal resource to be allocated

•     Decision authority and approval flow

•     Similar work previously carried out and its results

Writing down what is out of scope matters as much as writing down what is in scope. When the project's exclusions are not stated, expectation gaps usually surface during implementation. In projects involving more than one function, this heading also records which deliverable belongs to which unit.

The brief should be approved internally before it is shared. The approval process includes the manager who raised the request, representatives of the affected units and the budget owner. Corrections made at this stage are both faster and less costly than scope changes made after the project has started. The approved brief also serves as the shared reference document during proposal evaluation.

Scope, Success Criteria and Handover Plan

Success criteria define how completion will be recognised. They must be measurable; the number of documents delivered is an output indicator, not a success criterion. How many units have begun applying the system, how many managers can run the process independently, or how long the target process now takes are measurable criteria.

Determining internal resource in advance is also part of the scope decision. Consulting projects require data preparation, interview coordination and pilot support from internal teams. When this workload is not estimated, the schedule extends through internal delays. Recording in the brief how many people from which unit will allocate roughly how much time per week keeps the timeline realistic.

The handover plan is the component most often skipped. Who will run the system inside the organisation once the consulting work ends, which documents will be transferred and what training the internal team will receive should be defined from the outset. Without this, the system has no owner once the engagement closes. Where ownership sits outside HR, the handover plan is prepared under two headings: the technical structure transfers to the owning function, and the people-side systems transfer to HR.

HR's position in the project is also put in writing during the need definition phase. In projects HR owns, stakeholder management, data flow and implementation tracking run from a single point. Where ownership sits with another function, HR's responsibility is limited to the people component and that boundary must be stated explicitly in the brief. Without it, HR is held accountable for deliverables outside its scope while its own outputs go untracked. Where ownership is not defined at all, the project advances with the consultant repeatedly searching for a counterpart at every stage.

Project governance is set up at the same stage. Decision authority, the frequency of progress meetings, the format of interim outputs and how scope change requests will be handled should be written in advance. A two-week progress meeting rhythm provides sufficient tracking for most projects. Once this framework is defined, decisions taken during the project are recorded, and what remains in the organisation at the end is not only the output but knowledge of the process itself.

A correctly defined need shortens the duration of a consulting project and makes its output durable inside the organisation. Within our management consulting service, we support organisations in preparing the need definition and brief document for projects owned by HR, and in determining the scope of the people component in projects owned by other functions.

With 35+ years of corporate experience and 25+ years of C-level leadership perspective, we deliver strategic and applicable solutions. Contact us to define your consulting need.