November 25, 2010
Many large companies are concerned about measuring their business performance. It is not always obvious which departments, projects, products, and customers are more profitable and hence where the company’s focus should be. One approach that is helping the large organizations figure out their profitability is called Activity Based Costing. The model translates resource expenses into costs of basic activities constituting higher level projects and processes and from their derives product/service/customer costs. Such an analysis compared to the revenues generated by the corresponding product/service/customer helps to decide how resources should be used more effectively to maximize profitability.
You can find more detailed explanation of ABC on the Internet, here is just one interesting quote from http://www.asaresearch.com/articles/abc.htm:
Many experts believe that the best method for measuring a business may be “Activity Based Costing”. Some accounting software products such as SAP, Syspro IMPACT Encore, and Deltek offer strong ABC accounting.
The ABC model has a number of problems though that make its adoption quite problematic:
… the process of calculating activity expenses through interviews, observation and surveys has proven to be time-consuming and costly to collect the data, expensive to store, process and report, difficult to update in light of changing circumstances, and theoretically incorrect, by suppressing the role for unused capacity when calculating cost driver rates.
So an alternative approach for estimating an ABC model, called “time-driven activity-based costing,” addresses the above limitations. It is simpler, less costly, and faster to implement. Here is a great paper explaining TDABC and how exactly it is better than the original ABC model: Time-Driven Activity Based Costing. One of the key elements is how you measure an activity, and TDABC seems to be doing this by estimating time required by an activity:
The one new information element required for the time-driven ABC approach is an estimate of the time required to perform a transactional activity. As discussed earlier, an ABC system uses a transaction driver whenever an activity − such as setup machine, issue purchase order, or process customer request − takes about the same amount of time. The time-driven ABC procedure uses an estimate of the time required each time the activity is performed. This unit time estimate replaces the process of interviewing people to learn what percentage of their time is spent on all the activities in an activity dictionary. The time estimates can be obtained either by direct observation or by interviews. Precision is not critical; rough accuracy is sufficient.
I really liked the TDABC paper but I am sort of confused by these two statements:
- This unit time estimate replaces the process of interviewing people to learn what percentage of their time is spent on all the activities in an activity dictionary.
- The time estimates can be obtained either by direct observation or by interviews.
I understand that if you have the estimates you do not need the interviewing process. But, how exactly do you obtain these unit time estimates? The 2nd statement says, by interviews. So, do we get rid of the interviews or not? I am not sure what direct observation means exactly.
In any case the TDABC model makes alot of sense to me, and I like the idea of using time measurements instead of purely transactional measurements (10% – activity1, 20% – activity2, … = always 100%). I even think that you can do better than just the estimates. Organizations that use project management tools capable of time tracking could be collecting actual time measurements quite easily (depends on the tool of cause) all the time. Anyone tracking their tasks for PM reasons would automatically be logging time spent on the tasks. All that needs to be done additionally is proper categorization and directing that data into one of those TDABC systems (i.e. SAP, AcronSys, …)
So I am thinking the time measurements earlier generated by interviews could actually be a natural by-product of the PM task tracking process and will not be time consuming at all. A PM product that makes it very easy for people to track time could basically enable ABC/TDABC models for measuring business performance.
What do you think?
Here are two more links with more information on TDABC:
November 16, 2010
If estimate is a guess then we are for continuous re-evaluation of the guess. What I do is continuous re-estimation of my tasks. Usually as we work on a task it becomes clearer what really needs to be done, we get more familiar with the problem, so every day we can mark what is done and re-estimate the remaining work. This means that for all your tasks at any given time you will have the best guess. Can you do any better than that?
November 15, 2010
Whether meetings are harmful or an alternative to working they do take place. We all probably have one or two meetings this week, entered in our calendar by ourselves or someone else. My observation though is that most people do not track these scheduled meetings when estimating time required to complete tasks. Although I think it would be quite useful. Functional team members work on their tasks in between meetings so the more time is taken by meetings (let alone the time spent on context switching) the less time you have to work on your tasks. So at minimum every meeting pushes out your schedules.
What each of us on the team does for estimating tasks is he uses our visual work-hours calendar. The calendar defined by your work-hours time profile (i.e. Mon-Sat, 9am to 5pm, minus 1hr for lunch) shows only your available work-hours. Additional per day adjustments to the initial time profile make it quite flexible:
- Any meeting hours scheduled in your Google or Outlook Calendar are cut out from your work-hours calendar automatically (you don’t work on your tasks in the meetings).
- Some days you work more hours than the 8hr time profile, and some days less. So any day in the calendar you can be adjusted by +-Nhr. You usually do the adjustment for the day that is ending (at the end of your work) to reflect how it actually went.
Keeping the accurate trace of how many work hours were and will be available could add more clarity to estimating and communicating on schedules and commitments. It could also serve as an explanation of why schedules are slipping, the next time your manager asks you (because he set up all these meetings). Plus, next time a person setting up a meeting for you may find out that his own task shifts, because it depends on your deliverable. Just another reason to think if requesting that meeting is really necessary.