You are on page 1of 44

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 werent 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 postimplementation 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 InitiationPlanning-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.

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 cant 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 hospitals 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 didnt 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), didnt 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

functional Oversight Groupusually 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 didnt 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 werent 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%.

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 Cost and Schedule Improvement Project Historical Data Collection Analyze Results Duration 417 days 18 days 6 days Start Mon 1/4/10 Mon 1/4/10 Thu 1/28/10 Finish Tue 8/9/11 Wed 1/27/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 timenine monthswe 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.

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 Upper Mgmt Oversight Group IT Manager Vendors Internal Computer System Contract PMs Internal IT/Tech Staff (Project Team) Inputs Scope Functionality Assumptions Constraints Process Management defines scope Outputs Preliminary Scope Customer Nursing Staff Doctors Patients

Budget

Management sets budget

Top-down project budget

Deadline

Management sets deadline PM/Team determine schedule

Arbitrary deadline Preliminary Schedule fit to deadline Intermediate deliverables

Milestones

PM/Team determine milestones IT Manager purchases software Vendor supplies software

Vendor product literature Customizable software package

Purchase Order

Nonfunctional software Customized software implemented

PM/Team execute implementation, customization, and roll-out

Figure 2. SIPOC for <CLIENT> Project Initiation and Execution.

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

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 projects 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.

Av. Normalized Cost Variance


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

-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 valueadded 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 hospitals 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 members 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.

Sample Number 1 2 3 4 5 6

Table 1. Historical Project Rework Durations. Project Duration Additional Time Spent On Rework (months) (months) 20.107 3.985 12.352 1.760 11.678 .615 15.662 4.006 20.505 1.009 8.089 .998

13

7 8 9 10 Averages 14.398

17.029 12.181 13.002 13.374 2.465

4.496 4.048 .144 3.592

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 didnt 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 couldnt provide responses. Nurses worked around this by answering Yes or No and then writing in a text box that he/she really didnt 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 didnt 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 patients record requires a wait of 10 minutes on average due to the volume of information stored in all of a particular patients 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 theyre 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 hospitals servers dont support the volume of data and need to be upgradeda 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 patients 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 wasnt 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 wasnt 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 werent 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 expertopinion 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 wasnt part of the hospital culture to document lessons learned. 5.1.3 Model Process Audit/Should-Be Here weve 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 projects 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 managers 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 clients 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 managers 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 managers 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 managers 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 managers 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 managers 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 managers 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 managers 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 issuesall 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 actionsit 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 nonexistent, 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 wasnt 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 assignedthe 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 tasks 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 wont 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 minimallyacceptable 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 hasnt been controlledi.e. ignored and not brought back in line with expenditure forecastsor it is no longer controllablethe 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 paddingartificial 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 hospitals 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 hospitals bottom line), it was evident that the lack of proper planning and oversight efforts actually attributed to a siphoning off of the hospitals 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 hospitals 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

Project Created By Phone

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

Project Name/Number: Sponsoring Organization: Project Sponsor: Project Black Belt: Project Green Belt: Key Team Members (Name) Rodman Goodwin Benyuende Nacanabo Jim Richards Sean Lawless

Improvement of Cost and Schedule Control at <CLIENT>/ Project No. 09-2912 Finance Name: Larry Kristufek Office Location: 910 Name: Kevin Ross Office Location: 522 Name: Ed Kozak Office Location: 522 Title/Role DBA Sr. Programmer Network Administrator Director Phone: 555-555-5555 Mail Stop: N/A Phone: 555-555-5555 Mail Stop: N/A Phone: 555-111-1111 Mail Stop: N/A Phone Office Location 555-257-6666 555-257-6669 555-257-6612 555-257-1461

Principal Stakeholders (Name) Giselle Roberts Robert Jones Shevaun Johnson Jennifer Gee Mike Brow Lena Sjoblom Charles Leach

Title/Role CEO CNO CIO IT Mgr. PCC PICU PCC Psych PCC - SICU

Phone 555-257-5555 555-257-1111 555-257-1221 555-257-1331 555-257-1441 555-257-1001 555-257-1991

Office Location 1010 511 742 731 254 678 512

Date Chartered: 12/29/09 Revision: 1

Project Start Date: 1/4/10 Number: 3 Sponsor Approval Signature:

Target Completion Date: 8/13/11 Date: 12/29/09

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 cant 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 nonMedicare-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

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 months of underlying project. Completion of Initial Data Collection and Analysis 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.

Significant Milestones

31

Project Evaluation Form


Score 10 3 5 3 0 21 Interpretation Sponsorship External Customer Shareholder Employee or Internal Customer Other (supplier, environment, etc.) - Total Benefit Availability of resources other than team

10 10
1

Scope in terms of Black Belt effort 10 0


2

Deliverable Time to Complete Team Project Charter Value of Six Sigma Approach Total

10 10 5 76
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. 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.
2

32

Appendix B - Cause-And-Effect Diagram


Cause - Project Lasts Longer Than Anticipated

Project Scope Changing Innacurate Schedule Estimate Project Team Working Slower than Anticipated Problems Delaying Project Project Needs Rework A B C Cause - Inaccurate Cost Estimate Used

Wrong Method Used Inexperienced Estimator Scope Changed/Original Estimate no Longer Valid & Not Updated Project Cost Variance at 50%

Methodology Not Being Followed Inexperienced PM Contract PM Unmotivated Cause - Project Management

Team Issues Team Too Inexperienced Project Work Doesnt Match Skills Cause - People

Project Needs Rework: No QC, Poorly-Defined End-User Reqs. Not Addressing End-User Reqs.

Problems Delaying Proj.: No Risk Plan/Monitoring, Poor-Risk Planning/Monitoring

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

35

Perform Earned Value Analysis 5 Perform Earned Value Analysis 6 Analyze Results Make Recommendations Get Approval Execute Recommendations Re-Baseline Project Re-estimate project costs on task-by-task basis Re-estimate project task durations Final Data Collection Time Sheet Review Time Sheet Review 1 Time Sheet Review 2 Time Sheet Review 3 Time Sheet Review 4 Time Sheet Review 5 Time Sheet Review 6 Earned Value Analysis Earned Value Analysis 1 Earned Value Analysis 2 Earned Value Analysis 3 Earned Value Analysis 4 Earned Value Analysis 5 Earned Value Analysis 6 Close Out Improvement Project Confirm Work is done to requirements Get formal acceptance Create final report Create lessons learned Index and archive all project records Release resources

1 day 1 day 3 days 1 day 0 days 0 days 2 days 2 days 2 days 112 days 111 days 1 day 1 day 1 day 1 day 1 day 1 day 111 days 1 day 1 day 1 day 1 day 1 day 1 day 6 days 0.5 days 0 days 5 days 2 days 0.5 days 0 days

11/29/10 Fri 12/31/10 Mon 1/31/11 Thu 2/3/11 Thu 2/3/11 Fri 2/4/11 Mon 2/7/11 Mon 2/7/11 Mon 2/7/11 Mon 2/7/11 Fri 2/25/11 Fri 2/25/11 Fri 2/25/11 Fri 3/25/11 Fri 4/29/11 Fri 5/27/11 Fri 6/24/11 Fri 7/29/11 Mon 2/28/11 Mon 2/28/11 Mon 3/28/11 Mon 5/2/11 Mon 5/30/11 Mon 6/27/11 Mon 8/1/11 Tue 8/2/11 Tue 8/2/11 Tue 8/2/11 Tue 8/2/11 Tue 8/2/11 Tue 8/9/11 Tue 8/9/11

Fri 12/31/10 Mon 1/31/11 Mon 2/7/11 Thu 2/3/11 Fri 2/4/11 Mon 2/7/11 Tue 2/8/11 Tue 2/8/11 Tue 2/8/11 Mon 8/1/11 Fri 7/29/11 Fri 2/25/11 Fri 3/25/11 Fri 4/29/11 Fri 5/27/11 Fri 6/24/11 Fri 7/29/11 Mon 8/1/11 Mon 2/28/11 Mon 3/28/11 Mon 5/2/11 Mon 5/30/11 Mon 6/27/11 Mon 8/1/11 Tue 8/9/11 Tue 8/2/11 Tue 8/2/11 Tue 8/9/11 Thu 8/4/11 Tue 8/9/11 Tue 8/9/11

36

Appendix E. Project Gantt Chart

38

39

Appendix F Resource Assignment Matrix


Historical Data Collection Conduct Interviews Interview Analysis and Assessment Gather Historical Project Information Historical Project Methodology Review Historical Project Time Sheet Review Historical Project Earned Value Analysis Analyze Results Report As-Is Vs. Should-Be Findings Make Recommendations for Improvement Project Get Mgmt Approval Execute Recommendations Underlying Project Planning Time-Phased Budget Preparation Project Schedule Preparation Current Project Initial Planning Current Project Time Sheet Review Current Project Earned Value Analysis Analyze Results Document And Make Recommendations Get Mgmt Approval Execute Recommendations Intermediate Data Collection Time Sheet Review Perform Earned Value Analysis Analyze Results Document And Make Recommendations Get Approval Execute Recommendations Re-Baseline Project Re-estimate project costs on task-by-task basis Re-estimate project task durations Final Data Collection Time Sheet Review Earned Value Analysis Close Out Improvement Project Confirm Work is done to requirements Get formal acceptance P P SP4L P P P P P P Responsibility Nursing staff Mgmt S S S S S IT Staff S S S

P P P P

P P

S S

P P

P P P

P P

P P P

P P

S S

P P

P P

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

P P P P

P = Primary, S = Secondary

41

Appendix G Basis of Estimate Sheet


BASISOF ESTIMATE SHEET PROPOSAL N O. TASK/SUBTASK TITL E: Task Description: SHEET DATE PREPARED : WBS N O. OF

Method of Estimate/Assumptions/Adjustment Factors:


Engineering or Tech. Judgment Past Experience(Bottom Up) Other (Parametric, Apportioned)

D iscuss Potential Risks/Severities/Triggers/Responses AssociatedWith Task and Estimate:

Calculations of Labor Hours:

For Non-Labor Estimates Total Estimated Price:

Prepared by: Resource Estimator

Reviewed by: 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 : DU E DAT E : 1 1 20 0 1 12 13 TO TAL P R O P O SA L M G R . : T A S K /S U B T A S K T I T L E : TY PE : 1 1 2 3 4 5 HOURS 6 10 11 B Y 7 M O N T H /P E R IO D 8 9

ST A R T D AT E :

E ND DAT E :

R F P / N o .: W B S No.: P R O P . N o .: N o o F M O N T H S:

PR O P O S A L T IT L E : C L IN /W B S /T A S K NO. YE A R /F Y C a t e g o ry / N a m e

C L I N /W B S / T A S K NO . Y E A R /F Y

C a t e g o r y /N a m e

M O NTHL Y TO TAL = C a t e g o r y /N a m e 0 0 0 0 0 0 0 0 0 0 0

M O NTH LY T O C a t e g o ry / N a m e

M O NTHL Y TO TAL = C a t e g o r y /N a m e 0 0 0 0 0 0 0 0 0 0

M O NTH LY T O C a t e g o ry / N a m e

M O NTHL Y TO TAL = C a t e g o r y /N a m e 0 0 0 0 0 0 0 0

M O NTH LY T O C a t e g o ry / N a m e

M O NTHL Y TO TAL = C a t e g o r y /N a m e 0 0 0 0 0

M O NTH LY T O C a t e g o ry / N a m e

M O NTHL Y TO TAL = C a t e g o r y /N a m e 0 0 0 0

M O NTH LY T O 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

0 0

0 0

0 0

0 0

0 0

0 0

0 0

M O NTH LY T O O VE R A L

OV E RALL TO TAL =

You might also like