Who the Fuck Approved This?

A BUSINESS EXPENSE SHOULD HAVE A BUSINESS JUSTIFICATION BEFORE IT BECOMES SOMEONE ELSE'S PROBLEM.

Every business spends money.

Equipment. Software. Contractors. Consultants. Subscriptions. Supplies. Facilities. Professional services.

Some purchases keep the business operating. Some remove a constraint. Some create a capability the company genuinely needs.

And some happen because a person with authority saw something they liked and decided the company should have it.

Then the invoice becomes finance's problem.

The integration becomes IT's problem.

The workflow becomes the employees' problem.

And six months later, the person who approved the purchase wants to know why nobody made it work.

Let's go back to the beginning.

Who the fuck approved this—and what, exactly, did they approve?

Because permission to spend money and a sound reason to spend it are not the same thing.

The Demonstration Is Not Your Business.

Imagine a department wants a new software platform.

The vendor gives an impressive demonstration. The dashboard is clean. The automation looks useful. Management sees a version of the business where information moves neatly and everybody knows what to do.

A contract gets signed.

Then the software encounters the actual company.

Incomplete records. Conflicting definitions. Undocumented exceptions. Three departments entering the same information differently. A process that depends on someone named Susan remembering which customer gets handled another way.

The platform may work exactly as demonstrated.

That doesn't establish that the business is ready to use it—or that it solves the right problem.

Six months later, people are still maintaining the old spreadsheet.

Who made the mistake?

Maybe the vendor overstated what the product could do. Maybe implementation was mishandled. Maybe employees were not trained. Maybe the workflow was never tested. Maybe management bought a tool for a problem it hadn't bothered to define.

Find out.

“People resist change” is a possible explanation. It is not an investigation.

Start With the Problem You Are Paying to Change.

A purchasing decision should begin with the business requirement, not the product presentation.

Establish what users actually need, what the existing operation cannot accomplish, and which alternatives could address the problem.

That might mean purchasing new software, modifying a system the business already owns, improving the existing process, or deciding that the expected benefit does not justify the expense.

When possible, test the proposed solution against the company's actual workflow before making a larger commitment.

The vendor should demonstrate that the product can solve the business's problem.

The business should not have to reorganize its understanding of the problem around the vendor's demonstration.

You Didn't Just Approve the Invoice.

You approved something that may require other people to change how they work.

Who will migrate the information? Who will verify it? Who will build the integration? Who will train the users? Who will handle the exceptions after the consultant leaves?

What existing work will those people stop doing while they make this happen?

If no one answered those questions, the purchase has an implementation requirement without an implementation plan.

Then somebody gets handed the project and told to take ownership.

Ownership of what?

A deadline they didn't set? A product they didn't evaluate? A promise made by someone who never asked whether the necessary resources existed?

You can delegate implementation. You cannot make the original decision disappear by assigning the aftermath to someone else.

The approver does not need to personally inspect every technical detail. They need a reasonable basis for relying on the people who did, clear conditions for approval, and an owner with the resources to carry the work through.

A signature is not a substitute for any of that.

Your $200 Subscription Is Not Necessarily a $200 Decision.

Take a hypothetical platform advertised at $200 per month.

That is $2,400 per year.

Now suppose the proposed first year also includes these costs:

Separately, employees need twenty hours of training and setup. Administering the platform takes another two hours per month, or twenty-four hours during the year.

That is forty-four hours of internal work.

These are invented figures for a hypothetical analysis based on an understanding of how systems work. They are not vendor quotes or industry averages. Assume the cash items capture the additional payments for this example; a real estimate must include any other applicable charges, overlap, support, and commitments.

Now management says the platform will save ten hours of work per month.

Give that assumption a full twelve months after launch: 120 hours of gross time saved.

Subtract the twenty hours of initial internal work and twenty-four hours of continuing administration.

Seventy-six hours remain.

You are considering $7,200 in additional cash spending to release seventy-six net hours in the first year, before considering any other benefits.

That may be worth doing.

But it is a very different decision from “it's only two hundred bucks.”

Time Saved Is Not Automatically Money Saved.

There is an important financial distinction between reducing an expense and releasing capacity.

If employees complete their work faster but the business continues paying the same wages, the payroll expense has not automatically declined.

The company may have gained valuable capacity. It may be able to process more work, reduce delays, improve service, or avoid future hiring.

Those are potentially meaningful benefits.

But they are not the same as cash savings.

To claim a financial return, management needs to explain how the additional capacity changes expenses, revenue, or another economically meaningful outcome.

The first-year illustration assumes the business receives a full twelve months of benefit after launch. A real implementation delay would reduce that first-year benefit. One-time setup costs may support several years of useful work, while continuing fees, replacement, and exit costs can change the later years.

The Vendor Can Deliver Exactly What You Bought—and the Investment Can Still Fail.

A consultant delivers the report specified in the agreement.

An agency completes the contracted activities.

A piece of equipment performs to specification.

The company still receives little useful benefit.

Those facts can coexist.

The consultant may have been hired to diagnose, with implementation deliberately left to management. The equipment may require more suitable work than the business can supply. The agency may be producing material for an offer customers don't want.

Successful delivery and a successful investment are separate questions.

This is not an automatic defense of the vendor. Misleading claims, poor advice, defective work, or failure to deliver still deserve examination.

It means you need to establish what was promised, what was delivered, and what the business had to do to turn that delivery into value.

If management bought a report and assigned nobody to act on it, ask about that decision before announcing that consulting doesn't work.

If the vendor promised a usable integration and supplied something that doesn't function, investigate that too.

Follow the actual responsibility.

Don't select the easiest person to blame.

Buying the System Can Be Easier Than Leaving It.

A sensible purchasing evaluation should consider the entire useful life of the system.

That includes implementation, operation, maintenance, training, support, replacement, and eventual transition.

It also includes the cost of transferring information and knowledge when the company changes providers.

These obligations may not appear in the initial purchase price, but they can become substantial once the business depends on the system.

A purchase that appears inexpensive today can create expensive commitments tomorrow.

Not Every Expense Needs a Fucking Committee.

If somebody needs a basic, approved tool to complete a legitimate assignment, stop turning the purchase into an executive obstacle course.

Four people debating a minor expense can consume more value than the amount they're trying to protect.

That does not mean small purchases are always harmless. An inexpensive application with access to sensitive business information can create consequences far beyond its subscription price.

So the amount matters, but it isn't the only thing that matters.

Consider the risk, the duration of the commitment, how easily it can be reversed, and which other operations it affects.

Routine purchases within clear limits can have delegated authority. Cross-company systems, substantial contracts, or hard-to-reverse commitments need more deliberate review.

The person doing the work needs enough authority to do the work.

The person committing the company needs to understand what they are committing.

The GAO describes internal control as a management process for achieving objectives, including effective operations and reliable information. Its framework concerns federal agencies; the useful point here is that controls should help the organization function. [1]

A purchasing process that reliably prevents employees from doing their jobs has its own cost.

Some Benefits Are Supposed to Stay Invisible.

An unused emergency capability is not automatically a bad purchase.

A backup system may be valuable precisely because it is available when the primary system fails. A necessary protective measure doesn't become pointless because the event it addresses didn't happen this year.

So “nobody used it” is not sufficient on its own.

What was it purchased to do?

If it was supposed to be a daily workflow tool and nobody uses it, investigate. If it was bought for resilience, evaluate whether it provides appropriate, usable protection at a reasonable cost.

Not every expense needs an immediate sales return. Some protect operations, meet obligations, maintain necessary capability, or support a longer-term opportunity.

But the justification should exist before the disappointing usage report arrives.

You don't get to buy something for productivity, fail to deploy it, and suddenly declare that its real purpose was strategic optionality.

That isn't learning.

That's changing the explanation to avoid reviewing the decision.

A Bad Result Does Not Automatically Prove a Bad Decision.

You can evaluate reasonable alternatives, test important assumptions, identify risks, and still be wrong.

Conditions change. Suppliers fail. Customers behave differently. A bounded experiment can produce the useful answer that the larger investment should not proceed.

Accountability is not a requirement to predict the future perfectly.

Ask what was reasonably knowable at the time, what evidence supported the choice, what uncertainty was acknowledged, and how the company responded when new information arrived.

That is different from ignoring a known incompatibility, committing to an untested promise, or approving a project whose implementation owner has no capacity to deliver it.

A lucky result does not validate careless judgment either.

“We made money anyway” doesn't establish that the purchase caused the improvement or that the same decision should be repeated.

The review should make the next decision better.

If its only purpose is to find someone to punish, expect people to protect themselves instead of explaining what happened.

Decide How You Will Review It Before You Approve It.

The business should establish how the purchase will be evaluated before management approves it.

What operational condition is expected to improve?

What evidence would demonstrate that improvement?

When should the business reasonably expect to see results?

What would justify continuing, changing, expanding, or terminating the arrangement?

These questions should be answered before the company develops a financial or organizational incentive to defend the purchase simply because it has already been made.

“We've Already Spent the Money” Doesn't Justify the Next Check.

Money already spent and no longer recoverable is a sunk cost.

It does not become a financial benefit merely because the company continues spending.

The next decision should compare the costs and benefits that can still change.

That includes future payments, contractual obligations, operating expenses, switching costs, and the value of any useful capability the original investment has already created.

The relevant question is not how much money the company has spent defending the original decision.

It is which available choice makes the most economic sense from this point forward.

Follow the Decision.

Here is what would change my conclusion that the spending lacked a proper basis:

Show me a real need, reasonable alternatives, a credible estimate of the full commitment, an implementation owner with resources, and a way to assess the intended benefit.

Show me why delay or doing nothing would be worse.

If the purchase serves an important purpose despite low usage or no direct sales return, show me that purpose and whether it is being served.

If those facts support the expenditure, defend it.

If the evidence shows the original choice made sense but execution failed, address execution. If the vendor failed, address the vendor. If conditions changed, update the decision.

And if management approved something nobody could explain, own that too.

Approval records permission. Judgment has to justify the commitment.

Before signing the next contract, buying another platform, or approving another consultant, determine what the company expects to gain and what it will take to get there.

If the result turns out badly, don't automatically blame the person handed the purchase order—or the person handed the mess afterward.

Find out who made the decision, what they knew, what they committed the business to, and whether the decision made sense.

That's what approval authority is supposed to mean.

Continue Reading on anuhlest

• Everybody Is Responsible. Nobody Is Accountable. — why decision rights and outcome ownership cannot disappear between departments.
• The Gamble of Consultants — why purchasing expertise does not purchase a guaranteed outcome.
• Should I Hire a Marketing Agency, an Employee, a Consultant, or Build It In-House? — how to match an external or internal arrangement to the work the business actually needs.
• Your Business Made a Million Dollars. Where the Fuck Is It? — why reported activity and revenue do not answer the cash question.