If you check your bank account, it's not because you want to see just the numbers; I assume that you are not a kind of number fetishist that gets his or her kicks from watching numbers on a piece of paper (if you are…. then these are especially for you: 633677290…. oooh, aaaah). With the state of your finance you can determine how much you still can buy, how much you can give away to charity, etc. It provides you info over how much you can satisfy your own stakes.

The project progress provides information for the stakeholders that issued requirements to the process, to the way the project is conducted. Although I encountered some financial people that come very close to fetishism, keep in mind during this entire section that it's not the numbers that are important, but the impact of the numbers on the stakes.

Road to nowhere

To determine the progress, in time and in money, you got to have some roadmap. For time this is a project schedule and for money this is a budget.

The project schedule itself is not that difficult; it's a list of tasks, start and end date, who will perform the task, what will be the effort. Getting the schedule is something else, but, as everything in this course, no rocket science. A good starting point for creating the schedule is the project strategy you created during the intake. You have some phases and you need now to fill in these phases with some details. And that's where the WBS comes in.

WBS does not stand for "What a BS", well … sometimes it does, but normally it's a "work breakdown structure". You take a piece of paper and you set on top of it the tasks you must perform. Under it you write the tasks that make up this higher task, it's actually a more detailed description of the first task. And you can do this for every other task, resulting in a nice tree shape structure of tasks.

How far in detail should you go? There is no definitive answer to this question. Enough detailed to provide you with insight in the tasks that have to be performed, but not to the level of tasks that will take 2 hours to perform. That kind of detail is too much, it can even get the flexibility out of your approach, if during the project you find out you forgot something, or things are not going as you anticipated. This is a mistake encouraged by some stakeholders who are happy to see a WBS of 15 pages, thinking that the project manager has anticipated everything.

I read somewhere this comment about a schedule of a project manager:

My personal rule of thumb is this: If I can't fit the key tasks and milestones on a regular size sheet of paper and still read it, it's time to delegate part of the planning.

Milestones or Millstones?

With the phases and the WBS you can construct a list of tasks to be performed. Picking the dates for the tasks is an estimation problem, which we will handle later on. But how do you handle a list of tasks? How do you control the schedule? The answer is to have milestones.

Milestones are events with a specific date in the schedule, that function like a kind of beacon. They represent a state of the project that is unambiguous. You are there, or you are not there. You know those computer games where you have to race and pass all these checkpoints within a certain time frame? In a project we call them milestones.

Actually, all there is to say about milestones is in the following quote from Brooks:

For picking the milestones there is only one relevant rule. Milestones must be concrete, specific, measurable events, defined with knife-edge sharpness. Coding, for a counterexample, is "90 percent finished" for half of the total coding time. Debugging is "99 percent complete" most of the time. "Planning complete" is an event one can proclaim almost at will.
Concrete milestones on the other hand, are 100-percent events. "Specifications signed by architects and implementers," "source coding 100 percent complete, keypunched, entered into disk library", "debugged version passes all test cases". These concrete milestones demark the vague phases of planning, coding, debugging. (The Mythical Man-Month: Essays on Software Engineering, 20th Anniversary Edition)