Pigment implementation rescue.

A rescue recovers a Pigment project that has stalled, overrun, or gone live with a model finance doesn’t trust. We stabilize the model, find out why it went wrong without assigning blame, and fix the parts that matter most first, so planning can carry on while the model is repaired.

Usually the finance team already suspects it. These are the signs we hear most often:

• Boards that take long enough to load that people export to Excel instead
• Numbers finance can’t reconcile, so the old spreadsheets stay alive “just in case”
• A go-live date that keeps moving, or a budget that keeps growing
• Formulas nobody on the team can explain, and changes everyone is afraid to make
• An implementer who has moved on, leaving no documentation behind

In five steps, each with a clear output you can act on:

• Stabilize: agree a short change freeze so the model stops moving while we look at it
• Diagnose: a no-blame review of structure, calculations, data flows, access rights and Boards
• Plan: a prioritized recovery plan, separating quick fixes from redesigns
• Recover: we fix or rebuild the parts that matter most, in a Test & Deploy environment where possible
• Hand back: documentation and a walkthrough so your team, or your partner, can own the model again

Pigment’s own performance guidance names the usual causes: dimensions added “just in case”, structural redundancy that forces densification, stored zeros, single formulas that try to do everything, and calculations that compute first and filter later. Most are fixable without starting again.

Usually not. Often most of the model can stay, and the work is redesigning the few Blocks causing the trouble. If a rebuild is the cheaper path, the diagnosis will say so plainly and show why.

Then we work with them, not around them. A partner can bring us in to help recover a project, and we can work under their brand. We won’t take on a rescue in a way that breaks an existing partner relationship.