Why CAFM implementations fail on time, not software.

There is a version of this story that plays out in maintenance companies and managing agents across the country, and it goes the same way almost every time.

A company decides its current setup has run out of road. Spreadsheets, a shared inbox, a whiteboard, or an older system nobody enjoys using. Procurement runs properly. Three vendors are seen, demos are watched, a decision is made. The system that gets picked is usually a reasonable choice. Sometimes it is genuinely a very good one.

Then the implementation starts, and this is where it goes wrong.

The pattern

The implementation partner loads the asset register from whatever spreadsheet existed. Planned maintenance schedules go in, taken from a standard library rather than from how the buildings are actually staffed and used. There is training, usually a day, sometimes two.

Six months later the planner is still keeping her own tracker in Excel, because the system's schedule never matched reality and she cannot risk missing something statutory. The monthly client pack is still being assembled by hand. Engineers are still filling in paper job sheets and someone in the office is still typing them up.

The system has quietly become a work order logger. It records what happened after the fact. It does not run anything.

The licences renew, because nobody wants to be the person who says the rollout did not finish.

What actually caused it

It is tempting to blame the software, and sometimes the software deserves it. But talk to people who have spent decades putting these systems into businesses and the same answer comes back.

Nobody had the time.

Every implementation needs a champion inside the business. Someone who knows the estate, knows the people, and can make decisions about how the data should be structured. That person almost always already has a full job. The implementation gets added to it, not instead of it.

So the data build happens in evenings and weekends. It happens in the gaps between real work. And because it is never anybody's actual priority, it never quite gets finished. The locations are half built. The asset register covers the plant somebody happened to have a spreadsheet for. The PPM schedules are the vendor's defaults because nobody had a spare day to review them properly.

Everything downstream inherits that. Reports are wrong because the location structure is wrong. Compliance tracking has holes because the asset register does. The planner keeps her Excel tracker because she cannot trust what the system tells her.

None of that is a software problem. Every one of those systems would have worked if the foundations had been built properly. The foundations were not built properly because there were no hours in which to build them.

The other half of the problem

There is a second failure that compounds the first, and it happens on site rather than in the office.

If completing a job on a phone takes too long, engineers will not do it. They will finish the job, write something on paper, and hand it in at the end of the week. Somebody in the office then types it up, days later, from memory and handwriting.

That is where data quality goes. Not in the import, not in the setup, but in the daily friction of a form with eighteen mandatory fields being filled in by someone standing in a plant room with one bar of signal and another four jobs to get to.

A system that takes ninety seconds to close a job gets used. A system that takes six minutes gets worked around. And a system that is worked around stops being a source of truth within about a month.

What to do differently

Build your locations manually, up front.

Everything hangs off the location structure. Assets sit in locations. Jobs happen at locations. Reports group by location. Compliance is tracked by location. If that structure is wrong or incomplete, every single thing built on top of it is wrong too.

This is worth doing by hand rather than importing, because the act of building it forces the decisions that matter. How deep does this go? Is a floor a location or an attribute? Where do external areas sit? Four to six levels is usually right. Fewer if you can manage it. More and people stop being able to find anything.

Let the asset register accumulate through the work.

This is the one that surprises people, because the instinct is to survey the whole estate before going live.

Do not. A full asset survey is a project somebody has to justify, fund and finish, and keeping it current afterwards is a habit nobody owns. Six months later it is out of date and nobody notices until an auditor does.

Instead, put in what you actually know. The statutory items, the plant with compliance obligations, the things that break. Then let everything else arrive through the work. Every job raised against something not yet in the register is an opportunity to add it, and an asset added because an engineer attended it is a far better record than one typed off a survey sheet by someone who has never seen it.

A register that grows this way is smaller at the start and more accurate forever.

Get a usable record, not a perfect one.

Seven fields make an asset usable:

• Asset code
• Description
• Location
• Category
• Make
• Model
• Serial number

That is enough to find it, schedule it, report on it and order parts for it. Twenty-two custom fields make it a data entry exercise nobody completes.

Match schedules to how the building is actually run.

A standard library schedule is a starting point, not an answer. If it says monthly and the building is staffed to do it quarterly, the system will show you a permanent sea of overdue tasks and people will stop looking at it.

Test the phone before you go live, not after.

Have an engineer close a real job on a real phone in a real plant room. Time it. If it is not quick, fix it before anyone is asked to rely on it.

The question worth asking

When you are being shown a CAFM system, the demo will tell you what it can do. Every system in this market can do a great deal, and the list of features will be long and largely similar.

The more useful question is a different one.

How much of my week does this need before it is useful?

Because that is the number that decides whether you are still using it in a year, or whether you have a licence renewal you cannot quite bring yourself to cancel and a planner who still keeps her own spreadsheet.

Where this leaves you

None of this argues that the software does not matter. It matters a great deal. But it matters in a specific way that most procurement processes do not test for: whether the system can be got running properly by people who already have full-time jobs, and whether it stays quick enough to use once it is.

If you are choosing a system now, ask the vendor how the first two weeks actually go. Ask who builds the locations, and when. Ask what happens to your asset register if you never do a survey. Ask how long it takes an engineer to close a job on a phone.

The answers to those four questions will tell you more about whether it will work than any feature list.