What’s best about beating your head against a brick wall is how good you feel when you stop.

As discussed here last week and the week before, businesses beat their heads against brick walls all the time, the walls being ideas they keep on trying, over and over again. They never feel good because they never stop, no matter how often the ideas don’t work.

We’ve already discussed a number of reasons this happens. There’s one more we haven’t talked about yet, and it’s a big one: More often than not, in the world of business, changing your mind about an idea isn’t safe.

I realize this revelation is less than shocking. Quite the opposite — it’s part of most managers’ day-to-day lives, an inevitable consequence of the we-have-to-hold-people-accountable philosophy that paralyzes an organization’s ability to make tough decisions.

Given that companies should want every manager and executive to cheerfully abandon ideas that aren’t working, it’s worth asking how they change the situation, so that putting a bullet in an idea that isn’t working out is a career-enhancing move rather than a career-limiting one.

It’s an easily stated goal, which is quite different from it being an easily achieved one.

The solution (or, at least, a solution) starts with the recognition that we’ve been asking the wrong question. What we ought to be asking is how businesses should go about exploring promising-sounding concepts. If we understand that, we’ll understand how they will go about terminating the ones that don’t pan out, as a standard and well-understood step in the practice.

But we’re getting ahead of ourselves — that’s the last step, not the first, which is:

Analysis: Of course. The starting point for any concept is to do enough analysis to be sure it’s worth pursuing. Volumes have been written on this topic. For our purposes, what matters most is making sure you have a list of the key assumptions on which the idea depends. Once you have the list, replace as many as possible with research. For the rest, figure out how you’ll test them to determine whether they’re valid or not.

And if you aren’t sure you’ve identified them all, conduct a “pre-mortem” analysis — an excellent way to explore this topic.

Pilot/Prototype/Proof of Concept: Analysis matters, so don’t allow the impatient to intimidate the rest of the organization with premature accusations of “analysis paralysis.” On the other hand, endless analysis is an easy trap to fall into. There comes a time when performing a few experiments makes more sense than continuing to theorize. That’s when pilot projects, prototypes, and proofs of concept come into play.

And you do want to do at least one, and probably several of these. What you don’t want to do is what organizations usually do, which is to conduct a “proof of concept” on the easiest test case they can identify, and, when it succeeds, decide the concept has been proven.

Remember that list of key assumptions? While it makes excellent sense for your first pilot to be built around the easiest test case you can identify, that doesn’t mean its success proves the concept. You need to iterate your test cases, making sure each successive one tests additional assumptions from your list, until you’ve either validated or modified all of them.

Review: It isn’t enough to look at the results of a test project to decide whether it’s succeeded or failed. Because in the end, what matters isn’t its success or failure — it’s what you’ve learned by conducting it.

Every test should have a completion date — their duration shouldn’t be indefinite. And when they’re done, everyone involved in the test should be involved in answering the question, “What do we now know about the subject that we didn’t know before?”

By the time the organization has finished and reviewed enough test projects to have tested all of the assumptions and assessed all of the results, everyone involved should be convinced … by the data … of whether the idea is sound, and of what competent execution looks like.

Which still doesn’t answer the question of what to do about ideas that are already institutionalized, even though they don’t seem to work.

The answer isn’t to finally figure out, once and for all, that it’s the idea and not the execution. If that was going to happen, it would have already happened.

Here’s what can happen: Someone (you, for example) can identify a competing idea, and test that. If it works better that what the business has been doing, the business can adopt it without worrying about why the older idea wasn’t working.

Or about who has to be held accountable for it.

Participating in team sports is supposed to teach children valuable lessons about life … for example, that losing isn’t the end of the world, only the end of the game. That opponents aren’t enemies is another one.

It appears the New Orleans Saints didn’t get the email. Its players established a bounty system (I’d say “allegedly” except that nobody seems to be denying that it happened), funding a pool that paid players to injure targeted opponents.

Call it managing for results. Defensive coordinator Gregg Williams administered the program. Coach Sean Payton and general manager Mickey Loomis knew of it and did nothing to stop it. Why would they? It helped win games.

Or, call it criminal behavior that won’t be prosecuted: While paying someone to deliberately injure someone else is inarguably a felony, the experts expect prosecutors to defer to the NFL’s jurisdiction.

Imagine you’re NFL commissioner Roger Goodell. It’s your jurisdiction. What’s your first question?

It’s “who did what?” Who, that is, is to blame for this mess. When, as a leader and manager, you learn your organization has engaged in criminal activities, or activities you’ve defined as unacceptable through a policy manual, values statement, or other equivalent vehicle, you need to know whodunit. And you need to deal with them appropriately to make sure they don’t engage your organization in illegal or unethical activities again.

For criminal or unethical behavior, assigning blame … accurately … is essential.

When something else goes wrong, though, your first question should be Goodell’s second question: What characteristic of our organization led to the bad thing happening?

Goodell has ascribed it to culture, but I wonder, because when you count the total value of winning playoff games … including endorsements … there’s serious money at stake.

Regardless, this, and not who’s to blame, should be your first question when something goes wrong because when those in leadership roles ask who’s at fault, they’re making both a logical error and a tactical mistake.

The tactical error: Establishing a game of Whac-A-Mole, where the smart employees keep their heads down, and those who don’t … those who poke their heads out to help fix the situation … end up receiving blows to their noggins.

The logical error is that they’re assuming the conclusion. There are plenty of ways something can go wrong. Those who ask whose fault it is blind themselves to other explanations while fostering a culture of blame.

Last week’s column pointed out the enormous costs of this culture … where the habit is to ask who’s at fault instead of what when wrong. To change it, as is the case with most other changes in culture, what’s needed is a change in leader behavior.

In this case, the solution is literally formulaic: Success = aI + bE + cL. As is usual, a, b, and c are weighting factors. I, E, and L stand for idea, execution, and luck. Success comes from an idea that can work, strong execution, and good luck (or avoiding bad luck) too.

To get rid of a culture of blame, start with the formula whenever something goes wrong. Make it everyone’s habit.

If the idea wasn’t sound, ask whether there was a reasonable way to have discovered this before investing in it. The answer isn’t always yes. Presumably, Apple applied the same evaluation process to both the iPad and Apple TV. Whatever might have prevented Apple TV probably would have stopped development of the iPad, too. Bad trade-off.

If the problem was in execution, there is a possibility that someone screwed up, and if so, that whoever it was didn’t just make a mistake but is a chronic screw-up. It’s possible.

It’s more likely the problem lies in the organization’s systems, processes, or culture. Improving these would pay big dividends.

Even if the source of the problem was a bad employee, termination won’t fix the root cause. Something about the organization’s management practices left a chronic screw-up in place, after all. Fixing this problem would pay even bigger dividends than fixing processes and systems, and that’s assuming the screw-up isn’t screwing up because of poor leadership rather than incompetence or character flaws.

Then there’s bad luck. If that’s what happened, you need better risk management.

It might be worse, though — it might be an even more insidious problem, even harder to fix than a culture of blame: That the whole plan depended on good luck.

Regrettably, we’ll have to wait until next week to handle that little topic.