April 18, 2012

The problem with contracts: rigid agreements trying to predict a creative process

The title of this post has been lifted from an email conversation with Dirk Knemeyer, where I was sharing my frustrations with a recent challenge I faced during the course of my work. I want to explore this further in writing, particularly since tweeting about it for the past couple of days helped me feel better but there's never enough characters to wholly articulate the problem. I think its one that comes up for many in the creative fields, particularly those tending to push the envelope of the 'fuzzy front end'.
The issue clearly is related to working against a ToR that is fixed in terms of methodology and deliverables, which is easy to do upfront, whereas the real value is to deliver ultimate value (which cannot be foreseen upfront – otherwise why hire you!).Your proposal needs to refer to a methodology that mentions the empathy, fuzziness, ambiguity and chaos situation, and the resulting need for flexibility. There also needs to be an explicit reference to providing ‘answers’ rather than the following of a methodology which in itself is just doing something, whereas the point is finding (substantiated) answers.
This is a quote from another email conversation which I think better captures the situation than anything I could have written. The challenge ahead is now to work out the articulation and framing of either a new or hybrid methodology or a way to capture the contingencies in the original proposals themselves.

The question I'd tweeted was posed so:
Can you successfully solve the problem and yet fail contractually or meet the specs of the contract yet fail to solve the problem?
because the situation I'd faced was an interesting, if complicated one. My client had a problem in the field. They suspected it might be something to do with one area and proceeded to create terms of reference for a research project based on their hypothesis. My proposal was a response to that hypothesis and framing of the problem area but as it was a 'Bottom of the pyramid' or BoP focused project, I expanded the scope to include a broader, more exploratory study. Prior experience has shown me that since the BoP markets are still very 'new' and thus have never been studied as deeply as the mainstream consumer markets of the developed world, one was better off exploring a broader context in order to ensure the problem had been framed correctly in the original hypothesis than simply assuming it was so.

And I was right. The solution space turned out to be vastly more complicated than the original hypothesis or terms of reference for the project, requiring flexibility of vision in order to synthesize the whole in terms of insights that the client could act upon in order to improve their chances of success (i.e. "solve" their original problem).

This meant that while my final recommendations certainly fit within the original objectives, the path and process followed meandered, in some cases quite significantly, from that originally proposed in the contract.

Thus the conundrum of having "solved the client's problem" but falling short of meeting the metrics of success.

Thus, I'm now in the situation where I need to find new ways to frame my methodology and approach - my 'offering' if you will - in a manner that allows for flexibility and ambiguity while assuring confidence that the outcome will provide value.

I'll wrestle this out here on the blog since I find that much of it draws upon the original pondering I'd done when I first began looking at the ways the tools from the field of design integrated with the needs of business and strategy. Since then I have gain practical experience in the field and the time seems right to reflect upon those original and early thoughts and refine them, or rather, its time to iterate the prototype based on user feedback from the field ;p

3 comments:

  1. I think that failing the project metrics and still succeeding in solving the clients problem is more than possible, especially when acting under high uncertainty. This might sound a bit old, but maybe project teams should work more like start-ups: less deliverables, fuzzier problems and greater autonomy.

    Contracts are just replacement of trust: the lower the trust, more rigid the terms, and less passion for the work they allow. Having ownership of the cause and freedom of the means will lead to best outcome.

    Best
    @kobrako

    ReplyDelete
  2. I suspect the essence of the problem lies in a budget number. That is, the "contract" part is navigable but the need for a "bottom line" number really isn't. And inherent in this notion of the unknown, which I agree with, is that ultimately you can't put a "correct" figure on it up front.

    On internal teams I'm big on false deadlines: say it is due in 10 days, knowing it is actually 15, so you can give them a release on day 9 and benefit from both time pressure on one hand and perceived empathetic release on the other. Unfortunately this model doesn't work in the client world. If you took the approach of thinking you can do it for $20K so quote $30 to allow full fuzziness, the client will end up spending the $30K even despite your best efforts. We (humans, in general) tend to fill the entirety of whatever schedule or budget we are given, regardless of the efficiency or effectiveness.

    Don't know that I'm adding anything to the issue here, but in a capitalist workplace where companies judge their success on quarter-by-quarter metrics, we might be able to sell flexible process but it will be far more unusual to sell a volatile budget.

    ReplyDelete
  3. Kobra, Dirk,

    You both have excellent points - trust and bottomline. While I'm currently exploring a retainer as a possible solution to continue the work at the fuzzy front end, the fact remains that the company (by nature of its qualities) will tend to always want to know 'how long will this take' and 'how much will it cost us' in order to evaluate whether its worth the investment in time and money.

    How would an internal skunkworks handle the budgetary aspect of their work, Dirk?

    ReplyDelete

These comments are moderated for spam and offensive language