AI Project Scope Creep: A Parking-Lot Method to Keep Pilots Small

AI project scope creep is controlled by fixing the pilot's single success criterion in writing, then sending every new request to a parking lot instead of into the build. Each parked item is logged, sized by what it would change, and reviewed on a fixed date, so the answer to a good idea is "not yet, and here is when we decide." The pilot stays small enough to prove something, and the idea list stays alive.

Key takeaways

• Scope creep in AI pilots rarely arrives as one big demand. It arrives as small, reasonable requests that each add a data source, a tool, a channel or a group of users.
• A parking lot is one visible list with an owner, a fixed intake form and a scheduled review. It turns "no" into "not yet, and here is when."
• Triage by what a request would change (data, permissions, users, risk), not by how much someone wants it.
• Only two kinds of requests enter a running pilot: fixes to failures against the success criterion, and safety or compliance problems.
• Parked ideas are an asset. After the pilot, they become an evidence-based backlog for the next decision.

Why do AI pilots grow so easily?

An AI agent is easy to imagine in other places. Once a team sees an agent answer a question well, every nearby team recognizes its own version of the problem. Nobody is being unreasonable. The requests usually come from people who want the pilot to succeed.

The trouble is that each addition changes what must be tested. A new channel changes how people phrase questions. A new data source changes what the agent can get wrong and what it might reveal. A new tool means new permissions, and authorization guidance such as the OWASP Authorization Cheat Sheet is clear that access should be granted deliberately and limited to what the task needs. A new group of users changes what "good enough" means. When these arrive together, the pilot can no longer say what it proved, because several things changed at once.

Anthropic's guidance on building effective agents makes a related point: start with the simplest solution that works, and add complexity only when it clearly improves outcomes. A pilot is that discipline applied inside a company. Its job is to produce one clear answer, not to become a small copy of the final system. For the bigger picture of what each stage must show, see proof of concept, pilot or production.

What is the parking-lot method?

The parking lot is a deliberate place for requests to wait. It has four parts, and all four are needed.

• The fence: a one-page statement of the pilot's role, success criterion, named users, approved tools and approval boundaries. Every request is judged against it.
• The intake: one place and one short form, so requests do not arrive through hallway conversations, chat threads and email.
• The triage: a quick sort by what the request would change, done on a regular rhythm rather than in the moment.
• The review date: a calendar date when parked items are decided, ideally at the pilot's closing checkpoint.

The rule that makes it work is simple. No request is ignored, and no request enters the build without passing the gate. Ignoring requests damages trust. Accepting them quietly damages the pilot. The parking lot is the third option.

How do you set it up, step by step?

You can do this in one working session before a pilot starts, or in the middle of a pilot that has already begun to drift.

• Step one: write the fence. State the one role, the one success criterion, the named users, the tools and the approval boundaries on a single page. If the criterion is not yet observable, fix that first. The guide to success criteria for an AI agent pilot shows how.
• Step two: name an owner. One person keeps the list and runs the triage, usually the pilot lead, backed by the executive sponsor. The role is described in executive sponsor for an AI project.
• Step three: build the intake. Ask who is asking, what the problem is in one sentence, who would benefit, and what the request would touch: data, tools, permissions, users or channels.
• Step four: acknowledge quickly. Reply to every requester within a working day or two with the same message: received, logged, and here is the review date.
• Step five: triage on a rhythm. Weekly is usually enough. Sort each item into one of three groups: fits the fence, adjacent to the fence, or a different project.
• Step six: attach evidence. As the pilot produces results, link parked items to what was observed. A gap that keeps coming up from different people is a signal. A request from one loud voice is not.
• Step seven: decide at the review, and write down each decision and its reason, including the items you decline.

How do you say not yet without losing trust?

People accept a delay far better than silence or a vague "maybe." A good not-yet answer has four parts: it names the problem the person described, explains the delay in terms of the pilot's criterion, gives a date, and says who decides.

Not yet: your request is logged, and we decide on it at the review, once the pilot has shown its result.

A few habits sit behind that sentence.

• Say what the pilot is protecting. For example: we are testing one role against one measure, and adding this now would mean we could not tell which change caused which result.
• Do not argue against the idea. Often the idea is good. The reason to wait is sequence, not quality.
• Offer a manual workaround if one exists, so the requester is not left stuck.
• Show the list. When people can see their item next to the others, the process feels fair.
• Keep the review date. A parking lot with no review is a polite way of burying ideas, and people notice.

Requests from senior people follow the same path. They need it most, because a senior request is the hardest to decline and the easiest to accept without noticing the cost.

An illustrative scenario: four requests in one month

This is an illustrative scenario, not a client account. A distribution company pilots an agent that drafts replies to order-status questions for its customer service team. The success criterion: service staff send the drafts with only light edits, and a weekly sample review finds the drafts consistent with the order records.

Midway through, four requests arrive.

• The warehouse manager asks the agent to update delivery dates in the order system. This adds write access to a system of record. It is parked and flagged for a permission review.
• Finance asks the agent to answer invoice questions. This adds a data source and a new group of users. It is parked as adjacent.
• Sales asks for a customer messaging channel. This changes how questions arrive and who sees the agent's output. It is parked as adjacent.
• A service agent reports that drafts misstate the return window for one product line. This is a failure against the success criterion, so it goes in immediately as a change request.

At the review, the pilot has a clear result. The parked items now have evidence behind them: how often invoice questions actually reach the service team, which channel customers really use, and whether write access is justified. The company picks the next item and gives it its own role and criterion. Without the parking lot, the pilot would have carried four changes at once and proved very little.

When should a parked item move into the pilot?

Use these questions in order and stop at the first one that applies.

• Is it a safety, privacy or compliance problem? Handle it now, and consider pausing the affected part of the pilot.
• Is it a failure of the current role against the success criterion? Handle it now as a controlled change. The article on requesting and approving changes to a managed AI agent describes the path.
• Does it add a data source, tool, channel or write permission? Park it, and run a permission review before it is ever built.
• Does it add a new group of users? Park it until the pilot result is in.
• Would it change how success is measured? Park it, and treat it as a new pilot with its own criterion.
• Is it a refinement inside the fence, such as wording, tone or formatting? Batch it with other small changes at a scheduled point.

The order matters. Safety comes first because it cannot wait. Fixes come second because they protect the result the pilot exists to produce. Everything else changes what the pilot measures, which is exactly what the fence is there to prevent. If the pilot runs under a written agreement, the same logic belongs in it: a defined scope and a defined route for changes.

How does Be Human handle scope in a managed engagement?

A first engagement defines one useful role, the memory and tools it needs, the approval boundaries and an observable success criterion. That definition is the fence. During the pilot, new requests are logged in a shared list rather than built on request, and each one is described by what it would touch: data, tools, permissions and users. Fixes to failures against the criterion go through a controlled change process, and anything that adds access goes through permission review before it is built. Parked items are reviewed with the client at the agreed checkpoint, and those that proceed receive their own role definition and success criterion. Service is remote, in English and Portuguese, so the list and the review notes are written to be read asynchronously.

Frequently asked questions

Is a parking lot just a polite way of refusing? Not if it has an owner, a review date and written decisions. The point is sequencing: the pilot answers one question first, and parked items are decided with the evidence it produces. If the list is never reviewed, it does become a refusal, so protect the review date.

Who decides what leaves the parking lot? The executive sponsor or an agreed decision group, with the pilot lead presenting the triage. Requesters should not decide on their own items. Decisions should rest on the success criterion, observed results and the risk each item adds.

What if the sponsor asks for something mid-pilot? Run it through the same intake and state the trade-off plainly. If it is truly urgent, the sponsor can choose to change the pilot, but then the success criterion and timeline should be rewritten so the result remains interpretable.

How long should a parked item wait? Until the review at the end of the pilot or the next checkpoint agreed at the start. Items still wanted after the review should become their own small pilot with their own measure. Items nobody raises again can be closed with a short note.

Be Human editorial guidance. Examples are illustrative unless explicitly attributed. Sources provide background; implementation choices depend on your workflow.