In this article, we will look at the Develop Schedule process. This is where we take all the work we have identified, the estimated durations, the resource information, and the constraints, and turn them into a workable, realistic schedule model. The end result is the timetable the project will actually follow.
The two key outputs here are the project schedule and the schedule baseline.
The project schedule is the visible plan. It shows when each activity and milestone is planned to start and finish. It may appear as a Gantt chart, a network diagram with dates, or an iteration plan in an agile context. Its value is that it gives the team and stakeholders a shared, time‑based view of the work, so everyone can see what happens when, who is involved, and how different pieces depend on each other.
The schedule baseline is the approved version of that schedule. It is the frozen reference we use later to measure performance and control schedule changes. Once approved, any significant change to dates or sequencing goes through change control. The value of this baseline is that it lets us distinguish normal variation from formal changes, and it supports objective tracking of schedule performance over time.
Now let’s work backwards from these outputs and see which inputs are most important and how we use them.
To build the project schedule and its baseline, we start with the activity list and the activity attributes. The activity list is simply the complete set of activities that need to be scheduled. Without this list, we would inevitably miss work or plan only part of the project. The activity attributes add detail for each activity, such as constraints, leads and lags, required skills, responsible resources, locations, and predecessor–successor relationships. These details are essential to sequence activities correctly, assign realistic durations, and understand how one activity affects another in time.
We also rely heavily on duration estimates and the basis of estimates. Duration estimates tell us how long each activity is expected to take. The basis of estimates explains where those numbers came from, what data and assumptions were used, and how confident we are in them. Together, they allow us to calculate start and finish dates and to understand which parts of the schedule are more uncertain and might need buffers or closer monitoring.
Project schedule network diagrams are another critical input. These diagrams show the logical relationships among activities: which ones must finish before others can start, which can happen in parallel, and where leads or lags exist. The network diagram provides the structural backbone of the schedule model. When we combine it with duration estimates and resource information, we can compute paths through the network and identify the critical path.
Resource requirements, project team assignments, and resource calendars bring the resource dimension into the schedule. Resource requirements state what type and quantity of resources each activity needs. Project team assignments tell us who is actually doing the work. Resource calendars show when those people and other resources are available or not available. These inputs ensure that the schedule is not just logically correct, but also feasible given real resource limits. They allow us to detect overallocation, adjust sequencing, and plan around vacations, holidays, and other commitments.
Milestone lists and the project charter give us time anchors and external commitments. The milestone list identifies key events and dates, such as phase completions, governance reviews, or external releases. The project charter provides the high‑level timeline, mandatory start or finish dates, and major milestones the project has promised to meet. These inputs make sure the developed schedule supports the project’s strategic commitments and does not drift away from what was agreed at initiation.
The risk register is also important. It highlights risks that can affect the schedule, such as potential delays, external dependencies, or uncertain productivity. By considering these risks during schedule development, we can decide where to place buffers, where to create alternative paths, and where to increase scrutiny. This makes the schedule more robust and less likely to fail at the first sign of trouble.
Agreements, such as contracts, frame external constraints and obligations. They may include fixed delivery dates, blackout periods, or required sequencing of work dictated by suppliers or customers. Incorporating these into the schedule is essential to avoid contractual breaches and to align internal plans with external expectations.
Finally, the scope management plan and the development approach guide how we structure the schedule. The scope management plan explains how scope is organized and controlled, for example through a WBS or a product backlog. The schedule needs to reflect that same structure, so that time planning aligns with scope planning and changes can be traced. The development approach—predictive, iterative, agile, or hybrid—determines whether we build a detailed, long‑horizon schedule with a firm baseline, or whether we rely more on rolling‑wave planning, shorter iterations, and more frequent re‑planning. This ensures the schedule model fits the way the team will actually deliver.
Now let’s look at the tools and techniques that transform these inputs into a concrete project schedule and baseline.
Schedule network analysis is at the heart of this process. It involves analyzing the activity network, applying durations, and examining the resulting paths through the project. This analysis helps us determine whether the schedule is feasible, where the long paths are, and how changes in one part of the network ripple through the rest. It gives us a first sense of the overall project duration and where the schedule is most sensitive.
Building on that, we use the critical path method. Critical path method calculates the longest path through the network and identifies activities with zero or very little float. These critical activities are the ones where any delay directly affects the project’s finish date. Knowing the critical path allows us to focus our attention and resources where they matter most for time, and it provides a clear basis for later monitoring and control.
In environments where resource constraints are significant, we may use the critical chain method. This technique adjusts the schedule to consider resource availability explicitly and adds buffers to protect the project completion date. Instead of focusing only on logical dependencies, critical chain looks at both dependencies and resource constraints and then positions buffers strategically. The value is a schedule that is more realistic in resource‑constrained settings and better protected against common delays.
Resource optimization techniques, such as resource leveling and resource smoothing, help us align the schedule with real resource limits. Resource leveling tries to resolve overallocations by delaying or resequencing activities, possibly changing the critical path and overall duration. Resource smoothing adjusts activities within their float so that resource use is more even, without changing the project end date. These techniques are important because they turn an idealized schedule into one that the team can actually execute with the resources available.
Schedule compression techniques—fast tracking and crashing—are used when we need to shorten the schedule without changing scope. Fast tracking overlaps activities that were originally planned in sequence, while crashing adds more resources to critical path activities to finish them faster, usually at higher cost. These techniques are particularly valuable when the initial schedule does not meet required dates, and we need to consider trade‑offs between time, cost, and risk.
What‑if scenario analysis helps us explore options. We can test different assumptions, such as varying resource availability, changing sequencing, or adding scope, and see how the schedule responds. This gives us insight into how robust our schedule is and which options are most attractive if conditions change. It supports better decision‑making before we lock in the baseline.
Simulation techniques, such as Monte Carlo analysis, take this further by running many possible scenarios based on ranges for durations and risks. The result is a probabilistic view of the completion date, showing, for example, the likelihood of finishing by a certain date. This helps us decide how much schedule reserve we need and gives stakeholders a more realistic expectation of timeframes.
We also use leads and lags to fine‑tune the timing of dependent activities. By introducing leads, we can allow a successor to start before its predecessor fully finishes, when that makes sense. Lags insert waiting time between activities. Proper use of leads and lags allows the schedule to better reflect real‑world sequencing and can help optimize overall duration.
In adaptive environments, agile release planning and iteration planning are key techniques. Agile release planning looks at the product backlog, the team’s velocity, and priorities to plan which features or stories will be delivered in which releases. Iteration planning breaks down near‑term work into sprints or iterations. The value here is that the schedule is built around incremental value delivery and realistic capacity, rather than fixed, long‑range dates.
Throughout all this, the project management information system, or scheduling software, plays a central role. It allows us to enter activities, dependencies, durations, and resources, and then automatically calculate start and finish dates, identify the critical path, and detect resource conflicts. It makes it practical to maintain and adjust a complex schedule over time.
Data analysis and alternative analysis support all these techniques by helping us compare different schedule options. Decision‑making methods, including voting, then help the team and stakeholders choose among competing schedules, for example when balancing faster delivery against higher cost or risk. Meetings and workshops are used to review the proposed schedule, gather feedback, resolve conflicts, and build consensus before we approve the baseline.
Now that we have focused on the project schedule and schedule baseline, let’s briefly cover the remaining outputs.
Schedule data is the set of supporting details behind the schedule model. It can include assumptions, constraints, alternative scenarios considered, resource requirements, and the rationale for major decisions. Its value is that it documents the thinking behind the schedule, which helps with future updates, risk analysis, and communication.
Project calendars are another important output. They define working days, non‑working days, shifts, and specific patterns for different resources or locations. These calendars are essential for calculating realistic dates and for coordinating work across teams and regions.
Change requests often arise during Develop Schedule. As we analyze dependencies, durations, and resources, we may find that the original scope, resource plan, or constraints make the schedule impossible. In those cases, we raise change requests to adjust scope, resources, deadlines, or other aspects of the project plan. This ensures that the final schedule and baseline are aligned with an achievable overall plan.
Finally, several components of the project management plan and project documents are updated. We may refine the schedule management plan, for example to adjust reporting frequency or thresholds based on what we learned during schedule development. We update documents such as the activity list, activity attributes, milestone list, project schedule network diagrams, assumption log, basis of estimates, duration estimates, resource requirements, risk register, and lessons learned register, so they all remain consistent with the final schedule and baseline. Keeping these artifacts aligned prevents confusion later and supports effective monitoring and control.
In summary, Develop Schedule is the process that turns identified work, estimates, dependencies, resource limits, and constraints into a practical, approved schedule. By using structured inputs, powerful analysis techniques, and collaborative decision‑making, we produce a realistic project schedule and a solid schedule baseline that the team can use as the primary time reference for executing, monitoring, and controlling the project.
