Thursday, 4 December 2008

Time Recording and Wooden Dollars

Let’s look at a typical project in an agency / software house that has adopted time recording. During this project a number of things happen:
  • The developers are constantly pulled off the project to support legacy apps, attend company meetings, and tend to various admin tasks. Only the time they actually spend on the project is recorded on the timesheet. All other tasks are booked to non-project codes.
  • Its winter time and a lot of time is lost due to high absence and sickness levels within the team (snivel). Again, only the time they work on the project is booked to it.
  • There are performance issues with a developer, resulting in quality issues and slow delivery. The PM makes a case with the project office that it would be unfair to have all this developers time booked to the project as he hadn’t received “value for money”. The PM wins the case and not all of the time spent on the project is booked to it.
  • Part of the project (as sold by the sales team) involves a developer getting up to speed with a new piece of technology which is critical to the delivery of the project. It could be considered R&D. The PM instructs the developer not to book the time spent on this task to the project as its “Training” and should be booked to the general company training code.
The project is delivered late, BUT on paper the project is shown to have been delivered on budget and made a profit. The only problem is, in all of the cases above, the company is still absorbing costs so the fact that the time isn’t booked to the project means the project is dealing in wooden dollars. As this project is deemed to have been a financial success, this pattern is repeated on future projects. Scale this up to companies running many projects concurrently and this issue is hard to detect but massively amplified. Eventually, the company goes bust. A list of specific companies this has happened to and the evidence to back it up is available upon request.

Time recording is a necessary evil in most software houses or agencies. A public sector client of mine is currently debating the need to introduce a time recording system to help with managing 60+ concurrent projects. I’ve come across the time recording debate many times and there isn’t a simple answer to whether you should or shouldn’t do time recording. The key thing to understand and be clear on is your purpose for introducing time recording to your organisation. Here are some reasons for doing time recording that I've heard some organisations use:
  • We want a way to quantify and record the amount of effort that goes into a specific task so we can improve future estimates. (excellent)
  • We want to accurately measure the P&L of individual projects. (difficult)
  • We want to use time recording to track progress. (valid but a very poor way to measure progress)
  • We need time recording to maximise staff utilisation. (very, VERY bad. See below)
  • We bill our clients on a time and materials basis so the time we enter goes straight into an invoice for the client. (good work if you can get it)
  • Time recording will assist us with resource planning. (possible, but better tools available to do this)
Introducing time recording to your organisation will have a huge cultural impact. Below I’ve listed some of the good and bad points about time recording that should help you in forming a judgement on whether it’s right for your organisation:


- You have to police it resulting in staff feeling a squeeze from two different angles:
  • PM’s police what time is booked to their projects and fight like mad to stop time being booked to protect the budget. They have become very creative in their methods!
  • Line managers want to maximise the amount of billable time (wooden dollars) booked to projects and resist time being booked to non-project codes such as Training, Admin, Induction, Team Briefings, etc. (see utilisation below)
- Line managers waste a lot of time chasing individuals to fill in their timesheets that could be better utilised elsewhere.

- It requires a lot of discipline from staff to update their timesheet daily. Daily updates keep the data more accurate and timely. If you have staff updating timesheets weekly then it’s highly unlikely that the data will be accurate.

- You may end up employing someone just to manage and police the time recording system.
Burden – time recording introduces a huge burden to your organisation and those who work within that environment. Any additional burden kills morale. If you constantly hound staff to complete timesheets then you will destroy their morale.

- If there’s a lot of resistance to time recording you may find some staff purposely incorrectly book time to undermine the validity of the system.

- Inaccurate filing and recording of time:
  • Some time recording systems I’ve seen don’t allow you to enter more than 37.5hrs per week. So how do you record overtime? This is a great way for some unscrupulous project managers to hide project overruns.
  • I’ve seen PM’s entering time on behalf of their team and miraculously making the figures fit.
  • Most people just make the time fit into what they feel are appropriate allocations they can get away with. They try booking it all to projects before having to justify why they’ve booked it to non-project codes.
I’ve even come across PM’s who have stopped people from working on their project because “we don’t have the budget for you”. In these specific cases, the people offering help had no other work to do and could add real value. The real cost to the organisation would be the same as they’re paying for them anyway. The project would have been delivered earlier. The only cost to the project would have been in wooden dollars as the time recording system would report the project being over budget after they had recorded their time against it.

- Many KPIs (e.g. utilisation) within organisations are calculated using data from time recording systems. Given all of the above, this results in management decisions being made on wildly inaccurate data.

  • Split charging of time for shared resources. If a developer is pulled of your project to resolve a support issue for a previous project then it’s useful to bill the time accordingly.
  • Time recording can help in measuring how long specific tasks take when used in the context of historical analysis and estimation of future work.
  • Time recording, if used correctly, has the potential to separate effort from schedule (requires a lot of discipline). In other words, if a task took 4 hours of effort but the elapsed time was 2 days then both of these metrics are valuable. This difference between effort and schedule is extremely common and yet rarely recorded. The elapsed time is usually recorded which means the project accounts for team meetings, sickness, or any other issues not normally accounted for in project estimates.
  • Time recording generates data. Data is great for producing lots of reports and pretty looking management dashboards.
  • It’s very easy to measure staff utilisation with a time recording system…..or so it seems.


Most managers are trained and actively encouraged to maximise the utilisation of their staff. It makes sense right, as you don’t want staff sat around with nothing to do? It makes perfect sense that the more value we extract from our staff maximises the bottom line? Managers are often given a big fat pat on the back for reaching company utilisation targets, regularly in excess of 70%. Something that seems so obviously good actually has the direct opposite effect.

Maximising utilisation is bad. Just in case you didn’t get that, MAXIMISING UTILISATION IS VERY BAD.

To survive and be profitable in a software house the key is throughput. The more software you can get out of the door the more you can invoice clients. This is particularly relevant to fixed price contracts. I’ve come across very few outsourced software development projects charged on a T&M basis. The more you maximise utilisation the less chance you’ll have of having the right resource available when you need it. This incurs delays to the project or additional costs in bringing in contract staff or freelancers to cover. Many agencies in this situation experience the ripple effect where they start to borrow resources from other projects to get a project closed and invoiced. This cascades through all other projects. I’m not saying you should over resource so you can throw more bodies at a project, what I’m saying is you should over resource so you can improve your chances of having the right people available at the right time.

Maximising utilisation impacts heavily on staff morale. Staff feel pressured to book all time to projects and not to morale boosting activities such as personal development, training, team meetings, etc. It stifles creativity, communication, and innovation.

There’s an excellent book called Slack which covers the subject of utilisation in much more detail. The analogies it provides, which I quote far too often are:
  • If you run a motorway network at 100% - you get traffic jams
  • If you run a network connection at 100% utilisation – everything slows down
  • If you maximise utilisation within your agency – you print less invoices and go bust! (ok, this last quote is mine)

I’m sure there are many project accountants out there who may pick fault with what I’ve written here and quote various accounting theories and approaches. I genuinely welcome their comment along with others as this has proven to be a highly contentious issue within organisations. Feel free to comment.

1 comment:

Anonymous said...

There is a lot of competition in outsourcing software development, as there are many firms across the globe catering to clients looking for outsourcing their work. What is good is that the takers can choose the best from the lot.