Case Study: TCP Enhancements at Gigaplex Systems

Directions

When reading this case study, focus on the need to manage stakeholder expectations at various levels in the organization, with peers, management, and subordinates. Try to identify the activities that assist or undermine one’s ability to manage stakeholder expectations in a positive way.

Case Summary

Description

Stephanie White, one of CyCorp’s program managers, is having a tough time explaining to herself and to her boss what the main problems are that have caused the Gigaplex project to get out of hand. Meeting stakeholder expectations and interacting with a diverse multinational team as well as a tough client has been difficult for everyone.

Case Study Objectives

After reading the case study, you will be able to do the following:

• Understand the challenges of managing stakeholder expectations

• Understand the consequences of not performing stakeholder expectations management activities explicitly on a project

• Identify various stakeholder expectations management activities and their positive or negative effect on project success

Subjects Covered

Client/customer expectations, change in stakeholder expectations over time, managing stakeholder expectations, stakeholder expectations, team morale, team organization

Setting

The setting is a networking project in the United States that has a short time frame (less than one year).

Key Concepts

• Managing stakeholder expectations is an ongoing process that needs to be done throughout the lifecycle of the project.

• Communication between all stakeholders is key to making sure that project objectives are met.

• Understanding stakeholder expectations with respect to scope, time, quality, and cost is mandatory.

Terminology

Scrum: An iterative, incremental process for developing any product or managing any work. It produces a potentially shippable set of functionality at the end of every iteration (Advanced Development Methods).

TCP: Transmission Control Protocol (Cerf and Kahn 1974).

UDP: User Datagram Protocol (Postel 1980).

The Case

Scenario

It was late on Friday for Stephanie White, one of CyCorp’s most accomplished program managers. She was looking forward to a relaxing weekend, where she could escape with her family on board their 42-foot yacht, Destiny, from their home port of Bellingham, Washington, to a pleasant weekend cruise in the San Juan islands. She knew, though, that, from a lot of different perspectives, this day was far from over. She was due to meet Blair Borman, her boss and the VP of engineering, in an hour or so to explain what was going on with one of her project teams. The meeting was to provide Borman with an update on the recent developments in the Gigaplex Project, a project everyone at CyCorp had hoped would provide happy customers, a good revenue source from follow-on projects, and enhanced visibility to the company and its services.

As she was getting ready for a meeting, which everyone knew would last longer than expected and involve a much heated discussion, she tried to recollect in her mind the events of the past few months that got them this far. Fresh in her mind were the details she heard from Amit Gupta, the Gigaplex team lead about issues the team was having with its client. She struggled in pinpointing the underlying cause for all of this and in determining how to resolve the situation. Borman would certainly want recommendations, and she had none.

Background

A few months before, a request came from Julian Chen, a former employee of CyCorp and now a software engineer at Gigaplex. Through a discussion over lunch with one of his former colleagues at CyCorp, Julian discussed the idea for a collaborative new project between CyCorp and Gigaplex. Amit Gupta, a team lead at CyCorp and the person to whom Julian spoke, asked for more information to present to management for review. It appeared that Gigaplex was having a hard time moving large volumes of data over the Internet using Transmission Control Protocol (TCP) in a way that provided both performance and reliability. To address the company’s need, Gigaplex was looking to enhance the performance of existing communication protocols, other than TCP, while maintaining their reliability and to then embed them in an open source library used by Gigaplex internally for various file-transferring applications. Amit, from CyCorp, recalled:

Julian had a lot of ideas, but it was clear that if we decided to collaborate on this project, he was going to leave it up to us to choose which protocol we should implement. From the short presentation he gave me, I thought we could end up with a project that would have a business impact and that would be technically challenging as well.

Although CyCorp was still growing as a company, its management was adamant about using a structured approach to project selection that included issues of scheduling, scope, client involvement, and expertise. Technical management had been trained in formal processes and software engineering best practices and was trying to get the software development teams to practice these concepts and understand their value for project success.

From various perspectives, the Gigaplex Project was very appealing. If successful, CyCorp could use Gigaplex as a good reference to get its name out there as a company that helped solve a major problem faced by one of the industry’s giants. Despite that, some people at CyCorp couldn’t help but wonder why a company the size and magnitude of Gigaplex would be courting a relatively small software development house such as CyCorp, which is located so far away in Seattle, on a project that was this important. Julian, from Gigaplex, recalled:

At the time, Gigaplex was busy doing a lot of new product development. Company management usually pushed our internal needs for projects like these aside to take second chair to projects involving products that the market wanted. Gigaplex employees were each expected to help innovate company processes and protocols, which was how I got to think about solving our data transfer issues. Since I didn’t have time to drop my other ongoing projects and because no one at the company minded that we look for outside assistance, I turned to CyCorp. From my experiences there, I’ve always remembered the CyCorp people for their hard work and technical expertise. I had my solution in mind but was not going to force it onto them. I was really looking for an interesting exchange of ideas as well as a deeper investigation of how to tackle this challenge, perhaps from a different perspective.

White, who was part of the decision-making group at CyCorp for evaluating the Gigaplex Project, along with Borman and a few others, seemed very interested in using this opportunity to help give CyCorp people a glimpse into a large company’s work culture, processes, and product development. White remembered that another program manager stated in one of the discussions, “It would be nice to have the opportunity to do a great job on a real project for Gigaplex.”

After a short evaluation process, CyCorp decided that the project should go forward without further delay. Borman, knowing the importance of the project, handed it off to White, who was then tasked with putting a team together to get started as soon as possible. White didn’t have much time and was therefore forced to pick people who might not have worked together before. Borman asked her to keep him apprised of how things were going on a regular basis. It was important for Borman that this project be managed according to stakeholder expectations to enable future collaborations with Gigaplex. He also wasn’t about to lose the opportunity to highlight the importance of his division in the eyes of the other C-level executives at CyCorp.

Knowing this, White decided to staff the team with five very qualified engineers, two of whom had worked with Julian in the past while he was an employee at CyCorp. Figure 9-2 illustrates the composition of the project team. Being pressured by both Borman and Julian to get things moving, White didn’t have much time to assemble her team. Therefore, she chose a group of five team members who were very diverse in their personal styles, experience levels, and cultural backgrounds. She hoped that they would complement each other from a skills and qualifications perspective. The five included Amit Gupta, Patrick Adamson, James Famosa, Sathviha Jain, and Jin-Lee Han.

Figure 9-2: Gigaplex Project team

Gupta, who was a native of India, was tasked with the role of team lead and project manager. His background was in embedded systems, and he was experienced in large-scale implementation projects. He had experience in leading teams, and he was one of the people who had experience working with Julian in the past. He recalled:

To me, Julian was a client who was both very passionate and also a real hands-on developer. Unlike conventional software development (which looks only at delivering a solution successfully), his approach was aggressive (trial and error including failures). Since he wanted to build something groundbreaking, most of his ideas regarding technology were the result of his aggressive approach.

Patrick Adamson, the youngest guy on the team, was mostly quiet and shy but had an everlasting smile on his face any time someone asked him a question. Adamson used to work for Motorola on its telephony protocol stack and was familiar, at least at some level, with part of the issues Julian raised. James Famosa, another member of the team, was a native of Cuba who immigrated to the United States about nine years earlier and had spent the last five to six years working for a software company in Miami. He assumed the role of the software architect on the team. He was also the most experienced engineer on the team if one looked at it strictly from a perspective of the number of years of experience. The two others on the team were Sathviha Jain, another native of India who brought with her six years of experience working at Tata Consultancy Services (TCS), and Jin-Lee Han, a Korean who came to the United States to follow his wife who was doing her PhD at the University of Washington in marine biology.

Gigaplex Systems

Founded in 1998, Gigaplex Systems was an industry leader in content aggregation, content indexing, and search optimization. The company employed close to 4,000 engineers and business professionals (marketing, sales, and customer support) in offices all over the world with a large portion located in Silicon Valley. The company continuously looked for more ways to make content available to users anytime anywhere, at literally a tip of a finger. The company traditionally made its money from drawing users to its search pages, thereby creating a critical mass of viewers so that Gigaplex could generate revenue by selling advertising on its web pages. Other sources of revenue included paid subscriptions for provided services, which included access to its sophisticated search algorithms, search optimization for small businesses, and content organization/indexing.

The company’s culture was very technical in nature with people hired directly from top computer science programs at Carnegie Mellon, Stanford, MIT, and Berkeley and paid well. Despite its large work force, the company did not maintain or enforce strict rules and regulations related to the process of software development. Projects were free to choose how to conduct their internal business in gathering requirements, choice of life cycle, planning and tracking, and even customer management. Since most of the company’s projects were internal in nature, there was a certain project management know-how that was shared between people; however, for the most part, the free spirit of going where “no man has gone before” seemed to prevail.

One interesting aspect of the company’s internal way of doing things was the emphasis on having projects be secretive in nature, with people in various parts of the company typically being unaware of what others, even those in the cubicles next to them, were really doing. This mysterious, hush-hush mentality was part of what drew people to Gigaplex, but it also made daily operations a little more complex because issues of communication, coordination, and transparency had become an overhead.

Wrapping Your Hands Around the Project

Gigaplex was using an open source library, called NetCom5, that supported peer-to-peer communication over a wide number of network configurations, including firewalls and Network Address Translations (NATs). To be able to go through firewalls, NetCom5 used a protocol based on User Datagram Protocol (UDP), which had a reliability mechanism—similar to TCP—embedded in the data section of the UDP messages. This protocol, dubbed Pseudo TCP, was faster than TCP but not as reliable. One of the project’s objectives was to create an improved version, also based on UDP, which ideally would be faster than TCP for file transfers. The team decided to call this new protocol RUDP, where R stood for reliable. RUDP was not going to replace Pseudo TCP but was going to be part of NetCom5 library as another option.

A crucial part of the project was testing the reliability and performance of the new protocol. To accomplish this, the team needed to build a test suite that could automatically execute test cases using different parameters simulating different network conditions. One of the main objectives of the test suite was to evaluate the RUDP protocol based on its correctness (the protocol does what is expected, such as transfer a file) and its reliability (the protocol also works under adverse network conditions). In addition, the test suite was to measure the performance of the RUDP protocol by benchmarking it against Pseudo TCP and TCP (where appropriate). The client’s goals were simple: to allow all Gigaplex applications using NetCom5 to transfer files using the implementation of the new protocol, thereby improving the performance and efficiency with respect to bandwidth of Gigaplex’s file transfers within the organization.

As the project unfolded, Gupta set clear parameters for what his team needed to do. His main objectives were to implement the RUDP protocol, develop a test suite to test it thoroughly, and integrate it into the existing NetCom5 library. As the Netcom5 library was implemented in C++, the RUDP protocol had to be implemented using the same language. To make sure his team was able to achieve all of these objectives, he sat down with Julian (client) and Patrick Adamson, the “people person” on the team and the appointed client liaison, to define a set of responsibilities between them. Specifically, these responsibilities were the following:

Team Responsibilities

• Implement RUDP.

• Test the reliability and performance of RUDP.

• Merge RUDP into NetCom5.

• Keep the customer informed of the status of the project on a biweekly basis.

Client Responsibilities

• Keep team informed of any relevant project issues and their effect on the project.

• Be responsive to team’s requests for meetings or additional information.

• Be willing to negotiate with team any changes to the project’s requirements, based on the magnitude of the impact on the development effort.

Project Discoveries

To make effective use of his resources, Gupta split his team into two main task forces: the first included Patrick Adamson and James Famosa, and the second included Sathviha Jain and Jin-Lee Han. He tasked Adamson and Famosa with investigating existing networking protocols, including TCP and some of its variants (TCP Reno, Vegas, TCP Taho), Pseudo TCP, UDP, and the required RUDP. Gupta wanted to understand the differences and similarities in how issues of reliability, performance, and adaptability to existing network conditions impacted design choices in implementation. Getting a good handle on the various mechanisms the protocols employed, from loss detection to adjustable transmission rate, was part of the investigation. He then tasked the other part of his team with getting a clearer insight into the testing aspect of the project and the corresponding test suite. Although none of his team members (other than Adamson) had prior experience with networking protocols, it seemed that Famosa and Adamson spent quite some time digging into the mechanics involved with issues of reliability and performance. They compared the different protocols and even went to see Prof. Steven Row, who was one of the engineering professors at the University of Washington in Seattle whose research area was network protocols. Famosa remembered:

We made a lot of progress in our understanding of TCP during the last few weeks, and we’re now trying to understand FAST TCP, which is pretty much what Julian wants. Our goal, I think, should be understanding the protocol that Julian wants. The rest is easy. Prof. Row gave us a lot of reading materials. The situation is not simple. TCP was carefully designed, and that’s one of the reasons why it has been so successful. Creating protocols that are faster and as reliable as TCP is not a trivial task and is probably the topic of some PhD thesis at Caltech and other top schools. This topic for me was fascinating since it dealt with improving the foundations of the Internet. There is some math and creativity involved, which makes it even more of a challenge.

While the team members were taking their time being thorough in understanding the issues and how to address them, their interaction with their client Julian, who was already becoming impatient at not seeing much progress in terms of actual deliverables, was not going as expected. Sathviha recalled:

Julian was becoming impatient with us. He kept telling us that we should have been further along than we were and that coding a simple reliable UDP protocol was something he could do in his sleep. In fact, it seemed like he was testing us and not giving us the full picture for some reason we couldn’t put our fingers on.

The team members tried to get the most out of their interactions with Julian by using two mechanisms. The first was by directing the conversation to focus on specific questions for which they needed answers and that were communicated in writing to Julian prior to the meeting. The second was by fielding some questions on Pseudo TCP and existing NetCom5 issues to Brian Sparrow, the person at Gigaplex who wrote the Pseudo TCP code and integrated it into the library.

The team members also struggled internally in wrapping their hands around the various problems and in moving forward cohesively at a more adequate pace. The team did not seem to gel, and the different personalities on the team made joint decision making a difficult task. The iterative nature of the process that the team was using (Scrum) required trust and agility, two qualities the team, at least at that point in time, did not really possess. To further complicate things, sometime close to the Christmas break, there was a specific incident that made the team members feel a little uncomfortable with their client and his approach to the whole project. Gupta remembered:

It was a Friday afternoon, and we were having one of our regular client meetings. Julian was late (as usual), and we were discussing the items on the agenda when he walked in the door. We were going to start by addressing our list of questions, but Julian seemed irritated and claimed that we were wasting his time with questions that he had already answered. We knew Julian was hard to understand as it was, being a non-native English speaker with a heavy Taiwanese accent. Our problem had always been that his answers were vague and did not provide us with the specifics we needed to develop the solution. He could never really tell us what he meant in measurable terms, so we knew that meeting his expectations was going to be difficult. Julian kept pushing to have us commit to deliverables. He said that we were wasting time and that only by coding would we have enough insight into what we needed to do. When we claimed that our research has so far shown that creating a more reliable and faster TCP was probably unlikely, he claimed to have done this already a few months ago but said he couldn’t give us the code because of company nondisclosure issues.

The team members left the meeting a little shaken up. They weren’t sure what had just happened, but it certainly seemed that something was wrong. Was Julian really interested in this project? Was he just testing them to see what they could do? If he had already implemented the protocol, why not just incorporate it into NetCom5 and be done with it? They seemed to have been more questions than answers after that particular meeting than any one of them could answer.

Making Decisions

In the following weeks, Gupta directed his team to investigate whether creating a more reliable UDP was really as difficult as the experts had told them. Ongoing attempts to obtain Julian’s code, which he claimed would solve the puzzle, yielded no positive results. Julian was willing to share with the team his design for the protocol that he suggested they follow. The team tried to emulate his design in their own implementation of the network protocol, which they dubbed JUDP, with J standing for Julian. The team was bothered because some of the basic business drivers for this project no longer made sense in light of the experiments they had run and the data they had collected.

Reviewing Julian’s design, the team found that it was trying to improve on the Pseudo TCP algorithm in which there is network latency, typically because an out-of-order packet is received. Julian wanted to address that problem in a more fundamental way through the algorithm. His approach was to use a packet-based protocol, using acknowledgment types and a new property of window size adjustment based on packet round-trip time (RTT). The team couldn’t figure out which specific scenario this would help, a question Julian wouldn’t answer. Assuming there was something wrong with the existing Pseudo TCP algorithm that Brian Sparrow had already implemented and integrated into NetCom5, the team wondered whether there could be another existing TCP implementation that was already customized for this scenario, much like FAST TCP, which was for high-gigabit networks.

The team struggled to understand Gigaplex’s business driver for having a new protocol integrated with NetCom5. Was it slightly improved file transfer? What was the intended benefit? It seemed that answering this question would certainly help the team members better focus their work, but yet again, this was another dead end.

Gupta shared his thoughts with White on how the project was going. He produced a tracking chart that his team was using on a weekly basis to capture team-based parameters (see Figure 9-3).

Figure 9-3: Team-based parameters for tracking project

Gupta explained:

Stephanie, we use this chart on a weekly basis to capture parameters we feel are important for team cohesion, productivity and process, and internal and external communications. As you can see, things have not gone too well aside from process maturity. It’s starting to impact the team, and I’m not sure what to do. I was hoping you and I could explore this further and see how to get the project back on track.

Because her meeting with Borman was to be in a half hour, White did not have time to analyze the data, though the chart intrigued her. She was particularly interested in the specific metrics the team was using to quantify the team aspects being tracked. She told Gupta that they could explore this further after the weekend and that she needed some time to think about it and come up with ideas.

Case Problem

Stephanie White, a program manager at CyCorp, has a software project team that currently is uncertain about what to do next to satisfy the client Julian from Gigaplex. The team members are frustrated in their efforts to satisfy Julian. The team’s perception of its own morale, ability to manage the client, and organization is declining as the project goes forward in time. Wondering why they were tasked with implementing a protocol that supposedly has already been implemented by the client, the team members now question the original project objectives.

Stephanie must decide what to tell her boss Blair Borman, the VP of engineering, about the team’s situation. She thinks that she will need to explain the underlying cause for this situation and to recommend a solution for how the team should proceed. She has not had time to reflect upon what Amit Gupta, the project manager, recently told her about the team’s problems with the client and about the team’s perception of its current status.

What should she say to her boss at the meeting, which is to be held soon?

Case Analysis

Analysis Activity

Analysis Background

(P) Problem: Stephanie has the immediate problem of deciding what to tell her boss about the Gigaplex Project team’s situation. Stephanie also thinks that she should determine the underlying cause for the team’s current problems and that she should provide a recommendation for how the team should proceed.

(E) Experience: Stephanie is an accomplished program manager. Program managers usually manage a collection of projects whose objectives contribute to business and program-level objectives.

(A) Assumptions:

Stephanie’s assumptions follow:

• There is an underlying reason for why the Gigaplex Project team is having problems with the client, though Stephanie has not yet determined this reason.

• At the next meeting, her boss will expect her to provide a recommendation for how the team should handle its problems.

• The diversity of skills, knowledge, experience, personality, and cultural styles among the Gigaplex Project team members would enable the team to be able to execute the project successfully. (She implicitly had assumed that this diversity would not prevent the team from working well together.)

The team’s assumptions follow:

• There is a solution to the problem of implementing a communications protocol that can satisfy the requirements.

• The client would allow the team flexibility in determining the best solution.

(K) Knowledge: The following is an outline of what Stephanie knows about the CyCorp environment and project team as well as about the client Julian and the environment at his company Gigaplex. (You can assume that Gupta gave Stephanie this information, provided to you in the case study.)

• Environment/fact: The Gigaplex Project is important to CyCorp’s upper-level management because of the opportunity that the project has to enhance the company’s reputation, to promote future business with industry leader Gigaplex, and to develop the staff’s awareness of how a large company operates.

• Environment/fact: Amit Gupta, the team lead and project manager, worked with the client Julian in the past and has experience in leading teams.

• Environment/fact: The CyCorp team members are diverse in their cultural backgrounds, experience levels, knowledge and skills, and personal styles.

• Fact: The team members are not working together effectively. They have problems making decisions as a team.

• Fact: The Gigaplex Project team thinks that the objective for the project is to implement a communication protocol that enables file transfers over the Internet that are faster while being just as reliable as those possible when using the TCP protocol. The implementation is to be based on the modification of an existing protocol such as UDP.

• Fact: In a meeting with the client Julian and the CyCorp client representative Patrick Adamson, Gupta clearly outlined the responsibilities for the team and for the client. The client is aware of and did not disagree with these responsibilities.

• Fact: The team has researched existing communication protocols, has implemented Julian’s design for a communication protocol that is a modification of UDP, has tested the implementation, and has found issues regarding the ability of the implementation to satisfy the expected performance or reliability. Finding a solution to the protocol implementation problem has turned out to be very difficult.

• Environment: The Gigaplex company culture rewards technical innovation, but also fosters secrecy and information hiding among its staff. Gigaplex engineers are bright, well educated, and highly skilled.

• Environment/fact: The team has found it difficult to work with Julian.

• The team has difficulty understanding what Julian says. Julian’s first language is not English, and he has a heavy accent.

• Julian has refused to answer some of the team’s questions and has made comments that have demoralized the team.

• Julian has pushed the team to go directly to code to determine the solution.

• At the beginning of the project, Julian said that he would not push the team to follow his ideas for the solution but would welcome an exploration of solutions. He now insists that the solution involves an implementation of his own design, says that the solution is simple to code, and claims that he has already implemented his protocol.

• Fact: The team questions why it was tasked to build an implementation that was supposedly already done by the client. The team questions the client’s reason for the project.

Solution: The case study ends with Stephanie not having time to analyze the underlying cause of the Gigaplex Project team’s problems. She is not yet prepared to pose a solution to these problems. The analysis questions will challenge you to think about alternative solutions to the team’s problems. The case study purposely does not discuss what Stephanie actually considered telling her boss at the upcoming meeting. This is left for you to analyze.

Assumed Risk: There are no assumed risks yet since Stephanie has not considered alternative solutions or decisions for her immediate problem or for the ongoing team situation.

Analysis Questions

1. After reading the case study and the analysis background information, what do you think is the primary problem that the Gigaplex Project team must solve? What other issues does the team need to resolve?

For questions 2–6, specifically consider the problems related to managing the expectations of the Gigaplex client Julian.

2. What are the exact problems that the team is having in working with the client and in satisfying his expectations?

3. Describe what you think are the underlying reasons for the problems that the team is having in dealing with the client.

4. What characteristics of the client do you think contribute to the client management problems? In what way do these characteristics influence the interactions between the team and the client?

5. What characteristics of the team do you think contribute to the client management problems? In what way do these characteristics influence the interactions between the team and the client?

6. What alternative solutions do you have for how the team should proceed to better manage the expectations of the client? What risks, if any, are associated with these solutions?

7. What suggestions do you have for how the team can resolve internal issues so that the team members can work together more effectively? What risks, if any, are associated with these suggestions?

8. What alternative approaches does Stephanie have for reporting the Gigaplex Project team situation to her boss at the next meeting? What risks are associated with each approach?

Discussion

The Gigaplex Project team has a problem in managing the expectations of the client Julian. More precisely, Julian has expressed his dissatisfaction that the team is not further along in implementing the solution. The client says that he thinks the solution is simple and that he knows this because he has already implemented it. The team does not know what to do next to find the solution or to satisfy Julian. If Julian has already implemented a solution to the problem, the team questions the purpose for the project. In addition, the team is having problems working together effectively and is demoralized, a topic left for your analysis.

As discussed in the chapter context, managing stakeholder expectations involves setting, monitoring, and influencing stakeholder expectations. In addition, stakeholders are not likely to be satisfied if their perceptions are less than their expectations. Julian may not be satisfied because his perception of what the project team has done is less in some way than what he expected the project team to do. You might start by trying to understand how Julian’s expectations may have changed over the project. You may detect ways in which the project team could have been more effective in setting Julian’s expectations at the beginning of the project as well as in monitoring and influencing them as the project progressed.

The project objective, as stated in Gupta’s outline of responsibilities for the team, was to implement, test, and integrate a reliable communications protocol that would be based upon an existing protocol. At the beginning of the project, the team thought that it would have flexibility in determining the solution. Julian expressed a similar expectation when saying that he was not going to force his own ideas about the solution onto the team. The client and the team seemed to have similar expectations that the team would explore and develop its own solution.

So, what happened? Why did Julian push an implementation of his own design as the solution, and why did he do this if he had already implemented the solution? Julian was impatient when the team did not arrive more quickly at a solution in code. Julian seemed to have expectations about the process for how the team would determine the solution and about how quickly it would find the solution. We do not know whether Julian had these expectations at the beginning of the project.

When Julian saw the team struggle in finding a solution, his expectations regarding what the team should do probably changed. He may have welcomed the idea of exploring alternative solutions at the beginning of the project and then became unhappy when the exploration did not quickly yield an implemented solution. Julian now may be pushing an implementation of his own design because the team has not found another one that satisfies the requirements. He may think that by telling the team he has already implemented the solution, the team will work harder. On the other hand, Julian may want to compare the team’s implementation of his design with his own implementation (if one exists) and for the stated reason of nondisclosure be unwilling to allow the team to use his implementation for this comparison.

How could the team have managed Julian’s expectations in a better way? An issue from the beginning of the project has been the assumption, not fact, that a satisfactory solution could be found and implemented. There was a risk that Julian would be unsatisfied if a solution was not found in a timely manner. The team could have mitigated this risk by working with the client to specify and agree upon the process by which the team would determine whether a viable solution exists. Likewise, the team and client would have needed to agree upon measurable criteria for determining the viability of a solution. The main objective for this slightly different project would have been to determine the feasibility of a solution rather than to implement and integrate a solution, which could have been an add-on to the original project.

What should the team do now? One approach, in line with the team’s responsibility to report status, is for the team to explain clearly, objectively, and unemotionally to Julian what the team has done, what the results show, and what the team recommends should be done next in the project. For instance, the team might recommend that it help Julian define and prioritize communication scenarios that would clarify the performance and reliability requirements. The team would use these scenarios to determine whether their current implementation satisfies these more specific requirements and possibly to compare their implementation to the implementation that Julian created. The objective would be to determine whether the current implementation will be acceptable, possibly with some modification. Alternatively, the team might recommend that in the absence of criteria to more conclusively test the current implementation, it would be best to end the project with the current results.

Likewise, the team could try to manage Julian’s perception of what has been accomplished. The team did develop and test an implementation of RUDP that is based upon Julian’s design, which is what Julian eventually said that the team should do. The team could explain why the implementation supports Julian’s design. The team could then discuss what it knows about the pros and cons of the current implementation and ask Julian what he would like to do with this information. At this point, the team might offer one of the recommendations discussed previously.

It is clear that the team needs to communicate openly and objectively with Julian about its concerns. The team could explain how it has satisfied its responsibilities and ask Julian to satisfy his responsibility to provide them with requested information and to be willing to negotiate any changes to the project requirements that are needed in light of the time and effort required to accomplish them. Since the team is uncertain of Julian’s expectations for the project, there is a risk that Julian will be unreceptive to the team’s recommendation, but the team will not increase this risk by explaining what it accomplished in terms of its outlined responsibilities. If Julian is unwilling to listen to the team’s concerns, to consider the facts, and to reasonably determine the direction in which the project should proceed, then the team probably has little hope of influencing Julian’s perceptions or expectations. Closing the project may be the best solution in this case, regardless of the impact on Julian’s view of CyCorp. Effective policies for working with clients are based on objectivity, honesty, transparency, and facts, especially when dealing with difficult or dissatisfied clients.

Since Stephanie does not thoroughly understand the team’s problems, the best that she can reasonably do at this time is to brief her boss on what she knows about the team’s situation and to recommend that she look into the situation in more detail and report back in the near future. Considering the corporate importance of the Gigaplex Project, Stephanie also might solicit her boss’s advice on how he would like for her to proceed. The first approach introduces little risk since Stephanie does need more time to look into the problem. Asking for her boss’s advice may be a double-edged sword. While Stephanie would convey her understanding of the client’s importance, she also inadvertently might make her boss wonder whether she has the experience and confidence to manage a team that must deal with a difficult client. Stephanie could influence her boss’s perception by first briefly and confidently explaining what she plans to do to learn more about the team’s situation. She could say that because of the importance of the client she would like to know whether her boss has any particular directives regarding how she handles the situation.

Conclusions

In this case study, the client’s expectations changed as the project progressed because the client did not see evidence of a software implementation as quickly as he expected. The change in the client’s expectations concerned the process by which the client expected the product team to determine a viable solution. The team became aware of the client’s expectations regarding its process when the client insisted that the team should solve the problem by constructing an implementation of his own design. This happened after the team had spent significant time studying existing communication protocols to determine their potential use in the solution. Later when the team had problems developing an implementation that would satisfy the requirements for performance and reliability, the client said that he had already implemented a solution based on his design that was simple to do. The team then questioned the client’s purpose for the project.

From these facts, you can conclude that the team was not effective in managing the client’s expectations. At the beginning of the project, the team did not address the risk associated with the assumption that a satisfactory software implementation based upon a modification of the UDP protocol was feasible. The team did not discuss this risk with the client and thereby missed the opportunity to set the client’s expectation for how the project should proceed if the planned solution was found not to be feasible. The team also did not set the client’s expectation for the process that it would use to explore alternative solutions and for the importance of studying existing communication protocols to determine their potential for use in the solution.

The client did not satisfy his responsibilities to provide requested information in a timely manner and to inform the team of project-related issues. Communications between the client and team were not transparent and complete. Trust between the client and the team decreased as the project progressed. The team questioned the client’s motives for the project. The client’s perception of the team’s accomplishments may not match reality. The team still has the opportunity to correct the client’s perception as well as to influence the client’s expectations and satisfaction regarding the value of the project. The team will need to explain the facts in an objective and unemotional way to the client and to provide options that would require the client to make transparent exactly what he originally wanted to accomplish with the project and what he would like to do now. The state of the ongoing communications will likely help make or break this project.

Key Ideas to Remember

• Stakeholder expectations concern process as well as product.

• Communications, transparency, and trust are critical in managing stakeholder expectations.

• Stakeholder expectations can change as a project progresses.

• Managing perception is part of managing stakeholder expectations.

Case Study: Tough Sell at Henkel Labs

Directions

When reading this case study, focus on the need to manage stakeholder expectations at various levels in the organization, such as with peers, management, or subordinates. Try to identify the activities that help or undermine one’s ability to positively manage stakeholder expectations.

Case Summary

Description

Adam Stein, a manager at Henkel labs, which is a subsidiary of Henkel & Schöt, is trying to creatively collaborate with various project management offices within the company on multisite projects. In an attempt to generate more revenue for everyone involved, Adam sees opportunities in bidding for projects where one part of the company helps with development while other parts help with logistics, client or account management, and so on. Unfortunately, getting buy-in from the various stakeholders who are involved seems more challenging than it should be.

Case Study Objectives

After reading the case study, you will be able to do the following:

• Understand the challenges faced when attempting to manage stakeholder expectations

• Understand the consequences of not explicitly managing stakeholder expectations on a project

• Identify various activities in managing stakeholder expectations and their positive or negative effect on project success

Subjects Covered

Stakeholder expectation management, decision-making, offshore development, project management, communications, and negotiations

Setting

This case study takes place in the United States, Germany, Russia, South Korea, and Argentina. The company is a global software development company with overseas subsidiaries. The project has a short time frame (less than one year).

Terminology

PMO: Project management office

The Case

Scenario

Adam Stein had already written and erased six different drafts of the same e-mail to his boss at Henkel regarding the situation. It was very late at night, and he needed to get it done before he left for the day. He wasn’t exactly certain how to phrase the e-mail so that it wouldn’t sound too negative while sending a clear signal that whatever was transpiring was simply not working.

Trying to wrap up what he thought was a simple cooperative agreement, between the various Henkel offices, had proven to be a major challenge for the past eight months. It was bad enough that they were geographically dispersed with Adam in the United States and his colleagues José Luis Martinez in Argentina and Hilde Vandenberg in Germany, but on top of that, things were moving at a snail’s pace at best. The worst of it was that he, as a manager, couldn’t pinpoint the problem, determine who was behind it, or figure out how to get it fixed. He had his thoughts, though. As he went back to look at his screen and review what he had drafted, Adam sat back on his chair and tried to recall how this whole thing started.

Background

Henkel Labs (HL), where Adam had risen to division head about 12 months ago, was a relatively small (about 75 employees) subsidiary of Henkel & Schöt (H&S). H&S was a much larger software development company (more than 3,000 engineers) headquartered in Munich (Germany) with offices in Buenos Aires (Argentina), Moscow (Russia), Seoul (South Korea), and San José (California), as shown in Figure 9-4. In addition to overseeing research and development projects involving embedded systems development for various vertical markets in which Henkel was active, Adam was responsible for identifying and bringing more business into his division by scouring the market for other projects that were strategically aligned with H&S’ goals and initiatives. Adam’s boss, Joachim Ruddoff, was a quiet guy who was very pleased to lend a helping hand whenever needed but left Adam to handle day-to-day decision making. Although their relationship was an amicable one, Adam had heard from others at the company that Ruddoff was expecting him to perform in driving the division forward one way or another.

Figure 9-4: Henkel & Schöt (H&S) worldwide deployment and areas of specialty

Pulling Together for a Stronger Offering

About nine months before, when he was on a business trip to visit a client in Reno, Nevada, Adam got an interesting request for something he had never done before. While Henkel Labs was known for its development of custom-built embedded systems, the parent company, Henkel & Schöt, was engaged in other types of custom software development, some of which was sometimes quite different from that done by HL. This particular request, to convert a large financial system from an Oracle to an open source PostgreSQL database, involved systems that were unfamiliar to Adam. Not wanting to turn down the project until he fully investigated whether H&S could do it, he told the client he would get back to him regarding H&S’ ability to support the project.

Back at his office, Adam wondered whether this was a good business opportunity. On the one hand, he and his staff primarily were soliciting embedded software projects even though these tough economic times made it difficult to survive. On the other hand, there may be significant opportunity to solicit and support other types of business with existing HL clients by partnering with the parent company Henkel & Schöt. Adam did not know, from an experience perspective, whether HL could partner successfully with H&S in joint projects. HL’s role on such projects could be to provide some set of capabilities including, for example, project management, requirements elicitation, client liaison, and strategic account management. Adam decided, before jumping the gun, to touch base with Hilde Vandenberg, who was in charge of the project management office (PMO) at Henkel & Schöt’s headquarters in Munich (Germany). Adam recalled:

I was very excited at the opportunity to make things happen. I knew Hilde from before, when we both worked as junior engineers on development projects in the same H&S division in Germany. Despite her academic nature (Hilde worked for many years at the Fraunhofer Institute in Nürnberg), I knew she was going to listen. She had a good entrepreneurial mind on her shoulders and was knowledgeable about our business and financial needs.

In the coming weeks, Adam met with Hilde and her associate, Nicolas Stratti, a young chap from Milan who was very talkative and amiable with penetrating deep blue eyes. Hilde and Nicolas listened carefully to Adam’s proposal and were very interested in pursuing it further, but they want to proceed slowly at first to make sure they weren’t committing resources to things that weren’t possible. Hilde recalled:

Adam suggested a collaboration that on paper looked like a no-brainer. It seemed logical and made financial sense. Having our offices collaborate on projects in which some of the work might be done overseas while the client contact, account management, and even project oversight would be done locally, aligned with how things were done in today’s fast-paced environment. Nonetheless, I wanted to make sure, before we went any further, that some of my other project managers in the PMO bought in to the idea.

Nicolas worked with Adam to create a memorandum of understanding between the companies that explained the project in terms of the resources, responsibilities, and financial arrangements and that could be circulated to the various H&S offices that might possibly be interested in participating. Hilde asked Adam to meet with her key project managers in Moscow, Seoul, and Buenos Aires in order to achieve consensus on the viability of this project from a current tasking/resource allocation perspective.

Adam was very encouraged at the turn of events. Drafting the memorandum progressed better than Adam expected. Both Hilde and Nicolas helped Adam prepare a document that could lay the groundwork for a very fruitful collaboration. Upon returning to his office in San José, south of San Francisco, Adam told his boss Joachim Ruddoff about the ongoing developments. While Joachim outwardly tried to be optimistic and encouraging, he had reservations about this collaboration. Joachim thought:

This deal would be nice if we can get it. My knowledge of the different business units made me highly skeptical that anything would be decided, at least in the short term. Collaborative decision making across companies is not an easy task, and sometimes things can get stuck for months on end. As for Adam, he certainly was full of energy and a quick learner. His biggest drawback was that because of his optimistic nature, he would usually over promise things to clients and to management. Whether he could deliver on his promises was too soon to tell at this point, but I thought it was my responsibility to provide him some mentorship regarding the need to under promise and over deliver.

Adam worked on setting up a round of meetings, face-to-face wherever possible, with the various project managers at the locations that Hilde asked him to visit. If it was important to Hilde that they follow this process, he was going to stick to it and to prove to her, as well as everyone involved, that collaborative work across the company was not only possible but actually effective. He asked Nicolas’s support in explaining to these managers what they were doing so that it wouldn’t seem as if he was stepping on anyone’s toes.

Meetings, Meetings . . .

Adam sat down to draft an e-mail to Alexander Nikiski and Soo-Young Han requesting a meeting. He looked it over a few times, adjusting words here and there, before clicking the Send button. He had learned the importance of doing this from a painful accident that happened to him with an agitated client who got an e-mail he shouldn’t have seen. His e-mail read as follows:

Alexander/Soo-Young,

I am writing this note per a request from Hilde Vandenberg.

Henkel Labs, with its office in San José California, is interested in establishing a formal relationship with groups within Henkel & Schöt that will allow the company to represent and sell various expertise and to engage (time permitting) project resources from the various H&S offices worldwide to meet market needs/demand.

As part of my discussions with our parent company, Henkel & Schöt, Hilde was hoping to get some feedback from you as her senior project management officers regarding this proposition before committing to an umbrella agreement.

I was hoping to talk about this further, using our video teleconference system (unless you plan to be in the United States for other company business, in which case a face-to-face meeting is preferable). I know how busy you must be, but if you could spare 15 to 20 minutes of your time, I would greatly appreciate it.

Adam Stein, Henkel Labs

Head, Systems Development Division

As the days passed and while Adam waited for a meeting, he instructed two of his project managers to keep their eyes open and to see whether any of HL’s existing clients were interested in other projects on which the parent company, H&S, could bid. Adam knew that meeting and getting consensus from Hilde’s managers was going to take some time. He simply didn’t want to wait and was hoping that, by the time they had internally gotten things organized, they would have solicited some new projects that could benefit everyone.

Within a month or so, Adam was able to arrange meetings with Alexander Nikiski from Moscow (who headed the Russian project management office) and with Soo-Young Han from Seoul (who headed the South Korean project management office), both of whom were on a business trip to a client in the United States. They seemed willing to listen and to explore opportunities for collaboration. With each of them separately, Adam discussed the business proposition, high-level goals, and how collaboration would work. Adam mentioned that he would cover any internal expenses while promoting their business. The two of them seemed very interested in understanding the financial model to support the collaboration. The model that he and Nicolas had developed, a month or so before in Munich, involved a standard split across H&S regardless of which unit was involved in a project and depending on the role taken by a unit. They seemed more at ease when hearing that no one was to be left out or treated unfairly.

José Luis Martinez

José Luis Martinez, head of the Argentinean project management office, was a bit different from his counterparts. Adam had worked with him a few times in the past and had a lot of respect for his thoroughness and perfectionist nature. The downsides to these traits, in Adam’s opinion, were Martinez’s rigidness, lack of ability to make quick decisions, and lack of desire to take any risk in the process.

Recognizing that negotiating with Martinez would be different, Adam decided that he would need to take a different approach. So, Adam put together an e-mail that he thought would clarify his case and would present an opportunity that José Luis would not be able to refuse. Adam’s e-mail read as follows:

Dear José Luis,

I sat down with Hilde and Nicolas about two months ago to finalize what we think could be the terms for a Henkel Labs-Henkel&Schöt MOU to help HL solicit projects for the benefit of other global H&S offices (when they make sense financially to all sides). Hilde asked me to talk to some of the other H&S PMOs to get their perspective on what HL is offering as a value proposition. I've been doing this face to face with some of the folks.

I wanted to get your feedback on a recent opportunity that we are considering. In recent HL discussions with its clients in Latin America (Mexico, Panama, and Colombia), the clients expressed their interest in conversion projects. HL has no expertise with these types of projects.

The idea would be for us to work collaboratively by combining your expertise in conversion projects with our client management experience. We would conduct joint projects in the countries that I specified. When the HL-H&S agreement is signed, would working collaboratively on these specific projects be something that you might consider?

Adam

A day or so later, Adam received a copy of an e-mail that Nicolas sent to José. The e-mail stated the following:

From: Nicolas Stratti
Sent: Wednesday, February 09, 20-- 12:26 PM
To: José Luis Martinez
Cc: Hilde Vandenberg; Adam Stein; Joachim Ruddoff
Subject: Re: Henkel Labs – Henkel Schöt Project Agreement

José Luis,

Because any agreement will be between H&S and HL and because we need input from all of the project management offices that might potentially be involved, Hilde and I thought it wise to have Adam chat with other offices to assess interest and economics.

We can't frame an agreement until we understand the scope and the various level of involvement that our various offices might have, and because this is not an Argentina-only deal, we need input from a broader group. Adam's discussions with other subsidiaries at this point should have been presented as only for information gathering.

As to South America, I do think Adam has jumped the gun (just a bit), but I understand the need for him and HL to identify potential projects.

Once we have something (at the H&S level) that we think might work, the plan is to present it to the senior PMOs and then to the entire organization.

With that said, I suspect we are developing a straw-man that we can discuss (right, Adam/Joachim?), and I see no reason that the initial discussions on the straw-man term sheet can't be with you and Hilde.

Shall I arrange a meeting for us on this topic?

—NS

There seemed to be some reluctance from Martinez to go forward that Adam couldn’t explain. It might have something to do with Martinez’s personality or decision-making style. It might also be an ego thing, or it might be a real issue involving resource limitation. From Adam’s perspective, it was too early in the process and too difficult to tell. Nonetheless, Adam asked Hilde and Nicolas whether they wanted him to attend the meeting to clear the air and to contribute his thoughts on the matter.

As they were going back and forth in scheduling the meeting, Adam got a request for a video conference meeting with Martinez to go over things. Not wanting to refuse, Adam accepted but decided to bring along one of his most trusted project managers, Raúl Juan Ramirez, who was a native of Guadalajara (Mexico) and was intimately familiar with the types of projects that the Latin clients wanted but which HL could not support without H&S. Adam thought that having Raúl attend the meeting might be a great asset.

Adam’s primary objective for the meeting was to bring up the topic of sharing resources in a common way across company subsidiaries for joint project delivery. At the meeting, Martinez expressed a general interest in the idea, though he said he’d have to get more specifics on what Adam had in mind before he could say yes or no to anything suggested. Martinez indicated that two of the most important things for him in project selection would be maintaining the quality of service and making sure that his resources weren’t spent in a way that didn’t make financial sense. Adam acknowledged both of these points and said that when various opportunities became available, he would forward information about them to Martinez.

To keep Nicolas and Hilde in the loop, Adam sent them a note that summarized his impression of the meeting with Martinez. Adam’s note said the following:

Nicolas,

I met with José Luis regarding the HL/H&S deal. It was a pleasant conversation. We discussed potential offerings that we are already exploring in the system conversion project areas. It seemed that he was extremely receptive to it, which is why I plunged right in. I did not discuss numbers with him but wanted to let you know that he sees a lot of value from the relationship.

Martinez wanted to know what numbers we exchanged, and I told him to talk to you about them. He will talk to his people to get their thoughts on this as well.

Thx for the help,

Adam

In response, Adam received an e-mail that he didn’t expect from Nicolas. The e-mail read as follows:

Adam,

I really wish you had waited to discuss this with him until the meeting we already have scheduled. Although I am pleased to hear that he is receptive, you've now put me in the position of having to share numbers with him, without having the benefit of adjusting those numbers based on the meetings you are having and have had. You've also created an expectation that I will be available to meet with him in the near term, which is unfortunate because I'm busy with other things for the next few weeks. Worst of all, by not sharing with José Luis the draft document, you've created a divide (perceptual at least) between the HL position and the current thinking of the H&S/PMO administration.

Waiting until our meeting on March 19 really wouldn't have cost HL anything in terms of time, but it will probably cost me some cycles and some heartburn. As St. Augustine wrote, "Patience is the companion of wisdom."

If we're going to work as a team on this project, then I need to know to whom on my team you are talking and when you will be talking to them.

I'm disappointed in this turn of events.

Nicolas

Adam read the e-mail carefully and didn’t know whether he should respond. On the one hand, his relationship with Nicolas was something he wanted to preserve, but on the other hand, he didn’t feel he had done anything wrong. He decided that it was better to say something rather than to ignore the e-mail altogether, and so he replied:

Nicolas,

José Luis wanted to meet and talk about the specifics of what we were doing (or planning to do) in Latin America, and I couldn't just simply refuse. Our discussion started with the generic principles and then unexpectedly moved to the type of terms we would offer. I danced around the issue but was adamant in saying that no terms had been reached, finalized, or agreed upon. I emphasized that everything was in the negotiation stage. José Luis made it clear that he wants to be an active participant in the negotiations (something that you guys will have to manage).

I assure you that I did not give him the impression (or set the expectation) that you will have time for him before our March 19
meeting. I don't even know for a fact that he will try to contact you before the meeting. He impressed on me the need for him to be involved throughout the process because he thinks that his office is the biggest asset that H&S has (you and I already discussed his feeling about this).

Over the years, I've found José Luis to work in a way by which he slowly, sometimes painstakingly, though eventually comes around to a certain position. You have to chip away at why it's good for everyone and convey to him the logic of it many times over. I did not communicate any numbers to him. I merely said that we are still in the process of discussing things.

I don't want to get into interorganizational politics, but I understand the underlying powers at play. My suggestion would be that if you want to hold everything close to the chest, you can dance around the issues (or avoid a meeting) and be more specific on March 19.

All I wanted to do was to give you a head's up so that you're not surprised if JL does try to approach you. I don't think you need to share any draft document with him if you don't think that will help. You can (if you like) give him the general guidelines. These are not likely to change much anyhow if we want to strike a deal between everyone. Anything astoundingly different will lead to us not being able to market time/expertise anyhow.

The last thing we want to do, IMHO, is to slap something on him as a take-it-or-leave-it package on March 19. He doesn't do well in those situations. If anything, letting him get used to the general guidelines/numbers and mull over them is not a bad thing. If he explodes...well then, we don't need a March 19 meeting anyway, but I really don't think that he will.

Try not to get a major heartburn just yet. All in all, I don't foresee a major fallout (but I might be wrong). Still working for the same team, communicating, and updating. I am working on my ESP skills so that I don't have to waste airtime talking <smile>.

Apologies,

Adam

The meeting, which took place a week or two later with Adam and Martinez on video and the others in their Munich office, was a good one, at least from some perspectives. The meeting did not go into any specifics regarding a financial arrangement that would make everyone happy. There seemed to be a clear unwillingness on the part of Hilde and Nicolas to bring up numbers and to make things concrete. Hilde only appeared to want to discuss principles and how, from an operational perspective, such an arrangement would work out. At the end of the meeting, it was decided that both Adam and Nicolas would create a term-sheet draft for review (after revisiting the older draft they already had in place) and circulate it to both Hilde and José Luis. Once they had some consensus on the terms, they would draft a more final legally binding agreement to be signed by the participants.

Are We There Yet?

While on a trip to Cambridge, Massachusetts, to meet a client a week or two later, Adam put the finishing touches on the draft agreement and sent it to Nicolas. Nicolas asked for some modifications to the document and specifically mentioned that the draft would be more appealing if Adam could add some revenue sharing projections even if the numbers were merely rough estimates. The idea was not to commit to anything but rather to understand the financial benefit that this type of commitment would have for all participants. When these modifications were made, Adam sent the document off to Nicolas, Hilde, and Martinez and hoped to get a quick turnaround with their review. When two weeks went by and no reviews were received, Adam sent a note to Nicolas to see what was happening. He got the following short e-mail from Nicolas:

Adam, José Luis had to cancel our meeting. We are rescheduling. Hilde has been buried before leaving town to attend to some corporate business for all of next week. I've asked her to try to send you a response prior to her departure. She is still working on her e-mail even as I type this, so you may yet see something from her before she departs.

A week or so later, Adam pinged Nicolas again to see whether progress had been made. He received another disappointing note:

Adam,

We had to cancel our meeting again, as JL had a visitor from IBM. We're rescheduling.

Nicolas

In his disbelief that things were moving so slowly, Adam left a voicemail on Nicolas’s answering machine at work to see whether they could move ahead without José Luis. Nicolas sent back the following e-mail.

Adam, Hilde has yet to review the document, due to her hectic schedule. She is also counting on getting José Luis' buy-in. Trying to bypass or short-circuit him might have some short-term benefit but would be damaging in the long term. I will discuss the situation to see whether we can make some progress in my meeting with Hilde later this week and see what she thinks....

Adam was frustrated. He thought that he had done everything right, talked to the right people in the right order, and still seemed to be getting nowhere. In a recent conversation with his boss at the office, Ruddoff offered to help by calling Hilde directly himself to find out what was really happening. Adam told him that he thought he had things under control. But did he???

Case Problem

• Should Adam be doing anything else to meet the various stakeholders’ expectations?

• Should Adam call for upper-level intervention to move his venture forward for the good of the company?

• Is what Adam has seen so far in terms of interorganizational collaboration representative of what might happen in the future when a joint project is created?

• What should be the next move for Adam and for Hilde?

Case Analysis

Analysis Activity

Analysis Questions

1. What problems does Adam think he has?

2. What problems do you think Adam actually has in managing stakeholder expectations in his work to establish collaborative projects across H&S?

3. Explain what you think are the expectations of each of the following stakeholders for collaborative projects (product) and for how the foundation for these projects is laid (process): Joachim Ruddoff, Adam Stein, Hilde Vandenberg, Nicolas Stratti, and José Luis Martinez.

4. How do you think differences in personal style (such as approach to decision making or problem solving) as well as differences in business needs and priorities might be influencing the stakeholder expectations and perceptions?

5. Use the PEAK model to identify and analyze alternative solutions/decisions for how Adam might better manage the expectations of the stakeholders for his venture. Be certain to factor in the expectations, perceptions, and personal styles of the stakeholders.

6. What would you decide to do next if you were Adam? Explain your rationale.

7. What would you decide to do next if you were Hilde? Explain your rationale.