Many IT Solution providers struggle with the same project profitability issues. They can’t confirm if their project made money or lost money until weeks after the project has closed.
Even worse, they get blindsided by a project they didn’t know was in trouble until it’s too late to do anything about it. This leads to roller coaster quarterly profitability. As the projects and corresponding risks get bigger this also leads to C-level sleepless nights.
So how can you get better visibility into project profitability and find out earlier if a project is in trouble? 
Project Profitability Mistakes You Can Overcome
1. Not tracking detailed labor cost estimates…
Many organizations manage their project labor budgets against the same labor totals the sales engineer gave the sales rep for quoting purposes. Managing a project against a $50,000 total labor budget isn’t very useful because you don’t find out the project is in trouble until you get close to the $50,000 ceiling.
If you want to keep your project on track, what you really want to know is are we on track against each specialized labor type that the total labor budget was based on (design, project management, configuration, implementation, cabling, and training hours).
The silly thing is, the pre-sales engineer most likely documented on a piece of paper or in an Excel spreadsheet exactly what the detailed specialized labor type hours were (design, project management, configuration, etc), in order to come up with the $50,000 total labor budget that got passed onto the rep for quoting purposes.
Suggestion…
…why not keep that level of labor detail for tracking purposes and hand out the Project assignments in line with those same detailed labor types. Have people fill in their time sheets with how many design hours, how many PM hours, how many configuration or implementation hours, and compare that to the original detailed labor estimates.
For example if you estimated 20 design hours in the project early stages, and it ends up taking 40 design hours, you’d better be submitting a change order to the customer, or have a plan for how to compensate for those additional 20 hours over the remainder of the project. So instead of finding out about the extra 20 hours when you’re at $49,000 of your $50,000 project budget, you’d know about those extra hours while you still had 90% of your project budget remaining and lot’s of planning runway to fix it.
2. Not giving the VP of Services enough visibility into the sales pipeline for resource forecasting…
If your VP of Services only finds out what resources are required to implement a project the day it get’s booked, then they’re going to struggle with maximizing project services profitability. This is one of the primary contributors to roller coaster quarterly services profitability results. Great one quarter, miserable the next. Because it’s unlikely that your pre-sales engineers are preparing labor estimates for quotes that include 25% of all the project hours at overtime, or two people on a single task to compensate for the late project start because resources weren’t available on the date promised to the customer in the Sales process.
Suggestion…
…if you adopt the best practice suggested above and your project labor estimates are broken down by detailed labor type (design, project management, config, training hours) you now have the foundation for a labor hours forecast by specialized resource type. This allows you to forecast how many design, project management and training hours you are going to needed 30, 60, 90 days from now. Which will provide much better planning runway for appropriate new hires, or adjusting the margins based on leveraging subcontractors, or re-setting customer expectations for the project start and live dates.
P.S. A forecasted bucket of $50,000 of labor is almost totally useless for real world planning purposes. It has to be forecasted hours, by specialized resource type, in order to give your VP of Services a fighting chance to maximize project services utilization and subsequently project services profitability.
3. Not cycling implementation lessons learned back into the quoting process…
There’s that old saying about “doing the same thing again and again and expecting a different result is the definition of insanity”. This certainly applies to many organizations inability to cycle implementation lessons learned back into their quoting process. The problem occurs when they compare the actual project labor against the original $50,000 total services budget quoted. If the project comes in $5,000 (10%) over budget ($55,000), how do you figure out what went wrong? If you’re managing the project against the total services budget then there’s no easy way of determining where that extra $5,000 came from. And quite frankly, most companies won’t take the time to do the detailed project autopsy unless the project was significantly over budget, so that $5,000 in extra project labor never gets reconciled and so history just keeps repeating itself. But if you are tracking your project labor hours by detailed labor type, then it becomes very easy to see that your design hours came in 20 hours over, or your design hours came in 15 hours over and your PM hours came in 5 hours over. And now you have enough detailed information to confirm if this was a project specific issue, or if you’re under quoting some aspect of your project labor hours.
Summary
Yes, tracking detailed project services hours by specialized labor type will take a little more work. But if you don’t take this approach then getting visibility into things like mid-project profitability, useful resource forecasting and cycling implementation lessons learned back into the quoting process will continue to be a struggle. Those struggles are typically the difference between inconsistent and under performing project profitability and industry leading project profitability.
Get Your Mid-Project Profitability Scorecard
