EMIS 7365 - Fall’19

Case Study 5: The Trophy Project

Kulandan Singh
(International Student)

To be reviewed by: - Prof. Dr Nand M. Singh

EMIS7365-2019Fall-Singh-Kulandan-Case5-19930715.
Table of Contents

1. SYNOPSIS ...................................................................................................................................1

2: CASE STUDY RESPONSES ......................................................................................................2

3. PROJECT BASELINES ..............................................................................................................4

4. VERIFICATION AND VALIDATION ...........................................................................................5

VALIDATION................................................................................................................................................... 5
VERIFICATION ............................................................................................................................................... 5

5. GEM (GENERAL MANAGEMENT PITFALLS) .........................................................................6

EMIS7365-2019Fall-Singh-Kulandan-Case5-19930715.
1. Synopsis

The Trophy Project was project that was contracted out by a customer to a company.
There was a project manager assigned to the project, with resources assigned to work
on the project. However, the project was always behind schedule due to work not being
completed as assigned, due to project resources working on other projects. Even
though the project manager had ownership and was responsible for the Trophy Project.

Project Manager did not have sufficient authority of control over people assigned to the
project who were reporting to and hence worked as per directions of the functional
manager. Six months into the project, the customer realized that the project was behind
schedule and tried to intervene and solve the project by bringing additional resources to
work on a project that would help identify issues on the project.

This project was not only unsuccessful but also diverted the focus of the project
manager from the Trophy Project that was behind schedule furthermore. There were
many things attempted to bring the project back on track, managing it more closely, the
customer having their representative onsite etc., however none of them helped as the
functional managers till did not provide the resources that were required for the project.
All this led to the project manager being blamed for the project debacle, being replaced
and the project being completed a year behind schedule with a cost overrun of forty
percent.

EMIS7365-2019Fall-Singh-Kulandan-Case5-19930715. Page 1 of 6
2: Case Study Responses

Question 1: Why did the project get into trouble?

Project success does not just depend on the performance of the project team. Success
or failure often depends on the contributions of top management, functional managers,
customers, suppliers (or vendors), contractors, and others. Following are the major
reason for delay in project maturity: -

1- Organizational Structure: The structure of the organization was also a problem.

The Trophy project depicts a dysfunctional matrix-type organization. This is so
because a matrix structure allows for sharing of resources by having individuals
from different functional units to work on a particular project. This can sometimes
be disadvantageous to the progress of the project when resources are not
properly prioritized. Reichart had no power of authority; his resources were
controlled by the functional managers. Reichart realized that functional managers
were charging direct labor time to his project but working on their own ‘pet’
projects. This shows that there was an ineffective Project Office. Management
never took Reichart’s complaints seriously. He had to write a report directly to
corporate and division staffs. He had inadequate staff to stay at the required
pace, let alone make up any time that had already been lost. Reichart was
denied additional staff. He no longer reported to the project office but directly to
the operations manager. It is evident that the organizational structure is shaky;
it’s like it’s not being observed.

2- Interpersonal skills: The project manager needs to establish clear expectations of

members of the project team so that everybody knows the importance of his or
her role in achieving the project objective. They go on to say that the project
manager has to involve the team in developing the project plan that shows which
people are assigned to which tasks and how those tasks fit together. Throughout
the project, the project manager will have to persuade and negotiate with the
customer, the project team, and the company’s upper management. Reichart
was given too much responsibility for a problematic project when he had little
experience of managing a project; he had been an Assistant Project Manager.
Because of his inexperience, Reichart was unable to articulate himself well,
hence lacked in problem solving skills. For instance, he failed to identify the
problems and call a problem-solving meeting as a matter of urgency but instead
waited for the request for him to write a progress report for him to voice his
concerns.

3- Reichart’s Leadership and Managerial abilities: Reichart leadership style needs

to be improved. He is confident and willing to take up challenges. But without
proper coaching and mentoring, chances of him growing in this organization are
limited. Reichart leadership style is more reactive than proactive. Reichart needs
to be more direct persuasive and probing as well in order to get things done.

EMIS7365-2019Fall-Singh-Kulandan-Case5-19930715. Page 2 of 6
 After careful examination of the root causes of the trophy project, we came to the
conclusion that the organizational structure and the behavioural strategy are the
major root causes of the project failure. The change is economic climate exert a
lot of pressure in business to be robust enough to ensure that the client in which
they serve are satisfied without compromising the human capital involved in
delivering services. This required a lot of creativity and integration of processes
and system to ensure efficiency and effectiveness.

Question 2: What mistakes did Reichart make?

Successful projects require a good project manager. It’s the responsibility of project
manager to deliver project on time, with high efficiency & effectiveness. Following are
the mistakes of Reichart: -

1- Lack of initiation: Reichart failed to identify the problems and call a problem-
solving meeting as a matter of urgency but instead waited for the request for him
to write a progress report for him to voice his concerns.
2- Lack of communication & leadership: Reichart didn’t established productive
communication with project support staff; functional manager. It can be clearly
seen that functional manager was not in control of Reichart and resulted delay in
project maturity.

Question 3: What could Reichart have done differently?

Reichart would have spoken to the project sponsor and the functional managers right at
the start and also during the project to ensure that the resources are working full time
and dedicatedly on the project. He would have weekly status review right from the
project start that would ensure that problems can be addressed as soon as they come
up rather than when they become big. If functional managers were unsupportive, he
would have approached the management help to make the resources available for the
project. All this would have helped increase the project visibility, highlight and address
issues proactively that could have led to better project execution.

Question 4: Did Reichart have support from a project sponsor?

Top management did not take any responsibility for the failure of the project, and line
managers did not take responsibility for the resources given to the project. Even after
the client requested that the division general manager and his staff visit the customer’s
plant to provide progress, the division general manager was not willing to be held
responsible and accountable, and thus sent the project manager alone with his
delegations (functional managers) to the client. There is not efficient utilization of
resources, as line managers have the resources working for them on their own pet
projects. There were not adequate resources and staff assigned to run the project.

EMIS7365-2019Fall-Singh-Kulandan-Case5-19930715. Page 3 of 6
3. Project Baselines

The project baseline is simply a version of the plan that is created once the plan is
stabilized: it’s the original plan plus all of the approved changes that occur throughout
the life of the project. The baseline for a project consists of the scope baseline, the cost
baseline, and the schedule baseline. These baselines will provide a way to measure the
project's performance and analyze a project’s value. During the planning phase of a
project, project managers must take care to describe the work and resources that will be
required to deliver the project and achieve the project goals. The result of the planning
phase is a baseline that includes your objectives, the project scope, the resources
needed to complete the project, the details about the cost involved, and the project
schedule.

The project baseline is what project managers use to determine the overall health of a
project. If a project is falling behind schedule, then using the project management
triangle, there will be an effect on the cost and/or scope. It also means there is a change
in the project baseline. Some changes are unavoidable; however, that means that
changes to the project baseline are necessary. Even if changes are made to the original
project baseline, the project manager must keep the initial project baseline to better
understand the issues.

Benefits of baseline: Project baselines are a necessary part of project management.

So, a project manager will probably build some project baseline no matter what.
However, when a project baseline is approved by all parties, it can be especially useful.
The approved project baseline provides many benefits to the current project as well as
future projects. One of the biggest benefits to an approved project baseline is the
improvement in estimating capabilities for the company. Approved project baselines,
past project baselines, and documentation of changing project baselines can improve
future baselines. Companies can use them to see which projects came under or over
the baseline. From there they can make necessary changes.

Revising Baseline: Most projects have changes to the schedule or scope of work.
While project managers try to avoid this, unforeseen circumstances happen which
cause changes. These changes can impact the project performance, resources, and
especially the baseline. When this happens, project managers must change the
baseline for the project. Because the way the current project is no longer matches the
scenario for the original baseline.

Baseline revisions should only take place if the appropriate change process must take
place. Project managers should only make changes to the baselines moving forward.
When project managers change the entire baseline to fit the current time frame, it
changes historical data. It also makes it more difficult to use old baselines and project
performance data to make better estimates. Changing the entire project baseline alters
the history of the agreement between trade contractors and general contractor and/or
owner.

EMIS7365-2019Fall-Singh-Kulandan-Case5-19930715. Page 4 of 6
4. Verification and Validation

Validation

Validation is about building the right thing. Validation process determines if you have
developed the correct product for the customers and whether it meets all of their needs
and requirements. Validation process checks whether the product specification is
fulfilling the customers’ needs or not.
Validation is a subjective process used to assess how well the product is fulfilling or will
fulfill customer requirements. Modeling, simulation, and the user evaluation are few
examples of the validation process.
For example, let us say that you are developing a cell phone for your customers. You
conducted the market research, collected the number of features to be included in the
cell phone, and then you started the production.
However, when the cell phone is launched in the market, it did not get the expected
response from the customers, and eventually, it failed.
Here, you would say that the product could not be validated because it failed to meet
the customers’ requirement and needs.

Verification

Verification is about building something correctly. Verification process determines if you

are correctly building the product as described in procedure manuals and all quality
assurance and quality control activities are being performed as they are supposed to
be.
Verification process checks that the product is being developed with all specifications
are appropriately applied, or in other words, you can say that the verification process
sees whether the product is meeting all documented specifications or not.
Verification is an objective process where product specifications and all quality
requirements are documented well enough so that they could be measured and
analyzed.
For example, let us say that you are developing a cell phone to be launched in the
market. You conducted the market research and then collected the number of
functionalities to be included in the cell phone. You design the procedures to be used to
build the product and specify the quality requirements for it after collecting the
requirements.
Now, the production process has been started. You will perform the inspection activities
to the process to make sure that everything is going according to plan.
Afterward, you would say that the product has been verified and is being developed as
planned.

EMIS7365-2019Fall-Singh-Kulandan-Case5-19930715. Page 5 of 6
5. GEM (General Management Pitfalls)

The project environment offers numerous opportunities for project managers and team
members to get into trouble. Common types of management pitfalls are:

1- Lack of self-control (knowing oneself): Knowing oneself, especially one’s

capabilities, strengths, and weaknesses, is the first step toward successful
project management. Too often, managers will assume that they are jacks-of-all-
trades, will “bite off more than they can chew,” and then find that insufficient time
exists for training additional personnel.
2- Activity traps: Activity traps result when the means become the end, rather than
the means to achieve the end. The most common activity traps are team
meetings, customer–technical interchange meetings, and the development of
special schedules and charts that cannot be used for customer reporting but are
used to inform upper-level management of project status. Sign-off documents are
another activity trap, and managers must evaluate whether all this paperwork is
worth the effort.
3- Managing versus doing: There often exists a very fine line between managing
and doing. As an example, consider a project manager who was asked by one of
his technical people to make a telephone call to assist him in solving a problem.
Simply making the phone call is doing work that should be done by the project
team members or even the functional manager. However, if the person being
called requires that someone in absolute authority be included in the
conversation, then this can be considered managing instead of doing. There are
several other cases where one must become a doer in order to be an effective
manager and command the loyalty and respect of subordinates.
4- People versus task skills: Another major pitfall is the decision to utilize either
people skills or task skills. Is it better to utilize subordinates with whom you can
obtain a good working relationship or to employ highly skilled people simply to
get the job done? Obviously, the project manager would like nothing better than
to have the best of both worlds, but this is not always possible.
5- Ineffective communications.

EMIS7365-2019Fall-Singh-Kulandan-Case5-19930715. Page 6 of 6