Project weeknotes

What are weeknotes? #

We use weeknotes to inform the people we’re working with about our progress, issues we’re dealing with, and what we’re planning to do. They can be a really useful way to update people you deal with directly, but they can also be shared more widely with people who are less directly involved in a day to day basis.

Why do weeknotes? #

We think weeknotes are valuable for a bunch of reasons:

• Everything Giles says about doing weeknotes is doubly true as an agency
  • our teams will operate more effectively within clients
  • our people will communicate more effectively with each other
  • our project leads will understand their projects better
• As part of the Quality Management System, we need to be regularly communicating progress to our clients, and we need to be doing that in writing
• As part of our sales and marketing, we need to have a record of what we’ve delivered

Who should do weeknotes?

If we’re providing the PM or DM of a team then we’re directly responsible for the quality of that team’s delivery. If a team has a dxw-provided PM or DM, that team must be producing weeknotes. This is true even if dxw are only providing the PM or DM of a rainbow team.

If we’re only providing other roles, our responsibility is reduced but not eliminated. Rainbow teams with dxw folks should be producing weeknotes. If they already are, dxw must get copies of those weeknotes. If they’re not, we should be encouraging them to. The engagement’s Project Lead is responsible for making this happen.

If we’re working in a team that won’t be producing weeknotes, then the dxw folks must write weeknotes for a dxw-only audience.

Who’s the audience for weeknotes, and where should they be published?

Weeknotes are for us and for our clients. At a minimum, an external weeknote should be sent to the team’s service owner and shared in the dxw weeknotes Slack channel.

If we’re working with a client that already has a strong culture of weeknotes, we should also be publishing wherever those are already shared. If they don’t we should try and be the change we want to see in the world.

Some departments’ Service Assessment panels expect to be able to read a team’s weeknote history and have a place where they expect weeknotes to be stored.

What makes a good weeknote? #

All writing should be tailored to its audience, so we don’t want to be didactic about format, but for weeknotes to be useful for all the internal things we have planned they should have updates on all the following things:

• Progress or milestones achieved
• Emerging outcomes or value delivered
• Evidence or data points supporting progress
• Risks, blockers, and dependencies
• Reflections or lessons learned

A good weeknote:

• Sounds like it was written by a human. Ask yourself whether it would be something you’d be happy to receive and read. You don’t need to make it too formal.
• Is honest about progress as well as issues. This is a good way to flag things that need to get dealt with on a project.
• Gives a sense of what the team is delivering as whole. Don’t just write bullets covering what every individual on the team did that week.
• Brings the project to life. Do you have any images you can use to illustrate what you’ve been doing?
• Is frequent and regular. This is a good way to build trust with the wider team.

Template #

Weeknotes: project name Week ending: date

We send out weeknotes to update you on progress. Weeknotes highlight things we’re worried about, acknowledge achievements and show progress, and layout what we plan to do next. Along with our show and tells, this is the main way you will find out about the project so please read.

Get in touch with [insert delivery manager name] with any questions or feedback.

Good Things

What are the main highlights this week? Have you hit any milestones, or overcome any significant blockers? What decisions have been made? Do you have any images to show progress? (e.g. a photo from a workshop, or a screenshot of something that’s been built?)

Learned things

Have the team learned anything from a retro? Did anything happen that you didn’t expect? Have the team made any changes to how the team operates? Have the team uncovered anything new from user research? Does anyone from the team have any personal reflections that they’d like to share?

Difficulties

What challenges or issues does the wider project team need to be aware of? How are you dealing with them? What help do you need - either from within the project team or elsewhere?

Achievements

Are there any team achievements that need recognising? Are there any individuals you want to recognise? (they don’t need to be inside the core project team - they could be someone from a different department who helped you out this week).

What’s next

What are you planning to deliver in the next sprint? When is the next show and tell? What key meetings are coming up?

How frequent, and how detailed, should a weeknote be?

Weekly is ideal; fortnightly/by-sprint is OK; monthly is too infrequent.

It’s more important that they’re published regularly than that they’re perfectly written. We’d rather they were bullet points every week than beautiful prose once a month.

Last reviewed 2026-04

Last updated: 30 April 2026