This paper has been excepted from an article that was printed in the January, 1998 edition of IEEE Software.
Rob Thomsett, a well-known and widely respected consultant in the software project management area, talks about "first, second and third wave" project management. In the first wave (1960s and 1970s) software people had all the power and were the ones who dictated delivery dates and costs to end users and customers. During the second wave (1980s), there was (at least in principle) a more balanced power relationship, business people worked with software people to derive requirements and mutually set deadlines and costs. Now were in the third wave, and the balance of power has shifted to end-users and customers. This means that theynot software developersdictate the rules of the game. It also means that the rookie project manager had better learn to negotiate, with his customers, with the technologists on his team, and with the business executives who oversee his work.
There are, of course, many different ways to negotiate, but all can be summarized in five steps that every rookie project manager must learn:
1. A dialogue between two parties must be established. Since the software project manager is no longer in a position of power (as she was during the first wave), it is critical that she apply the communication skills that we discussed earlier. She must probe, offer ideas and suggestions, build on the clients ideas and suggestions and constructively criticize requirements that will lead to trouble. Since the power is on the other side of the table (whether software people like it or not), the project manager must work to make the customer understand that successful software will magnify the customers power, and that the only way success can be obtained is through a close working relationship.
2. A negotiating strategy must be plotted. A rookie project manager probably believes that quick thinking during discussions with end-users and customers is the key to successful negotiation. In reality, the most important thing for a rookie to do is to plan a negotiation strategy in advance, before any attempt is made to overcome obstacles and come to terms. In essence, the following questions must be answered: What will be negotiated Who are the players When and where will the meeting take place Once answers to these questions are obtained, the software project manager can better analyze his position, better organize the information hell need to conduct a successful negotiation, and better assess alternative solutions and positions that may come up during discussions. The vast majority of rookie managers walk into a customer meeting ill-prepared. They often get steamrollered as a result.
3. Obstacles to success must first be identified and then overcome. A rookie project manager and an end-user are discussing requirements and delivery dates for a major enhancement to a legacy system. They reach an impasse (e.g., an impossible deadline or a set of requirements that cannot be implemented within existing budgetary constraints) that seems impossible to break. What should the rookie manager do One approach is to state a firm desire to continue discussions and then initiate a change of pace. Something like, "I think weve made some good progress [Mr. Customer] and I want to continue so that we can finalize things and begin this project. Why dont we take a break and then get back together, at, let say 3:00 " Of course things may not be that simple. The customer may be confrontational or even irrational. There are ways to handle these behaviors as well, but only if youve had some training in negotiation.
4. The parties must come to terms. The rookie manager must now carry out the actual negotiation. To do this he should open with a statement of purpose (why the parties have gotten together) and a review of the information (already known to both parties) that is the substance of the negotiation. The rookie manager must recognize that both parties have needs and these can be fulfilled in a number of different way. Together he must work with the client to arrive at the best alternative. Finally, the software project manager must "close." That is, he must summarize the agreement and identify the responsibilities of both parties and the steps that follow.
5. The parties must make it happen. Using the organization and facilitation skills noted below, the software project manager begins the technical aspects of the project, but never forgets that communication and negotiation are ongoing activities
The vast majority of rookie software project managers have never had any formal training in negotiation. In fact, few have even read a book on the subject. They do not know the steps discussed above and do not apply them when they meet with end-users and customers. The result: misunderstandings, insane deadlines, unclear requirements, and a feeling of tension and frustration that leads to management phobia.
The following Negotiating Resources will provide you with additional information on this important topic.
Eight rules of negotiating
This short paper on negotiating, although written for home buyers, is quite appropriate for software engineers.
HOW TO IMPROVE YOUR NEGOTIATING SKILLS
A short article with some useful pointers.
Make a positive difference
An article that advocates keeping the client's point of view in mind as you negotiate
Negotiating techniques checklist
General principles that are applicable to any situation
The Negotiation Institute
A useful array of courses and free articles on negotiation
The Negotiation Skills Company
Presents a useful collection of articles on negotiation and related subjects
Amazon lists over 700 books on negotiating.