MBA 734, Negotiations and Alternative Dispute Resolution

Coming out of the grocery business, my understanding of price has long been rather simple. I thought there were only two components to price. There was the actual production cost of the item: how much money was laid out to grow, process, package, and ship the food. Then there was a margin for the grocer to provide the item to the customer, usually less than five percent, (grocery stores have long been tight margin operations) and not much else. With such a low margin, there wasn’t really much room for negotiating, I always thought. I was wrong. There is always room for negotiating.
In my MBA class on negotiating, we talk about how price carries so much more information; much more than I thought it did. It tells you who the target customer is. For example, price tells you where the item is in its product life cycle. Price will even tell you where the technology is in its adoption phase. Contrary to my understanding, price tells you almost nothing about actual production, delivery, or labor costs. Coming out of the grocery business, I was woefully unprepared to do any negotiating of any kind, which I inevitably had to do in my career as a project manager.
I remember negotiating the production contract for my first project coded at our contractor at the digital mapping company I used to work for. The negotiations were for a suite of point address cleanup projects. The negotiation took place early in the second quarter of 2009 for cleanup slated to begin with the third quarter. The map engineering division had already batch loaded all the address points they could find, and the fallout – those points that didn’t match anything in the map – was enormous.
I would be negotiating with a manager similarly assigned to Point Addressing in India. He was one of the many OPC Team Leads, or TLs, as we knew them. A couple of weeks prior to the negotiation, we’d sent over a few work areas so they could execute an Alpha project to determine the production metric, the results of which would be revealed by the TL in India at the meeting. We would be negotiating over the metric. Even though I knew next to nothing about negotiating, I did know quite a bit about the project.
I knew about the size of the project going into the negotiation. TechOps had batch loaded into the Core Map almost three and a half million points for the first country earlier the previous month. With a fallout rate of 21%, we had a little over 600,000 points to clean. The points were distributed unevenly across the entire country. We would group the points geographically into work areas sized such that they could be cleaned in roughly a day’s worth of work. But I knew more than just how much work would be required.
I also knew a great deal about our likely performance on the project from the team of three Fargo operators who had tested the cleanup process. From feasibility testing a few work areas in Fargo, they showed we could clean at a rate of 70, 90, and 120 points per hour, respectively. (The fastest coder had run into an area of large apartment complexes which required one type of fix, road name changes, which would clear hundreds of points at a time.) So, at an average metric of 90 points an hour, we knew we’d need just under 7,000 hours to complete the project. Of course, all of these details were subject to negotiation with the TL in India, and he was working with his own numbers.
For both parties, cost was discussed in terms of hours: map production hours, not to be confused with money. The hourly rate for the OPC had been negotiated at a level far above mine and long before the start of the fiscal quarter when a block of production capacity had been acquired for a predetermined rate. I wasn’t supposed to know or even care about the money, just the hours. I did know, however, that the aggregate hourly rate for the OPC was about $5.00/hr. For comparison, Fargo’s aggregate rate was $25.00/hr. I found that somehow to be a demoralizing differential. I still do.
My primary constraint was not really the specific number of hours I was negotiating for, but that I had to be right about whatever number to which we agreed. I actually had broad latitude with respect to how many hours I could request, presumably because the contractors were so inexpensive. However, I had to be right because it was always very difficult to change the allocation of hours for the project once the coding window opened and work began. Late in the coding window, when errors in estimating tended to become evident, a change order was even more problematic. I had to request enough hours up front so that, despite any late-quarter issues, I had enough contractor resources – but not too many – to complete the project on time.
Speed was understood of in terms of the production metric; how quickly could the process be executed. The metric was the average coding speed of the entire production team working on a given project. For point addressing, the metric was expressed in points per hour, but the metric we discussed was oddly detached from how fast the OPC could actually do the work. Despite the fact that we were supplying the production process, OPC developers typically re-engineered entire projects, often enabling the production team to work much faster than anything we could achieve in Fargo. Rumor was their process was as much as 25% faster than ours.
For example, according to my sources, the OPC team was doing the work with an off-the-shelf map building software package, rather than our proprietary map building interface. They would enter all of the new geometry, name additions, and address range changes into what was called a mid-cover. Their own map engineers would then load the mid-cover into our Core Map at the end of each shift, fixing things en masse. Unfortunately, the TL was under no obligation to tell me precisely how he executed the project. With this reengineered process, his actual metric, which I would never know, would likely put my team’s coders to shame. So, my negotiating power over metric was essentially nonexistent.
My strength was the outsourcing model itself. At a 5:1 cost differential, the company I worked for could afford to pay for a ridiculously low metric before they lost the economic advantage of hiring contractors in the first place. With that calculus in mind, I didn’t think any of my managers would mind if I agreed to something significantly less than what we could do in-house as long as it didn’t come too close to cutting into profits.
Another strength I had was that I knew a bit about the TL’s negotiating style. I’d actually listened in as one or two of my colleagues negotiated with him three, six, and nine months back on other projects. In every negotiation, he opened with a ridiculously low metric. Every time my colleagues pressured him to come up to a much higher metric, one closer to the metrics Fargo subject matter experts could achieve. The TL always gave a lot of ground but never could be talked into parity with Fargo. He always stuck at about 25% below Fargo metrics. Although he had demonstrated his willingness to come up quite a bit, that wasn’t the end of the story.
If he conceded too much on the metric during the negotiations before the project began, he invariably came back to the Fargo managers in the back third of the quarter asking for more hours. He always had a tale of woe. One time, the team was supposed to have encountered a very difficult run of work areas and they were no longer meeting the agreed upon metric. Another time, he reported latency in the network connecting his team to the Core Map which again hurt the metric. The last time he pulled this, it was because his team of geocoders were very new at the kind of coding required for the project and were thus slower than expected. Anything to make up for the concessions given during negotiations.
The Fargo managers, my colleagues, didn’t have much choice but to agree to the new, lower metric to ensure delivery of the project on time, but they always got in trouble for the Change Order. The problem was that a change in the metric meant more hours and, by extension, more money. Additionally, by the back third of the coding window, the OPC was booked to capacity; more hours needed for one project meant less hours for another. Reprioritizing the work in progress needed to be done. If you wanted work to be completed on say, Point Addressing, when the OPC was asking for more hours, you needed to stop work on a lower priority project, like GeoRepo.
The task of re-prioritizing projects fell on the map managers. They faced the tough decisions on what improvements they absolutely needed, and what improvements they could do without. They hated that. Map improvements were a key selling point for customers like Garmin and Harmon Becker. If a particular project had been committed to a particular customer, there was no way it could be deprioritized without disappointing a customer. The manager had to comb through the suite of projects and find work that wasn’t related to a deliverable. It was painful work. Additionally, the RMC managers never understood or bought excuses for why we needed more hours. Why couldn’t we just make accurate projections, they asked.
In order to stay out of trouble with my line manager and the map managers, I had decided on a strategy quite different from anyone else in the Fargo office. Although I would lead with the highest metric our team could achieve in-house, I would always make significant concession. My strategy was to engage collaboratively. With any luck, we’d be working together for many years to come, so I worked toward establishing and maintaining a relationship that would last far longer than any given project.
I wouldn’t even pressure the TL to come up so much from his opening offer. I would state my position but explain that whatever metric we did agree upon would have to be something he could live with for the entire duration of the project regardless of increased density, latent networks, or poorly trained resources. I told him I didn’t want a change request late in the coding window. Ever. I essentially threw hours at the OPC up front rather than be put into a position of adding the hours on the back end and getting in trouble with my managers.
We both got what we wanted out of our negotiations. I conceded on cost and speed; my counterpart conceded on late-breaking change requests. The end result was that my projects rarely needed change orders, and I rarely got into trouble with my managers for being wrong on my work orders. It wasn’t until long after those negotiations that came to find out OPCs real interest.
What their price should have told me, had I known to look, was that they were actually double booking their resources. If they were 25% faster than us and contracted for rates 25% slower than us, they had a margin big enough to double book their people. They’d work on one project half the time and turn around and deliver another project with the other half of their time, all the while billing both clients for full time each. What I know now is that it was basic economic principles at work. All the time I was feeling sanguine about a five-to-one wage differential, they were working a two-for-one billing differential. Both the seller and the buyer were realizing their own goals and objectives with respect to price, each capitalizing on the fact of their own asymmetric information. That’s economics at work.