Application 2 – Annotated Bibliography
contributed articles
O C T O B E R 2 0 0 8 | V O L . 5 1 | N O . 1 0 | C O M M U N I C AT I O N S O F T H E A C M 113
There is a growing interest in other large scale, technology immersed proj- ects (e.g., CRM, supply chain manage- ment…) that also span the organization and extend over a long time.2 Traditional project team management approaches are often not sufficient to see a team through these long, organization span- ning projects.3 Large scale projects are more susceptible to mid-project bog- down than smaller projects due to the scope and duration of the project. This is particularly so when the initial circum- stances change (e.g., changes in goals, team members…), and the initial ardor cools due to factors such as flagging en- thusiasm or reduced resources. The pur- pose of this article is to provide insight into large scale project team behavior and a framework within which project managers may more effectively see their teams through these difficulties.
Salient beliefs about teams in IS based projects are rooted in the as- sumption that team members’ goals are consistent with one another because any given project is typically focused on solving problems for a homogeneous set of stakeholders within a given func- tional area.6 However, project manag- ers of large scale, enterprise wide sys- tems implementations are faced with how to create hybrid team cultures that integrate a diversity of backgrounds, experiences, perspectives, cultures and goals.9 This includes end users and business managers who often have a larger role than in traditional projects. Project managers must find ways to overcome the biases that diverse team members bring to the project in order to facilitate collaboration.5, 8 Management of such diversity is made more complex because teams often develop their own obstacles to collaboration over the life of the project.3 These teams are also typically larger and the project lasts significantly longer than traditional IS projects, with team members rolling on and off the project throughout. Thus, it is difficult to sustain a consistent and cohesive project team environment.
Although managers of these large scale implementations often apply
D O I : 1 0 . 1 1 4 5 / 1 4 0 0 1 8 1 . 1 4 0 0 2 0 6
BY MARY C. JONES
Large Scale Project Team Building: Beyond the Basics Much has been written in the last few years about the success, or usually, failure of enterprise resource planning (ERP) projects. Many guidelines for success have been given including top management commitment, organizational change management initiatives, and comprehensive process mapping.1, 2
Although these are all important components of an ERP project, little attention is given to the implementation project team itself. Yet this is the group of people charged with gathering information and mapping the processes, developing and carrying out change management initiatives, and interfacing regularly with top management, organizational members, and other stakeholders during the project. Project managers of these teams must build and manage teams that blend a diversity of backgrounds and perspectives to collaborate on a large scale project that may last from two to more than five years. However, this does not apply only to ERP project managers.
114 C O M M U N I C AT I O N S O F T H E A C M | O C T O B E R 2 0 0 8 | V O L . 5 1 | N O . 1 0
contributed articles
standard team building techniques, these may not be enough to build and sustain the depth of integration need- ed to ensure a successful implemen- tation.7 An in-depth case study of ERP systems in four large firms in the en- ergy industry reveals that project man- agers of these types of projects may need to approach the management of their teams differently. This includes identifying and managing obstacles to successful teams that arise during the project and that team members bring with them to the project.
Findings from the Field The data from the four firms in this study were collected as part of a larger case study of ERP implementation. Be- cause of the complexity of the projects, we wanted to learn, in-depth, about the details of the project environment in order to provide rich information
that others could then use as a guide for their own large scale project teams. Thus, we used a case study methodol- ogy to gather information from face-to- face interviews, e-mail and telephone calls with 30 people in the four firms. Respondents represent a variety of per- spectives and levels in the firm rang- ing from CIO and/or project manager to lower level employees, and include people from information systems and from functional areas such as account- ing, purchasing, refineries, sales and distribution, and a variety of engineer- ing functions (Table 1). Each firm had implemented most major modules in their ERP package including financial accounting and controlling, fixed as- sets management, project manage- ment, plant maintenance, sales and distribution, materials management, and production planning. The small- est project team examined consisted
of 120 people at its peak for a project that lasted approximately three years with nine implementations. The larg- est consisted of 750 people at its peak for a project that lasted approximately three years with five implementations (Table 2).
In-depth interviews revealed many obstacles to collaboration and a variety of initiatives the project managers took to overcome these obstacles. Two types of obstacles emerged: internal and ex- ternal. External obstacles are related to what project team members bring to the project with them from prior ex- perience, perceptions, or frames of ref- erence. Internal obstacles arise within the team as the project progresses as a result of such things as the context of the project and the merger of team member differences.
Examination of the patterns across all the firms indicates that project managers might best approach proj- ect team building from a four-pronged perspective (Figure 1).
Build the Team. All four compa- nies implemented ERP across autono- mous business units that operated as silos. The organizational culture was not conducive to collaboration across units, thus was one of the first obsta- cles to cross-functional team work that the project team managers had to over- come. All project managers used infor- mal, social activities to help foster an atmosphere of collegiality among team members. The team manager at Com- pany A was the only one who used for- mal team building exercises, and these lasted throughout much of the proj- ect. Team members also participated in formal meetings at the end of each major phase of the project where they learned about activities that had hap- pened prior to them joining the team, and became integrated into the existing team. They spent a half of a day or a day off-site to go through “what we’d done, what we’d accomplished, what we had in front of us, how we were going to ad- dress that, and what the organization would be. Because each time you (start a new phase), you kind of reshuffle your team,” as new people come on and oth- ers go back to their business units.
Each project manager also tried to garner the best people in every area for the team, and in some cases sent people back to their units if they did not work
Table 2: Profile of Projects
Company Date SAP Project Began
Date of 1st Implementation
Date of Last Implementation
Number of Implementations
Number of Team at Peak of Size
Company A late 1995 early 1998 Nov 1999 6 150
Company B early 1995 March 1996 July 1998 5 750
Company C late 1996 Jan 1999 Dec 1999 9 120
Company D late 1996 Oct 1998 Oct 1999 2 300
Table 1: Profile of Respondents
Company Project Team Role for each respondent (1 respondent per line)
Company A SAP technical infrastructure manager� Change management manager� SAP custom development manager – largely SAP programming, interfaces, & conversions� Manager of one unit’s SAP implementation; member of SAP team on all others� Team leader for SD & AR/Credit modules � SAP Architecture Manager� Project manager�
Company B
(Multiple
roles many
members)
Responsible for SAP configuration; reengineering processes; managed quality assurance & � testing; change management IT team lead; applications development lead; general leadership with 3 others of Chemical & � Downstream implementations Managed configuration & upgrades throughout the company Project manager� Project Manager�
Company C Logistics team lead� Team lead of all financial modules of SAP� Director of the order-to-cash process. Dealt with customer service, accounts receivable, � credit and some sales accounting. Team lead for sales and operations planning� Change management lead. Responsible for communications and training materials. � Business implementation lead� Project Manager� Manager of the support group� Co-project manager� Co-project manager�
Company D Team Lead for Plant Maintenance module� Production support readiness leader; how the firm would be ready to operate SAP after go-live� Team lead for Sales & Distribution (SD) module and the Accounts Receivable (AR) module� SAP go-live coordinator� Business implementation lead in one division� Change management leader� Release 1 implementation manager� Project Manager�
contributed articles
O C T O B E R 2 0 0 8 | V O L . 5 1 | N O . 1 0 | C O M M U N I C AT I O N S O F T H E A C M 115
out. They focused on building a team of people who could “work in a fast paced team environment, were well respected in their units, were very knowledgeable in their areas, and who advocated lever- aging common processes.”
Equalize the Team. In addition to the basic building blocks, some of the project managers sought to equalize team members in order to overcome external obstacles that team mem- bers brought with them. For example, Company B’s organizational decision making structure was a traditional, hi- erarchical one in which functional and seniority distinctions were very much part of the culture. This was an obstacle to collaboration on the team because the project team consisted of people across levels of seniority and functions. For example, junior people were afraid to express their ideas in front of the more senior employees. The project manager deemphasized titles, rank, and seniority on the team to minimize this obstacle. He also removed func- tional distinctions on the team in or- der to break down traditional walls be- tween functional areas. For example, rather than referring to someone as a programmer, a buyer or an order entry clerk, they were each called order ful- fillment team members.
Company C’s project manager equal- ized team members by giving each mem-
hearing what the group next to you was talking about.” Although this was not easy to implement, both companies thought it was worth the effort.
The project manager at Company C took a different approach to overcome much the same project team based ob- stacle. He organized that team by pro- cess, rather than by function or module as was done by the other three firms. This built an overlap between modules and functions in the project, and often two or more functional groups would work together on a particular piece. For example, logistics was in the sales and distribution module, but Company C had a subteam manage the logistics process separately from the sales and distribution people. Because much of that data was also in the order-to-cash process performed by the customer service area, the logistics group worked closely with the order-to-cash group to make sure that the logistics pieces fit.
Tweak the Team. Regardless of initiatives that project managers use, initial collaboration in large scale proj- ects can still break down over time if not monitored. Ironically, obstacles to collaboration may also arise out of the very initiatives designed to minimize obstacles.4 This happened in each of the teams here. For example, at Com- pany B, senior people began to resent that junior people had ideas or knew things that they did not. Many stopped listening to junior people, and collabo- ration broke down. The project manag- er said that there was a noticeable dif- ference in the effectiveness of the team after this point.
At Company A, despite the success of the formal team building exercises, as time went by the team felt more pressure to finish the project and ta- pered off these exercises. As one mem- ber said, “where people came on who didn’t go through the extensive team building exercises we noticed some problems with them not having the background of how the culture of team relationships worked and not having had team building experience. We had a few more issues we had to deal with to get everybody in line and working to- ward the same objectives.” At Compa- ny D, the effectiveness of the podville structure in facilitating collaboration broke down as the integration partner ‘took a hard line’ on some things, and
ber the same bonus at the end of an im- plementation regardless of rank in the organization. The bonus was based on the overall quality of the work and how well the implementation deadlines were met. This provided an incentive for each member to work with others to accom- plish a common goal. As one member said, “we had a foxhole mentality” that united team members around a com- mon cause.
Structure the Team. Even if a proj- ect team manager is able to overcome obstacles team members bring with them, he/she may still be faced with obstacles that arise as the project pro- gresses and initial enthusiasm wanes under tight deadlines, reduced re- sources, and team members settle into ‘comfort zones’ of behavior that may not be good for the team. For exam- ple, if team members are left in their original units, and particularly in their original physical workspace, then their proximity may lead to them to collabo- rate more with those they are near than with the team. This can lead to subop- timal behavior within these isolated pieces of the team. To help overcome this internal obstacle, the project man- agers at Companies A and D organized their team members into small groups (podvilles) in one large open area. As one team member said, “you some- times could learn something just from
Figure 1: Classification of Initiatives to Overcome Cultural Obstacles To Project Team Collaboration
116 C O M M U N I C AT I O N S O F T H E A C M | O C T O B E R 2 0 0 8 | V O L . 5 1 | N O . 1 0
contributed articles
organizational team members began to feel that they could not or should not contribute their ideas.
The project manager at Company C was the only one of the four who took steps to ‘tweak the team’ and reestab- lish collaboration after its initial effec- tiveness began to wane. For example, al- though Company C’s project team was build around processes, it initially did not involve enough people from across the processes to gather sufficient knowl- edge about how to map them to ERP. This was apparent after the first round of implementations. So, they rebuilt the team to gather this knowledge for their other implementations, in spite of the objections of their integration partner, and knowing that this would add time and cost to their initial estimates.
Implications for Large Scale IS Project Team Managers Given these experiences, there appear to be two levels of interventions to overcome obstacles to effective teams: interpersonal and structural. Because obstacles arise out of both what the team members bring to the project (external) and what occurs as the proj- ect progresses (internal), we suggest a four pronged approach to large scale IS project team building. Although each of the project managers here used one or more of the prongs, none applied all four. Somewhere in their projects, col- laboration began to break down, and only one took steps to rebuild it.
We propose that interpersonal in- terventions, such as formal and infor- mal team building exercises, be imple- mented as the team is formed (Build the Team) to overcome external ob- stacles that may carry over to the team. However, this alone is not sufficient. Thus, deeper, structural initiatives to further overcome external obstacles are needed to put team members on an equal footing (Equalize the Team), such as rewarding all team members equally or removing hierarchical distinctions on the team. Another structural initia- tive is to alter the team workspace to minimize physical or social obstacles within the team (Structure the Team). Finally, the interventions should be monitored and action taken to restruc- ture, re-equalize, or rebuild the team’s foundations if one or more interven- tions begins to fail (Tweak the Team).
Although this initially sounds intuitive, note that not all of the project manag- ers in this study went this far.
The intense pressure of completing a project may create an environment in which project managers become so caught up in dealing with daily issues that it is not always easy to recognize, mid-battle, that the management strat- egy needs to be altered. One benefit of the framework proposed here is that it provides project managers with an overarching ‘battle plan’ so that they may more easily recognize when they are battling internal obstacles and what steps to take to overcome them.
While it is important to recognize that other factors such as leadership, coordination, and control also influ- ence collaboration, this four pronged approach provides a foundation for addressing and identifying major ob- stacles to large scale project team col- laboration. It suggests that project team managers must not only focus on initial team building, but that they also must continually monitor the team for changes that may undermine initial collaboration. It also suggests that not all that initiatives facilitate collaboration address the same type of obstacles, and that obstacles arise out of both the what team members bring to the project and from within the team itself. Both interpersonal and struc- tural initiatives are required to build and sustain long term collaboration on large scale projects.
References 1. Bingi, P., Sharma, M.K., and Godla K. J., Critical issues
sffecting an ERP implementation. Information Systems Management 16, 3, 7-17. (1999).
2. Brown, C. and Vessey, I., Managing the next wave of enterprise systems: leveraging lessons from ERP. MIS Quarterly Executive. 2, 1. (2003).
3. Earley, P.C. and Mosakowski, E., Creating hybrid team cultures: An empirical test of transnational team functioning. Academy of Management Journal. 43, 1, (2000), 26-49.
4. Garud, R. and Kumaraswamy, A. Vicious and virtuous circles in the management of knowledge: The case of Infosys Technologies. MIS Quarterly 29, 1, 9-33. (2005).
5. Jermier, J.M., Slocum, J.W. Jr., Fry, L.W., and Gaines, J. Organizational subcultures in a soft bureaucracy: Resistance behind the myth and façade of an official culture. Organization Science 2, 2, 170-194, (1991).
6. Jones, M.C. and Harrison, A.W. IS project team performance: An empirical assessment, Information & Management 31, 2, 57-65. (Nov 1996)
7. Jones, M.C. and Price, R.L. Organizational knowledge sharing in ERP implementation: Lessons for industry. Journal of End User Computing, 16, 1, 21-40. (2004)
8. Sackmann, S.A. Culture and subcultures: An analysis of organizational knowledge. Administrative Science Quarterly, 37, 1, 140-162. (1992).
9. Smith, H.A. and McKeen, J.D. Creating and facilitating communities of practice. In Handbook on Knowledge
Management: Knowledge Matters, Holsapple, C.W., Springer-Verlag: New York, 393-407. (2003).
Mary C. Jones is a professor of information systems in and Interim Chair of the Information Technology and Decision Sciences Department at the University of North Texas. Her work has appeared in Behavioral Science, European Journal of Information Systems, MIS Quarterly, and elsewhere.
© 2008 ACM 0001-0782/08/1000 $5.00