Improvement of Hospital Project Cost and Schedule Mgmt Final Rpt

Project Management Process Improvement at
<CLIENT>

CREATED BY:
ED KOZAK
SUCCESSFUL PROJECTS FOR LEADERS
16 EAST BURLINGTON AVENUE
LAGRANGE, IL 60525

FOR
<CLIENT>

Executive Summary
Of pressing concern to the CFO of <CLIENT> were the spending issues and schedule
slippages of internal implementation projects--issues that he felt contributed to the
current cash flow problem of the hospital that would grow to an even greater problem if
EMR capabilities weren’t fully implemented and operational by 2015. The CFO solicited
external help to 1) validate why there has existed such a level of overspending and
schedule slippage on projects, 2) propose a recommendation for solutions, and 3) change
the existing process to ensure better project budget and schedule control in the long run.
Successful Projects For Leaders (SP4L) had been hired as a consultant to assess what
went wrong with that implementation and to improve how projects in general would be
conducted at <client> so that it could move forward with the EMR project successfully.

Problem
Using the Six Sigma process of Define-Measure-Analyze-Improve-Control SP4L
determined what the priorities were for Management. We then chartered a project and
proceeded to understand and define the problem. Through surveys and interviews with
end-users, technical staff, and oversight committees, as well as historical project reviews
and data gathering, we were able to focus on the real issues at hand. To help clarify the
situation, we mapped the project Initiation-Planning-Execution-Control-Closing process
for internal projects, identifying issues as we proceeded. Eventually, the measurement
and analysis processes pointed to the fact that we had a real issue that was a major
deviation from the standard methodology for budget/schedule planning and control.
Fortunately, we had a clear understanding of industry best practices and good support
from Management to help research and resolve the problem.

Findings
Our findings indicated that deviations have existed across all projects at <CLIENT>
between project planning and control methodologies and the de facto best practices,
deviations that have had a severe cost, schedule, and quality impact. A change in the ad
hoc manner projects have been planned and controlled to follow the de facto standard
resulted in a low-cost solution to control project expenditures. We also identified a
severe quality issue, based on feedback from the end-user community, that can be
immediately addressed and rectified from this point forward. While it is early in the post-
implementation phase, we are seeing improvements in cost expenditures, schedule
slippages, and end-user satisfaction.

Conclusion
By using a systematic approach, we identified several areas in the project Initiation-
Planning-Execution-Control-Closing process that needed modification. The net result is
better project cost and schedule performance, leading to better cash flow budgeting and
planning, with an expected savings of more than $350,000 annually as well as improved
acceptance and ownership by the end-users. Based on the proactive response to their
issues, the CFO, CNO, and PCCs are satisfied and are serving as excellent centers of
influence for the rest of Senior Management and the nursing staff, respectively.

2

1.0 Introduction/Problem Statement:
When the CFO of <CLIENT> learned of the Federal Government mandate that health
care providers who fail to adopt certified electronic medical record (EMR) systems or
can’t demonstrate meaningful use by 2015 will find their Medicare reimbursements cut
and they will lose the chance to receive Medicare incentive payments for implementation,
he became increasingly concerned over his hospital’s abilities to meet that mandate.

Lately the nursing staff had been all abuzz, voicing their concerns over what they had
dubbed the latest implementation fiasco. The first part of their EMR implementation
went beyond its scheduled due date, and, when it finally went live, was full of
functionality problems. This implementation created an immense amount of additional
work for the nursing staff, despite it being implemented to reduce work and speed up the
patient care process. The nursing staff (PCCs, RNs, LPNs, CNAs) bemoaned the fact
that the system didn’t provide them with the functionality they needed (some input
screens did not allow all relevant data to be entered while others required irrelevant data
and would not let the staff proceed until it was entered), required 10 minutes to load, had
poor response times, was not able to communicate with other packages used at the
hospital to retrieve information (or retrieved incorrect information), didn’t provide the
ability to print reports in their required formats, and sometimes completely lost
everything that the staff had spent the last twenty minutes entering into the system. The
frustration of the nursing staff was high since they were still required to use the system in
its current state, but needed to duplicate every entry on paper so that important
information would be safe as well as compliant with Government regulations, and it was
felt that buy-in of any new modules for EMR implementation would be difficult. To
make matters worse in the eyes of the CFO, rumors had been circling that some of the
nursing staff were talking about unionizing.

Not only was the CFO concerned about meeting that Government requirement to
demonstrate meaningful use but also felt that the six projects conducted on average by the
hospital per year were costing it much-needed cash flow. The hospital had shown an
inability to meet internal project deadlines time and time again and each time the
expenditures of each project had grown exponentially from their original estimates. It
was a nightmare from an operational budgeting standpoint since previously-allocated
funds had to be reallocated to projects so they could be completed. The CFO disliked the
fact that any future project estimates would be similarly worthless from a forecasting
standpoint.

The hospital had always relied on Federal and State support to meet its budgets but the
economic downturn had created budgetary problems for these levels of the Government
and money was taking longer and longer to flow to the hospital, forcing cuts and other
drastic measures within it.

Up until this point the CFO and other representatives of Senior Management had felt that
the majority of projects conducted at <CLIENT> had been successes, based on
information that had been communicated upwards. It was their understanding that only a
few past projects had had problems and the blame had always been placed by the

3

functional Oversight Group—usually the Chief Nursing Officer (CNO) and two hospital
VPs from varying departments (whichever departments were tasked with doing the
majority of the work) appointed by Senior Management to plan the projects (budget,
deadline, functionality and report formats)—on poorly-selected internal project managers
or external PMs that the hospital had contracted with to do the job. When an internal
project manager was appointed, the hospital suffered from what was known as the halo
effect. It was always felt that a nurse be the project manager since he/she could bring
relevant subject matter expertise to the table. The nurse/PM chosen also had experience
outside of nursing, such as IT, for example, but had no project management experience or
even a basic understanding of project management principles. Furthermore, in every
circumstance when this was done, the nurse lacked relevant nursing experience. For
example, the nurse/PM appointee for the last project had rehab/sub-acute experience but
no beside care experience. The complaints and pushback from the nursing staff had shed
new light on this altogether and it didn’t take a rocket scientist to realize that the problem
was something greater internally and not solely due to poor project manager selection.

Although lack of project management experience and the frustration of the nursing staff
were concerns to the CFO, what was on the forefront of his mind were the spending
issues and schedule slippages--the former a pressing concern to deal with the current cash
flow of the hospital and the latter a pressing concern to deal with future cash flows if
EMR weren’t fully implemented and operational by 2015. The CFO solicited external
help to 1) validate why there has existed such a level of overspending and schedule
slippage on projects, 2) propose a recommendation for solutions and 3) change the
existing process to ensure better project budget and schedule control in the long run.
Successful Projects For Leaders (SP4L) had been hired as a consultant to assess what
went wrong with that implementation and to improve how projects in general would be
conducted at <CLIENT> so that it could move forward with the EMR project
successfully. We chose to utilize Six Sigma in our approach.

2.0 Project Initiation and Planning
2.1 Project Objective
Based on the voice of the customer (CFO, nursing staff), it was clearly evident that there
are three major areas of improvement

• Reduce project schedule slippage,
• Reduce project budget overages, and
• Improve end-product functionality.

It was also clearly evident, however, that improvement of all three areas would be beyond
the scope of one single six sigma project. In addition, based on how the need for rework
was identified to date for hospital projects and the difficulties that would be incurred in
obtaining good process control charts (discussed in Section 4.0), the objective of this
improvement project was focused on the following specific goals:

• Reduce project schedule slippage by 50%, and
• Reduce actual project expenditures by 50%.

4

It is estimated that doing so would improve project cycle times and would decrease
unwarranted project over-expenditures by $1,200,000 annually across all future projects.

2.2 Project Scope
The following are the items that were identified as the scope requirements:
1. Conduct investigations, including surveys/ interviews to understand the nature of
cost variances and schedule variances.
2. Investigate project performance standards and expectations.
3. Compare current project initiation, planning, monitoring, and control practices
against industry performance standards.
4. If performance is found to be substandard, investigate what is causing the
problem and recommend solutions.
5. Pending findings and approval for #4, implement recommended solutions.

2.3 Project Charter
– The Project Charter and Project Evaluation Form are provided in Appendix A

2.4 Project Validation Analysis
2.4.1 Causes and Effects
Cause-And-Effect diagram is provided in Appendix B indicating the possible causes to
the variances in project costs and schedules and the ones isolated for this project.

2.5 Work Breakdown Structure
The WBS at the summary task level is listed below. A fully-expanded WBS showing all
tasks and subtasks is provided in Appendix C.

1. Historical Data Collection
2. Analyze Results
3. Underlying Project Planning
4. Current Project Initial Planning
5. Analyze Results
6. Intermediate Data Collection
7. Analyze Results
8. Re-Baseline Project
9. Final Data Collection
10. Close Out Improvement Project

2.6 Project Schedule
The schedule for the high-level summary tasks, showing start and end dates, is shown in
Figure 1. A more detailed project schedule, showing subtasks is provided in Appendix D
and a more visual schedule showing task dependencies is given in Appendix E.

Task Name Duration Start Finish
Cost and Schedule Improvement Project 417 days Mon 1/4/10 Tue 8/9/11
Historical Data Collection 18 days Mon 1/4/10 Wed 1/27/10
Analyze Results 6 days Thu 1/28/10 Thu 2/4/10

5

Underlying Project Planning 4 days Thu 2/4/10 Tue 2/9/10
Current Project Initial Planning 2 days Fri 7/30/10 Mon 8/2/10
Analyze Results 4 day Tue 8/3/10 Fri 8/6/10
Intermediate Data Collection 112 days Fri 8/27/10 Mon 1/31/11
Analyze Results 3 days Thu 2/3/11 Mon 2/7/11
Re-Baseline Project 2 days Mon 2/7/11 Tue 2/8/11
Final Data Collection 112 days Fri 2/25/11 Mon 8/1/11
Close Out Improvement Project 6 days Tue 8/2/11 Tue 8/9/11
Figure 1. Project Schedule With Summary Task Start/End Times.

In order to conduct the performance improvement project it was necessary to piggyback
it on a project being conducted at the hospital. Although, hypothetically, the
improvement project could have been accomplished in half the time—nine months—we
felt it was important to collect six months’ worth of data in each phase of the project to
obtain a better sample and get a more robust indication of what was happening. The
optimal frequency for schedule and expenditure monitoring is monthly so three months’
worth of data would have only yielded three data points each for cost and schedule
performance.

2.7 Project Budget
The total budget for the project is $111,205 and consisted of 438 consultant hours and 75
hours of nursing and IT staff. Based on the deliverable metrics, it is estimated that the
ROI for the first year following the performance improvement is 416%.

Deliverable Metrics:

1. Reduction in Cost Variance. Validation: CV, Frequency: bimonthly
2. Reduction in Schedule Variance. Validation: SV, Frequency: bimonthly

Dollar Opportunity Estimates:
Average number of projects/year = 6
Average schedule slippage time = 4.63 months
Average cost/hour = $208.33
Size of Opportunity = $208.33*4.63 months*160 hrs/month/project*6 projects =
$925,985
Estimated cost of project = $111,205
Estimated Improvement: 50% reduction in slippage = .5*925,985 = $462,993
Savings = $462,993 - $111,205 = $351,788
First Year ROI = $462,993/111,205 = 416%

2.8 Resource Assignment Matrix (RAM)
The Resource Assignment Matrix is given in Appendix F.

6

3.0 Definition Phase
3.1 Process Model
Figure 2 shows the SIPOC for the as-is process at <CLIENT> for project initiation
through close-out and Figure 3 is the process flow for the as-is process for project
initiation through close-out at <CLIENT>.

Suppliers Inputs Process Outputs Customer
• Upper • Scope • Management • Preliminary • Nursing
Mgmt • Functionality defines scope Scope Staff
• Oversight • Assumptions • Doctors
Group • Constraints • Patients
• IT • Management sets • Top-down
Manager • Budget budget project
• Vendors budget
• Internal
Computer
System • Deadline • Management sets • Arbitrary
• Contract deadline deadline
PMs
• Internal • PM/Team • Preliminary
IT/Tech determine Schedule fit
Staff schedule to deadline
(Project
Team) • Milestones • PM/Team • Intermediate
determine deliverables
milestones

• Vendor product • IT Manager • Purchase
literature purchases Order
software
• Customizable
software • Vendor supplies • Non-
package software functional
software

• PM/Team • Customized
execute software
implementation, implemented
customization,
and roll-out
Figure 2. SIPOC for <CLIENT> Project Initiation and Execution.

7

Nursing

Tech Support

Contractor/
Internal PM

Management

Figure 3. Process Flow For Project Initiation Through Close-Out.

3.3 Failure Modes and Effects Analysis
A complete FMEA was conducted of the entire process group steps of the Project
Management Book of Knowledge (PMBOKTM), the de facto standard in America for the
methodology of conducting projects, to identify possible failure modes. Due to the size
of the spreadsheet containing the data, it is provided in a supplemental document titled
“FMEA Spreadsheet.xls”

8

4.0 Measurement Phase
Figures 4 and 5 show control charts of the average normalized task cost variance and
average normalized task schedule variance by month obtained for the past five projects
conducted at <CLIENT>. These indicate that even within one month of each project’s
initiation, variances had already occurred, and, without proper corrective action being
taken, continued to grow until the projects were terminated. It was necessary to
normalize the data since each project has budgets independent of the others and it was
necessary to show data in relative terms. Therefore, the normalized cost variance (CV%)
and the normalized schedule variance (SV%) were used. The formulas for each of these
are

CV% = Earned Value/Baselined Project Budget
SV% = Planned Value/Baselined Project Budget

These charts do not include the additional schedule effort and costs added to the project
to rework functionality errors and changes needed to satisfy end-user requirements. It
was determined that such an undertaking would be tabled for a future process
improvement project since no prior data had been recorded. Furthermore, due to the
hospital practice of waiting until a project was near completion before validating
functionality and content against user requirements, there would be no means to record
variables associated with rework until the overlying (i.e. the one being piggybacked
upon) project had reached its rollout point.

Figures 6 and 7 show the control charts that were constructed for the improvement
project, again, based on the normalized task cost and schedule variances by month for the
project.

Data was sampled for a six-month period prior to improvement of the process. At this
time the variances were so great that it was feared that corrective action to get the
variances back to zero would be improbable, costly, and might completely destabilize the
project. Instead, the variance at Month 6 was established to be the baseline and any
corrective action taken from that point on was to bring the project variances back to that
respective position.

Two factors attributed to the variances in Figures 4 and 5. The first is the lack of
corrective action. Corrective action is a standard project management practice on
successful projects that entails regular, frequent sampling of CV% and SV% followed by
performing actions on the project designed to steering it back on schedule and/or the
forecasted spend line.

9

Av. Normalized Cost Variance

0
1 2 3 4 5 6 7 8 9 10 11 12

-0.2

-0.4

-0.6

-0.8
Cost Variance

-1 Series1

-1.2

-1.4

-1.6

-1.8

-2
Month

Figure 4. Normalized Cost Variance By Month Over Past 5 Projects.

10

Av. Normalized Schedule Variance

0
1 2 3 4 5 6 7 8 9 10 11 12

-0.2

-0.4
Schedule Variance

-0.6 Series1

-0.8

-1

-1.2
Month

Figure 5. Normalized Schedule Variance By Month of Past 5 Projects.

The second factor is that the budgets of the projects were never estimated properly. That
is, they were never established as a dollar amount proportional to the work needed to be
done. It was stated earlier in the text that Management would assign a budget to each
project but this budget was not created by following any acceptable project estimation
techniques. Instead, a dollar was assigned to the project solely for the purposes of
allocating some money towards it, based on a gut feeling, and that total dollar amount
was apportioned downwards to individual tasks. It was understood that additional money
would have to be allocated at some future point after the majority of the budget to date
had been used up. This explains the volatility in Figures 6 and 7 from months 6 through
12. Simply put, the variances in task duration and task cost during that period are
attributed to the improper schedule and budget estimates, respectively. For months 13
through 18, the cost and durations of remaining task work were re-estimated and
baselined and it is evident that further reduction in the variability of schedule and cost
were obtained.

It is important to note that the six sigma project itself was separate in and of itself from
the piggybacked project that the hospital was being conducted. That project had a pre-set
scheduled duration that exceeded the six-month timeframe that a six sigma project would
span that it was necessary to follow in order to collect a sufficient amount of data.

11

As it was previously mentioned, due to the frequency of data being sampled, the
improvement project was constrained by the sampling rate, and for good reason. It would
be excessively costly to monitor schedule and costs variances on a daily or even weekly
basis and the value provided is marginally better than what a monthly frequency
provides. The positive value of the improvement would be lost if a costly and non value-
added monitoring process were forced upon the project just for the sake of sampling more
data. For that reason, in order keep the improvement project costs down, the underlying
project was conducted for six months prior to the onset of the improvement project. The
first improvement was made and the underlying project continued for an additional six
more months before the second improvement was made. Although starting and stopping
any type of project is not recommended, let alone one designed to improve processes, it
was necessary in this case.

Using historical data and the results of end-user interviews we determined that the
critical-to-quality (CTQ) variable is the number of hours spent on project rework

Cost Variance Run Chart

0.1

0
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18

-0.1
Normlized Cost Variance

-0.2

Series1

-0.3

-0.4

-0.5

-0.6
Month

Figure 6. Cost Variance Run Chart Showing Pre-, Partial, and Full Improvement.

activities. As it is defined in this hospital’s standard operating procedures, a rework
activity is one that is performed after the product is released to the client and the need for

12

rework has been identified by the client. That is, it does not include rework of bugs,
fixes, workarounds, etc. that are the result of each project team member’s individual
testing prior to roll-out. A defect, in the context of this report, is defined as one
additional, unplanned, unbudgeted hour of project work spent on rework.

Task Schedule Variance

0.1

0
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18

-0.1
Normalized Schedule Variance

-0.2

Series1

-0.3

-0.4

-0.5

-0.6
Month

Figure 7. Schedule Variance Run Chart for Pre-, Partial, and Full Improvement.

Table 1 shows that for the past ten projects, the average percentage of additional project
time spent on rework was 17.12280%. This presented a difficulty, however, in that
rework only applied to changes performed after a product had been released in order to
align the functionality and scope of that product with end-users’ needs.

Table 1. Historical Project Rework Durations.
Sample Number Project Duration Additional Time Spent On Rework
(months) (months)
1 20.107 3.985
2 12.352 1.760
3 11.678 .615
4 15.662 4.006
5 20.505 1.009
6 8.089 .998

13

7 17.029 4.496
8 12.181 4.048
9 13.002 .144
10 13.374 3.592
Averages 14.398 2.465

Therefore, in order to collect sufficient data for the Measure phase, we would have had
to make changes and then track the next ten projects to completion in order to determine
if the changes were correct and sufficient. This would amount to a minimum of two
years of data collection, since each project would yield one data point. For this reason
reduction of project rework was not considered as part of the scope of this project.

5.0 Analyze and Improve Phases
The methodology of managing projects was investigated, with particular attention being
paid to determine the underlying causes to the variances between estimated and actual
project budgets and schedules. Specific interfaces addressed were contributions by the
contract project managers, past Oversight Group members, and the end-users (nursing
staff). Initial observations were that, although a repeatable process was set in place by
Management to assign budgets and schedule durations to projects, the standard model for
conducting and managing projects, that of the PMBOKTM, was not being followed.
Keeping the Pareto principle in mind, SP4L felt that this alone could attribute for the
majority of budget overages, schedule slippages, and even project rework.

5.1 Exploratory Data Analysis
Using the PMBOKTM methodology as a guide, we identified what the current as-is
methodology is at <CLIENT> for conducting internal projects and compared it to the
should-be methodology of PMBOKTM, identifying gaps in the process along the way
and/or improvements in the process itself. Special emphasis was placed on the following
items in their respective process groups:

• Initiation - project charter, stakeholder analysis
• Planning - project work breakdown structure (WBS), project schedule, project
budget estimates and the process in which estimates are made, risk management
plan, quality management plan
• Monitoring & Control - performance monitoring, milestone management, Earned
Value Analysis, corrective action, risk management

5.1.1 As-Is System Process Audit
From a political standpoint the CFO asked us to address the concerns of the nursing staff.
This was a good-faith gesture on the part of the CFO to show the nursing staff that their
concerns were being heard loud and clear in hopes that it would get buy-in for the next
implementation project. One of the two biggest complaints was that none of the nursing
staff, i.e. the end-users, had been interviewed prior to the first EMR implementation to
determine what their needs were, what minimum functionality requirements the system
needed to have, nor what data needed to be collected for each of the input screens. In
addition, it was obvious that no criteria had been communicated to the project team by

14

the Oversight Group regarding user acceptance testing. Due to these two facts, the
system never functioned as needed once the system finally went live and months of
rework were needed to bring the functionality up to an acceptable level. When this topic
was pursued deeper it was discovered that it was common practice not to involve the end
users (i.e. nursing staff) to determine their requirements. Instead, the decision was made
at the CXO level what system performance would be.

5.1.2 Narrative Description of Undesirable Effects
Surveys were conducted anonymously by Internet using www.surveymonkey.com with
members of the nursing staff and IT staff regarding system performance of the EMR
implementation to date. Open-ended questions, Yes/No questions, and ranking questions
in Guttman and Likert formats were used to obtain a wide range of information.

The summary of responses allowed us to quantify the following undesirable effects:

• Projects were ready to be rolled out before the project team/Oversight Group brought
in any end-users to try out the system. As a result, overall project schedules were
delayed while the project team investigated post-implementation fixes. This was in
addition to project schedules already having been delayed an average of 4.63 months
beyond their original deadlines.

• Some mandated GUIs required nurses to provide patient subjective information
(answering Yes/No questions, based on patients’ responses to nurses’ questions).
Screens didn’t allow overrides of this and would not allow nurses to proceed further
without answers. However, many patients in critical care were unresponsive due to
their injuries and couldn’t provide responses. Nurses worked around this by
answering Yes or No and then writing in a text box that he/she really didn’t know
since the patient was unresponsive.

• Some screens (such as color drainage from tubes) only gave drop-down menus;
however the menus were far from inclusive of all the possible answers.

• Certain textboxes limited the number of lines allowed for answers. However,
consistent with the protocol for written reports, nurses kept a cumulative summary of
information from each time someone had charted. Due to the extended stays of some
patients and the limited number of allowable lines in the textboxes, nurses would run
out of space to provide answers and had no choice but to go back to the beginning of
summaries to erase earlier data to make room.

• Wound care screens go in sequential order, i.e. Wound 1 – Stage 2 bedsore; Wound 2
– Surgical Incision. The system didn’t allow the nursing staff to delete any wounds
that had healed so patients would appear as if they were still suffering from all of
their wounds all the time. The workaround has been to use textboxes at the bottom of
the screen to tell others to disregard the healed wounds, but the nursing staff feels that
“this makes them look stupid.”

15

• Currently, when a nurse gets into the system, the system loads all of the screens
before the nurse can proceed (screens are tabbed at the top of the GUI). Loading a
patient’s record requires a wait of 10 minutes on average due to the volume of
information stored in all of a particular patient’s screen as well as the number of users
on the system at any one time.

• Computers freeze constantly and kick nurses out of the system in the middle of
charting after inputting data for 30 minutes (the system does not have an autosave
functionality and users can only save data when they’re complete finished with a
screen and ready to move on to the next one). Input from IT is that the prior issue as
well as this one are due to the fact that the hospital’s servers don’t support the volume
of data and need to be upgraded—a cost that was no factored into the original budget.
Technical due diligence of server load capacity was performed prior to greenlighting
the project but it only established the capability of being able to satisfy the needs of
the initial scope. No additional due diligence was performed prior to adding each
new functionality requirement that the Oversight Group added.

• Initially, computers were connected to the server via wireless link but were quickly
realized to be nonfunctional (dropping signals and losing data) due to the proximity
of many rooms to MRI and x-ray equipment. Many were replaced by hardwired
laptops on carts (computers on wheels, or COWs) and the expenditure and time were
never factored into the project.

• Charting on paper would take the nursing staff five minutes. After the rollout it took
25 minutes to 50 minutes to chart via the computer.

• Biometric authentication devices (thumbprint scanners) were purchased for all of the
computers but were not part of the initial scope, schedule, or budget. These were
purchased as a fix to circumvent the amount of time it took for a nurse to load up her
screen as she moved from one patient’s room to another. Instead, a nurse could have
her data screens be open on multiple computers. Months after the purchase IT has not
been able to interface the thumbprint scanners with the COWs.

Responses from former project team members, including past project managers still
working for <CLIENT>, brought forth the following issues with respect to project
planning and monitoring:

• The project was planned as it proceeded. The package was delivered by the vendor
and the team set out knowing Point A and Point Z, but developed Points B-Y as they
went along.

• Cost was not a factor. There was a budget that was created by the Oversight Group
but that budget number was not communicated down to the project manager or team
to follow on a task-by-task basis. It was understood that implementation of the
system was a requirement and it would “cost whatever it cost to get the job done”.

16

• Schedule was not a factor. Many times during the project the team was directed to
add more functionality and many times they needed to go back to undo things they
had already completed. Even when this wasn’t so the additional scope meant that
whatever deadline was originally thrown out (or subsequently thrown out) was moot.

• The project manager reported back to the Oversight Group whenever higher-level
tasks had been completed, such as the installation of sub-package functionality.
Regular reporting to the Oversight Group wasn’t required.

• The project team was directed to communicate progress and issues only to the
Oversight Group.

SPFL identified and interviewed past members of Oversight Groups to determine what
their roles were in the project, the process they followed to initiate and plan projects, and
the potential impact of their roles. This information was categorized in accordance with
the process groups (PGs) of the PMBOKTM.

PG-1 Initiation
• Identify Project Manager – This step is not performed at this early stage, but
rather delayed until right before the project was scheduled to begin to save costs
• Create Project Charter – A project charter has not been created for any project.
• Identify Stakeholders – The Oversight Group considered themselves and Senior
Management to be the only stakeholders of any project.
• Determine Project Objectives – High-level objectives were created by the IT
Director and were always focused on the IT objectives
• Determine Assumptions and Constraints – IT assumptions and constraints were
considered.
• Create Project Scope Statement – Created by IT Director & Oversight Group

PG -2 Planning
• Create full-scale project scope statement – Only a preliminary scope statement
was used.
• Create Work Breakdown Structure (WBS) – The project team created high-level
(i.e. summary task level) tasks at the onset of project execution and each
individual member responsible for the oversight of task work kept mental tabs of
what subtasks needed to be performed. These weren’t documented in any global
WBS.
• Create User Requirements documentation – Oversight Group dictated what the
system requirements would be without input from end-users. These requirements
were not documented but instead were communicated orally to the project
manager.
• Project Budget – Oversight Group created project budget based on an expert-
opinion assessment by the IT Director of an approximate project budget. It was
understood that budgets were ballpark figures that that additional money would be
appropriated for projects when needed.

17

• Project Schedule – A series of expected milestones was created by the IT Director
via communication with the product vendor. This milestone chart also listed the
expected project due date.
• Risk Plan – The Oversight Group documented risks via communication with
product vendor. No formal, detailed, project risk plan was developed.
• Communication Plan – Communication plans were felt to be unnecessary since
the project manager, once hired, would be required to meet with the oversight
Directors on an as-needed basis.
• Procurement Plan – The IT Director remained in charge of procurement having
prior knowledge of potential vendors.
• Quality Plan (including end-user requirement documentation & user acceptance
testing) – Oversight Group members felt they could address any functionality
requirements/issues and did not want to involve the nursing staff. Quality control
was left to the individual project team member to police his or her own work.
• Project Management Plan – No project management plan was documented.
Management of the project was done on an ad-hoc basis.

PG -3 Execution
Since execution of a project is so specific to the nature of each individual project, there is
no value-added way to compare As-Is to Should-Be from the standpoint of a repeatable
improvement to a process.

PG -4 Monitoring & Control
• Earned Value Analysis (EVA) – EVA measurements for cost and schedule
tracking and control were not made during the lifecycle of the project nor did the
data exist to allow them to be made.
• Status meetings – Held once per month among the project team to identify
technical issues and progress. Progress was ascertained based on polling team
members currently engaged on tasks for them to give their best guesses as to how
far along in the project they were as well as their best guess at meeting
milestones. Some team members acknowledged that identifying percent
completion of tasks was simply a guess and that milestones that had been reported
by as complete were in fact incomplete. Status was communicated to Oversight
Group only when asked or when the project team felt it had hit a milestone.
• Prototype audits/walkthroughs – Prototypes of GUIs, report formats, etc. were not
created. Adjustments were made after rollouts, based on end-user responses.
• Corrective Action – Corrective action was not taken since schedule and cost were
not being monitored.
• Quality Assurance/Control – Quality control consisted of individuals working to
fix any programming errors found through their own individual testing but system
fixes were made to the system only after it had gone live.
• Change Control – Change control did not exist. Changes were made to project
scope whenever the Oversight Group requested them.
• Scope Control -- The scope of the project and others before it grew after
initialization as more and more functionality development was added to the initial

18

scopes. Budgets were increased at huge rates while delaying the project more and
more.

PG -5 Closeout
• Confirmation that work was done to requirements – Requirements were vague.
The project team would signal an end to the project when they felt they had
addressed the needs of the project, based on whatever requirements the Oversight
Group had given them.
• Gain formal acceptance of the product – No formal acceptance was given. The
project was considered complete once the project team felt it was complete.
• Final performance recording – The lack of user functionality and performance
requirements meant that final performance had not been recorded.
• Record lessons learned – It wasn’t part of the hospital culture to document lessons
learned.

5.1.3 Model Process Audit/Should-Be
Here we’ve identified the ideal state of how projects should be initiated, planned,
executed, and monitored, based on user interviews and user requirement documentation
as well as the PMBOKTM methodology.

According to the PMBOKTM, conducting a project is a repeatable process that follows a
specific methodology. Any deviation from that methodology decreases the chances that
the project will be successful. The following are the required steps in order to comply
with this methodology that exponentially improves the chances of success of a project.

PG-1 Initiation
• Identify Project Manager – A PMP-certified, or at least a project manager trained
to follow the PMBOK must brought on during Initiation when it has been decided
to conduct a project and before any project planning has begun. This is the only
way to ensure that other aspects of Initiation and Planning are conducted in
accordance with the PMI methodology.
• Identify Stakeholders – Project stakeholders by definition are those individuals
who can be positively or negatively impacted by a project and who have a vested
interest in the project’s success. They also provide subject matter expertise in
their domains which allows the project team to create requirement documents,
substantiate acceptance criteria, determine functionalities and system response
requirements, and risks. They must be identified at this early level to be able to
provide information for planning.
• Determine Project Objectives – High level projects must be identified by the
sponsor and the top level of management so they can be concisely flowed down to
project teams.
• Determine Assumptions and Constraints – Full system functionality requirements
must be identified (interfaces with other systems, system response times,
limitations to project budget, limitations to project scope, duration constraints)

19

• Create Preliminary Project Scope Statement – It is the duty of the project manager
to create a preliminary scope statement based on project objectives and
constraints.

PG -2 Planning
• Create full-scale project scope statement – It is the project manager’s duty, along
with the project SMEs, to create the full-scale project scope statement but only
after a preliminary scope statement has been prepared to the client’s satisfaction.
• Create WBS – the project manager is responsible for seeing that a complete, full
WBS is prepared by the project team. The WBS must not only contain summary
tasks but all necessary subtasks so that the project could be followed by anyone
with similar knowledge and be able to follow the progress of the project.
• Create User Requirements documentation – It is the obligation of the project team
to interview end users at all levels to identify requirements and functionalities that
are must-needs, functionalities that are nice to have but users can live without if
necessary, and functionalities that are not needed.
• Project Budget – It is the project manager’s responsibility to create (or at least
lead the creation of) the project budget. It is essential that the project budget be
created using the bottom-up estimating process, following the WBS.
• Project Schedule – It is the project manager’s responsibility to create (or at least
lead the creation of) the project schedule. It is essential that the project schedule
be created using the work breakdown structure.
• Risk Plan – It is the project manager’s responsibility to create (or at least lead the
creation of) the risk plan. It is essential that the risk plan be created using the
work breakdown structure as a guide, broken out in a task-by-task basis.
• Communications Plan – It is the project manager’s responsibility to create the
communications plan, in coordination with the project sponsor, to address the
communication needs of the project stakeholders.
• Procurement Plan – It is the project manager’s responsibility to create the
procurement plan if a boilerplate plan is not in place, or to customize the
boilerplate plan to the specific needs of the project if one is in place.
• Quality Plan (including end-user requirement documentation & user acceptance
testing) – It is the project manager’s responsibility to create the quality plan, in
coordination with the quality manager, to address the requirements of the project
stakeholders.
• Project Management Plan – It is the project manager’s responsibility to create the
project management plan, discussing the type and frequency of project
management oversight activities, escalation thresholds, and possible corrective
action constraints, since these have a bearing on the overall project budget.

PG -3 Execution
N/A

PG -4 Monitoring & Control
• Earned Value Analysis (EVA) – Must be conducted on a monthly basis with
results communicated and explained to the client.

20

• Status meetings – Held once per month to identify technical issues and progress.
Meetings should also be used to discuss/track/identify risks and issues—all things
that would impact rework and project durations.
• Prototype audits/walkthroughs – This must be coordinated with the efforts of QA
and technical (e.g. IT) personnel to ensure that project milestones are fully met
and to minimize possible rework activities.
• Corrective Action – Must be performed on an as-needed basis following each
regular EVA assessment.
• Quality Assurance/Control – Must be performed on an as-needed basis as
specified in the quality plan.

PG -5 Closeout
• Confirmation that work was done to requirements – This is to be conducted by the
project team prior to going live under the auspices of the client.
• Gain formal acceptance of the product – A formal acceptance process must be
followed using acceptance criteria that were developed prior to the onset of the
project and baselined by the stakeholders. Any changes in acceptance criteria
must follow the formal change control process and can subsequently change the
scope, budget, and schedule.
• Final performance recording – Final performance recording of the end product
must be performed and signed off on by the stakeholders.
• Record lessons learned – Lessons learned are to be documented at the end of
every stage as well as the end of the project for future reference/continuous
improvement.

5.1.4 Process Gaps
The following gaps have been identified in the project methodology at <CLIENT> with
recommendations for improvement.

PG-1 Initiation
• Identify Project Manager – Experienced project managers are not brought on in
the project early enough or at all. This effort is contradictory to efforts to
minimize project costs and has contributed to the uncontrolled escalation in costs.
• Create Project Charter – The project charter has not been created and must be
done before any project planning takes place. Creating the charter performs a
number of actions—it gives the project manager the correct level of authority and
background for the project, it forces an identification of the business need,
stakeholders, and assumptions/constraints. It also documents the preliminary
scope of the project.
• Identify Stakeholders – Stakeholder identification was not performed and needs to
be. At <CLIENT>, those stakeholders would be someone from Sr. Management,
the Directors of the various units at the hospital where use of the system would be
required, as well as representatives of the end-users themselves (i.e., Nursing
Supervisors, Patient Care Coordinators (PCCs), etc.). While it is true that the
patients themselves would be impacted by projects, their impact is indirect and

21

their level of knowledge of any project initiative is so minimal as to be non-
existent, therefore, they are not considered to be enough of a stakeholder to have a
voice in planning.
• Determine Project Objectives – Due to the lack of stakeholder identification,
high-level objectives were not considered across the enterprise. It is the
responsibility of the IT Director and Oversight Group to create the high-level
objectives by which the project team would create the lower-order project
objectives prior to documenting the user requirements.
• Determine Assumptions and Constraints – Although assumptions/constraints were
made by Management as well as the project team, documentation of them was not
performed and no validation of them was conducted with the full set of
stakeholders.
• Create Project Scope Statement – The project scope statement was weak in that it
did not provide specific functionality requirements nor discuss what was to be
deemed out of scope.

PG -2 Planning
• Create full-scale project scope statement – Results show that the project teams
were either satisfied with the preliminary scope statement, chose not to develop a
fuller scope statement, or were directed not to create one.
• Create Work Breakdown Structure (WBS) – A detailed WBS, one that contained
not only tasks at the higher summary level, but rather one that went three or four
levels deep, was not developed. When interviewed, each technical person who
had worked on projects had felt that he or she knew enough about what needed to
be done that it wasn’t necessary to develop a WBS. This is a misconception and
almost always leads to incorrect budget and schedule estimation as well as
undocumented risks.
• Create User Requirements documentation – Management and/or the Oversight
Group dictated what the requirements of the systems to be implemented would be.
Input was not obtained from end-users regarding functionality requirements,
reporting needs, factors critical to quality, acceptance criteria, etc.
• Project Budget – The Oversight Group and not the project team created the
budget. A budget was assigned—the dollar amount chosen was a dollar level that
the oversight Board felt comfortable with after getting system quotes from
vendors. Even with this suboptimal method, dollars could have been apportioned
downward to tasks based on some percentage obtained from expert opinion of
project SMEs or the IT Manager. The correct method is that the budget should
have been created using the bottom-up estimating methodology whereby the WBS
is broken out into sub tasks and each sub task’s budget is estimated. The budget
for each task is the sum of its respective sub tasks; the budget for each summary
task is just the sum of its respective tasks, and the total budget of the project is
then the sum of its respective summary tasks.
• Project Schedule – Neither the Oversight Group nor the project managers created
a project schedule. Instead, an arbitrary deadline in the future was set and efforts
were made to try to hit that date. It was felt by all technical staff interviewed that
the deadline served more of a guide and not a requirement. A project schedule,

22

broken out in a task-by-task basis, must be created and efforts made to adhere to
it, once baselined.
• Risk Plan – Since the majority of stakeholders were never identified, a full risk
plan discussing task-specific risks and their respective risk planning techniques
was not created. This is one of the causes for rework.
• Communication Plan – No plan was created. While the lack of a plan won’t
contribute to schedule and/or cost variances, it is good practice to put one together
so that all stakeholders can be kept informed and to aid with end-user buy-in and
ownership as part of change management.
• Procurement Plan – No plan was created. Lack of a plan can contribute to
schedule and/or cost variances in the form of lack of mitigation of risks; any
project where non-adherence to the schedule by subcontractors and/or vendors
must have such a plan.
• Quality Plan – No plan was created and this is evident by the amount of rework
and end-user frustration. All projects must have a quality plan in place and must
establish quality assurance measures to follow. In addition, the project team must
sit with the end-user community to establish acceptance criteria and minimally-
acceptable performance criteria. No criteria were documented.
• Project Management Plan – No formalized plan was created. The impact of not
having a plan is twofold. First, there is a lack of adherence to a pre-set number of
status meetings, reports, formats, etc., that can give rise to many and ill-timed
impromptu meetings. Second, lack of an established number of meetings, reports,
formats, etc. impacts the budget. Every time an unplanned and unbudgeted
meeting is held it money is removed from the budget and this gives rise to cost
variances.

PG - 3 Execution: N/A

PG - 4 Monitoring & Control
• Earned Value Analysis (EVA) – EVA measurements for cost and schedule
tracking and control were not made during the lifecycle of the project. Lack of
EVA means that project performance against the schedule and against the budget
were never tracked and this accounts for the large rises in cost and schedule
variances. This, tied in with the lack of proper estimating, would account for the
majority of budget and schedule waste.
• Status meetings – Not held correctly and results not communicated properly.
Held once per month to identify technical issues and progress. Progress was
ascertained based on polling team members currently engaged on tasks for them
to give their opinions of percent completion as well as meeting milestones. Some
team members acknowledged that identifying percent completion of tasks was
simply a guess and that milestones that had been reported by as complete were in
fact incomplete. Status meetings should identify work completed to date, issues,
corrective actions needed to be taken, risks, and identify near-term
task/data/information handoffs and milestones. Progress against the schedule
should be performed using EVA.

23

• Prototype audits/walkthroughs – None were conducted. It is essential that end
users be allowed to review, validate, and accept prototypes to minimize rework,
maintain the integrity of the project scope, and continue user involvement and
buy-in.
• Corrective Action – No action was taken to correct schedule and/or cost
variances, accounting for huge cost and schedule variances.
• Quality Assurance/Control – Quality assurance was not performed. Quality
testing was performed as an end result of the roll-out which accounts for the
rework that was a major part of most projects.
• Change Control – No change control process was documented or enacted. Scope
changes were made often regardless of budget and schedule.

PG -5 Closeout
• Confirmation that work was done to requirements – Not performed.
• Gain formal acceptance of the product – Formal acceptance was not given and
acceptance criteria were not solicited.
• Final performance recording – Not performed
• Record lessons learned – Not performed

5.2 “Critical-To Characteristics” and DPMOs
The critical-to-cost (CTC) variable for the process is the project cost variance (CV),
specifically, the uncorrected variance. A variance can be uncorrected either because it
hasn’t been controlled—i.e. ignored and not brought back in line with expenditure
forecasts—or it is no longer controllable—the attempt to bring it back in line with
expenditure forecasts happened too late and any attempt to correct the variance will be
too costly, not feasible, or the expenditure forecast itself (from which CV is derived) was
arbitrary as in the case of projects at <CLIENT>. The DPMO here is defined as the
number of uncorrected cost overage events per opportunity. Since actual to planned
expenditures are compared on a monthly basis, each monthly observation and comparison
is considered one opportunity. Thus defined, the DMPO, based on Figure 4 is

1,000,000 x (1 observed defect/monthly observation) = 1,000,000.

Based on the observations shown in Figure 4, negative cost variances on average across
the five past projects (signifying an over budget condition) had already risen by the first
observation and the variances grew larger for each successive observation. No attempt at
corrective action was taken.

The critical-to-schedule (CTS) variable for this process is the project schedule variance,
specifically the uncorrected variance, defined similarly to the CTC. The DPMO here is
defined as the number of uncorrected schedule slippage events per opportunity. Since
actual to planned performance is compared on a monthly basis, each monthly observation
and comparison is considered one opportunity. Thus defined, the DMPO, based on
Figure 5 is

1,000,000 x (1 observed defect/monthly observation) = 1,000,000.

24

Based on the observations shown in Figure 5, negative schedule variances on average
across the five past projects (signifying a schedule delay condition) had already risen by
the first observation and the variances grew larger for each successive observation. No
attempt at corrective action was taken.

5.3 Future Performance Levels
Arguably, the ideal target values for CV% and SV% respectively are in the range 0.0 to
0.05, that is, on budget and on schedule to slightly under budget and slightly ahead of
schedule. However, project budgets and schedules are estimates, even at their best, and
are also stochastic in nature; the duration of any repeatable task (and hence its cost) will
fall somewhere within a log-normal distribution. The target variance might also be
dependent on the nature of the project as well. While there will be some projects that
must be completed on time, regardless of cost, there might be others that must be
completed within budget, regardless of schedule. The future performance levels dictated
by this project treat the majority of those projects that fall somewhere within these two
extremes.

It is reasonable for an organization that has gone from an ad-hoc project management
approach to something more formalized to fall within a target CV% and SV% range of
0.0 ± .10. Future initiatives to raise the organization from a project management maturity
model (PMMM) Level 2 (formalization of the project management methodology) to a
higher level can be associated with continuous improvement to reduce this range even
further. However, a target CV and SV of 0.0 ± .10 is a sufficient target for future
performance levels within which to control projects.

6.0 Control Phase
6.1 Maintaining The Gains Made
As noted in this document there are several places where deviations from the standard
project management model existed. By focusing on two areas, those of budget/schedule
estimate and budget/schedule monitoring and control, we demonstrated the very positive
effect that best practices in each of these yield.

Figure 8 contains the suggested future state process map to be followed in order to keep
the project budget and schedule in control.

Nursing

25

Tech Support

Contractor/
Internal PM

Management

Figure 8. Future state process map for budget/schedule estimation, monitoring, and
control.

There are steps in place to control budget and schedules as a part of ongoing control:
1. The use of Basis of Estimate Sheets for project duration and budget estimating on
a task-by-task basis (See Appendix G).
2. The use of Time-Phased Budget Sheets (aka Labor Planning Sheets) to allow for
proper monitoring and control (See Appendix H).
3. The use of Earned Value Analysis at regular, monthly intervals to determine
whether budget and/or schedule are in or out of control.

26

4. Project control charts used to track normalized cost variance (CV%) and
normalized schedule variance (SV%) and also to plot CV% against SV% to
provide a quick visual determination of whether corrective action and/or
escalation is needed.
5. The use of monthly status reports detailing progress to date, expenditures to date,
risks, issues, successes, and other project data pertinent to stakeholders.

In order to ensure the stability of gains made in this project, we submit that the following
additional items should be put in place:

• Policy changes – Corporate policies should be changed with respect to how projects
are planned. The responsibility of budgets and schedules should be that of the project
manager and project team and should be conducted in the absence of Senior
Management so as not to bias the estimate, with final approval being reserved for
Senior Management. If Management were to require that an independently derived
budget be reduced it must be reduced by trimming scope and not arbitrarily cutting
costs. To do so would be to invite schedule and cost padding—artificial increases
whose sole purpose is to counteract arbitrary decreases.
• New standards – Standards must be put in place so that project teams and
stakeholders realize that slippage and budget overruns should be the exception and
not the rule. Changes in scope must also be limited and allowed only when of the
utmost concern since these impact schedule, cost, quality, and the stability of the
overall project and product. Scope changes must be reviewed by all stakeholders so
that impacts to all affected areas, both positive and negative, can be voiced.
• Modify procedures – Project management procedures must be changed so that
experienced (or at least PMBOK-familiar) project managers are allowed to lead
projects and so that these same project managers are allowed to follow the de facto
management methodology of the PMBOKTM.
• Modify quality appraisal and audit criteria – Stakeholder representatives must be
allowed to create acceptance criteria and audit prototypes throughout the project to
ensure minimal rework.
• Update project budget estimation models – It is understood that budget estimation is
not an exact science. However, it must be conducted to yield the best-suitable budget
estimate for any project at hand. Bottom-up methodology yields a more accurate
project budget estimate than any other method and should always be used.
• Utilize the accounting system – The hospital’s accounting system is capable of
producing monthly project cost reports, showing hours to date and expenditures to
date. Project managers must be able to receive these reports on a timely, monthly
basis in order for them to proactively monitor project budgets and schedules and to
take corrective action, if necessary, to bring expenditures and schedule in line with
planned progress.
• Τraining – If PMP-certified contract project managers are not to be hired for every
project the hospital must ensure that internal project managers are properly trained to
follow the PMBOK methodology. It is beneficial that an overview of the project
management methodology also be given to representatives of Management with a
focus on how project management relates to enhancing ROI.

27

7.0 Conclusion
The result of the project was highly noticeable to the CFO and the rest of Senior
Management and acknowledged the hazards of not following a standardized project
management model. While it may have been felt by some that following a project
management methodology should be limited in order to save project costs (an effort to
add to the hospital’s bottom line), it was evident that the lack of proper planning and
oversight efforts actually attributed to a siphoning off of the hospital’s bottom line
towards escalating project overspending. As a result, the CFO is seeing a reduced
demand of additional hospital funding toward projects. <CLIENT> has a better
estimating, monitoring, and control process in place and acknowledgement (and
communication thereof to the nursing staff) of issues related to end-user requirements
have created an eagerness on their part to assist in future implementations. At this point,
the estimated hard-dollar savings from this project are in excess of $350,000 per year
(based on six active projects) and that is a direct improvement of the hospital’s bottom
line. There is no estimate on soft dollars but quantitatively, as already acknowledged,
there has been an increase in the morale of the nursing staff due to the acknowledgement
that their input will be used in future planning efforts.

We have identified new policies and practices for Management to implement as well as
other project management methodology improvements to capture even more value.
These are identified in the FMEA worksheet and include:
• Creating a repeatable Project Selection process whereby projects and scope
modifications will be chosen based on a number of objective criteria such as ROI and
goodness of fit with strategic/financial objectives.
• The use of a Risk Management Plan and Risk Management Process to identify and
ameliorate risks before they arise.
• User requirement interviews and documentation to minimize project rework and
improve end-user buy-in.
• A Quality Management Plan consisting of intermittent quality audits by
representatives of stakeholder groups.
• The implementation and use of a formal Change Control process, used to consider the
benefits and detriments to the project (scope, budget, ROI, functionality, etc.) of any
proposed scope changes made once the project has begun.

28

Appendix A - Project Charter
Project Improvement of Cost and Schedule Control at <CLIENT>
Created By Ed Kozak Date 12/29/2009
Phone 555- 111-1111 Email EKozak@SuccessfulProjectsForLeaders.com

Project Name/Number: Improvement of Cost and Schedule Control at <CLIENT>/
Project No. 09-2912
Sponsoring Organization: Finance
Project Sponsor: Name: Larry Kristufek Phone: 555-555-5555
Office Location: 910 Mail Stop: N/A
Project Black Belt: Name: Kevin Ross Phone: 555-555-5555
Project Green Belt: Name: Ed Kozak Phone: 555-111-1111
Key Team Members (Name) Title/Role Phone Office Location
Rodman Goodwin DBA 555-257-6666
Benyuende Nacanabo Sr. Programmer 555-257-6669
Jim Richards Network Administrator 555-257-6612
Sean Lawless Director 555-257-1461

Principal Stakeholders (Name) Title/Role Phone Office Location
Giselle Roberts CEO 555-257-5555 1010
Robert Jones CNO 555-257-1111 511
Shevaun Johnson CIO 555-257-1221 742
Jennifer Gee IT Mgr. 555-257-1331 731
Mike Brow PCC – PICU 555-257-1441 254
Lena Sjoblom PCC – Psych 555-257-1001 678
Charles Leach PCC - SICU 555-257-1991 512

Date Chartered: Project Start Date: Target Completion Date:
12/29/09 1/4/10 8/13/11
Revision: 1 Number: 3 Date: 12/29/09

Sponsor Approval Signature:

29

Project Name/Number: PM Process Improvement/Project No. 09-2912

Project Mission Statement: Reduce project schedule slippage on average by 50% (historically, project
schedule variances have been 50%, on average) and reduce actual project expenditures on average by 50%
(historically, project cost variances have been 50%, on average).

Problem Statement: The Federal Government has mandated that health care providers who fail to adopt
certified electronic medical record (EMR) systems or can’t demonstrate “meaningful use” by 2015 will find
their Medicare reimbursements cut, and they will lose the chance to receive Medicare incentive payments
for implementation. Historically, the hospital has shown an inability of meeting its internal project
deadlines time and time again, and the expenditures of each project that have been undertaken have grown
exponentially from their original estimates, making any future project cost and time estimates seemingly
meaningless.

Project Scope: The methodology of managing projects will be investigated, with particular attention being
paid to determine the underlying causes to the variances between estimated and actual project budgets and
schedules. Specific interfaces to be addressed in this project are contributions by the contract project
managers, the Project Oversight Group members, and the end-users (nursing staff).

Project Objectives:
• Investigate the As-Is project management methodology
• Compare As-Is to the PMI standard
• Determine underlying causes to the variances between estimated and actual project budgets and schedules
• Make recommendations to correct deficiencies in As-Is methodology
• Implement recommendations
• Monitor the new process during new implementation

Business Need Address By Project:
Less project overspending => Improved annual budgetary forecasting abilities and free cash flow for other
investments
Improved implementation cycle time => increased patient diagnosis & release => reduction in non-
Medicare-covered costs
Improved implementation cycle time => higher probability of meeting Government mandate requirements
for implemented EMR => lower probability of losing Government Medicare Subsidization
Improved implementation cycle time => Improved hospital free cash flow and profitability

30

Significant Milestones Project Deliverables:
Report detailing As-Is/Should-Be findings,
Completion of Historical Data Collection and Analysis Recommendation for Improvement Project.
Time-phased budget and detailed project
Completion of Underlying Project Planning schedule of underlying project
Management approval to proceed with next
Completion of Improvement Project Planning and Approval phase of improvement project.
EVA report with control chart data for first six
Completion of Initial Data Collection and Analysis months of underlying project.
EVA report with control chart data for
Completion of Intermediate Data Collection and Analysis intermediate six months of underlying project.
Revised project budget and schedule for
Completion of Rebaselining of Underlying Project remainder of underlying project.
EVA report with control charts for last
Completion of Final Data Collection and Analysis scheduled six months of underlying project.
Final report including documentation of
Improvement Project Closeout lessons learned.

31

Project Evaluation Form
Score Interpretation

10 Sponsorship

3 External Customer
5 Shareholder
3 Employee or Internal Customer
0 Other (supplier, environment, etc.)
21 - Total Benefit

Availability of resources other than
10 team
1
10
Scope in terms of Black Belt effort

10 Deliverable

2
0 Time to Complete

10 Team

10 Project Charter

5 Value of Six Sigma Approach

76 Total

1
The required projected return was calculated to be $83,333*18 months*468 hours/2880
hours/1 = $243,749. The estimated project return was calculated to be $462,993.
2
The six sigma project itself was roughly three months of elapsed project time. However,
owing to the fact that the six sigma project was required to piggyback on an
implementation project in the hospital with an estimated duration of 18 months, the six
sigma project calendar time took almost 6 times as long to complete as its project time.
Therefore, it was assigned a number of zero.

32

Appendix B - Cause-And-Effect Diagram

Cause - Project Lasts Longer Than Anticipated

Project Scope Changing

Innacurate Schedule Estimate
Cause - Inaccurate Cost Estimate Used
Project Team Working Slower than Anticipated

Problems Delaying Project
Wrong Method Used
Project Needs Rework
Inexperienced Estimator
A
B C Scope Changed/Original Estimate no Project Cost
Longer Valid & Not Updated Variance at
50%

Methodology Not Being Followed Team Issues

Inexperienced PM Team Too Inexperienced

Contract PM Unmotivated Project Work Doesn’t Match Skills

Cause - Project Management Cause - People

Project Needs Rework: No QC, Problems Delaying Proj.: No Risk Project Scope Changing: Poorly-
Poorly-Defined End-User Reqs. Plan/Monitoring, Poor-Risk Defined Scope, No Change
Not Addressing End-User Reqs. Planning/Monitoring Control, No User Acceptance
Reqs.

A – No QC B – Poorly-Defined Requirements C – Not Adhering To Requirements

33

Appendix C - Project WBS

I. Historical Data Collection
A. Conduct Interviews
B. Conduct Interview Analysis and Assessment
C. Gather Historical Project Information
D. Historical Project Methodology Review
E. Historical Project Time Sheet Review
F. Historical Project Earned Value Analysis

II. Analyze Results
A. Report As-Is Vs. Should-Be Findings
B. Make Recommendations for Improvement Project
C. Get Mgmt Approval
D. Execute Recommendations

III. Underlying Project Planning
A. Time-Phased Budget Preparation
B. Project Schedule Preparation

IV. Current Project Initial Planning
A. Current Project Time Sheet Review
B. Current Project Earned Value Analysis

V. Analyze Results
A. Make Recommendations for Next Phase
B. Get Mgmt Approval
C. Execute Recommendations

VI. Intermediate Data Collection
A. Time Sheet Review
B. Perform Earned Value Analysis

VII. Analyze Results
A. Make Recommendations
B. Get Approval
C. Execute Recommendations

VIII. Re-Baseline Project
A. Re-estimate project costs on task-by-task basis
B. Re-estimate project task durations

IX. Final Data Collection
A. Time Sheet Review
B. Earned Value Analysis

X. Close Out Improvement Project
A. Confirm Work is done to requirements
B. Get formal acceptance
C. Create final report
D. Create lessons learned
E. Index and archive all project records
F. Release resources

34

Appendix D – Project Schedule

Task Name Duration Start Finish
Cost and Schedule Improvement 417 days Mon 1/4/10 Tue 8/9/11
Historical Data Collection 18 days Mon 1/4/10 Wed 1/27/10
Conduct Interviews 7 days Mon 1/4/10 Tue 1/12/10
Interview Analysis and Assessment 2 days Wed 1/13/10 Thu 1/14/10
Gather Historical Project Information 2 days Fri 1/15/10 Mon 1/18/10
Historical Project Methodology Review 5 days Tue 1/19/10 Mon 1/25/10
Historical Project Time Sheet Review 1 day Tue 1/26/10 Tue 1/26/10
Historical Project Earned Value Analysis 1 day Wed 1/27/10 Wed 1/27/10
Analyze Results 6 days Thu 1/28/10 Thu 2/4/10
Report As-Is Vs. Should-Be Findings 4 days Thu 1/28/10 Tue 2/2/10
Make Recommendations for Improvement
Project 1 day Wed 2/3/10 Wed 2/3/10
Get Mgmt Approval 0 days Thu 2/4/10 Thu 2/4/10
Execute Recommendations 0 days Thu 2/4/10 Thu 2/4/10
Underlying Project Planning 4 days Thu 2/4/10 Tue 2/9/10
Time-Phased Budget Preparation 2 days Thu 2/4/10 Fri 2/5/10
Project Schedule Preparation 2 days Mon 2/8/10 Tue 2/9/10
Current Project Initial Planning 2 days Fri 7/30/10 Mon 8/2/10
Current Project Time Sheet Review 1 day Fri 7/30/10 Fri 7/30/10
Current Project Earned Value Analysis 1 day Mon 8/2/10 Mon 8/2/10
Analyze Results 4 days Tue 8/3/10 Fri 8/6/10
Make Recommendations for next phase 1 day Tue 8/3/10 Tue 8/3/10
Get Mgmt Approval 0 days Wed 8/4/10 Wed 8/4/10
Execute Recommendations 0 days Fri 8/6/10 Fri 8/6/10
Intermediate Data Collection 112 days Fri 8/27/10 Mon 1/31/11
Time Sheet Review 111 days Fri 8/27/10 Fri 1/28/11
Time Sheet Review 1 1 day Fri 8/27/10 Fri 8/27/10
Thu
Time Sheet Review 5 1 day 12/30/10 Thu 12/30/10
Mon
Perform Earned Value Analysis 111 days 8/30/10 Mon 1/31/11
Perform Earned Value Analysis 1 1 day Mon 8/30/10 Mon 8/30/10
Perform Earned Value Analysis 4 1 day Mon Mon 11/29/10

35

11/29/10
Perform Earned Value Analysis 5 1 day Fri 12/31/10 Fri 12/31/10
Analyze Results 3 days Thu 2/3/11 Mon 2/7/11
Make Recommendations 1 day Thu 2/3/11 Thu 2/3/11
Get Approval 0 days Fri 2/4/11 Fri 2/4/11
Execute Recommendations 0 days Mon 2/7/11 Mon 2/7/11
Re-Baseline Project 2 days Mon 2/7/11 Tue 2/8/11
Re-estimate project costs on task-by-task
basis 2 days Mon 2/7/11 Tue 2/8/11
Re-estimate project task durations 2 days Mon 2/7/11 Tue 2/8/11
Final Data Collection 112 days Fri 2/25/11 Mon 8/1/11
Time Sheet Review 111 days Fri 2/25/11 Fri 7/29/11
Mon
Earned Value Analysis 111 days 2/28/11 Mon 8/1/11
Earned Value Analysis 1 1 day Mon 2/28/11 Mon 2/28/11
Close Out Improvement Project 6 days Tue 8/2/11 Tue 8/9/11
Confirm Work is done to requirements 0.5 days Tue 8/2/11 Tue 8/2/11
Get formal acceptance 0 days Tue 8/2/11 Tue 8/2/11
Create final report 5 days Tue 8/2/11 Tue 8/9/11
Create lessons learned 2 days Tue 8/2/11 Thu 8/4/11
Index and archive all project records 0.5 days Tue 8/9/11 Tue 8/9/11
Release resources 0 days Tue 8/9/11 Tue 8/9/11

36

Appendix E. Project Gantt Chart

Appendix F – Resource Assignment Matrix
Responsibility
Nursing IT
Historical Data Collection SP4L staff Mgmt Staff
Conduct Interviews P S S S
Interview Analysis and Assessment P S S S
Gather Historical Project Information P
Historical Project Methodology Review P S S
Historical Project Time Sheet Review P
Historical Project Earned Value Analysis P

Analyze Results
Report As-Is Vs. Should-Be Findings P
Make Recommendations for Improvement
Project P
Get Mgmt Approval P P
Execute Recommendations P

Underlying Project Planning
Time-Phased Budget Preparation P S
Project Schedule Preparation P S

Current Project Initial Planning
Current Project Time Sheet Review P
Current Project Earned Value Analysis P

Analyze Results
Document And Make Recommendations P
Get Mgmt Approval P P

Intermediate Data Collection
Time Sheet Review P
Perform Earned Value Analysis P

Analyze Results
Document And Make Recommendations P
Get Approval P P

Re-Baseline Project
Re-estimate project costs on task-by-task basis P S
Re-estimate project task durations P S

Final Data Collection
Time Sheet Review P
Earned Value Analysis P

Close Out Improvement Project
Confirm Work is done to requirements P P
Get formal acceptance P P

Create final report P
Create lessons learned P
Index and archive all project records P
Release resources P

P = Primary, S = Secondary

41

Appendix G – Basis of Estimate Sheet

BASISOF ESTIMATE SHEET SHEET OF
PROPOSAL NO. DATE PREPARED:
TASK/SUBTASK TITL E: WBS NO.

Task Description:

Method of Estimate/Assumptions/Adjustment Factors:
Engineering or Tech. Judgment
Past Experience(Bottom Up)
Other (Parametric, Apportioned)

Discuss Potential Risks/Severities/Triggers/Responses AssociatedWith Task and Estimate:

For Non-Labor Estimates
Calculations of Labor Hours: Total Estimated Price:

Prepared by: Reviewed by:
Resource Estimator Proposal Manager

42

L A B O R L A N N I N G S H E T
AppendixPH – Time-PhasedE Budget Sheet
P R O P O S A L T IT L E : R F P / N o .:
DU E DAT E : P R O P O SA L M G R . : W B S No.: 1
ST A R T D AT E : T A S K /S U B T A S K T I T L E : P R O P . N o .: 1 20 0
E ND DAT E : TY PE : N o o F M O N T H S: 1 PR O P O S A L T IT L E :
C L I N /W B S / T A S K 1 HOURS B Y M O N T H /P E R IO D C L IN /W B S /T A S K
NO . 1 2 3 4 5 6 7 8 9 10 11 12 13 NO.
Y E A R /F Y TO TAL YE A R /F Y
C a t e g o r y /N a m e C a t e g o ry / N a m e

M O NTHL Y TO TAL = 0 0 0 0 0 0 0 0 0 0 0 0 0 0 M O NTH LY T O





OV E RALL TO TAL = 0 0 0 0 0 0 0 0 0 0 0 0 0 0 O VE R A L

Improvement of Hospital Project Cost and Schedule Mgmt Final Rpt

Improvement of Hospital Project Cost and Schedule Mgmt Final Rpt

Recommended

Recommended

More Related Content

What's hot

What's hot (20)

Viewers also liked

Viewers also liked (20)

Similar to Improvement of Hospital Project Cost and Schedule Mgmt Final Rpt

Similar to Improvement of Hospital Project Cost and Schedule Mgmt Final Rpt (20)

More from Ed Kozak

More from Ed Kozak (7)

Recently uploaded

Recently uploaded (20)

Improvement of Hospital Project Cost and Schedule Mgmt Final Rpt