Planning in predictive and hybrid projects

Planning turns a charter into something a team can execute and a sponsor can hold to account. It answers four practical questions: what will be delivered, in what order and by when, with which people and materials, and at what cost. This course teaches the planning half of the Process domain of the PMP exam: requirements and scope, work breakdown structures, activities and networks, duration and cost estimating, the critical path, schedule compression, budgets and reserves, and earned value. Quality, risk, procurement, change control and closure follow in PMP-131, and adaptive delivery in depth follows in PMP-140. This first lesson explains what planning is for, how much of it to do, how plans differ across predictive, adaptive and hybrid life cycles, and introduces the invented project used throughout the course.

Where planning sits in the exam and the PMBOK Guide

At the time of writing (October 2026), the PMP exam follows the examination content outline that took effect on 9 July 2026. It has three domains: People (about 33 % of scored questions), Process (about 41 %) and Business Environment (about 26 %). PMP-101 described the ten Process tasks. This course covers most of the planning content of six of them: developing an integrated plan (the scope, schedule and cost parts), developing and managing scope, planning and managing resources (the estimating side), planning and managing finance, planning and managing the schedule, and evaluating project status with earned value and related measures.

The PMBOK Guide, eighth edition, released digitally in late 2025, organizes guidance into seven performance domains: governance, scope, schedule, finance, stakeholders, resources and risk. It also reintroduces five focus areas (initiating, planning, executing, monitoring and controlling, and closing) and links them to the domains through tailorable processes. For this course the relevant domains are scope, schedule, finance and resources, viewed mainly through the planning and the monitoring and controlling focus areas. You do not need to memorize process names for the exam, but you do need to understand what each planning output is for, how outputs depend on one another and which tool fits which situation.

Why plan, and how much

A plan is a shared prediction and a set of commitments. It lets the team coordinate, lets stakeholders see what they will get and when, and gives the project manager a reference against which to detect problems early. A plan is not a guarantee: it rests on estimates and assumptions that will turn out partly wrong. The value of planning lies as much in the thinking it forces, such as uncovering dependencies, risks and missing work, as in the document it produces.

Too little planning shows up as surprises: a permit nobody requested, a long-lead item ordered too late, a budget missing a whole category of cost. Too much planning shows up as detailed schedules for work that will change, months spent before any value is delivered, and plans so complex that nobody maintains them. The right level depends on the project's size, complexity, uncertainty, regulatory exposure and contract type. A fixed-price construction contract with a public owner needs a detailed, defensible schedule and budget. A small internal software improvement may need only a backlog, a target date and a cost ceiling.

Two related ideas help. Progressive elaboration means plans become more detailed as information improves. Rolling wave planning applies this to the schedule and work breakdown: near-term work is planned in detail, while later work is held as larger planning packages until it gets closer. Both are legitimate and expected; neither is an excuse for leaving known work out of the plan.

Life cycles and what they mean for planning

PMP-110 introduced predictive, iterative, incremental, adaptive and hybrid life cycles. For planning scope, schedule and cost, the key differences are when scope is fixed and how the plan responds to change.

Exam questions increasingly describe hybrid projects. A common pattern is a fixed external date (a regulatory deadline, a building opening, a trade show) with a component whose details are uncertain. The best answer usually plans the fixed elements predictively, plans the uncertain elements adaptively, and defines how the two will be integrated: shared milestones, interface points and a single view of status for the sponsor.

The running example: Project Compass

Throughout this course we follow Project Compass, an invented project at the invented Larkfield Regional Library. The library is opening a new branch, Eastgate, in a leased former retail unit of about 1,150 square metres. The project has four main components: fitting out the space (design, permit, demolition, building systems, finishes, furniture), installing self-service technology (RFID tags on the collection, self-checkout kiosks and security gates), building a mobile app that shows availability and lets patrons place holds and book rooms, and transitioning to operations (training, moving the opening collection and opening events).

The sponsor is the library's chief executive. The board has approved a cost baseline of $2.4 million with a management reserve held by the sponsor, and the branch must open before the autumn programming season. The fit-out and technology installation will be planned predictively, because the lease, permit and construction contracts need firm dates and costs. The app will be built in two-week sprints by a small product team, because patron needs are uncertain and early feedback is valuable. Later lessons build the requirements, WBS, network, estimates, budget and earned value for this project.

Figures are in Canadian dollars. The library is a public body, so its board approves capital budgets and expects regular, honest reporting against them.

The project management plan and its baselines

In a predictive or hybrid project, the outputs of planning are brought together in a project management plan. The plan has two kinds of content. Subsidiary plans describe how each area will be managed, such as scope, requirements, schedule, cost, quality, resources, communications, risk, procurement and stakeholder engagement. Baselines record the approved versions of scope, schedule and cost against which performance is measured.

Baselines change only through formal change control, which PMP-131 covers. This is a frequent exam point: if a schedule slips, you do not quietly move the baseline dates to match. You report the variance, analyse the cause, take corrective action and, if a change to the baseline is genuinely needed, submit a change request. Updating forecasts, by contrast, is normal and expected; forecasts are your current best estimate, baselines are what was approved.

Planning in adaptive projects produces different artifacts: a product vision, a roadmap, a prioritized product backlog, a release plan and iteration plans. These still have baselines of a kind, such as a release goal or a fixed budget per quarter, but scope is expected to change within them. In hybrid projects, the project management plan describes how the predictive and adaptive parts will be planned, measured and integrated.

Turning durations into dates

Plans are built in working time but communicated in calendar dates. A project calendar defines working days and hours and non-working days such as weekends and public holidays; resource calendars add individual availability. The example below converts the high-level phases of Project Compass, estimated in working days, into calendar dates. It is a simple version of what scheduling software does automatically.

# Project Compass: turning working-day durations into calendar dates
# (illustrative plan; weekends and listed holidays are non-working days)
from datetime import date, timedelta

# Statutory holidays observed by the library in 2027 (New Year, Good Friday,
# Victoria Day, Canada Day, Civic Holiday, Labour Day)
HOLIDAYS = {date(2027, 1, 1), date(2027, 3, 26), date(2027, 5, 24), date(2027, 7, 1),
            date(2027, 8, 2), date(2027, 9, 6)}

def is_workday(d):
    return d.weekday() < 5 and d not in HOLIDAYS

def add_workdays(start, n):
    """Return the date on which n working days of effort end, starting on start."""
    d, done = start, 0
    while True:
        if is_workday(d):
            done += 1
            if done == n:
                return d
        d += timedelta(days=1)

phases = [("Initiation and planning", 40), ("Fit-out: design to soft opening", 100),
          ("Grand opening and app launch", 20), ("Stabilization and closure", 30)]
start = date(2027, 1, 4)
for name, days in phases:
    finish = add_workdays(start, days)
    print(f"{name:32s} {days:3d} wd  {start:%a %d %b} -> {finish:%a %d %b}")
    start = finish + timedelta(days=1)
    while not is_workday(start):
        start += timedelta(days=1)
total = sum(d for _, d in phases)
print(f"Total working days: {total}")

Initiation and planning           40 wd  Mon 04 Jan -> Fri 26 Feb
Fit-out: design to soft opening  100 wd  Mon 01 Mar -> Wed 21 Jul
Grand opening and app launch      20 wd  Thu 22 Jul -> Thu 19 Aug
Stabilization and closure         30 wd  Fri 20 Aug -> Fri 01 Oct
Total working days: 190

The 190 working days stretch across almost nine calendar months because of weekends and holidays. Two common errors follow from forgetting calendars: treating working days as calendar days, which makes the plan look shorter than it is, and forgetting holiday periods when key people or suppliers are unavailable. When communicating with stakeholders, always state whether durations are in working or calendar days.

How the planning outputs connect

Planning outputs depend on each other in a clear order, even though in practice they are developed iteratively. Requirements describe needs. The scope statement and WBS define the deliverables and work that will satisfy them. Activities are derived from WBS work packages. Activities are sequenced into a network, durations and resources are estimated, and the critical path method produces a schedule. Costs are estimated from the same work packages and resources, aggregated into a budget and time-phased according to the schedule to create the cost baseline. Earned value then compares actual progress and cost against that baseline.

Because of these links, a weakness early in the chain spreads. Missing requirements lead to missing work packages, which lead to missing activities and costs, which lead to an optimistic schedule and budget. That is why exam answers about overruns often point back to scope definition or requirements, rather than to the estimating technique.

Planning effort and tailoring

Tailoring means adjusting processes, tools and documents to suit the project. A small project might combine the scope statement, schedule and budget into a single short document; a large one might have separate plans, a project controls team and formal reviews of each baseline. Factors that push toward more formal planning include contractual obligations, public accountability, safety and regulatory requirements, many interfaces, large budgets and long durations. Factors that push toward lighter planning include small teams, high uncertainty, low cost of change and frequent customer feedback.

On the exam, a question that asks what the project manager should do first in planning usually rewards understanding the situation (reviewing the charter, identifying stakeholders and their requirements, considering organizational process assets such as templates and lessons learned) before producing detailed plans. Another common theme is involving the team: estimates and schedules are more accurate and more likely to be accepted when the people who will do the work help build them.

Organizational process assets matter more than many candidates expect. Templates for a WBS, historical cost data from previous fit-outs, lessons learned from the last branch opening and standard estimating rates all make planning faster and more accurate. Enterprise environmental factors, such as building codes, the labour market, the library's fiscal year and its procurement rules, constrain the plan. Good planners look for both before starting from scratch.

Finally, planning is never finished. The plan is updated as approved changes occur, as risks materialize and as rolling wave planning adds detail. What should remain stable is the baseline, unless change control approves otherwise, so that progress can be measured honestly.