A timeline is a retrospective representation of a linear sequence of significant events which have occurred during the accomplishment of some activity. A timetable provides a corresponding, forward-looking series for pre-arranged events, and is often organized as a tabular list. Such timetables are used to plan and track such activities for performing and reporting on future work. Each of the events associated with these timelines and timetables may be comprised of either top-level milestones or more detailed inchstones.

In order for the times of these events to be planned or captured reliably, all such events should be performed within a well-defined and universally adopted workflow. The related process documentation and associated process assurance activities for this workflow can further organize this work into standardized flows, and help ensure that the throughput is adequate to achieve defined outcomes.

Once this is done, these events can also then serve as a means of budgetting slices of time for the various standard work activities, in the context of a target throughput pace desired for this work. The events can also become decision gates by which the overall activity is managed. By organizing the planned and actual information about these events, and recording and monitoring progress and historical tendencies over time, timelines can be used to visualize the status of this work, highlight patterns of successes and failures, and identify constraints in the flow of this work through a system. This information can then be used to identify opportunities for future improvements to how the work is being performed. Simply put, having a schedule for an activity doesn't by itself enable that activity to be completed on that schedule. For that to happen, a plan must be created which elaborates the steps involved in accomplishing the activity in a logical way, the time allocated to those steps must fit within the schedule, and the people who must implement that plan must have the will, belief, and wherewithall to execute the plan. Then, these plan agents must cooperate to update the plan as conditions and their understanding of the situation evolves, and they must effectively communicate the plan's status to the affected stakeholders.

When you've decided to use timetables and timelines for these purposes, it is easy to attempt to try to do too much too soon, and establish a timetable for as many events as possible in the system in question. While collecting a lot of data sounds appealing, the reality is that the more data there is to collect, the less likely it will be for the individual data items that are collected to be reliable; it's very difficult to achieve broad discipline without at least an initial focus. Rather than adopting such a 'breadth-first' approach, it is far better to begin with collecting a few key measures, and become experienced in ensuring that these measurements, and their data collection and decision-making approaches, are robust. These initial key measures can then be used to determine where to focus additional attention as the timetable events are expanded.

In the context of these initial events, any events which are reported as being completed must be really complete; accuracy of the actual timing of these events is necessary in order to establish trust in the reporting system, and to be able to use that information in effective decision-making down-stream. If the collected information is never used in decision-making, there will not be sustained motivation to perform the collection consistently; there is no motivation for people to collect data just for the purpose of collecting data. Even when the data is planned to be used, there is frequently a problem with status reporting of such information on many project teams. There are tendencies to report events as completed, even though work has not really been completed. There is also a tendency to avoid reporting the status of work at all. This can occur if individuals are being held accountable to do work that they were not involved in planning the commitments for, when there is a lack of clarity about what the events or commitments actually mean or how to satisfy them, or when problems occur during the activity, and individuals are fearful or embarassed about the outcomes these problems will lead to. All of these problems are complicated when too much data is attempted to be collected too quickly. The goal should be to isolate problems so that follow-on troubleshooting and additional instrumentation can analyze them, not to record every possible event.

To highlight how the number of measures can affect the predictability of target outcomes, let's say you've defined 5 serial inchstones for an activity which occurs weekly, and you believe that each of those events has a 90% probability of being completed within 4 hours of the original plan (the tolerable range of delivery at the end of each week). When evaluated over an extended period of time, it would be very unusual for individual measurements of such events to be normally distributed around the mean; instead, the distribution will nearly always consist of a few occurrences of early completions, and a concentration of data close to the targeted timeframe, with a spread of late-occuring events of various durations, and a long tail to the right for a few really late situations. Given this distribution, it will be rare for each late event to be offset by a corresponding early one. Statistically, with each event as indicated above, the likelihoods of on-time performance at the end of the chain will be .9**5, and will thus occur only 6 times out of every ten runs. Adding extra events to our tracking chain will not improve this probability, as it will only increase the exponent in this equation. Adding such events will also just make your system more complex, and will take more time and effort to status these measures. The real solution to improving predictabilility is instead to improve the likelihood of accomplishing each event itself, and actively manage a buffer for realistic contingency time at the end of the chain, as suggested by the Critical Chain Project Management methodology.

For an example of why clarity is important in defining such event definitions, consider the term 'project completion', as used by a home builder in discussing the status of building a house. There are at least three different interpretations of such completions, by different stakeholders; accomplishing each of these (the inchstones) in succession is critical to fully achieving the milestone the developer will ultimately pursue as project completion. The first inchstone is indicated when a house is substantially complete, which is when it can satisfy its intended use, i.e. the occupants can move in. This event might be measured by the availability of an occupancy permit. A second inchstone might be satisfied by the actual occupancy by the owner themselves, and might be measured by the owner's acceptance of the house, release of the final payment draw from the bank, and agreement on a punch list of outstanding items to be resolved. The last element of completion would then be final completion, which would occur when all punchlist items were signed off, and the builder no longer needed to have resources allocated to the project. As you can see, depending upon which stakeholder is involved - the buyer, bank, or builder - the definitions of 'completion' are somewhat different.

You can see from this example that defining a variety of attributes are important in order to ensure that events are useful for planning purposes. Each of the these attributes should be identified for such events:

• What is the event - What is its title and how does it fits into the linear sequence? For example, what are the preconditions for the event? What new things are enabled, once the event has occurred? Is the event always required, or is it's occurrence optional under some circumstances?
• Who is accountable for planning, reporting, and acting upon the event's occurrence - These responsibilities are often spread across different people, and a defined protocol of communications between them is important, to 'close the loop'.
• When is the event expected to occur - what triggers the events? This could be the passage of a prescribed period of time from some prior event, a hard calendar time event, or some measurement threshold being exceeded that is actively being monitored or sampled. In any case, the precise event's 'leading edge' timing must be carefully described.
• How is the event's completion defined - a measurement specification (see this example) is typically required to define the standard units, collection frequency, and validation approach for the event data. Events may also be identified by the completion of an activity (such as a design review being the culimination of the design activities). Entry and exit conditions should be clearly described; events that depend upon inputs from upstream activities should not accept defects from those upstream processes, because otherwise, the upstream event will be recorded as having been completed, even though that has really not occurred. Unless this validation has been done, there is risk that rework will just be passed downstream, and timing measurements will thus be unreliable.
• Where are the details of the event to be recorded - an 'authoritative repository' for capturing and examining the historical record of these events should be defined, and a means for incorporating corrections to that record should be provided.

An example of a timeline is provided here. It depicts the initial posting date of all original content posted on this web site. This 'initial publication' event is the date and time when initial content was first made available for a given article on the site; you can click on any of these events to pop up a bubble containing more information about each of these articles.

You cannot tell from this depiction when the material for that article achieved a 'final completion' state per above description, but you can note by browsing past periods of this timeline that there are periodic trends visible for the initial publication event, such as periods when a large volume of material was published in a short timeframe. This was often followed by other periods in which no publishing occurred at all. From this, you can determine that the rate of initial publishing clearly has a large variability to it. Note that while such a timeline can be useful to highlight such trends and patterns in this publishing, there is certainly not enough data available from this material to enable predictions of when the next occurrence of a published article might occur, when the next burst might occur, what the capacity of this system might be next week, or how one might improve the reliable throughput of this system (though each of these concepts themselves could certainly be critical for some stakeholders).

Planning and estimating such events is often not easy, since creating each individual article is a creative process, and the measured time and effort to produce these individual writings can vary as much as 300% (even with the same person doing the work) in my experience; this range is backed up by other experience in industry, given ambiguous requirements. In such a context, each article is essentially a unique problem to be solved, which may make it different from many precedented activities previously written. Such articles can turn into research projects that depend upon the focus and enthusiasm of the researcher, rather than a customer's specific need. This is different than the situation which presents itself in most production settings.

When you are performing repetitive operations in production settings over and over, it is possible to develop a well-defined, standardized set of historical results for such operations that can serve as the basis of reliable estimates for future work. Such results can then provide an accepted standard flow for routine work that is well defined. Adopting such standard work takes a long time to implement and is often problematic, but is especially so when the work itself has a high degree of uncertainty to it, such as when the work requires troubleshooting, is highly creative, or has little precedent to it. Understanding such sources of variability requires an adequate timeframe to collect and analyze representative data about similar situations, understand its root causes, and include an appropriate schedule accomodation in the corresponding planning.

Until the above attributes are defined, you run the risk that measurement errors, rather than process root causes, become a noisy distraction in focusing your improvement efforts. Once such information is defined and collected over time, many other root causes of variation can affect the execution of activities associated with planned events, such as: 

• The adequacy of planning to prepare for doing the work, and process management to guide it
• Inefficient multi-tasking of resources
• Variability in the competency and abilities of individuals who are doing the work
• Inattention to quality escapes in performing the work, either during the activity, or upstream of the activity
• Availability of resources, information, or tools required to perform the work and improve the capability to do the work
• Variability in the nature of the work itself

Let's explore another example to highlight some of these challenges. Early in 2008, a series of articles were published on this web site around the theme of personal mastery. As a part of that series, an experiment on goal-setting and planning was established to plan and track the exact number of hours and minutes required for writing each article. The data collection throughout this period was automated so that times were collected non-intrusively, to aid in the robustness of data collection. This collected data was then used for predicting the completion of this overall activity. A timeline for the articles in this series is available by clicking on this link; this timeline depicts the duration of the writing process, bounded by initial and final publication times for each article; clicking on individual items pops up additional information, which highlights the wide variation in the number of revisions that different articles went through.

An important context for understanding these personal mastery articles is that all of the work associated with this series was performed on a 'time-available' basis, as a personal hobby. It is thus subject to the classic challenges of multitasking, and had to compete with other activities at home. While the time spent on each revision of these articles was relatively small, this time was scattered over many different editting sessions over a long timeframe; it was rarely possible to give adequate attention to any one area, especially when 'fresh' mentally. Despite this, there was still wide variation across articles (typically, +/- >50%) in how many revisions were required to achieve 'completeness', how much time each article took to write, and how accurate estimates of the work required actually proved to be on an article-by-article basis. Analyzing this data indicates there was a gradual learning which occurred during this period... but that learning caused estimates to be increased, rather than productivity to be improved.

Was this data collection worth it? For my own recreational blogging, the answer is no, at least in the short term. But if others depended upon my ability to deliver such results within a target timeframe, the answer would more likely be yes. Of course, in that context, the temptation then might be to use a 'safe' estimate represented by the worst case previously experienced time, rather than offering a 50% likely time for any estimate. That, of course, would not optimize flow, though it might improve predictability of 'completion'. This reinforces the importance of understanding exactly what outcomes are desired for a given system, and their relative priorities, so that the best possible decisions are made to optimize those outcomes.

The above example is quite simple relative to the many sources of variation cited above, yet it highlights the challenges inherent in even such simple examples. In complex systems involving these additional sources of variation, if an event framework is used as the basis of holding people accountable to key events, and if the timetable or timeline is not yet robust,  it may be easy for the participants to fall into attitudes of victimhood and process firefighting, given the many risks associated with such data collection and management. A longer view is warranted, with more proactive approaches that will allow the system's outputs to remain competitive in the marketplace, and be improved in a disciplined way. In this context, a timeline can be helpful to begin analyzing the flow of the work through an organization, and prepare for mitigating the risks such as are described above. Just don't expect the train to start running on time overnight, just because you begin publishing a schedule for it!