How do I plan a fallback when a critical project input may not arrive?
Quick answer
List the decisions and tasks that depend on the missing input, then separate work that can continue from work that must wait. Agree on a trigger, such as a date or a confirmed delay, for reviewing a fallback. Choose a limited option that preserves useful progress, label any assumptions, and identify who must approve it before it becomes final. Record how you will switch back when the expected input arrives.
The question, the details, the next step.
A project depends on an input that may arrive late. How do I make a fallback plan without guessing what the missing information will say?
Plan around the uncertainty, not around an imagined answer. First write down exactly what is expected, who is expected to provide it, and when you need it. Then list the specific decisions or tasks that cannot be completed responsibly without it. This shows where the risk actually affects the project.
Separate the work into three groups: work that can proceed now, work that can proceed only with a clearly marked assumption, and work that must wait. A fallback should protect useful progress while keeping unconfirmed assumptions from quietly becoming final decisions. Note who has authority to approve any temporary substitute.
How do I choose a useful trigger? I don't want to switch plans too early, but waiting indefinitely is not workable.
Choose a trigger that is observable and tied to the work: for example, “If the input is not received by [date and time], review the fallback with [decision owner].” If a date is not appropriate, use a clear event, such as confirmation from the provider that delivery has slipped. Avoid a vague trigger like “if it seems late.”
Also set a review point, not just a switch point. At that point, check whether the input has arrived, whether the deadline has changed, and whether the fallback is still suitable. The trigger prompts a decision; it does not automatically approve a substitute. If approval is needed, name who will make that call and what work remains paused until then.
Can you show how this works for a project waiting on a partner's draft? I need something I can share with the team.
Assuming the partner draft is needed to finalize a project summary, a limited fallback might be to prepare the summary structure and fill in only information already confirmed by the team. Do not fill gaps with invented partner content; mark those sections as pending. This example is a planning illustration, not a claim about your project or a recommendation to publish the draft.
Copy and adapt this worksheet:
Expected input: [partner draft], from [owner], due [date/time]. Work that depends on it: [claims or sections that need review]. Work that can continue: [outline, confirmed material, formatting, or other independent tasks]. Work to hold: [decisions or statements that require the draft]. Trigger: If [observable condition] by [date/time], review the fallback. Fallback option: Prepare [limited work] using [confirmed material only]; mark [unknowns] as pending. Approval: [person or role] decides whether the temporary version may be used for [specific purpose]. Return plan: When the input arrives, compare it with the marked gaps, update affected sections, and seek the required review before treating the result as final. Next check-in: [date/time] with [participants].
Keep the fallback narrow enough that the team can tell what it does—and does not—authorize.
What should I communicate so nobody mistakes the fallback for the final plan?
Put the status in the document and in the message that shares it: “Working fallback—not final. Prepared using [confirmed inputs]. [Sections] remain pending [expected input]. Do not use for [decision or external purpose] until [approval]. Next review: [date/time].” Adjust the restriction to match the actual decision and approval process.
Give the team one clear place to record changes and questions. When the input arrives—or the expected input changes—revisit the dependency list and tell affected people what changed. If the deadline or scope has moved, update the trigger and fallback rather than letting an outdated plan circulate.
A practical checklist
Name the missing input, its owner, and the expected date or event.
List the decisions and tasks that depend on it; separate blocked work from work that can continue.
Set an observable trigger and a review point, and name the decision owner.
Describe a limited fallback using confirmed information; mark assumptions and unresolved sections.
State what the fallback may be used for, what remains paused, and who must approve it.
Record how the team will update the work when the expected input arrives or changes.
A few more useful answers
What if no alternative can preserve meaningful progress?
Record what is blocked, what decision or input would unblock it, and when the situation will be reviewed. A fallback can be to pause the dependent work and continue only independent tasks; it does not have to invent a substitute.
Should a fallback use assumptions?
Only if the relevant decision owner agrees that assumption-based work is appropriate. Label each assumption, limit what the draft can be used for, and keep approval-dependent decisions open.
What if the expected input arrives after the fallback starts?
Compare the new input with the pending sections and assumptions, update the affected work, and obtain any required review. Tell the team which version or sections have changed.