Agile Resource Planning at a Fixed-Bid Drupal Dev Shop

On any given month, Metal Toad Media will distribute the work for 25-30 different clients across 10 different development resources. The majority of our work comes from fixed-bid contracts, but we also have a number of time & materials maintenance contracts to fill in the gaps. We've tried many different software solutions over the years to coordinate this work, but we've settled on using our own set of customized Google spreadsheets to do our long-term resource planning and short-term work allocation in a very dynamic and agile fashion.

We use these spreadsheets as the basis for many conversations between departments in three dedicated resource planning meetings throughout the week. The main planning departments include:

• Production team manages active development projects
• Sales team brings in new projects
• Senior developers help to determine whether or not the required work matches the correct resource
• Management team is responsible for overall resourcing

Our spreadsheets provide tangible metrics for evaluating our current and future workload, and helps our management make key decisions as to whether we need to hire more devs or pursue more sales.

This chart describes an overview of how our teams collaborate in going from estimating incoming work to the weekly planning of resources:

I'll be describing the details of this process in the following sections:

• Ecosystem of Development Work
• Estimation of Tasks
• Tracking Likelihood Incoming Sales
• Calculating Required Resources
• Long-term Resource Planning
• Should We Hire or Get More Work?
• Weekly Resource Calendar

Ecosystem of Development Work

Metal Toad primarily works with the Drupal content management system, but we also do HTML5 apps & mobile apps with PhoneGap, hosting with our internal Copper Frog Hosting company as well as some Wordpress, Django, and node.js.

Our distribution of development work resembles a power law distribution where 80% of our work comes from 20% of our total clients. For example, in 2011 we had 45 different clients, and our top 9 clients represented 76% of our total billable hours.

In 2011, Metal Toad had 2-3 large projects, with a dozen medium-sized projects, and about 30 ongoing extended service agreements

• 10% Large projects with 2-4 developers longer than 2 months (>1000 hours of dev)
• 20% Medium projects with 1-3 developers from 3 weeks to 2 months (200-1000 hours of dev)
• 70% Small extended service agreements to fill in the gaps (30 ongoing projects ranging from 5-200 hours)

The majority of our work comes from fixed-bid contracts where our rate varies depending upon how much we're over budget. We typically don't go under budget since any additional hours are usually credited to the client under an ongoing extended service agreement (ESA).

The ESA maintenance clients are both existing clients who need additional features or ongoing maintenance, and we also take on new clients who need some maintenance help or new feature development. The rates for ESA contracts tends to be more fixed and predictable with these clients, but also represents the long-tail of our ongoing work.

Having a large number of ongoing ESA clients helps to buffer any transitional times between landing medium to large-sized clients, and it is also a great way to ramp up junior developers and keep all of our developers busy.

Estimation of Tasks

The estimation of work is a key component of being a fixed bid dev shop, and using open source software helps to improve the accuracy of our estimates. We work primarily use Drupal, and so our estimation process continues to be improve as Drupal 7 has stabilized and matured and as our development team gains more experience and knowledge in implementing the most popular feature sets.

Our sales team negotiates the initial scope of work at a high-level, and then passes it off to one of our developers who can give an estimate range for each line item. Sales will usually take the average case and start submitting formal proposals until the final proposal is signed.

There's always uncertainty when trying to estimate the process of developing software. Lately, we've been using senior devs for estimating the tasks for how long they think it'd take for a mid-level developer to complete the work since they won't always be the ones doing the actual development. Once a project eventually comes in, then the developer on that project will re-estimate the hours according to their understanding of the tasks, and then track their time to each of those estimates.

Estimation is built into the culture here and is a crucial piece of our fixed-bid processes, and so any developer can be expected to be pulled in to do an estimate by the sales team.

Tracking Likelihood Incoming Sales

Our sales team may have 15-30 potential new gigs at any given time with 5-10 proposals out, and this is information that they track within a spreadsheet called the "50/50 planner." It's meant to help communicate potential new gigs to the production team for resource planning and to management for the need to hire new developers.

It's not an exact science, and so the best way that the sales team has found to track their gut feeling. They quantify this by indicating whether or not the likelihood of landing a proposal is less than or greater than 50% or less than or greater than 75%. They also track the high-low range of development hours from early discussions, and the likely hours based upon submitted proposals. They also track the timeline needs, and whether the proposal has been submitted, in-progress or won.

During the long-term resource planning meeting, the production team will often ask the sales team for updates on the 50/50 planner so that resources can start to be booked if sales feels like there is a high likelihood of work coming in at any moment.

Calculating Required Resources

The process of booking time in the long-term planner involves translating the budgeted developer time across a number of weeks according to whatever the desired timeline is. The production team does this by calculating a number of couple of different scenarios to answer the question, "How long would it take to complete with 1 dev, 2 devs or 3 devs?"

We primarily concerned about how available our development resources are, and so we'll take the total number of development hours plus about 75% of the quality assurance budget and 50% of the meeting time. This provides us with the total number of required developer hours.

We book our devs at 90% capacity per week, meaning at around 36 hours. No human being is 100% efficient, and so we add a 150% multiplier to account for variation in focus, context switching between multiple clients, communication needs and all of the other things that come up throughout the week.

To calculate required capacity for a gig, we take the total number of developer hours multiplied by 150% and then divided by 36 hours per week. Let's say we've estimated a job at 200 hours. Then it'd take 1 developer: (200 hours X 150%)/( 36 hrs/week) = 8.3 weeks to complete the work if they were booked to full capacity. It'd take 2 developers 4.2 weeks or 3 developers 2.7 weeks. We're usually not able to book a dev at full capacity due to ongoing work, and so the 150% dev hour buffer helps the production team account for timeline considerations.

We're then able to translate this amount of required work and look at our long-term resource planner to determine our capacity.

Long-term Resource Planning

For our long-term calendar, we've found that it's easier to track upcoming work in terms of percentage of a developer week. Instead of saying that it'll take 1 developer 8.33 weeks to complete a task, we talk about it in terms of reserving 833% of that time over the next 2-3 months. That's 8 weeks booked at 100%, and then a week booked to 40% or 2 more days. This is how the project managers can easily translate the budgeted time into reserving a portion of a developer's time during a week to complete that work.

Using percentages also makes it easier to spread multiple work across any given week. Let's say we need to distribute 3 different projects to a single developer in a single week, then it's much easier to split it up 60%, 30%, 10%, than it is to do the math and figure out that it's 24 hours, 12 hours, and 4 hours. Timeline considerations are also taken into consideration when making this weekly distribution of work.

We try to reserve time in increments of 10% or 20%, which is either a half-day or full-day of development. This also helps to cluster work per project and minimize context switching once the hours are distributed across the week. Using percentages also helps us to try to book to only 90% capacity (36 hours). It also allows us to calculate our capacity in terms of percentage of each individual as well as our overall development availability.

We usually do our long-term resource planning in the middle of the week. That's largely because we do our individual weekly planning on Monday and Thursday, but it also tends to be a good time to look at the big picture of how much work is left to be done and what we have capacity to do in the future.

Should We Hire or Get More Work?

During our long-term resource planning meeting, our production and sales team can look at our long-term resource planner an see whether we're below, at, or above our billable capacity.

If we're not at 90% overall capacity for at least 3-4 weeks out, then it's probably time to put additional resources towards our sales process. If we're over capacity currently or the near future, then it's time to hire additional development resources. If we're at capacity, and everything is at equilibrium, then have more capacity to provide developers with non-billable time for our internal tasks, personal research and development and blogging.

We also keep a project management load-balance spreadsheet, which helps us determine the capacity of our overall project management team and to determine who has capacity to take on new projects when they come in.

Weekly Resource Calendar

Developers use this weekly resource calendar to help figure out how much time they should spend on each client per day, and it is used to start conversations between the production and development team if the work is not clearly defined.

The project managers take a first pass at translating the plan set out in the long-term planner into this weekly resource calendar. On Monday morning, the production team reviews this with the sales, senior development, hosting, and management departments. Special requests are taken into consideration and adjustments are made so that all of the developers are booked from Monday to Wednesday. There's another planning meeting on Thursday to schedule for Thursday and Friday.

The production team owns the weekly resource planner, and tries their best to keep it up to date at a high level based upon what development actually happened on any given day.

Summary

Resource planning requires a lot of conversations between a lot of different departments, and it's an iterative process with many feedback loops. We've found that our customized set of spreadsheets have helped refine our sales to production to development process and to handle a healthy and diverse development workload.

Sometimes it's really a feast or famine process in not knowing whether or not a medium or large client will land, but we've developed a lot of resilience with our smaller ESA clients to be able to fill in any gaps. We also happen to be getting a lot of great work coming in and Metal Toad is a growing company. You should check our Careers page to see if we are currently hiring.