Hiring a Pigment consultant: what to look for

Most Pigment projects that disappoint do not fail on the software. They fail on design decisions made in the first few weeks: how versions work, where data lives, who can change what. A good consultant gets those right. This guide covers what to look for when you hire one, whether it is an independent modeller or a partner firm.

Start with the problem, not the platform

A strong consultant asks about your planning calendar before they talk about Pigment. Who plans what, when, and against which version? How does Budget differ from Forecast? What does the board pack need to show? If the first meeting is a product demo, you are being sold software, not a model.

Five questions worth asking

1. How will you handle versions and actuals? Listen for a Version dimension with its own switchover month for each version, and flags that decide month by month whether a number is actual or plan. A single hard-coded cut-off date will break the first time you run two cycles at once.
2. Where will each number live? Good answers separate shared master data, planning inputs and reporting. Reporting applications should not hold inputs.
3. How will we know the numbers are right? Expect control checks that should read zero: headcount that ties to HR, a balance sheet that balances, an ARR bridge that reconciles.
4. What will you hand over? Documentation, naming conventions and a walkthrough your team can follow without the consultant in the room.
5. Who will actually build it? With a firm, ask to meet the modeller, not only the partner who sells the work.

Skills that matter more than certifications

Certifications show someone has learned the platform. They do not show judgement. Ask for a walkthrough of a model they built, ideally with formulas and boards visible. Look for clear naming, metrics with only the dimensions they need, and logic you can follow. Ask how they keep calculations fast as data grows; sparsity and dimension choices matter more than clever formulas.

Warning signs

• Everything goes in one application because it is "simpler".
• No plan for testing against your current numbers before go-live.
• Estimates given before anyone has seen your data or planning process.
• Reluctance to document, or documentation promised "at the end".

Independent modeller or partner firm?

Partner firms bring scale and breadth for large, multi-workstream programmes. An independent modeller suits a focused build, a model that needs fixing, or extra senior capacity inside an existing team. Many projects use both: a partner leads, and an independent modeller takes a workstream.

If you want to see how I approach these decisions, the Titan demonstration walks through a three-application SaaS planning model, from version design to reconciliation checks.