The Software Won't Fix It
(And We Build Software)

There is a particular moment in a growing business where someone says, out loud, that what the company needs is a proper system. Everyone in the room agrees, because everyone is tired, and because it is true that the current arrangement is held together with a shared spreadsheet and one person's memory.

The next thing that usually happens is a demo, a contract, and a go-live date. What often does not happen is anyone asking whether the problem in the room is a software problem at all.

Why We Are Arguing Against a Sale

We should be straight about our position before making the argument. EncubIQ builds software. Attriqs is our own product: Attriqs Attribution and Attriqs CRM. They run together as one revenue platform, and the CRM also stands on its own. We would be pleased if you bought it. We also advise businesses on how to choose and implement systems like it, as part of a broader management consulting practice.

That is a conflict of interest, so treat this as interested advice and check it against your own situation. We are writing it anyway because the failure we see most often is not a business that chose the wrong tool. It is a business that bought a good tool a year before it was ready for one, and then concluded the tool was bad.

That outcome is worse for us than a delayed sale. A company that has been burned once tends not to try again for years.

The Number Everyone Quotes, and Why It Is Not Here

Any article on this subject is expected to open with a statistic about how most software projects fail. Seventy per cent is the usual figure. We went looking for where it comes from, and the honest answer is that it does not come from anywhere.

In 2011, Mark Hughes published a paper in the Journal of Change Management asking precisely this question. He reviewed the five published sources most often cited for the claim that seventy per cent of change initiatives fail, and concluded there is no valid, reliable empirical evidence behind the figure. Three of them simply assert it. The two that did rest on real surveys were measuring something narrower, such as whether executives felt their objectives had been met. The number circulates because it is repeated, not because anyone measured the thing it claims to describe.

The equivalent numbers for CRM and ERP projects are in similar shape. The most-quoted ones date from 2001 and 2002, describe software that was installed on servers in your building, and are frequently published by firms selling implementation services into the same decision. We are not going to lean on any of them.

What the peer-reviewed literature does agree on is the causes rather than the rate. Work by Sudhir Kale in 2004, and by Foss, Stone and Ekinci in 2008, arrives independently at much the same list: unclear objectives, absent planning, underestimating the difficulty of moving data, and treating the purchase as a technology decision when it is a decision about how the business will operate. Notice that not one of those is a fault in the software.

Software Amplifies a Process, It Does Not Repair One

This is the whole argument, and it is worth stating plainly. A system takes what your business already does and makes it faster, more consistent and more visible. It is an amplifier. Point an amplifier at a clear signal and you get a louder clear signal. Point it at noise and you get louder noise, at some expense, on a three-year contract.

There is an old observation from software engineering that captures why. In 1968, Melvin Conway noticed that organisations which design systems tend to produce designs that mirror their own communication structure. The shape of the thing you build ends up matching the shape of the people who built it. Applied to buying rather than building: the system you configure will encode the way your organisation currently makes decisions, including the parts nobody has agreed on.

We have written before about how the cost of undocumented process decisions accumulates on its own, long before any software is involved. This is the sequel to that problem. Software does not clear the debt. It writes it into a system, gives it a login screen, and charges you monthly to keep it running.

The Three Problems Software Genuinely Solves

An argument like this is only useful if it is honest about the other side, so here is the other side. There are three situations where buying software is straightforwardly the right call, and in each one the process is not broken. It has hit a ceiling.

Volume a manual method physically cannot carry

This is the cleanest case because the ceiling is real rather than a matter of opinion. A spreadsheet has hard limits, and Microsoft publishes them: a worksheet stops at 1,048,576 rows. Concurrency is a softer limit than it used to be, since a file kept in OneDrive or SharePoint supports real-time co-authoring, but a local or shared-drive copy, which is still what most small businesses are actually using, is not built for several people editing at once without risking one person's save quietly overwriting another's.

A fourteen-person home-services company tracking thirty jobs a week in a shared sheet is fine. The same company at three hundred jobs a week across four crews is not: two dispatchers double-book the same technician, and checking whether an address was already quoted takes longer than the quote. The process worked. It ran out of room. Software is the correct answer.

Proving later who did what, and when

Every business carries a recordkeeping obligation. The IRS sets out in Publication 583 how long a small business must retain records supporting income and expenses, generally three years and longer in specific cases, and holds electronic systems to the same standard as paper. Contracts and disputes add their own reasons.

A contractor facing a change-order dispute eighteen months after a job closed cannot easily prove which version the client signed if change orders lived as documents in a shared drive. In a system with a timestamped approval trail, that takes two minutes. No amount of discipline makes a folder of files produce a reliable audit trail, so this is a genuine software win.

Coordination between people who cannot be in one room

Coordination has a real cost. Ronald Coase's 1937 paper on why firms exist at all rests on the point that organising activity carries transaction costs, and that we build organisations to reduce them. Software that gives dispersed people a shared, current view of the same information reduces that cost directly.

A small distributor with a warehouse team, two field reps who are never in the office and a part-time remote bookkeeper spends a real part of every day answering "is this in stock" and "did that invoice go out" by phone. A shared system removes a coordination tax that existed no matter how good the underlying process was.

The Three It Never Has

A process nobody has agreed on

Software needs a decision to encode. Where there is not one, implementation does not produce one, it just gives the disagreement an interface.

Take a six-person sales team where each rep privately defines a qualified lead differently: one wants a confirmed budget, another is happy with a scheduled callback. Buy a CRM and one of two things happens. Either the pipeline stages quietly encode several definitions at once, or whoever configured the system wins by default and everyone else works around it. The software did not create that disagreement. It made it permanent and load-bearing.

A process people actively route around

When a formal process does not fit how the work really happens, people build an informal one beside it. This is well documented: Steven Alter's Theory of Workarounds, published in Communications of the Association for Information Systems in 2014, sets out why and how staff deviate from prescribed systems, and a substantial body of research on unsanctioned tool use reaches the same conclusion.

Suppose every purchase over five hundred dollars officially needs sign-off in a system, but everyone finds that too slow, so approvals really happen by text and get entered afterwards, when they get entered at all. Move that same rule into new software with stricter enforcement and you do not get compliance. You get a new workaround, because the reason people avoided the old one, that it was genuinely too slow for how urgent the purchases are, was never addressed.

An accountability gap

If nobody owns a step, adding software does not give it an owner. Two long-standing findings in psychology explain why. Darley and Latane showed in 1968 that people are markedly less likely to act when responsibility is spread across a group rather than resting on one person. Latane, Williams and Harkins showed in 1979 that individual effort measurably drops in group settings. A follow-up two years later, by Williams, Harkins and Latane, showed that the effect depends on how identifiable each person's contribution is.

A task in a system with no named owner behaves exactly like a task with no owner at all. The difference is that it is now visibly not done, with a timestamp attached. That is worth something, but it is a much smaller thing than fixing the process, and it should not be sold to you as the same thing.

Can You Fix the Process During Implementation?

This is the promise that carries most purchases over the line. The process is admittedly messy, and the plan is to tidy it up as part of the rollout. There are two very different versions of that promise, and they look identical in a proposal.

What usually happens

The accidental version rarely survives contact with the calendar, and the reason is structural rather than anyone's fault. An implementation window is scoped, budgeted and staffed to configure software against a decision. It is not scoped to make the decision. Where the decision does not exist yet, one of two things happens. The project stalls, and the timeline and budget go with it. Or the decision gets made in the moment, in a ninety-minute configuration session, by whoever is on the call.

That second outcome is the dangerous one, and it follows directly from Conway's observation above. The people present during configuration are usually the ones accountable for hitting the go-live date, not the ones with authority over how the process should work. Their incentive is to get the system live. So a question that deserved three weeks of argument between the people who actually own the outcome gets settled in four minutes, and is then considerably harder to unpick than it would have been on paper. That is Conway's observation with a go-live date attached.

What can happen, on purpose

There is a version of this that does work, and we have used it. A go-live date can be the forcing function that gets a messy process written down, argued over, and standardised, so the software has something clean to encode. That only works if you treat the process work as the project and the software as the deadline, not the other way around.

Budget time and authority for the argument. Name the owner before anyone opens the vendor's configuration screen. Run the test below before kickoff, write the exceptions down, and agree that configuration does not start until the lists match. If the only people in the room are the ones accountable for hitting the date, you will get a live system and an unresolved fight. If the owner is in the room with a mandate to settle the fight, implementation can be the cheapest process redesign you will ever run. It is how our operations practice runs implementations.

This is not an argument that implementation is a good time to fix a process. That line is how a great many bad scopes of work get sold. The honest position sits in the middle: it can be, but only if you design it that way and pay for it that way. The two-column scope document in the ninety-day list below is how you tell the two versions apart.

The Test

Here is the diagnostic, and it costs nothing to run.

Pick any two people who currently do the job. Separately, without conferring, ask each of them to write down the actual steps, in order. Then compare the two lists.

If the lists do not match, you have found the thing to fix, and it is not a software problem. Buying a system at that point simply funds both versions to run in parallel, more quickly and at greater expense.

Note that this is deliberately a writing exercise rather than a conversation. Almost anyone can narrate a tidy version of a process out loud, particularly to their own boss. Two written lists either match or they do not.

Three follow-up checks catch what the main test can miss.

• The exception test. Ask both people what happens on the case that is not the standard case: the rush order, the difficult client, the refund outside policy. A process that only exists for the easy eighty per cent is not defined yet, and software will handle that eighty per cent beautifully while making the rest somebody's permanent manual workaround.
• The consequence test. Ask what happens if someone skips a step. If the truthful answer is that nothing happens and nobody would notice, you are looking at the accountability gap above, and no amount of enforcement in software closes it.
• The paper test. Ask those two people to follow their own written version, on real work, on paper, for a fortnight. If they will not follow their own checklist without a system compelling them, buying the system buys you a workaround generator. People who do not follow a process on paper reliably find a way not to follow it on screen either. They just call it logging it later.

The Ninety Days Before You Buy Anything

None of this requires a project, a budget or a consultant. It requires about ninety days and some willingness to hear an inconvenient answer.

1. Run the two-list test on the three to five processes the software would touch, before you take a single demo.
2. Name one person, by name, who owns each process. Not a department, not the team. One person with the authority to settle the questions that will come up during configuration. If nobody can be named, you have your answer about readiness, and fixing it costs nothing.
3. Time the current manual version for one week. How long does it actually take to log a lead or process an order today, by hand. Without that baseline, the return-on-investment conversation afterwards is guesswork, and you will not be able to tell whether the software helped or simply moved the same hours somewhere less visible.
4. Pilot the new process on paper for two to four weeks. If people follow it, software will make something that already works faster, which is the good outcome. If they do not, you have learned that cheaply.
5. Ask the vendor's reference customers one specific question: what decisions did you have to make before you switched the system on, and who made them. Not whether they like the product.
6. Put one rule in writing before kickoff: no configuration decision that changes how the process works gets made without the named owner. This takes an email and is the cheapest protection available against the ninety-minute-session problem.
7. Ask for the scope document in two columns: process decisions still to be made, and software configuration tasks. If the proposal does not separate them, the sale is assuming your process is already settled.

If you get to the end of that and the lists match, people follow the process on paper, and you have simply run out of capacity, then buy the software. That is what it is for, and you will get the full value of it because there is a working process underneath for it to amplify. It is also worth reading up on what to trust and what to ignore when every vendor is selling AI agents, and on what poor data quality costs once a system is running, because those are the next two decisions.

FAQ

*Published by EncubIQ Consulting | Last Updated: September 2026*