Project Reporting: How Often Should You Send Status Reports?
OK, so now you’ve read the first article in my series on project reporting, you’ll know three things:
So, just to recap (and I suppose just in case you were too lazy to read my first article), I wouldn’t just answer the question of how often you should report your project. Rather I insisted on explaining a better way of thinking – one of basing your reports on strong plans and controls.
To recap some more, PRINCE2 recommends a number of levels of control cycles. These can be thought of as cycles within cycles, and are:
I added a routine to that, which is implied within both PRINCE2 and PMBoK, and that’s the daily routine of each manager.
The frequency of these cycles will depend on a number of factors including, but not limited to:
For the purposes of this article, I’m going to assume a project of greater than 12 months duration (from concept to closure). This equates to a moderately complex IT project or significant construction project. If a project is much shorter than that, it may only have one execution stage and reporting may be more frequent than suggested below.
So that would make the project lifecycle, fairly obvious wouldn’t it? The length of the project! Well nice try, but you only win half the banana because you forgot to take into account that somewhere, some time, someone will need to do a Post Project Benefits Review – but because I’m actually in a really fantastic mood today, I’ll set the banana aside and give you a chance to earn it back later.
There are two main reports that are associated with the life of the project. The first is the End Project Report, which will convince the project board and corporate stakeholders that the project can be closed. This report should be created in the lead up to project closure (typically a week or two in advance is good).
The other project report is a Post Project Review, or Benefits Assessment Report. So, when should that be done? The simple answer is: when you expect to be able to determine that the benefits have been or are being received. This can be anywhere from a few days to a few years after the project, though if it’s going to be a long time, I suggest an interim report every, say, six months. That idea will keep interest in the benefits.
There are a number of factors that can determine stage boundaries. However, there is also a lot of commonality about the stages that typically work well for projects. These should be driven by business events, not necessarily technical milestones. However again, it so happens that technical milestones often do coincide with our chance to make some business decisions.
With all of that in mind, the other constraints I try to live within is that stages should be no shorter than two months and no longer than six months. Typically I find if I keep stages in the 3 to 4 month zone, then that works well. As it so happens for many projects, this works in with some natural decision points that may include:
Note these statements above are about the business decisions as much as the technical success. It’s a subtle distinction but an important one.
It’s an odd thing, this. Highlight reporting is one of the simplest but most misunderstood things about PRINCE2. Everyone seems to conclude that every time a report is produced it needs to go to a project board meeting and be distributed to every stakeholder this side of Jupiter. Then these same people complain that there are too many meetings and the reports are cumbersome! Well – I’m going to drop that line of thought now – remember, I’m in a good mood and determined to stay that way. I might even include a picture of my petting a kitten just to raise the tone.
It suffices to say, highlight reports should only go to the board and a few nominated, key stakeholders. Assuming the board members can read and know how to communicate with each other and the project manager, there’s no need for a formal meeting each report.
That improves the options available for how often to report the project. I think in determining the frequency of highlight reports, the key question is, how much could change in a week, a fortnight, a month, every two months, etc.? The board doesn’t want to get reports every so often that tell them the same thing but on the other hand, as an executive, you don’t want to get one report that says “Hey, it’s all sweet” and the next saying “Whoops, we’re two months behind!”
Personally, I’m a fan of a highlight report each fortnight as that seems to be about the time frame that gives sufficiently early warning of key project lead indicators without being overly burdensome. Many of my clients however prefer a monthly routine – sometimes though this is just because their project boards meet that often.
If you are preparing a regular update for stakeholders, then you typically do not want to share all the information you share with the board. For that reason, I use a highlight report format where all the pretty stuff and the key indicators are on the front page and all the nitty gritty, grizzly stuff is at the rear. Then I send the front page to all and sundry or post it on the project web page.
Here’s a place where more misunderstanding occurs. Checkpoints are reviews between the project manager and any team managers they have. If people don’t exist with that title, then take it as “anyone who is managing work on behalf of the project manager.” Again, I see project managers trying to include their entire team, and sometimes even their bosses, in checkpoint meetings and then complaining about the overhead involved. Oh dear, here kitty, kitty, kitty!
These checkpoints can be either one meeting or multiple meetings, and that depends mostly on whether all the information can be shared between teams.
The most common frequencies for checkpoints are weekly and fortnightly. I have been involved in projects that had daily checkpoints and this is often appropriate at the heat zones of a project – such as system roll-out for an ICT project.
This nuance is related to a concept I discussed briefly in my previous article in the series – the natural duration of a work package. The work you hand out to others to manage will have a natural sweet point for the duration of chunks you want to manage. In a sharp, fast-moving ICT project, this may result in work packages lasting only a few days. In other projects, these may be several weeks. A rule of thumb I use is that you should try to avoid having either of the following.
I’ll stress these are not hard and fast rules, but good rules of thumb.
So, if you want to win the other half of that banana you could try to guess the main factor I use to determine my typical checkpoint cycle. If you guessed something really complicated like work packages, then I’m afraid I’ll keep the banana.
I gravitate towards weekly checkpoints wherever I can simply because I find it much easier to remember. It’s so much simpler if, for example, on every Thursday morning I meet with Brian and Juanita for the internal checkpoint and then meet with the contractor in the afternoon. Then again, that may just be that in my old age I can’t remember which week it is. My point here is – with all the science in the world, you have to pick something that works for you and your stakeholders!
In my next article in this series, I’ll cover some of the things that should be in each of these reports and where they come from. In the meantime I’d better go – I have a hungry bird to feed. Here kitty, kitty, kitty!! Ah, there you are, nice kitty …
Project Reporting: How Often Should You Send Status Reports?
Research & References of Project Reporting: How Often Should You Send Status Reports?|A&C Accounting And Tax Services
Source
0 Comments
Trackbacks/Pingbacks