Unformatted text preview:

The WinWin approachWhy does WinWin work?Win–lose doesn’t workHow does the WinWin negotiation model work?Four generations of tool supportG1: Initial prototypeG2: Strong vision, not-so-strong architectureG3: Muscle-bound architectureG4: Group support system infrastructureEasyWinWinLessons learnedMethodology lessonsGroupware lessonsWinWin project lessonsAcknowledgmentsReferencesAbout the AuthorsReferencesDeveloping Groupware for Requirements Negotiation: Lessons Learned Barry Boehm, University of Southern California Paul Grünbacher, Johannes Kepler University Linz Robert O. Briggs, GroupSystems.com Defining requirements is a complex and difficult process, and defectsin the process often lead to costly project failures.1 There is no complete and well-definedset of requirements waiting to be discovered in system development. Different stakeholders—users, customers, managers, domain experts, and developers—come to theproject with diverse expectations and interests. Requirements emerge in a highly collaborative, interactive, and interdisciplinary negotiation process that involves heterogeneous stakeholders.At the University of Southern California’s Center for Software Engineering, we have developed a series of groupware implementations for the WinWin requirements negotiation approach (see the Acknowledgments at the end of the article for a list of organizations that helped sponsor this research). The WinWin approach involves having asystem’s success-critical stakeholders participate in a negotiation process so they can converge on a mutually satisfactory or win–win set of requirements. Groupware-supported methodologies are among the hardest to get right, and the rapidly moving technology of distributed interactive systems is a major challenge. This is due largely to the relative newness of the area and to the unfamiliarity of most software developers withthe phenomena of group dynamics. However, an even bigger challenge is creating a system that works well with people of different backgrounds, in different places, and often at different times. In particular, collaborative technology that supports requirementsnegotiation must address stakeholder heterogeneity.Our WinWin groupware system—which has evolved over four generations—enables and facilitates heterogeneous stakeholder participation and collaboration. Each generation reflects an increase in our understanding of what is needed for successful WinWin groupware operations and technology support. Here, we present the major lessons we learned during WinWin’s development.The WinWin approachThe original motivation for a WinWin groupware system was Barry Boehm’s frustration in using a manual win–win approach to manage large projects at DARPA. For example, win–win management of the $100-million DARPA STARS program was done primarily through monthly meetings of many STARS stakeholders: three prime contractors and their three commercial counterparts; three user representatives from the Army, Navy, and Air Force; DARPA customers and contract managers; and several research and support contractors. Each meeting concluded with a win–win agreement, so after a meeting, participants felt they had taken three steps forward. However, by the nextmeeting, the distributed stakeholders had independently “reinterpreted” the agreements,causing the process to move two steps back. As a result, it took six months to achieve a shared vision that the prime contractors’ success plans documented. Our analysis at the time indicated that a WinWin groupware support system could reduce this process to one or two months.The general win–win approach evolved more or less independently as an interper-sonal-relations,2 success-management,3 and project-management4 approach. We usually define it as “a set of principles, practices, and tools, which enable a set of interdependent stakeholders to work out a mutually satisfactory (win–win) set of shared commitments.”Interdependent stakeholders can be people or organizations. Their shared commitments can relate to information system requirements in particular (the WinWin groupware system’s primary focus) or can cover most continuing relationships in work and life (for example, international diplomacy). Mutually satisfactory generally means that people do not get everything they want but can be reasonably assured of getting whatever it was to which they agreed. Shared commitments are not just good intentions but carefully defined conditions. If someone has a conditional commitment, he or she must make it explicit to ensure all stakeholders understand the condition as part of the agreement.Why does WinWin work?WinWin works because people and groups have different preference patterns. A classic example was the 1978 Egyptian-Israeli peace treaty’s negotiation of the Sinai Peninsula borderline. It was at an impasse until it was clarified that Egypt preferred territory and Israel preferred getting a demilitarized zone. We elaborate on other reasons why WinWin works in the following.Win–lose doesn’t workIn requirements negotiation, nobody wants a lose–lose outcome. Win–lose might sound attractive to the party most likely to win, but it usually turns into a lose–lose situation. Table 1 shows three classic win–lose patterns among the three primary system stakeholders—developers, customers, and users—in which the loser’s outcome usually turns the two “winners” into losers.5Table 1Frequent Software Development Win–Lose Patterns (That Usually Turninto Lose–Lose Situtations)Proposed solution “Winner” LoserQuickly build a cheap, sloppy product Developer and customer UserAdd lots of “bells and whistles” Developer and user CustomerDrive too hard a bargain Customer and user DeveloperAs the table shows, building a quick and sloppy product might be a low-cost, near-term win for the software developer and customer, but the user (and maintainer) willlose in the long run. In addition, adding lots of marginally useful bells and whistles to a software product on a cost-plus contract might be a win for the developer and users, but itis a loss for the customer. Finally, “best and final offer” bidding wars that customers and users impose on competing developers generally lead to lowball winning bids, which place the selected developer in a losing position.However, nobody really wins in these situations. Quick and sloppy products destroy a developer’s reputation and have


View Full Document

USC CSCI 508 - usccse2001-508

Documents in this Course
Load more
Download usccse2001-508
Our administrator received your request to download this document. We will send you the file to your email shortly.
Loading Unlocking...
Login

Join to view usccse2001-508 and access 3M+ class-specific study document.

or
We will never post anything without your permission.
Don't have an account?
Sign Up

Join to view usccse2001-508 2 2 and access 3M+ class-specific study document.

or

By creating an account you agree to our Privacy Policy and Terms Of Use

Already a member?