If you’re anything like me, you work in a corporation or organization, and you work for someone else. Usually, that person also works for someone else. In any decent organization, two potentially conflicting things should occur:
- lower-level employees are given responsibility and the ability to work under their own initiative, and
- higher-level managers need to know what’s going on.
This is called management. The net result of this is that you will almost certainly, at some point in your career, be called upon to give a Status Report. A Status Report can be as simple as a casual office conversation, an email, or a fancy presentation complete with overhead slides, video, and a soundtrack. No matter what the medium, there are a number of things that you should and should not do in a status report. Here’s my list of the most important things to understand about a status report; forget these at your peril.
1. No surprises
Surprisingly, a status report isn’t about you reporting on your status. Your manager should already have a general idea of your or your project’s status. If you have problems with your project (for example, you’ve fallen behind schedule), then you need to let your manager know immediately, and not wait until it’s time to present your status report.
What, then, you may very well ask, is the purpose of the status report? Simply, it’s to convey all that information to your manager in a form that he or she can use to relay to his or her manager, and to give your manager the necessary time to analyze the status and ask questions about it.
If you write a status report, your manager may do nothing more than aggregate your report along with those of a number of other people and transmit it through the proper channels. On the other hand, your manager may actually be able to offer valuable advice or suggestions on overcoming obstacles or roadblocks.
Remember: if there’s news, then a status report is not the place to bring that up, though it’s always necessary to repeat it. When you tell your manager your news (good or bad), it will almost certainly be immediately relayed up the chain of command; the formal status report will act as a reminder and will help your manager determine what action needs to be taken in response to the change in status.
2. No big changes
Really, everything else that follows is essentially a corollary of number 1, “No Surprises.” In my organization, we code projects as green, yellow, or red, meaning, logically, “on track,” “possibly off track,” and “definitely not going to make that date.”
A project should never be downgraded more than one step. In other words, there is no excuse for a project being “green” on one status report and “red” the next. This is a clear sign that people have not been paying attention to the project (i.e., “managing” it) or that something is seriously wrong. If you want to make your manager extremely perturbed, then going from “green” to “red” in one status-report cycle is the way to do it.
Like the “no surprises” rule, this one can be handled by ensuring proper communication with your manager in between status reports. Unless you’re a polar explorer who’s out of touch with your base camp for 60 days at a time, there is always some way of letting your boss know when something has gone bad with a project. Generally speaking, the best way to avoid this is by simply staying on top of your project at all times.
3. Accept responsibility
That is, accept responsibility for what you’re doing. If your status report consists of phrases like:
- “The IT department wouldn’t let me have more paper.”
- “We couldn’t talk the Ops guys into installing our new code.”
- “We upgraded, but the new package had bugs in it.” what your manager will hear is:
- “blah, blah, blah, blah, I didn’t plan well, blah, blah.” If you needed to give the Ops team 2 weeks' notice and you didn’t, then step up and take responsibility. Even better, come prepared with a plan for addressing the problem. If your report says,
- “We didn’t give Ops two weeks' notice, so we shifted the widget preparation a week ahead in the schedule so that we could move the deployment out by a week.” then your boss will see you as a capable, responsible individual who is taking charge of the situation.
4. Wrap up with the positives
Which sounds better to you?
- We didn’t get the encryption keys in time to deploy the patch.
- We finished the patch ahead of schedule, and we could have deployed it had we been able to get the encryption keys in time. We’ll do that first thing next week.
If you said #2, go to the head of the class. The problem with #1 is not that it isn’t truthful, it’s that it’s incomplete (assuming all the facts are true). Many people will simply state the negatives in their status report (many formal status reports have a section for “needs attention” or “issues”), and this can leave a bad taste in your manager’s mouth. While some people might simply call this spin (and I’ll admit that it has much in common with that politically-charged word), it’s actually a valuable technique for letting your manager know that you’re in control of a project.
5. Use the report yourself
Too many people think of a status report as simply a bureaucratic chore that you do for your manager’s benefit. Don’t think of it that way: make it into something that you can use yourself. Make your status report reflect your continuing planning, anticipation, risk assessment, and analysis of your project. You can then speak with confidence, and will be much more valuable to your organization in the long run.