TeamMember Hourly Rate in TaskList Rollup sum

  • Pablo Casado

    Pablo Casado - 2010-03-12

    I need some help.

    Today I added a column to the Team member list dialog in the WBS.
    I added an hourlyRate field to the TeamMember class, I can edit the column, save the hourly, it works.

    But now I want to add a column to the task list project rollup summary page next to the Assigned To column.
    This column I want to display Actual Time * Hourly Rate.  This way I see an actual monetary total cost.

    I need some guidance on how to do this. I dug around EVTask and EVTaskList neighbourhood but EVTask only has a List of Strings containing the names of the assigned users. Should I somehow instantiate a TeamProject object which has a getTeamMemberList method and from this I can derive what I need.

    Am I heading in the right direction here?

  • David Tuma

    David Tuma - 2010-03-12

    No - I don't think the approach you've described is correct.

    First off, an EVTaskListRollup is not tightly coupled to a team project.  The user is allowed to create any number of rollups that may or may not have any connection to a team project.  In addition, they can create master EV rollups that may be rolling up data from many different team projects.  So when you look at a particular EV schedule, there won't be a way to find or construct an appropriate TeamProject object to pull hourly rate data from.

    Instead, you probably need to integrate with the data flow pattern that is currently used by existing EV logic.  First, here is an overview of the data flow:

    1) When you save the WBS, it also writes a file called projDump.xml in the same directory as wbs.xml.

    2) When an individual performs a "Sync to WBS," it compares the data in the projDump.xml file to the data in the personal plan and makes changes as necessary.

    3) At certain points in time, and individual's personal plan is exported to a ".pdash" file, in the same directory as wbs.xml. Earned value data is included in this export.

    4) The Team Dashboard imports data from all of the ".pdash" files associated with the project.

    5) The team-level rollups are computed by using the data imported from the ".pdash" files.

    So now, some implementation detail regarding your specific scenario.

    A) For step (1) above - the writing of the projDump.xml file - you may already be covered.  That file is written by the teamdash.wbs.WBSDataWriter class, but that class defers to the getAsXML method of the class to write data about each team member's schedule.  If you've already modified that method to support saving cost data, then projDump.xml is probably already including cost-per-hour data.  Take a look at the contents of the projDump.xml file to make sure.

    B) Step 2 above is performed by the teamdash.templates.setup.HierarchySynchronizer class. I would advise you to look at the saveScheduleData method and save cost-per-hour data into a field if it is present.  Then look at the syncSchedule method. This method is pretty complex but that can't be avoided, because it is handling the possibility of simultaneous edits that may have been made in the Team Member List and in the Task & Schedule window, and detecting which changes should be copied in each direction. You will need to understand this method and then add some logic here to write the cost-per-hour data into the personal schedule. I would advise that you use a call to tl.setMetadata().

    C) After you have made a change to the HierarchySynchronizer class, you are going to need to recompile it and put your recompiled .class file into the file. Then copy the new file into the processdash/dist directory so you can test.  Please note that since you don't have a digital signature for signing your modified ZIP file, all the code in the file will now be confined to the Java sandbox which will cause things to break.  You can turn off those protections by modifying the ProcessDashboard class so it does not call DashboardSecurity.setupSecurityManager().  But realize that you are opening a hole for a possible security vulnerability by doing so.

    D) Next, you will need to modify the EV calculation logic.  I would recommend adding a few fields to the EVTask object for baseline cost, planned cost, and actual cost.  Then, you'll need to modify the net.sourceforge.processdash.ev.EVCalculatorData class to compute and set the values of these fields.

    E) Next, you need to display the values you have just calculated. This can be done by editing the EVTaskList class.  Look in the dashboard SVN repository at changelist #3311 for an example of the changes you might make to display the new columns.  At this point, you should be seeing cost data in the personal dashboard for a personal schedule.

    F) Next, you need to modify the EVTask.saveToXML method to write each of the new cost fields.  Also, modify the EVTask constructor that takes an XML Element so it reads these fields.

    G) Finally, you will need to modify the calculation logic so it sums up cost data when computing an EVTaskListRollup. You might be able to accomplish this in the EVCalculator.sumUpNodeData method - but use caution; this method is called from EVCalculatorData too, and you don't want to double-count.

    As you can see, this is not a trivial change.  But that is because the dashboard's WBS sync logic and EV calculation logic is very sophisticated.

    As a completely separate (non technical) note, I'm curious about the accuracy of the data you are going to report using this method.  Most teams that use TSP earned value techniques find that they only have 12-15 "task hours" per week in their EV schedule, even though they are at work for 40 hours.  The other time is eaten up by overhead and recurring tasks, but is still billable time.  Do your teams not observe that pattern as well?  If they do, you will finish this enhancement and your cost calculations will be off by 100%.

  • Pablo Casado

    Pablo Casado - 2010-03-15

    many thanks for that detailed reply, I see have some work to do.

    As far as the data accuracy problem, this is the most talked about issue in all my client's TSP projects. It's a very contentious issue that drags launch meetings and continues for the entire duration of the project.

    In our team we have to accurately keep track of the "non-project-task" but still billable time. Therefor we always create tasks where we estimate effort and no size. These are on-going tasks that never finish until the project is completed.  Without accurately reporting the time spent on these non-tasks how can any accounting department ever accurately bill TSP projects to their clients? The typical effort-only tasks we add are Meetings, Project Management, General Admin etc.

    I'm interested to know what your TSP teams do?

  • David Tuma

    David Tuma - 2010-03-15

    Yes, this can be a confusing and contentious issue for TSP teams. To get past the contention, it is important to truly understand the underlying problem.

    TSP has a goal to track the progress of your project and produce useful projections for the future (for example, the completion date).  When you look at the equations that perform this analysis, you will find that they are based on a concept of 'project velocity' - how quickly are tasks being completed?  For this 'velocity' measurement to be accurate, it is most helpful if the items in your TSP earned value schedule represent true, non-recurring pieces of work that are getting you closer to the goal of completing the project.

    Of course, those discrete pieces of work are only one part of a successful project. There are many other pieces that relate to communication, coordination, "sharpening the saw," etc. Because these tasks are ongoing, their estimated and actual times are dependent upon the project duration. That is, if your project lasts an extra month, you'll have an extra month worth of meetings; if it ends early, you get to skip a month's worth of meetings.  The dynamic nature of these ongoing tasks is a poor fit with the 'project velocity' approach that TSP uses for schedule analysis. As a result, including them in your TSP EV plan may interfere with the TSP analysis calculations, resulting in projections that are of little value.

    So the key thing to realize is that TWO different things are being measured. TSP is ultimately trying to plan, measure, track, and project the percent complete of the project. On the other hand, the accounting department wants to track billable cost. It is nothing more than a coincidence that both of these objectives can make use of a time log.  Unfortunately, when people see that these unrelated objectives both require time tracking, they often assume that a single time log will suffice for both.

    Here is an analogy based on driving a long distance. TSP wants to watch the odometer of the car and see how many miles you've traveled, how many remain, and how fast you're driving. But accounting wants to know how much you've spent on gasoline, tolls, meals, and motels along the way.  If you capture information about motel cost and try to include it in your mileage calculation, it will make the mileage calculations less useful.

    So that describes the underlying impedance mismatch between the two systems. To move past it, management must be educated. In the past, I've seen teams use the following approaches to this problem (of course, there may be others):

    Approach #1) Maintain two separate time accounting systems. In TSP, use the EV schedule to track fine-grained tasks that directly impact the forward progress of the project. In the corporate time logging system, track time against coarse-grained buckets (e.g. charge codes) that encompass ALL billable work. Since the TSP work is a subset of ALL work, you would expect time time in the TSP time log to be less than the corporate time log; but no other mathematical relationship can be demonstrated.

    Approach #2) In TSP, use the EV schedule to track fine-grained tasks that directly impact the forward progress of the project. Then use ratios to relate this to the corporate time accounting system.  For example: in the launch the team may plan 15 hours of TSP time per week, but you know that they will be at work for 40 hours.  So at the beginning of the project you use this ratio to calculate the estimated project labor cost in dollars.  Then during the project, individuals capture time in their TSP time log. At the end of the day, they calculate the percentage of TSP time spent on each billable charge code. Then they use those percentages to allocate the total amount of billable time across the charge codes. For example: "Today I spent 25% of my TSP time on Project A and 75% of my TSP time on Project B.  I've been at work for eight hours. So in the corporate time accounting system, I'll put 2 hours in the Project A bucket and 6 in the Project B bucket."  This technique allows a single time log to be used as the basis of both accounting systems, using an assumption that indirect time follows the same percentage as direct time.

    Approach #3) In TSP, track every hour of billable time. (This is what your teams are doing.) This is less than ideal, because it has effectively hijacked the TSP earned value system and repurposed it for corporate accounting.  TSP will now produce metrics that are helpful for accounting; unfortunately they may be less helpful for project tracking and forecasting.  (As a side note: if you have individuals that are matrixed across multiple projects or charge codes, and they have to do an overhead task like reading email that doesn't directly relate to a single project, they will end up manually performing the time distribution described in approach #2.)

  • Pablo Casado

    Pablo Casado - 2010-03-16

    many thanks for your insight. I shall hi-jack your analogy for shameless re-use ;)

    Option 1 requires convincing developers to maintain 2 time keeping system. Maintaining 1 system already has high inertial resistance, 2 systems will require wielding the big boss stick.

    Option 2 requires the accounting department to do some arithmetic, I guess they are most qualified for this but they will complain. Or either the planning manager or team lead must do some work to provide accounts with the figures they want. Sounds like something the process dashboard could do automatically using the hourly rate field I added to Team Member list in the WBS and then also doing the little song and dance to the source you described above.

    Option 3 is not an option. You have convinced me of this.


Log in to post a comment.

Get latest updates about Open Source Projects, Conferences and News.

Sign up for the SourceForge newsletter:

JavaScript is required for this form.

No, thanks