Project management basics: scope, schedule, budget and the critical path

Plenty of people run projects without the job title: a website rebuild, a warehouse move, a product launch. The same few tools help in each case. You need a clear scope, a schedule that shows which tasks hold up the others, a budget tied to the work, and a list of what could go wrong.

This guide explains the triple constraint, the work breakdown structure, Gantt charts, the critical path method and the risk register, with one worked example running through the article.

What a project is, and the triple constraint

The Association for Project Management (APM) defines project management as “the application of processes, methods, skills, knowledge and experience to achieve specific project objectives”. What separates a project from ongoing work is that it has a finite timespan and budget.

The triple constraint, also called the project management triangle, links three things: scope (the work needed to produce the result), time and cost. Change one and at least one of the others usually has to move. Add features and you need more time or money. Cut the budget without cutting scope and quality tends to suffer. The idea is often traced to Martin Barnes, who taught a course using a triangle of cost, time and quality in 1969.

The triangle is a simplification. Critics point out that hitting scope, time and cost does not guarantee the project was worth doing, because it leaves out user satisfaction and stakeholder impact. Use it to frame trade-off conversations, not as your only measure of success.

Define scope with a work breakdown structure

A work breakdown structure (WBS) splits the project into smaller pieces until each one can be estimated, scheduled and assigned. Eric Norman, in a paper for the Project Management Institute, describes it as “a deliverable-oriented, hierarchical grouping of the work”, following the PMI’s PMBOK Guide.

Norman’s main guidance:

• Describe outcomes, not activities. Use nouns (“product photography”) rather than verbs (“take photos”).
• Follow the 100% rule. The WBS must include all the work in scope, including project management itself, and each level must contain all of the work of its parent, with nothing missing and nothing extra.
• Have at least two levels.
• Build the WBS before the schedule. A task list typed into scheduling software is not a WBS.

He also recommends a WBS dictionary that records, for each element, an owner, what “finished” means and how it will be checked. Once the scope baseline is agreed, changes should go through change control instead of being added quietly.

Build the schedule and find the critical path

To build a schedule, list the activities needed for each deliverable, estimate how long each takes, and record the dependencies. The University of Essex project glossary defines a dependency as a link that determines when one task can start or finish based on another.

The critical path method (CPM) then finds the longest chain of dependent activities through the project. CPM was developed in the late 1950s by Morgan Walker of DuPont and James Kelley of Remington Rand. The critical path sets the shortest possible project duration. Any delay to an activity on it delays the whole project.

Activities off the critical path have float (also called slack): the time they can slip without moving the end date. Critical activities have zero float.

An example (illustration only). A small brand is launching a new online shop:

There are three paths from start to finish:

• A, B, E, F: 3 + 5 + 3 + 2 = 13 days
• A, C, E, F: 3 + 4 + 3 + 2 = 12 days
• A, D, E, F: 3 + 10 + 3 + 2 = 18 days

The critical path is A, D, E, F, so the launch needs at least 18 days. Photography has 5 days of float (18 minus 13) and descriptions have 6. If the photographer is two days late, the launch date holds. If the site build slips two days, the launch slips two days.

To shorten a project, you work on the critical path. Fast-tracking means running activities in parallel that were planned in sequence. Crashing means adding resources to critical activities, usually at extra cost. Speeding up photography here would change nothing. Watch for near-critical paths too: shorten D by six days and the photography path becomes critical.

Show it on a Gantt chart

A Gantt chart is a bar chart of the schedule, with activities down the side and time along the bottom. Each bar’s length shows the activity’s duration. Modern versions also show dependencies and progress. The format is named after Henry Gantt, who designed his version around 1910 to 1915, although Karol Adamiecki had developed a similar chart in 1896.

Gantt charts are popular because almost anyone can read them without training. Their weakness is that on large projects, the dependency lines become cluttered and the critical path is hard to see. Highlight critical activities in a different colour, and keep the chart at a level of detail the audience needs. A sponsor needs milestones. The team needs tasks.

Set and track the budget

Essex’s glossary describes the WBS as splitting deliverables into work packages that can be scheduled, costed and assigned resources. That is the simplest route to a budget: estimate the cost of each work package (people’s time, suppliers, tools, materials) and add them up.

For the shop launch (illustration only), the budget might list freelance photography, the site platform’s fees, a developer’s days and the team’s own time. Add a contingency line for known uncertainty and state what it covers. Once the budget is agreed, it becomes the baseline you report against. Each week, compare spend to date with the value of the work completed, not just with the calendar. Spending half the budget at the halfway date means little if only a third of the work is done.

Keep a risk register

Essex defines a risk register as a log of identified risks that records each risk’s owner, status, possible mitigation and history. It defines an issue as a risk that is almost certain to happen or already has, and that will harm delivery if left unresolved.

The critical path helps you rank risks. A delay on a critical activity costs the whole project time. The same delay on an activity with float may cost nothing. Review the register at a set interval, close risks that have passed and move risks that have happened onto the issues list.

Common mistakes, and when to use something else

• Scheduling before scoping. Build the WBS first, then the schedule.
• Ignoring dependencies. A list of tasks with dates is not a plan if it does not show what waits for what.
• Single-point estimates with no buffer. Note your uncertainty and hold contingency.
• A risk register written once and never opened again.
• Adding scope without moving time or cost. The triangle catches up with you.

These tools suit projects where the outcome can be defined up front: an event, a fit-out, a migration, a launch. Where requirements are expected to change as you learn, such as building a new product with unclear demand, an iterative approach with short cycles may serve better. Even then, a simple scope list, a view of dependencies and a risk register remain useful.