• Save
Improvement of Hospital Project Cost and Schedule Mgmt  Final Rpt
Upcoming SlideShare
Loading in...5
×
 

Like this? Share it with your network

Share

Improvement of Hospital Project Cost and Schedule Mgmt Final Rpt

on

  • 1,652 views

Of pressing concern to the CFO of our client hospital were the spending issues and schedule ...

Of pressing concern to the CFO of our client hospital 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 so that it could move forward with the EMR project successfully. 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.

Statistics

Views

Total Views
1,652
Views on SlideShare
1,649
Embed Views
3

Actions

Likes
1
Downloads
0
Comments
0

2 Embeds 3

http://www.linkedin.com 2
https://www.linkedin.com 1

Accessibility

Categories

Upload Details

Uploaded via as Adobe PDF

Usage Rights

© All Rights Reserved

Report content

Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel
  • Full Name Full Name Comment goes here.
    Are you sure you want to
    Your message goes here
    Processing…
Post Comment
Edit your comment

Improvement of Hospital Project Cost and Schedule Mgmt Final Rpt Document Transcript

  • 1. Project Management Process Improvement at <CLIENT> CREATED BY: ED KOZAK SUCCESSFUL PROJECTS FOR LEADERS 16 EAST BURLINGTON AVENUE LAGRANGE, IL 60525 FOR <CLIENT>
  • 2. Executive SummaryOf pressing concern to the CFO of <CLIENT> were the spending issues and scheduleslippages of internal implementation projects--issues that he felt contributed to thecurrent cash flow problem of the hospital that would grow to an even greater problem ifEMR capabilities weren’t fully implemented and operational by 2015. The CFO solicitedexternal help to 1) validate why there has existed such a level of overspending andschedule slippage on projects, 2) propose a recommendation for solutions, and 3) changethe 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 whatwent wrong with that implementation and to improve how projects in general would beconducted at <client> so that it could move forward with the EMR project successfully.ProblemUsing the Six Sigma process of Define-Measure-Analyze-Improve-Control SP4Ldetermined what the priorities were for Management. We then chartered a project andproceeded to understand and define the problem. Through surveys and interviews withend-users, technical staff, and oversight committees, as well as historical project reviewsand data gathering, we were able to focus on the real issues at hand. To help clarify thesituation, we mapped the project Initiation-Planning-Execution-Control-Closing processfor internal projects, identifying issues as we proceeded. Eventually, the measurementand analysis processes pointed to the fact that we had a real issue that was a majordeviation from the standard methodology for budget/schedule planning and control.Fortunately, we had a clear understanding of industry best practices and good supportfrom Management to help research and resolve the problem.FindingsOur 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 adhoc manner projects have been planned and controlled to follow the de facto standardresulted in a low-cost solution to control project expenditures. We also identified asevere quality issue, based on feedback from the end-user community, that can beimmediately addressed and rectified from this point forward. While it is early in the post-implementation phase, we are seeing improvements in cost expenditures, scheduleslippages, and end-user satisfaction.ConclusionBy using a systematic approach, we identified several areas in the project Initiation-Planning-Execution-Control-Closing process that needed modification. The net result isbetter project cost and schedule performance, leading to better cash flow budgeting andplanning, with an expected savings of more than $350,000 annually as well as improvedacceptance and ownership by the end-users. Based on the proactive response to theirissues, the CFO, CNO, and PCCs are satisfied and are serving as excellent centers ofinfluence for the rest of Senior Management and the nursing staff, respectively. 2
  • 3. 1.0 Introduction/Problem Statement:When the CFO of <CLIENT> learned of the Federal Government mandate that healthcare providers who fail to adopt certified electronic medical record (EMR) systems orcan’t demonstrate meaningful use by 2015 will find their Medicare reimbursements cutand 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 haddubbed the latest implementation fiasco. The first part of their EMR implementationwent beyond its scheduled due date, and, when it finally went live, was full offunctionality problems. This implementation created an immense amount of additionalwork for the nursing staff, despite it being implemented to reduce work and speed up thepatient care process. The nursing staff (PCCs, RNs, LPNs, CNAs) bemoaned the factthat the system didn’t provide them with the functionality they needed (some inputscreens did not allow all relevant data to be entered while others required irrelevant dataand would not let the staff proceed until it was entered), required 10 minutes to load, hadpoor response times, was not able to communicate with other packages used at thehospital to retrieve information (or retrieved incorrect information), didn’t provide theability to print reports in their required formats, and sometimes completely losteverything that the staff had spent the last twenty minutes entering into the system. Thefrustration of the nursing staff was high since they were still required to use the system inits current state, but needed to duplicate every entry on paper so that importantinformation would be safe as well as compliant with Government regulations, and it wasfelt that buy-in of any new modules for EMR implementation would be difficult. Tomake matters worse in the eyes of the CFO, rumors had been circling that some of thenursing staff were talking about unionizing.Not only was the CFO concerned about meeting that Government requirement todemonstrate meaningful use but also felt that the six projects conducted on average by thehospital per year were costing it much-needed cash flow. The hospital had shown aninability to meet internal project deadlines time and time again and each time theexpenditures of each project had grown exponentially from their original estimates. Itwas a nightmare from an operational budgeting standpoint since previously-allocatedfunds had to be reallocated to projects so they could be completed. The CFO disliked thefact that any future project estimates would be similarly worthless from a forecastingstandpoint.The hospital had always relied on Federal and State support to meet its budgets but theeconomic downturn had created budgetary problems for these levels of the Governmentand money was taking longer and longer to flow to the hospital, forcing cuts and otherdrastic measures within it.Up until this point the CFO and other representatives of Senior Management had felt thatthe majority of projects conducted at <CLIENT> had been successes, based oninformation that had been communicated upwards. It was their understanding that only afew past projects had had problems and the blame had always been placed by the 3
  • 4. functional Oversight Group—usually the Chief Nursing Officer (CNO) and two hospitalVPs from varying departments (whichever departments were tasked with doing themajority of the work) appointed by Senior Management to plan the projects (budget,deadline, functionality and report formats)—on poorly-selected internal project managersor external PMs that the hospital had contracted with to do the job. When an internalproject manager was appointed, the hospital suffered from what was known as the haloeffect. It was always felt that a nurse be the project manager since he/she could bringrelevant subject matter expertise to the table. The nurse/PM chosen also had experienceoutside of nursing, such as IT, for example, but had no project management experience oreven a basic understanding of project management principles. Furthermore, in everycircumstance when this was done, the nurse lacked relevant nursing experience. Forexample, the nurse/PM appointee for the last project had rehab/sub-acute experience butno beside care experience. The complaints and pushback from the nursing staff had shednew light on this altogether and it didn’t take a rocket scientist to realize that the problemwas something greater internally and not solely due to poor project manager selection.Although lack of project management experience and the frustration of the nursing staffwere concerns to the CFO, what was on the forefront of his mind were the spendingissues and schedule slippages--the former a pressing concern to deal with the current cashflow of the hospital and the latter a pressing concern to deal with future cash flows ifEMR weren’t fully implemented and operational by 2015. The CFO solicited externalhelp to 1) validate why there has existed such a level of overspending and scheduleslippage on projects, 2) propose a recommendation for solutions and 3) change theexisting 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 whatwent wrong with that implementation and to improve how projects in general would beconducted at <CLIENT> so that it could move forward with the EMR projectsuccessfully. We chose to utilize Six Sigma in our approach.2.0 Project Initiation and Planning2.1 Project ObjectiveBased on the voice of the customer (CFO, nursing staff), it was clearly evident that thereare 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 beyondthe scope of one single six sigma project. In addition, based on how the need for reworkwas identified to date for hospital projects and the difficulties that would be incurred inobtaining good process control charts (discussed in Section 4.0), the objective of thisimprovement project was focused on the following specific goals: • Reduce project schedule slippage by 50%, and • Reduce actual project expenditures by 50%. 4
  • 5. It is estimated that doing so would improve project cycle times and would decreaseunwarranted project over-expenditures by $1,200,000 annually across all future projects.2.2 Project ScopeThe 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 A2.4 Project Validation Analysis2.4.1 Causes and EffectsCause-And-Effect diagram is provided in Appendix B indicating the possible causes tothe variances in project costs and schedules and the ones isolated for this project.2.5 Work Breakdown StructureThe WBS at the summary task level is listed below. A fully-expanded WBS showing alltasks 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 Project2.6 Project ScheduleThe schedule for the high-level summary tasks, showing start and end dates, is shown inFigure 1. A more detailed project schedule, showing subtasks is provided in Appendix Dand a more visual schedule showing task dependencies is given in Appendix E. Task Name Duration Start FinishCost 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
  • 6. 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 piggybackit on a project being conducted at the hospital. Although, hypothetically, theimprovement project could have been accomplished in half the time—nine months—wefelt it was important to collect six months’ worth of data in each phase of the project toobtain a better sample and get a more robust indication of what was happening. Theoptimal 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 scheduleperformance.2.7 Project BudgetThe total budget for the project is $111,205 and consisted of 438 consultant hours and 75hours of nursing and IT staff. Based on the deliverable metrics, it is estimated that theROI 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: bimonthlyDollar Opportunity Estimates:Average number of projects/year = 6Average schedule slippage time = 4.63 monthsAverage cost/hour = $208.33Size of Opportunity = $208.33*4.63 months*160 hrs/month/project*6 projects =$925,985Estimated cost of project = $111,205Estimated Improvement: 50% reduction in slippage = .5*925,985 = $462,993Savings = $462,993 - $111,205 = $351,788First Year ROI = $462,993/111,205 = 416%2.8 Resource Assignment Matrix (RAM)The Resource Assignment Matrix is given in Appendix F. 6
  • 7. 3.0 Definition Phase3.1 Process ModelFigure 2 shows the SIPOC for the as-is process at <CLIENT> for project initiationthrough close-out and Figure 3 is the process flow for the as-is process for projectinitiation 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
  • 8. NursingTech SupportContractor/Internal PMManagement Figure 3. Process Flow For Project Initiation Through Close-Out.3.3 Failure Modes and Effects AnalysisA complete FMEA was conducted of the entire process group steps of the ProjectManagement Book of Knowledge (PMBOKTM), the de facto standard in America for themethodology of conducting projects, to identify possible failure modes. Due to the sizeof the spreadsheet containing the data, it is provided in a supplemental document titled“FMEA Spreadsheet.xls” 8
  • 9. 4.0 Measurement PhaseFigures 4 and 5 show control charts of the average normalized task cost variance andaverage normalized task schedule variance by month obtained for the past five projectsconducted at <CLIENT>. These indicate that even within one month of each project’sinitiation, variances had already occurred, and, without proper corrective action beingtaken, continued to grow until the projects were terminated. It was necessary tonormalize the data since each project has budgets independent of the others and it wasnecessary 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 theseareCV% = Earned Value/Baselined Project BudgetSV% = Planned Value/Baselined Project BudgetThese charts do not include the additional schedule effort and costs added to the projectto rework functionality errors and changes needed to satisfy end-user requirements. Itwas determined that such an undertaking would be tabled for a future processimprovement project since no prior data had been recorded. Furthermore, due to thehospital practice of waiting until a project was near completion before validatingfunctionality and content against user requirements, there would be no means to recordvariables associated with rework until the overlying (i.e. the one being piggybackedupon) project had reached its rollout point.Figures 6 and 7 show the control charts that were constructed for the improvementproject, again, based on the normalized task cost and schedule variances by month for theproject.Data was sampled for a six-month period prior to improvement of the process. At thistime the variances were so great that it was feared that corrective action to get thevariances back to zero would be improbable, costly, and might completely destabilize theproject. Instead, the variance at Month 6 was established to be the baseline and anycorrective action taken from that point on was to bring the project variances back to thatrespective position.Two factors attributed to the variances in Figures 4 and 5. The first is the lack ofcorrective action. Corrective action is a standard project management practice onsuccessful projects that entails regular, frequent sampling of CV% and SV% followed byperforming actions on the project designed to steering it back on schedule and/or theforecasted spend line. 9
  • 10. Av. Normalized Cost Variance 0 1 2 3 4 5 6 7 8 9 10 11 12 -0.2 -0.4 -0.6 -0.8Cost 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
  • 11. 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. Thatis, they were never established as a dollar amount proportional to the work needed to bedone. It was stated earlier in the text that Management would assign a budget to eachproject but this budget was not created by following any acceptable project estimationtechniques. Instead, a dollar was assigned to the project solely for the purposes ofallocating some money towards it, based on a gut feeling, and that total dollar amountwas apportioned downwards to individual tasks. It was understood that additional moneywould have to be allocated at some future point after the majority of the budget to datehad been used up. This explains the volatility in Figures 6 and 7 from months 6 through12. Simply put, the variances in task duration and task cost during that period areattributed to the improper schedule and budget estimates, respectively. For months 13through 18, the cost and durations of remaining task work were re-estimated andbaselined and it is evident that further reduction in the variability of schedule and costwere obtained.It is important to note that the six sigma project itself was separate in and of itself fromthe piggybacked project that the hospital was being conducted. That project had a pre-setscheduled duration that exceeded the six-month timeframe that a six sigma project wouldspan that it was necessary to follow in order to collect a sufficient amount of data. 11
  • 12. As it was previously mentioned, due to the frequency of data being sampled, theimprovement project was constrained by the sampling rate, and for good reason. It wouldbe excessively costly to monitor schedule and costs variances on a daily or even weeklybasis and the value provided is marginally better than what a monthly frequencyprovides. 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 moredata. For that reason, in order keep the improvement project costs down, the underlyingproject was conducted for six months prior to the onset of the improvement project. Thefirst improvement was made and the underlying project continued for an additional sixmore months before the second improvement was made. Although starting and stoppingany type of project is not recommended, let alone one designed to improve processes, itwas necessary in this case.Using historical data and the results of end-user interviews we determined that thecritical-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 reworkactivity is one that is performed after the product is released to the client and the need for 12
  • 13. 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 individualtesting prior to roll-out. A defect, in the context of this report, is defined as oneadditional, 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 projecttime spent on rework was 17.12280%. This presented a difficulty, however, in thatrework only applied to changes performed after a product had been released in order toalign 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
  • 14. 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 hadto make changes and then track the next ten projects to completion in order to determineif the changes were correct and sufficient. This would amount to a minimum of twoyears of data collection, since each project would yield one data point. For this reasonreduction of project rework was not considered as part of the scope of this project.5.0 Analyze and Improve PhasesThe methodology of managing projects was investigated, with particular attention beingpaid to determine the underlying causes to the variances between estimated and actualproject budgets and schedules. Specific interfaces addressed were contributions by thecontract project managers, past Oversight Group members, and the end-users (nursingstaff). Initial observations were that, although a repeatable process was set in place byManagement to assign budgets and schedule durations to projects, the standard model forconducting 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 themajority of budget overages, schedule slippages, and even project rework.5.1 Exploratory Data AnalysisUsing the PMBOKTM methodology as a guide, we identified what the current as-ismethodology is at <CLIENT> for conducting internal projects and compared it to theshould-be methodology of PMBOKTM, identifying gaps in the process along the wayand/or improvements in the process itself. Special emphasis was placed on the followingitems 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 management5.1.1 As-Is System Process AuditFrom 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 theirconcerns were being heard loud and clear in hopes that it would get buy-in for the nextimplementation project. One of the two biggest complaints was that none of the nursingstaff, i.e. the end-users, had been interviewed prior to the first EMR implementation todetermine what their needs were, what minimum functionality requirements the systemneeded to have, nor what data needed to be collected for each of the input screens. Inaddition, it was obvious that no criteria had been communicated to the project team by 14
  • 15. the Oversight Group regarding user acceptance testing. Due to these two facts, thesystem never functioned as needed once the system finally went live and months ofrework were needed to bring the functionality up to an acceptable level. When this topicwas pursued deeper it was discovered that it was common practice not to involve the endusers (i.e. nursing staff) to determine their requirements. Instead, the decision was madeat the CXO level what system performance would be.5.1.2 Narrative Description of Undesirable EffectsSurveys were conducted anonymously by Internet using www.surveymonkey.com withmembers of the nursing staff and IT staff regarding system performance of the EMRimplementation to date. Open-ended questions, Yes/No questions, and ranking questionsin 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
  • 16. • 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 stillworking for <CLIENT>, brought forth the following issues with respect to projectplanning 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
  • 17. • 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 whattheir roles were in the project, the process they followed to initiate and plan projects, andthe potential impact of their roles. This information was categorized in accordance withthe 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 GroupPG -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
  • 18. • 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 ExecutionSince execution of a project is so specific to the nature of each individual project, there isno value-added way to compare As-Is to Should-Be from the standpoint of a repeatableimprovement 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
  • 19. 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-BeHere we’ve identified the ideal state of how projects should be initiated, planned,executed, and monitored, based on user interviews and user requirement documentationas well as the PMBOKTM methodology.According to the PMBOKTM, conducting a project is a repeatable process that follows aspecific methodology. Any deviation from that methodology decreases the chances thatthe project will be successful. The following are the required steps in order to complywith 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
  • 20. • 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 ExecutionN/APG -4 Monitoring & Control • Earned Value Analysis (EVA) – Must be conducted on a monthly basis with results communicated and explained to the client. 20
  • 21. • 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 GapsThe following gaps have been identified in the project methodology at <CLIENT> withrecommendations 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
  • 22. 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
  • 23. 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/APG - 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
  • 24. • 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 performed5.2 “Critical-To Characteristics” and DPMOsThe 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 ithasn’t been controlled—i.e. ignored and not brought back in line with expenditureforecasts—or it is no longer controllable—the attempt to bring it back in line withexpenditure forecasts happened too late and any attempt to correct the variance will betoo costly, not feasible, or the expenditure forecast itself (from which CV is derived) wasarbitrary as in the case of projects at <CLIENT>. The DPMO here is defined as thenumber of uncorrected cost overage events per opportunity. Since actual to plannedexpenditures are compared on a monthly basis, each monthly observation and comparisonis 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 acrossthe five past projects (signifying an over budget condition) had already risen by the firstobservation and the variances grew larger for each successive observation. No attempt atcorrective 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 isdefined as the number of uncorrected schedule slippage events per opportunity. Sinceactual to planned performance is compared on a monthly basis, each monthly observationand comparison is considered one opportunity. Thus defined, the DMPO, based onFigure 5 is 1,000,000 x (1 observed defect/monthly observation) = 1,000,000. 24
  • 25. Based on the observations shown in Figure 5, negative schedule variances on averageacross the five past projects (signifying a schedule delay condition) had already risen bythe first observation and the variances grew larger for each successive observation. Noattempt at corrective action was taken.5.3 Future Performance LevelsArguably, the ideal target values for CV% and SV% respectively are in the range 0.0 to0.05, that is, on budget and on schedule to slightly under budget and slightly ahead ofschedule. However, project budgets and schedules are estimates, even at their best, andare also stochastic in nature; the duration of any repeatable task (and hence its cost) willfall somewhere within a log-normal distribution. The target variance might also bedependent on the nature of the project as well. While there will be some projects thatmust be completed on time, regardless of cost, there might be others that must becompleted within budget, regardless of schedule. The future performance levels dictatedby this project treat the majority of those projects that fall somewhere within these twoextremes.It is reasonable for an organization that has gone from an ad-hoc project managementapproach to something more formalized to fall within a target CV% and SV% range of0.0 ± .10. Future initiatives to raise the organization from a project management maturitymodel (PMMM) Level 2 (formalization of the project management methodology) to ahigher level can be associated with continuous improvement to reduce this range evenfurther. However, a target CV and SV of 0.0 ± .10 is a sufficient target for futureperformance levels within which to control projects.6.0 Control Phase6.1 Maintaining The Gains MadeAs noted in this document there are several places where deviations from the standardproject management model existed. By focusing on two areas, those of budget/scheduleestimate and budget/schedule monitoring and control, we demonstrated the very positiveeffect that best practices in each of these yield.Figure 8 contains the suggested future state process map to be followed in order to keepthe project budget and schedule in control.Nursing 25
  • 26. Tech SupportContractor/Internal PM ManagementFigure 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
  • 27. 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 followingadditional 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
  • 28. 7.0 ConclusionThe result of the project was highly noticeable to the CFO and the rest of SeniorManagement and acknowledged the hazards of not following a standardized projectmanagement model. While it may have been felt by some that following a projectmanagement methodology should be limited in order to save project costs (an effort toadd to the hospital’s bottom line), it was evident that the lack of proper planning andoversight efforts actually attributed to a siphoning off of the hospital’s bottom linetowards escalating project overspending. As a result, the CFO is seeing a reduceddemand of additional hospital funding toward projects. <CLIENT> has a betterestimating, monitoring, and control process in place and acknowledgement (andcommunication thereof to the nursing staff) of issues related to end-user requirementshave 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 bottomline. 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 acknowledgementthat their input will be used in future planning efforts.We have identified new policies and practices for Management to implement as well asother 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
  • 29. Appendix A - Project CharterProject Improvement of Cost and Schedule Control at <CLIENT>Created By Ed Kozak Date 12/29/2009Phone 555- 111-1111 Email EKozak@SuccessfulProjectsForLeaders.comProject Name/Number: Improvement of Cost and Schedule Control at <CLIENT>/ Project No. 09-2912Sponsoring Organization: FinanceProject Sponsor: Name: Larry Kristufek Phone: 555-555-5555 Office Location: 910 Mail Stop: N/AProject Black Belt: Name: Kevin Ross Phone: 555-555-5555 Office Location: 522 Mail Stop: N/AProject Green Belt: Name: Ed Kozak Phone: 555-111-1111 Office Location: 522 Mail Stop: N/AKey Team Members (Name) Title/Role Phone Office LocationRodman Goodwin DBA 555-257-6666Benyuende Nacanabo Sr. Programmer 555-257-6669Jim Richards Network Administrator 555-257-6612Sean Lawless Director 555-257-1461Principal Stakeholders (Name) Title/Role Phone Office LocationGiselle Roberts CEO 555-257-5555 1010Robert Jones CNO 555-257-1111 511Shevaun Johnson CIO 555-257-1221 742Jennifer Gee IT Mgr. 555-257-1331 731Mike Brow PCC – PICU 555-257-1441 254Lena Sjoblom PCC – Psych 555-257-1001 678Charles Leach PCC - SICU 555-257-1991 512Date Chartered: Project Start Date: Target Completion Date:12/29/09 1/4/10 8/13/11Revision: 1 Number: 3 Date: 12/29/09 Sponsor Approval Signature: 29
  • 30. Project Name/Number: PM Process Improvement/Project No. 09-2912Project Mission Statement: Reduce project schedule slippage on average by 50% (historically, projectschedule 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 adoptcertified electronic medical record (EMR) systems or can’t demonstrate “meaningful use” by 2015 will findtheir Medicare reimbursements cut, and they will lose the chance to receive Medicare incentive paymentsfor implementation. Historically, the hospital has shown an inability of meeting its internal projectdeadlines time and time again, and the expenditures of each project that have been undertaken have grownexponentially from their original estimates, making any future project cost and time estimates seeminglymeaningless.Project Scope: The methodology of managing projects will be investigated, with particular attention beingpaid to determine the underlying causes to the variances between estimated and actual project budgets andschedules. Specific interfaces to be addressed in this project are contributions by the contract projectmanagers, 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 implementationBusiness Need Address By Project:Less project overspending => Improved annual budgetary forecasting abilities and free cash flow for otherinvestmentsImproved implementation cycle time => increased patient diagnosis & release => reduction in non-Medicare-covered costsImproved implementation cycle time => higher probability of meeting Government mandate requirementsfor implemented EMR => lower probability of losing Government Medicare SubsidizationImproved implementation cycle time => Improved hospital free cash flow and profitability 30
  • 31. 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 projectCompletion of Underlying Project Planning schedule of underlying project Management approval to proceed with nextCompletion of Improvement Project Planning and Approval phase of improvement project. EVA report with control chart data for first sixCompletion of Initial Data Collection and Analysis months of underlying project. EVA report with control chart data forCompletion of Intermediate Data Collection and Analysis intermediate six months of underlying project. Revised project budget and schedule forCompletion of Rebaselining of Underlying Project remainder of underlying project. EVA report with control charts for lastCompletion of Final Data Collection and Analysis scheduled six months of underlying project. Final report including documentation ofImprovement Project Closeout lessons learned. 31
  • 32. 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 Total1 The required projected return was calculated to be $83,333*18 months*468 hours/2880hours/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 animplementation project in the hospital with an estimated duration of 18 months, the sixsigma project calendar time took almost 6 times as long to complete as its project time.Therefore, it was assigned a number of zero. 32
  • 33. 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 - PeopleProject 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 ChangeNot Addressing End-User Reqs. Planning/Monitoring Control, No User Acceptance Reqs. A – No QC B – Poorly-Defined Requirements C – Not Adhering To Requirements 33
  • 34. Appendix C - Project WBSI. Historical Data CollectionA. Conduct InterviewsB. Conduct Interview Analysis and AssessmentC. Gather Historical Project InformationD. Historical Project Methodology ReviewE. Historical Project Time Sheet ReviewF. Historical Project Earned Value AnalysisII. Analyze ResultsA. Report As-Is Vs. Should-Be FindingsB. Make Recommendations for Improvement ProjectC. Get Mgmt ApprovalD. Execute RecommendationsIII. Underlying Project PlanningA. Time-Phased Budget PreparationB. Project Schedule PreparationIV. Current Project Initial PlanningA. Current Project Time Sheet ReviewB. Current Project Earned Value AnalysisV. Analyze ResultsA. Make Recommendations for Next PhaseB. Get Mgmt ApprovalC. Execute RecommendationsVI. Intermediate Data CollectionA. Time Sheet ReviewB. Perform Earned Value AnalysisVII. Analyze ResultsA. Make RecommendationsB. Get ApprovalC. Execute RecommendationsVIII. Re-Baseline ProjectA. Re-estimate project costs on task-by-task basisB. Re-estimate project task durationsIX. Final Data CollectionA. Time Sheet ReviewB. Earned Value AnalysisX. Close Out Improvement ProjectA. Confirm Work is done to requirementsB. Get formal acceptanceC. Create final reportD. Create lessons learnedE. Index and archive all project recordsF. Release resources 34
  • 35. Appendix D – Project Schedule Task Name Duration Start FinishCost 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 ImprovementProject 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 Time Sheet Review 2 1 day Fri 9/24/10 Fri 9/24/10 Time Sheet Review 3 1 day Fri 10/29/10 Fri 10/29/10 Time Sheet Review 4 1 day Fri 11/26/10 Fri 11/26/10 Thu Time Sheet Review 5 1 day 12/30/10 Thu 12/30/10 Time Sheet Review 6 1 day Fri 1/28/11 Fri 1/28/11 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 2 1 day Mon 9/27/10 Mon 9/27/10 Perform Earned Value Analysis 3 1 day Mon 11/1/10 Mon 11/1/10 Perform Earned Value Analysis 4 1 day Mon Mon 11/29/10 35
  • 36. 11/29/10 Perform Earned Value Analysis 5 1 day Fri 12/31/10 Fri 12/31/10 Perform Earned Value Analysis 6 1 day Mon 1/31/11 Mon 1/31/11 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-taskbasis 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 Time Sheet Review 1 1 day Fri 2/25/11 Fri 2/25/11 Time Sheet Review 2 1 day Fri 3/25/11 Fri 3/25/11 Time Sheet Review 3 1 day Fri 4/29/11 Fri 4/29/11 Time Sheet Review 4 1 day Fri 5/27/11 Fri 5/27/11 Time Sheet Review 5 1 day Fri 6/24/11 Fri 6/24/11 Time Sheet Review 6 1 day Fri 7/29/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 Earned Value Analysis 2 1 day Mon 3/28/11 Mon 3/28/11 Earned Value Analysis 3 1 day Mon 5/2/11 Mon 5/2/11 Earned Value Analysis 4 1 day Mon 5/30/11 Mon 5/30/11 Earned Value Analysis 5 1 day Mon 6/27/11 Mon 6/27/11 Earned Value Analysis 6 1 day Mon 8/1/11 Mon 8/1/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
  • 37. Appendix E. Project Gantt Chart
  • 38. 38
  • 39. 39
  • 40. Appendix F – Resource Assignment Matrix Responsibility Nursing ITHistorical 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 PAnalyze Results Report As-Is Vs. Should-Be Findings P Make Recommendations for Improvement Project P Get Mgmt Approval P P Execute Recommendations PUnderlying Project Planning Time-Phased Budget Preparation P S Project Schedule Preparation P SCurrent Project Initial Planning Current Project Time Sheet Review P Current Project Earned Value Analysis PAnalyze Results Document And Make Recommendations P Get Mgmt Approval P P Execute Recommendations PIntermediate Data Collection Time Sheet Review P Perform Earned Value Analysis PAnalyze Results Document And Make Recommendations P Get Approval P P Execute Recommendations PRe-Baseline ProjectRe-estimate project costs on task-by-task basis P S Re-estimate project task durations P SFinal Data Collection Time Sheet Review P Earned Value Analysis PClose Out Improvement Project Confirm Work is done to requirements P P Get formal acceptance P P
  • 41. Create final report P Create lessons learned P Index and archive all project records P Release resources PP = Primary, S = Secondary 41
  • 42. Appendix G – Basis of Estimate SheetBASISOF ESTIMATE SHEET SHEET OFPROPOSAL 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 EstimatesCalculations of Labor Hours: Total Estimated Price: Prepared by: Reviewed by: Resource Estimator Proposal Manager 42
  • 43. L A B O R L A N N I N G S H E T AppendixPH – Time-PhasedE Budget SheetP 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.: 1ST 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 0E 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 YC a t e g o r y /N a m e C a t e g o ry / N a m eM O NTHL Y TO TAL = 0 0 0 0 0 0 0 0 0 0 0 0 0 0 M O NTH LY T OC a t e g o r y /N a m e C a t e g o ry / N a m eM O NTHL Y TO TAL = 0 0 0 0 0 0 0 0 0 0 0 0 0 0 M O NTH LY T OC a t e g o r y /N a m e C a t e g o ry / N a m eM O NTHL Y TO TAL = 0 0 0 0 0 0 0 0 0 0 0 0 0 0 M O NTH LY T OC a t e g o r y /N a m e C a t e g o ry / N a m eM O NTHL Y TO TAL = 0 0 0 0 0 0 0 0 0 0 0 0 0 0 M O NTH LY T OC a t e g o r y /N a m e C a t e g o ry / N a m eM O NTHL Y TO TAL = 0 0 0 0 0 0 0 0 0 0 0 0 0 0 M O NTH LY T OC a t e g o r y /N a m e C a t e g o ry / N a m eM 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