Time is Not Negotiable

Sometimes I wax theoretical. My mind just loves this sort of stuff (I was always really attracted to ‎abstract math). In Agile discussions, there are always interesting insights to be found at the level of ‎philosophy: what are the explicit or underlying beliefs for an Agilist? One of my favourite topics is our ‎relationship to time, our scarcest resource.‎

The Project Management Institute refers to three variables that can be negotiated or constrained for a given project: scope, resources and schedule. Schedule is an interesting “variable” in that we have no choice about how time flows. We can control how much scope to ask for, we can control how much money to put towards the work, but we cannot actually “buy” more time than, say, our competitors. This has important implications which deeply challenge the PMI’s PMBoK model of project management.

The idea of sunk costs, also know as “don’t throw good money after bad” is difficult for most people at a psychological level. We often feel like making just a little more investment of time, work or cash will turn an ailing effort around. Unfortunately, a traditional waterfall or phased-based approach to project work increases the psychological pressure to continue working, even when the project is “bad”.

We know from the recent Chaos report statistics that two thirds of all IT projects are still either failing or challenged. We know that the bigger the project, the more likely it is to fail. We know that projects in other industries such as construction and economic development also have low success rates. How is it that we put all this money and time into these projects without knowing earlier if there are problems?

The problem is, of course, time. We can’t predict the future. The farther out we need to see, the more uncertain the view. Not only that, but we can’t “go back” to correct mistakes. We can only correct past mistakes by changing our future behaviour… by using up more time.

One organization I worked with wanted to do a small web-based project. They had been “thinking” about this project for three years. At various times they had done requirements gathering and analysis with various stakeholders… and then failed to execute on the project. Finally they got around to starting the project. Using an Agile approach, the first release of the project was completed in about eight weeks. How does this relate to time?

Well, first off, the project success was measured only in terms of the eight weeks of labor, not the time value of the sunk costs over the past three years. Now of course, the reasoning behind not including sunk costs is exactly because they are non-recoverable. Unfortunately, that doesn’t give a very good picture of the investment made in the project. The fact that the costs are non-recoverable is not because of money, scope or quality (the other project variables) but because time is not negotiable: you can’t get it back, you can’t get more of it, you can’t store it up, and you can’t transfer it to other people. Sunk costs are really better thought of as sunk time.

A project is a temporary and one-time endeavour undertaken to create a unique product or service, which brings about beneficial change or added value. [Wikipedia]

This helps to explain why large projects have such low success rates. The larger a project, the larger the sunk time. It’s hard to re-start projects, and the larger they are the harder they are to re-start. And yet, the proper approach to sunk costs (time) is to ignore what has gone past and treat your work as if you were starting from scratch. A project approach specifically does not allow you to do this. Hence the fiction of “earned value” (which is a whole other topic).

Only an Agile or operational approach allows for low sunk costs. By doing work in extremely small pieces, each of which actually delivers value, an Agile approach is best suited for the reality that time is not negotiable. Agile methods acknowledge that the best way to avoid sunk time is to not do much work until you deliver results. As well, since we can’t go back to change our mistakes, Agile methods allow us to check our work frequently and learn as we go.

In what other ways is time a different sort of variable than scope or cost? In what other ways does an Agile approach take this into account?

One way to illustrate this difference is through the “iron triangle” depiction of project constraints.  This diagram shows the difference between the project management conception of these constraints vs. the Agile conception:

Project ‎Management vs. Agile Work Constraints

[This article was originally published on Agile Advice on 25-Jul-2007]

If you find this useful, please consider contributing with our
“Value for Value” model.