It also assumes that you, or your team are the only arbiters of the finality of the final “deliverable” and not collaborating on a broader team, such as corporate IT, Marketing, or even external partners such as Brand Consultants, or software service agents for enterprise software.

This is moving WAY beyond what Cristina is talking about here so I won’t go further, but there are a ton of assumptions in your theory of what is a “final deliverable” let alone the value of intermediate deliverables as gatekeepers as part of the overall pricing structure.

The risks of any fixed bid will always fall squarely on the consultant/agent and as a project grows in size the level of all uncertainty grows not geometrically but exponentially.

– dave

Once again the definition of “deliverable” I’m using, or at least one facet thereof, is an artifact that acts as the content of one side of a commercial transaction (the other typically being money). So, once again, if your obligation in a contract is to deliver a website, the website is a deliverable (among many).

As such I am implying no more in my use of the term “deliverable” than “that which is (to be) delivered”. Am I using the word wrong?

Let me try to unpack this a bit. My overarching purpose is to look at alternative ways to strike deals around the acquisition of information artifacts, defined as anything that would be wrong if it said or did the wrong thing. These artifacts tend to be conceived and rendered as digital data, and as such the cost structure and risks around acquiring them are not governed by the costs of raw materials or rote labour, but rather that of gathering, concentrating, synthesizing and representing precursor information. The reason why I am interested in looking at alternative modes of exchange and financing of such artifacts is because I observe that these costs are inherently unknowable.

While the cost of gathering, concentrating, synthesizing and representing a specific piece of information is unknowable, the costs of these operations in general is not. In fact, it has never been cheaper. This realization is what led me to consider alternate ways to do deals around these kinds of artifacts.

What if, then, instead of striking a deal to deliver a complex artifact like a website, framed as a discrete capital investment, the deal was to deliver continual installments of simple artifacts that combine together over time, framed as an operating expense? That way, both actors in the transaction could ensure that they are getting value on an incremental basis, without the need for the risk exposure associated with a monolithic capital investment.

At this point the problem becomes, how do we answer the client’s question of “what did I get for my money?” It occurs to me here that what is needed is some way of connecting the simple artifact, which may be many degrees removed from the client’s goals, to the bigger picture. That’s something I’ve been working on, which is what inspired me to write the original article.

Deliverables are communication tools. You are communicating something to the client. That may or may not be a problem you are solving.

The real question is who am I talking to and what do they need me to communicate to them. Followed closely by what idea do you want to change in their head. The answer to none of these questions is limited to solving a problem for a client.

If you only ever communicate problem solutions in your deliverables, then you’re refusing to answer the first two most important questions: who am I talking to and what do they need me to communicate.

Understood problems: unknown solution
Maybe that really means you don;t understand the problem and you need more understanding so you can class it against understood or unsolved problems.

And I think Dorian’s post conflated documentation with solving the problem. One has nothing to do with the other, in my opinion. I’ll re-read and post a comment there.