Fundraising Operations
Milestone Dependency Mapping: Find the Critical Path
See which prerequisite actually controls a milestone date. Work through a pilot-readiness map, float calculation and delay scenario.
What you will learn
- Separate prerequisites from dates on a calendar.
- Calculate the longest dependency path in a simple plan.
- Explain which delay changes the milestone date.
A milestone dependency map shows what must happen before the next step can begin. The critical path is the longest sequence of dependent work in the schedule model. It determines the earliest modeled finish, not the task that feels most urgent today.
Turn the milestone into an acceptance test
“Launch the pilot” is incomplete. A better milestone names what counts as complete: a working prototype, an agreed customer test, trained operators and a reviewed result. Split the work into activities with durations, owners and prerequisites. Do not add a dependency merely because two tasks appear next to each other in a spreadsheet.
The Project Management Institute’s critical-path teaching explains the scheduling method. The founder example here uses simplified finish-to-start dependencies, working days and no resource conflicts.
Build the original dependency worksheet
Fictional pilot-readiness schedule, measured from day zero
| Task | Work | Duration | Prerequisite | Earliest start | Earliest finish |
|---|---|---|---|---|---|
| A | Approve test specification | 3 days | None | 0 | 3 |
| B | Prepare prototype | 5 days | A | 3 | 8 |
| C | Train pilot operators | 4 days | A | 3 | 7 |
| D | Run the pilot | 2 days | B and C | 8 | 10 |
| E | Review evidence | 1 day | D | 10 | 11 |
At a merge, the next task waits for the latest prerequisite to finish. D cannot start on day 7 just because training is complete; it also needs the prototype. The two paths are A → B → D → E, lasting 11 days, and A → C → D → E, lasting 10 days.
Find the critical path and available float
In this simple network, A, B, D and E form the critical path. C can finish one day later without changing the overall finish, assuming other conditions are unchanged. That one day is scheduling float, not free capacity or a promise the team can absorb any disruption.
Fictional delay sensitivity
| Change | Revised finish | Reason |
|---|---|---|
| B takes two extra days | Day 13 | Longest path becomes 13 days |
| C takes one extra day | Day 11 | C still finishes when B does |
| C takes two extra days | Day 12 | C becomes the limiting prerequisite |
| E starts before D finishes | Not allowed in this model | That changes the dependency, not just the date |
Add the constraints the simple model left out
If the same engineer owns B and C, the assumed parallel work may be impossible. Holidays, customer availability, approval queues and minimum waiting periods also matter. Add resource constraints and calendar rules before treating the worksheet as a committed schedule.
A duration is an estimate. Write its basis and the most important uncertainty. Where uncertainty is material, show a range or a separate delay scenario rather than hiding it inside an unexplained buffer. Recalculate the path when dependencies or durations change.
Use the map in a fundraising conversation
Connect the milestone to the evidence it creates. “We expect a reviewed pilot result after these prerequisites” is more useful than “We will be ready in two weeks.” It lets an investor see why a particular hire, purchase or customer agreement affects timing.
Keep the 90-day operating plan central for the broader rollout. This lesson supplies the dependency arithmetic inside that plan, not another general planning template.
Practice: stress the noncritical task
Using the table, increase C from four to six days. It now finishes on day 9; D finishes on day 11 and E on day 12. The delay is one day, not two, because C originally had one day of float. Record the explanation beside the new finish date.
In Finta, keep the milestone evidence and the investor conversation connected, then assign clear follow-up tasks. A dependency map becomes useful when someone owns the next prerequisite and the team records what actually changed.