Project risk is defined as an uncertain event or condition that, if it occurs, has either a positive or negative effect on a project’s objective. Generally speaking, the degree of uncertainty is directly proportional to the magnitude of change proposed. A complete migration to a new technology platform would, for instance, create more risks than say a minor upgrade of an existing platform. In a world of global economic uncertainty, the project team should not make things worse! The project risk management plan should provide stakeholders with the comfort that the project will deliver on the business objectives.
IT projects
require both a change of technology and operational processes to benefit from
the new investment. The result is a double
risk since either the technology or processes could fail and imperil the
project success as a whole. Whereas an IT team is likely to focus on the
technology, business users tend to focus on the process issues. The relative influence
of these two stakeholders determines how the risks are handled and the success
of the project risk management plan.
This feature
article highlights some of the major risk areas of concern in an IT project.
The article uses examples from a banking environment to show how a project team
can identify and deal with both the technical and process risks at critical
phases of an IT project.
Categorizing the Risks in an IT
Project
Risk
identification is about determining and documenting risks that might affect the
project. Broadly speaking, there are two main risk categories reflecting common
sources of risk in an IT project; the technical and organizational. The two
relate to the complexities of new technology and the internal realignment of
resources in new processes respectively. Crystallizing technical risks can lead
to significant delays in project completion, major cost overruns, and
operational problems. On the other hand, organizational risks expose the
business to delayed benefits, low user satisfaction levels, and high volumes of
support calls, among others.
In a financial
services environment, IT projects are usually strategically designed to improve
the competitive edge of the bank. Both technical and process problems are taken
very seriously because they could result in massive financial losses in
addition to lost opportunities. In a recent banking software project, the team
incorporating both the business users and the technical staff was co-located on
site. Process re-engineering was defined as a key deliverable in the project
plan to ensure that the technical development is matched with changes in
process maps to take advantage of new business features.
Managing Technical Risks
One way to
identify technical risks is to have a brainstorming session for the project
team. In a banking scenario, the team should consist of experts from various
areas such as software applications, hardware, network, security, and call-center
teams. Whether upgrading an existing system or migrating to a totally new
system, there are two core issues to look out for. First, because the entire
bank business is built on customer information, you must not lose any data
essential for customer transactions. Secondly, the interfaces from one
subsystem to another must work properly to provide seamless customer service.
Data Integrity
In the financial services industry, data integrity is
of paramount importance, both in internal operations and as a matter of
regulatory compliance. Anti-money-laundering laws and regulations governing
electronic money transactions increasingly require banks to acquire and keep
protected customer information. Therefore, all data such as customer
identification details, account balances, loans, and standing instructions are of
critical priority. A bank that cannot properly identify its customers would be
promptly shut down by the regulators or fraudulent actors whichever occurs
first!
In a typical
data migration from one system to another, the technical team maps data fields
from one system to another. A problem occurs when there is a major change in data
structures as shown in Table 1
|
Old System |
New System |
Risk |
||
|
Data Type |
Field |
Field |
Data Type |
|
|
Text |
Customer name |
Customer name |
Text |
None |
|
Numeric |
Account balance |
Account balance |
Numeric |
None |
|
Numeric |
Standing instruction amount |
Standing instruction amount |
Numeric |
None |
|
Date |
Standing instruction date |
Standing instruction date |
Date |
None |
|
Numeric |
Restricted amount |
Alert |
Boolean |
Data loss |
Table 1 – Data Structures
In the above example of a bank record, the format of
customer data is the same in both the old and new systems, except for the
restricted amount field. If a customer in the old system has a balance of
$10,000 in his or her account and, for example, the tax authority instructed
the bank to hold $2000 in disputed taxes pending resolution, the old system
restricts such amounts and the customer can only access the balance of $8000
for transactions. In the new system, this function is not available and is
executed as a general category of alerts in which a pop-up screen with
predefined text prompts a supervisor override. This can present a serious risk
of loss of data and requires a careful review of each individual account
affected.
Interfaces
In the case of a bank, a working interface is
required between the core software and other systems such as automatic teller
machine (ATM) modules, an Internet module or an electronic payments module. Details
of ATM transactions must be correctly and promptly updated, so that the same
customer can receive accurate details in real time through other channels (e.g.
Internet banking) or else money can be lost.
In addition,
consistency of interface configuration across platforms can be a source of
risks. This relates to the look and feel of the screen presentation to internal
and external users. It only makes sense that information is presented in a
consistent format across interfacing systems to an end user. A customer should
find similar details whether they are using an ATM Internet banking screen. Such
consistency reduces training costs and errors. This would also accelerate the
rate of adoption.
Technical Risk Response Plans
Several strategies can be adopted to respond to
technical risks as explained below:
Avoidance – it is important to obtain all the relevant information about existing
and new data format. In the banking case above, the old data types and fields
are identified and comprehensively mapped into corresponding types and fields
in the new system. If some old data are to be dropped or new data required in
the migration, a complete impact assessment should be done, options should be reviewed,
decisions agreed and signed off properly with particular attention to default
field values.
Similarly, in regard to interfaces, it is better to
use the inbuilt capabilities before attempting to interface with other systems.
An inbuilt ATM module in banking software obviates the need to interface with
another system so long as business requirements are met.
Transfer – Fixed-price contracting can help avoid escalating costs for the
client by transferring costs of extensive interface changes and bug fixes to
the banking software vendor; however, care should be taken to clearly define
the deliverables and related acceptance test procedures.
Mitigation – In banking, it is easy to test for “totals” in sample or pilot
tests with parallel runs. For instance, the transaction data used in the old
system are fed into the new system and comparisons are made on the outputs from
the two systems. Is the total number of transactions or accounts reported the
same? Is the total amount in suspense accounts the same? If there are
discrepancies, then the project team can drill down to find the root cause. If
the total number of accounts is not the same, is it the saving account,
checking account, or another type of account? This kind of testing will prevent
surprises on launch day.
Contingency
planning- Developing new processes around the
banking operations is the best way to fire-proof technology projects. For
instance, a manual data capture process can be put in place to deal with any
lapses in data migration for the bank customers. In the event that straight-through
processing fails between interfaces, a manual intervention process for a periodic
data update should be put in place. This ensures that customer service
continues, albeit with some delays.
Fig 1-Risk
Response Steps
|
A |
Identify Process Risks
New processes are necessary if business is to cash in on the benefits of technological deployments. Today, technology is used to transform the way business is done rather than to simply automate tasks. An ATM machine is more than a robotic bank teller dispensing cash; it offers a unique service at a low cost and in settings in which a teller would not fit. Additionally, new processes are used to mitigate risks arising from technology, such as the Internet threats that come with Internet banking.
A bank ATM, unlike the teller, does not carry the risk of getting sick, require overtime pay, and neither will it visit “Facebook” pages when no one is looking! However, it does require someone to load it with cash and the program details of what dollar bills are in which dispenser slot; otherwise, it will issue hundred-dollar bills just as often as twenty-dollar bills all day long! New processes are needed to govern the operations of the ATM network to mitigate the new risks of loss and exploit the opportunities created by the 24-hour access, card identification, and screen output functions, among others. Proper risk-response planning is, therefore, a main item in designing the new processes.
Internal Processes
A change of banking software application should be accompanied by revised work flows to exploit performance gains as well as improve controls. Oftentimes, the processes provide revised ways to capture data and produce or use system reports. The main areas of risk include user mistakes due to lack of understanding of the new processes, new capabilities may lie dormant or underutilized, and there could be vulnerabilities in the system or processes that compromise security controls and expose the business to expensive losses.
Consider a banking software project meant to provide a centralized enterprise database, enhance the quality of data available in the systems, and provide support for new channels while reducing the use of paper in the company. New processes designed to guide the users are needed, whereas additional software development could be necessary in certain cases to meet the user needs. Table2 below illustrates some of the issues that the project team can easily identify and the corresponding risk response plans.
Risk Issue | Risk Type | Old System | New System | Risk Response Plan | Additional Controls Needed | |
Data input;simple to use screen | User mistakes | Open one screen for one transaction | Open multiple screens for one transaction | Mitigation —user training and new process | Interface development to reduce screens | |
| Production of reports;timely reports | New capabilities | Off-line daily printout reports | Online report | Accept;no interventions | Developed repository for additional reports available for printing on an as-needed basis. |
Central data access; global availability of customer data | New capabilities and security controls | Several independent data bases | Single data base | Exploit—identify new products and processes | Developed guidelines to avoid frauds | |
Table 2 – Internal Risks
Note that additional development requirements may be needed to mitigate against the risks surrounding the processes. The project risk response plan should provide for this as part of the contingency planning. It is important at this point to clearly differentiate between new requirements and current project scope. Some of the new opportunities identified may best be exploited in a separate project.
External Processes
Just as in internal processes, changes to external processes are necessary to optimize the benefits of new technology. In this case, the key risk areas include users’ failure to understand the new processes, customer dissatisfaction with new features, and vulnerabilities in the system or processes that could compromise security controls and expose the business to expensive losses.
In the banking software project, some examples of the issues that the project team managed are shown on table3 below.
Table3 – External Risks
Risk Issue | Risk Type | Old System | New System | Risk Response Plan | Additional Controls Needed |
Teller transaction request; simple process | User mistakes
| Fill out transaction form | System generates receipts | Mitigation— customer training | development of smaller simple form |
Customer statement; provide key details | Customer dissatisfaction | Many details | few details | Accept | Customer communication |
Additional channels. Internet/mobile banking | Security controls | Not available | Available | Exploit —identify new processes | Security controls and processes for new products |
In this case, the initial response plans proved inadequate, and additional interventions were designed, emphasizing the need to continually monitor and review the risk-response plans.
Conclusion
IT projects provide a real opportunity for companies to dramatically improve performance through increased efficiencies and introduction of new products. Concerns over risk management in IT projects, however, continue to linger. Although the technology may be superb, it is the business processes that convert new functionality into business opportunities for maximum competitive advantage while ensuring that adequate controls are in place to avoid business losses.
Risk-response plans should be developed and continually monitored and reviewed to address both the technical and process risks. On one hand, loss of data and malfunctioning interfaces are of great concerns from a technical perspective, resulting in delays and escalating costs;on the other hand, adequate processes should be put in place to address user mistakes, exploit new capabilities, and provide security controls. Otherwise, this could lead to additional delays, user dissatisfaction, and business losses. Companies that properly manage the risks associated with IT projects stand the greatest chance of overcoming the current economic challenges.
About the Author
Francis Gituru is a project management consutant. He has worked on a large portfolio of projects and has gained valuable experience over the years. He holds an M.B.A degree in strategic management from United States International University, Nairobi.