This Week: Why Most Proclaim Builds Fail A Simple Audit

Most of this week was spent inside Proclaim builds that have grown organically for a decade. Nobody set out to create a mess. It happens because every urgent request gets bolted on to whatever was there before, and nobody owns the whole picture.

What we keep finding

• Duplicate case types that differ only by a handful of screens, each maintained separately.
• Screen logic doing work that should sit in a shared script, so a change has to be made in nine places.
• History entries and task types created ad hoc, which makes reporting close to worthless.
• No documentation, and the only person who understood the build has left.

Why it matters commercially

An unstructured build is not just an IT problem. It slows fee earners down on every file, it inflates the cost of every future change, and it makes accurate management information impossible. That is a margin issue, not a technology issue.

If a small workflow change takes three weeks to quote, the build is telling you something.

Three checks you can run yourself

• Count your live case types. If you have more than you have practice areas, ask why.
• Pick one recent change and trace everywhere it had to be applied. More than three places means duplication.
• Ask for a written description of one case type's workflow. If nobody can produce one, you have no documentation.

None of this requires a rebuild. It requires structure, documentation and a prioritised roadmap | which is usually where we start.