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.
There is a growing interest in other large scale, technology immersed projects (e.g., CRM, supply chain management…) 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 spanning 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 circumstances change (e.g., changes in goals, team members…), and the initial ardor cools due to factors such as flagging enthusiasm or reduced resources. The purpose 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 assumption 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 functional area.6 However, project managers of large scale, enterprise wide systems 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 standard team building techniques, these may not be enough to build and sustain the depth of integration needed to ensure a successful implementation.7 An in-depth case study of ERP systems in four large firms in the energy industry reveals that project managers 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. Because 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 methodology 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 perspectives and levels in the firm ranging from CIO and/or project manager to lower level employees, and include people from information systems and from functional areas such as accounting, purchasing, refineries, sales and distribution, and a variety of engineering functions (Table 1). Each firm had implemented most major modules in their ERP package including financial accounting and controlling, fixed assets management, project management, plant maintenance, sales and distribution, materials management, and production planning. The smallest project team examined consisted of 120 people at its peak for a project that lasted approximately three years with nine implementations. The largest 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 external. External obstacles are related to what project team members bring to the project with them from prior experience, perceptions, or frames of reference. 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 project team building from a four-pronged perspective (Figure 1).
Build the Team. All four companies implemented ERP across autonomous business units that operated as silos. The organizational culture was not conducive to collaboration across units, thus was one of the first obstacles to cross-functional team work that the project team managers had to overcome. All project managers used informal, social activities to help foster an atmosphere of collegiality among team members. The team manager at Company A was the only one who used formal team building exercises, and these lasted throughout much of the project. Team members also participated in formal meetings at the end of each major phase of the project where they learned about activities that had happened 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 address 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 others 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 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 leveraging 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 members brought with them. For example, Company B’s organizational decision making structure was a traditional, hierarchical 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 functional distinctions on the team in order to break down traditional walls between functional areas. For example, rather than referring to someone as a programmer, a buyer or an order entry clerk, they were each called order fulfillment team members.
Company C’s project manager equalized team members by giving each member the same bonus at the end of an implementation 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 accomplish a common goal. As one member said, “we had a foxhole mentality” that united team members around a common cause.
Structure the Team. Even if a project 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 progresses and initial enthusiasm wanes under tight deadlines, reduced resources, and team members settle into ‘comfort zones’ of behavior that may not be good for the team. For example, if team members are left in their original units, and particularly in their original physical workspace, then their proximity may lead to them to collaborate more with those they are near than with the team. This can lead to suboptimal behavior within these isolated pieces of the team. To help overcome this internal obstacle, the project managers at Companies A and D organized their team members into small groups (podvilles) in one large open area. As one team member said, “you sometimes could learn something just from 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 obstacle. He organized that team by process, 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 projects 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 Company 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 collaboration broke down. The project manager said that there was a noticeable difference 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 tapered off these exercises. As one member 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 toward the same objectives.” At Company D, the effectiveness of the podville structure in facilitating collaboration broke down as the integration partner ‘took a hard line’ on some things, and 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 reestablish collaboration after its initial effectiveness began to wane. For example, although Company C’s project team was build around processes, it initially did not involve enough people from across the processes to gather sufficient knowledge 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 project 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, collaboration began to break down, and only one took steps to rebuild it.
We propose that interpersonal interventions, such as formal and informal team building exercises, be implemented as the team is formed (Build the Team) to overcome external obstacles 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 initiative 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 restructure, re-equalize, or rebuild the team’s foundations if one or more interventions begins to fail (Tweak the Team).
Although this initially sounds intuitive, note that not all of the project managers 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 strategy 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 influence collaboration, this four pronged approach provides a foundation for addressing and identifying major obstacles to large scale project team collaboration. 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 structural initiatives are required to build and sustain long term collaboration on large scale projects.
Join the Discussion (0)
Become a Member or Sign In to Post a Comment