Preparing To Negotiate

Negotiation is part of our daily lives. Whether we are dealing with customers, co-workers, or our own families, it all comes down to ensuring that your needs are met in a manner that is fair to all involved.

Granted, there are those who would feel that the second half of that sentence is irrelevant. If your needs are met, you win whether it is fair or not. In my experience, this short-sighted view of the world also only works on the presumption that you never again have to deal with whomever was the subject of that negotiation; the world is full of other “targets” whom you can take advantage of next.

But this has never been true in our industry. We deal with a very small pool of decision-makers and chances are very good that you will deal with them many times over the course of a career.

More importantly, you will deal with them at different companies. So even though you maintain the relationship with the person, you may find them working under different constraints or assumptions when they change companies. Your needs and your frame of reference may have changed since the last time you worked on a project together as well. As such, every negotiation begins with elements of uncertainty no matter how long or how frequently you may have worked together, so you still have to prepare for it appropriately.

I am constantly amazed by how many developers — even vastly experienced ones — tend to fly by the seat of their pants instead of properly preparing to negotiate. They work from assumptions, take positions instead of defining needs, and some even believe that negotiation is synonymous with bartering or compromise. Hey folks, if you are going to run a business, either get up to speed on negotiating or hire someone to do it for you. And please don’t confuse legal counsel with professional negotiation. They are two complimentary but distinctly different skill sets.

Okay, soapbox preaching and shameless plugs for what FOG does ends there. Now let me share the framework we use to help prepare you for your upcoming negotiations.

You have heard me say that FOG’s mantra is FIT, which stands for Fairness, Integrity, and Trust. From that you might correctly surmise that I am big on acronyms — and our framework for negotiation preparation has one of its own. We don’t negotiate, we DIGOTIATE. You’ve got to DIG before you are prepared to negotiate … and DIGOTIATION stands for: Define, Inquire, Gather, Organize, Test, Inform, Align, Trust, Inspect, Observe, and then Negotiate. It sounds cumbersome, but once you have walked through the following framework a few times and enjoyed the positive outcome it brings to your subsequent negotiations and relationships, it will become second nature to you:

Define. Define your needs. What are the outcomes you positively must have in order to say “yes” to a deal. Sure, you have to have enough money to deliver the project, but what are the other tangibles and intangibles you must protect that, if you did not receive them, would be deal breakers for you? Don’t confuse “needs” with “positions.” Positions are stances that are taken that are not real needs; they are used to build room to haggle and protect the real needs. Whether you choose to fully communicate your needs from the outset is a choice of your negotiation strategy, but you can’t build that strategy without a clear definition of your real needs. That is why this must always be the first step in the process.
Inquire. This is the same as the “define” step, but directed at the other side of the negotiating table. What are the real needs of the publisher with respect to the project? Does it have to come in within a specific budget cap, be on store shelves in a particular window, or hit a particular review metric? Each one of these three needs alone can change how the rest of the negotiations is conducted. My favorites are the ones where all three of these concerns are in play. And remember, depending on the style and philosophy of the negotiator with whom you’re dealing, at this early stage of the process these may or may not be real needs. They could be positions instead.
Gather. Do you buy a car without researching it first online? Do you hire a contractor to do a major remodel in your house without checking their references? Software development contracts are major investments by both parties — publisher and developer. So gather as much information as you can about your potential partner before hopping into bed with them. Just because the publisher is the “money,” they are not the only one who should be doing due diligence. Talk to other developers with whom they are working and with whom they have worked. You should feel comfortable even asking the publisher for these references if you cannot find them otherwise. When you speak to these sources, learn as much as you can about potential problems in the milestone review and approval process, payment process, royalty reporting, and as many other potential sources of conflict between publishers and developers. Granted, every story has two sides and you don’t have to take all of these sources at face value. But it should inform you enough to be able to anticipate including some protectionist language in the final negotiation strategy on points of potential concern. Also, if the size of the contract is large enough, invest $2,500 in getting the most recent quarterly and lifetime-to-date sales figures from NPD http://www.npd.com. See how the publisher has done on similar titles so that you are prepared to validate their business model assumptions when it comes down to discussing royalties and recoupment.
Organize. Taking all of the aforementioned sources of data into account — your intelligence-gathering, your internal needs definition, and your preliminary discussions with the publisher — now is the time to organize and outline or checklist your crucial considerations with respect to any potential deal and your plan of how to achieve those objectives. This plan should allow for contingencies and also provide alternatives to which the other side must respond in order to advance past potential conflicts. For example, take the earlier scenario of a publisher who has put forward potentially mutually exclusive objectives, like “I want it cheap and I want it good.” This is the spot where you define options with respect to design scope and resource allocation that forces him to potentially resolve these conflicting objectives for you by making choices among the options that you present.
Test. Once you have the checklist and option or contingency plan, it is best if you role play it internally with other competent team members who were not directly involved in the creation of the plan. This gives the greatest level of objectivity and willingness to probe and find flaws or assumptions. Plus, they are hearing the plan for the first time just as the other side will be, so there is similar detachment. Once you have completed this phase and made any necessary adjustments to your checklist, it’s time to re-engage with the publisher.
Inform. This is the stage where you inform the publisher of your concerns about the project from an operational standpoint. For example, “this is an aggressive timeline and, if we are going to meet it together, we need to have flawless adherence to the milestone review and approval process and deadlines,” or “You want to achieve a Metacritic http://www.metacritic.com score of 80 or higher on this title, and we also think this is possible, but only if you agree to 12 levels instead of 15 to allow more time for play-balancing in the last third of the schedule.” While some would consider this negotiation, we do not. It is a collaborative process that must precede the business terms which will ultimately be defined. Until it is done, both sides can still inadvertently be proceeding with certain assumptions contaminating the mix. The worst thing that can happen is for these to survive to the actual course of development and then rear their ugly heads.
Align. This has to do with the alignment of expectations. Once you have expressed your concerns about the production details and they have expressed theirs, it is time to work together to resolve everyone’s expectations to everyone’s mutual satisfaction. Remember, folks … no hard-and-fast business terms are set yet; we are still deciding whether we are making an apple or an orange and, more importantly, whether it is even possible to make one together. You can’t possibly know how to staff or resource a project until you have had these conversations, and your biz dev folks can’t begin the negotiation without that knowledge. Further, you will learn a lot about what it will be to work with this potential publisher based on how collaborative or adversarial they are at this point in the process.
Trust. Another objective of the information and alignment stages is to build trust between you and the publisher. At the same time that you are evaluating what they are potentially like to work with, they are evaluating what you are like to work with, and the spirit of collaboration and problem-solving ability you bring to the process. The bottom line is that, if this phase is handled correctly, even if you can’t solve the details of this particular project to everyone’s satisfaction, they will be impressed with how you handle it and be more likely to bring you another project in the future without quite so many challenges involved. Further, when the production concerns can be resolved, the trust that you build during this phase of the process carries right over to set the stage for the respective business development professionals to deliver the best agreement to memorialize that trust.
Inspect. Okay, now the production group is ready to finalize the resource and staffing plan based on the mutually agreed scope and delivery timeline for the project. This gets turned over to the business development group for validation and inspection prior to being presented to the publisher. Now, it is not the role of biz dev to determine if the staffing plan is appropriate to the project; that is not what we mean by “validation.” It is however their role to ensure that all other factors — including overhead, outsourcing needs, engine licensing costs, downtime allocation, profit margin, and so forth — are incorporated in the final bid. The publisher also doesn’t want to fund a studio at a mutually agreed level and find out mid-way through development that the budget is short and the lights get turned out because no one planned for the light bill to be paid.
Observe. So now the bid is ready to go to the publisher. Most developers make another crucial mistake at this point, which is to just e-mail their proposal and sit waiting for a response, or maybe just follow up on it a week later. This robs you of the critical information you might need to save this job from going somewhere else, namely the real-time reaction to your proposal and the ability to interact with that reaction. Sure, if you have done everything right up to this point, the publisher should not be surprised by anything in your proposal. But isn’t it better to know if they are? Instead of just e-mailing the proposal, set a call with them to go over your proposal, and mail it to them shortly before the call. Naturally, if you can do a face-to-face meeting, that is even better. But it is not always possible or justified depending on how many people are competing for the project. In the meeting, walk them through how you came to the conclusions that you did, engage them for questions they might have, and even ask them if they think there is anything that you missed. If they have questions or concerns that you can address in real-time, do it. If you need to go back and rethink something, ask if you can get back to them in 24 hours with the revision and then keep that commitment. By taking this step in the process, you are decreasing the chance that your proposal will get killed in committee and you will just hear about it after the fact. Remember, when people have multiple choices, they look for the reasons to say “no” first to make the overall choice easier to make. Observe, respond, and don’t give them easy “no’s” with which to work.
Negotiate. Now, after all of that, you are actually prepared to finalize your strategy and negotiate the deal. Granted, deals can drop out at any point in the process right up to the 11th hour and 59th minute — and sometimes for circumstances beyond anyone’s control. But if you prepare for every deal properly, you will find that you not only close a lot more of them, you close better deals with fewer problems down the road when production begins.