Case Analysis

Analysis Activity
(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

(C) Mariam Asad

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.

1
(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

(C) Mariam Asad

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. n The team has difficulty understanding
what Julian says. Julian’s first language is not English, and he has a heavy accent. n Julian has refused to
answer some of the team’s questions and has made comments that have demoralized the team. n Julian has
pushed the team to go directly to code to determine the solution. n 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 2
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

(C) Mariam Asad

decisions for her immediate problem or for the
ongoing team situation.

3
ANALYSIS QUESTION
• 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?

• 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?

(C) Mariam Asad

• 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?

4
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

(C) Mariam Asad

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. 5
• 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.

(C) Mariam Asad

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.

6
• 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.

(C) Mariam Asad

7
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

(C) Mariam Asad

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. 8
REFERENCES
• Advanced Development Methods, Inc. What is scrum? www.controlchaos.com/ about/ (accessed May
31, 2009). Ågerfalk, P. J. and B. Fitzgerald. 2006.

• Flexible and distributed software processes: Old petunias in new bowls. Communications of the
ACM 49(10): 26–34.

• Albrecht, A. J. 1979. Measuring application development productivity. Proceedings of the Joint

SHARE, GUIDE, and IBM Application Development Symposium, pp. 83–92, Oct. 14–17, Monterey,
CA.

• Alessandra, Tony and Michael J. O’Connor. 1998. The platinum rule: Discover the four basic
business personalities and how they can lead you to success. New York: Hachette Book Group-Grand
Central Publishing.

• ARCEP: L’Autorité de Régulation des Communications Régulation des Communications

Électroniques et des Postes. www.arcep.fr/ (accessed May 22, 2009). Use Google to translate the
page.

• Aronoff, Stan. 1989. Geographic information systems: A management perspective. Ottawa, Canada:
WDL Publications.

• ASME. What’s your communication style? www.asme.org/Jobs/Manage/Whats_

Communication_Style.cfm (accessed June 2, 2009).

• Atkins, D., M. Handel, J. Herbsleb, A. Mockus, D. Perry, and G. Wills. 2001. Global software
development: The Bell Labs collaboratory. Proceedings of the 23rd IEEE International Conference

(C) Mariam Asad

on Software Engineering, p. 0681b, May 12–19, Toronto, Canada.
www.cs.uoregon.edu/~datkins/papers/icse-collab.pdf (accessed May 22, 2009).

• Barbacci, M., M.H. Klein, T.A. Longstaff, and C.B. Weinstock. 1995. Quality attributes. Technical
Report CMU/SEI-95-TR-021. Pittsburgh, PA: Software Engineering Institute, Carnegie Mellon
University.

• Baritault, Alain. 2009. Stimulating FTTH investments in France. MuniWireless, April 9.

9
www.muniwireless.com/2009/04/09/stimulating-ftth-investments-in-france/ (accessed May 22, 2009).