Develop Schedule in PMBOK 8 — Complete Guide

Article updated in March 2026 for the PMBOK® Guide — Eighth Edition.

Develop Schedule in PMBOK 8 — Complete Guide

Formerly known as: Develop Schedule (PMBOK 6)

The IT director had committed to the board: the new ERP system would be live by September 15th. He had calculated the timeline in his head — eight modules, roughly a month each, must be about eight months. February to September. Done. The project manager, hired three weeks later, inherited that commitment. She built the first real schedule in March. What she found: 47 external dependencies on data migration from legacy systems, 11 government compliance reviews with hard deadlines, and six modules that could not begin until infrastructure was in place. The critical path was 14 months, not 8. The board was informed in April. The director did not survive the conversation.

The damage was not caused by bad luck or poor execution. It was caused by a commitment made without a schedule. The develop schedule PMBOK 8 process is the structured practice of analyzing activity sequences, durations, resource requirements, and constraints to produce a realistic, achievable schedule model. It is the process that translates project aspirations into a time-bounded plan — and it is the process that, when skipped or shortcut, creates the gap between what was promised and what is actually deliverable.

PMBOK 8 describes Develop Schedule as an iterative process composed of four steps: Define Activities, Determine Sequence, Estimate Effort and Duration, and Adjust. This four-step model makes the process accessible and applicable to both novice practitioners and experienced project managers working on complex, multi-year initiatives.

• 1. What Is the Develop Schedule Process
• 2. Why Use the Develop Schedule Process
• 3. Inputs, Tools & Techniques, and Outputs (ITTO)
• 4. Step-by-Step Application Guide
• 5. When to Apply This Process
• 6. Real-World Examples
• 7. Templates and Downloads
• 8. Five Common Errors
• 9. Tailoring This Process
• 10. Process Interactions
• 11. Quick-Application Checklist

1. What Is the Develop Schedule Process

According to the PMBOK® Guide — Eighth Edition, Develop Schedule is the process of analyzing activity sequences, durations, resource requirements, and schedule constraints to create a schedule model for project execution, monitoring, and controlling. Developing an acceptable project schedule is an iterative process. The schedule model is used to determine the planned start and finish dates for project activities and milestones based on the best available information.

Schedule development may require the review and revision of duration estimates, resource estimates, and schedule reserves to establish an approved project schedule that can serve as a baseline to track progress. The process is explicitly iterative: the draft schedule may be unacceptable (too long, resource conflicts, missing milestones), requiring adjustments to sequence, resources, or scope before a final schedule baseline can be approved.

PMBOK 8 describes four sequential steps for developing the schedule:

1. Define activities — Identify and document the specific actions needed to produce project deliverables.
2. Determine sequence — Establish the logical order in which activities must be performed.
3. Estimate effort and duration — Determine how much work and how much time each activity requires.
4. Adjust — Review the draft schedule and apply optimization techniques to produce an acceptable baseline.

PMBOK 6 vs. PMBOK 8: How Develop Schedule Changed

2. Why Use the Develop Schedule Process

The schedule is the primary communication tool with stakeholders. The project schedule communicates when deliverables will be ready, when milestones will be achieved, when the project will end, and what the critical path is. Without a formal schedule, stakeholder expectations are managed through informal conversations that inevitably diverge from reality. A published, maintained schedule gives all parties a common reference point.

Scheduling reveals the impossible before it becomes the disastrous. The develop schedule PMBOK 8 process forces the project manager to confront reality: all dependencies, all resource constraints, all mandatory regulatory windows, all external events that the project must accommodate. The schedule computation often reveals that the originally promised timeline is impossible. Discovering this during planning — when alternatives can be explored — is always better than discovering it three months into execution.

The critical path determines where management attention belongs. Once the schedule is developed and the critical path identified, the project manager knows which activities have zero float (any delay extends the project end date) and which have buffer. Resource allocation, risk monitoring, and management attention should be concentrated on critical path activities. Without a schedule, these priorities are guessed rather than calculated.

Schedule data enables earned value management. The schedule baseline produced by develop schedule PMBOK 8 is a required input to earned value analysis. Schedule variance (SV = EV − PV) and schedule performance index (SPI = EV / PV) can only be calculated with a proper schedule baseline. These metrics give the project manager and sponsor objective, quantitative data on schedule performance throughout the project.

3. Inputs, Tools & Techniques, and Outputs (ITTO)

The following table presents the complete ITTO for the Develop Schedule process as documented in the PMBOK® Guide — Eighth Edition (Figure 2-22).

Key Tools and Techniques Explained

Critical path method (CPM): CPM analyzes all schedule network paths to identify the longest path through the project network — the critical path. Activities on the critical path have zero float and directly determine the project’s minimum duration. CPM is the foundation of predictive schedule development.

Precedence diagramming method (PDM): PDM represents activities as nodes and dependencies as arrows. Four dependency types are supported: Finish-to-Start (FS), Start-to-Start (SS), Finish-to-Finish (FF), and Start-to-Finish (SF). PDM is the primary technique for building the schedule network diagram.

Schedule compression: When the calculated schedule exceeds the required deadline, two primary techniques are available. Crashing adds resources to critical path activities to reduce duration — at additional cost. Fast-tracking performs activities in parallel that were originally planned sequentially — at additional risk.

Critical chain method: An alternative to CPM that accounts for resource constraints and human behavioral factors (student syndrome, Parkinson’s law, multitasking). Critical chain inserts buffers (project buffer, feeding buffers, resource buffers) to protect the project’s critical chain against uncertainty.

Rolling wave planning: For large projects where future work cannot be planned in detail, rolling wave planning involves creating detailed near-term schedules while keeping future phases at a high level. Detail is added progressively as the project progresses and more information becomes available.

Agile release planning: The agile counterpart to predictive scheduling. Release planning uses team velocity, sprint length, and backlog prioritization to forecast when specific features will be delivered and when the product will be ready for release. PMBOK 8 explicitly includes this as a Develop Schedule technique.

Estimation techniques: PMBOK 8 recognizes a full spectrum of estimation techniques. For adaptive projects, this includes planning poker, story points, and T-shirt sizing. For predictive projects: analogous, parametric, PERT (Program Evaluation and Review Technique), and bottom-up estimating. PERT (Optimistic + 4×Most Likely + Pessimistic) / 6 is particularly valuable for activities with high uncertainty.

4. Step-by-Step Application Guide

PMBOK 8 defines four explicit steps for developing the schedule:

Step 1 — Define activities. Decompose WBS work packages into specific, schedulable actions. Each activity should have: a unique identifier, a clear description of the work to be performed, expected outputs, and enough specificity to support duration estimation and resource assignment. Typical artifacts: activity list, activity attributes, milestone list.

Step 2 — Determine sequence. Establish the logical relationships between activities. For each activity, ask: What must be completed before this activity can start? What can start simultaneously? Every activity (except the first and last) should have at least one predecessor and one successor. Document the logical relationships using the precedence diagramming method. Identify mandatory dependencies (hard logic: this physically must happen before that), discretionary dependencies (soft logic: best practice sequence), and external dependencies (government approvals, vendor deliveries, regulatory milestones).

Step 3 — Estimate effort and duration. For each activity, estimate: (a) effort (how many labor hours or person-days of work does this require?) and (b) duration (how many calendar days or working periods will it take, given the available resources?). Apply PERT or three-point estimating for activities with significant uncertainty: (O + 4M + P) / 6, where O = optimistic, M = most likely, P = pessimistic duration. Document all assumptions and basis of estimates.

PMBOK 8 highlights key factors affecting duration estimates:

• Law of diminishing returns: Adding more resources does not always proportionally reduce duration — coordination overhead increases.
• Cognitive bias: Planning fallacy (underestimating duration), Hofstadter’s law (it always takes longer than you think, even when accounting for Hofstadter’s law), end-of-story illusion (underestimating the “tail end” work).
• Level of decomposition: Better estimates come from estimating at the activity level, not the work package level.

Step 4 — Adjust. Run the schedule network analysis using CPM or the critical path method to compute the early start, early finish, late start, late finish, and float for each activity. If the resulting schedule is unacceptable (too long, resource over-allocation, missed mandatory milestones), apply adjustment techniques:

• Fast-tracking: overlap sequential activities where risk allows
• Crashing: add resources to critical path activities
• Resource leveling: redistribute work to resolve over-allocation at the expense of duration
• Scope reduction: remove lower-priority deliverables (requires scope change)

Once the adjusted schedule produces an acceptable result, present it for approval and establish it as the schedule baseline.

5. When to Apply This Process

Before project execution begins: The schedule must be developed before significant work begins. In predictive projects, the schedule is developed during the planning phase. Work should not start on a predictive project without an approved schedule baseline.

Iteratively throughout planning: The initial schedule is rarely the final schedule. Multiple iterations of development (adding activities, adjusting dependencies, resolving resource conflicts) are normal and expected. PMBOK 8 explicitly recognizes schedule development as an iterative process.

During rolling wave planning: Large projects may develop detailed schedules for near-term phases while maintaining milestone-level schedules for future phases. The develop schedule process is re-executed for each phase as the planning horizon approaches.

When significant changes occur: Major scope changes, significant risk events, or changes in resource availability may require re-developing the schedule to reflect the new project reality. The updated schedule is processed through change control before the baseline is updated.

6. Real-World Examples

Example 1: Project Phoenix — Website Launch

Alex Morgan developed the Project Phoenix schedule over three iterations. The first iteration produced a 110-day schedule using bottom-up estimating from the WBS work packages. The client had approved a 90-day timeline. The gap required the adjust step.

Alex applied fast-tracking: the front-end development and back-end API development were separated, enabling them to proceed in parallel rather than sequentially. The UI design team started building front-end templates while the back-end developer built the API endpoints. This overlap reduced the schedule by 14 days. Remaining gap of 6 days was addressed by adding a second developer to the e-commerce module during weeks 6–9 (crashing), at a cost of $4,800 in additional resource time. The final approved schedule was 89 days — meeting the 90-day commitment with one day of contingency.

The critical path ran through: Infrastructure Setup → Database Design → Back-end API Development → E-commerce Module → Payment Integration → User Acceptance Testing → Go-live. Any delay in these activities would delay the project launch. Alex monitored critical path activities weekly and flagged any task starting more than 1 day late for immediate intervention.

Example 2: Project ProjectAdm — SaaS PM Platform

Eduardo used agile release planning to develop the ProductAdm schedule. Starting with a backlog of 340 story points (initial estimate), a team velocity of 24 points per sprint (2-week sprints), and a 6-sprint buffer, Eduardo forecasted a first major release at Sprint 16 — 32 weeks from kickoff. The forecast was presented to investors with a 90% confidence interval: Sprint 14 to Sprint 18 (28 to 36 weeks).

Eduardo updated the release plan every 4 sprints using actual velocity data. By Sprint 8, the team’s average velocity had stabilized at 28 points per sprint (better than projected). The updated forecast moved the release date to Sprint 13. This continuous update made the release forecast increasingly accurate as the project progressed — investors appreciated the transparency of velocity-based forecasting.

Download a Project Schedule Template for Software Development to build your schedule using CPM and agile release planning techniques.

7. Templates and Downloads

• Project Schedule Template — Software Development — Full schedule template with activity list, network diagram, CPM calculation, and milestone tracking.
• Schedule Management Plan Template — Defines scheduling approach, tools, update frequency, control thresholds, and performance measurement rules.
• Schedule Baseline Template — Approved schedule baseline with version control for tracking approved changes.

8. Five Common Errors

Error 1: Estimating duration from effort without considering availability. A task requiring 40 hours of effort does not take 1 week if the assigned resource is only available 25% of the time. Duration = Effort / (Resource Availability × Productivity Factor). Failing to apply this formula produces schedules that are systematically too optimistic.

Error 2: Not identifying all dependencies. External dependencies are particularly prone to being missed. Regulatory approvals, vendor deliveries, client decisions, shared resource availability — all of these create hard constraints on schedule activities that are not visible in the project’s internal WBS. Missing external dependencies is one of the most common causes of schedule delays.

Error 3: Ignoring cognitive biases in estimation. PMBOK 8 explicitly names planning fallacy and Hofstadter’s law as estimation risks. These biases systematically cause teams to underestimate duration. Counter them by: comparing estimates to historical data, using three-point estimating instead of single-point estimates, involving multiple estimators, and adding schedule reserves explicitly.

Error 4: Creating an over-optimistic schedule and then trying to crash it during execution. Schedule compression techniques (crashing and fast-tracking) are emergency tools, not planning techniques. Applying them during execution adds cost (crashing) and risk (fast-tracking). A schedule developed realistically — accounting for resource availability, dependencies, and uncertainty — should rarely need aggressive compression during execution.

Error 5: Developing the schedule without the team. Schedules developed by the project manager alone, without input from the team members who will actually perform the work, consistently underestimate duration and miss critical activities. The people doing the work are the best estimators of the work. Schedule development should be a collaborative exercise.

9. Tailoring This Process

Life cycle and development approach: PMBOK 8 provides explicit tailoring guidance for three life cycle types. In predictive projects, the schedule is defined upfront with formal baselines and change management. In adaptive projects, sprint-based scheduling with velocity forecasting replaces CPM. In hybrid projects, high-level predictive scheduling covers key milestones while adaptive sprints manage detailed execution.

Team experience: Experienced teams may use less-detailed high-level schedules; less-experienced teams benefit from more granular scheduling that reduces ambiguity. Tailor decomposition depth to the team’s ability to self-direct without excessive guidance.

Project scale: Megaprojects (billions of dollars, multi-year timelines, thousands of activities) require sophisticated scheduling tools (Primavera P6, Microsoft Project), multi-level schedule integration, and dedicated schedule engineers. Small projects may be adequately managed with spreadsheet-based schedules. Match the scheduling rigor to the project complexity.

Scheduling approach: PMBOK 8 recognizes several industry-specific scheduling approaches as valid tailoring options: Location-Based Scheduling (LBS) for construction, Lean Scheduling and Last Planner System for lean delivery, and Kanban for flow-based work. Select the scheduling methodology appropriate to the industry and team context.

10. Process Interactions

Interaction with Create WBS: The WBS work packages are decomposed into activities in Step 1 of Develop Schedule. The quality of the WBS directly determines the quality of the activity list and, therefore, the quality of the schedule. A comprehensive WBS produces a comprehensive schedule; a WBS with gaps produces a schedule with missing activities.

Interaction with Define Scope: The scope statement establishes the deliverables against which activities are defined. Changes to the scope statement require re-evaluation of the activity list and may require schedule re-development. Scope and schedule are tightly coupled: any scope change has a schedule implication.

Interaction with Sequence Activities: Sequence Activities is the formal process of establishing activity dependencies in PMBOK 8. It is embedded within Step 2 (Determine Sequence) of the four-step schedule development model. The outputs of activity sequencing — project schedule network diagrams — are direct inputs to the CPM calculation.

Interaction with Control Schedule: The approved schedule baseline produced by Develop Schedule is the primary reference point for Control Schedule. All schedule performance metrics — actual vs. planned dates, float consumption, critical path status — are calculated relative to the baseline. The baseline cannot be changed without formal change control.

Interaction with Risk Management: Schedule risk is one of the most significant project risk categories. Risk identification and quantitative risk analysis (Monte Carlo simulation) use the schedule model to assess the probability distribution of the project end date. Schedule reserves (contingency time) are sized based on risk analysis and are incorporated into the schedule during the Adjust step.

11. Quick-Application Checklist

• ✅ WBS work packages decomposed into specific, estimable activities (activity list created)
• ✅ Milestone list defined with mandatory dates identified
• ✅ Logical relationships established for all activities (predecessors and successors)
• ✅ Mandatory, discretionary, and external dependencies documented
• ✅ Leads and lags applied where appropriate
• ✅ Duration estimated for each activity (using appropriate technique: analogous, parametric, PERT, bottom-up, story points)
• ✅ Resource availability and calendars considered in duration estimation
• ✅ Cognitive biases accounted for (three-point estimating, historical data comparison)
• ✅ Schedule network diagram built and critical path calculated
• ✅ Total float calculated for all activities
• ✅ Schedule compressed if needed (fast-tracking and/or crashing)
• ✅ Resource leveling applied to resolve over-allocations
• ✅ Schedule reserves (contingency) included based on risk assessment
• ✅ Schedule reviewed with team and approved by sponsor
• ✅ Schedule baseline established and version-controlled
• ✅ For agile: velocity-based release plan produced with confidence intervals

Call to Action:

References

Project Management Institute (PMI). A Guide to the Project Management Body of Knowledge (PMBOK® Guide) – Eighth Edition. Newtown Square, Pennsylvania, USA: Project Management Institute, 2025.

PMBOK Guide 8: The New Era of Value-Based Project Management. Available at: https://projectmanagement.com.br/pmbok-guide-8/

Disclaimer

This article is an independent educational interpretation of the PMBOK® Guide – Eighth Edition, developed for informational purposes by ProjectManagement.com.br. It does not reproduce or redistribute proprietary PMI content. All trademarks, including PMI, PMBOK, and Project Management Institute, are the property of the Project Management Institute, Inc. For access to the complete and official content, purchase the guide from Amazon or download it for free at https://www.pmi.org/standards/pmbok if you are a PMI member.