PERT chart
Build a task network, calculate estimated durations and float, and identify tasks on a critical path.
Use a PERT-style task network when tasks depend on one another and some can run in parallel. This tool accepts a single duration or optimistic/most likely/pessimistic estimates, using (optimistic + 4 × most likely + pessimistic) / 6 for the latter. It calculates early and late times and total float.
Task IDs, task names, duration estimates in one unit, and predecessor IDs.
A dependency network, an estimated project duration, and critical tasks with zero total float.
On this page
How to use it
- Define the project endpoint, time unit, and estimating assumptions.
- List tasks and their predecessors without cycles.
- Enter consistent durations or ordered three-point estimates.
- Review the calculated critical tasks and float.
- Check resource conflicts and update estimates as you learn more.
Keep its limits in mind
The calculation assumes the dependency logic and resource availability are valid. It does not level resources, model schedule probabilities, or promise a delivery date. Parallel work may take longer when tasks need the same person.
Finding the critical path in a launch plan
Fictional example: Xinggang plans a request-system launch. After requirements A, development B and training preparation C can run in parallel; integration D needs both. Durations use days and exclude resource conflicts.
On a small screen, scroll across the diagram to read it.
Calculated result: B’s weighted estimate is 4 days. A→B→D totals 8 days and is the critical path; A→C→D totals 7 days. These are calculated estimates, not completed project timings.
Limit: C’s one day of float depends on all other inputs staying unchanged. A shared developer or an altered dependency can change the plan; no completion probability is calculated.
The 8-day and 7-day paths and 1-day float depend on the given durations, dependencies, calendar, and resource assumptions. They are not a completion probability or an unconditional permission to delay.
Next step: Track blockers on B, check whether parallel tasks share staff, and revise the network as estimates change.
Three reasons to pause before calculating a path
Use the network to ask which predecessors constrain the endpoint and where an estimate could change that answer. Define what “finished” means for each task, use one duration unit and identify a common starting point. A dependency should describe necessary sequencing, not merely a preferred order that nobody has checked.
Pause when the dependency network contains a cycle or a predecessor ID that does not exist. Pause when optimistic, most likely and pessimistic values describe different scopes or units. Pause when parallel branches require the same unavailable person. A valid arithmetic result cannot repair invalid logic or missing capacity.
Three-point estimates are judgments under stated conditions, not three observed completion records. Ask what makes the optimistic case possible and what the pessimistic case includes. Preserve those explanations with the numbers. This tool produces a weighted duration and deterministic path calculations; it does not produce a probability distribution for the project endpoint.
Choose a dependency calculation or a dated schedule
A network answers a conditional sequencing question. It does not know weekends, approved staffing or when the Sponsor is available. Choose the next view from the missing information instead of treating every chart as an interchangeable project plan.
| Method | Required material | Output / limit |
|---|---|---|
| PERT-style network | Acyclic predecessors and duration estimates | Paths and float; no modeled completion probability |
| Gantt chart | Tasks, dates and a working calendar | Dated bars; capacity still requires checking |
| Roadmap | Stage outcomes and enabling conditions | A route to discuss; no detailed task timing |
| RACI matrix | Deliverables and decision rights | Responsibility proposals; no duration estimate |
Worked case: reproduce the forward and backward passes
This continues the independent fictional Xinggang system-launch example, not Pinebridge’s dated preparation plan. The four-task input is complete for this teaching network: A requirements takes two days with no predecessor; B development uses 2/4/6 days after A; C training preparation takes three days after A; D integration takes two days after both B and C. Resource conflicts are excluded from the supplied calculation.
For B, (2+4×4+6)/6 = four days. Start the elapsed-time index at zero, without mapping it to calendar dates. A ends at two. Both B and C can then start at two; B ends at six and C at five. D must wait for the later predecessor finish, six, and ends at eight. Path A–B–D is eight days; A–C–D is seven. Adding every task to get eleven would incorrectly remove the stated parallel relationship.
For the backward pass, set the conditional project finish at eight. D starts at six, so B and C must finish by six. B’s latest start is two; C’s is three. A must finish by the earlier successor latest start, two, so it starts at zero. Total float is latest start minus earliest start. Only C has one day; that is conditional scheduling room, not an owned buffer or permission to postpone without checking.
| Task / duration | Earliest start / finish | Latest start / finish | Total float |
|---|---|---|---|
| A / 2 | 0 / 2 | 0 / 2 | 0 |
| B / 4 weighted | 2 / 6 | 2 / 6 | 0 |
| C / 3 | 2 / 5 | 3 / 6 | 1 |
| D / 2 | 6 / 8 | 6 / 8 | 0 |
Change an estimate, then review the whole network
The original conclusion is an estimated eight-day endpoint with A, B and D on the zero-float path. It is not an eight-day promise. In a separate sensitivity scenario, change only C from three to five days. A–C–D becomes nine while A–B–D remains eight; C becomes critical and B has one day of float. The original critical path is therefore not a permanent property of the task names.
Check people as a separate scenario. If B and C require the same person and must run sequentially, keeping the given durations would yield 2+4+3+2 = eleven days before any other constraints. That is a hypothetical revised sequencing assumption, not a result the current parallel network has discovered. Confirm actual availability and revise the dependencies or estimates before using it.
At review, ask the estimators about scope, dependencies, unresolved work and the conditions behind 2/4/6. Retain the old network and append revised inputs with reasons, then repeat both passes. Monitor near-critical branches as well as the current longest path. Do not convert the weighted average or one day of float into a likelihood of meeting a date. A probabilistic analysis would require an explicit uncertainty model and additional checks beyond this worksheet. Actual starts, finishes and any launch authorization remain separate records.
Check your work
- Task IDs are unique and dependencies are valid.
- All estimates use the same unit.
- Three-point estimates are in optimistic/most likely/pessimistic order.
- Critical-path results are conditional on the input assumptions.
Framework references
References explain the framework and its scope; they do not validate the fictional example's results.
Put the framework to work
Copy the outline and add your question, evidence, and open questions.