So I’ve just been quoting from Robert Levine’s excellent book “A Geography of Time”. One of the key concepts that he draws out in this book is a distinction between what he calls “clock time” and “event time”. Let’s have a go at providing a definition of the two.
Clock time is pretty much what it says on the tin - it’s the time on the clock. It’s the time of appointments. Also crucially, it’s the kind of time that’s used when you’re “on the clock.” It’s the kind of time that’s used in business settings, for meetings or appointments, it’s also the time that can be equated to money in the famous “time is money” slogan - if you’re a business and you’ve got employees in the office between 9 and 5:30 then that’s costing you money.
Event time is a bit different. In my understanding of this distinction, event time focuses on the actual event that happens when it happens. Levine is keen to discuss how these approaches to time work in different countries and cultures. But on the whole, that kind of thing makes me queasy. So I’m just going to stick to the culture I know something about and use an example from that. Let’s take the example of a party. There might be a start time on an invitation to a party, but there’s also an understanding (in my culture) that for a social party, the start time isn’t the start time - anywhere two or three hours later than that would be perfectly acceptable. There’s also a point (sometimes) after the official start of the party when the party has really got going, and then later on, there’s a point where “the party’s over.”
The party example isn’t a bad one, but I’m not sure it captures something else which is very important about event time. And that’s a logic that surrounds them. The famous example which is given often, is the gestation period for a human baby. Nine women can’t give you a baby in nine months (although I suppose you could have a very interesting time trying). The birth of a baby is an event, and crucially, that event then sets is train lots of other events (nappy changing, birth registration, pranging the car the first time you let them take it out by themselves) and there is a logic to these events. Actually, I think there’s someone has written specifically about this time calculus. James Allen came up with something called “Interval Logic” - which is discussed also in Venkatesh Rao’s book “Tempo”.
What I find fascinating about this distinction from a point of view of project management is that in order to get anything done, you need to pay attention to both, but focus on event time. Of course you need to pay attention to clock time (CT?) because time is, to some degree, money and we all need money and if we don’t count it at least every now and then very bad things happen (which interestingly tend to be referred to as “events”).
On the other hand, focus on clock time is very oftenabsolutely the wrong thing to do, if you want to get things done. Why? Because of that event logic. If you have to do A, and when A is finished, you have to do B, and then when you’ve got A and B, only then can you wait for C before finally doing D. If that is the logic, in order to do D, you have to do A no matter how long A takes.
Just take in that last sentence. Because I don’t care how much you or anybody else rants, raves, threatens or cajoles, it is true. If that is the logic, in order to do D, you have to do A no matter how long A takes.
And, this simple, undeniable fact about how event time works, is the root of many project management problems.
[Before we get on to the real painful discussion of these problems, let me just take the opportunity to have an aside. If clock time is money, or is at least associated with money, event time is associated with value. I regularly do an exercise, right at the beginning of the courses that I teach where I ask people to tell me the words and phrases that they associate with a project that is going well. Unsurprisingly, they regularly talk about projects being “On-Time” and “To-Budget”. What always surprises me is that they almost never talk about the projects being valuable. I think by focusing on event time and so, therefore, focusing on the logic between events, you’re focusing on the value of things in time in a way that gets lost if you just focus on event time.]
What kind of problems?
“We’ve already announced that we’ll have D ready by Christmas I want to see a plan which shows we can do D by then.”
Does this change anything the event logic? No. Does this increase the likelihood that the event logic will be obscured right up to the point where everybody turns up at Christmas and there is no D? Oh yeah! And that’s just the very diamond tip of this iceberg of pain.
I think it boils down to this. If you’re interested in “Getting Things Done” (although I’m not sure David Allen has much to say about this) - big things, that involve groups of people over a long period of time, or even substantial personal projects then you’ll be very interested in event time, in the logic of events. Of course you’ll also be interested in clock time and its a associated costs, but that won’t be your focus. For example, if A, B and C are very similar kinds of activities, you’ll be very interested in the clock time that is consumed to achieve A because it tells you an awful lot about how long B and C are likely to take and therefore, when you’re likely to get D.
If you have no idea about “Getting Things Done” or if you cynically don’t care about it one way or another, you’ll be entirely focused on clock time and be oblivious to event logic. You’ll get almost nothing done, and the things that you do get done will be done in almost the most inefficient way possible - the way you do things will look curiously similar to the way software development is done in most large organizations.