When sharing updates, it’s very easy to log lots of activity, and tell yourself (and others) that you’re being super productive… but that doesn’t necessarily translate into making consistent progress and communicating the news which matters most.

We regularly use PPPs as a way to share updates at Hanno, both internally (on personal progress and internal projects) and also externally, when we work with clients.

What are PPPs?

The PPP acronym references a very simple format for planning the week ahead and is designed to cut through the noise.

It's a simple list with 3 categories or ‘buckets’ for your tasks during the week:

  • Plans: On Monday, you sit down and think about all the tasks you want to complete during the week. What must get done? If any of these tasks are too big to complete, you break down the task into a smaller, completable chunk, and add this to your Plans.
  • Progress: as you complete your Plans during the week, you mark them as completed, and move them into a Progress section.
  • Problems: if any of your Plans get blocked, or you have issues which are going to prevent you from getting them done, you can move them into Problems. You’re also free to add new entries into the Problems category if other issues come up. It’s an especially good idea to use this Problems category to store all your blockers, so that your team can see them.

Using PPPs is like having an endless series of retrospectives–one every week–where we think about what we planned to achieve last week, and how that turned out in reality. If you added a few tasks into your weekly Plans on Monday, and you’ve only completed 50% of them when Friday rolls around, you’re forced to think about whether you really spent the week focusing on the tasks that mattered. Sure, priorities can sometimes change during the week–an unexpected task might pop up and derail you. But if you’re always being pulled off the tasks you told yourself were important, something is clearly going wrong.

Here’s how we use PPPs on a sprint

  1. Create the document. First, add 3 headings to the page. These are Plans, Progress and Problems, of course. We like to add today’s date to the top of the page, and name the file YYYY-MM-DD PPP. We keep all of the PPPs in a shared Google Drive folder for the sprint, which the client can view.
  2. Figure out your Plans. On day 1 of the project hold a standup as a team and figure out the key things you’re going to get done today. Your MITs, or Most Important Tasks. Write those down under Plans.
  3. During the day, you’ll be able to move most of your Plans into Progress, as they get done. If you get anything else important done, that can be added to Progress too. But try not to overdo it–this still needs to be a clear and concise overview.
  4. Add your problems: if you find any blockers, perhaps you’ll have messaged the client about these. You can list each blocker and link to a Basecamp thread where you’ve been discussing it. The Problems section serves a dual-function as the to-do list for the product owner, and anyone else on the team who can help.By the end of the day, each of our Plans should ideally become Progress. If they’re not getting moved into Progress, then that suggests there’s perhaps a Problem related to that task, which we need to bring up. Even if that problem is simply that we overestimated how much we could get done.
  5. And finally, add your Plans for tomorrow. Since we’re often working on different time zones, we find it most effective to set general plans for the following day, before we wrap up for the evening. This means that if anyone on the team is starting earlier tomorrow, they immediately know what they’re getting done.
  6. And we send this document to the client, over on Basecamp. The product owner is definitely CC’d here, but we can also include anyone else on the client’s team who wants to receive updates–even if this is the only piece of communication they receive on the project. We often have conversations with our product owner via comments on the Google Doc, too. That’s usually the fastest way for them to query us about specific things, and tell us when they’ve solved some of the Problems.

And the next day…

  1. We like to start the day by copying the previous day’s PPP, and removing the Progress tasks. These all relate to yesterday, so we don’t need them for now.
  2. If any of the Problems have been solved (since we’re usually working on different time zones, our product owners often manage to solve problems before we return to work the following morning), we remove these from the Problems section.
  3. And then, we carry on as we did yesterday.

It’s a beautifully simple, and incredibly effective way to plan and coordinate

There are tons of benefits to applying PPPs to ongoing projects, rather than just for internal team use…

  • They give a really clear, high-level overview. One of the original intentions of the PPP was to allow managers to get a high-level overview of how their subordinates were working, without needing to watch them every day. They could see the work being done, and whether it matched up with the plans that had been set out. That same benefit applies when we use PPPs on projects, too. Often you’ll have a CEO who’s delegated the project, or assigned a product owner. But if it’s a critical project, that doesn’t mean they can totally ignore it–the PPP allows them to follow along easily.
  • They help to win the client’s trust. And this is important, especially at the beginning of a relationship. Even if we give the client access to our Slack account (as we do), and set them up to be able to see all the code we’re pushing to GitHub, not every client has the technical knowledge, or the time, to follow this closely. The PPP allows them to make sense of this total transparency we’re giving them elsewhere, and to understand exactly what we’re working on. If you’re trying to be transparent with your clients, simply allowing them to stick their head into the firehose of code commits and IM messages isn’t enough. You have to give them the tools to understand what’s going on within that torrent of activity.
  • They are easy for the team to put together. Unlike project update calls, the PPP document can easily be updated during the workday and demands a pretty minimal effort from the team, relative to the amount of value it brings to the client. It’s also brilliant if you’re a remote team working on different timezones. We have short morning standups, but sometimes, the whole team isn’t able to attend, or perhaps the client has an urgent commitment and can’t make it. The PPP means that’s much less of a problem. The PPP is also the perfect tool for when we do have a client call. We don’t have to recap on basic progress updates, and instead, can spend precious discussion time to discuss the important issues, not the routine tasks and progress.
  • They are brilliant for surfacing and solving problems. No matter how busy the client is, they know that this PPP document is the one that they absolutely have to find the time to read each day. They also know that if they do one single thing in their day, helping to unblock us as much as possible on the things we’ve listed in the ‘Problems’ section of the PPP, would be the most effective use of their time.
  • They allow us to easily retrospect on our progress and learnings. Every time we run a project with PPPs, we realise that they’re a gift that keeps on giving. Have you ever finished up a project, and found it tough to try and look back and figure out why a certain situation or problem came about? The PPP is a brilliant way to help with these retrospective problem-solving sessions. Once you wrap up, the PPP becomes a neatly organised, chronological history of exactly how the project ran, and what challenges were faced along the way.
  • They help us to continuously improve our planning abilities. Just as we saw with the endless series of mini-retrospectives that came from setting personal plans for the week using the PPP system, we get the same on a team-wide level with we use it on sprints. If you finish every day by planning what you’ll get done tomorrow as a team, and then return to assess this in 24 hours, you begin to receive very immediate feedback and analysis of how you’re working. As a team, you begin to notice very quickly when you don’t achieve your plans, and are in the perfect position to make adjustments to make it more likely that you’ll succeed in hitting those predictions tomorrow.

To us, at least, there have been so many benefits to using PPPs, that we’ve baked them into our standard way of working on almost all projects.

It’s a simple and hugely effective technique that more than justifies the small time investment we put into it, and we’d highly recommend it to other teams.

Read more

To find out how we started using PPPs, check out our Logbook article from 2015.