Today, I’ll share a few thoughts on what makes a good project plan. And I’ll provide a sample project plan.

Why have project plans

Many agile teams focus on sprints or chunks of work. But they don’t really plan — instead, they do what they can each sprint, plot out their velocity, and determine what they can accomplish over the next sprints.

This is fine, but project plans are a tool for getting you to think about the contours of your projects. They have the following advantages:

• You can play with different ways of structuring the project, so you can sequence the value of delivery easier. This makes it easier to play with scope, incremental delivery, and to adjust to changes.

• You think through risks better with a project plan. You have to explicitly list things like when people are on vacation or on call. This can result in better planning.

• Many teams use sprint cycles or kanban cycles that are longer than a week. Weekly project plans give you more frequent signals if you’re on track or not.

• Sprint plans track all the work, which is useful. But that also makes the plan harder for stakeholders to understand.

Keep your project plans simple

Typical failure modes for project plans are no project plans at all, or overly complex project plans.

Complex project plans…

• can have many project artifacts.

• require time to keep up to date.

• can be brittle, requiring fixes or maintenance. They are highly dependent on the person who made the plan.

• sometimes create the illusion of more certainty. For example, the project “will be done in 23.53 to 27.55 days”.

I know a project plan is in dangerous territory when I see people allocated as fractional “resources”. Or when the plan is something that only one person can update.

Why keep it simple

One of the dangers of plans is that they can cement things into place. You want a project plan that allows you to make changes in seconds, not minutes or hours. Most complex project plans disincentivize change.

You also want a project plan that clearly communicates. An outside observer should be able to look at your project plan and figure out what will happen when. This requires the right altitude. Keep it simple.

Qualities of a simple project plan

Here are some things I recommend in a simple project plan:

• Make it week by week. List out what should happen each week, with a couple of bullet points. Doesn’t need to be more complex than that. What should the bullet points be? Things you will demo at the end of each week.

• Estimate milestones, not projects. You should plan milestones, not projects. Yes, a high-level project plan can be important, but you also shouldn’t overinvest in it by planning out the whole project in advance. That prevents you from making changes to sequencing or adapting based on things you’ve learned. You should make a high-level technical plan, and make a list of sequenced milestones. And to estimate the overall project, you might do some high-level estimates. But I recommend only having a week-by-week plan for the current milestone. [Does that mean these are really milestone plans? Yes, but I call them project plans anyway, because that’s what people are used to.]

• Milestones should be less than a month in length. See the milestones post for more details. The key insight here is that small projects typically go way better than large projects, so make all the projects small projects.

• Combine plans with weekly communication. It’s helpful to combine project plans with project reporting. Use a style of communication that is concise, represents the state of things dispassionately, surfaces risks, but maintains a “I’m taking care of things” tone. Combining plans with project reporting ensures the plan will be updated at least once a week. I’ll write about project reporting soon.

• Make text-based plans. I’ve found it more useful to have project plans be text-based, rather than tied to tooling like Jira. Tooling-based approaches are fine. But text-based approaches force people to think through everything differently. You can use links to link to sprint plans or individual stories, or whatever. But it keeps it easy to understand for someone not aware of the project. I sometimes don’t insist on this, but it depends on the circumstances.

Weekly project plan template

This is for a milestone within a larger project

Week of Jan 4th

• Single chart shows up in Slack. Data is canned.

• Schedule risk: we’re validating our list of chart types are all technically feasible. We’ll demo outcome of that investigation.

Week of Jan 11th

• Chart data reflects live information, and is functional in Slack chart.

• Additional chart type shows in Slack room, with most basic visual design.

• We’ve shown to at least one alpha customer for feedback. We start sharing with them every week from here on out.

• Jessica is on-call and doing interrupt-driven work for week.

Week of Jan 18th

• Most important feedback from alpha customers incorporated. Other work is prioritized to future milestones.

• Last chart type added.

Week of Jan 25th

• Holiday Jan 26th.

• Charts look great and are thoroughly tested, instrumented. We’ll show usage dashboards.

• Release end of week.

Thank you

Thanks for putting up with the click-batey title. It’s truly terrible.

This post originally appeared at https://www.rubick.com/weekly-project-plans/

You can subscribe to my weekly newsletter there, and receive a post on software engineering leadership once a week.

Image by Gerd Altmann from Pixabay