Problem:
Minor Changes-Big Risk, a Tale of Woe!
A large and very well known healthcare organization sported a very large mainframe infrastructure to run the software to support its patient care function. This consisted of billing, patient records, administrative software, and 150 applications to support general practice. Now, it is very common to receive upgrades continually for this software. This discussion question will be used to analyze the concept of risk and the need for planning strategies to minimize risks to the organization.
In this scenario, one particular upgrade, or, as Information Technology (IT) folks call it in the trade, code fix, created a significant problem that prompted a process change that made subsequent code fixes into mini-projects themselves. At this time, the primary actions around implementing these code fixes were cursory testing to make sure the software didn't break the system and then coordinating a time to implement it into production (live environment). This code fix to the billing system was one of the many that came through.
The fix was implemented at midnight on a Tuesday and became a colossal failure. The billing system was so broken that workers were sent home for 3 days because there was no work for them. The estimated loss in revenues during this period of 3 days until the system could be brought back online exceeded $1 million dollars per day. The vendor was immediately involved, and the organization requested a fix for the fix.
As a new project analyst that started work 3 weeks prior to this event and being a very bright individual, you are instructed to spearhead the new fix coming to fix the system and to ensure that no future problems like this occur again.
What are your first steps? How would you plan to handle this upcoming fix? How would you plan for handling the potential risk with this planned fix?