Plan and Manage Schedule: Creation

Before we plot a single date, we must select the fundamental framework governing how work will be released. The nature of your deliverable dictates your approach to time.

A predictive project schedule relies on a defined Work Breakdown Structure (WBS) to create a sequential flow of activities. In environments where changes are prohibitively expensive—like constructing a hospital—you must completely decompose the scope upfront. The schedule is a rigid map from start to finish.

In contrast, software and knowledge work thrive on empirical feedback. An agile project schedule typically uses release planning to map out high-level timelines for deliverable product increments, rather than micro-managing a multi-year plan. From there, iteration planning in agile methodologies schedules specific user stories into fixed-length timeboxes (sprints). The team commits only to what fits within that immediate timebox.

Alternatively, some environments prioritize continuous flow over fixed iterations. On-demand scheduling pulls work from a backlog as team capacity becomes available. Because it prevents bottlenecks by strictly limiting work-in-progress, on-demand scheduling is the primary scheduling method used in Kanban systems.

Source: Abstract Kanban Board by Jennifer Falco, CC BY 4.0.

Finally, the modern reality often requires a synthesis of both worlds. A hybrid project scheduling approach combines predictive high-level milestones—satisfying executives who need long-term capital forecasting—with agile execution phases for detailed work, allowing the delivery teams to adapt to discoveries on the ground.

We do not build schedules in a vacuum. A savvy project manager stands on the shoulders of past projects. Organizational Process Assets (OPAs) supply standardized schedule templates to accelerate new project schedule creation, and they include historical schedule data from previous organizational projects. Why guess how long vendor procurement takes when your organization has documented its duration across fifty past projects?

Simultaneously, we are constrained by the environment. Enterprise Environmental Factors (EEFs) heavily influence our work; in the context of scheduling, these include the commercial scheduling software systems utilized to develop the project schedule. You must operate within the algorithmic logic of the software your enterprise has mandated.

Within the software, we anchor our timelines using milestones. A project milestone represents a significant point, event, or major deliverable completion in a project lifecycle. Because it represents an achievement rather than the effort taken to get there, a project milestone has a scheduled duration of exactly zero days.

Source: Desenho de um marco no PrjetctLibre by Xexeo, CC BY-SA 4.0.

Work cannot simply happen in any order. To calculate a schedule, we must explicitly define the rules of sequence, known as dependencies.

Dependencies fall into four intersecting categories:

• Mandatory dependencies are legally or physically required relationships between project activities. (You cannot erect the walls until the foundation is poured; the physical universe demands it).
• Discretionary dependencies are established based on industry best practices or specific project team preferences. (You could install the plumbing and electrical simultaneously, but best practice dictates doing plumbing first to avoid water damage to wires).
• External dependencies involve relationships between project activities and non-project activities outside the team's control. (Waiting for a city municipality to issue a building permit).
• Internal dependencies involve relationships between project activities completely within the project team's control. (Your front-end developers waiting for your back-end developers to finish an API).

Once we understand the source of the dependency, we must define its mathematical relationship.

We can further manipulate these relationships using time offsets. A lead allows an acceleration of a successor activity based on the finish date of a predecessor activity (e.g., beginning to landscape two days before the exterior painting finishes). Conversely, a lag directs a mathematical delay in the successor activity relative to a predecessor activity (e.g., waiting three days for concrete to cure before building on it).

A schedule is only as reliable as the duration estimates of its component parts. Estimation is not guessing; it is the application of statistical and historical probability.

Predictive Estimation Techniques

When dealing with defined activities, project managers employ four primary methods:

1. Analogous Estimating: Uses historical data from a similar past project to estimate duration or cost for a current project. Because past projects are never perfectly identical, analogous estimating relies on expert judgment to adjust historical data for current project conditions.
2. Parametric Estimating: Uses an algorithm to calculate activity duration based on historical data and project parameters. If it takes one hour to frame ten square feet of wall, a 1,000-square-foot wall takes 100 hours. It is highly accurate when the underlying metrics are scalable.
3. Bottom-up Estimating: Aggregates the duration estimates of lower-level components of the Work Breakdown Structure into a total project estimate. It is the most accurate method but costs the most time to perform.
4. Three-point Estimating: Uses optimistic, most likely, and pessimistic values to calculate an expected activity duration. It acknowledges risk and uncertainty mathematically.

Three-Point Estimating Formulas:

• Triangular Distribution: Adds the optimistic, pessimistic, and most likely values, then divides the sum by three. Unweighted, treating all three scenarios as equally probable. (O + M + P) / 3
• Beta Distribution (PERT): Adds the optimistic, pessimistic, and four times the most likely value, then divides the sum by six. This weighted average anchors the estimate heavily toward reality. (O + 4M + P) / 6

Agile Estimation Techniques

In knowledge work, humans are notoriously terrible at estimating absolute time. Instead, agile teams estimate relative effort.

Story points are a relative measure of effort used in agile estimating rather than an absolute measure of time. Think of lifting furniture: you might not know exactly how many seconds it takes to carry a sofa versus a chair, but you intuitively know the sofa represents "13 points" of effort while the chair is only "2 points". Story point estimates account for the complexity, risk, and volume of work associated with an agile user story.

To arrive at these estimates, teams use Planning Poker, a consensus-based agile estimating technique designed to avoid the anchoring bias of individual estimates. By having all team members reveal their estimates simultaneously, junior developers aren't influenced by the senior architect's initial guess. Planning Poker utilizes a modified Fibonacci sequence (1, 2, 3, 5, 8, 13, 21...) to assign story point values to product backlog items, ensuring clear differentiation between sizes.

Source: Fibonacci Squares by Romain, CC BY-SA 4.0.

For massive backlogs, teams use Affinity estimating, which categorizes product backlog items into groups of similar size or effort (often using T-shirt sizes like S, M, L, XL) for rapid, high-level sizing.

Once all activities are defined, sequenced, and estimated, the project management software performs schedule network analysis. This vital calculation identifies early start, late start, early finish, and late finish dates for all project activities.

At the heart of this analysis is the Critical Path Method (CPM). The Critical Path Method calculates the longest sequence of dependent activities in a project schedule network diagram. Consequently, the critical path dictates the shortest possible physical duration for completing the entire project. If any activity on the critical path is delayed by one day, the entire project finish date is delayed by one day.

This introduces the concept of float, or "slack."

• Total float is the amount of time a schedule activity can be delayed without delaying the project finish date.
• Free float is the amount of time a schedule activity can be delayed without delaying the early start date of any immediate successor activity.

Because the critical path is the longest path, it has no buffer. Therefore, activities situated directly on the critical path typically possess zero total float.

In an agile context, timeboxes replace the critical path network diagram. To forecast schedules, we look to historical output. Agile velocity measures the exact number of story points an agile team successfully completes within a single iteration. Project managers utilize historical team velocity to mathematically predict the volume of work an agile team can complete in future iterations, allowing them to project release dates for specific features.

What happens when the mathematically calculated critical path extends beyond a mandatory business deadline? You must bend time. Schedule compression techniques aim to shorten the overall project duration without reducing the original project scope. There are two primary levers:

1. Crashing is a schedule compression technique involving adding additional resources to critical path activities. If painting takes four days with one painter, perhaps it takes two days with two painters. Because you must pay for overtime, expedited shipping, or extra labor, crashing a project schedule almost always results in increased total project costs.
2. Fast-tracking is a schedule compression technique involving performing normally sequential activities in parallel. You begin drafting the training manual before the software interface is completely finalized. Because you are making assumptions, fast-tracking a project schedule often increases overall project risk due to the potential for rework.

Sometimes the issue is not the deadline, but the people. If your star engineer is scheduled to work 120 hours in a single week due to parallel tasks, the schedule is biologically impossible. We must employ resource optimization techniques.

• Resource leveling adjusts start and finish dates of activities to balance resource demand with available resource supply. By delaying tasks until the engineer is available, applying resource leveling to a project schedule frequently alters the original critical path, often pushing out the project end date.
• Resource smoothing, on the other hand, adjusts activity dates exclusively within the mathematical limits of free float and total float. Because it never delays critical path activities, resource smoothing guarantees that the original project completion date remains entirely unaffected. However, it may not completely resolve all resource peaks.

A schedule is merely a theory until it is locked. A schedule baseline represents the formally approved version of a specific schedule model. It is the gold standard of intent, signed off by stakeholders.

Once execution begins, reality will inevitably diverge from theory. Project managers compare actual schedule execution performance directly against the schedule baseline to calculate schedule variances (e.g., Schedule Variance (SV) and Schedule Performance Index (SPI) in Earned Value Management).

Because the baseline represents a foundational business commitment, it cannot be arbitrarily rewritten when a team falls behind. The schedule baseline requires formal change control procedures for any subsequent modifications. This ensures that the history of the project's time management is transparent, disciplined, and governed by deliberate executive decisions rather than ad-hoc adjustments.