Business and Management Consulting

01Purpose and scope

• This manual supports the course Business and Management Consulting. It is written as a working reference for people who advise organizations on strategy, operations, organization design, technology choices, or performance improvement, whether they work in an external firm, an internal advisory group, or as independent advisors.
• The manual covers the activities that make up a typical engagement from first conversation to handover: understanding the client problem, agreeing on scope, gathering and analyzing evidence, shaping recommendations, supporting implementation, and measuring what changed. It also describes the roles, tools, and records that usually sit around that work.
• It does not teach a single methodology. Practice varies a great deal by sector, client size, and the kind of decision being supported. A five week diagnostic for a regional hospital network looks different from a three month cost review inside a manufacturing division, and both differ from an advisory role that stays on call for a board. Where a choice depends on local law, licensing, or sector rules, the current authoritative source governs, and this manual points you toward it rather than replacing it.
• Consulting in regulated or high-risk areas such as healthcare, financial services, tax, legal matters, and safety-critical operations carries obligations that this guidance does not settle. Nothing here replaces qualified professional judgment, approved internal procedures, or any authorization the client or regulator requires.

02Core principles

• The client owns the decision. A consultant's job is to make the decision clearer, better informed, and easier to carry out. When advice and the client's preference diverge, the difference should be stated openly, with the evidence and the trade-off made visible, rather than resolved by quiet persuasion or by softening the findings until nobody objects.
• Start from the question, not the answer. Most engagements that go wrong do so because the team solved a neighboring problem. Before any analysis, write down the decision the client must make, the options they are considering, and what would change their mind. That written question becomes the test for every later choice about data, interviews, and slides.
• Evidence should be proportionate. A recommendation that affects a capital budget needs more support than one that changes a meeting schedule. Match the depth of analysis to the cost of being wrong, and say plainly where the evidence is thin.
• Recommendations must be implementable by the people who will implement them. A plan that requires capabilities, budget, or political support the client does not have is a report, not a recommendation. Test feasibility with the operators, not only with the sponsor.
• Protect confidentiality and independence. Consultants see sensitive financial, personnel, and customer information. Access should be limited to what the work needs, and conflicts of interest should be disclosed before work begins, not discovered afterward.

03Planning and preparation

• Begin with a conversation that separates the presenting problem from the underlying one. A sponsor who asks for a sales force redesign may actually be trying to explain why the quarterly forecast keeps missing. Ask what has been tried, who has an opinion, what happens if nothing changes, and what success would look like to the people who will judge it.
• Write a scope statement that names the decision, the business units or processes in scope, the outputs, the timeline, the budget, and what is explicitly out of scope. Out of scope items matter as much as in scope items, because they are where later disputes start. Have the sponsor sign off on the statement, even if the signature is only an email confirmation approved under your firm's or department's rules.
• Identify stakeholders early and map their influence and interests. A typical map includes the sponsor who pays, the executive who must act, the managers whose teams will change, the frontline staff who hold the operational knowledge, and any functions with a veto such as finance, legal, information security, or works councils where they exist. Interviews should reach beyond the people who asked for the work.
• Plan data access before you need the data. Request extracts, system access, and document sets in the first week, and agree on who will provide them and in what format. Delays in data are the most common reason diagnostic phases slip. Confirm any data protection requirements that apply to personal data, and where the client is in a jurisdiction with specific rules, check the current legal requirements with the client's counsel.
• Set a team structure and a working cadence. Define who leads analysis, who owns client relationships, who runs the document trail, and who has authority to change the plan. Agree on a weekly steering rhythm with the sponsor so that surprises surface within days rather than at the final presentation.

04Recommended workflow

1. 1
   : Frame the problem. Draft a one page problem statement with the decision, the key hypotheses, and the criteria for choosing among options. Review it with the sponsor and at least one skeptical stakeholder before analysis begins.
2. 2
   : Build the baseline. Assemble the facts the client already has: financial statements, operating metrics, process maps, customer data, and prior studies. Note where figures disagree across sources and who owns each source. A baseline that nobody trusts will undermine every later recommendation.
3. 3
   : Gather primary evidence. Conduct interviews, observe work where practical, and run surveys or workshops if they serve the question. Record interview notes in a consistent template, and separate what people said from what the data shows.
4. 4
   : Analyze and test hypotheses. Use the analytical tools that fit the question, such as driver trees for profitability, process benchmarks against the client's own history, option scoring against agreed criteria, or scenario models for capital decisions. Test each hypothesis against disconfirming evidence, and write down the ones you rejected and why.
5. 5
   : Develop options and recommendations. Generate at least two credible options, including the option of doing little, and assess each on value, cost, risk, time to impact, and organizational fit. Recommendations should name the trade-offs explicitly, not only the upside.
6. 6
   : Validate with stakeholders. Walk the operators and functional leaders through the draft. Their corrections are not a threat to the work. They reveal constraints the analysis missed and build the support needed for implementation.
7. 7
   : Plan implementation and handover. Convert the chosen recommendation into an implementation plan with owners, milestones, dependencies, and resource needs. Agree on what the consulting team will do after the final presentation, whether that is nothing, a limited support role, or a transition to internal teams.
8. 8
   : Close the engagement. Archive working files according to the agreement and the client's retention rules, return or delete client data as the contract requires, collect feedback from the sponsor, and record lessons for the next engagement.

05Quality checks, risk controls and compliance

• Every deliverable should pass a review that is separate from the team that produced it. A second reviewer should check the logic, test the arithmetic on a sample of figures, confirm that sources are cited, and read the recommendation as a skeptical executive would. Keep a record of review comments and how each was resolved.
• Common risk controls include a scope change process, a register of assumptions with owners, a log of data limitations, and a conflict check against existing client relationships. Changes to scope should be written down with the impact on time and fees, and approved before work proceeds. Unapproved extra work is one of the most common sources of later disputes.
• Compliance depends on the client's sector, the location of the work, and the type of service provided. Anti-bribery and anti-corruption policies, competition law limits on information exchange with competitors, insider information rules for listed companies, and data protection obligations often apply. Where these rules are jurisdiction specific, consult the current official text or qualified counsel. A widely recognized reference for management consultancy practice is the ISO standard for management consultancy services, which describes process expectations, but it is guidance, not a substitute for local law.
• Where the work touches clinical decisions, financial reporting, tax positions, legal advice, or safety-critical operations, the consultant should not present conclusions as professional advice in those areas unless properly qualified and authorized. Refer those questions to licensed or accountable professionals and document the referral.

06Collaboration and documentation

• Keep a single source of truth for each engagement. This is usually a shared workspace with folders for data, interview notes, analysis, drafts, and client correspondence, with naming conventions the whole team follows. Version control matters: a steering deck that circulates in five different versions will generate five different conversations.
• Decisions should be recorded in a decision log that states the date of the decision, the people involved, the options considered, and the rationale. Avoid specific calendar dates in client-facing materials if your template does not require them, and use relative milestones such as week three or phase two when the timeline may shift.
• Working sessions with the client should produce short written notes within a day, listing actions, owners, and open questions. Client teams often assume that a verbal agreement is binding, and consultants often assume the same thing. Written confirmation prevents both errors.
• Deliverables need an audience. An executive summary serves the sponsor, a detailed analysis serves the finance or operations team that will test it, and an implementation plan serves the managers who must act. Build each document with its reader in mind and include an appendix that shows how figures were derived so that others can reproduce them.

07Measures and continuous improvement

• Define success measures before the engagement starts. Good measures are specific, attributable to the work, and observable within a time frame the client cares about. Examples include cost per unit in a named process, cycle time from order to delivery, first contact resolution rate in a service center, or the percentage of approved recommendations that reached the implementation plan within a set period.
• Separate output measures from outcome measures. The number of workshops held or slides delivered shows activity. Changes in margin, error rates, or customer retention show results. Track both, but report outcomes with honesty about what the consulting work caused and what other factors contributed.
• Establish a baseline and a tracking method that the client owns. Measures that live only in the consultant's spreadsheet disappear when the team leaves. Agree on the source system, the owner, the reporting frequency, and the threshold that triggers a review.
• Use after action reviews at the end of each phase and at engagement close. Ask what the team would repeat, what it would change, and what it learned about the client's decision process. Feed those lessons into templates, interview guides, and risk checklists so that the next team starts with a better toolkit.

08Common mistakes and how to prevent them

• Accepting the sponsor's framing without testing it. Prevent this by interviewing people outside the sponsor's reporting line and comparing their account of the problem with the original brief. Differences are worth exploring early.
• Building analysis on data nobody has checked. Prevent this by reconciling key figures with the finance or operations owner before they appear in a deck. A ten minute reconciliation call can save a week of rework.
• Overloading the final presentation. A deck with sixty pages and no clear recommendation rarely changes behavior. Prevent this by writing the recommendation and the decision request on the first page, and moving supporting analysis to appendices.
• Ignoring implementation capacity. Many plans assume the client has spare managers and budget in the same quarter. Prevent this by asking the client to name the people who will do the work and the time they can give it, before the plan is approved.
• Letting scope drift without a record. Prevent this with a written change process and a short weekly check of work performed against the approved scope. Small unrecorded additions accumulate into large disputes.
• Treating compliance as a final check. Prevent this by raising data, conflict, and regulatory questions in planning, when options are still open, rather than at the end when the team has invested heavily in one path.

09Practical checklist

• Confirm the decision the client must make and write it in one sentence agreed by the sponsor.
• Record scope, exclusions, outputs, timeline, and budget in a signed or confirmed scope statement.
• Map stakeholders, including those with veto or approval rights, and schedule interviews beyond the sponsor's group.
• Request data and system access in the first week and reconcile key figures with their owners.
• Check conflicts of interest, confidentiality terms, and applicable data protection and anti-corruption rules with counsel where needed.
• Test at least two credible options against agreed criteria, including the option of doing nothing.
• Validate draft recommendations with operators and functional leaders before the final presentation.
• Assign a second reviewer to check logic, figures, sources, and the feasibility of the implementation plan.
• Log decisions, actions, and assumptions in the shared workspace with clear owners and dates expressed as relative milestones where appropriate.
• Agree on outcome measures, a baseline, and the client system where results will be tracked after handover.
• Archive files and return or delete client data as the contract and retention rules require, then record lessons learned.

★Learning sources

• Micro Degree: Business and Management Consulting
• Micro Degree: Leadership and Team Management
• Micro Degree: Business Intelligence Management
• Micro Degree: ESG Advisory Services