I recently read a complementary copy of All Your Money Won't Another Minute Buy: Valuing Time as a Business Resource by Curt Finch of Journyx. And then this afternoon, I had a nice conversation with Curt around the topics raised in his book as part of his Blog Book Tour.
I found the book a useful overview of time tracking and clearly saw Curt's personality come through in the writing and the tone, particularly now that I've talked with him. There are a number of cases drawn out of Curt's personal experiences or from experience with their clients, and these added nicely to the topic. There are a couple chapters that don't quite seem to fit with the theme, such as the last couple of chapters on Web2.0 and other changes happening in telecommunications. (The connection is that Journyx have a software-as-a-service option, where companies could presumably mashup time tracking data with other operations data.) Curt tells me that most of the material in the book is drawn from articles he's written in the past -- a very reasonable way to write a book.
Journyx makes a time tracking application, so I had to read this with the view that the author is describing time tracking from their perspective. There are several chapters dealing with selection questions, and I assume that most of the "how to select a system" aspects lean in Journyx' favor.
The Blog Book Tour today was a friendly conversation, primarily around project management with frequent dives into how and why "time" is an important factor. Namely, time lost is time lost. I am particularly reminded of a Theory of Constraints quote, "Time lost on the constraint can never be recovered. Time gained elsewhere is a mirage." Curt completely acknowledges that the data recorded by Journyx is for historical purposes, that it shouldn't be used to manage execution of a project, which was a concern I had in reading the book.
So, the big question for me: why is time tracking so important to project management? I don't think I asked this directly. But the conversation we had talked around it. Obviously, actual execution data is going to be useful the next time similar work comes up for the organization. What else?
Curt suggests that collecting time data from a project outset can help indicate how things will go for the rest of the project. If the project consumes 25% of the allotted time while only completing 10% of the activities, vast experience has shown it is nearly impossible to catch up and turn a project in on time: task estimates never seem to be too high.
For those who know ToC and Critical Chain Project Management (CCPM), there are some flaws in this thinking. CCPM operates with buffers to judge the status of the project. But there are also behavioral aspects that must be followed in a CCPM implementation, which changes some of the assumptions underlying the "vast experience" comment above. Namely,
-
Recognize that it isn't successful task execution that creates project success, it is successful project execution.
-
Remove multitasking, where one person is forced to make progress on multiple tasks without completing any of them.
- Stop using estimated task times as a sledgehammer: ask people how much time they need to complete the activity at hand.
- Use "time remaining" information to prepare relay-race behavior of subsequent activities and take advantage of early finishes.
-
Corollary: Ask what is keeping the activity from being complete. This will give the opportunity to do Pareto-style analyses of the delay data to find the most common sources of actual project delay, rather than focusing on causes of task delay.
-
Set task priorities based on how much buffer consumption is attributable to the chain connected to the task. Don't allow the people tied to these critical tasks to be drawn into other work
Curt and I talked about a number of these aspects of project management, and he clearly sees the value in operating this way. In fact, Journyx application is being updated to ask for "remaining time" and then push it back into the project management system for status updates.
The idea of removing multitasking had Curt suggesting similarities to the mental state of flow: getting into a state where work just comes and nothing gets in the way. It also reminds me of the recent Quite Time Pilot at Intel. In some CCPM implementations, the current "owner" of the critical chain task gets a piece of red chain or other symbol that means, "Do not drag me away from this work."
How do you get the updates into your project management system? Do the individual knowledge workers do the updates? You don't want to go too far up the food chain, because it is the workers themselves that best know what is going on with their activities. But you don't want to distract them from their work, either. Curt recounted a story where a clerk was assigned to follow highly skilled people around and get their updates. And he had another where the update process went through the manager via short updates at the beginning of the day.
One thing that we started talking about that ran through the conversation. The project management system needs to be as simple as possible (but not too simple). Curt mentioned The One-Page Project Manager by Clark Campbell, and he suggested that it was reminiscent of presentation ideas of Tufte or the writing recommendations of Strunk & White. The idea is that the information needs to be presented in a way that people can take action (and know what actions they should take). Pages and pages of data or reports aren't going to make that happen. In the CCPM world, the buffer status report gives a normalized number (or graph) for a single project, and multiple projects can be plotted together to get a quick glimpse of the health of the portfolio.