Using Shared Leadership to Foster Knowledge Sharing in Information ...

Proceedings of the 38th Hawaii International Conference on System Sciences - 2005

Using Shared Leadership to Foster Knowledge Sharing in Information Systems Development Projects Barbara Hewitt University of Texas at San Antonio [email protected]

Abstract Information systems development (ISD) projects are enormously complex, requiring input from heterogeneous team members with a varied array of knowledge and skills. Because expertise in an ISD project is broad and complex, this expertise is not possessed by an individual developer but distributed among team members who are selected for their expertise in the relevant domains. In addition to working cooperatively and integrating tasks, team members must exchange knowledge in order to complete the assigned project. This enormous dependence on knowledge sharing creates extensive burdens for coordination and communication on both project managers and relevant domain experts throughout all stages of the ISD project. This paper conceptualizes the benefits of a combination of vertical and shared leadership in ISD project teams, as proposed by Pearce [1] and maps this structure to related early work on the dynamics and productivity of programming teams (most notably, Weinberg’s [2] Egoless Programming Team Structure). 1. Introduction Organizations in America spend over $275 billion on over 200,000 software development projects each year [3]. In 2000, only 28% percent of the development projects were completed on time and within the projected budget. Twenty-three percent of the projects attempted were cancelled altogether. While other projects were eventually completed, they were plagued by budget and time overruns or did not meet user expectations [4]. Examples of large software development failures or overruns include the Denver Airport baggage handling system, the Confirm travel reservation system and the California Department of Motor Vehicles (DMV) system. The baggage handling system delayed the opening of the airport for more than a year at a cost of more than $1million dollars per day [5]. The $45 million dollar California DMV system was cancelled without any working routines after seven years of development [3]. Information systems development (ISD) projects are enormously complex, requiring input from heterogeneous

Diane Walz University of Texas at San Antonio [email protected]

team members with a varied array of knowledge, skills and expertise. Because the knowledge, skills, and expertise needed for an ISD project are too broad and complex to reside in any individual developer, these must be distributed among team members who are selected for their expertise in the relevant domains. In addition to working cooperatively and integrating tasks, team members must exchange knowledge and actual learning must occur in order to complete the assigned project. This enormous dependence on knowledge sharing creates extensive burdens for coordination and communication on both project managers and relevant domain experts throughout all stages of the ISD project. Although prior research has attempted to explain why ISD projects succeed or fail [6-8], results have been inconclusive and the rate of failures and challenged completions is still great. Jurison [9] distinguishes between software (or system) related problems in ISD and management-related problems. Software problems include the intangibility of the product, the complexity, and the volatility of requirements. Management-related difficulties are derived largely from failure to follow good management principles, i.e., lack of an adequate plan, poorly defined goals, and unrealistic deadlines and/or budgets. The dynamics of knowledge sharing and project leadership have not been explicitly explored. This paper considers the nature of ISD projects as team-based knowledge work applied to a highly complex task with broad requirements for knowledge and expertise across multiple domains. This paper conceptualizes the benefits of formalizing knowledge sharing through a combination of vertical and shared leadership in ISD project teams, as proposed by Pearce [1] and maps this structure to related early work on the dynamics and productivity of programming teams (most notably, Weinberg’s [2] Egoless Programming Team Structure). To accomplish this, the paper is organized as follows. Section 2 describes the nature of ISD projects as teambased knowledge work and provides a review of some relevant project coordination and leadership structures. Section 3 contains a description of the proposed leadership structure, which combines vertical and shared leadership. Section 4 describes the implications of the

0-7695-2268-8/05/$20.00 (C) 2005 IEEE

1


proposed structure on ISD projects and contains an example of the roles of the vertical and shared leaders for one stage of an ISD project. Section 5 offers a discussion of the benefits and costs associated with the proposed structure.

2.

The nature of ISD projects

The most difficult challenges in software development are the definition of the requirements and the design of the system. The requirements analysis involves identifying the users’ needs and the project goals and objectives. The design process conceptualizes the needs and goals, and thus prescribes the systems objects and their relationships to achieve the intended purpose [10]. A significant portion of the software design task, in particular, is the understanding, clarification, and/or inference of the “intended purpose” of the proposed system. The designer or design team must translate abstract and incomplete requests and specifications into concrete design artifacts such as a working prototype or data flow diagrams. The software design process is an “ill-structured” problem, which often must be decomposed into a collection of well-structured component problems [11]. Rittel and Weber [12, 13] describe ISD planning and design problems, in general, as “wicked” problems. Much of ISD is knowledge work. For such tasks, there is seldom one correct answer and no enumerable solution set exists from which options can be selected. Old solutions cannot be applied directly to new projects and ex post evaluation is difficult. A major source of complexity in the ISD task lies in the difficulty of simply understanding the problem. As Figure 1 illustrates, the design of such computerbased systems generally requires knowledge that spans several domain areas [14]. Curtis, Krasner, and Iscoe stated “most project personnel were knowledgeable in one or two of the areas represented by the circles.” They also pointed out that one of the most salient problems was the “thin spread of application domain knowledge.” Today, with the emergence of new technologies, methods of incorporating these technologies, different system environments including hardware, software and database features and the increasing complexity in requirements within the user domain, the knowledge possessed by each team member is spread even thinner. While the knowledge and expertise have decreased, the number of domains requiring knowledge and expertise has increased. In general, no individual possesses all of the knowledge required for accomplishing the design task and thus, a team (or several teams) is assigned. A lack of knowledge, or thin distribution of knowledge within the project team is typical of the environments of large ISD projects, where systems are, (by definition) large, complex, and

often involve numerous, interrelated constraints and assumptions. Thus, ISD often involves teams (or groups of teams) of heterogeneous individuals (with respect to background, knowledge, and expertise), engaged cooperatively in highly interdependent tasks. That is, individual team members cannot work independently and then simply pool their results to complete a project.

Figure 1. Knowledge domains for information system development projects [14] Studies of the interactions of software development teams have found team members’ knowledge and expertise to be leading forces behind their participation and leadership in the design process. These findings stress the importance of the distribution of knowledge and expertise across team members and the related significance of context-sensitive learning (which is important in the upstream activities of ISD) and offer implications for managing the knowledge acquisition, sharing, and integration process [15, 16]. This enormous dependence on knowledge acquisition, sharing, and integration places extensive burdens for coordination and communication on both project managers and relevant domain experts throughout all stages of the ISD project. Ideally, project teams are staffed so that the knowledge and skills needed for the project are available within the project team. With so many knowledge domains represented across a problemspace too complex for any individual to understand well, the team members on a large ISD project (representing differing areas of knowledge and expertise) must exchange knowledge. Essentially, learning must take place in order for productive work to be accomplished.

3. Combining leadership.

0-7695-2268-8/05/$20.00 (C) 2005 IEEE

vertical

and

shared

2


Knowledge and expertise are increasingly important sources of power in group knowledge work. [17, 18]. Experts and problem-solvers derive power and influence from the value of the "know-how" which they contribute. When an individual has special knowledge and skills, which are both respected by the group and considered relevant for the task at hand, the individual can be expected to play a more significant role in the process of group software design. In studies of decision making and problem solving groups, individuals with task-related abilities were found to be more active in the group, made more contributions to the group’s activities, and had more influence on the group’s decisions [19]. From an in-depth study of the interactions of a software development team, Walz, Elam, and Curtis [15] found that knowledge and expertise were the leading forces behind participation and leadership in the design process. In a study of large complex software development projects, individual software development team members understood components of the application; however, the deep application-specific knowledge requirements was spread among the development team members [14]. Weinberg’s [2] concept of the Egoless Programming team formalizes this notion of mapping leadership roles to relevant expertise. Weinberg recommends a team structure where leadership roles shift, depending upon the set of skills and abilities in the group, and the match between these and the requirements of the sub-task being addressed. Decisions, problem-solving, and goal-setting are accomplished by consensus. In an empirical study of programmer team structures, Mantei [20] found that this structure outperformed the more traditional vertical leadership structure when applied to complex programming tasks of long duration. The egoless team structure has not proven effective in practice, however, for most software projects [9] in part because they tend to drift due to a lack of leadership. Pearce [1] has reviewed a wide collection of research on leadership and proposes the combining of vertical and shared leadership for teams engaged in knowledge work. His model is similar to The Egoless Programming Team structure, described above, in that leadership is shared and rotates “to the person with the key knowledge, skills and abilities for the particular issues facing the team at any given moment.” This model differs, however, in that the role of the vertical leader is essential for the functioning and progression of the shared leadership approach to knowledge work. Faraj and Sproull [16] distinguish administrative coordination (assign tasks, allocate physical and economic resources, manage resource dependencies and integrate outputs) from expertise coordination (coordinating task skills and knowledge dispersed throughout the group by knowing where expertise exists, identifying where it is needed and providing it to those

who need it). The notion of shared leadership considers expertise (and expertise leadership) to be an administrative resource to be managed within the team context. Pearce recommends this share leadership structure for tasks that are highly complex and interdependent, and whose solutions involve creativity. The application to ISD is straightforward, as an increasing number of ISD projects meet this criteria.

4. The Proposed Model. Pearce [1] offers specific leader behaviors through which both vertical leaders and team members can work and suggests that vertical leaders should offer both shared leadership support and shared leadership maintenance. For ISD projects, both management tasks and responsibilities can be identified that embody these notions of support and maintenance of shared leadership. The vertical leader in the ISD project can be considered to be an expert in yet another relevant knowledge domain – that of project management. This person is often assigned the role of project manager. Using project planning as an example illustrates the “technology of ISD project management” and shows its application to the shared leadership process. In traditional ISD projects, this vertical leader or project manager often maintains control over the project team for the project duration. This vertical leadership used in traditional ISD projects is depicted in Figure 2.

Figure 2: Traditional ISD team makeup where the project manager maintains leadership throughout the project

ISD planning includes the following activities: • Project Definition Identify objectives Identify requirements Select a development process

0-7695-2268-8/05/$20.00 (C) 2005 IEEE

3


Define the boundaries of the work • Estimation Estimate the size of the project Schedule Estimate costs, prepare budgets • Risk Assessment For project definition, experts in the user/application domain must drive the process of identification of objectives and requirements. Systems personnel will dominate the selection of a development process and identification of project scope. For these stages, shared leadership will facilitate the knowledge exchange, which is needed to accomplish the required tasks. The vertical leader should assist this task by identifying the project team member who possesses the knowledge required for each of each knowledge domain area explored in each project phase and allowing that person to lead the project discussions during this phase. This does not mean that this person should completely dominate this segment of the development project; however, when discussion is focused on this issue, this person should be allowed to lead the conversation and drive the development of this area. Estimation activities represent highly technical managerial tasks. The vertical leader will determine the project size, develop a schedule, and prepare a budget, including cost estimates, with minimal leadership required from the team members. Team members should be consulted, but the project manager should possess the knowledge required to complete this task. Risk assessment will also be led by the vertical leader, but with input and shared leadership from team members. McFarlan’s [21] contingency approach to risk management considers project size and structure. Large, structured projects require formal planning and control tools, for which the vertical manager serves as leader and domain expert. Other projects may require external or internal integration tools, which are related to the user/application domain experts and the technical domain experts, respectively. Teams with a combination of vertical and shared leadership will be better able to handle both of the kinds of difficulties typical of ISD projects, those related to software development and those that are managementrelated. With shared leadership across the domains, the team will be able to better navigate the software problems of intangibility, complexity, and volatile requirements. With a strong vertical leader to manage the project as well as the knowledge-driven shared leadership in the ISD project, the team will be less likely to suffer from the “traditional” management-related difficulties described above.

This proposed model of shared leadership model is depicted in Figure 3. While the project manager will maintain control over the project’s management at times, often the leadership of the development team(s) will change to the person with the most knowledge. Some projects will have only two levels: the manger and the developers; however the project will consist of several design teams with numerous levels within these teams. While the project manager should maintain the leadership for project management duties, team members should be allowed to lead when they possess the knowledge that needs to be shared during different phases of the project. Thus when the development team is discussing network administration, the team member with the most knowledge about network administration should be allowed to lead the group.

Figure 3: Shared leadership model

5. Conclusions The team structure proposed here for ISD projects will leverage the skills, abilities, backgrounds, and knowledge of the knowledge workers who make up the project teams. Preliminary investigations can be conducted to identify the costs and benefits. Studies can be designed to determine if the proposed structure affects the time to completion, cost of the project, and/or the functionality and quality of the ultimate product. Benefits should include software development projects that meet the user’s needs, that are developed on time within budget constraints (and are thus deemed successful). Costs may be related to increased conflict which leads to disharmony in the development group and thus projects that do not meet the user’s needs, are over budget and time allocations and thus failures. In a longitudinal sense, even for successful projects, the groups may not be able to work together in the future, due to the disharmony that occurred during the current project.

0-7695-2268-8/05/$20.00 (C) 2005 IEEE

4


The notion of knowledge and expertise as scarce resources in ISD is not new. The notion of managerial skill as a scarce resource is also not new. Additional work is suggested to address the issues of whether additional organizational systems, such as reward systems or training, can actually facilitate the development of shared leadership and/or increase managerial capabilities. Other related concepts may be found to affect the shared leadership process, such as culture and personality, creating implications for staffing and planning. The combination of vertical and shared leadership in ISD may leverage the constrained resources of development teams to provide enormous improvements in system success rates. However, the implications suggested here for the proposed management structures for large-scale projects must be studied extensively.

6. References [1]

[2]

Pearce, C.L., “The Future of Leadership: Combining Vertical and Shared Leadership to Transform Knowledge Work.” Academy of Management Executive, 2004. 18(1): p. 47-57. Weinberg, G.M., The Psychology of Computer Programming. Computer Science Series. 1971, New York, New York: Van Nostrand Reinhold, Company.

[3]

Johnson, J., “Turning Chaos into Success.” Software Magazine, 1999: p. 30-34,39.

[4]

Johnson, J., Boucher, K. D., Connors, K., & Robinson, J., “The Criteria for Success.” Software Magazine, 2001. 21(1): p. 3-10.

[5]

Guinan, P.J., J.G. Cooprider, and S. Faraj, “Enabling Software Development Team Performance: A Behavioral Versus Technical Approach.” Information Systems Research, 1998. 9(2): p. 101-125.

[6]

Seddon, P.B., “A Respecification and Extension of the DeLone and McLean Model of IS Success.” Information Systems Research, 1997. 8(3): p. 240-253.

[7]

DeLone, W.H. and E.R. McLean, “The Delone and McLean Model of information Systems Success: A Ten-Year Update.” Journal of Management Information Systems, 2003. 19(4): p. 9-30.

[8]

DeLone, W.H. and E.R. McLean, “Information Systems Success: The Quest for the Dependent Variable.” Information Systems Research, 1992. 3(1): p. 60-95.

[9]

Jurison, Jaak, “Software Project Management: The Manager's View.” Communications of the Association for Information Systems. 1999. 2(September): p. 2-50.

[10]

Churchman, C.W., The Design of Inquiring Systems: Basic Concepts of Systems and Organizations. 1971, New York: Basic Books.

[11]

Simon, H.A., “Technology and Environment.” Management Science, 1973. 19(10): p. 11101121.

[12]

Rittel, J.J. and M.M. Weber, “Planning Problems are Wicked Problems”, in Developments in Design Methodology, N. Cross, Editor. 1984, Wiley.

[13]

Rittel, H.W.J. and M.M. Weber, “Dilemmas in a General Theory of Planning.” Policy Sciences, 1973. 4: p. 155-169.

[14]

Curtis, B., H. Krasner, and N. Iscoe, “A Field Study of the Software Design Process for Large Systems.” Communications of the ACM, 1988. 31(11): p. 1268-1287.

[15]

Walz, D.B., J.J. Elam, and B. Curtis, “Inside a Software Design Team: Knowledge Acquisition, Sharing and Integration.“ Communications of the ACM, 1993. 36(10): p. 63-77.

[16]

Faraj, S. and L. Sproull, “Coordinating Expertise in Software Development Teams.” Management Science, 2000. 46(12): p. 1554-1568.

[17]

Kettinger, WJ and V Grover, “Special Section: Toward a Theory of Business Process Change Management”, Journal of Management Information Systems, 2000, Vol. 12 (1), pp. 9-30.

[18]

Morgan, Gareth, Images of Organization: The Executive Edition, Sage Publications, London, 1988.

[19]

Shaw, M.E., The Psychology of Small Group Behavior, 1976, New York: McGraw Hill.

[20]

Mantei, M. “The Effect of Programming Team Structures on Programming Tasks”, Communications of the ACM, 1981, 24(3), pp. 106-113.

[21]

McFarlan, F.W., "Portfolio Approach to Information Systems", Harvard Business Review, 59(5), 1981, pp. 142-150

0-7695-2268-8/05/$20.00 (C) 2005 IEEE

5