Why use timesheets?

Timesheets in this context are the documents, electronic or otherwise that record what time was spent by the person on what tasks. Some time sheets might also record the start and end time of each task rather than just the total time. Some timesheets also record breaks particularly where that is important for the employee contract.

The argument for not having timesheets is to reduce the administration workload. If the managers of the organisation are happy that people are contributing to the organisation appropriately then there may be no need to record anything in more detail.

Another argument is sometimes around the fact that professionals work at different efficiencies so recording time against each task tends to normalise professional activities for the wrong reasons. By their nature most professionals need to apply some creativity to their work so they may have different approaches to their work: this is good. Professionals also take pride in their work so they will work to the task rather than the time: this is also good. Timesheets may be seen to undermine that.

The argument for timesheets is about having some record of people’s activities and contribution to the organisation. Of course, measuring contribution is very difficult and arguably subjective, however, using time is also arguably better than nothing. A record becomes important for a number of business functions if nothing else. Some of those are about the person’s performance but most are about the metrics of any associated project and the organisation as a whole.

So what is the value of timesheets?

Person level: the person is communicating their contribution to the organisation and to each project or activity in terms of time. They are acknowledging that they have satisfied the requirements of their employment contract. In some sense, when all the members of an organisation are completing time sheets, there is an implicit fairness between people, of the roles and contributions by those people. When summarised, the split of work between different types of activities can be calculated; that is, their utilisation. At the person level, utilisation, when compared to others in similar roles, provides information about their work habits (good, bad or otherwise).

At an organisation level and for service based businesses the time sheet data is very often the record for invoicing. Timesheet data improves an assurance that the invoice is reasonably determined.

Utilisation can also be calculated at a team and an organisational level. In this case it provides information about how good the processes are at allowing people to do their primary role (their real job).

Timesheet data can also be compared to planned effort for any project or task to track the accuracy of those estimates. In some cases this might inform decisions about how the project or task advances. In other cases it might simply inform the next project or task of the same type.

Timesheet data can also be abstracted to a cost (using a cost rate for each person). In this case, it can be used to track the costs actually incurred on a project or task and compared to the planned costs. Reactions to a difference between actual and planned costs can be slightly more sophisticated because balancing straight time may not be so important as balancing project costs.

Because timesheets are typically recording admin and leave time (annual leave, sick leave, parental leave, etc.), they also become the record for leave entitlements.

Often the reason to require timesheets of staff are compelling: because they provide the data for invoicing to clients. Otherwise, timesheets are a good democratiser of the efforts of people in an organisation. Finally, the value of timesheets to the managers of the business invariably outweigh the imposition to people in the organisation. That imposition should be minimised by using a timesheet mechanism that suits the nature of the business.

Heads-up is our timesheet system and it is designed to minimise the imposition while maximising the value to the organisation. Of course, Heads-up also delivers the information discussed above that puts meaning and value behind completing timesheets.

Earned Value Management

For the types of projects that I have been associated with, using Earned Value Management (EVM) is the technique that I find most succinctly represents the status of the project. Being succinct is key when the project status is being presented to the project sponsors, whether that is a project director or a steering committee. One measure of this succinctness is based on the PMI Knowledge Areas; EVM is able to represent Scope, Time (schedule) and Cost in a single graph. For the record the remaining Knowledge Areas are Integration, Quality, HR, Communications, Risk and Procurement,

Another bonus from EVM is that it seems to force a notional contract between the project team and the steering committee or project director at the beginning of the project. The project team must put a value on each deliverable of the project. That process tends to sort out the real goals of the project and raise the awareness of those goals within the team. Those deliverables stay in focus during the life of the project because they are directly contributing to the project status graph. This also makes it harder to game the estimate-to-complete as the project progresses; the team must either change the value of a deliverable or re-scope it, which is usually very visible to the steering committee.

EVM is a simple concept. When I have introduced it to project teams and to clients, there is invariably a discussion about whether it is appropriate for the particular project or matches the way the client runs its projects. While there are limitations to EVM, my feeling is that those discussions as primarily being a resistance to change. I suspect they are also resistant to something that has an apparent simplicity. The concept is simple, however EVM needs to be applied well for that simplicity to be useful. Equally, the EVM project status graph is packed with information and reading it well is also key to getting that value out of EVM.

Of course, Heads-up, the product we sell, supports EVM. It can record the deliverables of each project together with their respective value, expected delivery date and actual delivery date. Mapping this against the actual costs gives the project team and the project director the picture of the project that is core to EVM. The actual costs drop out of the time sheets and cost rates which are again intrinsic to Heads-up.

Earned Value Management is well described in Wikipedia.

Setting up Jobs and Activity Types

One of the discussions we have with new clients is around how to set up the job structure – ie the list of jobs that staff see when they open their timesheet. This needs to support new jobs being added and old jobs dropping off as they are completed.

There are some questions to answer when making job hierarchy decisions:

  • Do your staff like codes or do they prefer longer descriptions?
  • Are you likely to have many clients or just a few?
  • Are the jobs short-term or do they last for months (or years), or is it a combination?
  • Are there separate divisions/profit centres/teams and do your staff usually work in only one, or across those divisions?
  • Are the divisions managed separately – eg is there a separate sales team? Are profits shared across divisions?
  • Do the jobs have consistent phases or is each job different?
  • What level of detail does your managers need to run the business?

The default for Heads-up is to organise jobs under each client. Most staff in an organisation know which client account they are working on, making it easy to sort the list and find the right job. From there, the job structure can focus on sets of jobs that might be related by a single proposal (RFP) or work site. Heads-up can also accommodate other job structures and generate a coded job number to suit. This is particularly important if the company has been using a job structure already and doesn’t want to re-construct it.

Within a single consultancy or work site it is sometimes useful to set up several sub-jobs if the project steering committee wants to assess the profitability of a project more deeply, such as at the project stage.

One alternative to sub-jobs is to use different activity types. Many timesheet systems cater for this (including Heads-up). Activity types give the user a separate dimension. Using activity types might be more appropriate if management wants to record the same activity type across different projects – eg track the split between on-site work and in-office work.

Traditionally job numbers were coded, so the first ‘letter’ might have corresponded to the office, and then the year, and so on. This was important if the user had to set up manual files to match. Now that most project artefacts are stored electronically, there is less need to encode the job number like this. Having said that, encoding some aspects of each job may be useful for communicating job information between staff.

Getting the job structure right will help to make the timesheet entry task (and other admin tasks) flow. Ultimately, the structure you adopt depends on the characteristics of the business and what management needs to record.

Managing by Cost (another thing)

The decision to manage a project at the cost level or at the revenue level might also be dictated by the type of project you’re dealing with. For example, architecture projects are often priced as some percentage of the overall building construction budget.

If the architect’s contribution to a building project is set up this way, then they may employ a top-down approach to setting their costs. They will set the budget for each stage of the project based on experience and on what sort of profit they want to get out of the work. That means concept design, development application, contract administration, etc, will each get a budget and the manager of each stage will be asked to work to that budget. Setting up the project this way helps the project manager limit the effort for each stage, particularly the design effort, where the input can expand easily.

Heads-up allows the project manager to set out the budget targets per milestone or per a consistent period. For example, they can generate a budget for each month which can be plugged into Heads-up and become the baseline when tracking the actual costs on the project as it progresses.

Managing by Cost or Managing by Revenue

For a professional services provider, the main costs of any project or consultancy are based on the cost rate of each person on the project. The main revenue is going to be based on their respective charge rate.

One of the significant decisions that an organisation should be making is whether to ask the managers to track costs or to track revenue. That decision has implications for the culture of the organisation and for the types of skills the organisation is expecting to see in its managers.

Managing a project by cost is suggesting that the income from the project has been decided by the person who sold it (the account manager or salesperson). It is up to the project manager to simply manage the project according to a cost schedule that was decided during the sales process. That might be a good thing if the managers of the business want the flexibility to bid for projects for reasons other than profitability.

In this mode, a good manager is likely to be risk averse so that costs are contained. They will be concerned about the cost rates and these are sometimes open to debate depending on what costs are attributed to the project resources (the people) and what might be considered overheads.

In comparison, managing a project by revenue is suggesting that there is still room to perform well on a project if the revenue it generates is improved. In this case, there is less of a penalty if the project increases in scope as long as the manager can pass that on to the client as additional revenue. The manager in these instances is probably advantaged if they have some sales skills – ie a good manager will justify project value to clients and even sell extension work as they complete the project.

By its definition, managing by work-in-progress (WIP) uses revenue to gauge the success of the project. When managing by WIP, the value of labour (and other items applied to the project) is measured at its charge rate so that it can be compared to the actual invoices that go to the client.

The decision about whether to manage the cost side or the revenue side has consequences within the business and should be carefully considered because of its impact on the company culture and the likely impact on how projects are run.

The Joy of Scaling

One of the big reasons that our clients take up our software is to plan for their growth. When one or two people start a new organisation they pretty much do everything themselves. Then they employ people and work responsibility starts getting divided. Those first few employees are likely to be highly trusted and they probably have a large say in the processes that surround the work they do. They’ve come on board understanding that it is a new organisation with fresh systems and that the business is young, energetic and keen. At some point, the work generated by the company will be too much for the business managers to oversee without either continuing to employ more highly trusted deputies and/or deploying some good tools and techniques.

For a detailed exploration of company growth, references like E-myth are good sources (see The E-Myth Revisited by Michael Gerber). It talks about technicians who start businesses that succeed as one-person organisations yet struggle in growth. In fact, as their organisations grow, poor technicians generally need to develop their managerial and entrepreneurial sides, and make sure the staff are maintaining that dedication that got the business started in the first place.

As the number of people in the organisation increases, the tools will need to become more complex because the responsibilities are being shared by more people, while the business managers need to have confidence in every aspect of the work. It is the work they likely did themselves when the company first started – work they took great care to get right for their new customers. The tools need to be efficient to allow business managers time to do their ‘real’ job. The business managers need to see evidence that the team knows what to do and that they are, in fact, doing it.

The power of delegation

One of the benefits that our customers don’t usually see until after they have started using Heads-up is its ability to allow them to hand over a lot of the admin work to employees while retaining a good level of oversight. For example, the project manager can be given the information they need to write an invoice but the business manager is still doing the final sign-off. Delegating responsibility like this is a leadership and management game. There are good and bad ways to do it and there are good and bad tools to support the process. The tools that allow managers to delegate responsibility also need to be well targeted and efficient. It needs to be clear as to what responsibilities are being delegated (within the bigger process). And there is no point in delegating a task if the handover and review processes take as much time as it would if you completed the task yourself.

The right person needs to know that they have a task to do and what it is – is it a decision, is it to get more information, is it to review (and approve) something. The task needs to be meaningful to the person doing it. They need to have all the information on hand when they are asked to action the task and they need a simple process.

Expense claims are a good example. The default review process in Heads-up for expense claims has three steps:

  1. The staff person is responsible for entering the claim and providing receipts for each claim. They then submit it, at which point Heads-up puts the claim in front of both an admin person and the team lead.
  2. The admin person reviews the claim to make sure it corresponds to company policy. If the claim isn’t compliant then the admin person can communicate that in the notes, and reject the claim. The team lead reviews the claim to make sure it corresponds to expenses on their project and that each claim item is costed to the right project.
  3. Once both of those reviews have been completed, a finance person can review the claim to make sure it satisfies the company’s (and probably the tax department’s) audit standards.

The expense claim entry and approval process happens in one system and all the data is in one database. If there are small errors in the claim, the admin and team lead can update the claim without rejecting it. Otherwise they can reject or approve it to the next step. In smaller organisations the roles might overlap, in which case Heads-up can be tailored to shorten the review process steps. This is an example at a micro level of the benefits, and indeed requirements, of efficient delegation to effective growth.

Top 5 Lead Indicators for Project Managers

No project starts, or should start, without some idea of its goal. Most of the indicators below require the project manager to qualify and quantify the intent of the project at its start. By qualify, that means to describe how the intent is satisfied. By example, a project to connect people on two sides of a river might be qualified by a method: connection by ferry will do to start with but eventually by a bridge. By quantify, that means to attribute to the intent a set of measurable values. Again, by example, the ferry is to be in place after one month and a two lane bridge is expected by the end of the year. Typically the minimum set of qualitative constraints on any project includes cost and timeframe. If the intent is loosely defined then the constraints may be equally loose, or they may be limited to an initial stage of the project.

1. Graph the burn rate

At the start, the project manager should have an idea of the project resourcing, human or otherwise, and respective costs of those resources. With that, the project manager can map out a budget over the course of the project (per week, month, etc). The burn rate is the accumulated actual costs over time. If the actual costs of the project, that is the burn rate, match the plan then we can be confident that the project is getting the resources that it expected. However, the project manager needs to be circumspect about attributing real progress on the project using this measure.

2. Utilisation and staff turnover

By simply collecting the contributions, in time, by each member of the project team, it is possible to make some judgements on the project’s health. If the numbers show that the project is consistently getting good blocks of time from people, that is probably better than inconsistent blocks or small chunks of time. If the team members are churning (ie people are getting replaced on the project), then that is a warning sign.

3. Measure progress not just activity

In our example, progress on bridge construction can probably be measured: a half built bridge should happen half way through the project, or, if the bridge is only 25% complete and you’ve spent half the costs then something is wrong. There are a few ways to extend that measure in a more realistic scenario:

  1. Incremental progress: extending the bridge example, if there are six spans to the bridge then completing each span adds a sixth to the progress.
  2. For a project where progress is less obviously defined, the project team might assess progress instinctively: how many hours, days, weeks do they think they need to complete the work…how does that compare to the remaining funds and time.
  3. It might be as simple as using invoicing: if the total of invoices sent to the sponsor equals the costs then you might call the project healthy. Of course, that assumes that you only send invoices for the work completed. This is described under ‘project realisation’ in Top 10 Project Metrics to Track.
  4. Earned value: at the beginning of the project, the team defines the set of deliverables and assigns a value to each one so that the total assigned value of all deliverables matches the total cost of the project. The health of the project can then be assessed by comparing the total value of completed deliverables (the earned value) to the total cost to date. The more granular the deliverables, the better the health readings. Read more about earned value management here.

4. Baseline and re-assess project success (and failure)

If the scope of the project is very well defined then it is probably the case that success is also well defined. However, if there is a broad intent to the project, then it may well pay to re-assess success and failure conditions as the project progresses. Indeed, it may be that the project is extended or stopped based on what is achieved or learnt as the project continues. In practice, re-assessing the success of the project is done by describing the progress of the project against its original intentions. By example, this project seeks to connect people across the river. We have since learnt that a ferry is enough to cope with the number of people who want to be connected so we are stopping the project – and calling it a success.

5. Measure maturity, or measure the measurements

The idea of project maturity began some decades ago and attempts to assess a team’s capability in adapting processes to the job at hand – ie the maturity of the team’s capability. A very abridged use of capability maturity might start with tracking quality reviews in a project. Much can be gleaned about the health of a project by tracking the timing, frequency and results of quality reviews as they occur through the project. The QA step is important and reviewing the history of QA reports adds a level of maturity. Again, by example, as each span of the bridge is completed, how many QA defects have been found and how does the number compare to previous QA results. For a more complete description of maturity the Capability Maturity Model is a good starting point, as is Carnegie Melon University’s ‘power’ CMMI for more extended information. Finally, if the number of defects is dropping as the bridge progresses that is probably good. If the number of defects is consistently low (or zero) then it might be worth checking that the review process is doing its job.

None of these indicators require sophisticated tools or techniques to record or track. All of them are powerful and help to provide some confidence to project stakeholders that the project is in good hands.

Workflow and Approval Processes

As a business grows, there is arguably a need to insert an approval step into some processes. Fundamentally, this is because the people with responsibility for the business are not doing all the excellent work that gets done in that business. The negative term is bureaucracy but, ultimately, approval processes serve everyone.

When to add an approval step

Here are some conditions that suggest an approval step needs to be added:

  • Responsibility: when the person doing the task needs to hand over responsibility for its result (whether they think that or not).
  • Risk mitigation: when a potentially negative impact of the task goes beyond the person doing it.
  • Quality control: when the task is complex and the result needs to be reviewed.
  • Informational: the team leader may not need to know the details of each new widget completed but they might need to take responsibility (through an approval step) for the number of widgets completed in the period.

When to not add an approval step

There are also cases where it looks like an approval step may be warranted but probably shouldn’t be added:

  • When the approver cannot do anything but approve the task. Subtly, there may be little point in adding an approval step if an item can’t be dealt with (or dealt with easily) if it is rejected.
  • When the responsibility should remain with the person who completes the task – whether that is the worker or the manager. It might be that some aspect of the task needs to be reviewed, in which case a second-party-review step should be constructed appropriately so that all concerned understand their role in the process.
  • When the risk is less than the effort to approve it or the penalty for delaying the result. In this case, an approval-in-principle step may be worth considering.
  • When the quality of the result is not in question or doesn’t outweigh the cost of complicating the process (ie the cost of the approver’s time or delays to the real work).
  • When it is informational only; that is, the manager needs to know that a process was completed but doesn’t need to have input into the result.

How to add an approval step

There are good and bad ways to add an approval step. Things to think about before implementing an approval step include:

  • Determine how much can be automated. Is a human getting involved because there is a value/qualitative decision to be made, or a complex set of rules, or extra information needed?
  • Add the approval step at the right point in the process. Does it need to happen right away, can it happen in bulk, or even as a retrospective step – so that the submitter can continue with their workflow?
  • Direct it to the right person (not every boss, not someone else’s boss) so that there is no ambiguity about who should be taking the next step in the workflow. As an aside, the decision maker needs to be aware that there is a decision to make.
  • Direct the result of the review to the right person: the original submitter, the next person in the workflow.
  • Put boundaries around the approval process. Is it assessing a subset of rules: for a leave request admin to assess leave available and the project manager to assess impact on team and project etc.

Because workflows and approval processes typically involve more than one person, the systems that support those workflows need to be centralised. Internet cloud-based systems do that job very well, not only because they are centralised but also because they remove the burden of maintenance from your organisation. Consider the amount of time your IT people are spending installing and updating software, and managing backups.