The Background

A large tech firm was losing money in deployment. CSMs (who's jobs included managing deployment engineers) we partially bonused on their utilization numbers. However, with so many concurrent projects, there was no way they could personally track this. Forecasting was almost always off, as projected utilization very rarely lined up with actual hours on a customer site. Management could not get a good picture of utilization until after a project was complete and billed.


The Current State

Resource managers were tasked with assigning engineers to projects, and kept a full calendar of every engineer's current assignments. However, this was viewed as basically a location calendar to see where an engineer was located and what their top priory project was at any given time. It only tracked working or not, and didn't track actual hours. This calendar was only truly viewed by resource managers, although it was available to engineers.

Project managers were tasked with giving 2 week forecasts of work loads. However, because of lean employment numbers, a resource manager was likely to assign more work to an engineer if they were ever informed of even a slight, temporary drop in utilization. A resource manager could also pull an engineer if a break was undetermined in length, even if it ended up only being a 1-2 day slump. This could result in a much larger break before an engineer was reassigned to the project. The fear of overburdening or loosing an engineer caused a large amount of hesitation in PMs to forecast anything less than near full utilization. 

Engineers were tasked with letting a resource manager know if they were not getting full utilization. However, this could result in more work, so it didn't always occur. Also, these communications often left out the PM and were the root of miscommunication. If an engineer told a resource manager they were only putting in half time, they would get addition remote assignments. However, often a PM would have imminent plans to boost their utilization and would run into issues upon discovering that their time was already accounted for.


 

Identified Problems

Tracking- There was no centralized place where every steak holder could easily see utilization forecasts.

Structure- There were technically 4 parties responsible for utilization reporting. CRMs were giving general ideas of what may be happening, resource managers were getting down to full time vs half time, PMs had the ability to get more granular but hesitated to do so, and engineers who could give an accurate account of past and present, but couldn't forecast accurately. Without one party taking full responsibility for the task, no party put in the effort to be as accurate as possible.

Staffing- A lean staffing model was naturally in place, in part, because of the CRMs bonus structure. They were bonused based on the cost of engineer staff vs gp from projects. It was understandable that no CRM would want to hire any more engineers than was absolutely necessary to complete the current work load.

Policy- The lean staffing model that kept engineers busy was the source of outright fabrication of utilization by PMs.


Solutions

Tracking & Structure- We determined that the calendar kept by resource managers could serve as a centralized place to track utilization with only a few minor tweaks. 1/2 and 1/4 days were implemented, along with color coding to indicated wether or not forecasted partial days were temporary or undetermined.  

 

Calendar distribution was extended to PMs, CSMs, and re-introduced to engineers. A tab with dynamic utilization graphs was added so anyone could select an engineer by name and determine how their time was being spent for the next month. The use of an easy to interpret pie chart would make discrepancies simple to identify by any steak holder. 

 
 

 

 

Staffing & Policy- As efficiency experts, we generally applaud a lean staffing model. However, it's dangerous to allow staffing models to be determined by employees with paychecks tied directly to these numbers.

We recommended utilization based bonuses be given some breathing room. Instead of a direct cost to profit determination, we wrote a policy setting 80% utilization as the bonus cap. (Industry average is 70-75%.) Average utilization in this firm hovered around 78-83%, so by sacrificing only 3 percentage points (at most), this policy eliminated the exponential increase in desperation for every last point.

With that small concession, more engineers could be hired, PMs would be less fearful of accurately reporting anything less than full utilization, and resource managers wouldn't be as pressured to fill an occasional partial day. This policy was written as a test, and our client was warned that some tweaking of the numbers may be required to achieve the right business/operations balance.