How we use Retain to run our own delivery teams

Most resource management advice sounds sensible until you try to run real delivery through it. At Retain, we run our resource management on the same platform our clients use. When something in the setup doesn’t hold up, it shows immediately in missed handovers, stretched teams, or plans that stop matching reality.

That’s forced us to be brutally practical about how we configure Retain and how we use it day-to-day. This piece shares what that looks like in practice, and the lessons that only show up once delivery pressure is real.

Key takeaways (read this first)

If you only take a minute from this piece, take this:

• Configuration decisions are key.
• Resource management breaks when demand isn’t aligned.
• Simple role models outperform complex skills frameworks.
• Visibility changes behaviour before it changes outcomes.
• AI works best once the groundwork is already done.

The delivery signal chain

At Retain, I like to think about resource management as a chain:

Pipeline → Project → Roles → People → Plan → Feedback

Each link passes context to the next. When one breaks down, the pain shows up somewhere else, usually in delivery, when it’s most expensive to fix.

You can see the problem here. If pipeline data is vague, project plans wobble. If roles are unclear, staffing turns reactive. And if feedback loops are weak, the same mistakes repeat.

We’ve taken several steps to strengthen each link internally. Here are our top lessons:

Lesson #1: Clarify demand early 

Most delivery problems start upstream, when demand enters the system half-formed and everyone assumes it will “sort itself out later.”

I find this hard to do, especially when sales momentum is strong. There’s always pressure to keep things flexible. But flexibility without structure just pushes complexity downstream.

At Retain, we’re deliberate about when work becomes “real” from a delivery perspective. Opportunities flow into Retain from our CRM automatically, but they only convert into live projects once they hit a meaningful confidence threshold. We bring opportunities into Retain at 50% probability to surface emerging demand early. They switch to Live at 100%, once sold. That separation between visibility and commitment keeps planning proactive without overcommitting capacity.

We stop guessing which opportunities might land and start planning around the ones that are likely to. Budgets, durations, and timelines arrive together, already connected. No duplication. No copy-paste gymnastics. No side spreadsheets lurking in the background.

This is key because otherwise you can end up scrambling. The same people get pulled in “just to hold the space”, and forecasts become optimistic placeholders.

By contrast, when you can see demand early, planning becomes calmer. Even if things change later (and they always do), we’re reacting from a position of complete visibility.

Lesson #2: Standardise role templates 

Once demand is clear, the next bottleneck usually appears when everyone starts reinventing the same project structure from scratch.

I’ve watched teams burn time debating who they might need instead of agreeing on who the work actually requires. It feels thoughtful in the moment. In practice, it slows everything down.

We’ve taken a bunch of steps to avoid that internally by leaning heavily on Retain’s role templates. These aren’t rigid job specs. They’re starting points that reflect the types of work we actually deliver.

Here are two examples.

A typical delivery project might automatically spin up:

• a project manager with relevant sector experience
• a professional services consultant familiar with the integration in question
• a technical specialist for more complex configuration work

Those roles appear as soon as the project is created, already tied to budget and duration, pulled through via CRM integration. That gives us an immediate view of demand without anyone having to “think it through” from a blank page.

Starting with a shared structure creates momentum, and refinement can happen once the fundamentals are in place.

Lesson #3: Keep skills frameworks usable 

Once roles are clear, attention naturally shifts to skills. This is where a lot of resource management setups collapse under their own weight.

I’ve been guilty of this. Given the chance, most teams build skills frameworks that try to capture everything. The result looks impressive. It’s also unusable in practice.

Similar to data, skills only help when people trust them. Internally, we made a deliberate call to keep our skills model tight. Around 10–20 meaningful categories. Enough to differentiate capability without forcing planners to wade through noise.

Skills are selected from the Retain Skills+ taxonomy, giving us a consistent and structured way to define capability across the business. That matters far more than theoretical completeness.

This is key because when frameworks get too detailed, people stop maintaining them, and resource managers fall back on gut feel. 

By keeping the model simple, we see the opposite effect. Planners use it. Teams trust it. Conversations stay focused on fit rather than taxonomy.

Lesson #4: AI works best once humans have done the hard thinking

AI helps the most when the basics are already in place. Before that, it just accelerates confusion.

We learned this the hard way. Until roles were clear, durations agreed, skills mapped, and availability visible, any kind of automation felt premature. You can’t shortcut the setup.

Then, and only then, are you ready to use AI in a meaningful way.

Because our roles are defined and our data is connected, Retain’s AI can suggest best-fit resources with context. It looks at skill match, availability, and budget constraints, then explains why a recommendation makes sense.

That explanation matters. When suggestions arrive without reasoning, trust evaporates fast.

Here’s my workaround: treat AI as a decision accelerator, not a decision maker. Resource managers stay in control. They review the shortlist, adjust based on nuance, and confirm assignments in a few clicks.

As a result, planning speeds up without becoming detached from reality. The AI handles the heavy lifting. Humans handle the judgment.

Lesson #5: Ensure forecasts reflect actual delivery

A clean plan on paper doesn’t mean much if it doesn’t survive contact with delivery.

Retain starts by spreading effort evenly across bookings. That’s useful as a baseline. It’s also rarely how work actually happens. Left untouched, those plans drift out of sync with reality fast.

So instead, we reshape them.

The next thing I’m thinking about once assignments are in place is cadence. Peaks, troughs, handovers, and the awkward weeks where everyone is “a bit” involved but no one is really focused.

Table View is where this gets practical. We adjust hours week by week in a simple tabular view, very similar to working in Excel, shaping forecasts around how the project will really run. It’s quick, visual, and immediately changes how the plan behaves.

You can see the problem here when teams skip this step. Forecasts look fine at a monthly level, but weekly pressure builds quietly. By the time it shows up, the only option left is firefighting.

By forcing ourselves to model the real rhythm early, delivery becomes easier to manage later. Not perfect. Just honest.

Lesson #6: Visibility changes behaviour 

Once plans are grounded in reality, visibility starts to matter in a different way.

Dashboards don’t magically fix delivery problems. What they do is remove plausible deniability. When project health, utilisation, and budget signals are visible in one place, conversations change quickly.

We track progress through milestones and timelines, shown as visual markers within the Retain plan against each project. Timesheet data is matched directly against planned bookings. That gives us a live view of actuals versus forecast, not a retrospective explanation weeks later.

That means earlier conversations. About scope. About pace. About whether something is genuinely ahead, quietly behind, or drifting toward trouble.

You can see the problem here when visibility arrives too late. Overspend looks sudden. Underspend gets misread as efficiency. In reality, both often signal misalignment.

Meanwhile, portfolio-level views give leadership a clear sense of where attention is needed, without turning every project update into a status meeting.

Lesson #7: Build trust to improve capacity planning

This is where everything we’ve talked about starts to compound.

Once demand is flowing in cleanly, roles are consistent, skills are trusted, and plans reflect reality, capacity planning stops feeling like guesswork. It becomes a strategic input.

We can see future demand alongside current commitments. Utilisation pressure shows up early. Skills gaps are visible before they turn into delivery risk. Decisions around hiring, upskilling, or contractor support become calmer and more deliberate.

Even when you’ve hit those markers, attention still matters. Capacity planning isn’t a one-off exercise. It’s an ongoing conversation between data and judgment.

What surprised me most was how much this changed internal behaviour. When people trust the picture they’re looking at, they stop working around it. Fewer side conversations. Fewer shadow spreadsheets. Better decisions made earlier.

The takeaway: capacity planning only works when people believe the signals underneath it.

What we learned the hard way

Some assumptions didn’t survive contact with real data.

We assumed certain roles would always be the constraint. They weren’t. We assumed some skills were scarce. They were just poorly surfaced. We assumed underspend was a good thing. In practice, it often flagged stalled work or unclear scope.

Those moments were uncomfortable. They were also useful. Clear visibility has a habit of removing comforting narratives.

Systems don’t replace judgment, they sharpen it. Once the noise drops, the real issues are harder to ignore.

Final thought: back to delivery fundamentals

Budgets are tighter. Clients expect predictability. Teams have less tolerance for chaos disguised as flexibility.

Running Retain on Retain has reinforced one thing for us: resource management only works when it’s grounded in delivery reality. Clean demand signals. Simple structures. Honest plans. Fast feedback.

This is just one way to configure the platform. It works for us because it reflects how we actually deliver work.

If you want to compare notes, pressure-test your own setup, or talk through alternative approaches, we’re always happy to have the conversation. You can book a demo here.