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.

Comments

Thanks very much for this

Thanks very much for this post. I enjoyed it. I was particularly interested in the section about calculating required resources, but I didn't quite understand it all. You stated,

We are 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.

I don't understand what that means. Are you saying that 75% of the budgeted hours for QA and 50% of the budgeted meeting time is developer time, specifically?

Thanks!

kent's picture

Re: Developer time

@ldweeks: That's correct. We have different budget line items such as development, quality assurance, project management, meetings and planning. This budgeted time is split between project managers and developers, and we're primarily concerned with the resource planning for our developers.

The developers account for 100% of development time.
There is usually a developer and project manager in each meeting, and so we add 50% of the meeting time to the total developer time.
The PMs will be searching for bugs during QA, and then the developer will be fixing them. So the developer is needed for about 75% of the budgeted QA time.
So Total Developer Time = 100% development + 50% meetings + 75% QA

1 + 1 developers = 2 developers?

Great article - very interesting to hear how other firms are managing this kind of thing. I don't think it necessarily resolves the underlying tension inherent in trying to quote in fixed price, and then delivering in an agile environment, but a very interesting read.

One question, the budgeting system seems to assume that extra developers on a project add value at a linear rate, ie 2 developers will complete the same job in half the time. Is that really your experience, or is it just to make the estimating process easier?

kent's picture

Adding developers does not linearly decrease timeline

@gollyg: Excellent question. Our experience does reflect that throwing extra devs at a project will not automatically make the timeline go faster.

There's ramp up time for each dev and some overhead with communication and coordination that does not make it a purely linear relationship. Adding devs can also increase the project management needs and increase the required meeting time.

However, in some cases it might speed up development, and those cases are when the tasks are very well-defined and in a granular fashion in the form of tickets. Also it can help if the tasks have a clear delineation between frontend and backend dev work. Having a dev manage the branch merges with distributed version control can also help streamline coordination of development.

In general, most of our medium-sized projects have 2-3 developers and they have well-defined tasks, and so we find that the communication and coordination is totally manageable.

If assume a project requires 3 weeks of dev for a single dev, then adding two devs would theoretically go down to 1.5 weeks and 3 devs would go down to 0.75. We would round that up to 2 weeks and 1 week, but in reality it doesn't work out that way. There's usually a minimum amount of 2-3 weeks of dev time with a week of QA and back and forth.

We're also usually booking them at 60-80% of the week for a dedicated project, and so there's some flexibility to stretch things out for the back and forth with the client that needs to happen, and for the time for the more involved tasks to get done.

Senior PM at Metal Toad Adam Edgerton also has done some investigation of the effects of project management time and meeting time based upon the scope of the project and the required timeline that's worth pointing out:
http://www.metaltoad.com/blog/moet-and-poet-curve-fitting-approach-proje...

I get the 'clearly defined

I get the 'clearly defined tasks' concept around developers, so it all makes sense. It is the hard to split tasks that can cause the issues, but as you mention there is a little extra in the estimates to account for it.

That linked article is another good read - you guys really delve into the details of what is sometime just 'gut feel'. Thanks so much for sharing.

Could you publish sample spreadsheets?

Thanks for the great article. I've done a lot of agency work and the balance between forecasting and operations is hard to get right. It would be great if you'd publish sample spreadsheets or even just the headings of the spreadsheets that you use.

Cheers!

Nice Open Honest Description

Thanks Ken

I like your systematic approach, probably learnt from hard experience. It is very similar to my field of managing infrastructure design teams for fixed prices. I came across your site in a search for 'resource planning software'. , which I'm finding is poorly understood or supported by effective software tools. It appears your org takes estimating and managing effort seriously, which is not too common. I trust you are more the successful for it.
Regards
Alex

Add new comment