Resource Management for Consulting Firms: Who Decides Who Staffs What

Resource management for consulting teams is the practice of deciding which named person staffs which engagement, at the right skill and seniority, and recording who held the authority to make that call. It is not scheduling. Scheduling assigns people to work that already exists. Resource management answers the staffing question directly: given this engagement and these people, who goes on it, in what role, and who decided. What it tracks is people and the staffing decisions made about them, not hours.

The stakes are concrete. SPI Research benchmarks show that teams running a connected resource management approach report roughly 10% higher billable utilization than teams running on spreadsheets. The difference is rarely a delivery problem. It is staffing the wrong person on the wrong engagement, or staffing the right one too late, because the skills-to-role match and the authority to assign live in different places. On a 70-person team billing 65 people at an average of 180,000 dollars a year, that 10% gap is around 1.1 million dollars of utilization left on the table.

Picture the director of resourcing at a 70-person consulting team on a Monday. A new engagement just closed and needs a lead by Friday. She opens three tabs. Tab one is the resource scheduler, with everyone’s allocation in colored bars. Tab two is the skills directory, with role and seniority by person. Tab three is a spreadsheet she built four years ago, where she maps named people to engagements and notes who signed off on each assignment.

Which tab makes the staffing decision? Tab three. The other two are reference. The decision lives in the spreadsheet because the scheduler knows who is free but not who is right, and the directory knows who is qualified but not who has the authority to assign them.

Resource management keeps failing the same way. The tools track allocation. They do not hold the staffing decision: who should lead this engagement, in what role, and who gets to make that call. That decision, the skills-to-role match and the sign-off behind it, lives outside the platform, in a side spreadsheet, every time.

What resource management actually is

Resource management for consulting teams is the staffing decision plus the authority to make it: matching a named person to a named engagement at the right role and skill, and recording who held the authority to assign them. The match answers who is right for this role. The authority layer answers who gets to say yes. Most tools track the assignment after it lands and skip both of those, which is why the decision still lives in a spreadsheet.

It helps to see where resource management sits against the rest of the planning stack. A consulting team runs three layers on the same people. The forecast is the pipeline weighted by stage: what work is probably coming. The estimate is capacity by skill and week: whether enough of the right people exist to deliver it. Both of those are portfolio questions, and both belong to capacity planning. Resource management owns the third layer, the actual: the named assignment of a specific person to a specific engagement, in a specific role, signed off by a specific owner. Forecast and estimate tell you whether the team can take the work. The actual is the named call that commits a person to it, and that call is where authority lives.

So resource management is two things welded together: the skills-to-role match and the authority routing that turns it into an assignment. Most tools record the result and miss the decision.

The skills-to-role match is the harder half. You need bench by skill, not just bench by headcount, because the question is never who is free but who is the right role and seniority for what this engagement needs. A senior consultant idle next week is useless to an engagement that needs a principal-level lead. The match has to run against the role, not the open slot.

The authority routing layer is what most tools reduce to a status field. Practice lead requests Jamie for a lead role. Resourcing director approves or counters. A partner signs off when the request crosses a threshold. Assignment lands. That chain of named owners is the part teams most need recorded, because when an engagement goes sideways, the first question is who staffed it and on what basis.

What a staffing record has to hold

A staffing record has to hold four things, not two: the person (skills, role, status), the role the engagement needs (which is not the title the person holds), the match between them, and the decision that turned the match into an assignment (who approved it, and why). Standard schedulers hold the person and the assignment. They drop the role profile and the decision, and that is exactly where staffing goes wrong.

Most resource tools hold two things: a person and an assignment. Sometimes three: person, assignment, and project. A record that can answer the staffing question after the fact has to hold four. The forecast and the estimate (what work is coming, and whether the team can cover it) belong to capacity planning. This section is about the fourth layer, the actual, and what each named assignment has to carry to be worth anything later.

The person. A named individual with skill tags, role, employee versus contractor versus partner status, target utilization, and unavailable time. This is standard, and it is the one thing most tools get right.

The role the engagement needs. Not a slot to fill, a role profile: this engagement needs a lead with SAP and data-migration depth, plus a consultant for process mapping. The role profile is separate from any person, and it is what the match runs against. Tools that only model open slots cannot tell a principal-level lead from a warm body with free hours.

The match. The link between a person and a role, with the rationale attached: this person fits, this one is a stretch, this one is wrong for the role even though they are free. A scheduler records that Jamie is 80% allocated. It does not record that Jamie was the right role match and Dana was the stretch.

The decision. Who decided, when, why, and what they traded off. Tools usually treat this as a comment on an assignment. Recorded as its own thing, it is what makes a staffing call auditable six months later when an engagement is in trouble and the first question is who put that person on it.

If your tool holds all four, you have a chance. If it holds only the person and the assignment, you are running on a scheduler, not a resource management system.

What the staffing record looks like in practice

A staffing view for a consulting team shows each person’s name, role, skill, engagement, allocation percentage, and commitment status (confirmed, soft commit, or pipeline hold) in a single table. It includes not just closed work but verbal agreements and weighted pipeline. Without those last two columns, the conflict check is always two weeks late.

Most resourcing discussions stay abstract. Here is what a week-of-staffing view actually contains for a 12-person life-sciences consulting team carrying four active engagements and two weighted pipeline deals.

Three things this table shows that a standard scheduler does not:

Soft commits are named. Jamie is 100% allocated across two engagements: 80% confirmed, 20% on a verbal. If Kellner closes before Nexagen Phase 2 ends, that conflict is visible now, not in week three of the engagement.

Pipeline is named. Priya and Marcus carry partial holds against LumaCare, an RFP at 60% probability. If LumaCare closes at the same time Kellner does, there is a 30-person-day gap in senior consulting capacity in the same two-week window.

Skills are columns, not tags. Data migration and SAP is a skill that Jamie has and Tobi does not. When a new data-migration engagement comes in, the first question is not who has availability. It is who has the skill, and what their allocation looks like against that skill.

This is the table that lives in tab three, the spreadsheet. Getting it into a connected system means the conflict check and the staffing signal are automatic, not manual.

Who owns the staffing decision

Every staffing decision has an owner, and naming that owner is the part most tools skip. The scheduler shows who is free. The skills directory shows who is qualified. Neither says who has the authority to put a named person on a named engagement, or who has to sign off when two practice leads want the same senior consultant.

Staffing authority is the spine of this whole topic, and it is the part that has nothing to do with availability. In a 70-person team the chain is usually three roles. The practice lead requests a person for a role on an engagement. The resourcing director owns the assignment and resolves contention when two practice leads want the same senior consultant. A partner signs off when the request crosses a threshold: a marquee client, a contractor over a certain rate, a senior person pulled off billable work for internal delivery. Each of those is a staffing decision with a different owner, and a staffing record that does not capture the owner cannot tell you, six months later, who put Jamie on the engagement that went sideways.

This is why the recorded decision matters more than the allocation number. When a practice lead asks for a senior consultant, the question is not only whether she is free. It is whether she is the right role match, whether she has the skill the engagement needs, and who gets to say yes. The skills-to-role match and the authority to assign are two separate facts, and the staffing decision is where they have to meet. Get the authority chain wrong and you get the quiet failure mode: nobody actually owned the call, so when the engagement slips, the post-mortem is an argument about who decided rather than a record of why.

That authority question is what separates this piece from capacity planning. Capacity planning asks whether the team has enough of the right skills in aggregate, and runs the weekly habit that keeps that honest. Resource management asks who, specifically, gets staffed where, in what role, and who signed off. The capacity planning piece covers the portfolio side; this page stays on the named call and the authority behind it.

What spreadsheets get right

Spreadsheets survive in consulting resourcing because they hold soft commits, pipeline holds, and the Jamie-or-Priya trade-off in the same view at the same altitude where the decision gets made. No standard PSA does that natively. The right tool does not replace the spreadsheet with a database. It makes the database as malleable as the spreadsheet and connects it to pipeline data the spreadsheet cannot see.

The resourcing spreadsheet deserves a defense, because most tooling content treats it as the enemy and that is wrong.

The spreadsheet survives because it is the only tool most teams have that can hold the structure of the table above. The owner can add a column for soft commit. She can color a row by partner risk. She can model the Jamie-or-Priya decision side by side, with skills visible and allocation percentages on the same line, and jot who signed off in the next cell. She can change the model when the team changes. The spreadsheet works because it is malleable and because it sits at the exact altitude where the staffing decision actually gets made: above the calendar, below the financial plan, with everyone named and present.

What the spreadsheet cannot do is carry the authority chain or stay current once more than one person needs to write to it. The sign-off is a note in a cell, not a record. The match rationale lives in the owner’s head. The shape of a good resource management system is not to replace the spreadsheet with a database. It is to make the database as malleable as the spreadsheet, connect it to the pipeline the spreadsheet cannot see, and keep the named owner attached to every assignment so the system answers the staffing question the operator used to answer by hand. This is the test Servantium is built to pass: it merges the sales pipeline and services delivery into one surface, so the soft commits and weighted holds the spreadsheet tracks manually arrive already attached to the deal that created them, and the sign-off is recorded against the assignment rather than remembered. When a tool fails this test, operators are back in the spreadsheet within 60 days of go-live. When it passes, the spreadsheet stops being a separate system, because the connected one finally does what it did and keeps a record besides.

Matching the bench to the role

The hardest staffing move is the bench-to-role assignment: a person comes off an engagement, and someone has to decide what they go on next, in what role, against what skill the next engagement actually needs. This is where resource management for consulting teams earns its keep, and where headcount-based tools fail hardest.

A bench number is a lie at the role level. Saying the team has 80 hours free next week tells you nothing about whether those hours belong to a senior consultant who can lead a data-migration engagement or an analyst who cannot. The staffing question is always specific: this engagement needs a lead with SAP and data-migration depth, plus a consultant for process mapping. Who on the bench matches that role profile, and who has the seniority to be the named lead rather than support.

Role matching has a second layer the bench number hides: stretch. Putting a consultant into a senior-consultant role on a low-risk engagement is how teams grow people, but it is a deliberate staffing decision with an owner and a rationale, not an accident of who was free. A staffing record that captures the role a person was assigned to, separate from the title they hold, is the only one that can answer whether you are developing people on purpose or just filling seats.

This is the half a spreadsheet cannot keep current, and it is exactly where a connected system earns its place. When skills, role, seniority, and availability live in one surface, the match runs against the role the engagement needs, not the headcount that happens to be idle. Servantium’s resourcing intelligence drafts the match: given an open role on an engagement, it surfaces who has the skill, who is genuinely available, who would be a stretch and who a fit, and whether moving a kickoff would free the right person for the role. The assignment is still a human call with a named owner. The system does the matching work that used to mean cross-referencing three tabs by hand.

The 50-person inflection

Consulting teams below 30 billable people run resourcing from a spreadsheet and a single person’s institutional knowledge. That works. Above 50 people, the spreadsheet stops being legible to anyone but its author and becomes a single point of failure. The 30-to-50 range is the danger zone: too big for a spreadsheet, not big enough to staff a full ops team. Instrument the spreadsheet first, then evaluate tools. A 2024 BenchPress survey reported that professional services teams using PSA software ran 19% higher gross margins than spreadsheet-dependent peers.

A pattern that holds across teams. Below 30 billable people, the resourcing spreadsheet is fine. The owner of the spreadsheet has the whole team in her head, including who can say yes to what. The constraint is rarely tooling at this size. It is a CFO who trusts her judgment.

Between 30 and 50 people, the spreadsheet starts breaking. The owner cannot hold the whole team in her head anymore, and the authority chain that used to be obvious starts to blur as more practice leads request the same people. The tools available are too clunky to replace the spreadsheet, and the team is not big enough to staff a real ops function to make a tool work.

Above 50 people, the spreadsheet has to go. The forcing function is legibility: a connected system holds the same model the spreadsheet did, but everyone can read it, and it does not freeze the team when its author goes on leave. The decision quality still comes from the people who own staffing. The system is what keeps each staffing decision auditable and survivable past one person’s tenure: who assigned whom, to what role, on what authority. That is the operating risk that forces the buy, and it is a different risk from the capacity question of whether you have the people at all.

For teams in the 30-to-50 range, instrument the spreadsheet first, then evaluate tools. Add the columns a staffing record needs: the role each person is assigned to, separate from their title, and the owner who signed off. By the time you cross 50, you will know exactly what your tool needs to do, and the eval will take 90 minutes instead of six months.

What changes with a connected system

A connected resource management system holds all four things a staffing record needs (the person, the role the engagement needs, the match, and the decision) in one surface, so the staffing table that currently lives in a spreadsheet stays current automatically. Skill and role matching runs against the role an engagement needs, not the headcount that happens to be idle. Conflict checks run at the person level, not after the fact, and every assignment carries the owner who made the call. The result is that staffing decisions are made on complete data, by a named owner, not from the best available subset.

Servantium’s resourcing surface holds those four things in one place: the person (skills, role, status, target utilization), the role each engagement needs, the match against it, and the staffing decision with its recorded rationale and sign-off. It reads the live pipeline that capacity planning maintains, so soft commits and weighted holds arrive already attached to the deal that created them. The assignment grid surfaces the table above in real time, not in a spreadsheet. It shows overallocations at the person level and flags skill-specific bench rather than headcount bench. The intelligence drafts; the operator approves.

The result is that the staffing decision stops requiring three tabs. The people, their skills and roles, and the assignment decisions are in the same surface. The record of who staffed whom, in what role, on what authority, stays attached to the engagement where the consequences land, not in a Slack thread from eight weeks ago.