A friend described an interesting analogy to me, and I am going to recreate it here.
When planning a project, are you more interested in the dates every activity happens, or are you more interested in how all the activities are connected together? Which focus will guarantee success?
The answer depends a little on what kind of work you are planning. Event-based planning focuses on the sequence of activities needed to complete the project. Time-based planning focuses on the time available and attempts to get as much done as possible, according to the clock.
And here is where the analogy comes in. In baseball, there is a clear sequence of activities from the first inning to the ninth inning. There is even allowance for ending early (if the home team is leading after the top of the 9th), or for extending the game when there is a tie. The primary focus is executing the events required to get to a win, not how much time it will take. (The longest professional baseball game was a 33-inning minor league game in 1981.) This is an event-based project with an understood sequence to get to the successful conclusion.
Time-based planning focuses on the timing, regardless of what happens in a given time bucket. In soccer (or football to the rest of the world), the match is played for a specific time. Each time period is controlled, and there are very few reasons to pause the clock. Depending on the league, there are rules for adding time to the play - all decided on the field by the referee. But if you are a soccer fan, you can expect nearly every match to be done in 90 minutes (plus a 15 minute halftime). The resulting score may be nil-nil or a 5-6 nail biter. The primary focus is time, not the activities within the match. (Association Football on Wikipedia).
Trying to run a baseball game to a clock would end up in a very different game. And trying to set a soccer match based on the number of possessions or goals or some other event-based rules would give you another game altogether. I won’t comment on whether this would be more or less interesting.
If you are trying to run an event-based project by locking down all the work to a clock or a calendar, I would wager that you will not get what you think. Similarly, if you try to describe an Agile time box by the sequence of events to be executed, you would be thrown out of the daily standup after about 2.3 minutes.
I don’t quite know how to stretch the analogy, but there is another aspect of these approaches - variability. There is always variability in human endeavors (look at the scores of those baseball games and soccer matches). For event-based projects, the way to manage variability is with strategically placed time buffers. Time-based projects must have a buffer of scope to handle variability.
The whole reason I am writing this is that people too often mix these things together. They try to play a baseball game with a time clock. Each event in a plan is given a start and finish date with no acknowledgement of variability, even though it is build into the individual tasks. There is no opportunity to finish early or start early, and there is often no real punishment for finishing the individual activities late. Unfortunately, the result is usually a game no one enjoys. The project team must decide to either to reduce scope or extend the time. (And often spend more money in the process.)
If you are playing baseball, throw out the timer. In event-based projects, figure out what the flow of work needs to be to successfully accomplish the project. Buffer the overall project. And execute like the project actually matters.