Project Planning, Estimation and Scheduling

Introduction

Project planning converts an approved idea into an executable system of work. In information technology projects, planning must address not only activities and dates, but also uncertain requirements, technical dependencies, specialist skills, procurement lead times, quality expectations, security obligations, and changing stakeholder priorities. A credible plan provides a common basis for decision-making: it clarifies what will be delivered, how work will be performed, what resources are needed, when outcomes are expected, and how performance will be controlled.

Planning is not a one-time clerical exercise. It is progressively elaborated as knowledge improves. At project initiation, a manager may know the business problem and high-level outcome but not the complete solution. During analysis and design, assumptions are replaced with evidence, estimates are refined, and the schedule is revised. Agile projects also require planning, although planning occurs at multiple levels: product roadmap, release, iteration, and daily execution.

This chapter examines scope definition, project charters, work breakdown structures, estimation, scheduling, critical-path analysis, resource allocation, and baselining. It also considers uncertainty, governance, ethical issues, and the use of contemporary digital and AI-enabled planning tools.

Learning Objectives

After studying this chapter, a learner should be able to:

1. Construct a project charter that establishes purpose, authority, assumptions, constraints, and success criteria.
2. Define scope and deliverables using a product-oriented work breakdown structure.
3. Apply analogous, parametric, bottom-up, three-point, and expert-judgment estimation methods.
4. Build a logically connected schedule using dependencies, durations, milestones, and resource information.
5. Calculate early and late dates, float, and the critical path using the critical-path method.
6. Allocate resources and resolve over-allocation while protecting technical and quality objectives.
7. Establish and govern scope, schedule, and cost baselines.
8. Evaluate estimation risk, ethical concerns, and the appropriate use of AI-supported planning tools.

1. From Business Need to Project Scope

A project begins with a problem, opportunity, regulatory requirement, or strategic objective. The planning task is to translate that need into an agreed scope boundary. Scope has two dimensions:

• Product scope: the features, functions, services, data, and quality attributes of the product or solution.
• Project scope: the work required to create and deliver that product or solution.

Confusing these dimensions produces incomplete plans. For example, “mobile banking application” is a product description. Project scope must also include requirements analysis, architecture, development, testing, migration, training, deployment, security review, and transition to operations.

A useful scope statement describes the objective, major deliverables, exclusions, acceptance criteria, assumptions, and constraints. Exclusions are especially important because they prevent stakeholders from treating every desirable feature as an implicit commitment. Acceptance criteria should be observable and testable. “The system shall be user-friendly” is weak; “95% of representative users shall complete account registration in under three minutes without assistance during usability testing” is more actionable, provided the measurement method is agreed.

The Project Charter

The charter formally authorizes the project and the project manager’s authority to use organizational resources. It is normally approved by a sponsor or governance body. A charter commonly contains:

The charter is not a detailed schedule. It is an authorization and alignment instrument. A charter that promises a fixed date, cost, and feature set without evidence may create an impossible triple constraint. Senior managers should explicitly identify which constraint has priority and what trade-offs are permitted.

2. Deliverables and the Work Breakdown Structure

A deliverable is a verifiable product, service, result, or capability. Activities describe work; deliverables describe outcomes. A work breakdown structure (WBS) hierarchically decomposes the total project scope into manageable components. The WBS should be deliverable-oriented, mutually understandable, and complete enough to support estimating and control.

The 100 percent rule states that the WBS should include 100 percent of the work defined by project scope, including project management and transition work, but no work outside that scope. Decomposition proceeds until work packages are sufficiently small to estimate, assign, schedule, monitor, and accept. Excessive decomposition creates administrative overhead; insufficient decomposition hides risk and produces unreliable estimates.

A typical digital transformation WBS might contain:

1. Governance and project management
2. Business and user requirements
3. Solution architecture and design
4. Software configuration and development
5. Data migration
6. Integration and infrastructure
7. Verification, validation, and security testing
8. Training and organizational readiness
9. Deployment and transition
10. Closure and benefits handover

A work package should have a defined output, accountable owner, acceptance conditions, estimated effort and duration, dependencies, and cost basis. The WBS dictionary supplements the graphical hierarchy by explaining boundaries, assumptions, quality requirements, and completion criteria.

The WBS is not necessarily the schedule. A schedule contains activities, logical relationships, dates, resources, and calendars. A WBS answers “what is included?”; a schedule answers “in what sequence and at what time will the work occur?” The two should be integrated through activity coding or a WBS identifier.

3. Estimation: Effort, Duration, Cost, and Accuracy

Estimation is a forecast, not a promise. Four concepts must be distinguished:

• Effort: labor required, commonly measured in person-hours or person-days.
• Duration: elapsed calendar time between start and finish.
• Cost: monetary value of labor, materials, services, licenses, and contingency.
• Capacity: amount of work a resource or team can realistically perform during a period.

Effort and duration are not interchangeable. If a task requires 20 person-days, it does not necessarily take four calendar days with five people. Communication, handoffs, learning curves, coordination, scarce skills, and technical dependencies limit parallelism. A simple relationship is:

Here, effective capacity is the productive effort available per calendar unit after accounting for holidays, meetings, support work, interruptions, and utilization limits. The relationship is an approximation and is inappropriate where work is sequential or adding people increases coordination more than capacity.

Estimation Approaches

Expert judgment uses specialists’ experience. It is efficient but can be affected by optimism, anchoring, authority pressure, and unexamined assumptions. Structured techniques such as Delphi estimation reduce the influence of a dominant individual.

Analogous estimation compares the proposed work with a completed project or component. It is useful early, when detail is limited, but requires genuine similarity in complexity, technology, team capability, and context.

Parametric estimation uses a statistical relationship between a measurable size driver and effort or cost. For example, if historical data support a rate of 6 hours per function point, then:

The units must be consistent. If size is 120 function points and the rate is 6 hours per function point, estimated effort is 720 hours. The rate is valid only for a comparable technology, quality level, team, and development process.

Bottom-up estimation estimates work packages or activities and aggregates them. It is usually more defensible after scope and solution design are sufficiently understood, but it takes more time and can conceal omitted work if the WBS is incomplete.

Three-point estimation represents uncertainty using optimistic, most likely, and pessimistic values. The PERT expected estimate is:

where E is expected effort or duration, O is the optimistic estimate, M is the most likely estimate, and P is the pessimistic estimate. This weighted average assumes the most likely value is more representative than either extreme. It should not be treated as a guarantee or as a substitute for risk analysis.

For O = 4 days, M = 7 days, and P = 16 days:

A commonly used approximation of standard deviation for a beta-shaped three-point estimate is:

In this example, σ = 2 days. This approximation is useful for communicating uncertainty but depends on the assumed distribution and quality of the estimates.

Cost Estimation and Reserves

Direct project cost may include labor, contractors, cloud services, equipment, licenses, travel, and training. Indirect costs may include shared infrastructure or corporate support. A cost estimate should state whether it includes taxes, inflation, currency effects, and management reserves.

A contingency reserve is held for identified uncertainties or “known unknowns” within the approved scope. A management reserve is controlled by governance for unforeseen work and is generally not assigned to individual baseline activities. Reserves should not be used to conceal weak estimating or unauthorized scope.

A risk-based expected monetary value can be calculated as:

where pᵢ is the probability of risk event i, Iᵢ is its monetary impact, and the summation covers relevant events. EMV is an expectation across possible outcomes, not a prediction that each risk will occur and not a justification for ignoring correlated risks.

4. Building the Project Schedule

Scheduling transforms scope and estimates into a time-based model. The principal steps are:

1. Identify activities from work packages.
2. Define activity attributes, including owner, duration, assumptions, and required skills.
3. Sequence activities using logical dependencies.
4. Estimate durations using resource and calendar assumptions.
5. Develop the network schedule.
6. Apply resource calendars and resolve over-allocation.
7. Identify milestones and control points.
8. Validate the schedule with technical experts and stakeholders.
9. Approve the schedule baseline.

Dependencies

A finish-to-start relationship means the successor cannot start until the predecessor finishes. Other relationships include start-to-start, finish-to-finish, and start-to-finish, although the first is most common. Dependencies may be:

• Mandatory: inherent in the work, such as testing after a build.
• Discretionary: preferred sequencing, such as conducting a design review before configuration.
• External: controlled outside the project, such as a regulator’s approval.
• Internal: controlled within the project team.

Leads and lags should be used sparingly and documented. A negative lag or lead can obscure logic; explicit activities are often clearer.

Milestones have zero duration and represent significant events such as approved requirements, completion of testing, or production release. They are not substitutes for the work needed to reach them.

5. Critical-Path Method

The critical-path method (CPM) calculates the longest path through a network of activities. It determines the shortest possible project duration under stated logic, duration, calendar, and resource assumptions. The critical path is not necessarily the most important business work; it is the path with the least schedule flexibility.

For an activity with duration d:

• Early Start (ES) is the earliest time the activity can begin.
• Early Finish (EF) is the earliest time it can finish.
• Late Start (LS) is the latest time it can begin without delaying the project finish.
• Late Finish (LF) is the latest time it can finish without delaying the project finish.
• Total float is the delay available without delaying the project finish.

Using a time origin of zero:

For a finish-to-start network with no lag:

Backward calculation begins with the required project finish T:

and:

Total float is:

Activities with zero total float form at least one critical path. Multiple critical paths may exist, and the path can change when durations, dependencies, calendars, or resources change.

Worked CPM Example

Consider the following activities:

Forward pass:

• A: ES 0, EF 3.
• B: ES 3, EF 7.
• C: ES 3, EF 5.
• D: ES max(7, 5) = 7, EF 13.
• E: ES 13, EF 16.
• F: ES 16, EF 17.

The earliest project completion is 17 days. The controlling path is A–B–D–E–F, with duration 3 + 4 + 6 + 3 + 1 = 17 days. C is not critical because its completion at day 5 does not control D, which must wait until B finishes at day 7. C has two days of float under this network.

CPM assumes that activity durations and logic are sufficiently reliable, resources are available as modeled, and the schedule is not constrained by unmodeled events. It is deterministic; uncertain-duration projects should supplement CPM with scenario analysis or simulation.

6. Resource Allocation and Schedule Feasibility

A schedule without resource consideration is only a logical network. Resource planning identifies the people, roles, facilities, equipment, data, environments, and external services required. Each assignment should consider competence, availability, time zone, security clearance, workload, and organizational authority.

Resource loading shows demand over time. Resource leveling changes activity dates to resolve over-allocation, potentially extending the project. Resource smoothing adjusts work within available float without changing the critical completion date, where possible. Common responses to over-allocation include changing sequence, using a qualified alternative, splitting work, reducing non-value-adding activity, negotiating scope, outsourcing, or adding capacity.

Adding staff does not always shorten software work. Brooks’s Law observes that adding people to a late software project can make it later because new members require onboarding and increase communication. Parallelization is effective only when work is divisible, interfaces are stable, and coordination costs remain acceptable.

Resource decisions also have ethical consequences. Managers should not assume unpaid overtime, conceal burnout, assign work beyond competence, or allocate scarce specialists solely according to political influence. Sustainable workload, psychological safety, inclusion, and fair access to development opportunities are part of responsible planning.

7. Baselines, Change Control, and Schedule Governance

A baseline is an approved version of a plan used for comparison with actual performance. A project normally maintains integrated scope, schedule, and cost baselines. The baseline should identify version, approval authority, assumptions, and effective date.

Baseline control does not mean refusing all change. It means evaluating changes transparently. A change request should describe the reason, affected requirements, effort, cost, schedule impact, risks, benefits, and decision authority. Approved changes update the relevant baseline; rejected changes do not silently enter the plan.

Useful schedule indicators include milestone variance, forecast completion date, critical-path movement, float consumption, and overdue predecessor activities. A schedule that is green only because incomplete work has not been entered is not controlled. Status must be based on objective evidence such as accepted deliverables, test results, or verified completion criteria.

Earned value management integrates scope, schedule, and cost. Let:

• PV = planned value, the authorized budget for scheduled work;
• EV = earned value, the authorized budget for completed work;
• AC = actual cost of completed work.

Then:

Schedule variance (SV) and cost variance (CV) are monetary measures even though SV indicates schedule position. SPI below 1 indicates less earned value than planned at the status date; CPI below 1 indicates that less value has been earned per unit of actual cost. These indicators require a credible performance-measurement baseline and should not be applied mechanically to work whose completion cannot be objectively assessed.

8. Illustrative Case: Digital Claims Portal

Background

An insurance company authorizes an illustrative project to create a portal through which customers can submit claims, upload evidence, and track status. The strategic objective is to reduce call-center demand and improve customer visibility.

Problem

The sponsor initially requests delivery in four months with a fixed budget and a broad feature list. Stakeholders include customers, claims staff, legal and compliance teams, cybersecurity, operations, and an external identity provider. Early discussion reveals that identity verification, document retention, accessibility, and integration with the claims platform may control the schedule.

Analysis

The project team creates a charter with measurable objectives: support digital claim submission for three claim types, achieve agreed accessibility conformance, integrate with the existing claims system, and complete security and privacy approval before release. It explicitly excludes international claims, automated fraud decisions, and redesign of the core claims platform.

The WBS includes requirements, experience design, portal configuration, integration, document storage, security and privacy assessment, testing, training, deployment, and transition. A dependency map shows that the external identity provider and claims-platform interface must be confirmed before final integration design. Three-point estimates are used for integration and security activities because their uncertainty is high.

The first network schedule shows a 17-week logical duration, but resource loading identifies a single security architect assigned to three concurrent initiatives. The project manager negotiates a shared allocation, moves noncritical training preparation into available float, and obtains an independent security reviewer. The schedule baseline is approved at 18 weeks, including an authorized contingency reserve for integration uncertainty.

Approach and Outcome

The team uses a staged delivery model with short development iterations, but retains formal approval gates for architecture, privacy, security, and production readiness. Weekly reviews examine critical-path movement and unresolved dependencies. A change request to add automated fraud scoring is rejected for the initial release because it would expand scope, require new data governance, and threaten the approved date. It is recorded for a later product decision.

The portal enters production after completion of acceptance criteria and operational readiness checks. Benefits are measured after release through digital-submission rate, claim-processing cycle time, accessibility defects, and customer support contacts. The case demonstrates that disciplined planning is compatible with iterative delivery: flexibility is applied within a controlled scope and governance framework.

Learning Points

1. Clear exclusions protect the schedule from uncontrolled scope expansion.
2. External dependencies must be identified early rather than discovered during integration.
3. Resource feasibility can change a logically valid schedule.
4. Governance should distinguish an approved change from an informal request.
5. Benefits measurement continues after project delivery.

9. Contemporary Tools, AI, and Governance

Project-management platforms can connect WBS elements, requirements, repositories, test evidence, timesheets, risks, and dashboards. Digital traceability is valuable when links are meaningful rather than created merely to satisfy a reporting requirement. Automated schedule generation can expose missing dependencies, but tools cannot determine whether a business assumption is reasonable.

AI systems can assist with activity decomposition, estimate comparisons, risk-language analysis, dependency suggestions, and scenario generation. Their outputs must be treated as advisory. Training data may reflect historical bias, confidential information may be exposed through inappropriate prompts, and generated estimates may appear precise without empirical validity. Professional use requires human review, data classification, explainable assumptions, audit trails, access control, and validation against actual performance. AI should not be used to fabricate progress, conceal uncertainty, or make unreviewed decisions affecting employment, safety, privacy, or regulatory compliance.

Planning must also account for accessibility, data protection, cybersecurity, records retention, procurement rules, contractual obligations, and sector-specific regulation. A schedule that omits mandated review is not aggressive; it is incomplete.

10. Challenges and Best Practices

Common planning failures include premature commitment to dates, optimistic estimates, omission of non-development work, excessive task-level detail, weak dependency logic, treating milestones as activities, ignoring resource calendars, and allowing baseline drift. Another failure is confusing activity completion with outcome achievement: coding may be complete while the product remains untested, inaccessible, or operationally unsupported.

Best practices include:

• Plan from deliverables and acceptance criteria.
• Record assumptions and test them early.
• Use more than one estimation method for high-consequence work.
• Separate effort, duration, cost, and capacity.
• Model external dependencies explicitly.
• Include security, privacy, quality, training, deployment, and support work.
• Use ranges and confidence language rather than false precision.
• Validate the network with the people who perform the work.
• Protect the baseline while permitting governed change.
• Reforecast from evidence and preserve the history of approved decisions.
• Treat team sustainability and ethical allocation as planning constraints.

Chapter Summary

Project planning establishes the practical route from an authorized business need to an accepted product or service. The charter defines purpose, authority, scope boundaries, assumptions, constraints, stakeholders, and success criteria. A deliverable-oriented WBS decomposes total scope according to the 100 percent rule and provides the foundation for estimating and control.

Estimation must distinguish effort, duration, cost, and capacity. Expert judgment, analogous, parametric, bottom-up, and three-point approaches are complementary rather than mutually exclusive. PERT calculations can represent uncertainty, but estimates remain dependent on assumptions and evidence. Scheduling sequences activities, applies dependencies and calendars, and identifies milestones. CPM uses forward and backward passes to calculate early dates, late dates, float, and critical paths. Resource loading and leveling convert a logical schedule into a feasible one.

Approved scope, schedule, and cost baselines support transparent performance measurement and controlled change. Earned value indicators can integrate progress and cost when completion is objectively measured. Contemporary tools and AI can improve visibility and scenario analysis, but professional judgment, data governance, ethical conduct, and human accountability remain essential.

Key Terms

Project charter: Formal authorization describing a project’s purpose, authority, boundaries, and high-level commitments.

Product scope: Features, functions, services, and quality attributes of the intended solution.

Project scope: Work required to create and deliver the solution.

Deliverable: A verifiable product, service, result, or capability.

Work breakdown structure: Hierarchical decomposition of total project scope.

Work package: The lowest WBS component planned, estimated, assigned, and controlled.

100 percent rule: Principle that the WBS includes all authorized work and no unauthorized work.

Effort: Quantity of labor required to perform work.

Duration: Elapsed calendar time required for an activity.

Analogous estimation: Estimation based on comparison with similar completed work.

Parametric estimation: Estimation using a validated relationship between size and effort or cost.

Three-point estimation: Estimation using optimistic, most likely, and pessimistic values.

Dependency: Logical relationship between activities.

Milestone: Zero-duration event representing a significant achievement or decision.

Critical path: Longest logical path determining the shortest possible project duration.

Float: Time an activity can be delayed without delaying a defined completion point.

Resource leveling: Adjustment of dates or assignments to resolve resource over-allocation.

Baseline: Approved plan used for performance comparison and change control.

Contingency reserve: Reserve for identified uncertainties within approved scope.

Earned value: Budgeted value of work objectively completed.

Review Questions

Short Answer Questions

1. Distinguish product scope from project scope.
2. What is the purpose of a project charter?
3. Explain the 100 percent rule of the WBS.
4. Why are effort and duration not interchangeable?
5. What does zero total float indicate in CPM?

Long Answer Questions

1. Explain how a project manager can develop a deliverable-oriented WBS and WBS dictionary for an enterprise software project.
2. Compare expert judgment, analogous, parametric, bottom-up, and three-point estimation methods, including their limitations.
3. Describe the forward-pass and backward-pass procedures used in critical-path analysis.
4. Discuss how resource leveling, schedule baselines, and change control interact in a complex IT project.
5. Evaluate the benefits and governance risks of using AI-enabled tools for project estimation and scheduling.

Analytical / Application Questions

1. A project contains two parallel activities of 5 and 8 days, followed by a 4-day integration activity that requires both to finish. Calculate the earliest completion time and identify the controlling branch. State your assumptions.
2. A team estimates a work package at O = 6 days, M = 10 days, and P = 20 days. Calculate the PERT expected duration and approximate standard deviation, then explain how the result should be used in planning.
3. A sponsor requests a new feature two weeks before release while retaining the original date and budget. Construct a change-impact analysis covering scope, dependencies, resources, quality, risk, governance, and possible decisions.

Multiple Choice Questions with Answers

Question 1

Which artifact formally authorizes a project and establishes high-level authority?

A. Project charter

B. Issue log

C. Resource histogram

D. Test script

Correct Answer: A. Project charter

Question 2

What does the 100 percent rule require of a work breakdown structure?

A. Every activity must take one day

B. All authorized project work must be included, and no unauthorized work added

C. Every task must have exactly one resource

D. All work must be completed before scheduling begins

Correct Answer: B. All authorized project work must be included, and no unauthorized work added

Question 3

A task has O = 4 days, M = 7 days, and P = 16 days. Using PERT, what is its expected duration?

A. 6 days

B. 7 days

C. 8 days

D. 9 days

Correct Answer: C. 8 days

Question 4

Which statement best distinguishes effort from duration?

A. Effort is elapsed calendar time; duration is labor quantity

B. Effort is labor quantity; duration is elapsed calendar time

C. They are always identical

D. Effort applies only to costs

Correct Answer: B. Effort is labor quantity; duration is elapsed calendar time

Question 5

In CPM, which activities form a critical path?

A. Activities with the highest cost

B. Activities assigned to senior staff

C. Activities with zero total float on the longest path

D. Activities with the fewest predecessors

Correct Answer: C. Activities with zero total float on the longest path

Question 6

If an activity has ES = 5, EF = 12, LS = 8, and LF = 15, what is its total float?

A. 2 days

B. 3 days

C. 5 days

D. 7 days

Correct Answer: B. 3 days

Question 7

What is the primary purpose of resource leveling?

A. To remove all project risks

B. To resolve resource over-allocation, possibly by changing dates

C. To increase scope without cost

D. To convert effort directly into profit

Correct Answer: B. To resolve resource over-allocation, possibly by changing dates

Question 8

Which reserve is generally associated with identified uncertainties within approved scope?

A. Contingency reserve

B. Profit reserve

C. Unapproved scope reserve

D. Sunk-cost reserve

Correct Answer: A. Contingency reserve

Question 9

If EV = 80 and PV = 100, what is the schedule performance index?

A. 0.80

B. 1.25

C. 20

D. 180

Correct Answer: A. 0.80

Question 10

Why should AI-generated project estimates receive human review?

A. AI cannot display dates

B. AI outputs may reflect biased data, hidden assumptions, or unsupported precision

C. AI is unable to store any project information

D. AI always produces longer schedules than humans

Correct Answer: B. AI outputs may reflect biased data, hidden assumptions, or unsupported precision