the concept of decision finality

This has been weighing on my mind quite savagely since I wrote it last week, because I think (by the way, thanks for excellent comments) it might be the key to unlocking the things I’m thinking about:

The builders and blockers are a slightly different issue, because they’re intrinsically political rather than technical. They either need to be treated as problems to be solved with the same approach as other bottlenecks, or taken seriously as political stakeholders. And asking that question is the same thing as asking “has the decision to build this thing actually been taken yet?” In my view, a lot of the problems on the Abundance Agenda might have a negative answer to this as their root.

So, let’s call this the question of “the point of decision finality” – the moment when the answer to this question changes from no to yes. The thing that’s troubling me is – does this entity, the point of decision finality, does it exist? Is there any such thing? If there is, then it’s clearly an important question of institutional design to say where in the workflow the point should be placed.

But so far I’ve just raised philosophical question after philosophical conundrum for myself – so I hope the philosophers among my readers might be able to help. Clearly, there is a sense in which there is no finality to a decision to build something until the ribbon is cut and the doors opened; projects can be abandoned and often are. Does this mean that there is no such thing as a final decision?

I think the concept can be rescued. Let’s say that the “point of decision finality” is the moment before which not building the thing is correctly described as “we decided not to”, and after which not building the thing is correctly described as “we failed to build the thing”. Now the question is – will this definition support my intuition that the location in the workflow of the point of decision finality is both important and something which is itself part of the design of the system?

My answer would be “not without a bit more substance to it”. Simply changing what you call a project from “failed” to “decided not to” isn’t something that makes a difference in the real world, and it doesn’t meet the challenge. So, what does make that difference; what changes in the world and the organisation when a decision crosses the point of finality.

The answer has to be one of information architecture, because all organisational questions are. After the point of decision finality, there is a qualitative change in the kind of information which the system is allowed to pay attention to. Before some project P reaches decision finality, for example, people are allowed to suggest plans under which the organisation tries to achieve its higher level goals through a set of projects which doesn’t include P. After that point, P has been decided on; the set of alternative plans to be considered is shrunk.

That means that the analytical problem with respect to P is “how can this be achieved?” rather than “should we do this?”. There’s another conundrum here for me, though, because I am not sure that these two questions are sufficiently different – as long as the first question could potentially be answered “it can’t” (or “it can’t, except at excessive cost”), then the second is open. As I said earlier, nothing’s really “decided” until it’s finished.

Which means that there is a constraint on the placing of the point of decision finality. In order for the decision to acceptably approach the ideal of finality, we have to say that to declare a decision final is to assert that you are confident that it can be achieved within the resources allocated to it.

So there’s a limit on how early in the workflow the point of finality can be. I am going to assert that subject to this constraint, the point of decision should come as early in the workflow as possible; keeping decisions open when they ought to be closed seems to create a lot of opportunities for people to engage in strategic behaviour. (It also seems to give advisory bodies like the Planning Inspectorate delusions of being judges; when people feel like a decision is still open, they also seem to believe it’s incumbent on them to maintain the appearance of an open mind).

And that suggests another point of decision architecture. You can’t achieve decision finality until you are reasonably certain that a project can be achieved in an acceptable budget envelope (with “budget envelope” to be taken here as meaning the budget in terms of environmental cost and political goodwill as well as the financial). But of course, you can’t be anywhere near certain of that until you know what the budget actually is. So this suggests two stages of analysis; an initial broad-brush exercise establishing the order of magnitude of the benefits and costs and bringing the tradeoffs into the open, then the decision point, then a detailed planning exercise to see how much surplus can be created, in terms of doing better than the tradeoff which was accepted. Of course, if the second number is negative, then that’s a failure, but I think the idea of “the project has failed” now has more definite organisational and economic meaning.

Sorry, that was a bit dense wasn’t it, readers? I’ll try to come up with a joke by Friday.