Organizational Physics and Change Requirements

Many AI engagements begin with a team that is confident in its technical plan. The model architecture is sound, the data pipeline is feasible, and the engineers can point to clear performance targets. Yet a surprising number of these engagements stall or are abandoned before they reach real users. This article examines one reason that happens and introduces a simple test that can catch the problem before any money or months are committed.

The intuition behind the problem is natural. If a project is technically elegant and clearly useful to the people building it, it seems reasonable to assume the organization will embrace it. Teams often judge a proposal by how interesting the problem is to them, how much better the model could be, or how much the solution would improve their own workflow. What they rarely check is whether the problem sits near the top of the organization's own list of concerns. That check is the belief worth examining.

The reason the filter matters is organizational rather than technological. The source uses the term organizational physics for the idea that certain organizational changes follow underlying principles, much as physical systems follow laws. Getting an AI system into production is one such change, and it cannot happen by force of technical argument alone.

Production deployment needs four things: sustained leadership attention, legal and compliance agreement, IT access, and workforce acceptance. Each of these is costly for the people involved. Leaders must keep their attention on the effort for a long time. Compliance and IT teams must revise positions they have held for years. Workers must change habits. The source's central claim is that none of these changes happen for problems that are not high on leadership's list. A problem that leadership ranks low cannot generate enough sustained effort to overcome these frictions.

The question behind the filter is concrete. Ask what the company is trying to accomplish over the next four quarters, and look for the three to five items that lead the list. Then ask which of those items your project addresses. The filter is not satisfied by a project that touches a vaguely related goal. It needs a direct link to something leadership has ranked near the top.

The filter should be applied early. The check happens before the engagement starts, because the decision it drives is whether to start at all. The diagram below shows the decision itself. When the answer is yes, the project proceeds. When the answer is no, the engagement should not start, and the source describes two ways to handle that no branch.

The source describes the no branch in two ways. The polite version is to scope a smaller exploratory engagement that could open the door to a future project that is properly aligned. The honest version is to leave. In both cases the full engagement does not start on the proposal as written.

Problem misdefinition is the error of framing a problem misaligned with leadership's priorities. In RAND's August 2024 meta-analysis of sixty-five enterprise AI initiatives, problem misdefinition sat at the top of the list of AI failure root causes. The source also states that most cases of misdefinition trace back to a single error: building against something the leadership cares about less than the team building it understood.

The mismatch is often invisible from inside the team. The team's own understanding of the problem feels complete, so nothing signals that the leadership's list points somewhere else. The comparison below contrasts the lenses a team tends to use with the lens the filter asks for.