Open Project Management - Progress Reports

Daily meetings are great to keep things moving forward during production. It's rare for the Client to be at these meetings so there needs to be a way to keep them in the loop. I've found that the best way to do this is to produce weekly progress reports. There are a number of benefits that a weekly progress report will achieve, one of the most important being a check of how things are tracking against the overall production schedule and also as a means to keep things transparent. They also can be very handy when you need to reflect on what was happening at a particular point in the project—sometimes we forget the decisions made early on and having them captured can be a lifesaver (not to mention a great way to cover your butt!).

It shouldn't take long to write a progress report. If it takes more than an hour, then you probably need a meeting; I find most progress reports take about half an hour to produce. They are not comprehensive detailed reports—remember, written communication is the least effective form—but rather a snapshot of where the project is at.

Over the years, I've adjusted what to include in a progress report and sometimes change the contents based on the project but the following headings are the core elements that I include in every progress report. For some weeks, there's nothing to say for a particular heading, which is fine, as long as it's captured.


This is really simple—what has the team achieved in the last week. It's a straightforward question and there have been times on projects when I've actually had to stop and think about it. If there are no achievements, there better be a good reason! Sometimes there is a good reason, like lack of content or missing information (which should have already been identified in daily meetings) but given that Clients are rarely at daily meetings, this is how they find out. However, be careful about overstating achievements, it needs to be real, you don't want to lead the client into a false state of security by stating something has been done when it hasn't; avoid exaggeration or optimism, this should reflect the true state of the project, be it good or bad.

It's also a good thing to be able to clearly state what's been achieved; it's a positive sign. Sure, sometimes the achievement may not mean a lot to the Client as they may not fully understand what was done, but at least they can see that something isbeing done! Basically, it forces a big picture review of the project and helps to raise issues and avoid slippage.


During a project, there is almost always a point in time when one member of the team is waiting for something from another member of the team. In eZ publish projects, the most common dependency is either content or a decision from the Client. Explicitly stating the dependency will hopefully make the Client aware of this. Sometimes it's not the Client directly who is supplying the material, it can be one of their staff and the Client might not be aware that it hasn't been delivered. This puts the pressure back on the Client to fulfil their role on the team.

What this part of the report should state is:

  • Are we waiting on anything?

  • If so, what?

  • Who's responsible for delivery? E.g., waiting on design approval, sample content, etc.


Assumptions are the cause of many problems. Not stating and testing assumptions can lead to wasted time, effort, and money. It's also a good way to raise issues in a non-confrontational way.

It's much better to be safe than sorry and state any assumptions as soon as they arise. And it's surprising how many assumptions are made during a project. It comes back to the imprecision of communication. When there is a gap in understanding, sometimes we make an assumption rather than asking for confirmation. Do this enough times and the gap between what the Client expects and what the Developer builds can be enormous.

So, state any assumptions and get the Client to confirm if they are true or not. E.g. we assume that the content will be entered by hand, not imported from the existing database.

Issues and Risks

This is the perfect place to report on existing risks and raise any new ones. It's also the place to raise any issues that have arisen during the project that need to be addressed. It doesn't have to be comprehensive, a summary is enough. If the issue is significant, a meeting should be held to resolve it. By putting it in the progress report, you capture when the issue was first raised.

In this section, you need to include the following:

  • Any problems that have occurred

  • Any new risks that have surfaced

  • An update on any existing risks or issues


The purpose of this section is to capture decisions made to resolve any issues or risks that have arisen. Once again, the full details may be captured elsewhere, e.g. in meeting notes or an email, but by including it in the progress report, it's easy to go back and see when the decision was made. It also acts as a reminder to the Client that the issue has been addressed and what the solution was. In this section, all you need to include is a summary of what issues have been resolved and how the solution will be implemented. Sometimes, it might simply be a statement that it was decided that it wasn't a problem, and no changes are needed after all.

Sample Progress Report


  • Addition of GC-specific Admin interface

  • Community Group Approval process

  • Homepage design applied

  • Wish lifecycle complete

  • Wish reporting complete


Don't need to support IE 5.0


Design sign-off required by 15th Oct to meet 31st Oct release date

Issues and Risks

Design Concepts - Further revision required Community Signup - As a part of initial registration, we need to ensure that we collect: confirmation of DGR status, organization name, location (NSW & Vic only).


Resolve Wish - No need for the text field "reason for wish being resolved"—this will come out of the reports each party has to fill out.