“How does the utilization report arrive at its numbers?”

It seemed like a simple, straightforward and innocuous question at the time. Unfortunately, it opened an institution-sized metallic food storage container of blind, soil-ingesting invertebrates.

You see, the person who’d commissioned the development of the utilization report didn’t really understand what he was building. He had vague amorphous ideas about what he wanted – perhaps he’d seen a report at some other company that was used to determine how well the employees were being utilized and decided it was a good idea. Based on second-hand knowledge and investigation into the reports themselves, here’s how I picture the utilization report’s progression in my head:

Project Requester: “I want a report that tells me if there’s enough work for my employees.” –note: He’s saying “show number of hours worked divided by number of hours that could have been worked”
– time passes –
Programmer: “OK, here it is.”
Project Requester: “It’s wrong. It needs to take holidays into account.”
– time passes –
Programmer: “OK, here it is.”
Project Requester: “It’s wrong. It needs to take PTO into account.”
– time passes –
Programmer: “OK, here it is.”
Project Requester: “It’s wrong. It  should use the number of hours the employee has been scheduled to work instead of the hours actually worked.”
Programmer: “What?”
Project Requester: “It has to.”
– time passes –
Programmer: “OK, here it is.”
Project Requester: “It’s wrong. If an employee had a job that ran late the night before, the Scheduling department schedules an employee for a block of time the next day in order to keep him from having to work. The report has to take that into account when it happens.”
– time passes –
Programmer: “OK, here it is.”
Project Requester: “It’s wrong. It needs to show that an employee worked the whole weekend if he was scheduled for a Saturday.”
– time passes –
Programmer: “OK, here it is.”
Project Requester: “It’s wrong. It needs to assume every employee spent two hours to get to the job site and two hours to get home.”
– time passes –
Programmer: “OK, here it is.”
Project Requester: “It’s wrong.”
Programmer: “How is it wrong?”
Project Requester: “The numbers can’t possibly be that low. The report is wrong.” –note: It showed an average of 64% utilization (i.e. employees jacked off 36% of the time for which they were paid). It was later found that actual utilization was 52% if they were afforded every possible benefit of the doubt.

The utilization report was used to determine year-end monetary bonuses for managers. However, every time the utilization numbers were too low to allow the maximum bonus, the managers would say “The report’s always been inaccurate. The numbers are really much higher.” And the bonus would be awarded.

It turned out “the utilization report” at my company actually meant six distinct reports. Here’s how the system worked:

• At the beginning of every month, a user would submit an IT ticket as a reminder to “run” the report on the 15th of the next month
• Somewhere near the 15th of the month, a specific developer would navigate to a directory on his machine and double-click an Access database
• The developer would then locate each of the six reports in the Access database and run them all in turn, exporting them as RTF files when they finished
• Each report was extremely resource-intensive and completely took over the IT guy’s computer, rendering him useless for hours – and even longer if the Access database crashed
• When all reports had been exported, they were attached to an email and sent to the user from Step 1

This process was repeated every month and caused much frustration for the user (because they couldn’t get the report immediately) and the developer (because it consumed his computer and he couldn’t get anything done). After hearing the developer curse and complain about the utilization report a few times, I set to work on the Access database. The process was changed to:

• On the 15th of every month, Windows Task Scheduler opens the Access database, triggering a VBA subroutine
• Each report is exported to RTF
• All exported reports are programmatically attached to an email message and sent to the user

The new process is entirely automated and takes about three minutes to complete. It turns out Access was running all of the report queries (a bunch of UNION ALLs in a number of views) twice – once to display the report to the developer, and again to export the data to RTF. In addition, the formatting process required to display the report inside Access took an enormous amount of time, whereas the formatting of the RTF to be displayed in an external viewer was far quicker.