Status Reports

Whether you’re following a pseudo-agile methodology or not, it’s a good idea to provide status reports at the end of each week or sprint. But why? You’re already busy enough as it is, right?

Firstly, it conveys professionalism and will make the project owner, as well as your client/account manager, feel valued and respected. You may consistently deliver stunning projects, but if during the course of delivering those projects you leave your clients hanging, unaware of what’s going on, or less than 100% confident that you’re going to be on time and on budget, then they will not value your approach to business and may be reluctant to give you further work or recommendations.

It’s also useful as an internal communication tool. If you’re spending time putting together such a report then why not send it to your boss and evryone on your team? They should also be interested in the information it contains and may even be able to point out if there are mistakes before you submit it to the project owner.

Status reports highlight the inevitable issues that arise during the production of web projects. Therefore it can serve as a launchpad for conversations about finding solutions. Just like in your daily standup meetings, if everyone is made aware of a problem then everyone can do what they can to resolve it. There’s the added advantage that issues are collated and communicated all at once rather than in various email threads, which may be a more eddficient way of dealing with them. It’s a form of issue log that both your team and the project owner’s team can be held accountable for.

The report should always include the latest project schedule. In fact the report’s very raison d’être is to let everyone know whether the project is ahead of or behind schedule and why. The schedule will undoubtedly be updated regularly and so it would be a mistake to only show it to people at or just after the kick-off meeting, or to leave it languishing and ignored on a shared server somewhere. It’s also a bad idea to leave communicated schedules until milestones, which may be weeks or months in the future, because web projects may change on a daily basis. Scheduling issues may highlight cause to secure more resources or de-prioritise requirements in order to stay on track. If the project owner is regularly updated on the project’s timings, then should you need any difficult conversations about extensions you will have a series or shared documents to back you up. Changes to the schedule become easier to sell as a regular progression of schedule revisions higlights how the situation has come about.

As with schedules, keeping the project owner regularly updated on the budget will reassure them. If it’s looking like the budget may be overrun, then they will be able to react early or extend the budget, having been kept informed along the way as to how this happened.

It’s not just about providing the latest information either. The report should also include a list of high-level action items, a general weekly to-do list for both your team and the project owner’s team, which supports project momentum and accountability. If someone fails to complete a stated task one week, then you can highlight here how it has affected the timeline.

The status report doesn’t really have to take much time to compile. Once you have a template from the first one, all you need to do is quickly update the information each week. You should already have the latest schedule and budget figures to hand anyway. It’s a constant challenge for a web project manager, juggling so many things, to stick to these formal processes. Project status reports may be deemed unimportant and may be one of the first things cast aside once Friday afternoon rolls around. However it does force good project management practice and it needs to become habitual. It just takes discipline. By compiling these reports you are forced to review all the information yourself on a regular basis, reinforcing your control over the project. If you allow yourself to leave it for a week, two weeks, a month, then not only will it take longer but you’ll be at a loss.

You can deliver status reports in whatever format you feel is appropriate, depending on your project owner and the tone of your organisation. Maybe a PDF, PPT, or even just in an email. What’s important is that the format is clear and consistent and accessible to everyone. As well as the format, you may want to adapt the level of detail and communication style for each client. Hopefully communication details will have been established at the start of the project. Maybe your client will want daily updates. Maybe they’re especially busy and not details-oriented so will not want lenghy reports. Maybe they’re not technical so the language should be simplified and without jargon. Maybe they will want you to call them after sending the report and talk them through it.

It’s important that the status reports don’t contain any major surprises. If there are major issues that need to be raised, do so immediately, not at the end of the week as a footnote in a summary.

This is part of a series of blog posts about web project management, drawn from years of personal experience. If you’d like to find out more about me then please visit my website: