How to Document Schedule Logic and Relationship Rationale
Create a practical record of why important schedule relationships exist, what evidence supports them, who owns the interface, and how the logic changed—without burying the schedule team in paperwork.
Schedule logic documentation explains the business, technical, contractual, or operational reason behind selected activity relationships. It gives reviewers enough context to understand why one event controls another, especially when the reason is not obvious from the activity names alone. Good documentation also identifies the evidence, owner, assumptions, and approval or change history needed to keep that logic credible.
This work is different from creating dependencies. A dependency-planning process decides which activity must precede or follow another and which relationship type represents the work. Logic documentation preserves the reasoning behind important or unusual ties so another qualified person can understand, validate, maintain, and—when conditions change—challenge them. It is also narrower than a general schedule health review, which examines many qualities beyond relationship rationale.
The objective is not to write an essay for every ordinary finish-to-start relationship. That would create administrative noise. The objective is selective traceability: document the relationships whose rationale, ownership, external basis, lag, exception, or consequence would otherwise be difficult to reconstruct.
A logic record should let a reviewer who did not build the schedule answer four questions without guessing: What does the predecessor provide? Why does the successor need it? What evidence supports that need? Who can confirm that the relationship is still valid?
Which relationships deserve a written rationale?
Documenting every tie at the same depth is rarely useful. Ordinary logic may be understandable from clear activity names and a standard workflow. Written rationale becomes valuable when the relationship contains judgment, crosses a boundary, uses an exception, or materially affects a commitment.
Discretionary sequencing
The team selected one sequence from several workable options. Record why this sequence was chosen, who agreed to it, and what condition could justify changing it.
External dependencies
The controlling event belongs to a customer, authority, supplier, utility, partner, or another project. Capture the commitment source, contact or owner, expected evidence, and monitoring method.
Unusual relationship types
Start-to-start, finish-to-finish, leads, lags, or other nonstandard techniques can be misunderstood. Record the physical or operational condition they are intended to represent.
High-consequence handoffs
A relationship protects a major delivery, safety boundary, shutdown, regulatory event, scarce resource, or customer commitment. Preserve the acceptance condition and accountable parties.
Cross-schedule interfaces
The predecessor and successor live in different files, systems, organizations, or levels of detail. Record the identifiers, synchronization rule, status source, and reconciliation owner.
Logic changed after approval
A relationship was added, removed, redirected, or reclassified. Record the reason, impact review, authorization, effective date, and reference to the applicable change record.
Self-explanatory standard flow
“Approve design” followed by “Release approved design” may be sufficiently clear when the activity names, owner fields, workflow, and standard finish-to-start relationship already communicate the rationale. Keep the schedule readable and avoid repeating what is obvious.
Logic that requires interpretation
If a reviewer could reasonably ask “Why must this wait?”, “Why can this start early?”, “What exactly is transferred?”, or “Who made this agreement?”, create a concise record before the knowledge disappears into email or memory.
Relationship Rationale Record Builder
Create a structured draft for one important relationship. The tool runs in your browser, sends no data, and uses your entries only to generate the visible record. Review the result with the responsible owners before placing it in controlled documentation.
Draft relationship record
What every documented relationship should contain
A useful record is compact enough to maintain and complete enough to survive staff turnover. The fields below form a practical minimum. Your contract, governance framework, or scheduling system may require more.
Stable identifiers
Record the predecessor and successor IDs plus concise names. Names can change; identifiers help preserve traceability. For cross-schedule logic, include the source schedule, project, supplier, or interface identifier so the relationship can be reconstructed.
Required input and enabled outcome
State what the predecessor makes available and what the successor is then allowed or able to do. This connects the relationship to real work rather than a software convention.
Rationale classification
Indicate whether the dependency is inherent, contractual, regulatory, discretionary, external, resource-based, or an acceptance condition. Classification helps reviewers apply the right challenge: mandatory logic needs proof, while discretionary logic needs a decision reason.
Supporting evidence
Reference the most stable available source: contract clause, approved workflow, technical procedure, interface agreement, decision log, design rule, permit condition, vendor commitment, or documented operating constraint.
Owner and counterpart
Name the role accountable for validating the relationship. For an interface, identify both sides of the handoff. Ownership is essential because a scheduler should not independently invent technical or contractual logic.
Exception explanation
If the relationship includes lag, lead, unusual relationship type, date constraint, calendar treatment, or another exception, record the physical meaning, quantity basis, and why clearer activities were not preferable.
Validation and approval
Record who confirmed the technical content and when. Approval should be proportionate: a routine interface may need owner confirmation, while a relationship affecting a contractual milestone may require formal authorization.
Review and change history
State when the relationship must be revisited and retain material revisions. A record that only explains the original decision becomes misleading after the schedule logic changes.
Build schedule logic documentation step by step
Use this process during schedule development, interface planning, baseline review, and controlled updates. Apply it to selected relationships according to the documentation threshold established by the project.
Set the documentation threshold
Agree on which relationships need written rationale before the team starts recording them. Include cross-organizational interfaces, discretionary sequencing, external commitments, high-consequence handoffs, nonstandard relationship types, material lags or leads, and logic tied to major contractual or regulatory dates. A threshold prevents two extremes: documenting nothing and documenting every ordinary link.
State where the record will live and which system is authoritative. Options include custom schedule fields, a controlled logic register, the schedule basis document, an interface register, or a linked change record. Avoid distributing fragments across private email, meeting chat, and personal notes.
Start with the real-world handoff
Ask the predecessor owner what becomes available and the successor owner what condition permits their work to begin or finish. Do not start by asking which software relationship type they want. That can produce a technically valid field entry that does not represent the actual workflow.
Use concrete nouns and acceptance conditions. “Engineering must finish before procurement” is incomplete. “Procurement may issue the purchase order after the approved technical specification and commercial requisition are released” defines the inputs and the enabled action.
Classify the reason for the dependency
Determine whether the relationship is inherent to the work, imposed by contract or regulation, selected as a management preference, controlled by an external party, driven by resource or access availability, or created by an acceptance gate. This classification affects how easily the relationship can change.
A mandatory technical dependency cannot be removed simply to improve a forecast. A discretionary sequence may be changed if owners evaluate the consequences and approve a better method. An external dependency requires an interface commitment and monitoring source rather than an unsupported internal date.
Capture evidence at the right strength
Use the most authoritative evidence reasonably available. A signed interface agreement is stronger than an informal recollection. An approved technical procedure is stronger than a generic statement that “we always do it this way.” Where formal evidence does not exist, record the responsible owner’s decision and the assumption explicitly rather than presenting it as established fact.
Do not paste sensitive or controlled material into an unrestricted schedule field. Reference the document identifier, section, controlled repository, and access owner. The record should help an authorized reviewer locate evidence without duplicating information that belongs elsewhere.
Represent the relationship in the schedule
After the real condition is understood, map it to the scheduling method selected by the team. Keep the model as straightforward as the work allows. If a standard finish-to-start tie expresses the transfer accurately, a more complicated relationship adds little value. If overlap or concurrent work is real, define the measurable point that permits it.
The dedicated task dependency process should govern relationship selection and network construction. The documentation record explains the rationale; it does not repair missing or invalid logic by itself.
Explain lags, leads, and unusual techniques
A duration embedded in a relationship can conceal waiting, curing, review, transport, or mobilization time. State what the interval represents, how it was estimated, which calendar applies, and whether a named activity would provide clearer ownership and status. A five-day lag is not self-explanatory merely because the software accepts it.
Leads, unusual relationship types, and date constraints deserve similar care because they can influence float, critical-path behavior, and forecast interpretation. Documentation should never be used to excuse invalid modeling. If the schedule can express the work more transparently with a real activity or milestone, improve the model.
Validate both sides of an interface
For cross-team or external handoffs, ask both parties to confirm the item transferred, required quality, planned date, notice period, status source, and acceptance method. A relationship documented by only the receiving team may rely on an expectation the delivering party never accepted.
Where the parties use different schedules, record both identifiers and define how dates will be reconciled. The separate external dependency process should govern commitments outside the project’s direct control.
Approve according to consequence
Use proportionate governance. A functional owner may validate a routine technical handoff. A relationship controlling a major milestone, contract commitment, shutdown, regulatory submission, or executive decision may need project management, customer, commercial, safety, or regulatory review.
Approval is not proof that the relationship will never change. It confirms that the rationale was understood, evidence was considered, and the selected representation was accepted at that time.
Link material changes to change control
When a relationship is added, removed, or materially altered, preserve the old and new rationale, effective status date, impact analysis, decision owner, and authorization reference. Do not overwrite history with a new explanation that makes the original logic impossible to reconstruct.
Not every routine update requires formal baseline change approval. Follow the established schedule change control process and distinguish normal status maintenance from changes to approved scope, sequence, methodology, or commitments.
Review documentation by exception
Use targeted triggers: changed owner, revised method, new contract requirement, shifted external commitment, modified calendar, unexplained float movement, critical-path transition, repeated forecast variance, or a relationship challenged during review. This keeps documentation current without forcing a complete rewrite every period.
Periodically sample high-impact records and confirm that the linked schedule IDs still exist, evidence remains accessible, owners still recognize the handoff, and the rationale matches current execution. Track corrections as quality improvements, not merely administrative defects.
Document different types of logic differently
A generic comment such as “required dependency” is not enough. The explanation should reflect why the relationship exists and what evidence can validate it.
Mandatory or inherent logic
The sequence follows a physical, technical, or unavoidable condition. State the required input and why the successor cannot proceed without it.
- Example: Pressure testing cannot begin until the test boundary is installed and verified.
- Evidence: Approved test procedure or technical standard.
- Change test: Has the physical method or acceptance basis changed?
Discretionary logic
The team selected a preferred sequence for efficiency, risk reduction, resource use, or management convenience. State the alternatives considered and why this sequence was chosen.
- Example: Complete pilot training before regional rollout to use pilot feedback.
- Evidence: Approved delivery strategy or decision record.
- Change test: Does the benefit still outweigh the schedule effect?
External logic
The event is controlled partly or wholly outside the schedule owner’s authority. State the counterpart, commitment source, confidence, monitoring method, and response if the date changes.
- Example: Grid energization depends on utility authorization.
- Evidence: Utility commitment, permit, agreement, or controlled correspondence.
- Change test: Has the external party reconfirmed the date and conditions?
Examples of concise, decision-ready documentation
These examples show the level of explanation that makes a relationship understandable without turning the record into a technical essay. Adapt them to verified project facts.
Approved specification to purchase order
Weak note: Procurement depends on engineering.
Useful rationale: The buyer may release the purchase order only after engineering issues the approved technical specification and the budget owner releases the commercial requisition. The specification defines the controlled scope quoted by the supplier. Evidence is the approved procurement workflow. Engineering and procurement leads validate the interface at each forecast update until award.
This wording identifies the actual inputs, enabled outcome, evidence, and validating roles. It also exposes that two inputs—not one—control release.
Permit acceptance to field mobilization
Weak note: Wait for authority.
Useful rationale: Field excavation in the controlled area cannot begin until the permitting authority issues written authorization for the approved work package. The external milestone is statused from the permit register maintained by the compliance lead. Mobilization planning may continue, but physical excavation remains blocked. Revalidate the tie if the authority authorizes phased release.
The record distinguishes preparatory work from the action legally or contractually blocked and defines a trigger for changing the logic.
Draft review before document completion
Weak note: Review starts early to save time.
Useful rationale: The technical review begins after the author completes the defined core sections and issues a controlled draft. Early review is a chosen delivery strategy intended to identify blocking issues before final formatting. The document owner confirms draft readiness; reviewers do not approve the final product at this stage. Remove the overlap if draft quality causes repeated rework.
The rationale defines the measurable overlap point and the condition under which the chosen sequence should be reconsidered.
Supplier test completion to site installation
Weak note: Installation follows vendor test.
Useful rationale: Site installation may start after the supplier completes the factory acceptance test, closes all shipment-blocking findings, and issues the release note. The supplier schedule milestone and project receipt milestone are reconciled weekly by the package manager. Transport is modeled separately because its duration and owner differ from factory release.
The record links two schedules and prevents testing, shipping, receipt, and installation from being collapsed into an ambiguous relationship.
Choose where the records should live
No storage method is universally best. Select one authoritative arrangement and define how users reach it from the schedule.
Schedule custom fields
Useful for short rationale codes, owner roles, interface IDs, evidence references, and review status that must stay directly attached to activities. Avoid placing long narratives in fields that are difficult to report, version, or compare.
Controlled logic register
Useful when selected relationships need richer records, approvals, evidence links, and history. Every entry should reference stable schedule IDs, while the schedule contains the corresponding register ID.
Schedule basis documentation
Useful for project-wide conventions, standard workflows, logic thresholds, relationship rules, and unusual techniques that apply to groups of activities. Do not rely on a general basis statement when a specific high-impact interface needs its own owner and evidence.
A hybrid arrangement is often practical: short codes and record IDs in the schedule, a controlled register for selected relationships, and project-wide rules in the schedule basis documentation. The systems must use common identifiers and a defined owner. Without that connection, documentation becomes a separate archive that no longer reflects the live model.
Protect access appropriately. The relationship rationale may reference commercial terms, security controls, personal data, regulated information, or proprietary methods. Record only what authorized users need and link to controlled evidence rather than copying restricted content into broadly distributed reports.
Test whether the documentation is usable
A record is not complete merely because every field contains text. Review a sample against the tests below.
Clarity test
Can an informed reviewer understand what is transferred and why the successor is controlled without interviewing the original scheduler?
Evidence test
Can an authorized reviewer locate the referenced source, and does it actually support the stated rationale?
Ownership test
Is a role accountable for validating the relationship, and does the counterpart recognize the same handoff?
Model test
Does the written rationale match the actual predecessor, successor, relationship type, lag, calendars, and status in the schedule?
Change test
Would a reviewer know when the logic changed, why it changed, who approved it, and which version is current?
Proportionality test
Does the documentation effort match the relationship’s consequence, uncertainty, and complexity rather than treating every tie identically?
Select relationships on the current critical and near-critical paths, external interfaces, large-float anomalies, major milestone paths, nonstandard relationship types, and recently changed logic. Sampling by consequence reveals more than reviewing only the first rows in the schedule.
Common documentation mistakes
Restating the relationship instead of explaining it
“Activity B follows Activity A” repeats what the schedule already shows. Explain the transferred input, required condition, and evidence. A rationale answers why, not merely what.
Using email as the only record
Email can support a decision, but scattered messages are difficult to govern and may omit the final agreement. Capture the approved conclusion in the authoritative record and reference controlled correspondence where necessary.
Assigning the scheduler as technical owner
The scheduler maintains the model but may not have authority to validate engineering, regulatory, commercial, or operational dependencies. Assign the relevant accountable role and let scheduling staff verify that the model reflects the approved rationale.
Documenting an exception without challenging it
A paragraph explaining a long lag or hard constraint does not prove the technique is appropriate. First ask whether a named activity, milestone, calendar, or direct relationship would model the work more transparently.
Losing identifiers during schedule revisions
If activity IDs are regenerated, records can become detached from their relationships. Establish stable identifiers, mapping rules, or migration checks before importing, renumbering, or consolidating schedules.
Overwriting the original decision
Replacing old rationale with new text destroys the audit trail. Retain material versions or change entries showing the previous relationship, revised relationship, reason, impact, authorization, and effective date.
Confusing documentation with schedule quality
A well-written rationale cannot compensate for missing activities, broken logic, unrealistic durations, stale status, or incorrect calendars. Use documentation alongside—not instead of—a broader schedule health check.
Collecting fields nobody reviews
If records are never sampled, validated, or used during change decisions, quality will decay. Assign a review owner, trigger, and exception report so documentation remains part of schedule management rather than an abandoned archive.
Schedule logic documentation checklist
Apply this list to important relationships before baseline approval and after material changes.
- The project has defined which relationships require documentation.
- One authoritative storage location and owner are identified.
- Predecessor and successor IDs match the current schedule.
- The record describes the real input and enabled outcome.
- The rationale is classified as inherent, imposed, discretionary, external, resource-based, or acceptance-based.
- A stable evidence source or explicit assumption is recorded.
- The technical or business validation owner is named.
- Both sides of an interface recognize the handoff.
- Nonstandard relationship types are explained in physical terms.
- Every material lag, lead, constraint, or exception has a basis.
- The written rationale matches the relationship in the live schedule.
- Cross-schedule links include identifiers for both systems.
- External commitments include a status source and monitoring owner.
- Approval is proportionate to the consequence of the relationship.
- A review trigger or validation cadence is defined.
- Material revisions preserve the previous rationale and authorization.
- Restricted evidence is referenced without exposing protected content.
- Exception-based samples are included in schedule quality reviews.
Questions about documenting schedule logic
Must every predecessor and successor relationship have a written rationale?
No. Set a threshold based on consequence and interpretive difficulty. Self-explanatory standard relationships may be adequately supported by clear activity names, approved workflows, and owner fields. Document discretionary, external, cross-schedule, high-impact, unusual, or exception-based relationships where the reason would otherwise be difficult to reconstruct.
What is the difference between a relationship note and a schedule basis document?
A relationship note explains one specific link or interface. A schedule basis document explains project-wide methods, assumptions, calendars, coding, thresholds, and modeling conventions. The basis may cover a repeated standard rule, while selected exceptions and high-consequence ties still need individual records.
Should rationale be stored inside the scheduling software?
Store short fields or record IDs inside the software when that supports reporting and traceability. Rich evidence, approvals, and version history may be easier to manage in a controlled register or repository. Whichever model is selected, maintain stable identifiers and define which location is authoritative.
How should a lag be documented?
State what the interval physically represents, how its duration was established, which calendar applies, who validates it, and why a named activity is not clearer. If the interval can change independently or needs status, model it as an activity rather than hiding it inside the relationship.
How do we document a relationship controlled by a supplier?
Identify the supplier activity or milestone, the project activity it controls, the committed output, acceptance evidence, source schedule or document, responsible counterparts, planned reconciliation cadence, and response if the commitment changes. Do not treat an unconfirmed target as an approved commitment.
Who should approve a relationship rationale?
The person or role with authority over the underlying technical, business, contractual, regulatory, or operational condition should validate it. Approval depth should match consequence. The scheduler should verify that the approved rationale and schedule representation agree but should not invent domain logic independently.
When should an existing logic record be reviewed?
Review it when the execution method, owner, contract, requirement, external commitment, calendar, or interface changes; when logic is modified; when unusual float or forecast behavior appears; when the relationship moves onto a critical or near-critical path; or when a reviewer challenges its validity.
Can logic documentation replace an interface agreement?
No. It can reference and summarize the scheduling effect of an interface agreement, but it does not replace contractual, technical, regulatory, or organizational authorization. Keep the controlled agreement as evidence and use the logic record to connect it to schedule activities.
How can we prevent the register from becoming outdated?
Assign an owner, use stable schedule identifiers, connect logic changes to the established change process, define review triggers, and sample high-impact records during updates or quality reviews. Remove obsolete records only under documented retention rules; preserve material history where it explains approved decisions.