If time is an illusion (and lunch time doubly so) why do we refer to it as one of the three sides of project management’s iron triangle? We certainly have the ability to negotiate time, to allow it to pass quickly or slowly in a subjective sense, and to push the limits of what we can fit into a given space starting at one point in time and ending in another. Despite this flexibility, though, it always seems that time limits us even when we push ourselves to our most extreme limits.

What’s going on has to do with how we merge together three separate yet nevertheless distinct concepts into a amalgam called “time”. By putting the three together we come up with an easy to explain idea – time is a boundary for every project. By pulling them apart, we can get a much clearer picture of how a project works with time and what it means practically for the projects we run.

What we generally think of as “time” in a project is composed of desired delivery dates, required delivery dates, and available work hours. The first we can negotiate; the second comes from some external factor we may have no control over, and the third measures the distance between where we are in the present and either the desired or the required delivery date. Confusion about that later point leads, pretty regularly, to disagreements and yelling matches between project managers and their sponsors.

Let’s take a look the three different elements:

1) The desired date
All projects, and most project iterations, have a “desired date”. That is, there is a generally agreed upon date when it would be nice for the system to come up and display operational stability. These are often called “go-live” dates but can slip if we run into technical or logistical problems. Each time the desired date slips, the project takes a hit as it moves from its original baseline.

Interestingly, many IT projects function entirely on desired dates. Executives negotiate among themselves when they would like to see a specific change or system go live. They then pass on these dates as required dates, even though they were primarily negotiated within the company and can be renegotiated if the situation demands it.

2) The required date
Some projects have dates set by non-negotiable external factors. For example, the government may require reports by a specific date or we may have negotiated a contract which stipulates particular behaviors from our systems by a specific date. We have to produce the result by the date or penalties begin to accrue.

Note that last phrase. Failure to meet a desired date means that someone gets annoyed or has to renegotiate a point with another part of the organization. Failure to meet a required date means the organization takes on risk or additional costs.

3) The available work hours
There’s only so many hours between the start of the project and the desired date. There may be more time between the start of the project and the required date; indeed there better be or the project starts off set up to fail. The total number of hours is further cut into by holidays, work schedules, and business requirements from HR or other parts of the organization. The total available hours is further compromised by system availability and the time required to learn the nuances of a particular environment or product.

If the work we have to do does not fit into the available time, we can try to change the circumstances controlling it (e.g. ask people to work longer hours) or try to renegotiate the desired date to come closer to the required date. Sometimes this works. More often, though, we end up cutting other parts of the project to make it fit into the work time available.

Let’s take this idea and put it into practical context. I’ll use as an example a project to replace leased desktop computers before the lease runs out.

In this case we started the work four months before the lease ran out. We wanted to finish it one month before the lease ran out. Every desktop we failed to return by the end of the lease period cost us a considerable amount of money (around $10 a day). Assuming we wanted to return all of the desktops to the leasing company by December 31st, this means:

We started planning to do this project in January
We started work September 1st
We have a desired date of November 15th
We had a required date of December 24th

Notice how we’ve already started to shave off available work time by setting the desired date two weeks before the end of the month. We could set the desired date to the 30th, but that would get us into one of the largest holidays in the US, not a good idea for what is essentially a logistics project. We need to finish this project before December, and it’s inevitable shipping delays

We have six weeks (roughly) to execute the work before we hit the desired date. It’s an additional five weeks (roughly) from the desired date to the required date – time we could easily use up if we did not plan properly before the work commenced.