A little less than a year ago, we took on a Power BI project internally, the results of which we just published in a case study. Our goal was and is to accurately measure our business head to toe, but we weren’t out to solve the entire challenge in one fell swoop. We practice what we preach with regard to Agile, so we started with a small experiment to see if it changed our behavior. Our Minimum Viable Product was How Did We Do Yesterday.
Just like many of our clients, we did not start from scratch. Also, like many of our clients, we had assigned one employee the task of putting together a data warehouse and reports, in addition to his normal workflow, so that we were ready to pull information about specific projects. That information was sourced from our custom Time Tracking system, our custom Job Tracking system, and QuickBooks (Did we mention we write custom software?). Since this was an MVP, we went with the information we had at our disposal:
- Time Entries Associated to Projects, Employees, Activities and Dates. The amount of time we worked.
- Activities: Categorize the time we enter.
- Projects: Associated to Clients
- Clients
- Roles: Associated to Projects and (Activities or Employees). This applies a rate to the time we work.
We also had a few reports that were already helpful in identifying problems whose data we wanted to surface quicker. Since it was a key piece of understanding how we performed the previous business day, we added them as well.
- Missing Time from Last Business Day
- Missing Roles for Entered Time
- Duplicated Roles for Entered Time
What determined if we had a good day?
For our MVP, we chose to focus on operations, selecting revenue as the key metric. We have been following the guidelines in Scaling Up, so we intended to look at this every day. That meant the first question we asked every day was Why? Therefore, we populated the remainder of the dashboard with key reasons why we earned the revenue that Power BI displayed.
- How many hours did everyone enter, and what were their billable and unbillable totals?
- Is anyone missing time completely (Time Bandits)?
- How much did each individual earn? (Note: this was not a performance indicator as our developers aren’t in control of the rates for their projects)
- Are we missing any roles that would prevent revenue from being recognized?
- Do we have any duplicate roles that would inflate the revenue recognized?
This simple dashboard essentially replaced a four-page report we pulled each day going into our daily leadership huddle. The reports remained for one main reason—as an MVP our synchronization with Power BI happened eight times a day, the limit for the Personal Gateway. We timed the sync with our huddle, and any stragglers would be picked up by later syncs.
Now, we could see a decent snapshot of operations with enough details to understand both how we did and why. Even better, we could pull it up anywhere. We had a tool that was going to start changing all of our behavior for the better.
What didn’t we have in our model?
While this described the basics, we were still missing a few standard metrics for professional service firms. One measurement occurs rarely but is absolutely critical to bubble up immediately when it does occur—unrealized time. Unfortunately, whether time is realizable or not is not an attribute that the time tracking system puts on the time entries. That information cannot, or rather shouldn’t, be stored at the transaction (time entry) level because it can be influenced by other time entries.
Also, thinking back, our end goal was to measure (and later forecast) the health our organization. In order to do this, we needed to analyze trends in the data we have already captured as well as bring in other data sources that measure other areas of our business like Marketing and Sales. Once we are confident that we are sufficiently measuring what is behind us, we can start to turn our attention towards what is in front.
Sign up for our newsletter to find out where we went from here.