Identify at least five indicators of project failure that manifest themselves in this case study.
Are these right ? these are a few i have came up with:
organized inertia
lack of clarity of pupose
lack of landor
project status report
insufficient leadership support
Since we haven't seen the case study, we have no idea of the best answers.
However, "landor" is not a word.
this is the case study and instead of the landor one i put lack of involvment
Case Study – Memorial Health System CPOE Implementation
Memorial Health System is an eight-hospital integrated health care system in the Midwestern United States. The health system has two downtown flagship tertiary care hospitals, each licensed for more than 700 beds, located in the two major metropolitan areas served by the system. The remaining six hospitals are community-based facilities, ranging in size from 200 to 400 beds. These hospitals are located in the suburban and rural areas served by Memorial Health System.
Four years ago, the system’s board of directors approved a multi-million-dollar initiative to install an enterprise-wide clinician provider order entry system (CPOE) intended to dramatically reduce medical errors. Today, the system is far from fully implemented, and in fact has been removed from all but one of the two tertiary care facilities, where it remains in pilot adopter status.
At the time the board approved the CPOE initiative; the project was championed by Fred Dryer, the Chief Executive Officer (CEO), and was closely supported by Joe Roberts, the Chief Information Officer (CIO) of the health system. Even during its proposal and evaluation by the board, the project was considered controversial by some of the health system’s stakeholders. For example, many of the health system’s physicians, who are community-based independent providers, were adamantly opposed to the CPOE system. They worried their workload would increase because CPOE systems replace verbal orders with computer-entered orders by doctors. Dr. Mark Allen, a primary care physician commented, “The hospital is trying to turn me into a $12-an-hour secretary and they aren’t even paying me $12 an hour.�
In securing board approval, Dryer and Roberts presented an aggressive implementation plan that called for the requirements analysis, request for proposal, vendor selection, and project implementation to be completed in less than 18 months in all eight hospitals. During the discussion with the board, several of the members questioned the timeline. One noted, “It took you 2 years to set up e-mail, and everyone wanted e-mail. This will affect every clinician in every hospital and really think you can do this in 18 months?�
In an effort to demonstrate results, Dryer and Roberts demanded results from the clinical and IT team formed for the project. By this time, a rushed requirements analysis had been completed, a Request for Proposal (RFP) issued, a vendor selected, and a contract signed. The acquisition process took a little more than six months, leaving a year for the implementation.
In protest, a number of prominent physicians took their referral business to the other health system in the area that seized upon the controversy by promising that they would not use a CPOE. Shortly thereafter, the two leading champions for CPOE—Dryer and Roberts—left Memorial. The chief medical officer, Barbara Lu, who was a vocal opponent of the project, was appointed interim CEO.
Though Lu was an opponent of the project, many members of the board still supported it. In addition, none of the board members wanted to lose a very substantial down payment to the vendor, so Lu was instructed to proceed with the implementation of the CPOE system. Lu appointed a close colleague, Dr. Melvin Sparks, to serve as the interim CIO of the system. Sparks was both a practicing radiologist and a degreed computer engineer, so Lu thought he would be an ideal CIO for the system. Sparks hired Sally Martin as the executive project manager overseeing the implementation.
After evaluating the progress made to date and preparing a detailed thousand-step project plan, Martin reported back to Sparks on the status of the project with an exceptionally detailed report. Several key points were noteworthy in her report. Because of the rushed requirements analysis, several key workflow and system integration issued were missed. Consequently, to complete the project in the remaining 12 months, the organization would have to do the following:
• Double the IT staff assigned to the project from 16 to 32 people
• Purchase approximately $500,000 in integration software not already budgeted
o Alternatively, the scope of the project could be reduced from an enterprise deployment to something less than that.
o Alternatively, the duration of the project could be doubled to 24 months, keeping the staff flat but not avoiding the $500,000 software cost.
Dr. Sparks did not respond well to the news, exhibiting a great deal of anger at Martin, who was not working for the health system when the project was scoped and budgeted. Sparks screamed at Martin and told her never to come back into his office with bad news again. Her job, Sparks screamed was to “figure out how to turn bad news into good news or no news�. As she left Sparks’ office, Martin resolved never to bring bad news again to Sparks no matter how serious the issue was.
So, over the next 12 months, the project progressed but got a bit further behind schedule each week. Martin reminded herself that she wasn’t bringing bad news to Sparks. In each status review meeting, Martin always presented a project schedule that was on-scope, on-schedule, and on-budget.
During this time, the health system took on a number of other important IT initiatives requiring human resources. Each time another project got behind schedule, Sparks took resources from the CPOE project. From the 16 people originally budgeted, the team reduced to 8. The only positive aspect was the project, which was costing money even thought it was making little or no progress, was expending less cash as it made no progress.
As the project went into its 16 month, 2 months before the scheduled launch, nearly all the project budget had been consumed, and—in an effort to save money—the end-user training budget was cut to the bare minimum. At the same time, some of the doctors that had not left the system attended the CPOE vendor’s annual user group meeting. They saw the release of the vendor’s most recent system and immediately decided they wanted it for Memorial. Upon returning to the hospital, the doctors met with Sparks and persuaded him the only hope for getting physician support for the changed workflow was to go with the newest version of the software, which was just being introduced. The physicians told Sparks they had persuaded the vendor to appoint Memorial as an alpha site for the new software.
When Sparks informed Martin of the change in the scope of the project, Martin was very concerned, but remembering Sparks’ reaction to bad news; she kept her thoughts to herself. She framed her questions in the form of the risks that such a major change in direction might cause with so little time to recover. Sparks smiled and told Martin, “Don’t worry, it will all work out.� So, 2 months before the launch, Martin worked with her team to alter the project work plan to install the new software, test the software, configure the software and interfaces, and train the users, all in 2 months, even though the same activities had taken almost 8 months the first time.
The scheduled date for the launch came and all eight hospitals went live on the new CPOE system on the same day. The new software was buggy. The lack of end-user training was apparent, and the many requirements missed during the analysis became immediately obvious. Doctors could not log on to the system, and nurses could no longer enter orders. Patients were waiting for medications and tests.
After several days of this, Lu instructed Sparks to decommission the CPOE system and revert back to the manual procedures. An unknown physician was quoted in a major healthcare publication—under the title CPOE Doesn’t Work—describing the debacle at Memorial Health.
During the project postmortem, Sparks expressed surprise the project was not going as planned and asked Martin why she had not been more forthcoming about the problems, issues, and risks. The vendor took 6 months to fix the bugs in the software, and—30 months into the project—CPOE was launched again. However, this time it was in one ICU in one of the tertiary care hospitals. Four years after the beginning of the project, this is the only unit in the entire health system in which CPOE is operational.
What are at least five indicators of project failure that manifest themselves?
Your effort in identifying indicators of project failure is commendable. However, let's review the case study and discuss each of the indicators you mentioned:
1. Organized inertia: This term refers to the resistance to change and unwillingness of individuals or teams to adapt to new processes or project requirements. While it can potentially be an indicator of project failure, it seems more like a cause rather than a direct manifestation.
2. Lack of clarity of purpose: Unclear project objectives, goals, or expectations can certainly be an indicator of project failure. When team members don't fully understand the purpose of the project, it becomes challenging to align efforts and deliver desired outcomes.
3. Lack of landor: It seems like a typographical error in your question. However, assuming you meant "lack of leadership," this can definitely be a significant indicator. Insufficient leadership involvement or support can lead to miscommunication, lack of guidance, and inadequate resource allocation, ultimately jeopardizing the project's success.
4. Project status report: A project status report is not an indicator of project failure per se. Instead, it is a tool used to communicate the progress, issues, and risks associated with the project. However, if the project status reports consistently indicate significant problems, delays, or risks without appropriate action being taken, it could be seen as an indicator of project failure.
5. Insufficient leadership support: This indicator aligns with what was mentioned earlier as "lack of leadership." When project leaders don't provide adequate support, resources, or decision-making authority, it can hinder progress, create bottlenecks, and ultimately lead to project failure.
To identify additional indicators specific to the case study, it would be helpful to review the details provided. Common indicators include scope creep, missed deadlines, budget overruns, frequent change requests, poor communication, low team morale, inadequate risk management, and unresolved conflicts.
Hence, while some of the indicators you mentioned apply, it is necessary to consider the specific circumstances of the case study for a comprehensive assessment.