Resource Allocation Template for a Small Team (With Example)

A resource allocation template for a small team is a one-page worksheet that lists your real capacity (people time and budget), your competing priorities, and exactly how much of each priority gets funded. Build it in four moves: calculate true capacity, collect every ask, rank them, and fund from the top until the money and hours run out. What remains unfunded goes on a written "not now" list.

Most small teams skip the capacity step, so every plan quietly assumes 100 percent of everyone's time. This worksheet fixes that.

Why spreadsheets of "who's working on what" fail

Teams usually start with a list of projects and a name next to each one. That shows assignment, not allocation. It cannot tell you that you promised 130 weeks of work to a team that has 76.

Three problems show up again and again:

• Capacity is guessed. Someone says "we have nine people" and plans nine people's worth of project work, ignoring support, hiring, admin and time off.
• Demand is never totaled. Each priority gets approved on its own merits, and nobody adds up the asks.
• Nothing is cut in writing. Work that doesn't fit doesn't disappear. It leaks back in as "just a small thing" and starves the funded priorities.

The template forces three numbers onto one page: capacity, total demand, and the gap between them. Once you see the gap, the prioritization conversation gets honest.

The units: person-weeks and dollars

Use two currencies only.

Person-weeks are the unit for people. A person-week is one person working on a project for one week. It is coarse on purpose. Hours imply precision you don't have, and percentages of a person get confusing fast.

Dollars are the unit for discretionary budget: contractors, tools, ad spend, events, software. Exclude salaries and fixed costs you cannot change this quarter.

Pick a planning window. A quarter works for most small teams because it matches how long a real project takes. If you don't run quarterly planning yet, how to run a quarterly planning process for small teams covers the cycle this worksheet plugs into.

Step-by-step

1. Calculate true capacity

Start with gross capacity: headcount times weeks in the window. Then subtract in this order:

1. Paid time off, holidays, planned leave.
2. Run work: support, bug fixes, admin, hiring, internal meetings, the work that keeps the business alive. Most small teams land between 25 and 40 percent. Measure it for two weeks if you don't know yours.
3. A reserve of 10 to 15 percent of what's left.

What remains is your allocatable capacity. Do the same for budget: discretionary dollars minus a 10 to 15 percent reserve.

Do this by role as well as in total. A team can have spare marketing weeks and no spare engineering weeks, and the binding constraint is the one that matters.

2. Collect every ask

List every priority that someone wants funded, including the ones you already believe are untouchable. For each, write:

• The outcome, in one sentence with a number.
• People ask in person-weeks, split by role.
• Budget ask in dollars.
• The owner (one name).

Ask owners for a number they would sign. If the ask is a range, take the upper-middle, not the optimistic end.

3. Total the demand and name the gap

Add up the asks. Compare to capacity. The gap is almost always 30 to 70 percent. That is normal, and it is the reason you are doing this.

4. Score and rank

Keep scoring light. Rate each priority from 1 to 5 on three questions:

• Impact: how much does this move the number that matters this quarter?
• Confidence: how sure are you the work produces that impact?
• Urgency: what happens if it waits a quarter?

Multiply impact by confidence, then use urgency as a tiebreaker. Do not average the three; a priority with high impact and low confidence should lose to a modest, sure thing. If you want a deeper scoring method, how to prioritize features on a product roadmap works for any list of competing bets, not just features.

5. Fund from the top, then shrink scope before you cut

Allocate down the ranked list until a role or the budget runs out. When the next item doesn't fit, you have three options in this order: reduce scope, reduce ambition of the target, or defer. Splitting the remaining capacity thinly across everything is the fourth option, and you should rule it out.

6. Write the "not now" list

List what you did not fund, with the date you'll reconsider it. This list is what protects your plan from scope creep, because it turns a vague "maybe later" into a recorded decision.

Worked example: a nine-person SaaS company

A B2B software company has $1.8M in annual recurring revenue and nine people: a founder who also sells, one product manager, three engineers, one designer, one marketer, and two customer success reps. The planning window is a 13-week quarter.

Capacity. Gross is 9 people times 13 weeks, or 117 person-weeks. Time off takes about 9, leaving 108. Run work at 30 percent takes about 32, leaving 76. Engineering alone: 3 engineers times 13 is 39, minus 3 for time off is 36, minus 30 percent run work (bugs, on-call) leaves roughly 25 engineering weeks.

Discretionary budget is $75,000 for the quarter. They hold back $15,000, leaving $60,000 to allocate. They'd rather hold the reserve in cash than spend it and borrow later.

Demand. Six priorities came in:

Demand was 130 person-weeks against 76 available, a 71 percent overrun, and $100,000 against $60,000 in budget.

The role check caught a problem. In the first pass, onboarding needed 12 engineering weeks and the integration needed 16, for 28 against 25 available. Nobody saw it in the totals because the company had spare designer and marketing time. The fix was to cut the integration to one accounting tool (14 engineering weeks) and trim onboarding to the three biggest drop-off steps (10 engineering weeks). That's 24 of 25, with one week of slack.

The hard call. SOC 2 was the most expensive item and a few prospects had mentioned it. The founder checked: only two of 14 open deals had asked, both under $10,000. It went on the "not now" list with a review date at the next quarterly planning session, and the founder agreed to tell those two prospects a date.

The people view. Once the table was set, they mapped names to it. The rule: no one is on more than two funded priorities. One engineer owns onboarding, two engineers own the integration, the designer splits between pricing and onboarding, and the marketer runs content and the pricing launch. The founder and one CS rep run the outbound pilot.

Template

Copy this into a doc or spreadsheet and fill it in.

RESOURCE ALLOCATION WORKSHEET
Team: ______   Window: ______ to ______   Owner: ______

1. CAPACITY
Headcount: __   Weeks in window: __   Gross person-weeks: __
 - Time off / holidays: __
 - Run work (__%): __
 - Reserve (10-15%): __
Allocatable person-weeks: __
 By role: Eng __ | Design __ | Marketing __ | CS __ | Other __

Discretionary budget: $__   Reserve (10-15%): $__
Allocatable budget: $__

2. PRIORITIES (one row each)
Priority | Outcome with a number | Owner | Role-weeks ask | $ ask
Impact (1-5) | Confidence (1-5) | Urgency (1-5) | Score

3. TOTALS
Total demand: __ weeks, $__
Capacity:     __ weeks, $__
Gap:          __ weeks, $__

4. ALLOCATION (ranked)
Rank | Priority | Funded weeks by role | Funded $ | Scope change

5. CHECKS
[ ] No role over capacity
[ ] No one on more than 2 priorities
[ ] Reserve untouched
[ ] Every funded priority has one named owner

6. NOT NOW LIST
Item | Why deferred | Review date

The mistake that sinks most plans

The most common error is funding everything at partial strength. When the gap is 71 percent, it feels fair to give each priority 60 percent of its ask. It isn't. A project that needs 36 weeks and gets 22 doesn't deliver 60 percent of the value; it delivers nothing until it ships, and it may never ship.

Avoid it with a simple rule: a priority is either funded to a version that completes, or it isn't funded. In the example, the integration was cut to one tool, not shaved across three. If you can't describe a smaller version that still works, defer it.

The related mistake is skipping the reserve. If your plan uses 100 percent of allocatable capacity, the first sick week or urgent customer problem breaks a commitment. A reserve of 10 to 15 percent is not slack. It is what makes the rest of the plan real.

Keeping the allocation alive after the meeting

A worksheet that lives in a folder doesn't change behavior. Put it on a schedule:

• Weekly: owners flag any role-week overruns in your regular team meeting. A fixed agenda like the one in this weekly team meeting agenda keeps it to five minutes.
• Monthly: compare funded weeks to actual weeks spent. If a priority is running 25 percent over, decide then whether to cut scope or pull from reserve. A monthly business review is the natural place for this.
• Mid-quarter changes: a new request may only enter by displacing something funded. Write down what comes out. If nothing can come out, the request goes on the "not now" list.

This is also the cheapest defense against scope creep. Every extra request has to show up as a trade in weeks and dollars, which makes the cost visible to the person asking. For the tactics on handling requests that bypass this, see how to manage scope creep before it derails your plans.

Key takeaways

• Plan against allocatable capacity, not headcount. Subtract time off, run work and a 10 to 15 percent reserve before you assign anything.
• Total the demand and name the gap in writing. A 50 to 70 percent overrun is typical, and seeing the number is what makes cutting possible.
• Check capacity by role, not just in total. In the example, engineering was the binding constraint while other roles had room.
• Fund priorities to a complete, smaller version or not at all. Spreading thin across everything delivers nothing.
• Keep a "not now" list with review dates, and let new requests in only by displacing something already funded.
• Review the allocation monthly against actual time spent, and change it deliberately rather than by drift.