Project management — concepts and methodologies

This chapter is a lesson independent of the product: it explains project management itself. Chapter 25 shows its equivalent in PORTWARE, and chapter 26 the planning and capacity screens.

Nothing described here claims to be "the right method". A method is right to the extent that it fits the shape of your work.

Four methods, four different questions

Method	The question it answers	The work it fits
Scrum	What do we commit to finishing in these two weeks?	Work whose scope is debated and advances by learning
Kanban	How many items are open right now and where are they stuck?	Continuously flowing work arriving from outside
Waterfall	Which work comes after which, on what date?	Work whose order is physically mandatory
Stage-Gate	Who approves moving on to the next stage?	Work that carries an investment decision and is expensive to reverse

All four can live in the same company: product development in Scrum, the support team in Kanban, field installation in Waterfall, a new product investment in Stage-Gate.

Flow: where work waits matters more than where it is worked on

The total time of an item splits in two: the time spent working on it and the time it waits in a queue. For most work the second is many times the first.

The conclusion is counter-intuitive: the way to speed up a team is usually not to work faster but to start fewer things at once.

Work-in-progress limit (WIP)

This is the idea at the centre of Kanban. An upper limit is set on how many items may be in a stage at the same time. When the limit is full no new work is started — one of the existing items is finished first.

The effect is twofold: work finishes sooner (because there is less switching) and the bottleneck becomes visible (because the stage whose limit is full is immediately obvious).

In a team with no limit everyone is busy and nothing gets finished. This is the most expensive form of mistaking busyness for productivity.

Cycle time and velocity

Cycle time: the time from an item's start to its finish. It measures the health of the flow.
Velocity: the amount of work a team finishes in a period. It measures capacity.

The two answer different questions and cannot replace each other. Cycle time means "how long does one item take to come out", velocity "how much work comes out in a period".

Estimation: why points, why not hours

The reason Scrum teams estimate work in story points instead of hours is this: people estimate absolute duration badly and relative size well. The answer to "how many hours will this take" is systematically wrong; the answer to "is this bigger or smaller than that" is surprisingly consistent.

A point is not an absolute duration. At the end of a period the relationship between points and elapsed time is revealed by measurement — the name of that relationship is velocity.

Planning in hours is not wrong; capacity calculation needs hours anyway (chapter 26). What is wrong is trying to do both with the same figure.

Capacity is a division

The whole of capacity management is a single fraction:

load = committed work time / available working time

The denominator is the person's contractual working calendar. The numerator comes from three sources: planned work, approved leave and meetings in the calendar.

Two conclusions follow, and both are violated all the time in practice:

Work with no time window cannot enter capacity. If it is not known when a piece of work will be done, it is not known which week's load it belongs to either. A deadline is not a window — it says when the work will finish, not when it will be done.
Work with no duration cannot enter capacity either. Work that has a window but no written number of hours does not increase the numerator.

A scheduling constraint is not the same as a relation

Links that can be made between two items fall into two different classes, and mixing them up breaks schedules:

Scheduling constraint: "B cannot start before A finishes." This is a date rule; the critical path calculation reads it, and if A is late B moves.
Information link: "this relates to that", "this is a duplicate of that", "this caused that". This is not a date rule.

A system that treats a "relates to" link like a scheduling constraint moves real deadlines at a moment nobody wanted. That is why a good tool keeps the two apart and the critical path reads only the first.

A milestone is not the same as a release

A milestone is a date: a moment marked within the project.
A release is a published deliverable: something with its own status, whose target date and actual release date are kept separately.

A single date field leaves the question "are we late?" unanswered. When the target date and the actual date are kept separately, the question answers itself.

Summary of this chapter

The four methods answer four different questions; they live together in the same company.
Most of an item's time is spent in a queue; the way to speed up is usually to start fewer things.
Cycle time measures flow, velocity measures capacity; velocity is not a performance grade.
Capacity is a division; work with no window or duration cannot enter the numerator and is not mixed into the average.
Relation links are not scheduling constraints; a release is a deliverable, not a date.