This exclamation from one of my team members had traveled through the office grapevine, labeling me as the kind of manager I never intended to be. What was I doing wrong? I couldn’t possibly be a micro manager. Not me!
I’m all about the fine art of delegation and giving props for jobs well done. I’ll always take time to assign a task, set expectations and provide my team with whatever resources they need to be successful on the project. Well, it turns out the classification of “micro manager” was assigned to me after I had requested that each team member submit a weekly status report.
Was I missing something? Wasn’t a status report required by every manager? How was I supposed to know how we were tracking towards deliverables and how everyone was performing?
I also looked at status reports as not necessarily a way to “check up” on people, but a way for team members to brag about their accomplishments. I could use them at review time to easily identify areas for improvement and outstanding achievements. It seems not everyone feels that way and sees them as an unnecessary waste of time.
Short and Sweet
Smart IT Columns
I’m not sure when the first status report was required in the corporate world, but I imagine the first ones were verbal, then hand written – eventually banged out with a typewriter, and thus a tad time consuming. But over time the effort it takes to produce a standard status report has streamlined with the advent of email. All a manager needs to do is provide a standard template, the team members fill in the blanks: tasks completed, tasks in progress, tasks to be worked on, problems, etc. – and voila! A status report can be cranked out and distributed in a matter of minutes.
If you keep them short and sweet, weekly status reports can offer value without taking up too much time. The focus should be on the exceptions, such as new risks, and not the mundane “task on schedule” comments. At a minimum, use status reports as verification of what you should already know, thus ensuring no misunderstandings occur.
Plus there is benefit to having team members sit down and think about what happened in the last week. It can force issues forward that may not have received proper attention without a concentrated effort to summarize efforts.
What’s Really Achieved?
The question still begs “what do you really learn in a status report?” As a manager, shouldn’t you know what issues are happening?
As a front line manager, yes you should because there should be ongoing, daily communication between you and your team. If you are surprised by a major issue that would be reported at the end of the week, perhaps you aren’t in tune with the important happenings on the project.
What about the managers up the chain? How is the CIO supposed to know about major issues that will impact multiple project budgets and timelines? Or how is the project’s business owner supposed to track major issues and perhaps concede a requirement to stay on schedule? Notice of my use of the term “major issues” because high level IT and business managers cannot afford to be mired in the details.
Therefore, it should be mandatory for team leads and managers to share task status and major issues up the chain. This can be accomplished through a project portal using green, yellow or red to highlight tasks that need attention, or simply have a separate page for critical issues or new risks. Another approach would be to produce a very succinct report from your project management tool showing how you are tracking to deliverables and include a list of major issues.
Or, Maybe Not
Smart IT Columns
On the other hand, perhaps times are changing and the status report really is becoming a corporate efficiency relic of times gone by. In today’s very connected world an alternative option would be to set up individual project blogs or use a project portal to allow team members to post items when issues arise. Let everyone in the corporate food chain see the same “status” in one central location.
One problem here could be lack of a filter, resulting in upper management overreacting to issues that are misconstrued. Some thought needs to be put into the controls and processes so you don’t end up with a mish mash of incongruent (or incorrect) information that just leads to confusion and bad decision making.
Let’s finish up with the original question. For project team members, are status reports a necessary evil? My conclusion is that as a manager you are responsible for the project. If a person fails at a task, it is ultimately your responsibility and therefore you need a clear window into progress or lack thereof.
So no matter if they blog it, talk it, or write it, team members should be accountable for timely communication of their task status. The only way to avoid nasty surprises is through some combination of verbal and written status updates.
Feel free to give the informal methods a try, but if the communications aren’t coming through loud and clear, then perhaps some micromanagement is in order. Although I prefer to think of it as responsible management.
Now excuse me while I go see what my employees are up to.