Posted by: jsonmez | October 26, 2010

Agile Contract Negotiation, Don’t be a Liar

I wrote a post talking about how you have to either choose to release based on features or time, but not both.

I got a comment on that post basically stating: “I like the idea, but how do I sell it to my clients?”

The commenter pointed out that there are two things he could say:

  • We agree on which features you get, but I can’t say when you will get them.
  • You will have some features on a date, but I can’t tell you which or how many.

I thought this was a very excellent point, because neither of those sounds very good to your client.  I addressed it a bit in my post, but I thought this question really deserved a longer and better answer.

Many people have asked me about Agile contract negotiation.  I don’t think there is a really great answer out there.

Honestly, the best answer you can possibly give basically equates to “trust me.”

I’m going to show you how to say “trust me” in a little more diplomatic word choice while at the same time showing you how to demonstrate why you are trustworthy and why other vendors you are competing with may not be.


Why you are trustworthy

It is a lot to ask a client to just trust you.

Unless of course you have some good reasons to be trusted.

One huge issue in trust is transparency.  The more transparent a person or process is, the more likely someone is to trust that person or process.

A good example of this might be your 401k.

Most people trust the 401k plan at their work.  (In fact too many people blindly trust it.)  Now, imagine that you had a 401k plan at your work and you got no description or choice of what funds to invest into.  You just take part of your salary each month and put it in the “plan”, and when it is time to retire, you will be set.  You don’t get to see statements each month or anything.  You just have to trust that your money is being taken care of.

What I did there is remove the transparency and the choice or control.

If you want to add trust, you add transparency and control.

Compare this to most software development contracts.  In general you hire a company to build some software, and they promise to have it done by a certain date for a certain amount of money, but you don’t see anything until it is supposed to be done, and you don’t see how they are building it.

If you are following an Agile methodology like Scrum, Kanban or XP, you are offering a much more trustworthy position than traditional waterfall development.

Use this as your selling point.  Don’t try to hide it in a box.  The reason you are trustworthy is because you are going to let your client see exactly what you are accomplishing each week and let them set the future direction.  They are able to know exactly what they are getting in relation to what they are paying for.

You should be constantly showing a working product at the end of each cycle and letting the customer prioritize what you work on next.  You don’t have to draw up a contract that says a date and a number of features.  Instead, let the client figure out that data themselves from the progress you are making.

The great advantage of this approach is that your client is constantly getting up-to-date information to base projections of time and budget on.  Using the data you are giving them, they can accurately predict how long it will take before you are done with what they need.

They also have the option of doing things like:

  • Scale down the features in order to make a time window.
  • Release or go live early, because they know they can.
  • Increase the length of the project to get a few more key features done which will add significant value that is worth being a little later.
  • Change the set of features to optimize for ones that are less risky or can be done more quickly.
  • Realize which features are absolutely needed and save money by only building those.

I believe 100% that if you can clearly communicate this point there is no reason why any reasonable client wouldn’t trust you.

Most of your clients are used to having smoke blown up at them.  They understand that vendors and consultants lie.  They understand to some degree that software development is unpredictable.  You won’t have to convince them of those points.

You will only have to convince them that you won’t lie, and you will be transparent.

Why people promising dates and features are liars

You can read my post about features or time as a refresher, but it is pretty basic common sense that you can’t promise both without being either a liar or a cheat.

Strong words, but it is absolutely true.  You are either telling your client that you can make a date with a certain number of features without having any facts to back up that claim (lying), or you are padding enough to make sure that you can deliver even though you know a true estimate would be much less (cheating).

The truth of the matter is that no one can accurately predict the intersection of features and time for any significant product.

You can have the best intentions and you can try as best as you can to be as accurate as possible, but in most cases you are going to be lying if you try to claim it is anything but a wild guess.

I am not going to go into the details of why this is the case in this post, since I already covered it earlier.

If you want to destroy your competition, just ask your client to compare what information you are going to provide them against what your competition is providing.

Ask them about what kind of assurance they have that vendor x will actually deliver the 20 features that aren’t even clearly defined yet in 6 months.

You can be assured that they do not have good answers for these questions, because there is no method of accurately predicting the time it takes to build software.  Unless your competition is clairvoyant, you can indicate that if they are predicting a set of features in a particular time frame that they are not being honest.

On the other hand, you can come from a position of complete honesty and transparency.

How to say it

Obviously you don’t want to do something like this:

You: “Okay, here is the deal.  My company is super Agile.  What does that mean?  It means that you can trust me and my competition is basically all a bunch of dirty scum bag liars.”

Client: “Umm, ok.  So how do we write up a contract?”

You: “Don’t worry about that.  Just trust me.  I am Agile.  You can track my velocity n00b!”

You don’t want to bash the competition.  That is never good, but you do want to highlight the difference between your company and the competition.

You want to hammer in the points that you are transparent that you give them control.  You want to talk about how anyone who tries to promise a date for a set of features that aren’t really even defined yet, may have good intentions, but has no possible way of accurately making that prediction.

Ultimately, your competition is going to be pitching a fixed price contract with a fixed duration, and you are going to be pitching a time and materials contract.

Here is the problem.  Most clients are going to prefer that fake security of the fixed price and time contracts.  Sure it is a false security, but you need an additional selling point to be able to make your choice more appealing.

Offer the early out.

What is the worst part about signing a 1 year contract for x dollars?  You are committed.  If something goes bad or wrong, you still have to pay up.  Your client is aware of this, and it is a scary part of inking the deal.

You have a better offer.  You can win by saying that when you are building the software, you will be delivering a working product at the end of each cycle.  In addition, they can abort or change directions any time.  Your progress is visible at regular intervals, and your client has the option to have you stop building the product if they feel that you are not making the progress they need.

You have the competitive advantage of your client being able to choose to work with you can not have to commit to a large time frame or budget.  They have the ability to evaluate the progress at each step along the way.

Worst case scenario for them is that you partially build a product for a month and if it isn’t working out, they ask you to quit and they choose someone else.

Worst case scenario for someone pitching a fixed cost and fixed time contract is that your client looses x amount of dollars and time and doesn’t know about it till the deadline comes and goes.

So, yes it is harder to pitch a time and materials contract, but mainly because of two reasons:

  1. You don’t know how.  You don’t have the experience doing it, because you have been doing fixed price contracts for so long.
  2. Your client isn’t used to it.

If you are willing to devote the time and energy into educating your client, you will find that you can be successful and you don’t have to be a liar to do it.

As always, you can subscribe to this RSS feed to follow my posts on Making the Complex Simple.  Feel free to check out where I post about the topic of writing elegant code about once a week.  Also, you can follow me on twitter here.


  1. Wow, John, you are so agile you can’t even see what it’s done to you.

    Do you honestly think T&M projects are the only way to be transparent?

    On fixed price projects, we send a status email every week detailing which features are done and which aren’t. We try to release early and often versions with whatever functionality we’ve already got. There sometimes is an early out. If a client changes his mind, even if there’s no such clause in the contract, we can usually accommodate him (adjusting the fixed price, of course). The client always knows how far ahead we are and what the current risks are to our timely completion.

    Yes, we are agile. But most of our projects are not T&M – because most clients prefer fixed price. When you offer a guaranteed fixed price combined with the flexibility of the agile approach, that’s when the client is happy.

    We are not liars, or cheaters. When asked for a time estimate we might say that it would probably take three months, but we can’t guarantee that. If you want a fixed time contract we’ll write down four months, and try to do it faster than that. That is honesty. Everybody knows it’s hard to estimate – why do we need to hide that fact? Just because it’s a fixed price project doesn’t mean it has to be a black box.

    • As usual, I agree with most of what you say.

      And yes, it is certainly possible to do a fixed price contract and not be a liar or a cheat. But, in most cases you are going to come down to the bargaining table with a weaker position than another company offering a fixed price contract that isn’t being honest.

      My main point is this. Fixed price contracts don’t work as well with agile practices. With waterfall, it makes more sense. (But still has some of the same problems.)

      I use strong words to get a point across, not to insult people. For this industry to develop companies have to get used to going time and materials on both sides.

      Fixed price contracts truly don’t make sense with agile development. Even though your company is successful at doing them. I would still ask the question, would you be more successful doing T&M contracts?

      Good point though, I agree with much of what you said, and I am glad you brought up the other side of the argument.

      • I think the success of a project is not really related to whether it is T&M or fixed price. These are just two pricing options. If it were my call, I’d just offer both to the client and let him choose whatever he prefers. Thus, we’re not making the T&M or fixed price decision part of the decision whether to go with us.

  2. John,

    This is your field of expertise way more than mine. So please can you answer me this:

    “Hi John, this is your client – the one you are building the £3 million web application for. We need a quote for this new feature. How much will it cost?”

    So, if you don’t know how long it will take – and estimating makes you a “liar”, how can you give them a quote?

    A good answer here and I promise to subscribe to your blog.


    • Hi Nick,

      Sorry for the delay. Been quite busy lately.
      I do have a good answer for this situation.
      In this scenario, it sounds like you are already building this expensive web application. If you are collecting data about how many backlogs you are getting done in a certain amount of time, you should be able to give a very accurate quote. For example, let us say you are practicing Scrum. You can measure you velocity and you can have your team break the feature being requested down into story points. You can compare the amount of estimated story points to your velocity to determine about how long it will take and how many resources. You can break that into monetary figure based on your particular contract.

      Here is the real beauty of that approach. Lets say it is going to take 4 weeks for that feature. At the end of week 1, you can give a more accurate reestimate. In fact, if you allow your client to see your burn down charts and metrics, they can at their own leisure calculate the estimated time to completion at any time they choose, with a great deal of accuracy. The key difference here is that we are able to use past performance and real data as a metric. That is always going to be better than a guess without real data to back it up. Hope that helps. There are no easy slam dunk answers here, but I hope you can see how time and materials type contracts benefit both parties in this situation and how using metrics from the current project are better than guessing ahead based on some non-empirical data.

  3. Gracious blog post you have hereabouts. I hadn’t pondered such.

Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s


%d bloggers like this: