Before I start explaining how I do project management, I think it’s important to understand why you should even bother doing that.

I'll cover:

• The planning spectrum
• How I see project management
• Planning for maintenance work
• Planning for strategic work
• Make it visual

As I see it, project management falls in a spectrum.

In one end of the spectrum you have groups that don't do estimates at all. At the other end of the spectrum you essentially groups that operate in full waterfall model. Everything is planned upfront, and once you start executing, you don't go back and review the plan.

Project management is usually boring, so working with no plan seems a very cool thing. It makes it seem that you can work on whatever you want. But if you're working as part of a larger group, or on something that is used by other people, that almost never happens.

Most often than not, when you're about to start working on something you're interested in, some small fire starts and you need to jump on it.

When the project you're working on is successful, this starts becoming the rule rather than the exception. Sometimes there are even multiple fires going around and you need to find ways to duplicate yourself to be able to tackle them all at the same time.

So without a plan, your work becomes more like a firefighter. You don't get to control when someone needs your help. But as soon as someone calls, you need to be there in your best suit, to help people with what they need.

In the beginning this might feel fun. It might seem that your job is really important and you're having an impact in your project and users. But this doesn't really scale, so as the company and demand grows, you'll end up working more hours and hire more firefighters to your team.

At the other end of the spectrum you have groups that plan a lot upfront before starting to execute.

In environments where there's no trust, people plan mostly to protect their own ass. If you present a plan that everyone agrees, and you've executed that plan and delivered your part, no one can really blame you if the project fails?

But planning is also useful when there's trust between the teams working together. If you're doing consultancy, or shipping a project that requires coordinating multiple people, planning is a good way to estimate how long it will take to complete the project, and how resources should be allocated to the project.

My approach to planning falls in the middle of this spectrum. I think the biggest competitive advantage you can have as a person or a company is your ability to react to changes. And changes are interesting because you can plan for them, but your plan will almost certainly be wrong.

So I plan, knowing upfront that my estimates are going to be wrong, and I'll have to change my plan in a matter of days or weeks.

So why plan if I already know that my plan is going to be wrong? For me, planning is there so that I can:

• Understand the big picture
• Focus on the big picture, not fires
• Do resource allocation
• Give visibility to others

When you're working on a successful project or with multiple teams, everyone will have a different opinion on what your team should be working on. If you're part of an horizontal team like UX, docs, or any other team that serves multiple other teams, other teams will also try to influence you to work on something different.

It's natural that every team thinks their project is the most important one and is also understaffed. So if other teams see the value in what you do, they'll constantly try to pull you into their projects.

Of course you won't have time to do everything, so you need to decide where your work is going to have the most impact for your users. A good way to do that, and get a pulse on the big picture, is to start planning.

When you create a plan, you get a better understanding of the big picture and company priorities, which in turn influences your plan.

With more and more fires to put out as time goes by, you might feel tempted to only work on those things that need immediate attention. It feels stressful having to act fast to not let issues affect users, but it also feels comforting in a kind of strange way.

I mean, it's way more comfortable to work on issues that are clear and well defined. After you've solved these issues you can cross them from your todo list and feel that you've made progress.

It's more difficult to plan and work on problems that are not neatly defined and that you'll only be able to cross them from your list a couple of weeks down the line. And if the plans and priorities change, maybe you'll not even get to work on those and cross them from your list.

But if you're lucky and are working on a successful project, this is exactly what you need to do.

If you're working on a project that is growing at 2X This means that next year, you'll have more users that you've ever had before. All combined. If you're spending your days putting fires all day long, you're probably not preventing new fires from happening.

If you have multiple members in your team, planning is a good way to inform where you should deploy each team member.

Once you know which projects are more complex or have more risk, you can decide to deploy more team members to be sure the project is successful.

You can also use your plan to allow team members to rotate across projects, and ensure team members keep learning and growing, and maintain a low truck factor.

Once you have a plan you can share it with your stakeholders, so that they have visibility on your progress, what you're working on, and the trade-offs you're making along the way.

Sharing your plan along with the rationale you've used to created it, is a good way to ensure you're spending time doing what matters most to your users, and not on a specific project.

80% of the discussions I had where people complained about the quality or speed of the documentation or training my team was delivering was because these people didn't have visibility into what we were doing and our priorities.

Once I shared my plan and rationale with them, most of them would agree with the priorities or gave us resources to solve something that was low priority for me but important for them. Other times I would understand how something I thought as low priority was having a real impact on our users, and reviewed my priorities.

Now that you understand my approach to planning we can dive deeper and check how I create a plan.

We already brushed this, but I think that there are two different types of work. Maintenance and strategic work.

I call maintenance work, to the work that you need to do to put the current fires away. These are tasks that you probably are already tracking on Github, Jira, or any other tracking system.

I call strategic work to the work that you should be working on to improve your product, or prevent fires form happening down the line. If you don't plan upfront, you probably don't have this planned anywhere.

Maintenance and strategy are so different that I plan differently for both types of work.

I think planning for maintenance work is easier, so let's start with that one.

My rule of thumb is to only spend 20% of my time doing maintenance work, I address this with a timeboxing strategy.

I work 40 hour weeks, and 20% of that is a full day. So I try to schedule a fixed day on my calendar to just focus on this kind of work, and try to avoid working on these tasks on other days of the week.

If you commit to only do maintenance work during this day, you'll start noticing that it's difficult. There's always a new fire or someone asking you to do something. Even when no one is asking you to do something, you'll always find small things that are broken and you'll feel like fixing them.

To force myself to work on maintenance issues during maintenance day only, whenever I find something that needs improvement, I file an issue. And when someone tells me about something that's broken or needs attention, I teach them how to file an issue, or create one myself and share it with them.

If you do this consistently enough, it sets the expectation to the rest of the group that there's a single channel for making requests.

I like GitHub issues, but I don't really care which tool I use for tracking issues, as long as anyone in the company can file new issues and search for existing ones. This ensures that more people can add relevant information to the issue like workarounds, customers that are blocked by this, and other information that you can use to prioritize the issue.

Also, the easier it is to file an issue the better. When your company is growing fast, you won't have the time to train everyone and teach them how to file issues. Most probably you won't even know that new people joined in other departments, so having a trivial way to file issues is the best way to ensure you're collecting feedback from every corner of the company.

Once everyone is trained to file issues, you'll start accumulating a long list of issues. After a while you have so many issues that you could spend your entire 20% time just trying to understand what each issue is about. So you need to ensure that your issues contain meaningful information, and can be understood by someone that doesn't have any context on what the problem is about.

And there are only two ways to do this:

• Triage frequently
• Triage in bulk

I tend to prefer the first approach.

I keep an eye out for incoming issues and try to triage them as soon as possible. For me this works better because I prefer spending a bit of time upfront cleaning the issues, than having to spend a lot of time just doing that.

Most importantly this gives the perception to others that you're paying attention to their requests. You're not telling them that you're going to solve their problem, but you're acknowledging their problem. It also ensures they still have the problem fresh on their mind, so they'll be able to give you more information if you ask for it.

If someone filed an issue that a command is not working, they'll usually be able to tell you the exact command if you ask them after they file the issue. But if you only ask them a week later, they'll probably not remember the command they were trying to run.

Here are some guidelines I use when triaging issues:

• Anyone should be able to understand the problem just from the title
• The description has information on how to reproduce the problem
• I apply meaningful labels like which product or area the issue relates to

The next step is to prioritize the issue.

If you're using Github issues you can apply priority labels like P0, P1, P2. Most often than not, you'll notice that you'll have a ton of P0s around, and that not P0s are the same.

That's why I prefer something similar to a Kanban board, where all the issues can be stacked and sorted on a single column. When you have multiple P0s, you're still forced to decide which one to put on top.

You can install a chrome plugin called ZenHub that allows you to do this with Github issues.

But you still need a way to sort and prioritize issues, so what criteria to use?

To prioritize maintenance issues, you can use a simple framework that most support teams use. You just need to know

• How many users are being affected by this issue
• Is this affecting a critical workflow, like a trial or going to production

It's fairly intuitive. If an issue is affecting tons of users on a critical workflow, that issue has the highest priority.

I don't do this, but if you want to make this a bit more formal, you can also create a scale from 1 to 5 for both of these vectors, and multiply their result to get the final priority for the issue.

To get a pulse on what's affecting customers, I also keep an eye on

• Slack
• Forums
• Twitter
• Stackoverflow

I might not reply to all of the questions I see on these channels, but I can start building a mental model of the impact issues are having on users.

I also make sure to have formal and informal sessions with

• Support - they're the ones finding problems all day long
• Training - they're the ones teaching new users all day long
• Solution engineers and architects - they're the ones using the product
• Product managers - They're the ones hearing the complains from all these groups

I maintain weekly 1:1s with some of them, and go out for lunch once in a while with the others.

Having a prioritized list of maintenance issues makes it easier to ramp-up new contributors.

Instead of letting new contributors wonder around the code base, you can give them maintenance issues. This allows new contributors to focus on a specific task at hand but also have total ownership of the end result.

By solving maintenance issues new contributors have to learn the tooling the rest of the team uses, will start learning about the style and conventions used in the code base, and will be able to receive very specific feedback about their proposals. They can also learn how to estimate their work and refine their estimates since the scope of these issues is fairly closed.

You can assign several maintenance issues to new team members that are of increasing complexity and broader scope. This allow new members to have mensurable and structured milestones.

The only caveat about using maintenance issues for ramp-up is that you need to always keep in mind that this period is explicitly used for the new team member incubation. Don't fall in the trap of only letting them tackle maintenance issues. You didn't hire that person for that.

Planning for strategic work is a bit more interesting because you're planning for things that don't exist yet. This means that the scope of this work is ill-defined, and there's definitely more risk involved.

But that's ok. It's better to be working on something you know your users want, even if you're not absolutely sure what that is, than to complete all the items in your todo list, feel good about yourself, and only have a marginal impact on your users.

When planning strategic work

• Identify milestones
• Create a definition of done
• Define the MVP
• Identify risks

I start planning for strategic work by identifying milestones.

Milestones are important dates in your project. Usually I keep track of Beta releases GA releases * Conference dates

But milestones can be anything really. If you’re doing agile, the demo at the end of the sprint is also a milestone

Even when you don't have delivery dates for your project, it's always useful to create them so that you're forced to prioritize what matters and what doesn't.

Planning forces you to look at the tasks you have in your head and put them on paper. When you do this as part of a team, you start noticing that the descriptions you create for tasks might not be so obvious to the rest of the group.

This forces you to go back and forward and identify a list of tasks that need to be done, but also define how to tell if a task is completed or not.

Most times, after you've identified all the tasks that need to be done for the project, and you start estimating them, you'll notice that they extend far beyond the delivery date that was set for the project.

This is scary at first, because it makes you feel that the project is already behind and you haven't even started. But at least you're now aware of everything that needs to be done, so you can revisit the plan and start cutting.

You'll be forced to define the Minimum Valuable Product, and what are improvements that don't need to ship on day one. If you're a perfectionist like me, you'll never be happy in doing this, but this is what allows you to deliver what your users need first.

Once you've identified the tasks that you need to do for the project, you need to estimate them.

You can use story points for this, is is a time-agnostic way of estimating the complexity of a task. But I prefer estimating in days. I know most of my estimates are going to be wrong, so I don't spend time deciding if a task will take 5 days or 5.1 days.

To avoid these kinds of discussions, I use a discrete scale in days:

• 0.1 - around 1 hour
• 0.5 - around half a day
• 1
• 5
• 10

When you identify all the tasks that need to be done, you'll notice that some tasks are not obvious or you depend on other teams to do something for you but you don't control those teams directly.

These are tasks that introduce risks to the project and might cause it to slip. But just like a daemon that you can exorcise after you know its true name, risk is more manageable once you know it's there.

You can allocate more time to solve tasks with higher risk, follow their progress more closely, and create a plan B if something goes wrong.

Due to it's nature, strategic tasks are not very repeatable. This means that you won't get a lot of similar tasks that allow you to refine your estimates.

This also means that your estimates are going to be wrong. If you overestimate, you'll deliver your project on time and still have time left to do things that are outside the MVP, which is always great because you'll be shipping a more complete product.

But if underestimate, you'll have no time to do everything that needs to be done before the deadline.

You have no way to know if you're overestimating or underestimating your work, so just to be sure you'll be able to deliver everything on time you should include some buffer time in your plans.

There's two ways you can do this. You can either extend your estimate for each task by a bit, or you can add some time at the end of the project, and make sure it is the last task before the deadline.

Since the plan changes often, I prefer the second option. I review the time it will take to complete the project, and add buffer that is 5%-10% of that time to the end of the project. This value is totally arbitrary, keeping buffer time between 5%-10% ensures I can still deliver on time but give me enough feedback at the end of the project so that I know if I'm overestimating or underestimating.

Even though every strategic project will be different, it's still good to try to refine your estimates. If you're planning with 20% buffer times, even if you constantly underestimate all the tasks, you'll have enough buffer time to not be stressed when you start getting behind your plan. So you won't improve the way you're estimating work.

One of the goals of planning is being able to share your plan with others. But most times your stakeholders only care about the big picture, not the details.

You could share your plan with them for example on an Excel spreadsheet, but that makes it really difficult to see the high-level picture of the work that you'll be doing and the milestones ahead.

So the best way to share a plan with others is to make it visual. I use Gantt maps for this, but keep them lightweight.

I keep a track for maintenance work, and as many tracks as needed for the several strategic projects. At OutSystems I had a track for

• docs
• training
• curriculum development

At Docker, I have one track for UCP and another for DTR

And don’t forget to share your plan with others. Even if you have a plan, others might not know about it, So you should take every opportunity available to tell everyone about it.

This allows other teams to know where you’re spending time, and you’ll be able to collect feedback in your Prioritization. If you’re lucky enough, others will start using your plan and will tell you when making a decision That impacts your plan.

If you liked this post, and want to learn how to build better products, maybe we can meet at Fluent. I'll be explaining why you need docs to cross the chasm.