Charging Ahead on Charge Codes
This article is part of our "From the Trenches" collection. It describes best practices for defining your organization's charge code structure for the project management system or timesheet system.
To download the Word version of this article, see Charging Ahead on Charge Codes.
To see more articles, see "From the Trenches" white papers.
Charging Ahead on Charge Codes
I'm often asked to help organizations define their charge code structure, either for their project management system or their timesheet system. While it's true that every organization is different and different needs result in different types of charges, there are some common practices we've found over the years that are universal.
Ask less, not more
No one likes bureaucracy, so the more complex a charge code structure you make, the less likely it will be that people make accurate reports. Imagine, for example, that I make a list of 10,000 charge codes in a long flat list to choose from. You might have to scroll for an hour, examining each possible entry in a drop-down list before you'd find the exact right choice for this particular timesheet or project update. Then you'd need to scroll through the rest of the list to make sure you didn't find something that wasn't just a little more exact.
Let's not be silly. No one will do that. They'll take the first entry that seems reasonably close and choose that. Failing that, all hours will ultimately end up in charge "999:Miscellaneous".
So make your list simple. Ideally, it should not require scrolling at all, but should be visible on a single screen or perhaps with one more click. That means that you're only choosing from 20-30 possible options at most. In this case, less is more.
If management is determined to get much more detail, remind them that it is better to get more accuracy and less detail than more detail and less accuracy.
Don't ask what you know already
I've seen many charge code structures where there is an identical charge code for each department or each project. Yet, if people are already being asked to choose the project and we're doing an entry for meetings for example, then I know that the line item must be "meetings on this project" so why pollute the charge list with multiple meeting items? The same logic holds with departments. If we have a list of employees who belong to each department, then we already know what department they're in. Why pollute the charge list with "Sales department meeting", "Technical department meeting" and, "Marketing department meeting". Just make one item called "Meeting" and we can deduce from the employee's department and the project they're on what the meeting was for.
Be resolved to better resolution
Picking an appropriate level of resolution for your project and your timesheet is a common challenge. Think about what level you want to manage things in with these conditions: 1) There needs to be more value in the data than in the time to collect it, so if you spend all day reporting on your day, how will you actually get anything done? 2) Work at a level that you're prepared to make decisions on. 3) The more complex it is to enter, the less likely you are to get accurate data. 4) When possible, get everyone working at the same level of resolution so you're not managing one group in tasks that are 10 minutes long and another in tasks that are 3 days long. For many people, being able report 3-5 lines of detail for a given day is plenty of detail.
Condition your data
Some people will make the end user answer the same questions over and over. For example, we've seen systems with a column for "R&D" meaning that this charge is or is not a charge eligible for an R&D tax credit. But we should be able to associate the eligibility to the task itself rather than each line of each person's timesheet. Moreover, what would I do if some users thought that it was eligible and some users thought that it wasn't? This likely scenario also plays out in examples such as, "Design-eligible for R&D" and "Design-not-eligible for R&D". This doubles the number of charge codes for no return in value. Just have someone in R&D flag each drop down value as eligible or not and you won't have to keep asking end users to try to figure it out each week.
Better project and timesheet systems allow a hierarchical display of data. If you have no choice but to have a lot of possible choices, then building a hierarchy can make a lot of data easier to swallow. Think of 5-10 items at maximum to choose from at each level. And don't be tempted to make dozens of levels. Making a 3-4 level hierarchy should be able to cover most options. After all, 10 items per level in a 4-level system is 10,000 possible charges. Is your project more complex than that?
Show me less
The fewer questions and choices you give your users, the better off you'll be. If there is anything you can answer in the background then try not to ask it of users on your timesheet. The goal is not to collect the most data possible, it's to collect as accurate a picture as possible, and you'll do better at that if you insulate the end users from data, questions, and options that make no difference to them.
What will you do with that data?
I'm often told by middle-management types that they need "much more detail" than I'm suggesting and my response is always the same: "What will you do with it?" The purpose of gathering task-based timesheet data is to make better business decisions, so I'll often ask those middle managers what business decision they're not able to make now that they think they'd do better at if they had more detail. When you start to look at information that way, you find that you probably need less of it. It might be enough to find out just the total number of hours spent in meetings or in transit or in overhead tasks than to find out what every one of those tasks was.
Drill deeper… but only when you must
When you start to do timesheet analysis to figure out where your hours are all going, you are bound to find some disproportionate results. Where you find an unusually high percentage of hours that defy expectation, drill a little deeper. But not too deep. Add one more layer of detail for that charge and give it a few weeks to see what data you get. The temptation will be to expand a single charge code like "meetings" into 50 new charge codes with every possible type of meeting that could occur. Try resisting this temptation and instead change that 1 charge code into 5 or 6. If you don't get the detail or you still have disproportionate results, delve a little deeper.
Keep a clean house
Charge lists have a tendency to increase in size but never decrease. It's a good practice to review them on a regular basis and eliminate bloat. If you do, you're more likely to continue to get more accurate information and be able to identify areas where you're losing time.
Charge code management—whether it is for your project schedule or your timesheet system—can make the difference between an efficient system from which data can be counted on or a system with too much definition and not enough accuracy. When you design your charge code structure, we recommend starting with less, not more. It's much easier to add more detail later if it is required than it is to undo more detail and make it simpler for overwhelmed users.
About the Author
Chris Vandersluis is the president and founder of Montreal, Canada-based HMS Software, a Microsoft Certified Partner. He has an economics degree from McGill University and over 30 years experience in the automation of project control systems. He is a long-standing member of the Project Management Institute (PMI) and helped found the Montreal, Toronto, and Quebec chapters of the Microsoft Project Users Group (MPUG). Publications for which Chris has written include Fortune, Heavy Construction News, Computing Canada magazine, and PMI's PMNetwork, and he is a regular columnist for Project Times. He teaches Advanced Project Management at McGill University and often speaks at project management association functions across North America and around the world. HMS Software is the publisher of the TimeControl project-oriented timekeeping system and has been a Microsoft Project Solution Partner since 1995.
Chris Vandersluis can be contacted by e-mail at: firstname.lastname@example.org
If you would like to read more EPM-related articles by Chris Vandersluis, see HMS's EPM Guidance site (http://www.epmguidance.com/?page_id=39).
We'd love to hear your thoughts. Choose the type you'd like to provide:
Our feedback system is built on GitHub Issues. Read more on our blog.