Many data-centric companies make three common mistakes which lead to situations where at best, you are collecting data that is hard to analyze and at worst, is a total waste of the organization’s time to capture.
Likely, you can find at least one of these issues today in your own company.
The absurdities of reality
Every Friday afternoon, people across thousands of companies take part in the largest fiction writing event in the world, the filling out of the weekly timesheet. This comment is intended to illustrate a serious data capture issue.
The timesheet can be used to capture usable data for the organization’s planning processes, which would result in more rational scheduling. However, in many situations, the timesheet becomes either a memory (or lack thereof) test or a test that you can do basic math to ensure a group of random numbers add up to forty.
The question is, is it worth doing at all if we aren’t doing it well? We discussed previously why we need this data so how do we prevent the fiction from occurring?
Are you creating data tools or collecting data taxes?
A common mistake made by many companies is poor communication of the purpose of data collection. Any data that you are going to collect from every employee on a recurring basis should support a specific conversation within the organization. That conversation should also be widely supported by management and understood by every employee such that fictionalization is minimized.
The “every employee” aspect is also important from an organizational change perspective. When management doesn’t have to fill out timesheets, employees view timesheets as a control mechanism rather than a data gathering tool. This leads to truth shaping behavior, designed to prevent possible negative performance review implications.
I worked for one company where the project information in the timesheets was used for client billing. The linkage from timesheet to paycheck was clear to everyone and timesheets were very accurate as a result. Timesheets were a very useful data tool in this context.
Contrast this with another personal experience. I was directed to fill out a weekly timesheet at a company where I was an employee. The purpose of the timesheet was never communicated, it simply had to be done. Being honest in my reports, I logged that I had worked 44 hours that week. On Monday, my honesty was admonished by my Manager who informed me that Finance wanted everybody to log 40 hours, no more nor no less. I asked “Wouldn’t it be more efficient for Finance to put 40 hours next to each employee in a list rather than make everyone fill out a timesheet?” but never got a good answer. Timesheets for this company’s employees were viewed as an unnecessary data tax and data quality suffered.
Are you collecting the right level of data detail?
If time tracking takes each employee thirty minutes per week and you have two hundred employees at an average blended rate of $100 per hour, time tracking is a $10,000 per week activity.
The $10,000 question is therefore, are you capturing the data you need to support the critical business conversation that required time tracking? In many cases, companies are capturing very detailed data or are capturing that data that was identified by the original department that first rolled out the tool. For Project organizations, you may need data granularity to the project or even task level. Operational organizations may need team, function, or support ticket level data. Different needs may predicate different conversations that need different levels of detail on the timesheet. One size does not have to fit all.
Asking for the wrong level of data from employees leads to data being placed where convenient rather than where it should go. For example, if you have 200+ tasks on your timesheet, likely most time will get applied to those tasks that are memorable rather than the actual tasks that were worked. This greatly impacts the quality of collected data.
Can you analyze your data?
The last challenge arises when you attempt to drive actions based on the collected data. Is the data captured in a form that is actionable or was the structure driven by Finance or some other bookkeeping function? Bookkeeping is a necessary task but it should not be the sole driver of how to structure the inputs. Timesheet lines can contain extended information, allowing those bookkeeping views to be synthesized by your Business Intelligence tools.
For example, if your goal is to drive annual application replacement decisions, then the timesheet lines for support should include a way to denote the application(s) involved. Once the person entering their time understands the decisions being driven off of the data, the data quality goes up and you will know the top ten applications that took up the majority of your support team’s time by the end of the year.
You will find much greater success in capturing this data if you do the following.
- The organization is clear on the purpose of the data
- The data is captured at the right level of detail for the need
- The data is accessible to do the analysis for non-bookkeeping needs
Please like this article if you liked the content. I look forward to reading your viewpoints and experiences in the comments below.
This article is published as part of the IDG Contributor Network. Want to Join?