KPIs for an Outstaffing company
In a developer management role, you should be looking at metrics that will help you change processes and improve the way services are delivered. The more intelligence you can gain about how developers are utilised in the organisation, the easier it is to identify both quick wins and longer-term strategic improvements.
Below, we look at four KPIs your management can use to manage efficiency and track improvements.
Tracking the number of developer request cancellations over time is one of the most important metrics for an Outstaffing company. However, a single figure alone is of little value. You also want to record why the developer was cancelled. Were they booked in again at a later date (pointing to an issue with scheduling, or project delay) or was the work terminated for good?
Create a list of common reasons for cancellations, and allocate a reason to each cancellation. Track the revenue impact of each cancellation as well. Every project day cancelled is a day you aren’t paid. Even if the work is rescheduled for the future, it may not be possible to allocate that developer to another client in-between at short notice, so they may not be carrying out revenue-driving activity during that period.
Over time, you’ll get rich data about why developers are cancelled and what revenue impact that has for your company. Look out for trends. Is there one client that cancels more commonly than others? Is there a particular type of developer that gets cancelled more than others, perhaps software testers, or front-end developers? This can help you understand the thought process for clients. You may be able to influence future cancellations by reiterating the benefits of a particular type of work, or by addressing the underlying cause of cancellations.
Another good KPI to track is developer extensions. A developer extension happens when a developer is extended on a program. Let’s say an individual was scheduled to work on a client project for three weeks. At the end of three weeks, they are extended for another fortnight.
On the surface, that might look like good news. After all, you can bill the client for an additional 10 days of work, and the developer is fully booked for longer. But what about the project booked to start at the same time? Now that client is facing a delay because the developer is still finishing up their last job. However, developer extensions can point to other issues. If they are happening frequently, it could be because the client’s estimating process is not adequate. Are the sales teams effectively collaborating with delivery teams to ensure they fully understand what work is required to deliver the project?
Check your data for trends. In particular, look to see if any client (or type of client) is requesting extensions more than others. This could help you understand more about their industry or the complexity of their work, leading to a better negotiation process.
Sharing your bench just got easier
Are you currently using a Google sheet to manage and share your bench?
Teami makes it faster than ever to update clients and partners with bench resource availability.
Management should be able to track utilisation. Utilisation is a measure of how much time a developer spends on productive (in most cases: revenue-generating) work. Track how many developers are not being utilised at any given time, and also who those developers are. Again, you are looking for trends. Is it a few individuals that seem to be on the bench longer than others? Why could that be?
It’s easy to see that you want your staff to be as utilised as possible. A developer scheduler can help plan the work and match incoming projects to the available developers. If you can identify staff who are routinely under-utilised, look at their skills profile and how closely it matches the incoming work. Could they be retrained and upskilled so they can contribute more broadly to projects? Or is there another underlying issue that is stopping managers allocating them to client-facing work?
Time to Staff
Finally, look at how long it takes to start a developer once you have the client’s project or job spec. This time period equates to how much time is lost figuring out staffing levels and finding developers. The smaller you can make the time to staff period, the faster your projects get started. People spend less time not being utilised and more time client-facing. Clients are happier because they don’t have to wait so long for work to begin.
Once you’ve got enough time to staff data, you’ll be able to see what types of projects or clients take the longest. With that intelligence, you can start to plan staffing for those projects beforehand, so that you can minimise the lag when the project is eventually ready to start.
There might be other improvements you can make as well: review your process for requesting and allocating developers to see if you can streamline it with the right tools.
The more information you have, and the easier it is to interpret that information, the more you can improve your processes. The changes you make might feel subtle, but if you can cut a few days off each developer request, get better at estimating accurately and minimise under-utilisation in the team, you’ll make a huge difference to the bottom line and your customers’ satisfaction.