My Projects

July 3, 2009 No comments yet

Status Reporting and the Controlling Cycle

As I am currently working on improving our controlling cycle support and status reporting I thought it would be a good time to share some thoughts about this topic with you in general. This will also round up my other posts around project controlling a little bit and put them into a larger context.

So far we have mainly discussed two areas of project controlling:

  1. The fact that project controlling is very important and that it needs to be done on a regular basis
  2. The generally individual most important controlling dimensions such as resources, costs and milestone dates

As I am currently discussing how we can further improve Onepoint's project controlling features with some key customers, this is the perfect time to cover the overall controlling cycle in more detail as well as the typical "output" of a controlling cycle iteration: the project status report.

First, the controlling interval. Most clients I recently talked to either have a weekly or a monthly project controlling interval. Weekly intervals are typically in use when there are many small projects that need to be tracked, monthly intervals if there are mainly larger projects with an average duration of more than six months. Some clients also use a two-weekly controlling interval. My personal preference (we have small and large projects) is a short, efficient jour-fixe-style weekly controlling interval.

Next, status controlling. Beside the individual controlling dimensions we already discussed in various posts, the overall status controlling ties everything together. It also typically makes up the first section or page of a good project status report. What we always encounter at our clients is that they are minimally tracking the textual status in the eyes of the project manager as well as open issues/notable problems (often also simply in the form or a plain text area). In addition, we typically see a subjective rating of the overall project status in the form of a smilie and/or a project traffic light. What we are also seeing more and more often is an explicit outlook often called "outlook" or "next steps" which I like a lot and we will definitely add this to our "Controlling Cycle Option 2.0".

Third, details. Beside "real" details (numbers... :-) about resources, costs and milestone dates, we are now seeing more and more clients who are introducing subjective ratings for these key dimensions. Typically these ratings are implemented as smilies or traffic lights (interesting detail: just a few years ago people would probably have used numbers ;-). Needless to say that I recommend visual signals since symbols and colors are much easier to spot than numbers. I also like the approach of some of our clients who are allowing an optional line of text beside these ratings that allow the project manager to explain the situation by supplying a short textual statement.

Finally, we have discovered so far that a good status report always starts with the "executive summary", i.e. the project meta data (title, project manager etc.) with the overall status information, followed by a detailed status (if there is one). Beside that we are not sure yet what a good general "status report template" should really contain in addition, since not every reporting dimension is as important for every client and/or project. We are pretty sure that a list of milestones is crucial for most clients, but beyond that we are yet undecided.

Well, we have just begun our three month process of client discussions and if you are interested I am happy to share our findings with you. What about your status report - how does it look like? What do you like about it? Is there anything you would change if you could?