The Project Failures I Keep Seeing in Trades and Construction Businesses

Good intentions, capable people and the right technology still aren't enough to make a change stick.

I've spent a lot of time inside trades and construction businesses, fixing processes, putting in software and building systems around the way they work. The thing that stands out every time is how busy they are.

There's always another job starting, another customer waiting on something, another problem on site that someone has to sort out. The people running these businesses are juggling a huge amount, and a lot of their processes have grown out of pure necessity.

So when a business gets to the point of asking for help with its systems, there's usually a good reason. The processes are getting hard to manage. Information isn't reaching the right people. Admin is eating too much time. Or the business has simply outgrown what its systems can handle.

Whatever the reason, there's usually real enthusiasm for getting it fixed. But I've learned that a business can have the right technology, a capable consultant and a clear need, and still struggle to make the change stick.

A lot of these failures are surprisingly predictable, and most of them are avoidable. These are the ones I see most.

1. People don't understand why the change is happening

This is one of the biggest, and one of the easiest to underestimate.

When a business decides to change a process, there's usually a good reason. Management wants better reporting, clearer accountability, more accurate numbers or better productivity. It makes sense to the people who made the decision.

But somewhere between that decision and the person who has to do something differently, the reason gets lost. The worker hears there's a new process. They get instructions and a start date. Nobody actually explains why.

That causes problems on two levels.

People push back on changes they don't understand

People are much more willing to get behind something when they understand what it's for. That doesn't mean everyone has to agree with every management decision. But smart people will question things that don't make sense to them.

If someone has done their job well for years and you bring in a process that makes their day harder, they're going to wonder why. If the only answer is "management wants it", you haven't given them much. And if they can't see how it helps the business or the people using it, they'll push back.

Sometimes that's loud. People complain, question it, tell you the old way was better. Other times it's quiet. They keep doing it the old way, avoid the new process where they can, or do just enough to get through the day. None of that helps.

People can't make good calls without context

This is the part that often gets missed. When people know why a process exists, they make better decisions inside it, and that matters because no system can predict every real-world situation.

Say we're asking someone to record what they worked on during the day. If they know what that information gets used for, they've got something to go on when they hit an odd situation. If they don't, they might make a perfectly reasonable choice that quietly undermines the very numbers the business needs.

That's not the worker's fault. They've been asked to do the job without the context to do it well.

Explaining the why isn't just about getting people to accept the change. It's what lets them use the system properly.

What to do instead

Make sure the reason for the change gets all the way through the business, not just to management. Talk to operations. Talk to the people in the field. Explain the business problem in terms that relate to their work, and wherever you can, show them how the new system is meant to make things better.

A consultant has a big part to play here. When you're gathering requirements from different parts of the business, you should also be helping those people understand the bigger goal. You're not just asking people how they work. You're bringing them with you.

2. The business doesn't make enough time for the project

This is probably the most common one I see.

The business knows it needs help. It brings someone in. Everyone agrees that fixing the processes and systems is important. Then the day-to-day takes over. The owner's too busy to review decisions. The ops manager keeps getting dragged into urgent work. The people in the field who need to test the software aren't available. Progress gets harder and harder.

It's usually not a lack of commitment. Everyone wants it to work. They just haven't made room for it.

Bringing someone in doesn't take the business out of it

When you bring someone in to work on your processes, systems or technology, you're buying their experience. Someone who can work out what's really going on, design the fix, build it and help the business through the change.

What they can't do is magically know every detail of how your business runs. That knowledge lives in your people. The owner knows the commercial goals. Operations knows how work moves through the business. The field knows what it's actually like to do the work. A good result needs all three, and that takes time. Someone has to sit in the discussions, answer questions, make decisions, and, importantly, someone who'll actually use the system has to test it.

The false economy of leaving people out early

At some point the people who know how the work is done are going to have to look at the system. That's unavoidable. The only question is when.

You can bring them in early, while the design is still flexible and changes are cheap. Or you can wait until it's handed over and find out you've misunderstood something important. The second one is nearly always more expensive. Now the feature is built. People might already be trained on it. It might already be live across the business. And only then do you find out it doesn't work the way it needs to. You revisit decisions, rework the software, tell everyone what's changed and maybe retrain them, all because the right people weren't available early enough.

It's the classic false economy: dodge a small commitment now, pay a much bigger one later.

What to do instead

Treat the business's time as an essential part of the project. Make time for the owner or leadership when decisions are needed. Free up operations people to explain how things work and review designs. Set aside time for field users to test early versions before it goes wide.

That doesn't mean everyone in every meeting. Quite the opposite. A good consultant should be very deliberate about whose input is needed, when, and how much of their time it takes. But once those moments are set, the business has to protect them. It's the reason our engagements start with time inside the business before anything gets built.

If you can't make time to build it properly, you'll likely spend more time dealing with its problems later.

3. The project loses its rhythm

Good engagements have a rhythm: a steady pattern of conversations, reviews, decisions and feedback.

That doesn't mean lots of meetings. It means a reliable pattern of contact that suits how the business runs. Some businesses move fast and want frequent short conversations. Others work better with fewer, bigger reviews. There's no single right answer, but there does need to be a deliberate one.

Why rhythm matters

Without a steady rhythm, a project loses momentum. People forget what was agreed. Decisions stay open. Feedback is late. The project fades into the background while urgent work takes over, and weeks later everyone gets back together and tries to work out where things were left.

Or the opposite happens. The consultant keeps working, but the business hasn't been involved enough along the way. People are surprised by what's been built, they question decisions they didn't know had been made, and work that looked like it was on track suddenly needs revisiting.

Neither is much use.

Keep people involved without swamping them

Good rhythm means enough contact that the project stays connected to the business. That might be regular short catch-ups with the key people, set reviews of work in progress, clear points where decisions get made, or simple, consistent updates on what's done, what's next and what needs attention.

The details should suit the business. What matters is that people know when they'll be involved and what's expected of them.

There's a trust side to it too. A predictable rhythm tells people the project is being managed, their input counts and things are moving. That matters even more in a busy business where the project is competing with a dozen other priorities.

4. The business tries to change too much, too fast

This is related to rhythm, but it's a different problem. Rhythm is about communication. Pace is about how much change you're asking people to absorb.

Get the pace wrong and you can cause real damage, even when everything else is going well.

I see this a lot in trades and construction. These businesses have a strong get-it-done culture. There's a problem? Fix it. There's a better way? Do it. Most of the time that's a real strength. It becomes a problem when you're making big changes to how the business runs.

When relief turns into impatience

There's a pattern that shows up when a business brings in someone who actually knows what they're doing.

The owner has often been living with a pile of frustrating problems for a long time. They may have known for years that some processes needed fixing but never had the expertise or the time. Then someone turns up who can actually solve them, and there's relief. Finally we can fix this. And this. And that. And while we're at it, let's change these other five things too.

From the owner's side it makes complete sense. They've finally got someone who can deliver what's been needed for years, so why wouldn't they want as much done as possible? But there's a catch.

A business can only absorb so much change

I can design or build several improvements in quick succession. That doesn't mean the business can take them all on at the same speed.

Every change asks something of the people it affects. They need to understand it, maybe learn something new, change their habits and get comfortable with it. And all the while they've still got their normal jobs. The jobs don't stop, the customers don't go away, and the business doesn't suddenly have unlimited room for learning new systems.

Bring in too much too quickly and people get overloaded. Training doesn't have time to sink in. Mistakes go up. Confidence drops. Systems that would have worked if they'd been brought in more carefully start attracting frustration and pushback.

Ironically, trying to improve the business faster can end up slowing the whole thing down.

Managing the pace is part of the job

This is where experience really counts. It's not enough to deliver whatever the client asks for as fast as possible. Sometimes the job is to move quickly. Sometimes it's to slow down, pause, or go back and fix something that isn't working.

And sometimes it means a hard conversation, looking the owner in the eye and saying: "No, I don't think we should do that right now."

Not because it's a bad idea, and not because I can't deliver it, but because it isn't the right time for the business. We can talk about it, work out what it should look like, and put it on the plan. But maybe the last round of changes needs another month to settle first.

That's not always an easy conversation, especially with an owner who's keen, ready to go and happy to pay for the work. There's a natural pull to say yes. Part of being good at this is having the judgement, and the backbone, to say "not yet".

The goal is to change the business as fast as it can absorb it, not as fast as I can build it.

5. Treating pushback as a people problem instead of information

Another one shows up once a new system goes live. The software's in. Management is waiting for the improvements. But the people using it aren't happy. They're saying it doesn't work properly, they're annoyed by the new steps in their day, and some of them are openly against it.

It's tempting to call that resistance to change. The staff are difficult, they don't like technology, they'll get used to it. Sometimes people do need time and support to adjust. But I think it's a mistake to assume that's the whole story.

They might be telling you something important

Picture it. You've been on site all day. You're tired. You've got a report or timesheet to fill in before you can knock off, and the new software makes that a lot harder than it needs to be. You complain. Not because you want to undermine the owner or derail the project, but because someone's taken a slice of your limited time and made your job harder.

That frustration is worth understanding. It might point to a real design problem. It might mean the change wasn't explained properly, or the training wasn't enough, or we're simply asking too much of the person using it. Whatever the cause, it's information, and information is valuable.

Make room for honest feedback

On a good project we've already involved field users during the build. We've listened to their concerns, they've tested early versions, and by launch some of them are confident enough to help their workmates.

But what if that didn't happen, and the rollout is already under way with people fed up? The first job is to make it really easy for them to tell us what's wrong. Ask for feedback. Invite the complaints. Give people simple ways to show the problem, ideally a quick video on their phone of exactly what isn't working. Then take it seriously. Don't brush it off, don't get defensive, and don't assume that because a decision made sense in a management meeting it must be right on site.

Recovery needs visible action

Once you've got the information, you've got decisions to make. If the system is causing real disruption and you can safely roll it back, that might be the best move: back to a small pilot group, fix the fundamental problems, rebuild confidence, then try again.

If rolling back isn't practical, you need a deliberate recovery. Prioritise the problems, fix the worst ones fast, tell people what you're doing, and make the fixes visible to the people who raised them. A clear message saying several issues have been found and will be fixed tomorrow morning is worth far more than a string of silent changes through the day. People need to know what's changing and when, and they need to see their feedback getting results.

Over time that brings confidence back, and it can turn an unhappy group of users into people actively helping improve the system. (There's more on how I run that loop in what the Toyota Production System taught me about building business systems.)

The people using the software aren't in the way of the project. They're how it succeeds.

What ties them together

Look across these and there's a pattern. The failures usually aren't caused by a lack of expertise or good intentions. They come from underestimating the human side of changing a business.

People need context. They need time to take part, the right amount of communication, a pace they can handle, and to know they're being heard. Technology matters, of course. So do good process design, clear requirements and solid delivery. But they're only part of the job. A business system doesn't deliver anything just because it's technically finished. It delivers when the business can actually use it.

If a project of yours has stalled and you can't see why, the six questions I use to find what's missing are a good place to start.

What the job actually needs

I think whoever is leading these projects needs more than technical skill. They need to understand the different views across the business, and to tell when a problem is technical and when it's about the organisation or its culture. They need to set the right rhythm, protect time for the people whose input matters, and manage the pace of change rather than just saying yes to every new request.

And they need to be willing to push back on the client when something isn't in the business's interest. That last one matters most. The right person isn't necessarily the one who says yes to everything and delivers it fastest. Sometimes it's the one who can see the business isn't ready for the next step and has the confidence to say why.

The real measure isn't how fast something gets built. It's whether the business runs better for it, for good.

Building the right system is half of it. The other half is helping the business get ready, willing and able to use it.

If that's the kind of help you're after, the fit check takes a few minutes, or get in touch and we'll have a chat about where your business is at.