What is it that has otherwise well-organized companies implement 2, 3 or even more timekeeping systems at the same time? What would prompt otherwise rational people to supporting multiple entry of such a tedious chore?

Particularly in projectized organizations, the issue of time collection is a hot one. There have been many popular management structures over the years. Recently the notion of "Matrix" organizations have been very popular. In a matrix organization, there are people who are responsible for work elements. These people call upon people who manage groups of resources. These resource managers are responsible for the appropriate availability level and skills of their group. Once work has been completed, resources are returned to the resource pool for reassignment or retraining.

Several years ago, the emphasis in most organizations was toward giving power to the resource managers. With a tighter economy and more focus on producing results, many organizations are now giving more power to those who manage the particular projects. The degree to which control is left with the work element managers is the degree to which we could say an organization is "projectized".

There is a movement throughout the world toward more project-oriented organizations and the more project-oriented a company is, the more this timesheet issue seems to be a problem.

There is little disagreement about the basic layout of a timesheet; some kind of descriptive element along the left, the days listed across the top, hours entered in the cells below. Sounds simple. So why would anyone take issue with this kind of application?

There is an inherent conflict in implementing any timesheet system in a projectized environment which is not immediately obvious. Over the next few pages, we'll reveal this conflict and propose a potential resolution to it.

Getting back to basics

Why bother with a timesheet system at all? There are several good reasons to automate timekeeping:

• Eliminate errors

With manual timekeeping systems, the opportunity to introduce inaccurate data is enormous. Users can easily mis-type information or simply not look up correct codes or not have the timesheet add up properly or simply enter work as "miscellaneous". All of this increases work downstream in the timekeeping process and adds work and heartache to everyone.

• Be fast

With data entered directly into an automated system, turning data into useful reports or transactional files for moving into other organizational systems becomes much easier and much faster. One of the biggest attractions of automating the timekeeping environment for project managers is access to labor actuals in a more timely fashion.

• Reduce workload

With an automated system, controls could conceivably be created to trap typographical errors and other inaccuracies in the timesheet while it is being completed. Also, there is no need to re-enter manual time sheets into a computerized system. Finally, calculations, reports and other time-consuming irritants

• Ensure that all billing is done accurately and that hours are not lost

In any manual timekeeping system, it is difficult if not impossible to establish checks and balances to ensure that billing information is done completely and accurately. An automated system can provide reports that compare expected billings with actual billings and identify any un-billed hours for scrutiny by the billing department.

• Provide the "actual" element of variance reporting

Project-oriented systems often provide some type of variance report. This kind of report shows the actual progress to-date against the original plan. While the planned progress is usually maintained in the project system, the actuals must come from somewhere. Automating the timekeeping environment provides the project system with the progressed element of the budget vs. actual report.

Matrix organizations and the problems they bring

Needs of Project Managers: get the data in a timely fashion. It's not ok to wait until labor actuals have gone through the entire financial cycle. Data would return to the project control environment as much as 6 weeks late. By that time any value from variance reporting will be lost.

A matrix organization is set up in two dimensions. On one axis there is the organizational structure. This structure is sometimes the traditional hierarchical structure of an organization with supervisors reporting to department heads who report to a more centralized authority. At other times it is a more autonomous Resource Manager structure where someone is responsible for the training and availability of a certain category of resource.

On the second axis is the work breakdown structure. This can be imagined as the top level being all work the organization does, the second level being, perhaps a project level with one entry per project and a third level being the tasks within that project. Obviously for more complicated projects, additional levels could be generated. This work will be managed by project managers who report to a more central authority and are responsible for the results of the project.

The matrix occurs where the project managers make requests of the resource managers for the resources required to accomplish the project. The project manager must contend with resources which come from a variety of sources. The resource manager must contend with their resources being used (sometime simultaneously) on a variety of projects.

The problem with this environment is that the hierarchical or organization breakdown structure typically collects time for reasons of "time and attendance" for payroll purposes and sometimes for purposes of "time and billing" for either internal and/or external invoicing. The requirement for such a system is generally payroll-oriented. The requirements are usually quite simple. For salaried staff the only thing the payroll system requires is the number of days worked. If there was time not worked, the payroll system might also track such items as holidays, vacations and, paid or unpaid sick leave. For staff who are paid hourly, there is a further requirement for the number of hours worked and the rate at which work was performed such as standard or overtime.

For better or worse, most timesheet systems in use today have been established by the finance department for time and attendance purposes.

If billing is also automated, then there is an additional requirement put on the timesheet environment. In this case the timesheet system may also be required to provide more description to the invoice such as the project name being worked on and perhaps the category of work being done. Such billing is often done monthly and is often a part of the month-ending process by Finance.

All of these finance-oriented functions are generally historical in perspective. The furthest forward a financial system will look is the status date of currently collected data.

The authorization process for this level of functionality is from the employee to their supervisor from there to the department level then on to the payroll department.

Unfortunately for the project managers of the organization, their requirements for time collection are quite different. A project manager needs to know what hours have been spent on which tasks. This will enable them to produce a budget vs. actual analysis and forms the basis of forward forecasting. The project manager also needs to know what progress has been made on a particular task or, more exactly, what the Estimate to Complete is.

The project manager has virtually no interest in which employee actually did the work or in how many hours a particular employee may have worked in the past week.

Unlike Finance, Project Management is future-oriented. The project manager's job is to consistently look for what is left to do. While the project is in progress, the oldest data of interest to the project manager is the current reporting period (e.g. the past week or past month).

The authorization for project data is done by task and aggregated to the project level. Each project manager must approve of all charges against the project for each period.

Yet another issue to further complicate an already unworkable situation is the conflicting requirement for the timeliness of the data.

Payroll must have the timekeeping data quickly in order to produce paycheques. Yet, returning timesheet data to other systems usually has to wait until the current financial cycle is complete. This often means that project managers often cannot see the timesheet data for as long as 6 weeks after it is spent. Why? For example: If an employee enters his timesheet on the first day of the month, it will not be summarized by Finance for redistribution to other systems until month's end. By the time the month is "closed" it could easily be the middle of the month following.

This is, of course absolutely unacceptable to Project Management. By the time this data can deliver a useful variance report, whatever opportunity existed to make an impact on the project has been lost. Most project managers need to know the actual labor costs within a few days of when they were spent not a few weeks.

How organizations try to solve the timekeeping dilemma

• Create multiple timesheet systems

The most comment response to handling the conflict is to have multiple timekeeping systems. This is never done by design but rather by desperation. Finance usually starts their own system first. Its system is well established by the time Project Management tries to make use of it. Obviously with its own needs a priority, the Finance timekeeping system either does not have the functionality or does not have the timeliness required or both.

Project Management then creates a completely new timesheet system to "intercept" timesheet data before it is sent to Finance. This results in at least two completely detached timesheet systems. Worse, the systems are almost guaranteed not to reconcile. IF the project management organization is not fully integrated then it is entirely possible that more than one timesheet system will be created to service each project.

• Don't have a timesheet system

Some organizations handle the problem by simply giving up. It's too complicated a problem to solve and for some organizations, if they don't have an explainable solution, they simply won't implement any. Payroll has other methods of taking care of paycheques, particularly if most employees are salaried. Project managers simply do without budget vs. actual reporting and variance reporting.

• Don't do activity-based-costing (It's too hard)

Another method of giving up is simply to abandon activity-based-costing as part of the organizational structure. Payroll continues with its own system but management of costs on projects is simply not done. A surprising number of project management environments simply do not include cost management. When asked, project managers say they want to do cost management but cannot get access to actual costs in a format or in time to make the useful.

• Create a customized timesheet system which either:
  • Bursts the timesheet into line-by-line approvals

This solution sounds very elegant. Certainly as an automated feature, it is not complicated to program. Each line item on the timesheet probably lives as an individual record anyway. The problem with this method is that once it is burst apart and sent off to each project manager, the chances of re-assembling the timesheet are almost nil. Each project manager who deletes a line or changes a code means that the entire timesheet must be re-sent to everyone involved. With the payroll clock ticking in the background, users will ultimately have to by-pass the system simply to get paid.

• Route the timesheet through everyone who might have an interest in changing it.

The problem with this method is that each member of the route can change the timesheet relative to others. If the last person on the route removes a line item, the timesheet may no longer add up to the same number of hours which the employee worked. This routing may also take an inordinate amount of time. Payroll simply can't wait until virtually everyone has agreed about this particular timesheet and it frankly doesn't care about the resolution of 90% of the debate. All they want to know is: Has the person worked that many hours or not?

The key to the kingdom

They used to say that every impossible situation has to have a hidden solution somewhere and happily, there is one here.

What allows us an escape from the matrix organization dilemma is that once the number of hours have been determined for payroll purposes, it is extremely rare that changes in the actual task performed is of interest to them!

This is by no means insignificant. If this is so, then we can break the authorization process into two steps. The first, and it seems the easiest, is to determine the number of hours worked by a particular employee and, possibly the rate at which they were worked. Once this data is established and approved, the second phase would begin, allowing the project managers to change the descriptive elements of the timesheet while preventing them from changing the total number of hours worked.

While it seems simple, most automated timekeeping systems do not allow such a process. Because the distinction has never been made between the different requirements of the different parts of the organization, most timesheet systems simply allow that a timesheet is approved or not.

Escaping the Matrix Trap

A process which escapes the "Matrix Trap" will have to do the following:

• Get data to the payroll department fast
• Allow project managers to alter data elements of the timesheet without altering totals and perhaps rates.
• Maintain the originally entered data for audit purposes
• Maintain an audit trail line-by-line

Any automated timekeeping system which would have to work in a projectized environment would have to support the above process and in addition would have to:

• Work on a commercial database to facilitate links to pre-existing systems.
• Have pre-defined links to existing project management systems.

This was our design at HMS when we first started TimeControl.

In the TimeControl design we support the following flow of data:

TimeControl is structured to accomplish both of these as follows. The system allows for a very rapid validation through the organizational structure of the payroll data. This validation includes the ability to determine that all timesheets have been collected and that Once this is done, TimeControl data is posted to a non-changeable status. This locks in the number of hours assessed per person for payroll purposes. Since payroll has virtually no interest in exactly what tasks these hours were spent on, a transaction file of the data can be generated that will be used to create the payroll.

Once the data has been posted, it is now made available for reporting back to the project managers. Project managers are given a report by project and task for hours worked the week previous. Project managers are given a grace period during which they can institute changes if required. Should they find a charge to be altered, the project manager takes advantage of unique functionality to create a Debit/Credit against any timesheet in existence. The Debit/Credit must equal a zero balance of hours. This functionality allows the project managers to remove hours from one charge code and put it onto a different charge code without altering the original timesheet. Debits and Credits are added to the original timesheet while maintaining a complete audit of who entered what.

The payroll is unaffected as it has no interest anyway in which charge codes are used. If a billing system is in use, it can get the updated data at the same time as the project management system.

The project management system gets its information as soon as the organization wishes. The variable in such an environment is the amount of "grace period" allowed to the project managers to institute changes before data is posted to the project management environment.

One of the advantages of this kind of environment is its forgiving nature. If a project manager isn't ready or doesn't enter his or her changes, they can simply be entered after the fact. The data will then self-correct in the next project management update period.

Conclusion

Times are tighter. In today's economy virtually every aspect of an organization must be as effective as possible.

There is no room anymore for duplicate effort in mission critical systems.

For anyone in a project-oriented organization looking to automate timekeeping, they'll need to consider the process of the data and the timeliness with which it arrives at the parties who require it.

Any project-oriented timekeeping process must deliver:

• Timely results to the people who need them
• A structure for approving the labor actuals in two directions:
  • Organization oriented
  • Project Oriented
• An ability for project managers to enter changes to the charge definitions without affecting the total number of hours worked by an employee.
• An audit trail of entries and changes
• An ability to reconstruct or display originally entered data by the employee
• An ability to return the results to the systems that require them