top of page

Project Management Ratios in Website Redesign Projects - Part 1

This is part 1 in a 2-part series exploring Project Management Ratios in a sample of website redesign projects ranging in size from 300 to 6,000 hours. In part 1 we explore the use of historical PM ratios as a means for initial project estimation. In part 2 we look at the correlation between the PM ratios and overall financial performance to improve our forecasting models even further.

Questions we want to answer:

  1. What are realistic project management ratios to expect on website redesign projects?

  2. What affects on overall financial performance will increasing/decreasing PM overhead have?

About the Data

  • Random project sampling taken from various clients, industries, and years (2006-2016)

  • Projects must have included a full range of services from initial discovery phases all the way through implementation

First - Why this is Important

Agencies and corporations often struggle to understand or allocate sufficient project management time to their projects. From a financial perspective, sales teams and management generally feel that higher PM overhead ratios increase project costs and make their organizations less competitive.

As a result, the allocation of PM time on a project during the sales or planning phases is arbitrarily restricted (often at or below 10%).

Underestimating any activity or discipline can be problematic. In all cases, the time and cost associated with reconciling low estimates with reality is greater than the simple difference between the two. The additional costs manifest themselves as:

  • Higher overhead expenses to update schedules and project plans

  • Re-work and other unexpected or non-billable tasks

But underestimating project management is particularly noteworthy because it means that critical project activities will either happen without the necessary coordination and facilitation they need, or they won't happen at all. And the consequences here tend to extend far beyond the scope of an individual project, as critical resources are pulled off other projects to help course correct.

So, what are realistic project management ratios to expect on website redesign projects?

Before we look at the data, it's important to understand the right and wrong way to leverage a PM ratio in an initial estimate.

The Wrong way to Use the Ratio

A 10% PM ratio does not mean you should multiply all other project activities by 10% to forecast PM hours. To illustrate why, let's use a simple example:

  • Assume core project hours: 900 (before PM time added)

  • Assume PM Ratio: 10%

  • Wrong Calculation: 900 x 10% = 90 hours

  • Total Project Hours: 990

  • Actual PM Ratio: 90/990 = 9.1%

If we use the PM ratio as demonstrated here, we will immediately underestimate the number of hours that are needed.

The Right way to Use the Ratio

To use the ratio correctly, we need to do the following

1 - Determine total project hours:

Total Project Hours = Core Hours / (1-PM ratio)

Total Project Hours = 900 / .9

Total Project Hours = 1,000

2 - Multiply total project hours by PM Ratio

PM Hours = Total Hours x PM Ratio

PM Hours = 1,000 x .1

PM Hours = 100

The simplified version of this formula would be:

PM Hours = (Core Hours / (1-PM Ratio)) x PM Ratio

PM Hours = (900 / 90%) x 10%

PM Hours = 100

So What Does the Data Say?

A note about variance

First, we see a lot of variation in the % of project management ratios in our sample set, even among projects of the same general size. This may suggest inconsistencies in the project management processes or inconsistent / dirty data. Likely both.

On closer inspection, it's more likely that inconsistent time recording and categorization is a stronger influence on the data. We see, for example, an unusual number of projects clustered at or near 0%, even those above 2,000 total hours.

Option 1 - Ignore the Variance, and Take the Current Average

But, let's assume, hypothetically, that the data is accurate. If we do no further analysis, we could simply use the average (13.48%) of our sample set (as a starting point) for all future models.

In our earlier example, this would yield the following:

(900 / (1-13.5%)) x 13.5%

= 900 / (86.5%) x 13.5%

= 140 hours

That's a 40-hour (40%) difference from the previous 10% assumption. Aside from the financial impact, depending on resource utilization rates, that 40-hour difference could equate to a 1-4 week schedule shortage.

Option 2 - Dismiss the Outliers and Take the Adjusted Average

After controlling for projects below 1% and over 50%, the average of our new sample set comes out to 14.32% (rounded to 14.5%). Again, using our previous example, this would yield:

(900 / (1-14.5%)) x 14.5%

= 900 / (85.5%) x 14.5%

= 152 hours

If we saw strong upward or downward trends in the PM ratio that correlated to increases in project size, we could take this a step further and use different values for different ranges of project sizes (e.g., below 500 hours vs. above 500 hours). But in this case we won't because our trendlines are relatively flat regardless of project size.

We could stop here and use the newly calculated average of our data to re-calibrate our ratio-based forecasting model. This would certainly be an improvement over arbitrary guesses, but is it good enough?

While it provides useful guidelines and should be used to set minimum acceptable thresholds within an organization, the historical average for PM ratios is still a relatively crude estimation model. It should not be used as a substitute for more rigorous analysis of project specifications, especially when our process shows deviations from the average by over 100%.

In other words, if we know that there are some cases where the PM ratio will end up being close to 50%, failure to recognize those factors and adjust our 14.5% model can still lead to severe project shortages and poor financial performance.

In part 2 we will explore the correlation between the PM ratio and project profitability to help further refine our estimation model.

Recent Posts
Search By Tags
No tags yet.
bottom of page