Learn the Weekly Rituals You Should Master as a Software Project Manager

Why a month, as opposed to something sooner or later? The short answer is that this is what I've seen both with my own experience and with evidence from some limited data I've seen. You can read more about this in my post on milestones, not projects. 

I recommend getting the product manager, designer, and people who have thought the most about the technical contours of the project in a room, and telling them you'd like to identify a milestone: "What would the best milestone be that is less than a month away? Let's come up with a few possibilities, and choose the one we like best." 

Start with the constraint that you always need a milestone that is less than a month away. If you don't have one, or you're about to finish a milestone, make sure you have the next milestone identified. Refer to that milestones post to learn more about the art of breaking up projects, and also remember that this is a real skill that takes time and practice to develop.

2. Update Your Project Plan

I book time every week to update my projects. I review the project plan and make sure it reflects my current thinking. I ask myself if it still seems realistic. I think through the rest of the project and think about potential sources of delay and risk. 

Wishful thinking is your enemy. Look at everything from a skeptical perspective. For some people, this is natural, and for others, it requires practice. 

You will often need information from others in order to update the project plan. I usually schedule a weekly meeting per team, or per project. At this meeting, I have the main leaders present, walk them through the next couple of weeks in detail, show them my current thinking on the project plan, and ask them to critique it. I then go through further out into the future, but with a little less fidelity the further out we get. Usually, I invite someone representing product, technical leadership, and design. 

Try to keep these meetings pretty high level. You want them to not be a huge waste of time for the participants. I often find it best to join this activity into a meeting that has a larger purpose. For example, a local team's leadership meeting might cover this in 5-10 minutes every week, but the majority of our time we might discuss other matters, like the things we're concerned about or need to improve.

One anti-pattern for project managers is that you can get into a habit of pinging people for information all the time. This is annoying at best. Make it inexpensive for people to keep you informed. And also encourage people to surface what they're observing, so you don't have to update them. Switching communication to push from pull is preferable. 

What Should the Project Plan Look Like?

I make project plans that are week by week. Each week has a couple of bullet points. The bullet points are things we plan to demo that week. The demos should include technical demos, but the description of what we will deliver should be as customer-focused as possible. 

I also add time-based events that are relevant to the delivery of the project. For example, vacation time, on-call schedules, and offsites.

The goal for your project plan is to not be more specific that a couple of bullet points. You want a plan that is easy to change. The more specified your project is, the more expensive it is to alter it. A good project plan should be a tool for discussion and one that encourages change rather than discourages it. When I see lots of project artifacts, and things that require updating, I get skeptical. Gantt charts communicate effectively but are often a sign the underlying data is hard to change. 

One thing to watch out for is many engineering teams work on a person per project. The more you can use the team as a unit of delivery for your projects, the better. This is a deeper topic, so I won't go into a lot of detail now, but in general, when I see project plans that specify what each person is doing, I view that as a sign that the project is unnecessarily brittle, and a team that is overly specializing, and not doing enough knowledge sharing. This can be appropriate for small companies, but otherwise, I tend to discourage it. If I see the fractional allocation of "resources" in a project, I typically scream, take a lighter out of my bag, set my hair on fire, and run out of the room. The fewer projects you're managing, the better you'll do with them, so that's another argument for teams focusing on fewer projects.

People ask if you need a week-by-week project plan if you're on a team that has two-week-long sprints. Of course, it is up to you, but I would do it week by week. Otherwise, you have very little visibility into whether things are on course or not. If I were doing it on a two-week-long sprint cadence I would tell the team that this is a plan showing whether or not we could demo this by Friday every week. 

3. What Should Your Risk Registry Look Like?

As you update your project plans, you should also ask yourself what could go wrong. Here are a couple of ways to ask yourself, or others, questions that will help you plan better:

• What is most likely to go wrong with this project? 
• What projects have been similar to this in the past? What challenges did we have with them?
• What's the worst-case thing that could happen on this project that seems like it could actually happen?
• If we had to bet this month's salary on this project going well, what are things we would be worrying about right now?

Risk management is a balancing act. You don't want to overinvest in many of your risks, but you do want to think through them. After you come up with new risks, list them as bullet points in your risk registry. 

For each risk, you or your leadership group should determine if you want to take any action to mitigate that risk. Next to your risk registry, list your plan next to each or write down, "accept risk."

If your leadership group is functioning well, you can have rational discussions about the risks, and the cost to mitigate the risks. I suggest when you introduce a risk registry, you have a conversation about the costs of mitigation and be sure to have conversations about not just how you'll mitigate risk, but whether you even want to.

4. Write a Weekly Project Update

After updating my project plan and risk registry, I have a good idea of the current state of the project. Now I help the people around me by sharing that state, in as concise a format as possible.

The aim of a weekly project update is not to share everything about the project. It's also not to show how great your team is. When you approach project updates from either of those perspectives, your writing becomes excruciating to read. Instead, you should focus on the needs of your reader, and give them just enough information that they can come to you if they need, to have a longer conversation.

This tweet summarized a lot of the things I've learned over the years about writing concise, readable updates. It also features some wonderful examples, so I strongly recommend reading through it:

One thing I'd like to emphasize is that you should come across as a neutral party: objective, upfront about risk, and exposing things without bias.

Your update should include a link to the source of the information: the project plan, risk registry, and a link to demo the current state of the project.

After you write your update, send it to your stakeholders. You can use a mailing list or a channel in Slack. You want to make it easy for new people to follow the information. You'll probably be surprised who finds it useful. You might find other parts of the company that find your updates useful. 

These updates help the people around you to be effective. Your manager will be informed about the state of the project, so they can represent your work in meetings (you have no idea how helpful this is for them). Other teams that depend on you won't have to contact you to get updates. It provides a very nice communication scaffold. You may even get thank you notes!

Incidentally, these updates help demonstrate your ability to manage the project. 

I find the project updates to be a good forcing function for doing the rest of the project management. Knowing that I have to send out my weekly update forces me to take the time to do everything else. 

Ideally, the update should be just a tweet or two in length. You don't need a lot of detail: people can talk with you if they have questions.

Thank You

I've had a long history with project management, even writing project management software in the past, but Bjorn Freeman-Benson really hammered into me the details of how to write a good update. He acted as an editor, training me each week on how to do better.