By John Sonmez 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.

liar

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 and 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 without having to commit to a large timeframe 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 until 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.

About the author

John Sonmez

John Sonmez is the founder of Simple Programmer and a life coach for software developers. He is the best selling author of the book "Soft Skills: The Software Developer's Life Manual."