In a rush? I’ll email you a copy of the project status report template, an instruction slide, and a full video walkthrough for free. Fix my project reporting
If your product management team is anything like mine, you:
- Constantly have to work to keep stakeholders on the same page and up-to-date on what’s happening
- Spend more time on project management than you’d like to
- Would much rather be product managing than project managing (but someone’s got to do it, right?)
Well, the report for keeping stakeholders across project statuses at our company was broken. Of course, conversations are a vital piece of the puzzle, but it helps to have a central report to speak to (and share asynchronously – especially as a remote team).
It felt like a chore to update the report every week, and in a way, we felt like we were micromanaging ourselves…
Inspired by Shape Up, I spent a couple of hours while watching TV reworking our reporting process, and it’s already shaping up to be a game-changer! (pun intended)
The book is filled with excellent tools and frameworks, but we had to start somewhere. After all, I’m a product manager, so I can’t help but prioritize.
Our project reporting process was broken and tedious
As our team had grown, our project reporting process hadn’t. For the most part, we’d walk key stakeholders through the status of our projects in meeting once per week. As we grew though, this became time-consuming and was starting to feel rushed even in a 90-minute meeting. At the same time, we’d grown to have team members in NYC, Europe, and Australia. This meant we could never have everyone in the same meeting – so we alternated week-to-week.
We needed a way to document and broadcast the status and progress of our projects
The reporting document we were using was focused on:
- whether the project needed external intervention
- when it was scheduled for completion
- what work was done last week; and
- what was planned for next week
It caught a lot of the detail but lacked a lot of the essential but abstract aspects like risk, uncertainty, and progress against the high-level goal.
We felt like we were micromanaging ourselves
The old method wasn’t terrible, but by listing the tasks completed and tasks planned every week – we spent a lot of time in the detail and discussing what was happening next instead of the bigger picture. Plus the details were already captured in Jira.
We want to spend our time talking strategically about our project dependencies and our rollout plans, but we’d get stuck in individual tasks and why they hadn’t been completed in the time originally planned.
After reading ShapeUp I knew we could take inspiration and fix our project tracking process
Each and every chapter of the book was filled with great ideas that I wanted to try out in our team (and have started to) – but the section on showing progress stood out as an approach that could help us better report on our projects.
The chapter on “showing progress” inspired me the rewrite our process and project status template…
Ready to skip to the good stuff? Grab a copy of the slide templates, instruction slide, and walkthrough video. Just enter your email address, and I’ll send it over.
We use Atlassian’s Jira extensively across the business, so we couldn’t just switch to Basecamp
If you’ve read the book, I’m sure you’re thinking, “why don’t you just use Basecamp?”. Basecamp is literally designed to streamline this process, and they even have a chapter dedicated to putting the system to work in their product.
Our company is a massive user of Jira across the business (not just in product & engineering, but publishing & editorial too). So bringing in a new software tool wasn’t on the cards.
I thought about using Jira but got stuck on the 3-tier hierarchy since sub-tasks are kind of a pain when it comes to reporting. It also felt like it would end up a lot of work to maintain and honestly felt a bit over-engineered.
We were already using Google Slides to manage many of our internal reports and presentations (a little more engaging than a written document – sorry Jeff Bezos), and so I figured we could try and stick with the same tool. But, I wanted to start from first principles.
I focused on the content first and listed out everything we needed to know about a project’s status
When working on a product, it’s easy to start sketching out wireframes early in the process. But a lesson I’ve learned is that if you jump into the visual too soon, you’ll compromise the output because it’s easy to make tradeoffs based on appearance rather than merit.
Since this report had to fit on a single slide, there was a design element to it. But, I didn’t want to fall into the trap of designing too early. I opted to just start with a handwritten list of what we need to know about a project.
It’s tailored to our company, but I think it’s relatively universal.
I started with the “who, what, when, why” and built a list from there.
Then I ranked each one by importance.
I started sketching out ways to convey this information in a clean and concise layout
I knew I wanted the hill chart to be the focal point. This is the primary tool from the ShapeUp chapter I mentioned.
Simply put, the hill chart represents the projects as a hill with two main phases: uphill and downhill. In the uphill stage, you’re still discovering everything that’s required to complete the project, and you’ve got unknowns and risks to mitigate. In the downhill phase, you’ve identified all the work to be done, and now it’s just a matter of executing and checking off all the items on the checklist. In both these cases, ‘you’ refers to the team on the project.
The best part of hill charts for me is that they incorporate the uncertainty of a project in its early stages. In a typical project, you create an initial set of tasks to be done. But, once you start really start the project, you realize there’s other work you didn’t think of. It’s a normal part of the process. You’ll discover extra work you couldn’t have anticipated, especially when working with legacy systems or as a newly formed team.
I did feel like one thing was missing, though. When managing a project, it’s important to see progress over time. Sure you could reference between each week’s slides, and some stakeholders would even commit it to memory, but that’s a lot of work.
Instead of deleting the marker of progress each week, we’d duplicate it and make last week’s gray. That way, you could see all the previous stages of the project and get a clear indication when a project was stagnating – or regressing.
I built out a slide for my project’s update this week and did so in a way where I could (if others liked it) lockdown most of the formatting into the slide template. Why? To save a bunch of busy-work and ensure consistency – making it easier for readers to consume the information because they know what to expect and where to find everything. They can build a rhythm as they go through the 10+ slides.
Worth noting: we’re a semi-remote global team, so we discuss project status one a week – but since I’m in NYC, I only attend every other meeting.
This week, was a project meeting where I don’t attend BUT I wanted to get feedback on my new slides. Rather than waiting for next week, I decided to try something novel and just put my new slides into the old deck and see what people thought of them afterward. It would definitely demonstrate whether they could stand on their own!
Turns out they really liked them. The first task on the meeting notes was for everyone to migrate their slides to “Bryce’s template.” Thanks, Ryan Singer!
We’ve been using them a couple of weeks now, and the dynamic of our project meetings is way more engaged and productive. This small change in our process has had a profound impact. Highly recommend you grab a copy below and try the project cards in your own team! 👇🏻👇🏻👇🏻
Put this system to work in your own team for free! I’ll send you a copy of the slide template, a detailed instruction slide, and a walkthrough video. Just make sure to thank @rjs on twitter.
But wait, there’s more…
I’ve read the whole book once already, and this is my implementation of one small piece of the book (it’s just a small slide of one chapter). I’m already working on ways to implement more aspects of the book in our product management process. If you haven’t already, go read the book for yourself – it’s probably one of the best time investments you could make.