10 minutes estimated reading time.

Key takeaways:

• A work breakdown structure divides project scope into manageable deliverables and work packages.
• Time planning starts when each work package is converted into activities.
• Smaller activities are easier to estimate, sequence, assign, and track.
• Dependencies determine the correct order of work.
• Resource availability affects task duration and project completion dates.
• Milestones and the critical path help teams monitor schedule performance.
• The WBS and project schedule should stay connected throughout delivery.

Introduction

Every project needs a realistic answer to one question: how long will the work take?

A deadline may appear simple in a contract or project brief. Yet that date depends on many smaller activities, approvals, resources, and dependencies. This is why integrating time planning into the WBS is useful.

A work breakdown structure, or WBS, divides the total project scope into smaller deliverables and work packages. The project team can then estimate each item, place activities in the correct order, assign resources, and build a practical schedule.

Without a WBS, teams often rely on broad guesses. For example, a manager may estimate that a website project will take three months but overlook user testing, content approval, data migration, or staff training.

A WBS makes hidden work visible. Once the team can see the work, it can plan time with greater accuracy.

What Is a Work Breakdown Structure?

A work breakdown structure is a hierarchical breakdown of the total project scope. At the highest level, it shows the complete project. Below that, it lists major deliverables, smaller components, and detailed work packages.

For example, a staff training project may include:

• Training needs analysis
• Course design
• Learning material development
• Trainer preparation
• Program delivery
• Assessment
• Project review

The course design deliverable may then include:

• Define learning outcomes
• Develop the course structure
• Select learning activities
• Prepare assessment requirements
• Review the design
• Obtain approval

The WBS starts with scope, not dates. Once the scope is clear, the team can convert work packages into scheduled activities.

Why Time Planning Should Begin with the WBS

Time planning becomes unreliable when it starts with a deadline rather than the work. A sponsor may request project completion within eight weeks. The project manager could divide that period into broad phases, but this approach may miss important tasks or allow too little time for reviews and approvals.

A stronger process follows these steps:

1. Confirm the project scope.
2. Identify major deliverables.
3. Break deliverables into work packages.
4. Define the activities needed for each package.
5. Estimate activity durations.
6. Identify dependencies.
7. Assign resources.
8. Build and review the project schedule.

This process connects project scope directly to time.

Planning question	How the WBS helps
What work must be completed?	It identifies deliverables and work packages.
How long will it take?	It provides smaller items to estimate.
What must happen first?	It exposes task dependencies.
Who will complete the work?	It supports resource assignment.
How will progress be measured?	It creates clear tracking points.

How Work Packages Improve Time Estimates

A work package is a manageable component at the lowest practical level of the WBS. It should be detailed enough to estimate, assign, and track. Yet it should not be so small that administration becomes difficult.

Consider the work package “prepare employee handbook”. This may still be too broad for a reliable estimate. The team could divide it into:

• Review current policies
• Confirm legal requirements
• Draft handbook sections
• Conduct management review
• Revise the draft
• Obtain final approval
• Format and publish the handbook

Each activity is easier to estimate than the complete handbook.

Activity	Estimated duration
Review current policies	3 days
Confirm requirements	2 days
Draft handbook sections	7 days
Conduct review	4 days
Revise the draft	3 days
Obtain approval	2 days
Format and publish	2 days

The project duration may not equal the total of all activities. Some tasks can overlap, while others depend on earlier work. Therefore, time estimates must be combined with task sequencing.

Step 1: Confirm the Project Scope

Before building the WBS, confirm what the project must deliver. The project team should understand:

• Project objectives
• Required deliverables
• Quality standards
• Exclusions
• Constraints
• Assumptions
• Approval requirements
• Completion criteria

For example, a project to introduce accounting software may include system setup, data migration, user testing, staff training, procedure updates, and post-launch support. If the WBS only includes system setup, the schedule will underestimate the true duration.

Step 2: Identify Major Deliverables

Next, divide the project into major deliverables. Deliverables should describe results rather than broad actions.

Weak label	Clear deliverable
Work on training	Approved training program
Handle software	Configured software system
Do testing	Completed user acceptance testing
Finish documents	Approved operating procedures

Clear deliverables help the team understand what completion looks like. They also create natural schedule milestones.

Step 3: Break Deliverables into Work Packages

Break each deliverable into smaller components that can be estimated and assigned. Ask:

• What must be produced?
• What work is required?
• Can the work be estimated?
• Can one person or team own it?
• Can progress be measured?
• Are the completion criteria clear?

For example, “launch new service” may be too broad. It could be divided into:

• Complete readiness review
• Confirm staff availability
• Finalise customer information
• Activate service systems
• Conduct launch communication
• Monitor first-week performance

Step 4: Convert Work Packages into Activities

The WBS focuses on deliverables, while the schedule focuses on activities. Therefore, the team must identify the actions needed to complete each work package.

For example, the work package “approved brochure” may require:

• Prepare content outline
• Draft copy
• Select images
• Complete design
• Conduct compliance review
• Obtain feedback
• Revise and approve the final version

Each activity should connect to a WBS code.

WBS code	Work package	Activity
3.2	Approved brochure	Prepare content outline
3.2	Approved brochure	Draft copy
3.2	Approved brochure	Complete design
3.2	Approved brochure	Obtain approval

This connection helps prevent missing work and uncontrolled additions.

Step 5: Estimate Activity Durations

Once activities are clear, estimate how long each one will take. Consider:

• Amount of effort
• Staff availability
• Skill and experience
• Review periods
• Approval periods
• Supplier lead times
• Public holidays
• Planned leave
• Technical complexity
• Risk and uncertainty

Useful estimating methods include:

Expert judgement

Ask people with direct experience to estimate the work.

Analogous estimating

Use the duration of a similar past activity.

Parametric estimating

Use a measurable rate. For example, if a team reviews 20 files per day, reviewing 200 files may take 10 working days.

Three-point estimating

Prepare optimistic, most likely, and pessimistic estimates.

Estimate	Duration
Optimistic	4 days
Most likely	7 days
Pessimistic	12 days

Bottom-up estimating

Estimate each detailed activity and combine the results. Bottom-up estimating often produces stronger results because it starts with defined work.

Step 6: Identify Task Dependencies

Activities rarely happen in isolation. Some tasks must finish before others begin, while other tasks can run at the same time.

Relationship	Meaning	Example
Finish-to-start	One task must finish before the next begins.	Drafting finishes before review starts.
Start-to-start	One task must start before another starts.	Data collection starts before data checking.
Finish-to-finish	One task must finish before another finishes.	Testing cannot finish before corrections finish.
Start-to-finish	One task must start before another finishes.	A new support team starts before the old team finishes.

Finish-to-start is the most common relationship. Dependencies help the project manager create a realistic sequence and identify delays that may affect later work.

Step 7: Include Leads, Lags, and Waiting Time

A lead allows a later task to start before an earlier task fully finishes. For example, graphic design may start after the first report sections are approved, even if the full report is still being written.

A lag creates a waiting period. Examples include:

• Approval waiting time
• Supplier delivery time
• Recruitment advertising periods
• Legal review periods
• Stakeholder response time
• System processing time

Waiting time may involve no active work, but it still affects the completion date.

Step 8: Assign Resources

Task duration depends on who is available to complete the work. Consider:

• Required skills
• Staff capacity
• Competing work
• Equipment needs
• Contractor availability
• Supplier availability
• Budget limits

A technical specialist may be assigned to system configuration, testing, training review, and launch support. Each estimate may look reasonable, but the total schedule may still be impossible. Resource levelling can resolve this issue by changing task dates to match actual availability.

Step 9: Build the Project Schedule

After estimating durations, identifying dependencies, and assigning resources, the team can build the schedule. The schedule may include:

• Activity name
• WBS code
• Start date
• Finish date
• Duration
• Assigned resource
• Dependency
• Milestone
• Progress status

WBS code	Activity	Duration	Dependency
1.1	Confirm requirements	3 days	None
1.2	Approve requirements	2 days	1.1
2.1	Prepare design	5 days	1.2
2.2	Review design	3 days	2.1
3.1	Complete build	10 days	2.2
3.2	Conduct testing	5 days	3.1
3.3	Correct defects	4 days	3.2
4.1	Obtain approval	2 days	3.3
4.2	Launch	1 day	4.1

Step 10: Identify the Critical Path

The critical path is the longest sequence of dependent activities that determines the earliest project completion date. A delay to a critical-path activity may delay the whole project.

For example, a system launch may depend on:

1. Requirements approval
2. System design
3. Configuration
4. Testing
5. Defect correction
6. Final approval
7. Launch

Activities outside the critical path may have float. Float is the amount of time a task can move without delaying a milestone or the final completion date.

Common WBS Time-Planning Mistakes

Making the WBS too broad

Labels such as “develop system” do not provide enough detail for sound estimates.

Adding too much detail

Tracking every minor action creates unnecessary administration.

Estimating without team input

The people completing the work often provide the most realistic estimates.

Ignoring approval time

A document may take two days to write but ten days to approve.

Confusing effort with duration

Effort is the active work required. Duration is the total elapsed time.

Ignoring resource conflicts

One person cannot complete several full-time tasks at the same time.

Failing to update the WBS

Scope changes should lead to updates in both the WBS and the schedule.

How to Track Time Against the WBS

The WBS remains useful during delivery. Track:

• Planned and actual dates
• Percentage complete
• Remaining duration
• Delayed activities
• Missed milestones
• Resource issues
• Approved changes

WBS code	Planned finish	Forecast finish	Status
2.1	8 May	8 May	Complete
2.2	10 May	12 May	Delayed
3.1	24 May	26 May	At risk
3.2	22 May	22 May	On track

This structure helps the project manager explain where delays have occurred and what effect they may have.

Conclusion

Integrating time planning into the WBS turns project scope into a practical delivery plan. The WBS identifies deliverables and breaks them into manageable work packages. The team can then define activities, estimate durations, identify dependencies, assign resources, and build the schedule.

This process improves time estimates, task sequencing, resource planning, and schedule control. When the WBS and schedule remain connected, project teams can identify delays earlier, explain their effects more clearly, and respond to change with greater confidence.

Frequently Asked Questions

1. What is the purpose of integrating time planning into the WBS?

It connects project scope with the project schedule. The team can estimate smaller pieces of work instead of guessing the total project duration. This makes the schedule easier to review, track, and update.

2. Does a WBS include start and finish dates?

A traditional WBS focuses on deliverables and work packages. Start and finish dates usually appear in the project schedule. The two should remain linked through WBS codes or activity names.

3. How detailed should a WBS be?

It should be detailed enough to estimate duration, assign responsibility, and measure completion. It should not be so detailed that tracking becomes difficult. The right level depends on project size, risk, and complexity.

4. Who should estimate activity durations?

The people with direct knowledge of the work should contribute. This may include team members, technical specialists, suppliers, contractors, and experienced managers. Their input often produces more realistic estimates.

5. What happens when a work package changes?

The team should review the effect on activities, dependencies, resources, milestones, cost, and risk. The project manager should then update both the WBS and the schedule. This keeps the plan consistent with the approved scope.