Turning Unclear Work Into a Workable Plan

Some projects begin with a detailed brief. Many useful projects do not. They begin with a recurring complaint, a pile of notes, an awkward handoff, or a sentence such as “we need a better way to do this.” That is enough to start a conversation, but it is not yet enough to estimate, design, or build responsibly.

The first job is not to make the request sound more polished. It is to turn uncertainty into a small set of decisions that people can inspect. A workable plan does not claim to eliminate every unknown. It identifies which unknowns matter now, which can wait, and what evidence will tell the team whether it is moving in the right direction.

Start with the situation, not the proposed solution

A request often arrives in the form of a solution: build a dashboard, replace a spreadsheet, automate a report, or create an app. Before accepting that solution, describe the situation that caused someone to ask for it.

Useful questions include:

• Who is trying to accomplish something?
• What are they doing today?
• Where does the work slow down, become unreliable, or require repeated explanation?
• What happens if nothing changes?
• What would become easier if the project worked?

This is not an argument against the original idea. It is a way to preserve options. A dashboard might be appropriate, but the underlying need could be a reliable weekly decision rather than a screen that is available all day. A spreadsheet replacement might be justified, but the immediate problem could be inconsistent definitions rather than the spreadsheet itself.

Write the situation in plain language. Avoid feature names and product categories for a moment. If the description makes sense to someone who has not attended the previous meetings, it is probably becoming useful.

Define the decision the work should support

Projects become clearer when they are connected to a decision or action. “Improve visibility” is difficult to verify. “Let the operations lead see which requests are waiting for an owner before the Monday planning meeting” is more concrete. It identifies a person, a moment, and a use.

There may be several decisions in the larger system. List them, then choose the first one worth supporting. That choice creates a boundary. It also helps distinguish necessary inputs from interesting data that does not affect the first delivery.

A good first boundary is narrow enough to finish and broad enough to matter. It should describe a complete slice of use, not merely a technical layer. “Set up the database” is a technical activity. “Record a request, assign an owner, and show unassigned requests” is a usable slice. The latter can still require a database, but it explains why the work exists.

Separate facts, assumptions, and open questions

Unclear projects often contain statements with different levels of certainty. Treating all of them as facts creates avoidable rework. Make three lists:

1. Facts: conditions that can be observed or confirmed now, such as the format of an existing export or the people authorized to approve a request.
2. Assumptions: beliefs being used for planning, such as how often a report will be needed or whether a current identifier is unique.
3. Open questions: missing decisions or information that could materially change the approach.

The distinction matters more than the document format. A short table in a shared note is often enough. Give each important assumption an owner or a way to test it. If an assumption cannot be checked before work begins, state what the team will do if it proves false.

Not every question must be answered immediately. Prioritize the questions that affect scope, safety, cost, or reversibility. The color of a future settings screen can wait. Whether the system will contain sensitive personal data cannot.

Make constraints visible

Constraints are part of the design, not administrative details. Time, budget, available skills, existing systems, accessibility needs, security requirements, maintenance capacity, and approval processes all shape a workable solution.

Record constraints early and describe their practical effect. “Must use the existing identity provider” is more useful than a general note about integration. “A nontechnical staff member must be able to update the categories without a deployment” directly affects where configuration belongs.

Some constraints are preferences in disguise. That is fine, but label them honestly. A required condition should not compete silently with a nice-to-have convention. When tradeoffs appear, the team can then protect the true requirements first.

Describe the first useful delivery

The first delivery should have a clear user, a clear capability, and a clear way to review it. Describe it with examples rather than a long inventory of components.

For example:

A coordinator can enter a request with a due date and owner. The planning view shows overdue and unassigned requests. Existing requests can be imported from the agreed template. The first review uses representative, non-sensitive sample data.

That statement does useful work. It names core behavior, a migration boundary, and a safe review method. It also leaves room for technical choices until those choices are needed.

Alongside the delivery description, write what is out of scope. Exclusions protect focus and reduce accidental expectations. They are not promises that an idea will never be built. They explain what the current estimate and schedule do not include.

Plan the next learning step

A plan is stronger when it includes a learning loop. Decide what will be shown, who will review it, and what question the review should answer. “Get feedback” is too broad. “Confirm that the three status groups match how coordinators prepare the weekly meeting” gives reviewers something specific to evaluate.

Choose the cheapest responsible artifact for that question. It might be a sketch, a sample report, a clickable prototype, a small data transformation, or a thin working slice. The artifact should reduce a meaningful uncertainty. It does not need to resemble the final system in every respect.

End the planning step with a short decision record: the situation, the first supported action, the known constraints, the selected scope, the major assumptions, and the next review. This record can be revised. Its value is that the team can point to the same current understanding.

Clarity is not a prerequisite that someone must bring to the project. Creating clarity is part of the work. A good plan makes uncertainty visible, converts the most important parts into decisions, and defines a first delivery that can teach the team something real.