14 Trouble Health System Case Analysis By Haoying Zhang To Dr. Kamyar Shahrooz Northeastern University Nov 20, 2017 Introduction With the exit of the former project manager, the team has failed to work together as planned which has resulted in lagging behind the preset schedule. The management and all other stakeholders within the company have expressed distaste about how the project is going on so far. Some of the factors that have contributed to this situation include inadequate staff- most of the team members are also working in other departments, misunderstanding between the architect and the database administrator and the rapidly changing user requirements which have made it hard for our programmers to follow a constant line of development. However, this project is necessary for the company and there is need to complete the tasks before our competitors launch their products and skew the market share in their favor.Team DynamicsPreview The team dynamics have been affected by various human, technical and interpersonal factors. The main players who have contributed heavily to the team dynamics include the architect, database administrator, former project manager and the programmers on the ground themselves. The technical aspects of the team, which have had profound effects include the introduction of a new programming language and the general structure of the company as is at the moment. The interpersonal factors have included the lack of or inadequate communication about the project progress among the team members themselves and the management in its entirety. Broad categories of the team dynamics include the following: The Architect and the Database Administrator These two individuals have had in-fights which have terribly derailed and demoralized our team. Their failure to agree on basic protocols in regard to how the database supports the vendor reports have made it hard to progress comfortably as it should ideally be. The former Project Manager The sudden exit of Peter has left a huge responsibility gap in the team. By far, he was the most experienced manager around: - with a massive experience gained from managing similar projects for a very long period of time. This has partially contributed to the kind of disarray that is being witnessed today among the team members. Legal Team The company lawyers have been unable to draft a policy document. This is because they were not given enough information about the project early enough. Interpersonal Factors Our project sponsor rightly stated that she was deeply disappointed in Peter’s actions of not soliciting for project team members on a full-time basis. The lack of communication for this critical component led to the current state whereby the team members are usually working in various departments within the company, hence unable to dedicate enough time to the project as is needed. The team has also failed to communicate with the concerned managers about the lack of c ...

1. 14
Trouble Health System Case Analysis
By
Haoying Zhang
To
Dr. Kamyar Shahrooz
Northeastern University
Nov 20, 2017
Introduction
With the exit of the former project manager, the team has failed
to work together as planned which has resulted in lagging
behind the preset schedule. The management and all other
stakeholders within the company have expressed distaste about
how the project is going on so far. Some of the factors that have
contributed to this situation include inadequate staff- most of
the team members are also working in other departments,
misunderstanding between the architect and the database
administrator and the rapidly changing user requirements which
have made it hard for our programmers to follow a constant line

2. of development. However, this project is necessary for the
company and there is need to complete the tasks before our
competitors launch their products and skew the market share in
their favor.Team DynamicsPreview
The team dynamics have been affected by various human,
technical and interpersonal factors. The main players who have
contributed heavily to the team dynamics include the architect,
database administrator, former project manager and the
programmers on the ground themselves. The technical aspects
of the team, which have had profound effects include the
introduction of a new programming language and the general
structure of the company as is at the moment. The interpersonal
factors have included the lack of or inadequate communication
about the project progress among the team members themselves
and the management in its entirety. Broad categories of the team
dynamics include the following:
The Architect and the Database Administrator
These two individuals have had in-fights which have terribly
derailed and demoralized our team. Their failure to agree on
basic protocols in regard to how the database supports the
vendor reports have made it hard to progress comfortably as it
should ideally be.
The former Project Manager
The sudden exit of Peter has left a huge responsibility gap in
the team. By far, he was the most experienced manager around:
- with a massive experience gained from managing similar
projects for a very long period of time. This has partially
contributed to the kind of disarray that is being witnessed today
among the team members.
Legal Team
The company lawyers have been unable to draft a policy
document. This is because they were not given enough

3. information about the project early enough.
Interpersonal Factors
Our project sponsor rightly stated that she was deeply
disappointed in Peter’s actions of not soliciting for project team
members on a full-time basis. The lack of communication for
this critical component led to the current state whereby the team
members are usually working in various departments within the
company, hence unable to dedicate enough time to the project as
is needed. The team has also failed to communicate with the
concerned managers about the lack of clear cut trajectory and
plan for the project.
Miscellaneous Dynamics
The team has experienced various challenges ranging from the
absence of a concrete risk plan, conflict about roles within the
team, over budgeting and an absence of a clear testing strategy
among other factors.
Stage
The team is currently in the performing stage. This is where all
action is supposed to be happening and is actually happening to
a great extent (Baughman, 2008). Most of the active team
processes are happening at this particular point. They include
the continuous module and unit testing, responding to various
comments and opinions from the end users and writing code for
some components of the system. Although this is the stage
whereby relationships should be flourishing, the working
statuses among the team members and the relationship between
the architect and database administrator has not been as
productive as it was initially meant.Skill Deficiency
Our team members have a background in Java with no skill in
MS- oriented languages like the one being used currently. This
has led to a loss in time since our developers need to consult
with the product vendors on various aspects of the language
being used. In addition, our developers have occasionally

4. developed poorly performing systems since they are unable to
optimize the code as they should in this particular
environment.Recommended Training
Due to the skill deficiency that has been noted, I recommend the
following:
· Hiring of a VB Studio specialist and programmer in the team
· Subscription to online learning resources where our
programmers can learn about the best practices in VB studio
The merit of hiring a VB Studio expert is because our own
programmers will be able to learn about the best coding
protocols for this particular framework. In addition, this will
enable us to fix various bugs wherever they arise
notwithstanding a reduction in the amount of time and money
spent on soliciting the services of the software. With the access
to an online learning portal, out programmers will have the
chance of polishing their skills wherever they want.Conflict
ResolutionCause
The major players of team dynamics are also the main causative
agents of conflict within the team. However, some specific
individuals have caused derailment in the project objectives
much more than others. The aspect of “technical ignorance” in
regard to the new programming language has considerably
reduced the overall team efficiency.
Cause of Conflict between Database Administrator and
Architect
The architect’s expansive skills and the database administrator’s
“well-polished” political connections are an important recipe
for the success of the team’s endeavors. However, the two have
been unable to arrive at a single solution to address the way
third party software interacts with the database which has led to
conflict between the two.
Cause of Conflict among the Staff Members
The existences of multiple responsibilities of the staff who are
working on the project have been the greatest cause of conflict

5. among the team members. The previous project manager failed
to request the various staff’s supervisors to allow them to work
on the team full time. This resulted in the team members
reporting to more than one supervisor and not dedicating fully
to the team agenda. This divided responsibility and the
inadequate communication between the members thereof led to
the members not knowing exactly what modules they should be
working on which further increased the conflict within the team.
Cause of Conflict between the User Pack and the Programmers
Constant redefinition of the requirements scope has seen the
users proposing numerous changes to the programmers. Some
programmers complained about this, but the management
requested them to effect the changes that are being asked of
them. However, it must be noted that developers usually spend a
lot of time writing code and it would be beneficial if a thorough
user requirements was documented so that they do not have to
scrap every line of code written once there is a small change in
user requirements.Strategy for Resolving the Conflict
Some of the strategies that are going to resolve the conflicts
include holding subject discussions, channeling proper written
communication, mediation and holding a ballot among the team
members over sensitive areas of decision making (Davidson &
Wood, 2004). The following table illustrates how these
strategies are going to be used.
Strategy
Impact/Approach
Inclusion of proper written communication
Some of the biggest challenges which are facing the team
include a conflict as a result of lacking in a clear definition of
responsibilities among the team members. There needs to be a
proper way of sending memos to the various departmental heads
so that they can become privy with the engagements of their
staff thus allowing them to dedicate their time fully on the
project. The team members also need to express their challenges
to the management in writing instead of just keeping quiet and

6. expecting the management to somehow figure out what they
want achieved. The test pack needs to document their proposals
and the pertinent version in order to provide a clear set of goals
for the programmers. We will develop a version control
mechanism so that all team members can integrate into a
common branch and monitor the tasks being performed by
various programmers to avoid task conflicts.
Mediation
The architect and the database administrator are always at war
about how the database should interact with the third-party
software. The architect has vast technical skills while the
administrator’s representative feels like the subject is his own
area of expertise, hence should have the final say in regard to
how the software interfaces with the local database. Since these
conflicts are stemming from the technical know-how, it will be
important to call the two parties in a meeting with senior
management and have them agree about who is going to be in
charge of what, and the other party should be ready to respect
all decisions made by the chosen leaders so that there can be a
single source of authority about the matter.
Compromise
The team comprises individuals with a background in Java
programming. Working on a VB studio project has been
demanding for the members which have sometimes led to
performance issues with the code that they are producing.
However, the team should be allowed to deliver a working
prototype even if they are not using the best classes/ methods
for the various functionalities. With good project
documentation, later versions of the software can be upgraded
to incorporate optimized source code. In addition, the vendors
are attending other companies as well, which has reduced the
amount of usable support that they can offer to our team.
Therefore, the need for software with the best big O will not be
the cause of a lag in delivering the project- this needs to be
compromised.
Voting

7. Instead of holding endless debates about who should be
responsible for various aspects about the project, a simple
voting system will be devised to enable the team members make
a selection about various distributions in regard to the project.
For example, the war between the architect and the database
administrator hinges on the technical capabilities of the two
individuals. Since the team consists of programmers who are
relatively well versed with the technical aspects of the whole
platform, they will hold a vote on whom they feel is best suited
for the job and spell out the duties of the elected leaders to
avoid wrangles involving the scope of responsibility. The
rationale behind voting is exhibition of democracy and the
derived satisfaction about the individual mandated with taking
charge.
Proposal for Laissez-faire for the Current Team Structuring
Stage
Laissez-faire should be the leadership style in use (Sayyadi,
Soosay, & Reaiche, 2015). This decision has been informed by
the following observations: - given that it involves giving the
worker full autonomy and all the necessary power to make
decisions as they deem necessary.
Skill level and Experience of the Team Members
The team consists of individuals who have an extensive
experience in programming and the general software
development lifecycle (SDLC) practices. This gives them the
ability to formulate working schemes on their own since they
are outright professionals in what they are doing. The team
leaders such as the architect are well experienced in the
operation of the whole project having overseen similar project
before.
The use of Outside Staff
The team has been relying on external VB staff studio for
support. This is because the team does not have an expert in the
Microsoft language packs. As a leader, it is very difficult to

8. manage and oversee what the consultants and specialists from
the vendor are doing to support the project. Therefore, this
makes the use of Laissez-faire most appropriated for this
particular scenario. The existence of an already laid down
project timeline means that the team is capable of working on
their predetermined tasks and submit deliverables without
having to be tied down by frequent feedbacks. This further
makes the chosen leadership style the most appropriate for this
project.
The following table summarizes the fundamental paradigms of
this leadership style in regard to the ongoing project.
Paradigm
Consequence
Autonomy
Critical decisions made by programmers
Self-Rule
Programmers will create their own schedules
Guidance
There will be room for consultationMotivation and Confidence
Presently, the team is largely demoralized. The exit of the
project manager and subsequent disarray witnessed among the
team members has almost killed the motivation to keep going.
The programmers are no longer certain that the code they are
writing will not be thrashed aside by the ever-changing
requirements from the user pack. Moreover, the team members
are being answerable to more than one team leader since they
are still working on their side projects in their various
departments. Programming and integrating user requirements is
a generally daunting task which calls for a lot of patience from
the side of the developers. These individuals have had to put
long hours into the course by staying up late into the night
while debugging the source code for various modules.
The low level of technical know-how among the team has
necessitated for the inclusion of the VB Studio specialists in our
team. However, some of these consultants have been busy
attending to other companies which have resulted in inadequate

9. support to our programmers. This in itself has been a
demotivating factor since our members have to wait for a
relatively long period of time for various blockers to be
resolved. The legal team does not seem to be in sync with the
project that is being undertaken. In fact, they have stated there
was inadequate communication in the preparation for drafting
policy documents which are vital in the launch of the project.
The user pack is breaking for thanksgiving holiday which will
considerably hinder the progress that the team wants to make.
Therefore, it is evident that there is a need to establish cohesion
within the team and motivate every stakeholder involved in the
exercise in order to realize the desirable progress.Cohesion
Motivation Strategy
The following strategies will be used in building the team
cohesion:
· Reselection of team members
· Restatement of the project objective and identification
· Promotion of open communication
· Increase in trust among project stakeholders
· Promoting conflict resolution
· Encouraging feedback and
· Dedicating time for fun
Reselection of the Team Members
The reconstitution of the team members is going to be one of
very first initiatives towards achieving cohesion among the
team members. Staffs who feel like they no longer believe in
the course of the project will be excused to leave. Individuals
who are dedicated to different projects within their departments
will also be given an opportunity to decide whether they want to
onboard full time into our time or remain under their respective
supervisors. If extra budget is approved as promised by the
project sponsor, we will hire a full time instructor who is
conversant with the MS programming environments and
integrate him as one of the team members. This will reduce the
time wasted in seeking vendor consultation time.

10. Restatement of the Project Objectives and Identification
The goals of the team and various individual responsibilities
towards its realization have become vague with time. Therefore,
there is need to hold a meeting and have the project sponsor and
other management teams restate the importance of the project to
the company in general.
Promotion of Open Communication
The barriers that have hindered effective communication
between the team members and the managers will need to be
addressed so that every stakeholder knows about the immediate
progress of the team. Managers will be encouraged to visit the
programmers more often and foster personal communication
which will ease the tension between the two parties.
Increase in Trust among Stakeholders
This will particularly be important in establishing cohesion
between the project architect and the database administrator.
The need for appreciating the competencies and specialties of
each professional will be stressed so that they can respect each
other’s decision about how the database should interact with
third party software.
Promoting Conflict Resolution
Just like every other team, there is always the probability of
various types of conflicts arising within the team members.
However, there has been an “infinite” change from the user
pack with regard to the kind of specifications they would like to
see resolved. As such, getting the two sides to agree on a
common base of requirements will go a long way in establishing
cohesion in requirements.
Encouraging Feedback
There is need to avail feedback about various reports from the
team members. To achieve this, each developer will be required

11. to develop a plan which outlines the work intended to be done
for each day, the blockers encountered, deliverables and
projections for the next day. This will make it possible for the
project manager to respond to various blockers in a timely
manner, hence promoting a mutual understanding among the
concerned parties which will ultimately foster cohesion.
Dedicating Time for Fun
Having fun is a great way of promoting inter-personal
relationships. Game events and outdoor camping will be used to
promote cohesion between the management and other employees
of lower ranks. Participating in these activities is crucial
towards building an easy rapport which will indeed promote
other important virtues within the work environment.
References
Baughman, S. (2008). Assessment of Teams and Teamwork in
the University of Maryland Libraries. Libraries and the
Academy, 293-312.
Davidson, J., & Wood, C. (2004). A conflict Resolution Model.
Theory into Practice, 6-13.
Executive Project Status Summary. (n.d.).
Medical IS Vendor - Project Charter. (n.d.).
PJM 6140 Troubled Health System Project Case Study. (n.d.).
Sayyadi, M., Soosay, C., & Reaiche, C. (2015). The emerging
role of transformational leadership. The Journal of Developing
Areas, 459-467.
The Case of the Troubled Health System Implementation at
Healthcare Unlimited, LLC. (n.d.).

12. Medical IS Vendor Medical IS Vendor Medical IS Vendor
Medical IS Vendor –––– Project Project Project Project
CharterCharterCharterCharter
Project Name: Health System ImplementationProject Name:
Health System ImplementationProject Name: Health System
ImplementationProject Name: Health System Implementation

13. PJM 6140 Troubled Health System Project Case Study
Background
Healthcare Unlimited, LLC a leading health services company,
embarked on a new product development
project. Healthcare Unlimited needs to expand its clinical data
warehouse (CDW) to ingest third-party
data feeds from medical IS vendor and onsite clinic data to
incorporate this information to downstream
employer group analytics and reporting processes. This
expansion will also be used to develop new
activity reports to message value on these products.
The nature of the company’s business is that it operates in an
extremely competitive environment that
necessitates fast delivery to market so as to prevent competitor
companies from gaining dominant
market share with similar competitive products. Therefore, the
key success factors of the project were
time to market and quality. Cost of delivery was not a major
concern.
Scope

14. The scope of the project was to create a modular software
package to handle medical IS vendor data to
ensure appropriate preventative care is being tracked for
members, including the systems changes, the
vendor medical IS database tables, and medical IS vendor
reporting. The project was divided into
modules consisting of: medical IS DB tables, promote tables,
and medical IS vendor reporting. A project
manager was appointed, but has since left due to personal
reasons.
Time Scales
The launch date was set as December 1, 2015. The product had
to be ready for launch on this date, as all
the marketing material would reflect this date and the launch
had to precede the launch of similar
products from competitors. The project kickoff was May 5,
2015. The tasks that had been completed
prior to May 5, 2015 were the business case compilation and
approval and the project team
establishment.
Technology

15. The systems development was to be done using the MS Visual
Studio programming language and SQL
environment, which was new to the development team. The
developers were sent on MS Visual Studio
programming training two weeks prior to the project start. The
developers were used to working in a
Java programming environment and had not worked with any
MS-oriented languages before. The new
medical IS vendor reports will integrate into the existing
system located behind the intranet. These new
reports, unlike the existing reports, will utilize both SQL Server
and Teradata. SQL Server will control the
security access and parameter selection for the reports. The
application will then send the selected
parameters to Teradata in order to populate the body of the
report.
Infrastructure
Database Servers
• MS SQL Server 2008 R2
• Teradata 14
Reporting Servers

16. • The system will use an SSRS deployment server.
Development Tools
• MS Visual Studio 2008 Shell
• SQL Server Business Intelligence Development Studio
• SQL Server Management Studio
Business Requirements
The current application will display the medical IS vendor
reports. The system generates SQL Server
Reporting Services (SSRS) reports based on user-selected
parameters. Users can choose to view reports
in three formats: Excel 97-2003 (XLS), Portable Document
Format (PDF), or Comma Separated Value
(CSV).
The exported data within Excel or CSV files will contain “user-
friendly” headers and not
database column headers.
Scripts will execute on a weekly basis to import the following

17. vendor sources into the target system:
• Chip Rewards
• Spire
Scripts will execute on a monthly basis to import the following
vendor sources into the target system:
MDLive.
Case Study Summary of Events
Business Case Development
The product development department developed the business
case for the proposed new product,
including projected cost/benefit analysis based on previous
similar products and current market share.
The business case was reviewed by executive management and
approved.
Requirements Definition
The product development department developed the
requirements specification for the new product.

18. These requirements were specified based on the understanding
level of the project team, which had
many years of experience in the company and an extremely
good understanding of the systems. Some
of the finer details of the requirements, such as the reporting
requirements and the final policy
document wording, were not defined at this initial stage. The
outstanding requirements would be
agreed upon during the project, once the users had decided
exactly what they wanted in this regard.
Project Team Appointment
Peter was appointed as the overall project manager. Peter had
been with the company for 15 years and
been involved in numerous projects for new product
developments in the past. He knows the existing
systems intimately and had good working relationships with all
the various departments involved in
product development and launch. The project team appointed
consisted of people from various
departments, all of whom had been involved in previous product
development projects. Their
knowledge of the systems and applications is extensive. After
delivery of Module Two, Peter left due to

19. personal reasons.
Project Kick-off
The product development executive, the sponsor of the project,
chaired the project kick-off meeting,
held on May 5, 2015. She emphasized the importance of the
project to the company, as it would ensure
good returns by getting the new product to market before its
competitors. She stressed that the delivery
date must not be compromised in any way, as this would open
the doors for competitive products and
the opportunity would be missed. The project manager and the
team were asked to get busy
immediately with their planning, and a follow-up meeting was
set for August 5, 2015 to review the
project plans.
Project Plan Development
The project manager had been involved in many similar projects
in the past, and thus knew exactly what
the project entailed. For this reason the plans were based on
previous historical information of past
projects. The project plans included only the systems-related

20. work. The interfacing to other areas, such
as the legal department, marketing, and operations, would be
handled by the project manager at the
specific time required for their input. Project plans were drawn
up using a scheduling tool. The phases
and tasks were detailed, but resources were not allocated to the
tasks. Task dependencies were not put
into the plan.
Project Plan Management
Management of the project plan consisted of updating tasks with
their percentage complete on a
weekly basis. Record of actual hours spent on specific tasks was
deemed not necessary. Each resource
gave an estimate of the percentage complete for each task,
which was used to update the plan.
Resource availability was handled in an informal manner
whereby each resource gave feedback on a
weekly basis regarding his or her workload on the project and
other non-project work responsibilities,
such as systems maintenance.

21. Progress Reporting
Progress reports were produced every two weeks. These
consisted of a progress summary, deliverables
attained, percent complete, risks, issues, and cost information.
(See the most recent Medical IS Progress
Report below.) Minutes were kept for some meetings. (See the
most recent Meeting Minutes below.)
Progress for Period May 5, 2015 – August 5, 2015
Initial progress was good, with all team members working well
together. Programming started almost
immediately, since the team knew the systems so well that they
were able to make some of the
required changes immediately. Some issues were identified with
the user requirements, since not
enough detail was in the requirements document. These issues
were resolved between the
programmers and the users. Some of the programmers
experienced problems when they discovered
they were working on the wrong version of the user
requirements. This was resolved when the users
printed out the current version of the requirements for all the
team members to make sure they were

22. all working on the current version.
Progress was not as fast as desired, due mainly to users
changing their minds about the requirements.
The programmers were very accommodating with such changes
and tried their utmost to keep the users
satisfied. Unfortunately, the number of changes and additional
requirements requested by the users
caused the work to fall behind schedule. When some of the
programmers complained to the project
manager, he said that it was essential that users received what
they wanted, so their changes must be
accommodated, even if it meant having to work extra hours to
catch up.
The programming was also delayed from time to time due to
technical problems experienced with the
new development environment. The company did not have
anyone experienced in the new
development software, thus had to rely on vendor support,
which was a bit lacking due to their
commitments at other companies.
Progress for Period August 5, 2015 – October 5, 2015 (two
months before live date)

23. The sponsor became concerned with the project progress, since
she felt there was a risk of not meeting
the required delivery date. The programmers were working long
hours to try catch up on the project
work, as well as doing their required maintenance and problem
fixing of the live systems. The legal
department said that they may not be able to provide the policy
document wording in time for the live
date, due to other priorities. They said they may have been able
to if they had known about it sooner.
The user department said they may have a problem getting the
test packs ready for user testing, as
some staff were going on leave over the Thanksgiving period.
Initial testing revealed that the performance of some of the
modules was very slow. This was resolved to
some extent when it was found that some of the programmers
had used inefficient coding, as they were
new to the programming language being used. There were also a
number of bugs reported, one of
which causes the product to crash at least once a week. There
are numerous change requests submitted
by users for enhancements to the product.

24. Peter, the project manager, has left, and the project team is in
complete disarray, and there seem to be
issues between the architect and database administrators on just
how the database supports the vendor
reports. As of now the two areas are not working together to
develop solutions for the issues. There also
seems to be a loss of a defined testing strategy, which has
cropped concerns with development and user
acceptance. There is no existing method of capturing reported
issues, or how to handle changes.
Management is unhappy about the project and there is no
established communications method to
inform them about the project status. The project is over budget
by 20%. The vendor is asking for pre-
payment in order to deliver the third and final module for the
final payment of $75,000, which was 75%
of the total vendor cost. The module has not been tested yet.
There is no communications plan, no risk
plan, no systems implementation plan (to define how system
implementation testing is handled), and no
total cost of ownership (TCO) fee schedule. There is a conflict

25. within the project team (e.g., team
members have conflicting roles, or experience time pressure as
a result of working in two positions
within the organization simultaneously).
Medical IS Progress Report
Client VP Operations Project Number W1005
Project Medical IS Vendor Type of Project Development
Project Manager Peter Johnson Reporting Period Start:
End:
1 Progress Summary
Programming work is almost complete and testing has begun.
Unfortunately, it is going to take longer than planned to
complete the programming
due to changes requested by the users and errors made by the
programmers using the new programming language. We are
hoping that this time
will be caught up by working overtime and reducing the testing

26. time planned.
2 Major Activities Completed before Reporting Period
Commenced
2.1 Business case approved
2.2 User requirements document completed
2.3 Programming underway
2.4 Unit testing underway
2.5 Test pack compilation started
3 Major Activities during Reporting Period
3.1 Programming continuing
3.2 Unit testing underway
3.3 Test packs complete
3.4 Implementation plan started
3.5 Changes made per user requests to date
4
Deliverables and Milestones

27. No Description Baseline End
Date
Forecast or
Actual End Date
%
Complete
4.1 Initial project plan
4.2 Approved project charter
4.3 Program code
4.4 System testing
4.5 User acceptance testing
4.6 Go live
4.7 Post implementation audit
4.8 Project acceptance sign-off
5
Risks
Contingency Plan/Actions

28. Impact
(1-10)
Probability
(1-10)
Score
(I * P)
Actionee
Status
5.1 Delivery date may be
missed due to changes in
user requirements
Work overtime to catch up 8 5 40 PJ Open
5.2 Project team members
may take leave over the
Thanksgiving holidays
Plan leave into project

29. schedule
7 5 35 PJ Open
5.3 Other departments may
not have resources to do
the policy docs and
testing when required
Agree tasks with other
departments
8 6 48 PJ Open
6
Issues
Impact
(1-10)
Actionee

30. Due Date/
Status
Action
6.1 Changes to requirements requested by the users are
causing delays in project delivery
9 PJ Agree final requirements
with the users
6.2 Currently behind schedule with some tasks, but should be
able to catch up without affecting the scheduled delivery
date
9 PJ Work overtime
6.3 Get final policy document wording from legal
department
8 PJ Agree date with Legal Dept.
6.4 Make sure Testers are available for required testing dates 8
PJ Agree resources and dates for
testing with user departments

31. 7 List of Scope Change Requests
No Date Description Client
Approval
Impact
7.1 No official change requests to date
8 Major Activities for Next Period
8.1 Complete programming
8.2 Complete and get approval for project charter
8.3 Start system testing
8.4 Start planning for user acceptance test (compile test plan)
8.5 Fix errors and omissions identified during testing
8.6 Compile and agree implementation plan
8 Budget Tracking
Task/Phase Planned Cost
(Baseline)
Actual Cost to
Date
Remaining

32. Cost
Estimate at
Completion
Percent
Variance
Medical IS Vendor 441,650 230,892 210,758 529,980 20%
Meeting Minutes
MEETING DATE: May 15, 2015
PROJECT: Medical IS Vendor
SUBJECT: Weekly Progress
ATTENDEES: James Weary (JW), Peter Johnson (PJ), Tim
Drew (TD), project team members
APOLOGIES: Wanda Jackson (Sponsor)
Outstanding from Previous Meeting’s Minutes

33. Item
Minute
Actionee
Status / Due Date
1. PJ to discuss user requirements changes impact with sponsor
PJ PJ could not get
meeting with sponsor
Meeting Minutes
Item
Minute
Actionee
Status / Due Date
1. Testing plan to be drawn up and testers allocated by the user
department PJ

34. 2. Leave schedule to be drawn up for all project staff to assess
project schedule impact PJ
3. Legal department to give expected completion date for new
policy document wording PJ
4. Machine needs to be booked and set up for training of testers
and running of the user
acceptance test
JW
5. Testers to be identified by user departments and allocated for
testing period required TD
6. Current problems with system performance of the Java code
to be escalated to vendor for
urgent resolution
PJ
Scope Change Requests
Item
Change request description
Actionee

35. Due Date
Status
1. No official scope change requests to date
Next meeting: 06/01/2015 (3pm. – 4pm) - Meeting Room 2.3
The Case of the Troubled Health System Implementation
at Healthcare Unlimited, LLC
The Confidential Memo
Along with you welcoming papers, you received the following
confidential memo from the PROJECT
SPONSOR:
From: Project Sponsor, Healthcare Unlimited, LLC
To: IT Project Manager (you)
Date: September 4, 2015
Welcome to Healthcare Unlimited, LLC and congratulations on
accepting the project manager

36. position for the Medical IS project. It is my sincere hope that
your tenure with Healthcare
Unlimited, LLC will be both productive and rewarding. In this
letter you will find a list of several
critical barriers you need to consider and address as you take
charge of this troubled project.
1) Both your Architect and the Database Administrator
representative on your team
are very competent employees. Unfortunately, during the past
two months they
have created a difficult environment on the team that spurred
higher level of
conflict.
2) Senior management is quite unhappy with the dynamics of
the team and its
inability to address the internal conflict. The rest of the
organization has already
expressed concerns over the lack of motivation and tangible
results with the
team. As a result, you must take this into account if you choose
to restructure the
team.
3) The strategic plan for our company highlights the importance

37. of quality and time-
to-market of all our services. The board of directors is anxious
to see results with
the Medical IS project since it will have a large impact the
strategic direction of
the company.
My door is always open and I look forward to a productive
relationship.
Regards,
Your PROJECT SPONSOR
After reading the memo, you contact the PROJECT SPONSOR’s
administrative assistant to request your
first meeting with her as the new project manager of the
Medical IS project.
Meeting the PROJECT SPONSOR
During your meeting with the PROJECT SPONSOR you realize
that her job security hinges on your success
with the project.

38. You also find out that your team is not fully dedicated to the
project, but team members still spend half
of their time working on other duties in their departments.
Moreover, each one reports to a separate
manager in addition to you. The PROJECT SPONSOR notes:
“The first project manager never considered negotiating with
the various managers to acquire
additional team members from the legal, marketing, and
operations departments to be assigned
full time. He also didn’t consider the early warning signs that
the team conflict was escalating as
a result of their other duties. Projects do not start as ‘red’ and if
they do, they are doomed from
the start. I have to admit, I expected a lot more from him, but
instead felt mislead. At this point,
the board of directors is really unhappy with the lack of
progress on the project. We all need
someone who can take charge, motivate the crew, make any
changes necessary to set this
project on the correct path and ensure its success. I know this
will be a difficult task, but I am
confident in your ability to resolve the conflict on the team.

39. I also have to be honest with you. The previous project
manager complained about not having
control over the decision-making process in the team, because
of the conflict between the
Architect and the Database Administrators’ representative. In
fact, he mentioned that their
competitive and stubborn attitudes about who should actually
make decisions on the project
were ‘out of control.’ As a result, the morale of the team is low.
There is no sense of belonging.
I will support any changes you decide to make, but I want you
to be cautious and think several
moves ahead as to how each of your decisions will impact your
team and our organization. Also,
keep in mind, if you need to train any of your staff, I will
approve the training budget. You just
need to act soon.”
You ask about the skills of your team members. Your PROJECT
SPONSOR informs you that:
1) The Architect has the most technical expertise among the rest
of the team and has
been on several prior system integration projects. He was on the
original Medical IS

40. project team;
2) The Database Administrators’ representative has well
established political
connections in the organization, but lacks credibility among the
rest of the team
members. He has background in project management, but this is
his first technology
project at our company and he is the most recent addition to the
team;
3) The Operations representative has great initiative and
ambition to be on the project,
but her availability is very limited. She is well respected in the
organization for her
ability to round-the-troops behind a common vision. She was on
the original team
that procured Medical IS system contract and knows the most
common issues that
can occur with modifications to such systems. Her current direct
supervisor is flexible
when it comes down to ‘loaning’ her full time to the project, but
he needs to be
informed;

41. 4) Your Marketing representative has great problem-solving
skills and an excellent
attention to detail. She was on several prior system integration
projects with our
company. She has previously worked in the Legal team for 3
years before moving to
the Marketing team.
You ask what immediate changes would you like your
PROJECT SPONSOR to see. She reflects:
“One of the most important things is to make sure that before
the project starts, you have a
good plan since a project that is off track costs more to recover
than later. At the present time,
the company is not capable if designating any more resources.
The way I see this, the number
one challenge is the team. You won’t be able to start this
project in isolation. The team is the
key! Yet, since the morale is low that by itself can kill the
project.”
You thank her and promise to provide her with status as soon as
you meet with your team and make a
decision. Next, you schedule a meeting with your team.

42. Meeting the Team
At your first team meeting, the Database Administrators’
representative show up late. Before you even
start the meeting, the Architect comments how important it is
for all to show up on time.
Database Administrators’ Representative:
“From the start, I know this is going to be a team-roast meeting
for me. Before you even start, I
have to say one thing, how do you expect me to make it on time
when yesterday I was handed
ten new requests and had four back-to-back meetings since 8AM
this morning? I can’t clone
myself and you know we are understaffed. This isn’t my first
team meeting and I understand the
importance of being here on time. Perhaps, you can speak with
my Manager next time and ask
him to take away some of these requests.”
Architect:
“We all have other responsibilities, but if we are not here on
time, we can’t finish on time and

43. then we are late for our other tasks. You were aware that the
meeting starts at 10AM. You knew
about it since yesterday. Also, this is not the first time you are
late-”
The Marketing Representative cuts the Architect short:
“I think we should hear what our new project manager has to
say. So perhaps you two can table
this discussion for later.”
The Database Administrators’ Representative:
“I am getting really tired of this. I can’t stand each time either
of you two (the Architect and the
Database Administrator’s Representatives) come into my office
and tell me what I should or
shouldn’t do. We already had this discussion once and I don’t
want to repeat myself. When I
have a priority request, all else is set aside. I don’t think this is
going to change, considering how
important some of these requests are for the future of the
company.”

44. The Marketing Representative:
“I have to say that without many of the software initiatives, the
company will have a hard time
retaining qualified staff to assist with the work on the requests.
The same is true for the
architecture design and for functional units such as Marketing
and Legal. Now, the Medical IS
project is not less important than your requests. In fact, it is
strategically aligned with our fiscal
year’s growth projections and if it fails, none of us will be
around to have this discussion again.
Architect turns to the Database Administrators’ Representative:
“The Design department is in the middle of system design for an
application to assist them with
the software roll-out process. I have been involved with it from
the start and can tell you that no
other member of that team is as problematic and as self-
centered as you. In fact, when the
schedule began to slip on that project, all team members
hunkered down and worked extra hard
to meet the established deadlines. We all pitched in and acted as
one unit. No other task was

45. more important than the project-”
Database Administrators’ Representative interrupts the
Architect:
“Wait a minute! You are misleading the rest of us again. ‘We’
on that project was you, the
Architect, and a member of the Documentations department plus
the complexity of that system
was so low that it hardly mattered to the company. It certainly
is nowhere near the caliber of this
project. Besides, if you knew anything about project
management, you’d know that the intent is
to break down the work into smaller packages and estimate it
properly. Your project manager
had no experience with this and he underestimated the work. As
a result, you all had to work
crazy hours to meet the deadline. I can’t stand incompetence
when it comes to project
management.”
At this point the Database Administrators’ Representative turns
to you and smirks.

46. The report should include the following:
A. RecoveryProject Scope Planning: Establish the recovery
project scope plan and controls. What are the business
requirements? What are the system requirements (software and
hardware)? In establishing your project scope plan, you might
consider these aspects:
1. Requirements (requirements traceability matrix)
2. Existing work breakdown structure
3. Person responsible for each requirement (responsibility
assignment matrix)
B. RecoveryProject Cost Planning and Control: Establish a
recovery cost control plan with strategies to help maintain
prospective value of the new project with respect to expected
expenditures and added business values. As you are developing
your cost control plan, you could consider aspects such as these:
1. The cost–benefit analysis
2. The TCO（Total cost of ownership）
3. Budgeted vs. actual costs
4. The earned value of the recovery project
C. RecoveryProject Quality Planning: Craft a recovery plan for
ensuring quality of the recovery project outcomes that identifies
acceptable performance standards and recommended recovery
strategy. Ideas to consider may include:
1. Key performance indicators of quality
2. Important factors in defining quality
3. How to measure quality

47. D. RecoveryProject Risk Planning: Craft a recovery plan for
identifying and monitoring risk. In your recovery plan, you
could consider:
1. The amount of uncertainty in the project and how to deal with
it
2. The threats of greatest concern
3. How each threat should be dealt with
E. RecoveryRisk Control: Determine corrective actions and
controls to deal with uncertainty and its impact on the project,
based on your risk plan. Ideas to consider may include:
1. Appropriate quantification of the risks (probability vs.
impact)
2. Contingency funding or time buffers in place to handle
threats
Rubric
Guidelines for Submission: Final Exam should follow these
formatting guidelines: 10-page analysis report in MS Word,
double spacing, 12-point Times New Roman font, one-inch
margins, and citations in APA 6th edition;