I. Organizational overview A brief description of the organization, e.g. number of employees, number of locations, when established, key individuals, products or services provided. This should take up no more than one half page of your report.

II. Identification of Interpersonal Issues Identify the OB issues (people issues) that appear in the case study. As a group, you will later decide which are the most critical and therefore should have top priority for managers to deal with.

Choose two or three of the following as the basis for your analysis and recommendation: Conflict is there conflict or the potential for conflict between individuals or teams? Motivation Are the methods used to motivate employees appropriate and effective? Leadership is leadership style effective? Is it appropriate for the situation? Culture what role does company culture play in success of the organization? Are there threats to the existing company culture? Is there a need to adapt to a new culture? Communication is adequate and does it use appropriate channels? Change management is the organization facing significant change? What challenges or opportunities does change present? Other OB issues that you wish to discuss related to concepts covered in class.

NOTE: DO NOT DISCUSS THE CAUSE OF THE ISSUES OR RECOMMEND SOLUTIONS IN THIS SECTION. Simply introduce / describe the issues you will discuss in your report. (hint: dont use the word should in this section)

The whole assignment should be no more than 500 words (approx. 2 pages). Please use a 12pt font, double spaced, and consistent.

Case Overview

This case follows a project team as they work to implement a vaccine safety database tracking system within a major international pharmaceutical company. The company was formed through the merger of two organizations. Team members are located in Canada and in the UK, and conduct much of their work virtually. In spite of their technical skills and abilities, the team struggles to collaborate; after more than a year of work, key conflicts remain unresolvedmany of which are not apparent to all team members. The case concludes with senior management appointing process advisors and implementing a conflict escalation process. Whether these interventions are effective or even appropriate remains an open question for students to explore.

Review this case as if you are a consultant hired by the company to improve the teams dynamics. As you read, keep in mind that the case is written

primarily from the perspective of the Canadians on the team. Look for the merits in their points of view, but consider how the

same facts might be interpreted differently .

Case Description

VaxPharm Ltd

Headquartered in the UK, VaxPharm Ltd is one of the worlds largest vaccine companies. It was established two years ago when two formidable pharmaceutical companies, PfiVax and OxPharm, combined. Although officially termed a merger, in practice, it might better have been described as an acquisition of PfiVax, a UK-based company with extensive Canadian operations, by OxPharm, a UK-based company.

Like all vaccine companies, VaxPharm is obligated to keep detailed records of its vaccine safety practices. To do so, VaxPharm relies on sophisticated database systems that track and record harmful events associated with the administration of its products in the market and under development. The Vaccine Safety Division of VaxPharm is charged with fulfilling this obligation. The division is headed by Henry Thomson. He is based in the Canada, but the division has managers and employees in numerous countries. Thomsons deputy director, Monica Seibold, is located in the UK.

The Vaccine Safety Division is in the process of implementing a new harmful event database system called Lighthouse, which will be used by division employees around the globe.

Project Team Structure

The core team responsible for designing and implementing Lighthouse consists of:

• Steve Mendez (UK), Project Manager.

• Francisco Sanchez (Canada), Communication Lead. Francisco is from the Vaccine Safety Division and is charged with keeping all managers in the Vaccine Safety Division updated on the status of the project.

• Jackie Bruce (UK), Global Information Systems (IS) Lead. Jackie is from the IS Division. Her role on the team is to ensure that the system (including software and hardware) is appropriately integrated and compatible with other company systems and applications.

• Petra Morris (UK), Global User Lead. Petra is part of the Vaccine Safety Division. Her role is to ensure that the system meets the tracking and reporting needs of the Vaccine Safety Division.

• Karen Wong (Canada), Validation Lead. Karen is from the Vaccine Safety Division. Her role is to ensure that the system is fully tested and that all test results are documented

• Jeannette Bender (Canada), Training Lead. Jeannette is from the Vaccine Safety Division. She is charged with making sure users are trained on how to use the system.

• Parkash Singh (UK), Quality and Safety (Q&C) Lead. Parkash is part of the IS Division. His job is to ensure that the system meets all the regulatory requirements of government agencies worldwide.

In addition to the core team, five subteams were formed. These subteams each have a user lead from the Vaccine Safety Division and an IS lead, and report directly to the User Lead (Petra Morris) and IS Lead (Jackie Bruce) respectively. Each team also has two to four additional members, most of whom are involved with the project on an intermittent basis. Overall, half of the subteams members are located in the Canada and half are based in the UK.

- An administration subteam (located in Canada.) is responsible for ensuring that Lighthouse maintains separate databases for each product in all of its packaging forms

- A data entry subteam (located in Canada) is charged with identifying all of the fields that would appear on the systems screens.

- A workflow subteam (members evenly divided between Canada and the UK) is responsible for determining the ways in which the system automatically passes work from one user to the next. For example, a case entered into the system would typically first be handled by a data-entry clerk before being transferred to a vaccine safety evaluation expert and finally to a reporting officer who would submit the case to regulatory authorities.

- A migration subteam (located in the UK) is responsible for mapping all the data from the legacy (existing) systems to Lighthouse.

- A report subteam (located in the UK) is charged with designing the reports that will be generated from lighthouse

Core Team Dynamics

The Lighthouse core team, some of whom had worked together before, started the project by holding a one-day, face-to-face kick-off meeting in London at the corporate headquarters. Meeting as one large group, all project team members attended, including those on the subteams. There were formal introductions to ensure everyone knew each other. The roles of the various subteams were articulated and the project timeline established. At the time, recalls Francisco Sanchez, the proposed schedule seemed reasonable and the subteam structure made sense to us all. Looking back, however, there was no opportunity to really get past formalities.

Steve strongly controlled the way meetings were run by restricting the kind of information that was exchanged and the ways in which it was exchanged. In and of itself, this would not have been a problem for many of the team members. As Karen Wong, the core team validation lead, explained when she was interviewed for this case, Its a project managers job to monitor what occurs during team meetings. The problem with Steves approach, though, was that he was too autocratic to be practical. For instance, he frequently put together an agenda for meetings

without input from other team members. Further, he would allot only 10 minutes for other issues not on the agenda and only if time permitted.

Early in the projects life cycle, Francisco Sanchez, the communication lead, presented a communication plan to the core team during one of their conference calls. Steve remained quiet during the presentation and offered little in the way of comments on the plan presented; however, following the meeting he called Francisco, stating that nothing was to be presented at core team meetings without his prior knowledge. Frustrated and angry, Francisco became more withdrawn; he felt that as a part of the core team, his discretion and expertise were being undermined.

. However, their UK-based core team colleagues (all of whom had been part of OxPharm prior to the merger), especially Steve, consistently responded negatively to any input based on the previous project. In fact, it had gotten to the point where it seemed that any

Communication across subteams was a key point the Canadian members of the core team wanted to stress to their UK colleagues. From their work on Echo, they had learned how important it was to keep people informed of what other subteams were doing. System development is dynamic, explained Karen Wong. We had learned how quickly any two subteams could head down different paths if the communication and coordination was not as dynamic as the work itself. She went on to stress that too frequently, the result would be one or both teams having to rework their designcreating time delays that rippled through the project schedule and lead to bad feelings within the team. Its not that our colleagues in the UK wanted poor communication, Jeannette Bender added, but they were committed to dealing with this challenge through a chain of command. Petra and Jackie wanted to be the focal points for passing information across subteams. That may work fine in theory, but not in practice. Instructing the subteams to communicate through the user and IS leads slowed things down. Anyone who has ever played the grapevine game knows how much gets lost when layers are added between the start and end of a communication chain. Referring to the physical distance that separated some of the subteams, she stressed, Its not like we could even rely on informal communication in the halls to fill in the gaps .

The Core-Core Team

In many instances, decisions which could have been made collaboratively by the core team were not made that way. Instead, Steve, acting unilaterally or at best in consultation with UK team members, made decisions that were then communicated back to Canadian team members as being finalized. Increasingly, Canadian team members felt as though their input was not valued and that their perspectives were not being given due consideration.

In one telling example, during a core team teleconference, the team was discussing important data entry fields that would need to be included in the system. Among other things, these unanticipated additions were going to affect system report generation as well as eventual training. As the team was exploring the implications of the changes, Steve stopped their discussion by declaring that the team as a whole need not be concerned. Referring to himself and his UK colleagues, he said it was an issue that could be taken up by the core-core team. To the Canadians on the team, the remark only reinforced their sense of alienation.

When Steve was asked about the change of plans, he said that top management made the decision. In subsequent discussions with some of those senior managers, however, it was discovered that they were not involved in the decision and that it had been made by Steve.

Tensions Spread to the Subteams

The subteams continued to fall behind schedule, but the delivery date remained firm. The timeline slippages were obvious, but almost no one was willing to discuss them openlyleast of all the Canadians on the core team. It was easy for us to see how the slippages were related to subteam communication breakdowns, but wed been down that road so many times we didnt know how to raise it anymore, explained Francisco Sanchez.

In September, the Canadian core team members felt they needed to escalate their concerns. After consulting with Karen and Jeannette, Francisco approached Henry Thomson, the head of the Vaccine Safety Division. According to Francisco, Henry, who was also based in Canada, took his concerns seriously and promised to act. I assumed, said Francisco, that meant Henry would work through Steve, perhaps coaching and counseling him on how to open up dialogue and communication within the core team and throughout the project overall.

Instead, Henry chose another approach. He sent an e-mail message to the entire division, not just those working on the Lighthouse project. The message was sent under his name and that of his deputy director, Monica Seibold, who was located in the UK .

When we launched the Lighthouse project by forming the core team and subteams, we expected that all team members would collaborate to develop best practices for a new safety database system. We anticipated that this would mean building on lessons learned from past projects and processes and taking into account evolving regulatory requirements and thoughtful consideration of other best practices.

tion rather than the rule. Team members should ultimately abide by majority opinion. However, for those times when team opinion is evenly split or when the disagreement pertains to key strategic objectives, the team sponsors should be contacted so they can work with team members and other appropriate staff to finalize a course of action