IT Management: Capacity planning
You need a data-driven system to perform effective and accurate capacity planning for project workloads.
Ryan Haveson
My favorite line from “Star Wars” is when Luke tells Yoda he will try to raise his fighter from a swamp using The Force. Yoda famously chastises Luke by saying, “No! Try Not … Do, or do not … There is no try.” It turns out that this is pretty relevant advice for software engineers.
As a team leader, one of the worst feelings you’ll ever have is when you realize your team is going to miss a deadline. This is a bad situation for many reasons. As you approach the deadline, people will have to start working extra hard. They’ll be trying to make up the lost time, sometimes even working nights and weekends. On top of that, you often have to cut corners in these situations. This means the quality suffers.
When the deadline comes and goes and the project still isn’t complete, there are no medals handed out for that extra hard work. There’s only disappointment that you missed the deadline. And as if that wasn’t bad enough, with all the corners cut in an attempt to make the deadline, the state of the code is likely less then optimal. The result of all that “trying” ends up being a bad taste in everyone’s mouth, along with a sub-standard product.
One of the hardest lines you have to balance as a manager is when you have to push people to take on aggressive deadlines, while at the same time being realistic with how much work people can take on. Estimating work is difficult. This is one reason people use Agile, because you don’t have to be particularly good at capacity planning.
That said, any multi-month project requires setting expectations on what the end result is going to look like and how much effort it’s going to take to get there. While mastering capacity planning takes years of practice, one telltale sign that people are taking on too much is when you hear the words, “I’ll try.”
Do your best
When someone tells me, “I’ll try,” I immediately translate that in my head to, “I will do my best, and if I don’t get it done I will at least have worked long hours in my attempt. But don’t hold me accountable if I fail.” This is a tricky one to manage and respond to appropriately. On the one hand, you don’t want to dampen anyone’s enthusiasm for pushing themselves or for taking on assignments that stretch their capabilities. On the other hand, teams and leaders are held accountable for results, not for efforts.
When someone tells me “I’ll try” on a mission-critical task, I always respond by saying that it’s better to say “no” than “I’ll try.” I can plan around “no” in myriad ways. I can add more people to the project. I can change the scope of the task. I can look into the details and clarify ambiguities to make the task easier.
There’s no easy way to plan around “I’ll try.” Does that mean I need someone else working on the project to hedge against failure? That’s inefficient. Do I blindly assume the person will succeed, even though they already set my expectations that failure is a strong possibility? That would be unwise.
So how do you avoid this pitfall? Create an environment where people are comfortable saying “no.” Most managers don’t like it when someone on their team says they can’t do something. After all, it’s a sign of weakness, right? The natural thought process is that if they were just smarter or harder-working, then they would be able to get it done. On the other side of this, people hate saying “no” because they worry that it will make them look bad.
At the end of the day, you have to remember there’s only so much that one person can accomplish. They will either complete their tasks or not, based on their skills and experience. Pounding your fist and cracking a whip will get people to work 10 percent to 20 percent harder for periods of time, but it won’t get them to be twice as productive. Saying “yes” and failing will look worse than saying “no.” Encourage people to know their limitations and capacity. Ultimately, your team will improve its ability to predict and hit deadlines.
You need a scientific, data-driven method to measure your team’s capacity. Maybe you’ve learned the lesson about making your team members comfortable saying “no.” However, your boss or company executives may still think forcing people to say “yes” to impossible deadlines is a great management technique.
Even if you’re working in a supportive environment, when you scale out to managing large teams and planning months of work, simply “guesstimating” your team’s capacity is inadequate. You must adopt a date-driven model for measuring your team’s overall bandwidth. Here are a few factors to consider.
- Track Estimates Versus Actuals: If your team works in a model where you estimate work before starting (either in a waterfall or Agile model), then start tracking the cost estimates versus the cost actuals on a per-person or per-team basis. From there, you can create and publish tables of which teams estimate accurately and which do not. Work with your leads or team members who are still learning how to estimate to help them improve. In the meantime, at least you’ll know your error bands. That way, when you set a schedule, you’ll have some data with which to model how much buffer time to include.
- Track Incoming/Fix Rate/Backlog: Some teams work off a backlog of incoming requests, bugs or issues. It may be easier to simply track the team in aggregate if the size of the work items is roughly homogeneous (for example, a batch of one- or two-day projects). If the incoming rate equals the fix rate or if the backlog is roughly stable in size, you’re at capacity. If your backlog is growing, you may be headed for a situation where your team won’t be able to keep up with demand. Publish these metrics so everyone understands the bigger picture. Use this to drive resource planning discussions with management.
- Model the Points of Scale: If you manage something like a customer support group, your team’s workload may scale with the number of users. If you’re able to show a correlation between the number of incoming help requests and the number of users, you could use the company’s sales predictions to help estimate your future resource needs. If your team spends 10 percent of its time maintaining the current codebase, be sure to account for that when you estimate your capacity for future projects. By having a model for your points of scale, you’ll be able to extrapolate the outcomes of various scenarios based on the data you already have.
Learn to say “no”
Lead by example and say “no” when that’s the correct answer. With all the merits of saying “no,” it turns out it’s really one of the hardest conversations to have. No one likes hearing that something can’t be done. When someone is asking you or your team to take on more work than you’ll be able to handle, it’s important to lead the conversation by talking about your data model.
While most people hate math, it turns out that most executives respond to discussions based on data-driven models. If you’ve modeled your team’s capacity and throughput, have a model for the points of scale. If you can prove you’ve already cracked the whip to get that 10 percent to 20 percent extra productivity, you should have the right context set for a conversation around what can be done. Shift the focus away from the question of whether your team can do more work, and focus it on the relative priority of the new work compared to the existing work.
The next time someone tells you, “I’ll try,” remember the words of Yoda: “There is no ‘try.’” While you should absolutely push your team and create a sense of urgency around its work, you have to be careful of crossing that line where you push the team beyond the point of giving you valuable information. If they aren’t comfortable telling you “no,” even when that’s the right answer, it’s going to do more harm than good.
Don’t just take your team members’ word for it. Have a scientific, data-driven model for your team’s overall capacity. It will help you become better at capacity planning and it will help you have resource and project-scoping conversations with your executives.
Your success ultimately comes from delivering results. Missing deadlines erodes your credibility. If you have the confidence and the data model to back it up, you’ll prevail in your conversations around what your team can take on—and you’ll position yourself and your group for great success.
.jpg "Ryan Haveson")
Ryan Haveson has more than 15 years of experience leading engineering teams and delivering software and services for some of the world’s most recognized brands, including Xbox and Windows. He was a group manager in the Windows Experience team for Windows 8. He and his team designed and delivered end-user and developer-facing features, including the live tile notifications platform and the new Task Manager. He’s currently leading the engineering systems group at Qualcomm Inc. for the Windows/Windows Phone on Snapdragon division in sunny San Diego. Reach him at ryanhaveson@hotmail.com or at linkedin.com/in/ryanha.