JournalMay 2015

PPPs: a simple system to boost productivity and banish project chaos

Update: Take a look at our straightforward guide to using PPPs in our Remote Work Culture Toolbox.

Have you heard of the busy trap? It’s pretty clear that many of us suffer from it in our personal lives, but I think it can often creep into our workdays, too.

A little while ago, we were using a little tool called iDoneThis, to try and break down some barriers in our team and to help each shipmate to understand what everyone else was working on. It worked relatively well, in that we definitely got a better idea of what people were doing. Here’s what one of my daily entries looked like:

Daily updates from iDoneThis

The problem, we soon realised, was that 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 progress towards the things you actually need to get done.

“The things that matter most should never be at the mercy of the things that matter least.” – Goethe

Why spend 4 hours working hard and telling yourself you’re getting lots done, if you could pick a simpler, yet far more effective way to accomplish that goal, which takes just 2 hours? Or, even worse, why spend those 4 hours working on tasks which grab your attention, if it’s compromising your ability to make progress on the really important ones?

This isn’t a case of people trying to mislead others–it’s just a natural tendency for us to get pulled off-track. Sometimes, we have to resist the urge to work on the task which lands in our inbox and grabs us…

“Besides the noble art of getting things done, there is a noble art of leaving things undone. The wisdom of life consists in the elimination of the nonessentials.” – Lin Yutang

So we started looking for something that would help us do 2 things better, as a team:

  1. To keep the whole team in the loop about the important things that each person was working on, to allow us to collaborate more easily.
  2. To help us set better personal targets, stay on track with the tasks that are really important, and plan our weeks better.

Stumbling upon a better way to plan our weekly goals

I happened to stumble upon an app called Weekdone, when I was looking for a tool to help us set better OKRs. It just so happened that Weekdone also let you track your daily and weekly progress, as well as how you were approaching your longer-term goals.

They do this using a system called “PPPs”, and give you the tools to do this, within the app.

The format is pretty simple–you have 3 categories and ‘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.
My Weekdone plans for the week

Now, the developers among you might have noticed that in many ways, this format is very similar to a morning standup in a team. And that’s intentional–it’s designed to give everyone a really clear picture of where the project is at, and it mirrors many of the same topics you’d cover in a standup.

Weekdone market their product mainly towards managers who are looking to get better insight into what their team is doing, and I suppose that’s something that you can gain from it. But even in a self-organising team like ours, where we’re working to transition all ‘management’ to be via peer and self-coaching, their product is still massively helpful.

The big thing here is that unlike idonethis, or even Asana (which we basically run our whole lives with), using the PPP system doesn’t allow you to fool yourself into equating busyness with productivity.

It’s like 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.

So PPPs turned out to be a great tool for us internally…

Let’s fast-forward a few months…

About a year ago, we were working as a product crew on a project, prototyping and iterating a new SaaS product for a long-term client of ours. We’d been working with them for years, and had a strong, trusting relationship with their product owner, who was a member of their marketing team.

All was going smoothly, and at about 75% of the way through the project, we had most of the application scaffolded out and were starting to think about tightening things up and working towards a handover.

But all of a sudden, we had an unexpected intervention… our product owner’s new boss, who had just been hired to head up their marketing department, started to get a little worried. Realising that he knew very little about this new project that was rapidly making progress, he decided to intervene and try to pause the project until he could understand more about what we were doing.

The problem, we soon realised, was that while our product owner knew exactly what was going on, and was very comfortable with the situation, other stakeholders and members of his team were out of the loop. Even with status meetings happening inside their team, the important details and decisions involved in our project were not being communicated to their wider team.

And when you think about it, that makes sense. Not everyone has the time to follow along with every project that’s happening within their company. And even if one of their co-workers is trying to keep them updated, there’s no guarantee that the co-worker is sharing the right information with them, in a way that’s easy for them to understand.

We realised that we needed to come up with a better way to clearly communicating what we were doing on the project, so that anyone could look in and understand where we were at. And so that our product owner could update other stakeholders with minimal effort.

So we modified the PPP system to use it on client sprints, too

It didn’t take us long to realise that the problem we were having with our client was exactly the same one as we’d been having internally, right before we started using PPPs. We’d been getting lots done, but we weren’t communicating that work in the right way, and this made it hard to stay on the most productive track and share our progress with those who needed to know about it.

And so, we began to try and use PPPs on our client projects, too. We took the same method and started lo-fi, using a simple Google Document each day, to prepare better daily updates for our clients.

We’ve iterated this quite a bit, to get to our current system, but at its heart It’s all very simple, and not so different to how you’d use PPPs if you were working on your own tasks.

Here’s how we kick off day 1 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.

Posted by
Jon Lay

Jon is a Partner at Hanno. He wears many hats, but his primary focus is on leading our engineering and technical operations.