In our office we spend a lot of time talking to large organizations about how to implement labour control systems. It’s not coincidence, after all, we publish timesheet software but what’s surprising is the wide range of expectations of people who have been brought together to choose and implement the new system.

The first element of complexity that drives many of the issues is that a timekeeping system is one of the few if not the only centralized system which will be so wide distributed. Typically a timesheet system needs to be used by every single employee and put onto every single desktop. There is no other database-oriented application which will have to work together yet be used by so many. The larger the organization, the tougher the problem.

With more and more organizations becoming projectized, a desire to get a handle on actual labour spent is becoming a higher and higher priority in many companies. This often brings together a committee mandated to find (if possible), re- write (if absolutely necessary) a timekeeping system that will allow management a greater degree of control over timesheet data. The collection of people in such a committee often makes for some surprises. After all, collecting some timesheets should be a fairly low-priority function right? ‘Fraid not. First of all, while filling in a timecard, or timesheet at the end of each week is often a low priority for most employees, the need for that data can often be one of the highest priorities for the organization. If, for example, the payroll is keyed off the timecards, then not getting that data collected means no paycheque on Monday, something that is a high priority for most of us. Second, because so much of the company (if not all) has to use the system, it is very common to find representatives from all aspects of the organization. For what is sometimes the first time, Marketing finds itself in a meeting with Engineering, Administration, Production and Management. For these two reasons, it is not uncommon to find the committee also has some highly placed friends. It may actually have the Chief Financial Officer or Chief Information Officer actually on the committee itself.

So with all this highly placed interest, you’d figure that most organizations would at least have a clear idea of what it is they need. Well, that’s unfortunately not often the case.Part of the problem stems from a general lack of consensus over what function a timekeeping or time management system should perform. For some users, an agenda system similar to Microsoft’s Outlook seems like just the ticket. This “to-do” list has, after all, a place to record how much time a task took. Surely access to such a system would satisfy the needs of management? Such systems fit the role of time- management systems from an end-user perspective just as a Day-Timer or other hard- copy agenda would.

Another perspective often stems from the Human Resources department. Here, the management of “exception-days” such as vacation or holidays or sick-leave make interest in a management-by-exception system that is usually referred to as “Time and Attendance”. Time and attendance systems look to provide minimal information as they only look at anything that isn’t the expected work-week. In a salary-only environment, this is also enough to manage the payroll and a time-and-attendance system will often be used for this as well.

“Punch-clock” time systems add to the general confusion as the security department pipes up to say that they mag-card system that gives staff access to the front door is already keeping a running data stream of who’s in and who’s out. Surely the data from this system could answer all the needs put forward thus far? After all, if a person is absent, they won’t be able to use their card to get into the building. I can’t tell you how many times we’ve been asked if our own timesheet system could reconcile data from the building access system. It sounds like a low-effort plan except that it doesn’t often give enough information to be useful to anyone but security. After all, if you didn’t swipe your mag-card on the way into the office today is that because you were a) sick? b) on vacation? c) absent without leave? d) on assignment out of the office? or; e) because you walked in behind a kind person who held the door open for you? It’s impossible to tell and, even if you could, it still doesn’t help the Project Management group with what you did with your time.When an organizations starts looking for time-management systems, the perspective of individuals is to find a system that helps the individual organize the tasks in their day. The organizational perspective is generally to took for a system which can collect actual hours spent by task to determine that the most effective use is being made of the resources available. We call such a system a Project-oriented timesheet. For a Project-oriented timesheet system to be even deployable, it must provide some key elements:

• The system must have enough functionality to manage the data of the organization yet have and end-user interface that effectively requires no training. You should expect that the large majority of end-users will be looking for any excuse not to fill in their timesheet. “It’s too complicated” is just too tempting.
• The system must have an ability to lock-down information such as total hours for finance so that these finance-oriented values are not altered without approval yet must still have some “redistribution” functionality which allows project managers to redistribute hours after-the-fact to get them onto the proper tasks and projects when in error.
• The system has to support the organization’s internal hardware, software, operating system and data structure. After all, this will likely be the most deployed data application in the company. It makes no sense to start implementing such a system on a data environment which is contrary to the company standard.

Once you’ve found or written a system which is deployable, your work is not over. All the classic issues that come with deploying an enterprise-wide system will be here in spades. Make sure that some of these elements are on your list for consideration when you make up your implementation plan:

Get an executive-level product champion. Given people’s general reluctance to fill in timesheets, you can expect to require the authority of someone at the executive level sooner or later. Also, it’s almost a guarantee in most large-sized organizations that along the way you’ll find multiple department-level timekeeping systems in use that some people will be reluctant to abandon.Have a plan. I know I keep mentioning this in almost every column but it’s because I see organizations almost every week who still try to implement an enterprise-wide system without a plan. (Um… If I visited your firm last week, I didn’t mean you… Honest!) Once you’ve got a plan, make sure you manage its progress.

Start small. Over and over I see implementations where every employee is put onto the system on the first day. They’re sometimes successful (mostly not) but the pain you’re in for if you go this way! Start with a core group of users and schedule bringing on the balance week by week once the use of the system is stable. Leave the most reluctant (and unfortunately, sometimes the noisiest) until last.

Make sure that the goals that this committee sets out are clearly identified. If the need is really for a time and billing system, don’t be looking for just a time and attendance system. You’ll end up spending an enormous effort implementing something that won’t meet the demand.In the end, the most important analysis is a Return on Investment. The investment of money in the new system is the least significant. The effort to get the entire organization moving in one direction is what costs. Make sure you’ve identified what returns the organization will receive for that effort.