“Time after Time” goes the song by Cyndi Lauper. Time has been a pervasive theme in software development projects, and in fact, for all projects. But what time are we really talking about? What defines late? Is time the most important control measure? There are three distinctly different “time” perspectives: planned versus actual, elapsed time, and schedule performance. Each of these place a different perspective on “time.” So our song might be “time after time, after time.”
The usual perspective on time comes from the emphasis on planned versus actual time. In general, making the plan is good — not making the plan is bad. Unfortunately, plans are more about politics than estimates in many organizations. Plans are more likely to be wrong than not, but the people doing the work are usually blamed for schedule overruns. Plans can also be target dates — dates when a project result is needed rather than an estimate — a legitimate management request. Unfortunately these dates are often communicated to project teams as an absolute requirement rather than as a “desire” to be considered in the planning and not a mandate. Between the problems with consistent estimating, the uncertainty surrounding the future, politics, and a myriad of other factors — planned versus actual time is a very complex topic.
The second perspective on time is elapsed time — time from the beginning to the end of a project. When some people declare — “The project is late,” — they actually mean the project is taking too long, irrespective of the planned date. For example, even though a project is planned for 2 years and is on schedule, the perception is often negative just because of the total time. On the other hand, a project that delivers results in 3-6 months will usually be well perceived. To some extent regardless of plans, results in a short period are considered successful while longer periods are considered not successful
The third, and last, perspective on time is that of schedule performance — a perspective that far too few organizations actually look at analytically. This could also be called a benchmark view of schedules — as in “what is the performance of others in the same circumstance?” For example, if you have a software project developed in a certain technology, of a certain complexity level, that produces a 100,000 lines of code, with a team of 10, in six months — how does that performance compare to other similar projects? These kinds of comparison numbers are available from several metrics firms. I’ve seen projects that were considered failures from a plan versus actual perspective, that had above average schedule performance when compared to industry norms.
Agile development can help in coming to grips with some of these issues — commissioning shorter projects, delivering incrementally with timeboxed schedules and variable scope — but the fundamental problems of politics and reality versus fantasy can still exist. Getting a handle on “time” problems is not a simple issue and a better understanding of these three time perspectives — planned versus actual; schedule performance, and elapsed time — can help organizations address the real and complex issues around time.