In one Consulting Quest engagement, the team worked with a client’s Finance team during the budget cycle. The work started by putting every consulting request for the coming year on one list: which unit asked, for what, at what cost, and when it wanted to start. All of this happened before any project was negotiated.
That list, reviewed with Finance before the budget was fixed, raised the client’s savings target by 4% of the consulting budget in the first year and by just over 8% in the second. Both figures came from demand decisions alone. The savings negotiated on each project come on top.
The requests on a list like this are rarely weak. Most have a sponsor, a budget line and a business case that holds up. That is exactly why the list mattered, because sound requests compete for the same money.
Prioritising consulting projects means comparing every request against the others, within a consulting budget agreed with Finance, and with someone who has the authority to stop or postpone. Approving each project on its own merits is a different job, called validation, and most organisations already do it well.
Most review committees approve consulting projects one at a time, so two sound projects both get funded
Most organisations that buy consulting regularly have a process for it. A request comes in through a form, a business case goes with it, and a committee reviews it before sourcing starts. People follow the process, and it does what it was built to do.
Take two requests in the same quarter. Project A has a sponsor, a budget line and a return that survives questions. Project B arrives with the same three things. Both pass the committee and both get funded, because nothing in the review asks which of the two is the better use of the same euro.
This is the gap between validation and ranking. Validation checks that a project deserves to exist: someone is accountable, the money is there, and the expected return is credible. Ranking decides where the project sits against every other claim on the same budget, and it accepts that some sound projects will wait a year.
Each function around the table does its own job well. Finance confirms that the money exists, procurement that the process was followed and the sourcing will be defensible, and the sponsor argues for the project they brought. None of those jobs includes telling a sound, fully budgeted project that it will wait because something else is worth more.
This is how a committee that reviews requests one at a time can approve every good project and still fund the wrong ones.
Without a ranking, a unit’s standing and last year’s budget decide the allocation
When two sound requests compete and nobody holds the job of choosing, something still chooses. In practice it is whatever needs no judgment: how much weight the requesting unit carries, and how much it spent on consulting last year. Neither is a decision anyone took, though both are always available when a portfolio question goes through a process built for one project at a time.
The allocation this produces leaves no trace in the minutes. Seen from inside, the year reads as a series of approvals, each one documented and each one correct. Nobody approved a weak project and nobody skipped a step.
So the review twelve months later rarely finds the cause. It looks at how the firms performed and at the quality of the business cases, and both usually hold up. The real decision happened earlier, when the budget was split along last year’s lines, and no document records it as a decision.
The incumbent firm plays the same role on a smaller scale. When one firm already holds three workstreams, the fourth tends to follow, because the relationship exists and the onboarding is already paid for. Continuity has real value, and its saving is easy to see. The question that goes unasked is whether that firm’s expertise was the best use of the budget for the fourth piece of work.
Overlapping requests stay invisible until two firms deliver conflicting answers
The same gap is easiest to see where business units commission consulting on their own. In a transformation programme, three units can brief firms on connected pieces of work in the same quarter. Each request is reviewed against its own business case, by a body with no way of setting it beside the other two.
The overlap appears later, in delivery. Two firms produce different recommendations on the same process, and someone has to decide which one the organisation will follow. By then, both pieces of work have been paid for.
It usually gets filed as a coordination problem, although a one-at-a-time review produces it quite reliably. An organisation that first sees a consulting need when the RFP goes out has no point at which two needs could meet. Catching the overlap takes two things upstream of sourcing: one view of the whole pipeline, and a check on whether work the organisation already owns answers part of the request.
The second check costs little. A study that one unit commissioned two years earlier can answer part of what another unit is about to brief, and only someone looking across units will know it exists.
Comparing requests starts with one pipeline and a consulting budget agreed with Finance
Demand management starts with visibility. Before anyone can compare requests, they have to sit in one place and be described in the same way: the business problem, what the unit expects to get, what it will cost, and when it needs to start.
In the Consulting Quest engagement, that list came first. Requests were gathered from across the business, each with its own project envelope, which is the bottom-up half. The consulting budget for the whole entity was agreed with Finance, which is the top-down half. The two were then reviewed together during the budget cycle, with Finance working alongside the review rather than receiving its result.
The two halves do different jobs. The consulting budget fixes the total, so every project envelope becomes a claim on a known amount and the review is a real choice between them. Without that total, the sum of the project envelopes tends to become the budget, and the review turns into a discussion about trimming it.
Finance plays a second role. Procurement can run the review and spot duplicates, and the sponsor can explain the need. Holding the total across all units is Finance’s job, and without that total the review has nothing to rank against.
Once the requests sit on one list, each one is scored on the same criteria. These cover the link to strategy, the expected value, urgency as distinct from preference, dependencies on other work, and whether something the organisation already owns answers part of the need. One set of criteria for every request is what makes them comparable. It also brings the overlaps described above to the surface on the first pass.
A review that can only say yes or no cannot free up budget
A demand review gives each request a decision, and the range of possible decisions is what gives the review its weight. An intake form that only knows “approved” and “pending” has no way to record the answers in between, and those are the answers that bring budget back.

The ranking also needs an owner, and that is the role most often left open.

The last row carries the weight. A committee without the authority to stop or postpone a project can only validate, however senior its members are.
A request is comparable only when it arrives with its need, impact, budget and expected return
Comparison needs a common format. A request written as a problem statement cannot be ranked against one written as a firm’s proposal, and neither can be ranked against a request that exists only as an email from a sponsor.
At its core, the business case carries four things: the need, the expected impact, the expected budget, and the return that the last two imply. Read commercially, it is the case an investor would want to see before committing money. It is also what lets the review put two requests from different units side by side and say which one is worth more.
Timing counts as much as content. The business case has to exist before the scope is written, because scoping takes the same senior time the review is meant to protect. Once a scope exists, with workshops held and perhaps a firm already consulted, the effort itself creates an expectation that the project will go ahead.
Few committees reverse that in practice, so a request that is scoped before it is ranked has, in effect, already been ranked.
In a transformation programme, the same rule applies to the roadmap. A roadmap whose workstreams carry no business case describes what the organisation wants to do. Once each workstream states its need, impact, budget and return, the roadmap also says what the organisation is willing to pay for, and in what order.
The ranking has to keep running after the contract is signed
Most review processes end at approval, although the budget keeps moving after it.
Change orders are the clearest case. An extra workstream, an additional analysis or a longer phase usually arrives as a commercial conversation with the firm about rate, duration and whether the change is fair. Each one is also a new claim on the consulting budget, and it takes money that the review had given to other work or held back. The real question is whether this addition is the best use of the remaining budget today. A price negotiation cannot ask it, because the only comparison it holds is between the firm’s price and what the work should cost.
Extensions work the same way. A running engagement renewed for another phase often skips the review because it is already under way, and the renewal is treated as continuity rather than as a new request. Sending larger change orders and extensions back through the same review keeps the ranking current through the year. A threshold agreed in advance, rather than debated case by case, stops this from slowing down every small adjustment.
One more question belongs in the review before any sourcing starts, which is whether the work needs an outside firm at all. A workstream that a firm could deliver cleanly looks most attractive at exactly the moment it deserves a question. Ease of delivery is a fact about the market, while the decision to buy rests on what the work is worth to the organisation. The make-or-buy decision has its own framework, covered in Crafting an Effective Make or Buy Framework for Consulting.
What running the review looks like in Consource
Consulting Quest ran that review as an engagement. Consource was built so that the same review keeps running after the engagement ends, every budget cycle and for every request, without the list being rebuilt in a spreadsheet each year.

What changes in the working week depends on the seat.
– Finance sees the consulting pipeline before the budget is split, and approved budget against actual spend during the year, without collecting a spreadsheet from each unit.
– Procurement receives requests that are already described in the same format, so the review starts with comparison instead of a chase for missing information.
– Strategy and Transformation sees consulting demand by department and approval stage, while the order of work can still change.
The governance body still makes every decision. What Consource changes is the ground it decides on: the full list, with the same information for every request, in every cycle. The platform is SOC 2 Type II and ISO 27001 certified, with data hosted in the EU.
See the review running on a live pipeline: Book Intake Demo
The second budget cycle is where the comparison pays
In the Consulting Quest engagement, the second year’s savings target was about twice the first: just over 8% of the consulting budget against 4%. The consulting budget itself came down by 4% in the second year, as a result of the same review. Both savings targets were set before any project was negotiated, which makes them the part of consulting ROI decided upstream.
The gap comes from time. A demand review is a discipline, and it takes more than one budget cycle to take root. Stakeholders also need to see the process work before they trust it. Once they do, requests arrive earlier and more complete, and a decision to re-scope or postpone is taken as part of the process rather than as a verdict on a project.
Three measures show whether the review is working:
– the share of reviewed requests that were re-scoped, combined, postponed or stopped
– the time from a request being submitted to a decision on it
– the share of finished engagements closed with a written account of what they delivered against the business case
Watch the first measure closely at the start. A review where almost every request proceeds is usually approving rather than ranking.
The practical step comes before the next budget cycle: put every consulting request for the coming year on one list with Finance, before the consulting budget is split between units.
An organisation that does this once gets a better budget for one year. One that keeps doing it gives the discipline time to take root, which is what the second year of this engagement showed.
See how Consource keeps the review running every budget cycle. Book Intake Demo
Frequently Asked Questions
1. How do you prioritise consulting projects?
Put every request on one list, described in the same format, and compare the requests against each other on the same criteria: link to strategy, expected value, urgency, dependencies, and whether existing work already answers part of the need. Do this within a consulting budget agreed with Finance, so the project envelopes compete for a known total, and give the review the authority to re-scope, combine, postpone or stop.
2. Who should own the prioritisation of consulting projects?
A governance body that can stop or postpone projects as well as approve them. Finance sets and holds the consulting budget, and procurement or the category manager runs the review and keeps the record of decisions.
3. How is prioritisation different from project approval?
Approval checks that a project deserves to exist. Prioritisation decides where it sits against every other request for the same budget. An organisation can approve every sound project and still spread its budget across the wrong ones, because approval never compares them.
4. When should Finance be involved?
During the budget cycle, before the consulting budget is split between units. Finance sets the consulting budget from the top while requests, each with its project envelope, are gathered from the business, and the two are reviewed together. Once the budget has been split, the review has nothing left to rank against.
5. How much can demand management save on consulting?
In one Consulting Quest engagement, reviewing the full pipeline with Finance during the budget cycle raised the savings target by 4% of the consulting budget in the first year and by just over 8% in the second. That came from demand decisions alone, and savings negotiated on individual projects come on top. For measuring the return on each engagement, see Maximizing Consulting ROI: A Strategic Playbook for Leaders.
