Introduction

I have often seen engineering and product teams making commitments in the absence of resource planning. Most companies I work at have followed quarterly planning. It's important when doing planning at any interval to have an idea of what is possible. This is the point of resource planning. Without taking stock of your team, their capabilities, and their upcoming plans, you are going to head into the quarter blind.

Importance of Goals

In an upcoming blog post I will talk about the importance of goal frameworks. OKRs are the framework I recommend, but there are other options. The important thing is to have a goal with measurable key results. Goals give you the ability to aggressively prioritize what must get done. They must be at least briefly mentioned.

Overview

There are three key steps in my quarterly planning.

1. Resources
2. Projects, Tshirt sizes, and priorities
3. Connecting resources to projects

Resources

Resource planning will take into account onboarding, ongoing maintenance, out of office time, and any other factors that your team can capably predict. The amount of time your team has can then plug into the projects the team wants to accomplish in a given quarter. Let's jump into a toy example.

I have four developers on my team. I know one of them is onboarding during this quarter and one of them is taking a vacation. Our team is growing so we have interviews. Oh and our product is bursting at the seams with maintenance. Every week we have to dedicate time to fixing bugs for our sales team.

Onboarding Planning

I assume that an onboarding developer will not be able to contribute for at least 60 days. Realistically they should be contributing something by day 30, but they typically also will require time from other developers. So they are going onto my planning as a 0 for the first 90 days. Then I will ramp them up to be producing at a .8 person week at the 90 day mark.

Out of Office time

Ask all your team members what their upcoming calendars for the quarter look like. If someone is out of office for a week. They are a 0 for that week. Simple, but effective. I also schedule 0.05 off every person because I know that people have appointments, get sick, eat lunch, use the bathroom, and tend to their families.

Maintenance Time

Maintenance must be accounted for during resource planning. If I'm new to a team I assume that 20% of their time is dedicated to maintenance. You can customize this using your gut instincts, or even better would be having data to back this up. Base camp actually defers maintenance during their 6 week product cycles. They spend 2 weeks at the end of every 6 week cycle doing bugs, so they might not even need to schedule maintenance time.

Putting it together

Now that we have allocated time for maintenance, OoO, and training, we can get a total amount of time (in person weeks) that we have available for the quarter, week by week. This will become an input to our actual project planning.

Projects and Tshirt sizes

It's important to know what projects have to get done, when they have to get done, what their priority is, and roughly how big we think they are. Estimations are guaranteed to be wrong by definition, and also because product development is overly optimistic by nature. You need to get your lead engineer, or the team to provide estimations at a weekly scale. I ask for a number of single person weeks between 1 and 12.

Project fidelity

Your team won't have all the details on projects at this stage most of the time. Estimation is an art form and the best lead engineers can get reasonably close. Make sure all stakeholders watching this process understand that estimations will be wrong and are subject to change.

Accounting for optimism

Teams in my experience always underestimate, no matter how good they are. I always multiply my teams estimations by a 1.2. The adage of underpromise and overdeliver is critical. You might have board members or sales depending on projects being done by the time you specify. You don't leave the house for a wedding 1 hour away, exactly 1 hour before it starts. You provide buffer because it's wise. It's different than sandbagging. Ultimately teams are expected to develop "as fast as they can" anyways, so if you happen to finish early, that's fantastic, move the schedule up. Don't finish late, but if you do, overcommunicate. The output from this exercise gives you the means to communicate EARLY when things are going wrong.

Connecting resources to projects

Connecting resources to projects is what matters. This process forces stakeholders to consider what priorities are most critical. By saying yes to one project you can literally see another project bump down. If someone in the middle of the quarter asks you to pause work on something for another project, you can confront them with this gantt chart to make sure the impact is understood. We are here to make our companies, stock holders, customers, and ourselves successful. This is about protecting ourselves from unrealistic expectations, and making sure that we can deliver on our promises.

Prioritization

The most important projects go at the top. You now have the estimated amount of time the project will take, even accounting for optimism. You have the number of person weeks available for any given week. Lay out where the project falls week by week in this quarter.

Maintenance period and QA

Teams also need to account for QA and maintenance after release. I know from experience that the most important bugs to fix, and the most common bugs often relate to recent releases. You can't ship a feature and walk away. There will be rough edges that should be fixed immediately. There will be breaking bugs that can't be left alone. This is a special category of bug in my planning, and I allocate time for it. QA also must be accounted for.

Time committment

This process should not take days. It should be possible to do in hours. The meetings might happen over a week or more, but the amount of time dedicated should not be large. I prefer in many cases to have the PM, Designer, and Lead go through these exercises independently, then conduct a review sign off meeting with the team at large. This saves wasted time on meetings and most engineers depend on their lead for the estimations anyways. It is critical that the team has buy in on the plan, so it's also acceptable to perform all steps together.

Resource Planning should only take the lead engineer an hour of their time. Typically your PM and lead engineer have a reoccuring 1-1, this is the right time to discuss the resource planning.

T shirt sizing can take less than an hour if projects are reasonably described and scoped by the PM.

Resources to projects can happen by the lead engineer / pm working together. This might be several sessions as the details evolve. By the beginning of the quarter the gantt chart should be locked down.

Ongoing Maintenance, what comes next

I create a new sheet each week and updating the actual vs the predicted. This allows me to easily keep track of where projects are at. I stay on top of communicating any changes in the schedule to ensure people understand that projects are in good hands. This builds trust and confidence, and prevents miscommunication. Updating the sheet weekly takes less than 10 minutes for me. At a minimum you should create an end of the quarter sheet and compare the beginning of the quarter to the end of the quarter. Do a retro with your key stakeholders and look for opportunities to improve.

Summary

This exercise provides accountability, growth, and protection. You will not need to spend a large amount of time to enter the quarter prepared. You can adapt without sacrificing communication. You have a realistic document to point to when you are saying no to something. You can explain why something is going to take the time you expect. Dial in your estimations as you gain more information. We can explore how to improve these week by week in a future article. If you like this process feel free to grab my excel template. We also do talks and consulting, feel free to reach out at https://www.rune.tech/contact.