Sunday, September 18, 2005

Thoughts on Project Time Tracking








In a couple of recent consulting engagements, the subject of time tracking has come up. For the organisations that have never required people to report time worked, there is an instinct that it is too much of an imposition on the work force and it would distract from getting the work done. There's an interesting reference to this in this article about Microsoft's use of MS Project from a couple of years ago.
gantthead offsite content
For organisations with a business model for delivering services (as opposed to a pure cost centre model), the idea of recording work done as a means of justifying billing is acceptable and may already be established.
The step to full task work effort recording against a baseline needed for Earned Value calculations can be too big a cultural step for some organisations. This is particularly true for those that already have some form of time recording - typically at the general activity type (vacation, project x, project y, administrative) - using a system that is already integrated into an accounting or payroll system.
One strategy that is often proposed is to use the EPM (Enterprise Project Management) system's task time tracking functionality as a front end to the legacy time reporting system - or vice versa. Designs for this kind of integration requires that key fields are present in the source system for matching records in the target system. It also implies that the administrator(s) of the source system have management processes that are sufficient for data management in both systems.
I'd be interested in readers' experiences and comments on this subject.

Labels: , , , , ,

posted by G McHardy @ 10:51 AM, Read More...  
7 comments links to this post

7 Comments:

At 11:20 AM, Blogger Jerry Manas said...

Graham, this is an excellent point, and I LOVE the Microsoft article you linked to.

I've heard of a number of failed EPM (Enterprise Program Management)tool implementations over the last few months, and in EACH case, it was due to the organizational culture's resistance to entering time. What was supposed to become an organizational enabler became a burden.

I like your suggestion that much depends on what you're trying to get out of it. If the focus is on billing a client based on hours, it becomes more critical to enter time. If the focus is on getting the work done, then using percent complete is quicker and often more accurate.

The trouble then becomes how to track "Actuals" if using Earned Value to track against budget. I know of some organizations using an "Earned Value lite" model, where actuals are collected at the high "project" level (as opposed to the taks or even milestone level) in the organization's normal time reporting mechanism.

To me, this makes sense and is "good enough" in most cases. I know that the Project Frontier site offers a "Streamlined" Earned Value approach using a point system (Garry Booker, the founder, occasionally posts on PMThink and may have some additional thoughts to add).

 
At 11:45 AM, Blogger Jerry Manas said...

Three caveats to my previous post:

1) For a capital project, where it's important to capture the labor hours spent on certain items (in adherence with SOP 98-1 capital reporting rules), it becomes more critical to capture time at the task or at least WBS level.

2) If an organization wants to capture history of how long it's taking to do certain phases (such as estimation, or testing, etc.) for the purpose of making improvements, it's valuable to capture time at the level being analyzed.

3) If an organization wants to do enterprise resource planning and balancing or if they're using Critical Chain to plan around constrained resources, it become more important to enter time.

In any case, if an organization makes the decision to capture time at the task level and use it for scheduling (for any or all of these reasons), then there's one additional thing they need to do.

They need to train the resources to revise the "remaining time" if it varies from what the system is telling them is remaining (which most enterprise PM tools will do). To just capture time spent tells us nothing about the future and cannot be effectively used for scheduling or resource availability.

That's not to say resources need to reforecast every task, merely that they need to change the automatic "reforecast" when reality differs from what the system is telling them. THEN, the system can calculate the TRUE percent complete.

So, at what level time is entered, and whether you need to capture "remaining time" depends on whether time is being captured just for historical or auditing purposes or if it's also being done for resource availability and scheduling purposes. If the latter is included, then "remaining time" is needed.

 
At 11:52 AM, Blogger Jerry Manas said...

Sorry, one more post on this (I just can't resist this topic).

If an organization does decide to require time entry, judging by the failure rate on this, it is CRITICAL to realize why it is that they're capturing time, what they hope to get out of it, and make that case very clear to the community at large. If people understand the rationale, they'll be more likely to buy into it.

But think twice about alternatives and whether the senior management support is there to fully drive the culture change if it is needed.

I'd love to hear others' experiences with how they've dealt with this organizational cultural challenge (perhaps the biggest barrier to implementing enterprise PM that there is today).

 
At 12:16 PM, Blogger G McHardy said...

Jerry, Thanks for the responses. In the earned value lite model I've worked with a client recently that was using that approach - in fact tracking labour hours by general activity type within a project. One outcome was that the (experienced) project managers were doing a lot of reverse calculation to try to figure out which tasks were actually having time reported against them.

 
At 1:14 PM, Blogger Jerry Manas said...

Graham, good point.

What I was referring to as "EV Lite" was just entering time at the "project" level (to get Actual Cost for Earned Value), but it could also be done at the general category level. It assumes you are using a manually entered percent-complete to track progress and maintain the schedule.

That can be simple and effective for scheduling and forecasting, and if at the right level, can give you labor hours broken out correctly for financials. But it has some major repercussions, as you've pointed out.

It won't give you true resource availability if that is a goal. Nor will it give you historical data at the lower levels. Most importantly, it tends to divorce the time-entered (i.e. actuals) from the project schedule (which is maintained via a manually entered percent-complete), with the result that PMs are forced to reverse engineer the actual time to integrate it with the schedule. Otherwise, if costs are going over-budget, how else could you tell which task or tasks set it over?

With the low project management maturity level of many IT organizations, this "lite" approach may be OK (which is what I was alluding to).

But if an organization needs to track time for true resource availability and wants better integration of actual costs with the project schedule for real budget tracking, then the way to go is to enter time at the task level. Otherwise, the result will be just what you encountered; project managers trying to reverse-engineer the actual costs back to the schedule.

 
At 4:44 PM, Anonymous Garry L. Booker said...

Yes, Jerry, I do have some thoughts to add. Thanks for prompting me. :o)

The core concept of Streamlined EVM is to focus your organization on its highest priorities and focus yourself on your own highest priorities. Measuring schedule performance and cost performance are not unimportant in Streamlined EVM, but they have to be done AFTER focusing on the details of technical performance. This is different than EV Lite which begins with integrating cost, technical and schedule performance, but only at a macro scale (e.g. this week I worked on Project X.) In other words, EV Lite foregoes useful detail in favor of integrated cost/technical/schedule measurements, while Streamlined EVM assumes that daily details ALWAYS matter and that focusing on technical performance is the first and most important step toward cost and schedule performance.

An essential element of Streamlined EVM (like Agile Project Management) is a weekly planning cycle for every individual. In these incremental weekly plans, details matter. You can't say at the end of the week, I spent 40 hours on Project X. You have to answer, did I accomplish the things I set out to accomplish on Monday. I have found that if I have a personal weekly plan that I created I am far more likely to keep track of my time accurately than if some authority orders, begs and threatens me to fill my time before the end of the week. So, I think it is far easier to socialize the idea of weekly planning than it is to socialize the idea of weekly time keeping. But weekly time keeping is an easy next step after weekly planning -- especially if individuals have ownership of their weekly plan.

By the way, the "compelling scoreboard" I have mentioned in previous posts can and should be an integral part of weekly planning and weekly time keeping, and the compelling scoreboard should include details right down weekly planning items. This is a significant departure from most EPM dashboards, which seek to reduce megabytes of useful details to stop light colors (two-bit depth!) and one-dimensional guages. If person X is not doing his/her weekly planning and timekeeping, a compelling scoreboard will make this fact clear all. I'm sorry I don't have graphic examples of a compelling scoreboard, but I'll get them posted on my site eventually.

/Garry
www.projectfrontier.com

P.s. the article about Microsoft developers eating their own dog food is funny in so many ways.

 
At 9:41 PM, Anonymous Garry L. Booker said...

Oh yes. I should have mentioned that I have a page on my web site about weekly planning. I just added a screenshot from Excel. This spreadsheet is what I use to do weekly/daily planning and daily timekeeping. It's an example of how to integrate cost/technical/schedule at a very detailed level.

The screenshot can be found at http://www.projectfrontier.com/planweekly.html#TimeTracking

I'm working toward converting this from Excel to a Macromedia Flash (ActionScript) application.

/Garry

 

Post a Comment

Links to this post:

Create a Link

<< Return to PMThink! Project Management Gateway