Not a Metaphor: Getting Out of The Deliverables Business

I’ve been thinking about contracts recently. That’s not surprising, given the amount of time I’ve been spending in contract negotiations with a very large new client. I’m excited to get started working with them, and I believe that they are genuinely excited to begin working with us. But we’re having trouble getting started, and it’s a familiar kind of trouble: although the principals in the deal all agree on the terms of the deal, the client’s procurement department has sent us a contract that makes no sense for the kind of work we want to do together.

* * *

When my colleague and co-author Jeff Gothelf started talking about Lean UX, his rallying cry for the idea was, “Getting Out of The Deliverables Business.” The key idea here is simple: designers in the old economy are in the business of making deliverables: they are hired to produce a thing–a Photoshop file, a wireframe drawing, a magazine layout, etc. But evidence keeps piling up that this approach doesn’t work. Modern software teams can have more success with an approach that is less about deliverables and more about doing whatever it takes: it’s about working with a team to do research, facilitation, collaborative design and development. (And yes, this approach still includes working in Photoshop and the traditional tools.)

So “Getting Out of The Deliverables Business” was mostly intended, I think, as a metaphor. Or perhaps as a way to prompt software teams to think about how they can be most effective in their work.

But there is one situation where “Getting Out of The Deliverables Business” is not a metaphor or a provocation but rather an imperative: it’s the contract.

***

My friends and future clients are excited to work in a new way: using an agile rhythm and lean methods to discover and validate the features of the system as we are building it. The problem is that the contract their procurement team wants to use would lock us into an old-style waterfall process—one in which we pretend to know what features we need to build ahead of time, and then grimly build those features (never learning or adjusting as we go) as we race towards our deadline.

To be fair to my future client, in my years of doing consulting based on Agile methods, I’ve never seen a contract from a large firm that didn’t make these same assumptions and force you into a waterfall method. The typical concepts you see built into these contracts include:

  • Fixed-scope deliverable: Assuming that the features of the system are known in advance.
  • Fixed time deliverable: Assuming that we know how long it will take to build the scope in question, and specifying a delivery date for these features.
  • Acceptance: Assuming that at the end of the project, we’ll be able to tell that we’re done based on a set of “acceptance” criteria that were identified (and fully understood) at the beginning of the project.
  • Corrections: assuming that the we will provide free labor to “fix” software that doesn’t meet the acceptance criteria (which in term assumes known acceptance criteria.)
  • Payment upon acceptance: tying payment to acceptance, rather than to hours worked.

The core fallacy here is the assumption that anyone knows what the end point of the project should be. While that may have been true when companies were purchasing things like corporate identity systems or warehouses, for software this just isn’t true. In software, you discover complexity and efficacy as you work. Thus you must set up software projects as you would a sailing trip: with the ability to sense current conditions, and learn and adjust as you go.

So the contract is the place where we define what business we’re in. To keep ourselves out of the deliverables business, when we write contracts with our clients, we build up from a few key concepts:

  • We assume that none of us know exactly what we’re going to build when we get started.
  • We assume will use the work we do together on the project to discover the right thing to build together.
  • We will design, build, and validate software together with our clients, and do that continuously and iteratively throughout our projects.
  • We will evaluate our progress based on the outcomes that we’re achieving. Are we making software that’s effective? Is it serving the needs of the users and the business?
  • We ask to be paid for the time we spend, rather than features we build. We commit to demonstrating valuable progress in each iteration. In return, we allow our clients to walk away at any time if they feel they are not getting value.

The bottom line here is that we write time-and-materials based contracts, rather than fixed-scope or fixed-time contracts. I don’t know any other way to do agile consulting. Have you found other ways? How do you stay out of the deliverables business?

6 comments Write a comment

  1. There is no other way. You have to walk away from clients that don’t get it — if you are committed to meaningful lean-agile delivery. It doesn’t mean the old way is wrong for all client services — plenty of money has been made doing it the old way. But usually the money comes from being an expert at fooling with contracts as opposed to delivering the optimum value.

  2. I’m 100% with you on this matter.

    As a developer, If you go down the waterfall path, your relationship with the project itself becomes a conflictive one.
    – You become scope police.
    – The full product potential is never reached – due to scope limitations.
    – Product and Development quality are sub-par.
    – The customer won’t be happy, and the relationship will ultimately fail.

    Also, Josh – what do you think about test coverage percentages? For example, we’re doing some work with a large company, they don’t understand the value of the coverage %. They don’t understand that we need to create tests for 80% of the code for example, which in turn is more time.

    How successful have you been at explaining this to a prospect?

  3. While I agree wholeheartedly with the sentiment – and maybe the ultimate approach – this struck me oddly upon first read.

    In the first half of your post, you emphasize that the value is in results, not the process, which I of course agree with. The second half argues that clients should pay for time worked. From the client’s perspective, how is this different than paying for deliverables? If you are focused on results (for example, the proof to a hypothesis) – then shouldn’t you be paid for getting a proof to said hypothesis?

    I point this out while acknowledging that the time required for the proof is unclear – but this is the problem with any fixed price engagement. Perhaps T&M is the only answer here; it just struck me as a possible inconsistency in the logic.

  4. Isn’t this a familiar struggle for any service-based business? Having been on both sides of the client-vendor fence, I’d argue it’s on us service providers to set clear expectations when scoping a project.

    I think clients deserve a measurable outcome in exchange for fair pay. That doesn’t mean defining every outcome as a deliverable, but it does mean framing outcomes clearly. I’m not an agile developer, so I may well be missing something critical, but when we (myself and a client) aren’t sure what the final project shape will take, my deliverables tend to be simple process docs. Maybe that’s a collection of user stories, or a content matrix, or simply a recommendations doc. I find most clients are fine with that degree of ambiguity.

    Too simplistic? Am I missing something?

  5. Josh,

    Thanks for the article! I am a systems designer still in school and have an assignment focusing on this exact subject. Unfortunately the text covers agile methods in about two pages! Textbooks are good at mapping things out in “Best Case” scenarios leaving us with unrealistic ideas as we merge with real world problems. You and other seasoned designers, that are willing to share, help get me a little more shipshape before I hit the sea.

    -Mike

Leave a Reply

Required fields are marked *.