The Three Project Types Every Agency Runs (and the One That Loses Money)

A pattern I've watched repeat at agency after agency: the leadership team is reviewing the quarter's project margin report, and one engagement is dragging the average down. It's the retainer with the long-standing client. The build was healthy; the retainer that followed it has been bleeding for six months. The team's instinct is to attribute it to a difficult client or a soft project lead.

The actual cause, almost every time, is structural: the retainer has been mixed in with the build in the reporting view. The build was profitable on its own. The retainer is unprofitable on its own. The combined number is mediocre, and the leadership team is now optimising the wrong project.

The fix is not better project management. The fix is to separate the three types of work that almost every agency runs, and report on each separately.

The three types

Every agency I've worked with, mine included, runs three distinct shapes of work in parallel. The three have different economics, different pricing models, and different cost lines. Reporting them as one thing is the most common structural error I see.

Development work

Fixed-scope, time-bounded engagements. A landing page rebuild. A platform migration. A six-week data integration. A four-month MVP build.

Economics: a fixed-price estimate, paid in milestones, with margin determined by how well the actuals tracked the role-rate estimate. Margin variance for development work is dominated by role drift (senior covering junior), scope creep (unbilled change requests), and the post-launch tail.

Risk profile: high upside, high downside. A well-priced build that ships on plan can land at 35–45% margin. A poorly-managed build with scope creep can land at 5–15% margin or worse. The variance is large because the engagement is fixed-price.

Support work

Ongoing, recurring engagements. A monthly hours retainer. A bug-fix and small-improvements arrangement. A 24/5 standby contract for a production system. Often follows a development engagement; sometimes started independently.

Economics: a fixed monthly fee for a budget of hours (e.g., £8,000/month for 60 hours of senior + mid time at flexible role mix). Margin is determined by how well actual hours tracked the budget. Margin variance for support is dominated by hour creep — the team spent 75 hours on a 60-hour budget — and role creep (the bug needed senior attention, not mid).

Risk profile: lower variance than development. A well-run support retainer lands at 30–40% margin month-to-month. A poorly-run one lands at 5–20%, but rarely goes negative because the monthly fee provides a floor.

Internal work

The work the agency has to deliver to function but that doesn't bill to a client. Sales meetings. Pitch development. Internal training. Account management between projects. Leadership and operations time. Engineering R&D and tooling investments.

Economics: not pricable to a client. Pure cost line. The agency funds it from the margin on Development and Support work.

Risk profile: invisible. Internal work that grows unchecked silently inflates the agency's effective overhead, compressing margin on every billable engagement. Internal work that's starved silently degrades the agency's ability to win the next engagement.

What goes wrong when they're mixed

Most agencies on Jira have a single Jira project per client (e.g., CLIENT for everything to do with one client account). Tickets in that Jira project mix Development work (the build), Support work (post-launch fixes and ongoing maintenance), and Internal work (account management, status calls, internal handoffs). Worklogs accumulate against tickets without distinction; margin is computed at the Jira-project level.

Three patterns of leak follow.

Pattern 1: support quietly subsidises development

When the build for a client wraps up, the post-launch support work starts arriving as new tickets in the same Jira project. The build is "done" from the team's perspective. From the financial reporting perspective, the build is still open — because there are still tickets being worked on against the project key.

The build's margin therefore continues to absorb the cost of the support hours. Six weeks of post-launch support, at three senior days a week, is roughly £15,000 of hidden cost in the build's margin column. The build that landed at 32% margin on day of go-live is a 24% margin engagement six weeks later — and the team has no idea, because nobody updated the build's margin number on the closing pack.

Meanwhile, no separate "support" margin report exists, because the work hasn't been segregated into a separate sub-project. The post-launch work is invisible as a category. It's just "things still being done for the client".

Pattern 2: development gets interrupted by support tickets

The same blurred boundary works in reverse during a long-running engagement. The team is mid-way through a build sprint when a urgent bug report arrives from the client. The bug is for the previous version of the same product — clearly support-shaped, not development-shaped. But the ticket lands in the same Jira project. The team picks it up because the client is in pain and the relationship matters.

The build's hours have just been consumed by support work. The build's margin has just been compressed. Nobody wrote a change request, nobody re-priced the engagement, and the team is now slightly behind on the build because three days went to support.

Repeat this five times during a six-week sprint and the build is two days late, the team is mildly stressed, and the margin is 8 percentage points lower than the estimate. The closing pack reports a "scope creep" issue. The actual issue is sub-project drift — the build was being interrupted by support work that should have been on a separate sub-project with its own budget.

Pattern 3: internal work disappears entirely

Internal work — account management between projects, sales pitches that didn't convert, internal tooling improvements — is rarely captured at all in agency time tracking. The hours go untracked because nobody is sure where to log them. The cost of the time disappears into the agency's overhead allocation, where it becomes invisible.

A senior account director who spends 30% of their week on prospect calls and pitch development — entirely uncosted — is effectively doubling the agency's overhead at no project's expense. The margin on Development and Support engagements looks healthier than it is, because they aren't carrying the cost of the account director's prospect time.

When the agency goes to do a quarterly margin review and discovers that the bottom line is worse than the project-level reports suggested, this is almost always one of the contributing factors. The internal work has been eating margin invisibly.

The structural fix: three sub-projects per client

The fix is to model each client account as one Jira project containing three explicit sub-projects, distinguished by the component field (or labels — both work; we use components):

• Development — fixed-scope, time-bounded build work. Each engagement is a separate epic; each milestone gets its own budget tag.
• Support — ongoing retainer-shaped work. The monthly budget for the support work lives as a known number; tickets accumulate against it.
• Internal — work the agency does for the client account but doesn't bill to a deliverable: account management, prospect development, internal status meetings.

Every ticket gets exactly one component. The component is set at ticket creation, usually by the project lead. Tickets without components fail validation and don't transition to "In Progress" (see the Jira configuration article for the workflow validation).

Once components are clean, the same Jira project — formerly a single blurred margin number — surfaces three independent margin reports in the layer that became Saldo. Each line carries its own pricing model, its own cost structure and its own variance attribution. The leaks described above stop being invisible because they have somewhere to live.

Once components are clean, three things become possible:

Development gets a clean margin

The Development sub-project's margin is computed against the build's role-rate estimate, with role drift and scope creep tracked separately. Once the build closes, the sub-project is closed too. Subsequent work goes into Support or a new Development sub-project (e.g., a Phase 2). The build's margin number is final on the day the build closes.

Support gets a budget vs spend

The Support sub-project tracks against a monthly budget. The retainer is £8,000 for 60 hours of senior+mid time; the report shows what was spent against it. Hour creep (over 60 hours) and role creep (more senior than the budget assumes) both surface as variances. The conversation with the client about repricing the retainer becomes quantitative.

Internal gets visibility

The Internal sub-project's hours are visible. The agency knows that 12% of the senior account director's time was spent on internal work for the client this quarter, costed at internal rates. The cost line for internal work either gets pushed into the agency's overhead allocation (which is the right answer for most internal work) or, where the work is specific to a client, gets billed back to the client through a relationship management line.

The aggregate effect: the build's margin gets cleaner (no more support absorption), the support retainer gets visible (and usually repriced upward by 10–20% in the first quarter), and the internal work gets named and managed.

What changes about pricing

Once the three sub-project types are separated, three pricing decisions become explicit that were previously implicit.

Development is priced by role-rate estimate

We've covered this in detail in the role-rate piece. The headline: the estimate lists which role does which hours at which rate; the project ships at the agreed price; variance is tracked against the estimate.

Support is priced by monthly retainer with a budget

The right pricing model for support is a flat monthly fee that covers a defined number of hours at a defined role mix. The contract specifies what's included (e.g., 40 hours/month, 70% mid + 30% senior, response within 4 hours during business). Anything above the budget is either out-of-scope (a change request, billed separately) or absorbed by the agency (with a re-pricing conversation if it happens twice).

The pricing decision the agency owes itself: what's the minimum support retainer that covers the cost of staffing the team to be available? Below this floor, the retainer is unprofitable structurally — the agency is committing to availability without the revenue to justify the staffing. We've seen agencies run support engagements at £3,000/month that cost £4,500/month to staff, for years, before the math became visible. Always.

Internal work is funded by the agency's gross margin

Internal work is not billed. It is funded by the gross margin from Development and Support. The agency's gross margin number — typical target 60–65% on labour — has to support the cost of internal work plus overheads plus profit. When internal work expands without being noticed, it eats into the gross margin and either compresses overhead (which means cutting non-billable hires the agency may need) or compresses profit (which means a worse year).

Visibility on internal work changes the conversation from "we're not sure where the bottom line went" to "internal work was 14% of total hours this quarter, here's what we did with it, here's the choice for next quarter".

What the first quarter on this model looks like

Three patterns we've seen at every agency that has installed the three-sub-project model:

• At least one support retainer needs to be repriced upward. The first time the support sub-project is reported separately, the agency discovers that one or two retainers are running at margin levels that aren't sustainable. The repricing conversation is uncomfortable but rarely loses the client. Most clients accept a 10–20% price increase on a clearly-stated retainer when shown the actuals.
• The development side gets healthier-looking. Once support is no longer mixed in, the build's margin numbers improve materially — usually by 5–10 percentage points on the average build, sometimes more if the support absorption was severe.
• Internal work surfaces as a discussion. Senior account managers' time on internal work, which had been disappearing into overhead, becomes a number the leadership team is making decisions about. Some of it is correctly internal (sales pitches, account development); some of it gets either reduced (excessive internal status meetings) or pushed into a billable line.

The combined effect on margin, in our experience: 4–8 percentage points of recovered margin in the first quarter, mostly from repricing under-priced support and removing the support drag from misreported builds.

Why this is more important than the tool you use to report it

We sometimes get asked whether installing the three-sub-project model requires Saldo or something similar. It doesn't. The model is independent of the financial layer. You can install it in Jira, report on it from a spreadsheet, and run a healthier agency tomorrow.

What Saldo (or any decent financial layer) does is automate the reporting once the structural change is in place. The structural change matters whether you have the tool or not. The tool just lets the structural change pay back faster.

If you want to see this running on your real Jira data — Development, Support and Internal sub-projects with separate margin reports, repricing conversations surfaced automatically, and overhead allocation working correctly — that's Saldo. The 15-minute demo runs against your real Jira; we don't ask for card details up front.

The shorter version: every agency has three project types. Reporting on them as one type is the structural error that hides most of the margin leaks. Separate the three; the rest is much easier.