How can I prove on paper that we need more resources for our team?

Question

The higher management in most places seems to have a pigheaded tendency to avoid hiring more resources at all costs. The company has been growing in the last few years and a lot more functionality has been added to the product. The team size should also gear up to scale. In my case, every time I approach them on the subject of hiring more resources they give me one of the following answers:

• We cannot add more resources right now because we are in a financial situation (while the company reports a consistent double digit growth in profits)
• The argument about improving existing resources so they scale up and become more efficient
• The philosophy about how we are "passionate, relentless, courageous people" who are so "committed to our customers" that we would "gladly go over the extra mile" to get our job done
• My own leadership capabilities start getting questioned - that I'm not "motivating them enough" or they would "stretch themselves for completing their work", or I need to find ways to increase efficiency, output. It's always something that I should be doing or the team should be doing besides hiring more resources.

Is there a way I can prove, on paper at least, that we need to have more resources?

Answer 1

TL;DR you aren't selling the right thing

Is there a way I can prove, on paper at least, that we need to have more resources?

It doesn't look like your goal is to prove anything. Even if it was, it would be rather pointless: in most cases a person who you have proven a point to won't like you after that.

You aren't going to get more resource by proving that your existing ones aren't enough.

The team size should also gear up to scale.

Why? What would happen if it doesn't gear up? "More strain" on an existing team is not, unfortunately, enough to trigger hiring. Until you dramatically fail, you are "enough" for the most real-life business cases.

What I would advise you to do, is to come up with the tangible value for the company in hiring new people. If bringing additional resources brings more value to the company, then it will be viewed from a different standpoint.

For example, "having more resources will":

• increase customer satisfaction by reducing issue resolution time
• improve product quality by doing better testing
• reduce time to market for new features by having more development capacity
• etc.

You should also try very hard to make these quantifiable, rather than abstract, if you have some historical productivity data at hand. Once you have numbers, ditch your text and draw a simple chart showing, for example, improvement of quality of service depending on more resources.

At the same time, you should protect your other ends, like this:

The argument about improving existing resources so they scale up and become more efficient

Make sure you have an improvement plan (remember, that to improve something you have to be able to measure it first), and consistently show something to your management. Almost no manager likes being in the dark, and until you show ongoing progress, it won't be noticed.

The summary: shift focus from what you want, to what your company/manager wants. Highlight the value for the company at each point and cut off everything that doesn't contribute to it.

Answer 2

If you truly need resources, whether it is human, financial, space, tools, etc, you will experience capability degradation. That degradation will cause some unfavorable result such as quality, time, morale, employee turnover, and costs. So the proof is embedded in your operations and / or project performance metrics. You should be able to show special cause movement on your numbers.

Unfortunately, there are too many organizations and leaders who are too quick to blame people--blame the manager, blame the team--and assume that someone else, another team, would perform in this exact same environment. So despite the numbers, if your organization culture is like this, you may not get very far.

Also, keep in mind that organizations tend to get fat and happy over time, meaning there are typically a ton of efficiency enablers untouched and there is a lot of resistance from existing teams to find them. Denying resources that a team is screaming for often causes a team to adapt and evolve, returning to pre-change performance levels while maintaining pre-change resource levels. Good leaders know this, too, so you really need to examine your current practices to ensure you have pulled every efficiency enabler lever you know how to pull.

Answer 3

You have to write down the task that every of your employee do : we call that a description of task. It is very rare now a day that an employee is given a clear description of task, if given. After you have to establish the deadline of your project : the starting date and the date of delivery. When you make you plan your project, you have to know day by day what you need : the amount of employee, the amount of money, the material parts to build your device or make your project. At the deadline, the date of delivery you must give to the customer(s) what they pay for. In advance, you have to know if there is a problem.

Answer 4

We are actually embarked on an experiment to help document exactly that need by using Kanban. The idea is to have data to give to management about where User Stories back up and for how long. That's where the kanban board comes in--we're tracking when the stories get to what spot in the workflow, how things back up, how long it takes to get work out.

This sort of data is an important first step. Sometimes it helps. Sometimes you need to think of other data to gather, or other ways to show management what is happening. If nothing else, a kanban-based push for limiting work in progress (WIP) based on kanban principles can still speed up the velocity with which changes make it from request to production.

Not of this will stop management from whining about lack of money or how everyone should get more efficient, etc. There may, in fact, be no money to staff up. You may need to dig up some articles about working routine overtime makes software develop more slowly, with more bugs, and increases staff turnover, but facts are not always the cure for belief. ("Code Complete" is a good reference for a lot of this; so are many books on Agile development, and of course, Anderson's original book on Kanban).

But, if management is impervious to data, you also know that you need to move to your next position elsewhere. Faith-based (in the sense of ignoring data) technology companies do not have a great track record of survival ;-).