In a consulting firm the product is people’s time, so staffing projects is not admin, it is the core of the business. Every hour of a consultant on the wrong work is either lost margin or a project delivered late. Once the team grows past a few dozen people, a spreadsheet and the resourcing manager’s memory can no longer keep up, and staffing decisions become too slow and too much of a guess.
In our experience this is the moment for custom resource management software, not yet another off-the-shelf tool that doesn’t understand the concepts a professional services firm lives by: a task schedule is not the same as staffing people onto roles, and a holiday calendar says nothing about margin. We don’t have a case study in exactly this area, but we have engineers who have built planning tools, resource registries and integrations with HR and sales systems. In a team augmentation or dedicated team model we drop those skills in where they’re missing, and we treat the system as custom software maintained over years, because only a tailored build reflects your billing models (time & materials, fixed price, retainer), seniority levels and rates.
What is a consultant skills and availability registry?
It is the foundation of the system: a single source of truth about who you have and when. Without it, every forecast and allocation is built on sand. We build it to hold several layers of data at once:
- the skills profile (technologies, certifications, industries, languages, project roles),
- the proficiency level and proven experience, not just self-declarations,
- availability over time, with allocations, leave and soft bookings,
- constraints such as location, willingness to travel or non-compete clauses.
The point is to keep the data live rather than archival. So we wire the registry into the systems where this information already originates, instead of asking people to fill in yet another spreadsheet.
How do you build a staffing and allocation tool?
Staffing is a matching problem: project demand on one side, available people with the right skills on the other, and a good tool shortens the path from “who can join this project” to a decision from hours to minutes. We design, above all, a clear allocation view on a timeline, where you see who is free, who finishes next week and who is overbooked. We add soft and hard bookings, to tell a confirmed assignment from one planned against an unsigned proposal. We also automate match suggestions: the system proposes candidates for a role by skills, availability and rate, while a human makes the final call. We don’t pretend staffing is fully algorithmic, because the client relationship and a consultant’s development path matter too, so we build it as decision support, not an automaton.
How do you plan consultant utilisation?
Utilisation is the metric the board watches, because it shows how much of the team’s paid time generates revenue. The trouble is that utilisation measured after the fact is a quarter late, while decisions have to be made earlier. We build planning so that it looks forward:
- planned utilisation derived from current allocations and bookings,
- target utilisation per role, business line or seniority level,
- early alerts about people dropping below or climbing above the threshold,
- a clear split of billable time from investment time (development, pre-sales, internal initiatives).
We also make sure the dashboard explains the metric rather than just displaying it, because 85 per cent utilisation means one thing for an architect and quite another for a junior on the bench ahead of a large contract.
How do you integrate staffing with the recruitment pipeline?
Staffing and recruitment are two sides of the same skills gap. If the system can see that in six weeks you’ll be two senior people short in a technology, that signal should reach recruitment automatically, not after the fact. So we connect the tool to the recruitment pipeline so that:
- skills gaps from planning become recruitment demand,
- candidates in process show up as future, conditional availability,
- a new hire’s start date feeds the capacity forecast,
- the build vs buy decision (recruit, move someone internally or reach for contractors) rests on the same data.
We build the integration through the existing ATS API, without rebuilding it, so that one gap isn’t counted three different ways in three places.
How do you forecast capacity against the sales pipeline?
Sales promises clients delivery dates, and delivery has to staff them with people. Without a shared view, sales sells a team that doesn’t exist, or the firm keeps people on the bench because it can’t see what’s coming. We build a forecast that overlays the sales pipeline onto team availability: opportunities enter the plan with their probability and expected demand for roles, so the system shows not a single scenario but a range, what happens to capacity if you close 30, 50 or 80 per cent of the pipeline. We don’t promise magical accuracy, because sales data tends to be optimistic, so the tool surfaces its assumptions rather than hiding them in one number.
How do you resolve allocation conflicts and test scenarios?
Allocation conflicts are daily life: the same person is needed on two projects, a client pushes a start date, a key consultant takes extended leave. A good system doesn’t pretend conflicts don’t exist, it surfaces them early and suggests ways out:
- detecting overlapping bookings and availability overruns in real time,
- “what if” scenarios, the effect of moving someone without touching production data,
- an impact view of which project suffers if you pull a specific person off it,
- a decision trail of who changed an assignment and why.
Scenarios matter most here: the resourcing manager plays out several options in a sandbox and only promotes the best one into the plan, instead of testing changes on live projects.
Which skills do we provide for this kind of project?
We shape the team around the specific system, not “just in case”. A resourcing tool sits where business logic, data and integration meet, so the team combines several skills:
- an architect and backend developer designing the data model for availability, skills and allocation,
- a frontend developer owning readable timelines and utilisation dashboards,
- an integration specialist connecting the system to HR, ATS and CRM through APIs,
- an analyst or product owner translating staffing and billing rules into requirements.
Where the forecasting and match-suggestion layer comes in, we add data and AI skills (predictive models, scoring candidates against a role). That is a real competence in our group, which we plug in where it adds value, not for the buzzword.
How do we do it at RITS?
We do it as a nearshore partner from Poland, in the model that fits your situation. We build the system as custom software developed by our team when you start from scratch, or we augment your team with the missing roles when the tool is built in-house. We verify skills before the start, shape the team around the specifics of the system, and thanks to a close time zone we join your code reviews and meetings without a long ramp-up. Even without a case study in exactly this area, we supply people who have built planning tools and data integrations. That is the heart of our offer: a competence you actually staff, not a promise.
Where do you start building a staffing system?
Start from the single most painful question you can’t answer quickly today, for example “who is free in three weeks and has the skills for this project”. That defines which data registry to build first and which integrations are genuinely required at launch. It’s better to ship one working flow (registry plus allocation view) and grow it towards forecasts and scenarios than to design everything at once. We covered the differences between a custom build, team augmentation and managed services in our article on IT engagement models.
Building a project staffing or consultant availability system? Let’s talk, we’ll match a team and an architecture to your delivery model.