By using a broad entry to capture your plans for the coming week, you’re showing that you’ve failed to plan! The whole purpose of a status report template is to detail the expectations of you. Those expectations cannot be listed until careful planning has occurred. If you’ve followed the process for creating your status report templates carefully, you don’t need to include a “Goals For Next Week”; they’re already listed!

Besides a failure to plan, an entry for “Goals For Next Week” indicates a failure to understand the difference between a goal and an expectation. Your goals are just that - yours. A status report details your accomplishments against the expectations others have of you. A status report isn’t about your goals, it’s about meeting the expectations of others. One might argue that the expectation here is for you to list that which you are expected to do next week. But, once again, this would be a duplication of effort if the template were laid out properly. A properly laid out status report template would already answer the question through the proper listing of the expectations on you, i.e. that which you’re expected to do in the coming week!

Too many people look at a status report and think “Static Report”. When done correctly, a Status Report is anything but static!

Finally, including a question such as this is a poor excuse for not taking the time to properly follow the process of status reporting. It’s the cheap way out, the “catch all”. There’s no place for such a question as this. You need to detail the expectations, not use broad sweeping questions (see 7 Rules For The Proper Use Of Status Reporting). Don’t allow yourself to fall into using bullets to document the routine, expected, and/or mundane tasks just because it’s “safe”. While employers rarely encounter legal trouble for the “mundane”, it’s very demoralizing!

Here are three steps you can take to move towards better status reporting:

• Take the small amount of time required to review your status report template. If you have anything resembling “Goals For Next Week” or “Plan For the Week”, restructure your template so that the expectations are properly captured.
• Pull out your oldest status report which is based on the same template you’re using today. If the template is more than six months old, consider revising the template or reviving your career! Remember: your career isn’t static, so your status reports shouldn’t be static either!
• Review the template and ask yourself if all the expectations placed on you are properly captured. Imagine someone walking up to you and asking, “What do you do here?” Don’t stop there! This time, imagine you’re the manager or boss and ask yourself the question, “Why should you be given that promotion or raise?” If you can’t answer the expectations of you, it will be difficult at best to expect that next promotion or raise!

I hope this post has raised your awareness that status reports are anything but static!

Share

Until status reports are appreciated for what they are and what they are not, your opinion of them has most likely been formed without the proper background. Thus, when you act upon them, whether to have your organization complete them or to fill one out yourself, you’re probably doing yourself and your organization a huge disfavor.

Without discipline to the management of your information through structured data collection at regular intervals, you will never achieve anything more than haphazard, disjointed, unwelcome efforts to “improve communications”. You need a process that leverages status reports in many ways.

The #1 Problem With Status Reports

Ask yourself this question: why do you use (or want to use) Status Reports? The number one reason I hear is: To improve communication within a team, a project, an organization or an entire company.

Fostering communication is an admirable goal, no doubt, but if that’s your number one reason, chances are very good that you’re in serious trouble and status reports aren’t going to help — they’re going to hinder! If you haven’t used status reports from the inception of your team, project, organization or company adding them only adds to the chaos and confusion.

Introducing status reports incorrectly will result in the perception that you’ve thrown your hands up in defeat and have resorted to the “worst possible communications tool”; the dreaded Status Report. Why? Because improperly handled, a status report is nothing more than “busy work”.

You may have already tried several other approaches to “improve communication”; most notably Wikis and Blogs. In so doing, you probably didn’t notice the other forms of communication which are occurring without your intervention; things like e-mail, hallway discussions, and post-it notes. By introducing status reports incorrectly, they will be perceived as being “forced upon” the employee. With resistance from the outset, you’re doomed to fight an uphill battle. Odds are not in your favor.

Bringing Discipline to Your Team, Project, Organization or Company’s Management of Information

Notice how I have not used the term “Information Management”. I’ve done that for a specific reason. Information Management and Information Technologies (IM/IT) represent distinct professions. Status reporting isn’t focused on your IM/IT Department although it may involve them in the administration of the system (and they may well be users themselves). Proper status reporting allows your employees to manage their own information; that flow of communication that either needs to get out to someone else or be documented for later retrieval.

So, what’s wrong with “traditional” status reports? Let’s take a quick look at one. If you’re a Windows user with Microsoft Office installed, open “InfoPath”. Both 2003 and 2007 have a template for a “Status Report”. Let’s look at that. For those that don’t have InfoPath, follow along for a moment and see if this doesn’t fit the description of status reports you’ve either been asked to fill out or have created in the past. Let’s jump to the heart of the template and look at what’s being asked of someone; “Last Period”, “This Period”, “Issues”, “Notes”. What will this status report tell us six months from now? Very little. Why? Because it tells us very litle now!

How fair is it to report what you did in any given “period” when the expectations are not present? For example, let’s say you “Assisted three customers with the installation of ABC.” Is that your job or were you going out of your way to make certain someone had a pleasant experience with the company’s product? Were you expected to assist 90% of all new callers, but of the 20 new calls only satisfied 3? Without the context of the expectations placed upon the individual, the content is virtually worthless! This is not the actionable, timely information an organization requires. It’s another example of confusing, bad, stale information. Organizations which introduce status reports to “improve communication” aren’t on the Information Highway, they’re road kill!

Here are seven rules which I think can help teams, projects, organizations and companies use Status Reporting effectively.

Rule #1: Use Status Reports to Document Events for Historical Purposes, Not Immediate Action

If you believe a status report will communicate “current events” for immediate action, you’re fooling yourself. It only takes one key person to be off on vacation for two weeks to throw everything into ruin. It’s my experience that by the time a status report is published, the information contained within is already stale. You need to properly address events as they occur, but document them for later review as well. The purpose of the status report is to be that documentation vehicle by which you can later perform a review (a.k.a. After Action Report, Lessons Learned, Post Mortem, Retrospective, etc.). You need to deal with an issue when it arises, not two weeks later when someone returns from vacation or, worse yet, when someone with less motivation gets around to reading a status report.

My experience has been that if someone doesn’t read your Status Report within the first 24 hours it’s published, they’re not going to read your Status Report period.

I’ve also noted over the years that the majority of status reports written are not reviewed within 24 hours. This makes them better as historical documents than actionable reports.

One of the biggest crimes I’ve seen with status reports is the dreaded “generic template”. Often like the one I pointed out in InfoPath, these could easily be created as: what’d ya do, what are ya gonna do, why haven’t ya done it? Sound demoralizing? It is!

Rule #2: Evolve Your Status Reporting Template As Expectations Of You Change

Generic templates lead to boredom. Boredom leads to two things; status reports that are created by those who should be documenting facts but turn out nothing more than repeating lists of bulleted items and apathetic readers who soon learn to ignore those repeating lists of bulleted items. Don’t let this happen to you! Personalize the templates.

Sit down with your team, customer, manager, etc. and discuss what will make a good status report from each member. Some may report on the status of system services (e.g. the Athena system experienced an outage due to failure of a WD250GB hard drive in the RAID-5 array which affected 60% of the CRM users; replaced the drive within one hour and recovery of the RAID-5 array completed in 4 hours) while others may report on customer interaction (handled 15 calls on CRM reports resolving 100% while online with user) or project progress (milestone A reached). Make the report meaningful to the person and their situation. Be specific, but be brief as well. Note the examples which are succinct; in six months someone will understand these. Remember, there’s a lot of other communication going on already so stick to the purpose of the status report.

Status reports have to be mutually agreed upon. Management should not force the employee into a generic template and the employee should not repeat bulleted lists with each report. Remember, the purpose of a status report has little to do with communicating “current events” for immediate action. A status report is a documentation tool for later review. Even a review of the previous week on a Monday morning is a historical review. Senior management will expect that any issues documented in the report will already be in the process of being addressed.

Rule #3: Write Your Status Report As If Your Next Promotion Depends Upon It

An employee has to write a status report that is relevant to their situation. It documents events that are pertinent to their environment, their contribution, their performance. As such, a status report is written primarily for the benefit of the individual. Sound crazy? What will the individual and their manager refer back to when it comes time to write an annual performance review? And who is the primary beneficiary of that review? Of course it’s the individual. Left to memory, at best management might get one or two highlights from the year. Given an individual’s documentation of their performance and a manager’s ongoing active review, the annual performance review can be a more objective, complete, analytical discussion. Annual performance reviews should not be one-sided speeches and the quickest way to ensure that the individual is provided with the best appraisal possible is to review their performance as documented in their status reports against the expectations of the employee during that time period. Ongoing active review of status reports with appropriate feedback ensure personnel issues are managed throughout the year, not sprung on someone in surprise at an annual review.

The annual appraisal should be a review, not a surprise!

If there were one thing I hope you take away from these thoughts, it would be that you keep the purpose of a status report in mind at all times; it documents for later review. There are much more effective means of communicating on a near real-time basis.

Rule #4: Don’t Use Status Reports As Blogs or Wikis And Don’t Use Blogs Or Wikis As Status Reports

I’ve seen blogs and wikis used as effective communication tools for teams and projects. They’re great for collaboration in exploring some idea, topic or issue of interest. They are worthless as status reports. They lack the appropriate structure (see Rule #2 above). Keep the purpose of a status report in mind and you’ll quickly be able to utilize the right tool for the right purpose. This doesn’t mean that a status report and a blog may not reference the same material. In fact, the topic of discussion may appear in several status reports (as progress is determined to be made, contributions are recorded, etc.). However, the status report is not the discussion and the blog is not the historical archive. The fact that the discussion occurred, a brief synopsis of the discussion (perhaps limited only to the topic) and where to find the discussion may be all that is necessary in the status report. But, it is necessary!.

Rule #5: Don’t Use Static Status Reports; Evolve Your Templates

Your world is changing every day. While a status report template doesn’t need to change that frequently, it should be dynamic and it should be updated as the situation warrants. Don’t create a template and then think that you’re good for the life of the project. Stuff happens; evolve the status report template with the changing expectations.

Nothing is constant except change itself; teams change, proejcts come-and-go, and individuals change, thus status reports must change. For example, after a promotion, at least one template of the employee’s status report may change to reflect new expectations. Note that the change may be to only one template. To properly capture an employee’s contribution may take several templates; one for a project, one for their corporate responsibilities, one for individual expectations, etc.

A good status report template doesn’t set goals for the individual, it communicates expectations.

Rule #6: Use Status Reports To Capture And Communicate Expectations

Goals are something you set personally. A team or project may set goals, but it does not set the goal for the individual. Make no mistake, the team or project does set goals and there is a relationship between those goals and the individual, but they are not the individual’s goals. Instead, they are the team’s expectations of the individual. This is a very important distinction! It’s my belief that this point is missed by every attempt to manage status reports.

Rule #2 states you don’t use generic templates, but it doesn’t state who is responsible for creating those templates. It is my belief that the individual and at least one other person from the team or project must agree upon the expectations placed on the individual. Involving the individual helps solidify the expectations on both sides. Project kickoff meetings are great for communicating and capturing the expectations of each individual. This allows a more detailed analysis at a later date, often by a customer when contemplating an invoice or an option to renew or extend a contract, an after action or lessons learned meeting or at the time of the employee’s annual performance review.

Rule #7: Status Reporting Is A Process, Not A Form

By now, I hope I’ve convinced you that the reason traditional status reporting does not work well is that most attempts to implement it ignore the process and focus on a form. Without a process which makes everyone aware of the power and value of status reporting, forms will fail - no matter how good they are. The company is being cheated if status reporting isn’t implemented in such a way that lessons can be gleaned. The individual is being cheated if the process doesn’t involve them up front and communicate the expectations placed upon them. The individual, manager and company are being cheated if performance appraisals are not incorporated as part of the process. Don’t be cheated!

Share

The Goal
The goal here is to be able to securely view each of three Lorex cameras from anywhere on the Internet.

The Environment
My environment consists of the following:

• Linksys BFSR41 Cable Router
• Cox Communications Premier Hi-speed Internet service
• DynDNS CustomDNS service
• Two Lorex IPSC2260 and one IPSC2230 IP enabled cameras

The Problem
Each camera has a built-in web server. While this makes setup and maintenance very easy, it also makes it difficult to view each camera directly from the Internet when using DHCP. From my work with the cameras, it appears the reason is that any TCP/IP packet coming into the router will first look at the port (80), then look down the list of Port Forwarding IP’s and send the packet to the first IP it finds answering the mail for port 80. One solution would be to pay four times the cost of a single CustomDNS service from DynDNS and give each camera its own Internet enabled IP. This is an expense I want to avoid.

The Solution
The solution I implemented was to use the WebHop feature of DynDNS’s CustomDNS to port forward a cname over to a specific IP. Thus, I have three cameras positioned around the house:

1. Garage; mounted at the end of the garage rotating 270 degrees from front-door to garage door
2. Guest House; a.k.a. the little house, watching the back door
3. Pump House; positioned on the side of the house under the eaves pointed at our well

Each camera appears to recieve a TCP/IP request on a configurable port (defaulted to 80) and return streaming videa via a configurable UDP port (defaulted to 9001).Using the Lorex setup, I setup each camera to have a static IP, a port other than 80, and a UDP port other than 9001. The TCP and UDP ports are important because they are plugged into the Linksys router and DynDNS setup. My setup was:

Using the above ports, I opened the Lorex setup for each camera, chose “Network” under the “Basic Settings” and set the Port and UDP numbers here, but I did NOT change the DynDNS settings. The cameras would not have an individual DynDNS service to plug-in here. For security, I went to “Account Settings” under “Basic Settings” and added a username/password.

My next step was to open the Linksys router’s configuration and go to “Applications & Gaming” which brings up the port forwarding configuration. I made two entries for each camera; one for the TCP port number and one for the UDP port number.

The next step was to go to DynDNS’s configuration and add a MyWebHop for each camera. I used the name of the camera as the hostname (e.g. “pumphouse”). I included the port number on the redirect URL (e.g. http://example.com:82/). I also cloaked the URL so that the user did not see the port number after the first returned page.

The Result
I now have the ability to view all three cameras from anywhere on the Internet using their cname (e.g. http://pumphouse.example.com/Cam1.htm) securely by using the username/password in the Lorex setup above.

The Credits
If the solution sounds straight forward and simple, it is. But it wasn’t without trial-and-error for me. Help came from DynDNS, several times on a weekend including Sunday. The following were particularly helpful: Jason Hutchins, Brad Goodwin, Christian Smith, and Mark Parraway. I HIGHLY recommend DynDNS and thank them for their help!

Share