Question

Perform qualitative risk Analysis using a 5×5 matrix for software development System on 500 medical records for a health clinic

Levels of Probability and Impact on Four Specific Objectives Used to Evaluate Individual Risks.

Cost

Schedule

Resources

Scope

Answer 1

Health care information technology is on the brink of a paradigm shift. There is a push to implementing electronic medical records, and there are substantial risks associated with this critical initiative. These risks need to be identified and managed. Fortunately, project management is designed to manage risks. Project management methodology has a systematic approach to anticipating unknown risks, prioritizing known risks, and placing resources and attention toward those most likely to threaten the critical success of the project. There are, in effect, two types of risks associated with Health Care IT projects: project risks and organizational risks. These risks need to be managed meticulously in order for the organization to realize the business benefits and value of the project outcome. This paper will address both types of risks.

While there are many ways to approach risk, and these methods vary by culture and industry, these differences are being addressed in other forums.

Risk Analysis in Software Testing

Risk Analysis is very essential for software testing. In software testing, risk analysis is the process of identifying risks in applications and prioritizing them to test. A risk is a potential for loss or damage to an organization from materialized threats. Risk Analysis attempts to identify all the risks and then quantify the severity of the risks. A threat as we have seen is a possible damaging event. If it occurs, it exploits vulnerability in the security of a computer based system.

Items with higher risk values should be tested early and often. Items with lower risk value can be tested later, or not at all. It can also be used with defects.

How to perform Risk Analysis during software testing

When a test plan has been created, risks involved in testing the product are to be taken into consideration along with the possibility of their occurrence and the damage they may cause along with solutions; if any. Detailed study of this is called Risk Analysis.
Some of the risks could be:

1. New Hardware.
2. New Technology.
3. New Automation Tool.
4. Sequence of code delivery.
5. Availability of application test resources.
   
   In Software Testing some unavoidable risk might takes place like:
6. Change in requirements or incomplete requirements.
7. Time allocation for testing.
8. Developers delaying to deliver the build for testing.
9. Urgency from client for delivery.
10. Defect Leakage due to application size or complexity.
11. 
    To overcome these risks, the following activities can be done.
12. Conducting Risk Assessment review meeting with the development team.
13. Profile for Risk coverage is created by mentioning the importance of each area.
14. Using maximum resources to work on High Risk areas like allocating more testers for High risk areas and minimum resources for Medium and Low risk areas.
15. Creation of Risk assessment database for future maintenance and management review.
16. Identify and describe the risk magnitude indicators: High, Medium and Low
17. 
    High magnitude means the effect of the risk would be very high and non-tolerable. Company may face severe loss and its reputation is at risk. It must be tested.
    Medium: tolerable but not desirable. Company may suffer financially but there is limited liability or loss of reputation. It should be tested.
    
    Low: tolerable. Little or no external exposure or no financial loss. Company's reputation is unaffected. It might be tested.
    
    Three perspectives of Risk Assessme
18. Effect.
19. Cause.
20. Likelihood
21. Effect - To assess risk by Effect, identify a condition, event or action and try to determine its impact.
22. Cause - To asses risk by Cause is opposite of by Effect. Begin by stating an undesirable event or condition and identify the set of events that could have permitted the condition to exist.
    Likelihood - To asses risk by Likelihood is to determine the probability that a requirement will not be satisfied.
    
    Risk Identification
    
    There can be different type of risks include as follows-
    
    
    Software Risks: Knowledge of the most common risks associated with Software development, and the platform you are working on.

1. Business Risks: Most common risks associated with the business using the Software.
2. Testing Risks: Knowledge of the most common risks associated with Software Testing for the platform you are working on, tools being used, and test methods being applied.
3. Premature Release Risk: Ability to determine the risk associated with releasing unsatisfactory or untested Software Products.
4. Risk Methods: Strategies and approaches for identifying risks or problems associated with implementing and operating information technology, products and process; assessing their likelihood, and initiating strategies to test those risk.
   

   	Cost	Schedule	Resource	Scope
   Inadequate communication, more is better than less	0.1	0.35	0.35	0.2
   Vendor relationship	0.4	0.2	0.2	0.2
   Protection from Obsolensce – do not install an old system that will need major upgrade in few months, or will be sunsetted in few years (contractual protection – service agreements.)	0.1	0.2	0.5	0.2
   Make sure you know your TCO (total cost of ownership) early on and let your executives and board know & Establish a PMO (Project Management Office) to assist with the planning and implementing your high-profile projects.	0.25	0.25	0.15	0.35

   Risk Monitoring and Control in Health Information Technology Projects

   	Sources of Risk	Risk Management Strategy
   1	Planning Risks	Avoid misunderstandings & scope creep, do SOW and WBS. Management commitment is critical, and needs to be built into the plan. If the project is too low in the management hierarchy, this task takes on added importance and takes more time as well. Support infrastructure must be identified or built into the plan. Alignment of the existing infrastructure elements may be needed to incorporate the new features of the project outcome. Reputation/credibility are important to earn trust of stakeholders; select and communicate credentials and track record. Visibility has pros and cons; getting the organization involved is necessary for quality; tell them what to expect so they buy in. Funding must be based on accurate estimates and realistic for the full scope of the product life cycle. Budget for close out. Public relations are a part of the plan; a conflict management plan is less visible, but is part of good risk management. Put detractors into the risk management plan and assign someone to maintain relationships with each skeptic throughout the project. Organizational/Project Governance
   2	Initiation Risks	Avoid grandiose goals. SMART goals are necessary to engage the best efforts of the team and to sustain credibility for the end results. If you cannot quantify it and manage the triple constraint, break it into smaller, sequential projects. Do not over promise; protect early estimates of time and cost from becoming set in stone. Estimates are based on operations that have already benefited from repetition and refinement.
   3	Scheduling Risks	Delay: Seek out historical precedence from other IT projects in the past. What is the average delay, and typical causes? Overrun: Calculate the average standard overrun of other projects and build that into conservative estimates of completion. Crashing: Is it a habit? It is a risk? Is it a result of poor planning? Inertia: Create a sense of urgency with realistic but firm due dates. Implications of inertia are that letting the project extend too long allows unknown crises to immerge. Over-analyzing issues is counterproductive; select project managers with a natural inclination to take action. Deliverable/milestone tracking system
   4	Resources Risks	Practitioner: Get the right expertise, protect their allocation by involving their management in the value proposition. Proper orientation, training, job roles and teamwork are a given. Delegate enough authority so they are empowered to do their job, and protect them from unwanted interference. Know when to escalate to their upper management to avoid stalling. Middle Management: Focus on relationship skills as well as technology or business knowledge; do not underestimate the importance of meetings. It is not top down; it is middle up.* Try weekly meetings to review priorities and backlogs. Executive: Get and keep the right sponsorship at the right organizational level to run interference for the project on all fronts. Project governance needs to be set at the right organizational level to involve the key players in all departments. Allocation: compare to other projects 100% allocation, not more to avoid burn-out, implement methods for retention. Executive sponsor intervention…stealing staff Lack/shortage – hire & retain the best and brightest Access to qualified expertise Contracting: if possible (pros/cons) feasibility (expand the role of the business analyst to incorporate the entire system. Hire business analysts who can sell the concept and negotiate the appropriate support or issue resolution.)
   5	Procurement Risks	Vendor Management Contracts/agreements Legal Advice Maturity level match of capabilities
   6	Quality Risks	Avoid compromises or Gold Plating Quality assurance Quality control Advocacy vs. collaborative decision making (quality process)
   7	Communication Risks	Inadequate communication, more is better than less Appropriate media for level of recipient and content/complexity of message
   8	Education/Training Risks	Type (educate versus train) Amount of training and its cost Timing of training - Just in time training Certifications periodically and ongoing Value to delivery critical success factor
   9	Relationship Risks	Vendor relationship Team relationship Sponsor relationship Stakeholders relationships Users relationships Suppliers relationships All other relationships
   10	Budgetary Risks	Budget overrun, Cost Benefit Analysis (CBA) Cost Model ROI TCO
   11	Critical Path failure risk	Deliverable/milestone tracking system Contingency plans/ make or buy/ alternatives & options
   12	Technology Risks	Hardware/software, networks, firewalls, infrastructure, etc. have the right resources; use proven/reputable vendors/systems. Measure the maturity level of the technical environment. Use checklists for qualify measures, certifications for staff, etc. Document features & functions in the contractual agreements and manage the contract. Assess the physical environment: if you are going electronic for the first time, you need space for the equipment – desk/counter space for the workstation, printer, scanner, etc. In patient rooms, if you are using computers on wheels (COWs) you need to have space to manoeuvre, if you are using wireless technology, you have to have adequate access points (AP). Before all this, you need to have the right infrastructure: WAN/LAN/WLAN to support the new technology. Protection from Obsolensce – do not install an old system that will need major upgrade in few months, or will be sunsetted in few years (contractual protection – service agreements.) Ensure adequate customer support coverage – 24x7x356 and high availability, have escalation procedures in place for mission critical applications, and negotiate the cost of this high-level support. Use thriving vendors that continue to grow and develop their products, have good market share, and outstanding customer relationships, ask for references, call the references and hear their stories, do site visits, etc. Make sure you know your TCO (total cost of ownership) early on and let your executives and board know. Have a sound plan for software management: maintenance, troubleshooting, upgrades & patches, optimization, and a credible/defensible estimates. Establish a PMO (Project Management Office) to assist with the planning and implementing your high-profile projects. Keep good records – documentation/contracts/minutes, etc Reward high performers and celebrate success!
   13	Acts of God – Force Majeure	Death Accidents Fires, floods, other Natural Disasters Etc.

   The goal of this is to share knowledge about risk management with the day-to-day practitioners, equip them with the tools to use on the job, and make them better project managers in risk assessment and documentation. We also, hope to instil confidence to use these techniques. We did not cover it all! This is a very dynamic field and information grows exponentially.

   In summary, we have tried to describe the environment for healthcare information technology, the key players in this field, the critical issues, and industry experience.

   The challenge is to introduce new concepts by using a holistic approach to managing risk. Taking into consideration the project as well as the organization, the software as well as the hardware, the programmer as well as the end user, consider partnering with your IT vendor. Plan and have a contingency plan. Involve your stakeholders and executives, and let them have a sense of ownership. Successful HIT projects are a collaborative effort, and working together is the only path to success.

   Note: probablities have been decided on an estimate by just deciding importance of the object with factors