A Formula for Healthy Project Size Compared to Organization Size

This post is the first in a series following the session I presented at Drupalcon Austin recently, entitled "Oh look, we're growing!" The session as a whole focuses on my experience from a project management and operations perspective as Metal Toad grew from a small web shop into a medium-sized technology consultancy, and why I think project management needs to play an integral role in steering an organization's growth. Given the vastness of the subject matter, the presentation included a number of topics where I dedicated a single slide to what could have been an entire hour-long presentation on its own. Hence this series, which aims to go deeper into those topics!

Other Posts in This Series:

  1. A Formula for Healthy Project Size Compared to Organization Size
  2. Scaling Projects and Scaling the Organization
  3. Unit Change During Project & Organizational Growth
  4. Family-Sized Business Units & the Agency Holding Company Model
  5. Beware the Matrix Model?
  6. Communication Styles and Team Dynamics
  7. Agile Versus Waterfall, Once and For All
  8. Process Frameworks That Weather Growth
  9. "Why" Not "What" Documentation
  10. Project Manage the Organization
  11. Plan or Pain?

How Many Projects and What Size?

Scaling growth at a service company can often be a more complex scenario than growth at product company where there's greater emphasis on pricing and number of units. In product, a simplified view of making a million dollars requires selling one million units at $1, selling one unit at $1,000,000 or anywhere in-between. When your business is service-based and relies on balancing the needs of numerous clients versus your team's resources in both skill set and availability, matching project scale to organization scale becomes a crucial balance. To build a million dollar service business, there's no way to support the overhead of selling one million $1 projects, or likely even one hundred $10,000 projects. Conversely, a million dollar service business isn't sustainable with a single million dollar project per year either. Too many firms make this mistake of putting all their eggs in a single basket, and if the project ends unexpectedly, they're promptly out of business.

Instead, finding a healthy balance of project scale to organization size can be determined by using a number of factors:

  • Anticipated/goal revenue for the organization (annually in dollars)
  • Total expenses budgeted (annually in dollars)
  • Amount of cash in the bank/short-term credit available (in dollars)
  • Average lead time to close a sale (in years, will likely be a fraction)
  • Number of full-time billable project resources (developers, creatives, etc.)

With that information, a simple two-part equation helps inform where you might find your ideal project size and number of concurrent projects. The first part of the equation assesses what projects may be too small for your organization to take on, while the second determines at what point projects become too large and therefore too risky for your organization.

Project Size Equation Part 1:


Number of Project Resources > Number of Concurrent Projects

This part of the equation is pretty straightforward. I could get a lot more complex about how I arrived here, but much of the reporting we've done historically indicated that when our average was less than one resource per project, the project efficiency versus the project's overhead for sales, meetings, wrap-up, and time-splitting for resources wasn't particularly profitable. As a result, our goal is to always have less concurrent projects than people available to complete those projects.

Project Size Equation Part 2:


Number of Concurrent Projects > (Revenue + Expenses) / (Cash & Credit / Sale Lead Time))

This is where a bit more math gets involved. This part of the equation seeks to find the minimum number of concurrent projects an organization should have in order to diversify revenue sufficiently so that no single project can sink the ship. It takes a look at the total cost of losing a project (lost revenue and expenses attributed to a single project) over the time required to replace that project versus the amount of cash and short-term credit available to the organization to weather the storm of a lost project without layoffs and other cost reductions. I use revenue plus expenses (which at first glance seems like a strange sum) for two reasons: 1) It's essentially a 2X expenses multiplier plus profitability and 2) I like representing expenses + profitability as revenue to put emphasis on the opportunity cost of lost sales as expressed in revenue not accrued.

An Example Scenario

Here's a scenario to help illustrate how to apply the above to your business.

  • Anticipated/goal revenue for the organization: $2,000,000 (annual)
  • Total expenses budgeted: $1,700,000 (annual)
  • Amount of cash in the bank/short-term credit: $150,000
  • Average lead time to close a sale: 0.167 years (2 months)
  • Number of billable project resources (developers, creatives, etc.): 8 Resources

This organization's equation would be as follows:

When solving for the healthy number of concurrent projects, you arrive at a number more than 4.1 but less than 8. That translates into an average monthly project dollar amount roughly between $38,500 and $75,0000. This can be a helpful sizing tool for new project engagements as well, because when reviewing a statement of work, you can take the total amount of the engagement and divide it over the project's duration to compare to the ideal range.

Still a bit confused? Let's look at a couple of examples if this organization were to have various numbers of projects.

With only two projects, if the organization lost one project suddenly, they'd lose $167K in revenue opportunity and incur $142K in expenses ($309K total) over the two months required to replace that project with a new sale. They'd be running out of cash after two months and unable to weather another lost project, and given the lost potential for revenue, likely profitability for the year would be slashed by more than half.

At 6 concurrent projects (within the ideal range), if the organization lost a project, that loss would represent $56K in lost revenue opportunity and $47K in expenses ($103K total) over the time required to replace the project. Compared to $150K in cash and credit available, the $47K lost certainly isn't ideal, but that scenario can repeat itself twice more in short succession without taking the company out of business. Likewise, the $56K in lost revenue potential represents only one sixth of their goal profit for the year.

At 12 concurrent projects, if the organization lost a project, the loss would represent $28K in lost revenue opportunity and $24K in expenses ($52K total) over the time required to replace the project. Given the organization has $150K in cash and credit available, $24K in expenses and under 10% of lost potential profit isn't a huge problem assuming it's not a regularly recurring situation. Good news! That said, at 12 projects with only 8 resources available, the noise level would be somewhat high as developers, and creatives all juggle multiple projects for multiple clients. If those projects are all 12+ month engagements then perhaps the acquisition cost would be acceptably low, but in all likelihood 12 concurrent projects would require constant new sales (several per month) to sustain. This scenario doesn't pass my gut as being particularly sustainable and profitable long-term, and it doesn't sound like much fun for the team members involved either!

This formula has generally been predictive of where an organization should aim to fall in terms of number of projects and project size. The organizations who I've run this by that are doing well all find that their situations fit this formula, Metal Toad included.

How about you? Do you think my concurrent project formula identifies a healthy balance for project size compared to organization size with weight given to an acceptable level of risk based on cash and credit available? Leave a comment!

Catch me at the Digital PM Summit

Interested in the topic of organizational growth from a PM perspective? Join me and a bunch of fellow PMs at the 2014 Digital PM Summit in Austin! I'll be presenting a talk similar in nature to my Drupalcon presentation and related to this blog series, but new and improved after additional months of experience and iteration. The Bureau of Digital Affairs did a great job with the inaugural 2013 event, and 2014 promises even more in store. With a great lineup of speakers, topics, and of course after-parties, you'll definitely get your monies worth. I hope to see you there!

Add new comment

Restricted HTML

  • Allowed HTML tags: <a href hreflang> <em> <strong> <cite> <blockquote cite> <code> <ul type> <ol start type> <li> <dl> <dt> <dd> <h2 id> <h3 id> <h4 id> <h5 id> <h6 id>
  • You can enable syntax highlighting of source code with the following tags: <code>, <blockcode>, <cpp>, <java>, <php>. The supported tag styles are: <foo>, [foo].
  • Web page addresses and email addresses turn into links automatically.
  • Lines and paragraphs break automatically.

Ready for transformation?