Timedora

1 Traditional Project Planning Foundations

Learn how traditional project planning defines and organizes work, estimates schedule and cost, manages risk, establishes approved baselines, and controls changes and performance.

Purpose and planning foundations

defines work before execution, establishes approved scope, schedule, and cost baselines, and compares actual performance with those plans. The plan is an agreed reference for making changes visible, evaluating their effects, and deciding what to do; it is not a promise that nothing will change. A project charter and scope statement help establish objectives, deliverables, stakeholders, assumptions, and constraints.

Clarify the situation and stakeholders

Before estimating or scheduling, clarify the problem the project must solve and who has authority to approve its objectives and deliverables. Separate known facts from assumptions, constraints, risks, issues, and open questions rather than treating uncertain information as fact.

An is something treated as true for planning that may need verification. For example, a vendor may be expected to provide test access by May 1. Record an owner and a date to validate the . A is a confirmed limit on available choices, such as a fixed launch date, funding ceiling, regulatory requirement, or limited staff availability. A is an uncertain event that could affect an objective; if an event has already happened, it is an issue rather than a future . Assign an owner and due date to each open question that needs an answer for reliable planning.

Identify stakeholders—the people or organizations that authorize, fund, perform, use, regulate, or are affected by the project. Clarify each stakeholder’s needs, influence, responsibilities, and approval role. A sponsor may authorize funding; users help define acceptance needs; a technical team estimates and performs work; and a compliance specialist identifies mandatory controls. Involve affected parties early enough to surface conflicting requirements.

Define and organize the work

Define the project’s purpose, measurable objectives, major deliverables, acceptance criteria, and exclusions. A goal such as “Improve the website” is too vague to plan or verify. A more useful objective is to deliver a redesigned public website with an accessible home page, service directory, and approved content by September 30; the team should also specify how acceptance will be tested.

A decomposes the full project scope into deliverables and manageable work packages. If required work is missing from the WBS, it is likely to be missed in estimates or appear later as unplanned scope. For each work package, clarify the expected output, owner, effort or resources, dependencies, and evidence of completion.

Keep scope distinct from the solution approach: scope states what must be delivered, while activities describe how the team will deliver it.

Estimate schedule and cost

Estimate activities from the defined work and sequence them using logical dependencies. Estimate durations with people who understand the work, account for resource availability, and identify milestones and the . A delay on a critical-path activity can delay the project; a delay on another activity may consume its available float without immediately moving the finish date. A credible schedule has traceable logic and explicit assumptions, rather than only a list of desired dates.

Estimate costs against the same work breakdown. Include relevant labor, materials, equipment, services, and other project costs, and document the estimating basis and uncertainty. Keep the estimate distinct from the approved budget: the budget is the authorized funding plan and may include contingency. Identify what contingency covers and who may authorize its use; do not hide uncertainty by padding individual task estimates.

Document estimating assumptions and assess how changes in key assumptions, risks, and uncertainty could affect cost and schedule.

Plan and respond to

Write each as a conditional cause–event–effect statement. For example: “Because the specialist is shared with another program, they may be unavailable during integration, delaying testing.” Assess likelihood and impact using definitions appropriate to the project. Prioritize significant risks, assign an owner, and plan a response.

Responses may reduce likelihood, reduce impact, avoid the exposure, transfer it where appropriate, or accept it with a contingency plan. Revisit risks as the work and evidence change. responses can themselves affect scope, schedule, and cost.

Approve baselines and control changes

Once scope, schedule, and budget are sufficiently developed and reviewed, obtain the required approval and establish the project baselines. The scope defines the approved work; the schedule captures approved planned dates; and the cost is the approved, time-phased budget used to measure performance. Together, these baselines provide the reference for control. The project plan should also state how progress will be reported, who can approve changes, and how changes will be recorded. A is an approved plan against which deviations and proposed changes can be evaluated, not a forecast of certainty.

When a stakeholder requests added scope, clarify the requirement and assess its effects on deliverables, acceptance, dependencies, resources, , schedule, and cost. Submit the request through the agreed change-control process. The authorized decision-maker may approve it, reject it, defer it, or request alternatives. Update the relevant plans and baselines only after approval, so informal requests do not quietly become commitments.

During execution, compare actual progress with the plan, investigate variances, forecast likely outcomes, and agree on corrective action.

Measure and investigate performance

Earned-value measures compare planned work, completed work, and actual cost:

  • PV (planned value): Budgeted value of work scheduled by the status date.

  • EV (earned value): Budgeted value of work actually completed.

  • AC (actual cost): Cost actually incurred for completed work.

  • SV (): SV=EV−PVSV = EV - PV.

  • CV (cost variance): CV=EV−ACCV = EV - AC.

  • SPI (schedule-performance index): SPI=EVPVSPI = \frac{EV}{PV}.

  • CPI (cost-performance index): CPI=EVACCPI = \frac{EV}{AC}.

For example, if PV is $50,000, EV is $40,000, and AC is $45,000, then:

SV = -$10{,}000, \quad CV = -$5{,}000, \quad SPI = 0.80, \quad CPI \approx 0.89

The project has earned less work than planned and spent more than the budgeted value of that work. These signals prompt investigation; by themselves, they do not explain the cause or determine the remedy. Check affected activities, critical-path consequences, estimate-to-complete, and risks before recommending action. in earned-value terms is measured in budget units, not days.

Apply the planning process

A community library plans to launch a redesigned service website before the fall registration period. The sponsor confirms the required launch date and an $80,000 funding limit. Staff assume the vendor will deliver a usable test environment by June 1, but the vendor has not confirmed this. The project manager records the for validation. Library staff, patrons, the accessibility adviser, IT, the vendor, and the sponsor are identified as stakeholders, and their acceptance and approval responsibilities are clarified.

The team defines deliverables: approved requirements, redesigned pages, a service directory, tested content migration, staff training, and launch approval. It explicitly excludes a mobile application. The WBS breaks the deliverables into work packages such as approving content, configuring the test environment, migrating content, conducting accessibility testing, fixing defects, and training staff.

The schedule shows dependencies rather than assuming them away: accessibility testing follows migration, and launch approval follows testing and defect fixes. The team checks whether staff and vendor resources are available on the needed dates, identifies which activities control the launch date, estimates costs by work package, and checks the costs against the $80,000 limit.

The team records a that a late vendor test environment could delay testing and launch. The vendor contact owns confirmation, while IT prepares a fallback test environment whose cost and timing are assessed. After stakeholders review the scope, estimates, schedule, and responses, the sponsor approves the baselines. A later request to add an online booking feature is assessed for cost, time, testing, and training impacts and submitted for change approval rather than added informally.