There are four key variables that control a project: Resources, Scope, Quality, and Time.

Therefore there are four key questions for a project review:

	1. Do you have the resources you assumed when you estimated?

Measures resources.  If they don't match assumptions, this is an issue for management to deal with.  

	2. What percentage of stories do you have completed?

Measures scope.  We have stories on cards for the entire effort.  These may be detailed or macro.  If we're 3/4 of the way through the schedule, we should be 3/4 through the cards.

	3. What are the scores on the functional tests?

Measures quality.  Number of tests should be increasing, scores should be improving.

	4. Have you been working any overtime?

Measures time.  Overtime is man's way of trying to make more time.  It doesn't work.  We may well work more than forty hours, and that's OK.  We don't call it overtime unless it hurts.
    *----------------
A C3 project review follows this pattern.  

First we describe our resource situation.  At our last one, our immediate management knew we were under-resourced, but the CIO apparently did not.  The problem got attention.

Then we describe the amount of functionality we have completed.  We describe and explain any deviations.  Four main causes of deviations:

	* a set of stories takes longer (or shorter) than we thought. (see NoSecondChance)
	* resources were different from planned.
	* stories are not complete 
	* functional tests missing

We then assess the health of the code by showing how we are doing on functional tests.  A graph does this nicely.  If you're screwing up quality, your functional tests, or lack of them, will show it.

We then assess the health of the developers by answering the overtime question.  If we're killing ourselves, it is an indication that we are doing something wrong and need to change our process.
    *----------------
Management still might ask us to go faster.  We explain calmly that we are presently producing engineering days at rate R, and that we have P people and N cards.  There are E engineering days to go.  The expected delivery date is D.  

Sometimes they offer resources.  We tell them what we could do with new resources, how long it would take to get them on line, what the project impact would be.  If it's tricky, we'll tell them we'll replan and get back to them.  We refuse to guess.  They can't find someone who knows better than we do, they can only find someone who will lie.

Sometimes they mention overtime.  We tell them that we worked extensive overtime during the crunch to first release, and we produced fewer engineering days per real day than if we had worked our normal schedule.  Overtime doesn't improve the schedule.

Sooner or later they get it.  You want it sooner, the best thing to do is to do less.  They'll help with the Customer's scope issues.  --RonJeffries