trouble project recovery plan
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
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
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
• 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 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.
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
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 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.
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
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)
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.
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 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 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
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
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
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
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
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
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
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
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
Due Date
Status
1. No official scope change requests to date
Next meeting: 06/01/2015 (3pm. – 4pm) - Meeting Room 2.3