Workflow: WBS → sequence (network) → durations → critical path → Gantt → compress → track (EV, velocity, burn-down).

A real schedule: hundreds of WBS rows with bars over time. This is where the chapter ends up.

These four words are often mixed up, but each adds something. Planning lists what has to happen, estimating sizes it, scheduling puts dates on it, and tracking checks whether reality is following along.

Each question depends on the last. You can’t size work you haven’t listed, and you can’t set dates before you know what depends on what. So a WBS comes first.

A schedule isn’t a separate activity but the result of all the earlier work. It’s also never really finished, as approved changes and risks keep altering it, which is why iterative and continuous matter.

If you assume a server is available and it isn’t, your schedule breaks. A constraint is different: it’s a real limit, such as only using in-house staff. Knowing which is which tells you what could change.

Why does the risk register matter for dates? Each risky task may need extra time or a backup. So a schedule that ignores the risk register is too optimistic.

If it isn’t in the WBS, nobody will do it and nobody budgeted for it. So it’s more than a to-do list: it’s the agreed picture of all the work, with clear owners.

Seen again Ch 1.2, slide 39: Scope decomposed with a WBS

Seen again Ch 5, slide 21: RBS is analogous to WBS

Numbering shows the hierarchy: 4.2.3 is under 4.2, which is under 4.0.

A process WBS asks “what steps do we go through?”, so it suits a PM tracking the work. It’s organized by activities such as requirements and testing.

A product WBS asks “what parts does it have?”, so it suits an engineering manager thinking about components such as the database.

Hybrid = phases on top, components inside. Common.

Short labels are easier to scan and discuss. Branches may end at different levels because some work needs more detail, and you shouldn’t plan beyond what you can actually manage.

This is the level where you can assign, budget and check the work. If you can’t say clearly when a work package is done, it’s not defined well enough.

Too big and you can’t see trouble until it’s late, and too small and you’re micromanaging. One-to-two gives a size that’s easy to estimate and easy to track.

Memory trick 8/80: no package under 8 hours (micromanaging) or over 80 hours (invisible).

A WBS has to match how you’ll actually work. Iterative work loops, but a list can’t, so you “straighten” it by writing out each round. Operations usually aren’t included, as they happen after the project.

Choose by what you know. Clear problem? Work from the top. Similar past project? Reuse its structure. Still unclear? Rolling wave details near-term work now, and later work later.

You can only break something down from the top if you understand it. So top-down suits a familiar problem. On something new, you’d miss parts without noticing.

Starting from all the small tasks gives you lots of detail, but you need to know them first. So bottom-up needs more complete requirements and takes longer.

Why start from nothing if a similar project exists? A template saves time and reminds you of tasks you’d forget. But it only helps if that project is really comparable.

Brainstorming catches tasks that a formal breakdown misses. Bring in those doing the work, since they know what’s really involved and commit more to a plan they helped build.

Almost everything hangs off the WBS: you cost it, schedule it and check risks against it. So a poor WBS spreads problems into all of them, which is why it’s worth getting right.

You won’t schedule or budget for work you forgot, so it appears later as a surprise. That’s why what’s missing hurts most. Stop splitting once you can estimate a piece with confidence.

Having a list of tasks doesn’t make a schedule. Network analysis works out the dates, and each method answers a different question, such as “what can’t slip?” or “what if this is late?”.

The precedence diagram shows what must happen before what. Seeing that lets you spot which tasks could run in parallel, and that’s how you find ways to shorten the schedule.

Why the longest path? Because the project can’t finish until its longest chain of work is done. Every task on it has no spare time, so any delay there moves the end date.

A milestone takes no time and uses no resources. It’s a checkpoint marking that something got done, such as a completed phase.

Trap The critical path is the LONGEST path, not the shortest. Its length is the SHORTEST possible project time.

This is the input for the network diagram, so errors spread from here. Ask the team, since they know what really depends on what. Risky tasks get extra time here, rather than hidden later.

The right side of the original slide recaps the four RUP phases (see Chapter 4 slides 26–30).

Seen again Ch 4, slide 26: Iterative SDLC phases

Draw: one node per activity, arrows from each predecessor. D has two predecessors (B, C), so two arrows enter D.

Tip Exam drawing: add Start and End nodes, write duration on each node, and check every activity in the table appears once.

A single estimate pretends you know how long something takes. PERT uses three and weights the likely one, which reflects real uncertainty better, especially on new work.

Instructor Labels over the formula: optimistic, most likely, pessimistic.

Seen again Ch 6, slide 34: Three-point estimating

(2 + 4×4 + 5) / 6 = 23/6 ≈ 3.8.

Here the circles mark points in time and the arrows carry the work. A dummy arrow takes no time, and only shows that one thing must wait for another.

σ tells you how uncertain the estimate is. A task estimated at 4–6 days is much safer than one estimated at 1–20, even if they share the same expected time.

Slack is how much a task can slip without moving the end date. It’s worked out by comparing the latest and earliest finish.

If there’s no spare time, any delay moves the whole project. So zero slack is how you recognize a critical task.

A task can’t start until everything before it is done, which is why you take the largest incoming finish time. Going forward tells you the earliest date the project can end.

Going back from the end, a task must finish before its earliest successor needs to start, so you take the smallest. This tells you how late each task may be, without delaying the end.

Both are spare time, but they differ in who’s affected. Using free float bothers nobody, while using up total float can squeeze later tasks, though the end date holds.

Memory trick Forward = MAX of incoming EFs. Backward = MIN of outgoing LSs.

A-C-D-E = 9 + 7 + 11 + 8 = 35 (C is 7 in the table on slide 37). A-B-D-E = 33, so only B has slack (2).

Read the table: B ES 9 / EF 14 / LS 11 / LF 16 → slack 2. All others 0 → critical path A-C-D-E.

It works because you can read progress at a glance. But all those bars say little about what’s really critical, and with thousands of tasks the chart becomes unreadable. Hence its low information density.

A big chart of mostly empty space shows few facts per page. That’s fine for a small project, but a large one needs network analysis as well.

Bars = activities; % shown inside = progress.

Anyone can read a bar chart, and bars are easy to move. That’s why it’s so widely used for reporting, including to non-technical people.

A bar shows when, not why. So moving one task may affect others without the chart showing it. That’s the risk of relying on a Gantt chart alone.

Answer: B → C → E = 3 + 9 + 4 = 16 days is critical. A (9) and D have slack.

Trap A Gantt alone hides the critical path. Draw the network.

CPM assumes people are always available, which isn’t realistic. CCM asks “is the person actually free?”, so the longest chain may change once you consider resources.

Trap CPM ignores resources. CCM includes them.

CCM example: mobile app, prototype due in month 4.

Rather than padding each task, it collects spare time in one buffer at the end. People can’t quietly use it up on each task, so everyone can see how much protection is left.

Think of a project buffer as the protection at the end. A delay on the critical chain eats into it, and watching how fast it shrinks tells you how much trouble you’re in.

A resource buffer isn’t time but a warning: “your expert is needed in two weeks.” This helps stop a late person from delaying critical work.

You don’t know what will go wrong, but you can test what happens if it does. What-if shows which delays matter and which don’t, so you know where to prepare.

A schedule may need one person to do three tasks at once, which can’t happen. Leveling fixes that by shifting work, and shifting a task can even change which path is critical.

Each is a different way of removing a clash. If two tasks want one person, you can delay one, split it, or move the person from a non-critical task, as those have time to spare.

Lead = successor starts EARLY (overlap). Lag = forced WAIT between tasks.

A plan assuming work every day will fail if the client’s site closes in summer. Calendars add these real limits, and they’re easy to forget until they stop the work.

Different people need different views. A network diagram shows the logic, a Gantt chart shows dates, and a milestone chart gives executives only the key points.

Instructor Circled: network diagrams, Gantt charts, milestone charts.

Think of the four levers: do less, add people, do things at once, or do something else instead. Each has a cost, so the question is which one fits. Reducing scope is often the cheapest.

Instructor Next to the items: “less outputs”, “more people”, “lead”.

More people on critical tasks shortens the time, but it costs more. Only critical tasks are worth crashing, since speeding up others doesn’t move the end date. That’s why you analyze the trade-offs.

Overlapping tasks saves time without adding people. But the second task may start on unfinished work, so you might have to redo it, and that’s the risk you’re accepting.

Compression has limits. Even with money or overlap, past about 25% you’ll mostly get chaos, as the work needs a minimum amount of time.

Memory trick Crashing costs MONEY. Fast-tracking costs RISK.

Six people for a month isn’t the same as one person for six months, because they spend time talking to each other. That’s why the man-month is called a myth: it counts effort, not progress.

New people need training from those already busy, and every addition means more communication. So in the short term, adding people to a late project slows it further. That’s Brooks’s Law.

Each new person adds a link to everyone else, so communication grows much faster than the team. Going from 7 to 14 people takes you from 21 to 91 channels.

Twice the people doesn’t give half the time, since coordination has to fit in somewhere. That’s why the job takes 7 months rather than 6.

Seen again Ch 3, slide 34: Large teams and communication paths

Testing comes last, so every earlier delay takes time from it. It’s also where the surprises come out, at the worst possible moment. So planning more test time is the fix.

Nobody notices one lost day, so nobody acts, and those days add up. So clear, checkable milestones matter, as does telling the truth about status, rather than saying what people want to hear.

Why does sequencing come before resources? First work out what’s logically possible, then see who can do it. Otherwise, you may mistake a staffing limit for a real dependency.

Now you can test the schedule. Calculate the critical path first, then try scenarios, then fix overloads. Compression comes last, because you only compress what you need to.

A “+” group is rolled up to hide detail.

Most tasks simply wait for the previous one to finish. Other links let tasks overlap in a controlled way, such as coding and integration finishing together. That’s what Finish-to-Finish means.

Starting a task 5 days before its predecessor ends is a lead. Tasks now overlap, which saves 5 days in total, and it’s the same as fast-tracking those two tasks.

Two tasks might each look fine, while the same person is booked for 16 hours that day. A resource graph shows this at once, as well as who has spare time.

Finishing the easy, early tasks makes a project look further along than it is, because the hard work is still ahead. Don’t count tasks, or you’ll get a false sense of progress.

Effort-weighted: 660 of 2,100 hours = 31.4%, not ~50%.

PV = planned budget of scheduled work. EV = budget of work actually done. AC = actual cost.

CPI = EV/AC, SPI = EV/PV. Below 1 = bad (over budget / behind).

Instructor “They might give you some values and you need to calculate.”

Memory trick EV is always on top: CPI = EV/AC, SPI = EV/PV, CV = EV−AC, SV = EV−PV.

Setting up early gives you something to compare against. You can’t say you’re behind unless you defined the plan first, and that’s what the setup steps are for.

Work through the logic. The task is done, so you’ve earned all its value and you’re on schedule. But it cost 120 for 100 of value, so CPI is below 1: on time, but over budget.

Instructor Next to the budget: “100/1000 × budget”; AC 120 circled.

Giving credit only for finished work stops the “90% done for weeks” problem. It only works when tasks are small, and that’s why you break big ones down. Fuzzy milestones can’t be checked.

Rather than guessing, look at what the team actually finished. Velocity is real evidence of what they can take on, so planning the next sprint is less of a guess.

Seen again Ch 4, slide 59: Velocity in Scrum

Axes: Y = work remaining (points/hours), X = time (days/sprints).

Actual line above the ideal line = behind schedule; below = ahead.

It’s one activity seen at different stages, so each step feeds the next. Tracking results improve your next estimate, which is why they’re a continuum and not a one-way list.