STATUS REPORTS

It's funny the things that seem to be constant across lots of different cultures, and one of them, I've discovered , is that during their school days, many people have written an essay entitled A Day at the Seaside.

Perhaps you did too, and if so, maybe you remember how it went. All human life was there “ the weather, the personalities, the events, the emotional highs and lows, the interplay of characters “ and, at the end of it all, we tumbled into bed, sand between our toes, badly sunburned, covered in calamine lotion, tired but happy after a tremendous day.

I mention this because most status reports seem to bear striking similarities to a day at the seaside essays . They might as well be called "Here were all the dead interesting things that happened on the project last week." As we read on excitedly we find out all the minutiae that occurred on the project and invariably there is the happy ending “ just like in our essay; the upbeat conclusion that says everything's OK, all's right with the world.

But is the project on target? Hey, I don't know. And you certainly won't find out from reading a day at the seaside status report. If you want to come away with a permanent warm feeling, then a day at the seaside is just for you. But if you want some useful information, you will have to look elsewhere.

The status report I propose is a top-down creation, going from the most high level to the most detailed. It says in no uncertain terms what the status of the project is; and you can perhaps see why people might not want to write these “ they are completely unforgiving and clinical in terms of what they reveal.

Here, then, is a structure you might follow in writing a status report.

Level I

Is the project on schedule? Yes or no? Your status report template could have two boxes where you tick one. If the project is on schedule, people may not want to know any more.

Level II

At this level you present some high-level information on the state of our four parameters: functionality, delivery date, effort and quality.

Functionality

A couple of sentences stating at a high level:

what the functionality started off at
any major changes that have occurred

and pointing at the change control log (see Chapter 1) where the detailed changes and history of changes can be seen.

Delivery date

Here's what it was originally	mm/dd/yy
Here's what it is now	mm/dd/yy
Here's how it changed	nnnn

Change no.	Date	Reason for change	New del. date
1	mm/dd/yy	xxxxxxxxxxxxxxxxx	mm/dd/yy
2	mm/dd/yy	xxxxxxxxxxxxxxxxx	mm/dd/yy

n	mm/dd/yy	xxxxxxxxxxxxxxxxx	mm/dd/yy

Effort

Here's what it was originally	nnnn man-days
Here's what it is now	nnnn man-days
Here's how it changed	nnnn

Change no.	Date	Reason for change	New effort (in man-days)
1	mm/dd/yy	xxxxxxxxxxxxxxxxx	nnnn
2	mm/dd/yy	xxxxxxxxxxxxxxxxx	nnnn

n	mm/dd/yy	xxxxxxxxxxxxxxxxx	nnnn

Quality

If you are measuring quality, say, with something like mean time to defect (MTTD), then you could also treat it the way we treated delivery date or effort, above. If you're interested you'll find a good discussion of MTTD in Puttnam and Myers (1992).

Finally, at this second level, you should make some general statement about the state of health of the project. Even though it may be on schedule there may be some calamity looming. Here you can say in a few sentences what the big issues, known risks and problems outside your control are, and what you are doing/ would like done about them.

Level III

At Level III, if you're feeling a bit like a frustrated novelist because you haven't been able to get into a day at the seaside, then this is your chance for a bit of narrative. If you like, you can write down the things that are currently happening. This would correspond very much to the "current stuff" we talked about in Chapter 7. Do it by person maybe, and that way everyone gets something said about him and feels loved and wanted.

Level IV

Finally, at this level, you can throw in everything and the kitchen sink. Here you can include a copy of the current plan “ the Gantt chart “ showing all the detail in the world.

Finally, the last question is who do we give this great opus to? Well, in the spirit of what we said in the introduction to this chapter, it seems to me that we should give it to as many people as possible. Clearly there may be things that we don't want the team or the boss or the customer to see, but there's nothing to stop us doing a sort of " vanilla " report for general consumption with a little note attached if there are things we want to report to a specific audience.

By giving it to the team, we enable every person to see the big picture and how their part fits in. Other people may spot things that we haven't seen. The more problems are identified now, the fewer problems we'll have down the line.

Equally, by giving the status report to bosses and customers we avoid the project becoming a black hole where money is poured in, and someday something may come out. We not only do a good job but are seen to do a good job.

As an example of what I mean here (and this is very much by way of illustration rather than a rule) on a project I ran for a client, I produced two versions of the status report. One “ the same one “ went to the team and my boss, i.e. my client. The other went to my client's client, i.e. my customer. There were two differences between the reports.

All references to who was working on what were removed from the customer's version on the basis that this was my client's business and not the customer's.
Any downbeat or ominous messages were removed from Levels II and III of the customer's version. This, however, was because the project was generally going well. If it had been otherwise then we would have been passing those messages on to the customer. Had we had to do this, then, among other things, we would have been preparing the customer for bad news. And in doing this, we would have been following the principle of no surprises that we talked about in Step 7. If we had had to break bad news to the customer, what he would have seen all the way would have been professional project management of the situation.