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.\n\nI got a comment on that post basically stating: “I like the idea, but how do I sell it to my clients?”\n\nThe commenter pointed out that there are two things he could say:\n\n

\n
• We agree on which features you get, but I can’t say when you will get them.

\n

• You will have some features on a date, but I can’t tell you which or how many.

\n

\n\nI 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.\n\nMany people have asked me about Agile contract negotiation.  I don’t think there is a really great answer out there.\n\nHonestly, the best answer you can possibly give basically equates to “trust me.”\n\nI’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.\n\n\n\n

Why you are trustworthy

\n\nIt is a lot to ask a client to just trust you.\n\nUnless of course you have some good reasons to be trusted.\n\nOne 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.\n\nA good example of this might be your 401k.\n\nMost 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.\n\nWhat I did there is remove the transparency and the choice or control.\n\nIf you want to add trust, you add transparency and control.\n\nCompare 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.\n\nIf you are following an Agile methodology like Scrum, Kanban or XP, you are offering a much more trustworthy position than traditional waterfall development.\n\nUse 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.\n\nYou 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.\n\nThe 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.\n\nThey also have the option of doing things like:\n\n

\n
• Scale down the features in order to make a time window.

\n

• Release or go live early, because they know they can.

\n

• 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.

\n

• Change the set of features to optimize for ones that are less risky or can be done more quickly.

\n

• Realize which features are absolutely needed and save money by only building those.

\n

\n\nI believe 100% that if you can clearly communicate this point there is no reason why any reasonable client wouldn’t trust you.\n\nMost 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.\n\nYou will only have to convince them that you won’t lie, and you will be transparent.\n\n

Why people promising dates and features are liars

\n\nYou 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.\n\nStrong 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).\n\nThe truth of the matter is that no one can accurately predict the intersection of features and time for any significant product.\n\nYou 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.\n\nI am not going to go into the details of why this is the case in this post, since I already covered it earlier.\n\nIf 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.\n\nAsk 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.\n\nYou 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.\n\nOn the other hand, you can come from a position of complete honesty and transparency.\n\n

How to say it

\n\nObviously you don’t want to do something like this:\n\nYou: “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.”\n\nClient: “Umm, ok.  So how do we write up a contract?”\n\nYou: “Don’t worry about that.  Just trust me.  I am Agile.  You can track my velocity n00b!”\n\nYou 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.\n\nYou 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.\n\nUltimately, 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.\n\nHere 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.\n\nOffer the early out.\n\nWhat 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.\n\nYou 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.\n\nYou 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.\n\nWorst 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.\n\nWorst 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.\n\nSo, yes it is harder to pitch a time and materials contract, but mainly because of two reasons:\n\n

\n
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.

\n

2. Your client isn’t used to it.

\n

\n\nIf 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.