Because I tend to do a lot of behind the scenes work in the projects that I get nobody really sees my work. They know if it doesnt work, but there really isnt anything to see. This type of work tends to eat up fairly large chunks of time between spikes. The result is that there can be a few days between deliverables which can leave customers wondering what it is that I'm up to. To take care of this I tend to do daily updates. This way I'm able to tell my client what I'm doing. It also causes me to chunk my work down a little so that everyday I have something accomplished even if it can be tested in the larger system yet.
I realize most developers hate doing status reports. So do I. Nobody actually reads them and if things do get sideways nobody is going to care. But here is thing - for whatever reason people actually read my status reports and as a result I tend to not get in to those sideways situations very often.
Part of the reason people don't read status reports is because a lot of the time they contain pretty useless crap. I've seen reports from some of the big 5 consulting companies that were chalk full of it. Why the hell would anybody bother with that? I tend to make mine short and sweet with short entries listing briefly what I did. You don't need an entire dissertation. The code is in subversion so they can go see for themselves. Just a quick line saying "fixed the web-service so that it authorizes users based on domain group membership". That is all the customer needs. If they want more they can email you and ask whatever questions they need.
I also raise flags this way. "Having trouble getting the information about the ISAM file from the mainframe group" was responded to by the PM the next day with "who are you working with? I've talked to their manager and he says they'll help." However, give some thought to raising issues and risks because attentive managers will show up asking questions. Absolutely raise risks, but carefully articulate what you see as a risk and be prepared to talk about it.
My goal with status reporting is two fold: communicate with my client and document what they are paying me for. Ok, they’re not really paying for the status report they are paying for my solution to their problem. But as I said earlier – sometimes I go dark for a while and I like my client to know what I’m up to. The more important aspect is the communication. By telling them what I’m doing and point out problems that I see I engage them in conversation about the project. It keeps the project alive and can keep it from crashing.
Hopefully, you do something for a status report. Don’t be fancy. Just read the news – short, simple and concise. Your client, employer, customer, parents, kids, next door neighbor’s dog will thank you.
If they bother to read it. ;)