Development Feasibility Dependencies

LANDSHILOH · DEVELOPMENT LAND FEASIBILITY

A development feasibility dependency plan identifies which findings and decisions must precede other work. This page focuses on sequencing evidence and keeping responsibility for each decision clear.

Build a dependency-based feasibility plan

A feasibility plan should identify the evidence needed for each decision and the order in which to obtain it. Begin with a consistent concept and use the same version when requesting agency, provider and professional responses. Track later revisions so an encouraging response to a smaller project is not reused as support for a larger one.

Separate owner decisions, technical findings, provider commitments and agency approvals. Each has a different decision maker. Buying a report does not guarantee a favorable conclusion, and completing a study does not itself create an approval.

Put this subject into practice

Start with one project version and list the questions that could change its scale, layout or timing. Link dependent tasks and identify which can reasonably proceed in parallel. Ask each provider what inputs their work requires.

When a finding changes the concept, identify which earlier responses need updating. Maintain the original response and the new version rather than reusing a favorable answer for a materially different project.

Working record

Create a separate record for this subject so its findings are not mixed with unrelated approvals or investigations. Keep the actual source, review date and responsible person with each entry.

• Project version
• Decision or study
• Required preceding input
• Decision maker
• Impact of a changed concept

Illustrative example

A provider response covers an initial small concept. A later, larger proposal should trigger review of the affected dependency rather than inheriting the original response as proof of suitability.

Fictional example for explaining the process, not a listing, valuation or approval.

Does a pre-application meeting complete feasibility?

No. It can identify the process and questions. Title, access, site, infrastructure, market and financial investigations still need the evidence appropriate to the actual project.

Start with a dated project baseline

A dependency plan is useful only when everyone is considering the same proposal. Create a short baseline brief with the parcel identity, intended use, approximate project scope, known constraints, proposed phases and unanswered questions. Give the brief a date and version. Include the same brief when requesting related reviews, and identify assumptions that reviewers should challenge.

The baseline need not be a finished design. Its purpose is to prevent different people from answering different questions without realizing it. A preliminary response about a small initial phase should remain linked to that phase. If the proposal changes, record what changed before deciding whether the response remains relevant.

Build a development dependency register

For each task, ask the person performing it what information they actually need. Do not assume the order from a generic checklist. A reviewer may be able to begin a limited screening with incomplete information while reserving a later conclusion until more evidence is available. Document that limited scope.

Distinguish prerequisites from useful parallel work

A prerequisite is an input needed to undertake or interpret the next task. Parallel work can proceed without that input, provided its assumptions remain explicit. Marking everything sequential can waste time; treating everything as independent can produce costly revisions.

For example, organizing existing parcel records may proceed while introductory provider questions are being prepared. A detailed cost request that depends on a particular layout may need to wait until that layout is sufficiently defined. Ask providers which early tasks remain useful if the concept changes and which would need to be repeated.

Place the decision deadline beside the task sequence. Work backward from the decision that needs evidence, allowing for review and follow-up. Record estimated durations as planning assumptions, with their source and date. Do not present an unconfirmed schedule as a promise from an authority or provider.

Keep four kinds of decision separate

• Owner decisions: what the owner wants to pursue, spend or change.
• Professional findings: conclusions within the scope of a specific investigation.
• Provider responses: information or commitments about a defined service request.
• Agency decisions: determinations within the relevant authority’s process.

A favorable result in one category does not supply the result in another. Keep the decision maker, scope and supporting document with every status entry. “Report received” and “finding reviewed for this concept” are different milestones. So are “question submitted” and “response received.”

Trace the effect of a changed finding

When new evidence changes a project assumption, identify the affected tasks before commissioning more work. Record the original assumption, the new finding and the project version that will use it. Then ask the relevant reviewers which earlier outputs remain usable and which need revision.

1. Describe the change in one sentence.
2. Identify the input or assumption it replaces.
3. List every task that used that input.
4. Ask the responsible people to identify necessary updates.
5. Revise the schedule and cost assumptions.
6. Record the next owner decision and the evidence it needs.

Keep earlier records marked as superseded rather than silently overwriting them. This allows a later reviewer to understand why a scope or budget changed and prevents an outdated response from circulating as current support.

Worked example: a revised site layout

A fictional owner begins with Concept 1 and requests preliminary service information. Later site research leads the team to consider a different arrangement, Concept 2. The owner does not assume that the original service response covers the new arrangement.

The dependency register links the service question to the relevant concept. It marks the original response as received for Concept 1 and creates an action to ask whether Concept 2 changes the scope. Cost work that depends on the service arrangement remains provisional. Unaffected record organization continues while that question is answered.

The resulting decision note says which assumptions are current, what is awaiting confirmation and which expense or schedule entries could change. It does not label the entire project feasible merely because several individual tasks are complete.

Use a short review agenda

At each review, ask what changed, what is blocked, which response is overdue and which decision now has enough evidence to discuss. Review the tasks nearest the relevant decision deadline first. Assign a named person to each follow-up and record the expected output.

End the review with a current list of unresolved dependencies. Separate questions that could alter the basic concept from refinements that can wait. The purpose is to spend the next research effort on the question that most improves the decision, while preserving a clear record of uncertainty.

Is a completed dependency register proof of feasibility?

No. It records how evidence and decisions relate. The quality, scope and conclusions of the underlying work still matter.

What if a provider cannot give a firm duration?

Record the duration as unconfirmed, ask what affects it and plan a review point. Keep a range or alternative scheduling assumption visibly labeled rather than inventing a precise date.

General education from LandShiloh. Apply current records and appropriate professional review to the particular parcel, jurisdiction, proposal and transaction. This article does not supply an approval, legal opinion, financing commitment or property certification.

Discuss your land research question.