Post Production Facility Software Problems: The 7 That Cost Real Money, and How to Avoid Them

Why does scoping this as a scheduling project keep going wrong?

Scheduling is what everybody sees, so scheduling is what gets scoped. The board is the artefact the whole facility looks at, its shortcomings are easy to list, and a demo of a nice resource calendar is satisfying in a way that a cost accrual model is not.

The problem is that scheduling is largely a solved problem. Farmerswife schedules cleanly. Xytech MediaPulse schedules and bills. Even a whiteboard schedules, badly but visibly. Rebuilding the board buys you a marginal improvement on something that mostly works, while the actual failure, which is that the schedule and the money live in different systems, goes untouched.

What that separation costs is diagnostic ability. When a job loses money, nobody can say whether it was labour overrun, a rate concession, unbilled overage or storage carried for five months, because the transactions were never joined to the job while the work was happening. You get the number without the cause, which means the same underpriced work gets quoted again next quarter.

The fix is a phase one scoped around the booking and the cost being the same object. A booking carries a resource, a rate, a job, a planned duration and an actual duration, and accrues cost and revenue as it happens. Then a producer can see on a Wednesday that a job is at 78 percent of its quoted value with 40 percent of the work outstanding, which is still a conversation. The identical figure on an invoice run is a post mortem. Get that right first and the schedule improvements come along with it rather than instead of it.

What goes wrong when you migrate jobs, rate cards and work in progress?

Three migrations bite, and the third is the one that damages the launch.

Rate cards are messier than anyone admits before they open them. The published card is the starting point, and the real pricing is the published card plus client specific concessions agreed by different people over several years, some documented in a contract, some in an email, some only in a producer's memory. Teams that plan to import the rate card import the fiction. Then the first invoices generated from the new system disagree with what the client expects, and the client is the one who tells you.

Job history migrates badly because old records were kept for billing rather than for analysis. Costs were captured at whatever granularity the accounting system needed, so historical margin by suite or by producer usually cannot be reconstructed no matter how the data is transformed. Facilities plan to launch with two years of comparative data and end up with a chart that starts on go live day.

Work in progress is the dangerous one. A facility that attempts a cutover with jobs in flight ends up with partial histories: half the bookings for a job in the old system, half in the new one, and no way to produce a coherent cost for either half.

The fix is to reconcile client specific rates as a business exercise before migration, owned by whoever runs commercial relationships, and to accept it will surface concessions nobody remembered granting. Migrate closed jobs as reporting reference rather than as repriceable records. And never cut over mid quarter with live jobs. In-flight jobs stay in the old system until they close, new jobs open in the new one, and you run parallel for two to three weeks with schedulers working in both and comparing.

Why do the storage, transfer and finance integrations break after launch?

These three are the ones that quietly stop working while everything on screen looks normal.

Storage integration breaks because storage platforms report at the volume or share level and jobs live at a folder or project level. The mapping between the two is maintained by an infrastructure team who reorganise things for good operational reasons and do not think of it as touching a finance system. One reorganisation and your cost attribution starts assigning a client's storage to the wrong job, or to no job at all, and because the total still adds up nobody notices for a quarter.

High speed transfer integration breaks on completion reporting. A transfer that was initiated is not a transfer that succeeded, and builds that record initiation as the billable event will bill for deliveries that failed and were repeated.

Finance integration breaks on authorship. If both systems can create an invoice, they will, and you will discover duplicate revenue during a reconciliation. If neither is clearly the author, credits and adjustments raised in the accounting package will never flow back, so job margin in your new system drifts steadily away from the ledger.

The fixes are decisions rather than code. Agree one authoring system for invoices before development starts and enforce it, with adjustments flowing back to the job. Reconcile total attributed storage against the platform's total on a schedule and alert on unattributed volume, because unattributed storage is the early warning that the mapping broke. And treat a transfer as billable only on confirmed completion.

What happens when collective agreement rules are not covered?

If your staff are covered by a collective agreement, overtime bands, turnaround violations and meal penalties are not payroll details, they are cost drivers that decide whether a long session was profitable.

The gap arrives in a specific way. Scope says the system will calculate labour cost from time captured, everyone agrees, and nobody asks which rules apply. What gets built applies a flat hourly rate with a simple overtime multiplier. It is wrong on any day with a turnaround violation or a missed meal break, which is precisely the days that overran, which is precisely the days you needed accurate cost for.

The failure is worse than leaving it manual, because people trust a number on a screen. A half implemented rule set produces confident job margins that are wrong in one direction on exactly the jobs where margin was tight, and a producer making a scheduling decision on that figure makes it badly.

There is a second version of this in freelancer engagement. Rates agreed per person per job, sometimes with minimum call durations and kit fees, get modelled as a single day rate, and the cost attributed to the job is wrong from the first booking.

The fix is to scope the rules you actually operate under, deliberately, with the payroll or human resources (HR) lead in discovery rather than consulted afterwards. Test the implementation against historical timesheets that include the awkward weeks, not a clean sample. And where a rule is genuinely too intricate to implement well, leave it out and flag the affected shifts for manual costing rather than approximating it, because an obviously incomplete number gets checked and a subtly wrong one does not.

Should you build custom or configure what you already own?

A single site facility with a small number of suites and a stable client base should not build. Farmerswife suits that shape well, it is affordable, and honestly the discipline of raising change orders the same day matters more than the tool you raise them in. A facility that cannot get its producers to raise variations will not be fixed by software.

If you are a large facility with a conventional operating model and you want a supported product with a vendor behind it, look seriously at Xytech MediaPulse before commissioning anything. It is a capable system that connects scheduling to billing properly, and building an equivalent is a substantial undertaking you should only start with a reason you can state in one sentence.

Before either, audit your own configuration. Facilities routinely run a capable system at a fraction of its capability because it was set up years ago by someone who has left, and the parallel document producers keep is often working around a configuration problem rather than a product limitation. Find out which it is before you fund a replacement.

The build case appears when two or more of these hold. You operate multiple sites and cross charging is currently a spreadsheet. Your rate structures or session conventions need configuration so heavy that maintaining the configuration is its own job. You cannot see live job margin and you know unbilled overage is material. Storage cost is growing and cannot be attributed to clients. Or you have already bought a facility system and your producers still run the real schedule in a parallel document, which is the clearest signal that the tool does not match how the work happens.

How do hidden costs get into the quote?

The screens are usually estimated fairly. These are the items that arrive later.

• Sites and cross charging. Each additional site brings local calendars, holidays, rates and an internal cross charge model. Multi site is a design decision, not a configuration setting, and retrofitting it costs more than including it.
• Storage and transfer integration. This is infrastructure work rather than screen work, it needs access to systems owned by another team, and it usually needs their time more than yours.
• Collective agreement rules. Genuinely intricate, and worth scoping honestly rather than assuming. Include testing against historical timesheets in the estimate.
• Client portal with media review. The moment review moves inside the portal you have added secure playback, watermarking and access control, which is a phase rather than a screen.
• Creative tooling integration. Pulling version state automatically from editorial and finishing tools is doable and is never as simple as the vendor documentation implies.
• The parallel period. Two to three weeks of schedulers working in two systems is real cost in their time, and it is the cheapest insurance in the project.

What separates a build that works from one that fails here?

Four things, and the first decides the rest.

Capture has to be frictionless at the point of work. A suite check in and check out that records actual time without anyone completing anything. When actual exceeds booked beyond a tolerance you set, the system drafts the variation itself with job, resource, time and a reason prompt, and places it in the producer's queue that evening. Ask any prospective developer how they would capture a session that overran, from the point of view of the person in the room. If the answer is a form, they have not thought about it, and the whole design problem is that one question.

The second is modelling resources as genuinely different things. A person has a calendar, a grade and overtime rules. A suite has a rate and a location. Equipment moves between sites. Storage accrues cost continuously with no calendar at all. A single resource table with a type column will fail on the third requirement and be patched from then on.

The third is a client portal that shows agreed scope, approved variations and current spend. It sounds like a convenience and it is actually behavioural: it removes the awkwardness that stops producers raising overage at all. A variation raised the same day is a normal conversation, and the same variation raised six weeks later is a dispute.

The fourth is ownership. You should own the repository, the cloud accounts and the right to bring in another firm, agreed in writing before kickoff. At Digital Heroes the client owns everything from the first commit. Your rate structures, job history and utilisation data are the analytical asset of a capital heavy business, and you should never need a supplier's permission to use them.