The RPG Mistake That Quietly Breaks Your Certinia PSA Reporting

Every Certinia PSA implementation reaches the same decision in its first week: how to structure Region, Practice, and Group. It feels administrative — like naming folders before you start filling them. So teams give it fifteen minutes, sketch something that looks like their org chart, and move on to the parts that feel like "real" configuration.

That fifteen minutes is one of the most consequential design decisions in the entire build. RPG is the spine of every number the platform will ever report: utilization, backlog, actuals, margin, forecast. And the mistake rarely announces itself during implementation. It surfaces months later, when a services leader asks a reporting question the structure simply can't answer — and the only fix is to restructure a hierarchy that now has live financial data hanging off it.

Here's the misconception at the root of it, and how to design RPG so you never have that conversation.

The tree that isn't a tree

Most teams picture RPG as one nested hierarchy: a Region contains Practices, and Practices contain Groups. It's the intuitive reading. It's also wrong, and it quietly sabotages everything downstream.

In PSA, Region, Practice, and Group are three independent hierarchies. Each has its own parent/child structure, and every transactional object — resource, project, opportunity, assignment — is tagged on all three axes at the same time. That independence isn't an accident or a limitation; it's the whole point. It's what gives you matrix reporting: the ability to slice the same data by geography, by service line, and by team, in any combination.

The useful mental model isn't three levels of one folder. It's three tags on every timecard. A single consultant might carry Region = UK, Practice = Data & Analytics, Group = Delivery Pod 3 — three orthogonal facts, each rolling up its own separate hierarchy. Model RPG as one tree and you collapse those three lenses into one, throw away the matrix, and spend the rest of the engagement fighting the tool to get reports it was designed to give you for free.

Give each dimension exactly one job

Once you accept that these are three independent axes, the design question becomes: what question does each axis answer? The convention that holds up across implementations:

Region is geography tied to financial accountability — and, critically, to currency, tax, and billing entity. Anchor Region to the dimension along which money actually breaks. It's also the axis that carries expense policy: apply an expense limit or rate to a region, and it cascades to every resource in that region. If your expense rules differ by location, Region is where that lives.

Practice is the service line or delivery portfolio — usually the engagement-manager-owned view. This is your "utilization by competency" and "margin by service line" lens. If leadership thinks about the business as Advisory vs. Implementation vs. Managed Services, that's a Practice split.

Group is the most granular team, pod, or cost center — the finest-grained rollup you genuinely need to report on, and no finer.

The discipline that keeps this clean: before you add a single level to any dimension, name the specific report or billing behavior that requires it. Every node you create is a permanent tagging and maintenance obligation. Depth you can't justify with a real reporting need is depth you'll regret.

The rules the model quietly imposes

A few structural facts shape how you build, and it's worth knowing them before you start clicking:

One top-level per dimension. PSA allows exactly one headquarters Region, one global Practice, and one top-level Group — and you enforce that through the Hierarchy configuration group. Turn that enforcement on early, so nobody accidentally spins up a second root and fragments your rollups.

RPG comes first, full stop. Set up your Region, Practice, and Group hierarchies before you create any opportunities, projects, resources, permission controls, or assignments. Everything downstream tags against RPG, so it genuinely has to exist first.

Rollup is automatic and independent. The moment you tag an object with a region, practice, or group, its numbers — timecard entry, expense entry, utilization, backlog — roll up that entity's hierarchy. And they roll up all three hierarchies separately. After setup, validate that every leaf node lands where you expect on each of the three axes, not just one.

Know your override points — and set a policy. RPG defaults from the resource's own record, but it isn't locked there. You can override the RPG that timecard revenue, timecard cost, and expenses roll up to at the assignment level. This is genuinely useful: a US-based consultant staffed on a UK engagement can have their revenue book to the UK region where it belongs. But used inconsistently, it becomes the source of every "the numbers don't reconcile" investigation. Decide up front whether RPG is driven by who the resource is or what they're working on — then apply that rule uniformly across the org.

Where architects get caught: RPG vs. the project hierarchy

This is the trap that catches even experienced implementers. The RPG hierarchy and the project hierarchy are two separate rollup structures, and they don't behave the same way.

The project hierarchy lets you nest child projects under a master project — and unlike RPG, it allows multiple top-level master projects. Now here's the part people miss: you can run a single global program as a US master project with child projects in the UK, Germany, and Japan, and each child project's business records book to their own region's actuals and roll up their own RPG hierarchy — not the master's US region. Data rolls up the project tree and, entirely separately, up the RPG trees. Each child can even bill in its own currency.

That's a powerful pattern for global delivery — consolidated program-level visibility while each region keeps clean, correctly-denominated financials. But it only works if you design the two hierarchies deliberately and in tandem. Assume the project tree and the RPG tree move together and you'll be debugging misplaced actuals for weeks.

The settings that don't bite until you're at scale

Three operational choices that feel minor in a sandbox and matter enormously in production:

Actuals processing mode. PSA can process actuals in Immediate or Scheduled mode. Immediate feels great in a demo — everything updates in real time. At real transaction volume, Scheduled mode is far more scalable and fault-tolerant, and it's the right default for any org with meaningful throughput. Choose it consciously; don't inherit the default and discover the problem under load.

Cost visibility. Cost data lives on many objects — the resource, the assignment, the timecard, the transaction. Securing it isn't a single switch; it's a deliberate permission-set and field-level-security exercise, and you have to validate your reports too, because a cost field can leak through a report even when it's hidden on the record. RPG makes this sharper, because regional and practice leads usually should see their own costs but not each other's.

The plan fields are a trap for logic. Region, Practice, and Group Plan records exist, but their fields aren't validated and aren't used in any formulae — they're for lightweight planning only. Don't build reporting or automation that assumes they feed calculations. They don't.

The most expensive mistake of all: reorganizing later

If you take one thing from this: decide the structure deliberately up front, and start flatter than feels necessary.

Because actuals attach to RPG at the moment each transaction is processed, restructuring the hierarchy after go-live means all your history was computed against the old shape. And the trap here is completely predictable — I've watched it play out repeatedly. An organization gets PSA live, sees the depth of insight it's suddenly getting, and immediately wants to re-slice the data a different way. Now they're restructuring against a live system full of financial actuals, and every historical rollup is in question.

The move is to start with the minimum viable hierarchy — one top-level in each of Region, Practice, and Group — validate the matrix reporting against the actual questions your leadership will ask, and only add depth once a genuine reporting need forces your hand. Flat is cheap to extend. Deep-and-wrong is expensive to unwind.

The bottom line

RPG isn't folder-naming, and it isn't a five-minute setup task. It's the reporting architecture your services organization will live inside for years. Get the three-independent-hierarchies model right, give each dimension exactly one job, respect the way it interacts with the project hierarchy, and resist the urge to over-engineer on day one.

The teams that treat RPG as a quick administrative step pay for it every single quarter afterward. The teams that treat it as the architectural decision it actually is barely think about it again.