1
IEEE TRANSACTIONS ON ENGINEERING MANAGEMENT, VOL. 45, NO. 2, MAY 1998 199 Book Reviews Teams and Technology: Fulfilling the Promise of the New Organ- ization—D. Mankin, S. G. Cohen, and T. K. Bikson (Boston, MA: Harvard Business School Press, 1996). Reviewed by Ann Majchrzak. The premise of this book is that both teams and information technology (IT) are necessary if the possibilities of each are to be met. The book is written in clear, uncomplicated language. Managers responsible for the development of IT likely to be used by teams will find the book particularly useful. The book is organized into four parts. In the first part, the framework called Mutual Design and Implementation (MDI) is introduced. The MDI is not really a framework but rather a set of principles for promoting the simultaneous and interrelated design of information technology and the teams that will develop and use the technology. Part II is focused on designing what the authors call the MDI team. While much of what is presented is generic to effectively designing and managing any team, there are a few nuggets particular to IT development teams. One such nugget is that MDI teams should be held accountable not just for developing the information technology but also for developing user teams and an implementation plan. Another nugget is the identification of minimal qualities of user representatives (what the authors call “user delegates”). Although the authors skip over the problem of conflicting user requirements, the concern that user representatives become co-opted and lose touch with the use communities is given important treatment in this and the next part. Part II also discusses, at some length, the role of internal IT experts on such IT development projects. The authors strongly suggest, and reiterate this point in the last chapter, that IT professionals should shed their roles as leaders, designers, and programmers and instead adopt roles of IT coordination, integration, and technical support. The authors recommend that local experts (defined as those reporting to line managers who are knowledgeable of both the business and IT) are much better suited to develop IT than IT professionals. Unfortunately, data supporting this claim are not presented, but it appears that the claim is sufficiently plausible and currently popular for managers to take it seriously. Last, this part provides an excellent discussion of the role of the person leading the IT development effort. The authors describe the leader using Manuscript received October 8, 1996. The reviewer is with the Marshall School of Business, University of Southern California, Los Angeles, CA 90089 USA. Publisher Item Identifier S 0018-9391(98)03146-8. such words as “enabler,” “facilitator,” and “group therapist.” Project leaders do not solve problems for teams; they pose key questions and clarify differences. Note that this role is in sharp contrast to the “heavyweight program manager” role promoted by others. Out of the four chapters in this part, I found the one on leadership to be the most clear, directive, and specific. In the words of the authors, “Part III [which begins on p. 123] is the heart of the book; it is where the mutual design and implementation process is put into action.” As promised by the authors, this part is the most specific and directive, with excellent short examples integrated into the text. While this part contains many suggestions, a few are particularly worthy of mention. 1) Users should be involved not to get “buy-in” but rather to solicit users’ valuable knowledge and expertise. 2) The development project should not be cut off from the rest of the organization. 3) Systems should be designed to exploit users’ progressive learning curve rather than be idiot-proof. 4) Technology should pose no limits on with whom users work, on what they work, or what information they use. One of the chapters is devoted specifically to information technology. While this chapter contains a useful critique of the traditionally used waterfall software development method, the chapter is light on technical issues. For example, missing is any discussion of a typology of technologies commensurate with the typology of teams offered in an earlier chapter, types of technical issues likely to be traded off against each other, typical technical options often considered with different social options, and types of technical issues that particularly warrant prototyping. Nevertheless, admonishments to rapidly prototype and design for flexibility and integration are useful reminders. Last, in Part IV, the personnel policies of rewards and promotion that need to be changed with the implementation of teams are discussed. In sum, the book has several interesting and useful points that make it worthwhile and fast reading by practitioners. A particularly useful literary technique that I found enjoyable was the use at the beginning and end of each chapter of installments of an ongoing story of an IT development project. The story nicely encapsulates most of the major points of the book. 0018–9391/98$10.00 1998 IEEE

Teams and Technology: Fulfilling the Promise of the New Organization [Book Reviews]

  • Upload
    tk

  • View
    212

  • Download
    0

Embed Size (px)

Citation preview

Page 1: Teams and Technology: Fulfilling the Promise of the New Organization [Book Reviews]

IEEE TRANSACTIONS ON ENGINEERING MANAGEMENT, VOL. 45, NO. 2, MAY 1998 199

Book Reviews

Teams and Technology: Fulfilling the Promise of the New Organ-ization—D. Mankin, S. G. Cohen, and T. K. Bikson (Boston, MA:Harvard Business School Press, 1996).Reviewed by Ann Majchrzak.

The premise of this book is that both teams and informationtechnology (IT) are necessary if the possibilities of each are to bemet. The book is written in clear, uncomplicated language. Managersresponsible for the development of IT likely to be used by teams willfind the book particularly useful.

The book is organized into four parts. In the first part, theframework called Mutual Design and Implementation (MDI) isintroduced. The MDI is not really a framework but rather a set ofprinciples for promoting the simultaneous and interrelated design ofinformation technology and the teams that will develop and use thetechnology.

Part II is focused on designing what the authors call the MDI team.While much of what is presented is generic to effectively designingand managing any team, there are a few nuggets particular to ITdevelopment teams. One such nugget is that MDI teams should beheld accountable not just for developing the information technologybut also for developing user teams and an implementation plan.Another nugget is the identification of minimal qualities of userrepresentatives (what the authors call “user delegates”). Althoughthe authors skip over the problem of conflicting user requirements,the concern that user representatives become co-opted and lose touchwith the use communities is given important treatment in this andthe next part. Part II also discusses, at some length, the role ofinternal IT experts on such IT development projects. The authorsstrongly suggest, and reiterate this point in the last chapter, thatIT professionals should shed their roles as leaders, designers, andprogrammers and instead adopt roles of IT coordination, integration,and technical support. The authors recommend that local experts(defined as those reporting to line managers who are knowledgeableof both the business and IT) are much better suited to develop ITthan IT professionals. Unfortunately, data supporting this claim arenot presented, but it appears that the claim is sufficiently plausibleand currently popular for managers to take it seriously. Last, this partprovides an excellent discussion of the role of the person leadingthe IT development effort. The authors describe the leader using

Manuscript received October 8, 1996.The reviewer is with the Marshall School of Business, University of

Southern California, Los Angeles, CA 90089 USA.Publisher Item Identifier S 0018-9391(98)03146-8.

such words as “enabler,” “facilitator,” and “group therapist.” Projectleaders do not solve problems for teams; they pose key questionsand clarify differences. Note that this role is in sharp contrast to the“heavyweight program manager” role promoted by others. Out of thefour chapters in this part, I found the one on leadership to be themost clear, directive, and specific.

In the words of the authors, “Part III [which begins on p. 123] is theheart of the book; it is where the mutual design and implementationprocess is put into action.” As promised by the authors, this part is themost specific and directive, with excellent short examples integratedinto the text. While this part contains many suggestions, a few areparticularly worthy of mention.

1) Users should be involved not to get “buy-in” but rather to solicitusers’ valuable knowledge and expertise.

2) The development project should not be cut off from the restof the organization.

3) Systems should be designed to exploit users’ progressivelearning curve rather than be idiot-proof.

4) Technology should pose no limits on with whom users work,on what they work, or what information they use.

One of the chapters is devoted specifically to information technology.While this chapter contains a useful critique of the traditionallyused waterfall software development method, the chapter is lighton technical issues. For example, missing is any discussion of atypology of technologies commensurate with the typology of teamsoffered in an earlier chapter, types of technical issues likely tobe traded off against each other, typical technical options oftenconsidered with different social options, and types of technical issuesthat particularly warrant prototyping. Nevertheless, admonishments torapidly prototype and design for flexibility and integration are usefulreminders.

Last, in Part IV, the personnel policies of rewards and promotionthat need to be changed with the implementation of teams arediscussed.

In sum, the book has several interesting and useful points that makeit worthwhile and fast reading by practitioners. A particularly usefulliterary technique that I found enjoyable was the use at the beginningand end of each chapter of installments of an ongoing story of anIT development project. The story nicely encapsulates most of themajor points of the book.

0018–9391/98$10.00 1998 IEEE