Cataloging and Managing Risks

Risk is the possibility of suffering loss. The loss could be in the form of diminished quality of the migrated application, increased development and/or support cost, missed deadlines, or complete failure to achieve the mission and purpose of the project. In other words, a risk is a problem waiting to happen. It is recommended that the MSF approach to risk management be adopted, as illustrated in Figure 5.1. This approach allows you to retire risks through a process of identification, analysis, mitigation planning, tracking, and control.

Figure 5.1: The MSF approach to risk management

This type of risk analysis and planning is often referred to as risk driven scheduling. This type of planning is of particular use in UNIX to Windows workstation migration because of the overall scope of a migration.

Identifying Risk

Throughout the assessment stage, you will have been spotting and documenting issues surrounding the migration. The issues may be business-, technical-, application-, or infrastructure-specific. Before you can create a realistic project plan, you must determine whether any of the issues pose a serious risk to the project, and what should be done to minimize the probability of things going wrong.

In general, the more potential stumbling blocks ” attitudinal, structural, or otherwise ” you identify ahead of time, the easier it is for you to minimize the amount of time spent trying to resolve them during testing.

Issues can be of a business, technical, application, or infrastructure nature. You can now decide which issues are risks to the migration project. Identifying a complete set of risks now allows for a thorough analysis later. You should make it clear that it is better to identify a risk and then determine that it is of low priority at the analysis stage, rather than to discount it earlier on. This approach ensures more complete coverage, as well as reducing debate and demonstrating your willingness to listen to the project stakeholders.

Business Risks

Effective risk management must consider the business environment in which the project operates. Many information technology projects fail, not for technology or project management reasons, but because of larger organizational pressures that are typically ignored.

Table 5.1 lists some examples of non-technical risk sources and possible consequences.

Table 5.1: Business Risks

Categories of risk sources	Project consequences
Project resources	Cost overruns Schedule slips
Development process/environment	Inadequate functionality Poor product performance
Operational/support environment	Demoralized staff Application instability through incorrect administration Insufficient physical space
End user	Customer dissatisfaction Lack of application support
Distribution of user base	Deployment problems Difficulties in training users

A major source of risk is the resistance to change by management, operations staff, and users. UNIX is an established platform that enjoys a high degree of loyalty from many of its users, especially in terms of high-end applications, such as computer-aided design/computer-aided manufacturing (CAD/CAM), engineering, and software development. Those advanced users who have developed custom functionality for their UNIX applications and tools through shell scripting may be especially fond of it. Thus, it is also important to determine whether some people in the organization might be biased against the project because of their devotion to UNIX. The following are questions that should be addressed:

• How open is management to the idea of changing the environment?

• Is the value of the migration (that is, its benefits minus its costs) considered to be inadequate or negative? This question can be addressed at the risk analysis stage.

• Which groups might resist migrating to Windows? Groups could be organizational or geographical.

• Will users be open to the migration, open to it but with reservations , or totally opposed to it?

Additional risks may include unavailable personnel, and policy, procedural, or legal issues. In addition to the risks, migration projects also have constraints such as:

• Hardware lease expirations.

• Migration timetables.

• Resources availability.

• Expected cost savings.

Failure to achieve any of the constraints could also be construed as a risk.

Technical Risks

The application s technical context can be a major source of issues and risks. The following questions help you determine the technical risks of the application migration:

• Is the way in which your systems and networks are administered going to present any difficulties?

• Does the required experience to perform the migration exist in-house, or is it available from outside?

• Do you have adequate technical support from the application vendors ?

• Are there any specific constraints on standards conformance or security requirements ” for example, is the application safety-critical?

• Would a delay to the migration cause any problems ” for example, in terms of new technologies or versions of software being released?

• What contingency and disaster recovery plans are in place, and how will the migration affect them?

Application Risks

The application itself is a likely source of concern. You can identify potential risk areas by answering the following questions:

• Is the existing application code and scripts of sufficient quality to be ported? You should include configuration and installation scripts where these exist.

• How comprehensive is the existing development environment (for example, source control, configuration, build, debugging, and bug tracking)?

• Is current application performance considered sufficient by its users, and how will the migration affect this?

• Is there a shortfall between the existing application functionality and the needs of its users?

• Is the planned version of Windows too new for the UNIX application, or is the UNIX application simply incompatible with Windows?

• Is the technical complexity of the planned solution a cause for concern?

• Is backward compatibility required with the original application?

If you are porting a Fortran application, you should also consider the following risk areas:

• You will need a Fortran complier from a third party ” is it compatible with other tools?

• Call level integration will likely be needed between Fortran and C/C++ code.

• A cross-language build and debug strategy will be needed for Windows.

Infrastructure Issues

The supporting infrastructure, and dependencies between infrastructure and application elements, can also yield issues and risks. The following questions should be addressed:

• Is the current hardware infrastructure suitable for running Windows, and/or is replacement hardware being sought?

• If the ported application is to exist in parallel with the UNIX application, will the two infrastructures coexist without difficulty?

• Can the network support the testing requirements of the project, particularly performance and scalability testing?

• Are there any dependencies with, or impacts on, other infrastructure elements, especially proprietary systems and applications, languages, or scripts?

• Does the application depend on third-party software that is incompatible with Windows?

• Do you require to switch off any infrastructure elements before, during, or after the deployment of the new application?

Additional risks may include configuration problems, driver incompatibilities, scheduling conflicts, and resource conflicts.

Risk Analysis and Mitigation

The risk analysis stage involves taking each risk in turn and determining its constituent parts . You can consider a risk as being made up of:

• Description . The description must be in a language that the risk stakeholder (that is, who it affects) understands.

• Impact . The impact is the effect that the risk would have, if it happened .

• Probability . The probability is the likelihood of the risk becoming real.

• Severity . The severity is the scale of impact that the risk would have, if it happened.

• Cost . It may be possible to assign a specific cost to each occurrence of the risk.

• Mitigation . Mitigation is the actions to be taken to ensure that the probability of the risk is reduced or removed.

You can quantify risks in terms of both their probability and severity. You should determine mitigation actions for each risk; that is, one or more actions to ensure that the risk is minimized or removed. Most risk factors can be mitigated with proper project management. However, there are some risks that can quickly escalate and become critically important.

You can also use the mitigation to quantify the risk. For example, if a mitigation action is easily implemented, it may be seen as worth doing even if the risk probability is low. Mitigations can be classed as hard, medium, or easy, based on the perceived degree of difficulty in resolving the issue with the stated solution.

Table 5.2 lists examples of issues that need resolution for the success of a migration project. Each issue is listed along with a proposed solution or mitigation strategy. The issue is then classified using a severity level defined as risk to the success of the project: high, medium, or low. High severity means that the issue is a project showstopper if there is no resolution; low severity means there are other workarounds or alternative solutions.

Table 5.2: Example Issues

Issue	Impact	Mitigation	Severity	Implementation
Lack of support for X11R6. (Interix supports. X11R5.)	Some of the application s X functionality could be compromised	Verify applications dependence on Release 6. Application ma be able to use X11R5. X11R6 available from Interop Systems. http://www.interopsystems.com/Products2.asp	Low	Easy
Motif 1.2	Requires 3rd-party library	Use Motif 2.2 from Interop Systems. http://www.interopsystems.com/Products2.asp	High	Easy
Lack of support for xrt widgets from bluestone	Some of the application s X functionality could be compromised	Verify applications dependence on bluestone s xrt widgets vs.standard X toolkit. Need to verify availability of widget for Interix.	Medium	Medium
NIPC library needs to be ported to Interix subsystem	Could increase time/effort required to move the AT&T NIPC library to Windows/Interix.	Requires source code from AT&T, and assumes use of standard UNIX IPC mechanisms. Trail port to Interix to verify ported functionality.	High	Medium
Data complete source code port to Interix needs proof of concept trial port	Could increase time/effort required to move the MQSS application to Windows/Interix.	There were no dependencies discussed would make this a difficult port using Interix.	High	Easy

Note  

Fortran migration risks are best mitigated by first defining the Windows development environment. This includes which Fortran compiler to use, and how to integrate with C/C++ code or third-party libraries. Second, modularity of the Fortran code combined with platform-specific feature extraction into a C/C++ compatibility layer also enhances the ability of the code to migrate from UNIX to Windows. This is also essential if the application needs to target both the UNIX and Windows platforms.

Managing the Risks

Risks should be included in a common repository and reviewed on a regular basis. You should publicize the top ten risks in the form of a risk assessment document. Not only does this ensure that everyone is aware of the risks, it also shows how you are proactively managing the migration project.

You can reassess risks, and identify new ones, at regular intervals on the project. An opportunity to do this is at a milestone, where the reviews that take place should also incorporate a risk assessment. New risks should be included in the risk register as they are identified, whether or not a risk review is taking place.

However, there is no need for excessive risk management. Try to limit your risk assessment document to a maximum of ten high-priority risks most likely to threaten the project. You can then determine the additional contingency planning that is necessary at this point, taking into account the time frame and objectives of the project.