An organisation may know that a service is slow without knowing why or where to start. A consulting engagement is a defined assignment agreed by a client and consultant to understand a need, inform a decision or support improvement. This guide explains how the work moves from a clear question to usable deliverables, who is responsible, how outputs are accepted and how to select the consultant.
If you first need a definition of the field and its boundaries, start with Management Consulting Explained: Definition, Scope and Types.
Before the engagement: turn the need into a question
Many requests begin with a broad statement such as “we need to improve performance” or “we need to restructure.” That is a starting point, not a scope. Convert it into a question that can be answered: What causes service delay? Which decision rights create bottlenecks? Which capabilities are required to deliver the strategy over the next two years?
What should the scope include?
The scope of work defines what the assignment includes and excludes. It connects the question, deliverables and working method. A deliverable is something the consultant supplies, such as a process map or measurement tool. An outcome is the change that follows its use, such as a shorter waiting time. It identifies the units or processes covered, the period represented by the data, the stakeholders who need to participate and the assumptions behind the proposal. It also specifies review rounds, file formats, language and who approves the work.
Set decision gates: agreed checkpoints where both parties confirm readiness for the next stage. For example, solution design should follow approval of the diagnosis, and the roadmap should follow agreement on the preferred option. These gates reduce rework and prevent unresolved differences from carrying over into the next stage.
The 6 stages of a consulting engagement
The stages below are a practical explanation and can be combined for a smaller assignment. ISO 20700:2017 provides guidance on delivering management consultancy services. This 6-stage structure explains the work for readers; it does not reproduce the standard’s structure.
1. Initiation and scope
The parties agree the question, intended outcomes, deliverables, exclusions, roles, timetable, and governance. A good scope states what the engagement will not address as clearly as what it will.
2. Current-state discovery
The team gathers relevant information from documents, systems, interviews, and observation. The purpose is not to collect the largest possible volume of data. It is to establish a sufficiently reliable basis for decisions and to make data limitations visible.
3. Analysis and diagnosis
Analysis looks beyond symptoms to causes. It may use process mapping, accountability analysis, benchmarking, risk analysis, or performance indicators. The required result is a testable explanation, not a long list of observations.
4. Options and recommendations
Options are developed so leaders can compare benefits, cost, risk, and conditions for success. A sound recommendation explains not only what to do, but why that choice fits the organisation better than the alternatives.
5. Planning and implementation support
Recommendations become initiatives, owners, milestones, dependencies, and required decisions. Support may include templates, capability building, pilots, risk management, and progress reviews. This support must be agreed: a diagnosis-only assignment does not automatically include implementation.
6. Closure and knowledge transfer
The client reviews deliverables against acceptance criteria, knowledge and working files are transferred, open decisions are documented, and ownership for subsequent results is confirmed. Closure is a transition from project ownership to business ownership.
What deliverables should you expect?
Deliverables depend on the question. They may include a diagnostic report, process map, operating model, policy, governance framework, roadmap, dashboard, or change plan. A presentation alone is not sufficient when implementation requires working tools.
| Deliverable | What makes it usable? |
|---|---|
| Diagnosis | Clear evidence, root causes, and agreed priorities |
| Design | Defined roles, processes, and controls rather than general principles |
| Roadmap | Initiatives, owners, timing, dependencies, and risks |
| Performance measures | Linked objective, definition, formula, unit, baseline, target, data source, owner and review frequency |
How do you accept deliverables and control changes?
Agree acceptance criteria before work begins. A process map should do more than look attractive. It should show the process boundaries, responsibilities and decisions, and process owners should test it against a real case. Identify who reviews, who approves, when feedback is due and how it will be resolved.
When a new need emerges, record a change request. Describe the additional work, its reason and its effect on deliverables, time and cost. The authorised decision-maker decides before work starts. Distinguish correcting a deliverable that fails the agreement from adding work outside the scope.
Limit data access to what the task requires. Agree what may be shared, how information is stored and how it is returned or deleted at closure, subject to applicable requirements. Clarify rights to use the outputs and the file formats the team will receive.
Who does what?
- Executive sponsor: confirms direction, removes obstacles, and approves major decisions.
- Client project manager: coordinates access to people and information and tracks decisions and milestones.
- Process owners: explain the current reality, test designs, and own implementation.
- Consulting team: manages the method, analysis, design, facilitation, documentation, and knowledge transfer.
When decision-makers participate late, rework increases and recommendations are less likely to be adopted. Participation does not require everyone to agree on everything; it requires a clear way to hear evidence and resolve trade-offs.
Illustrative example: reducing late service requests
Suppose a service organisation completed 100 requests in one month, and 30 missed their agreed deadline. The late-request rate is 30 ÷ 100 × 100 = 30%. These figures are hypothetical, not client results or a general benchmark.
The client and consultant agree to study one request type, diagnose delays, design an improvement and run a 2-month pilot. The trial target is 15%, without increasing errors or overtime. Before comparing results, the team defines lateness, its calculation and the data source. This establishes the measurement baseline.
The team reviews request records and timestamps with employees. Suppose the evidence shows repeated waiting for 2 approvals. It compares simplifying approval with redistributing work. Management authorises a limited trial with suitable controls. The consultant supplies an updated process map, clear responsibilities and a tracking tool, and trains the team to use them.
The key performance indicator (KPI) is the late-request rate compared with the target. The service manager monitors it weekly alongside errors, overtime and request volume. Monthly results use the same definition, with checks for changes in request complexity or staffing.
The map and tool may meet their acceptance criteria while the outcome target still needs more time. At closure, the service manager takes over monitoring and sets a follow-up review date. This separates deliverable quality from implementation and the resulting improvement.
How to select the right consultant
Build a verified consulting shortlist
Check the legal entity that will contract with you before comparing proposals. The official Dubai business directory allows searches by business name or Dubai Unified Licence number. Use the relevant licensing authority for other jurisdictions. Registration establishes an identity check, not proof that a consultancy can solve your management problem.
Compare the proposed team’s relevant experience, diagnosis method, practical outputs, knowledge transfer, conflicts of interest and total fees. Ask for permission to verify comparable client work and distinguish the firm’s portfolio from the experience of the people assigned to your engagement. A brief initial enquiry can clarify the need; a lengthy request for proposals is not a prerequisite for starting a conversation. Keep a dated record of the evidence and selection reasons rather than relying on an unsupported league table of firms.
Common mistakes that reduce value
- Starting with a preferred solution before agreeing the problem.
- Expanding scope without adjusting time or resources.
- Relying on interviews without testing statements against available data.
- Leaving major decisions until the end of the engagement.
- Measuring success by meetings and reports rather than use of the outputs.
- Treating communication and change as activities that begin after design.
Frequently asked questions
How long does a consulting engagement take?
There is no universal duration. A focused diagnosis may take weeks, while a multi-workstream transformation may run for months. Timing should reflect the size of the question, data availability, and decision speed.
How do we know whether the engagement succeeded?
Use 3 levels: the quality of deliverables, their use in decisions and implementation, and the operational or strategic outcomes that emerge later. Do not attribute every result to the consultant alone because implementation is a shared responsibility.
Conclusion
Start with a defined question, then connect it to scope, deliverables, acceptance criteria and clear responsibilities. Test the solution before expanding it, and monitor use and outcomes after closure. Select the consultant based on the team, method and evidence, then define the support needed within services relevant to your organisation.