Project Scoping Essentials

Imagine a data science team that has spent three weeks scoping an AI tool for document classification. The model performs well on sample files, the data is clean enough, and the engineers are confident the build is achievable. Yet the project stalls once it reaches the people who would have to approve and maintain it. Nobody argues that the idea is technically unsound. The trouble is that it does not sit near the top of the customer's agenda, and that single fact quietly decides its fate.

This article follows that stalled project through the decision points that matter during scoping. The central rule is simple: a proposed AI project should move past scoping only if the problem is among the customer's top five priorities. The rest of the article explains why that rule exists, how the forces inside an organization act on a project, and what a team should do when a proposal fails the test.

Think of scoping as a gate with a single question. A proposal enters the gate as an AI problem the team wants to build. The first and most important check asks whether that problem is among the customer's top five priorities. If the answer is yes, the proposal can move past scoping. If the answer is no, the source describes two honest paths the team can take, which are covered later in this article.

Trace the flowchart with the stalled project. The proposal enters the gate. The question about the top five is answered no, because the document classification problem sits low on the customer's agenda. The path therefore leaves the 'move past scoping' box and enters the stop branch. Notice that the gate never asks how accurate the model is, how much data exists, or how hard the engineering will be. Those facts can all be favorable and the proposal still fails at this gate.

The source frames the reason for stopping a misaligned project as organizational rather than technical. The point is not that the model would fail. The point is that a production AI system needs sustained attention from senior leadership over a period of months, and an organization will only supply that attention to problems it already values. A system can be well built and still be the wrong investment, because the surrounding organization has no reason to finish it.

Consider what happens to a project that sits outside the leadership's top five. Several separate groups each respond in a predictable way, and their responses compound. Leadership has no political capital to spend on the project, so it cannot push other departments to cooperate. The legal team, which must review the system, moves the review down its queue. The IT team applies its standard request process, which the source describes as a six-week cycle. Finally, the line workers who would use the system treat it as one more initiative to wait out instead of a change to adopt.

The friction does not come from one bad decision. Each group responds reasonably to its own priorities, and the combined effect is a project that cannot gather the sustained effort it needs. This is why a team cannot treat the customer's priority ranking as a formality. Ignoring alignment does not usually produce a dramatic failure at the start. It produces a slow buildup of delays that each seem reasonable on their own.

The source uses the term organizational physics for the built-in dynamics and constraints inside an organization that shape whether a project succeeds. The term is a way of naming forces that are always present, whether or not anyone writes them down. In the stalled project, those forces were leadership attention, legal review, IT processes, and frontline adoption. The source notes that each of these depends on priority.

Read the concept map from top to bottom. Organizational physics sits at the top because it describes the whole environment. The four middle nodes are the specific forces through which that environment acts on a project. Each of them feeds into project success. The map does not claim that the forces can be measured precisely. It shows that a team scoping an AI project has to reason about these forces, because they determine whether the project gets the attention and cooperation it needs.

When a proposal fails the top-five test, the source describes two honest paths. The first is the polite stop. The team scopes a smaller exploratory engagement instead of the full project. This keeps the relationship open and may lead to a properly aligned project later. The second is the honest stop. The team leaves the engagement rather than continuing with a project the organization will not sustain.

Read the comparison column by column. The polite stop has a path that continues the relationship: a smaller engagement, an open relationship, and a possible aligned project in the future. The honest stop has a single path that ends with the team leaving. The source does not say which option is required in every case. What it establishes is that both are legitimate responses to misalignment, and that the choice concerns how the relationship and future work should be handled.