IT Project Risk Management




IT Project Risk Management











PDF version of this report
You must have Adobe Acrobat reader to view, save, or print PDF files. The
reader is available for free
download.

IT Project
Risk Management

by James G. Barr

Copyright 2021, Faulkner Information Services. All
Rights Reserved.

Docid: 00021114

Publication Date: 2106

Report Type: TUTORIAL

Preview

According to the Standish Group, only about one-third of all software
development projects are successful, with the standard of “success” being
projects delivered on time, on budget, and with the required features and
functions. To help improve that dismal percentage, IT project
managers should invoke basic risk management principles when planning and
conducting even the most modest IT initiative.

Report Contents:

Executive Summary

[return to top of this
report]

Only 31 percent of all software development projects are successful,
according to a 2020 market research report from the Standish Group;
“successful” meaning projects were delivered on time, on budget, and with
the required features and functions.

Related
Faulkner Reports
Setting Project Goals and
Measuring Performance Tutorial
Project Management
Planning and Scheduling Tutorial
Next Generation Project
Management Market Trends Market

By contrast, 50 percent of all software projects are challenged, i.e.,
they are delivered late, over budget, and/or without the required features
and functions, and 19 percent of software projects are outright failures,
either cancelled prior to completion or, even worse, delivered but never
used.1

While these statistics are shocking, they are not exactly surprising,
especially to IT veterans. What is surprising is that most IT
departments plan and conduct projects as if success were the norm.

However, since project success has been generally elusive, a responsible
chief information officer (CIO) – or quality or risk manager – should
insist that risk management principles be applied to all IT projects from
birth to death, or throughout their software development lifecycle (SDLC).

Proper IT project risk management is imperative, particularly as:

  • The pace of software development, especially mobile app development,
    has quickened.
  • More software is customer-facing, as opposed to traditional “back
    office” applications.
  • Software in all forms is under persistent – and often sophisticated –
    cyber attacks, which seek to exploit any code- or logic-related
    vulnerabilities.

Description

[return to top of this
report]

To help eliminate or at least mitigate the risks commonly associated with
IT project management, the project manager should:

1. Ensure the project has a clearly-defined and realistic set of
deliverables.

What is the project designed to deliver? Are the project
participants capable of fulfilling these deliverables? Do they
possess the requisite skills and experience? Do they have access to the
requisite resources (including, if necessary, special funding)? Do
they have a “track record” of completing projects (at least their
contributions to projects) on time and on budget?

2. Ensure the project has measurable milestones.

Milestones are typically intermediate results that demonstrate: (1) the
ability of project team members to adhere to a specific timetable; and (2)
the ability of those members to produce tangible results. Moreover, the
act of achieving periodic milestones illustrates that a project is on
target or that a project is behind schedule. If the latter, the project
manager can adjust the project, adding more resources for example, in an
effort to compensate for time lost.

3. Ensure the project team members are held accountable for a project’s
success or failure.

While the project manager should “own” the project, so too should each
project team member. Project failure without personal consequences is
a virtual recipe for project failure.

4. Execute service level agreements with “extra-enterprise” project team
members.

IT projects are frequently performed with the aid of consultants,
contractors, or other business partner personnel. As with any
outsourcing arrangement, the specific responsibilities of third-party
participants should be codified in one or more service level agreements
(SLAs). These agreements should define:

  • The expected availability of extra-enterprise personnel.
  • The process for reporting and correcting poor performance.
  • The obligation to protect enterprise information (which may be
    addressed separately in a non-disclosure agreement).

5. Refrain from relying on project management software.

While tools like Microsoft Project are useful for recording project
activity, they are not capable of managing a project. Only the
project manager can do that.

6. Use project meetings to share information, not make decisions.

Project meetings, particularly impersonal meetings like conference calls
are useful vehicles for exchanging information. They are not
especially useful for consensus building or decision making; in part,
because the decisions may only affect a few team members, and because some
of the attendees may be less than “attentive.” They may, for example, be
multitasking during the meeting.

7. “Pull the pitcher” if necessary.

Just as a baseball manager will summon a relief pitcher to replace an
ineffective thrower, a project manager should not hesitate to replace an
under-performing team member. A warning may be appropriate if time
permits, but, ultimately, a project cannot be held hostage to one or two
individuals who are not satisfactorily completing their assigned tasks.

8. Engage people with relevant skill sets.

For example, almost all IT projects could benefit from having a technical
writer onboard. Documentation is an underrated element in most IT
projects because many IT managers and technicians are poor
writers. Rather than resent the presence of a technical writer
(someone who may or may not have an IT background), most IT professionals
would embrace someone who could handle complicated writing chores.

Ideally, project team members – in particular, project team leaders –
should be certified. One popular and respected credential is Project
Management Professional (PMP), offered by the
Project Management Institute.

9. Build security, continuity, and compliance into all IT projects.

There’s a growing consensus that certain IT project deliverables like
security, continuity, and compliance are foundational. In other
words, these elements should be incorporated into each and every IT
project, not just because they’re essential but because the cost of
“retrofitting” them (adding them in later) could be prohibitive.

Consider a project to build a new customer-facing IT application:

  • Security – The application should boast sufficient
    safeguards to ensure that a customer’s personally identifiable
    information (PII) is safe from theft or misappropriation.
  • Continuity – The application should be integrated
    into the enterprise business continuity plan. If a disaster
    strikes, the application will be “continued” or recovered according to
    its business value.
  • Compliance – The application and the environment in
    which the application will function should conform to all relevant
    regulations and standards. For example, if the application is
    financial, Sarbanes-Oxley and Gramm-Leach-Bliley may apply. If the
    application processes healthcare data, HIPAA may apply. If the
    application is invoked by European customers, Basel II may pertain.

10. Employ Agile Project Management.

In the Agile model, software is developed in small sections called
iterations. When complete, each iteration is reviewed by the project
team, which then decides what the next iteration should be. This
dynamic framework in which planning and execution continuously interleave
enables the project team to revise the project in response to real-time
problems and evolving requirements.2

Current View

[return to top of this
report]

Enterprise Risk Management

Whether motivated by the need to improve IT project performance or IT
operations in general, more and more enterprise officials are embracing
enterprise risk management (ERM).

ERM is the process of analyzing an enterprise’s exposure to risk, and
determining how to handle such exposure. Enterprise risk, which is
the potential for disrupting enterprise operations, comes in a variety of
forms, including IT risk, financial risk, and security risk, among
others. Effective enterprise risk management relies on the consistent
application of risk management best practices, like the adoption of a
proven risk management framework.

Although many enterprises have developed or adopted complex schemes to
measure and manage risk, basic enterprise risk management is deceptively
simple:

  • Step 1: Identify Risks – First and foremost, risk
    management means knowing your risks. Devices such as scenario
    analysis, risk assessment, even old-fashioned “brainstorming” may be
    employed to identify risks.
  • Step 2: Rank Risks – Once risks are identified,
    they must be ranked, from severe to inconsequential. Ranking
    involves two factors: impact (if a risk were realized) and
    likelihood (the chances that a risk will occur).
  • Step 3: Measure Risks – In an environment where
    several elements exhibit high risk, it is often necessary to quantify
    the risk so that appropriate resources can be applied to risk reduction
    and risk control.
  • Step 4: Reduce Risks – The real reward in risk
    management is not knowing when or where two trains will collide, but in
    avoiding the collision. This is where risk managers often defer to
    their operational colleagues, encouraging them to develop methods of
    reducing risks by reducing risk impact or risk likelihood.

Risk Mitigation

There are four basic methods of mitigating risks:

  • Method 1: Risk Avoidance – Refraining from
    participating in “risky” activities. Within the context of an IT
    project, risk avoidance might involve replacing a project team member
    with a poor project management history. A project manager should
    not feel obliged to rehabilitate an individual who has failed at past
    project assignments.
  • Method 2: Risk Reduction – Limiting the severity of
    risk-related losses. For an IT project, risk reduction might
    involve scaling back on project deliverables if producing these
    deliverables seems, in retrospect, overly ambitious.
  • Method 3: Risk Toleration – Learning to accept
    certain risk-related losses. For example, an IT project may be
    expedited in an effort to bring a new application to market as soon as
    possible. If the accelerated schedule can be met without
    sacrificing quality, the application will be delivered early. If
    complications arise, the sponsor of the application will “have to live
    with” the original availability date.
  • Method 4: Risk Transfer – Transferring risk
    responsibility to another party (or parties). If the risk is
    security, for example, a project manager may delegate the risk by design
    or necessity to the CSO or other authority who will then own that risk.

Positive Risk

Risk is not all bad. As analyst Jamie Johnson observes, “most people
assume that all risks are inherently negative, but this is not true.”3
Suppose, for example, that an IT project involves the creation of a new
consumer application. Suppose, also, that demand for the application
increases beyond enterprise expectations. This positive development, or
positive risk, may result in accelerating the project schedule, thereby
realizing a faster return on investment. Speeding up application delivery,
however, may produce negative risks, like reducing test time and
potentially compromising application quality.

IT project managers should attempt to anticipate positive risks, and
apply the same due diligence in managing positive risks as they do the
more typical negative risks. See Table 1 for common positive-to-negative
risk correlatrions.4

Table 1. Positive-to-Negative Risk Correlations
Positive Risk Related Negative Risk
Users Request Additional or Modified Software Features or
Functions		 New or modified features or functions may be implemented “on the
fly,” i.e., without proper IT project risk management. Any
feature/function malperformance may tarnish overall IT project
performance.
Users Request Expedited Software Delivery Rigorous software testing may be sacrificed to save development
time.
Project Is Completed Ahead of Schedule Future IT project schedules may be shortened if officials conclude
that project schedules are, in general, inflated.
Project Is Completed Under Budget Future IT project budgets may be reduced if officials conclude
that project budgets are, in general, excessive.
Project Is Completed With Surplus Resources Future IT projects may be under-resourced if officials conclude
that some project resource requirements are unwarranted.
Project Success Drives Demand for Additional Projects Owing to resource constraints, future IT projects may be pursued
with inadequate staff, insufficient funds, and no reliable risk
management oversight and direction.
Project Receives More-Than-Normal Public Mention or Praise Hackers and other cyber criminals may target project software and
users, potentially resulting in security and privacy breaches.

Project Gold-Plating

Stepwise, a Polish “software house” warns against IT project
“gold-plating”, or showing off to users at the expense of project and
project team integrity. Developers [may] tend to showcase their skills by
adding solutions that add nothing to the product. An example would be the
use of the latest technology, which is still in Beta. Such a solution may
be innovative, but it may make it difficult or even impossible [for many
users] to use the application … (e.g. those who use older devices).”5

Inevitable Risk

Be advised that IT project risk is, in some cases, inescapable. As
Stepwise explains, “The project environment is full of inevitable risks
which are sometimes very difficult to predict. This includes political
changes in the country, changes to the law, as well as obsolescence in
software and technology. Software houses undertake more and more complex
projects, and software development is
developing
so dynamically
that the related risks are constantly intensifying. For this reason, the
strategic approach of software development companies to planning and
implementing digital projects becomes so important, [allowing] for
comprehensive and effective risk management in IT projects.”6

Recommendations

[return to top of this
report]

Risk Identification

An academic study conducted by Daranee Pimchangthong and Veera Boonjing
reveals that “Risk identification was the highest influence on all IT
projects success, and risk identification needs to be completed first.
Therefore, project managers should be aware of this practice to improve IT
project success rate.”7

Figure 1 illustrates the enterprise risk management process as a
continuing cycle from first,
Identify, to
Assess,
Evaluate

and
Control & Monitor.

Figure 1. The Enterprise Risk Management Process

Figure 1. The Enterprise Risk Management Process

Source: Captive Planning Associates (Creative Commons
License)

According to analyst Bart Jutte, there are certain “golden rules” of
project risk management. Among these are:

  • “Identify Risks Early in Your Project – The first
    step in project risk management is to identify the risks that are
    present in your project. Talk to … experts outside your project
    that have a track record with the type of project or work you are
    facing.
  • “Clarify Ownership Issues – Some project managers
    think they are done once they have created a list with
    risks. However this is only a starting point. The next step is
    to make clear who is responsible for what risk!
  • “Prioritize Risks – A project manager once told me
    “I treat all risks equally.” This makes project life really
    simple. However, it doesn’t deliver the best results
    possible. Some risks have a higher impact than
    others. Therefore, you better spend your time on the risks that can
    cause the biggest losses and gains.
  • “Plan and Implement Risk Responses – If you deal with
    threats you basically have three options: Risk avoidance, risk
    minimization, and risk acceptance. The biggest category of responses are
    the ones to minimize risks. You can try to prevent a risk occurring
    by influencing the causes or decreasing the negative effects that could
    result.”8

Outsourced IT Projects

When outsourcing an IT project, the chief information officer (CIO)
should:

  1. Inquire about the outsourcer’s approach to risk management, and
    reject any candidate companies that exhibit a cavalier attitude toward
    risk.
  2. Include reasonable risk management standards in the outsourcing
    contract or associated service level agreement (SLA).
  3. Appoint a risk management liaison – an individual from his or her
    staff that will work as part of the outsourcer’s team and monitor the
    project from a risk management perspective.
  4. Ensure that the risk management agenda includes both standard
    concerns, such as completing the project on time and on budget, as well
    as those supplemental concerns critical to all modern enterprises
    including regulatory compliance and data security.
  5. Budget for risk management oversight; in other words, include risk
    management costs when evaluating an outsourcing proposal.

New and Emerging Technologies

Just as expertise and experience can reduce the risk associated with IT
projects, insufficient expertise and experience can elevate that
risk. For projects involving cloud computing, virtualization,
enterprise mobility, Big Data, artificial intelligence (AI), machine
learning, robotics, the Internet of Things (IoT) and other new or emerging
technologies, enterprise IT planners should:

  1. Start with a few small projects before tackling any large-scale
    initiative.
  2. Secure expert guidance from a consulting firm that specializes in the
    target technology.
  3. Engage seasoned business partners, like IBM or Microsoft, where
    project deliverables demand extra-enterprise resources.
  4. Establish realistic return on investment (ROI) measures tailored to
    the target technology. What is success and how will it be measured?
  5. Secure management backing. Let enterprise officials know that
    new technologies present new risks, and that higher levels of risk
    tolerance may be required.

Software Testing

Almost all IT projects involve software development or
deployment. These projects are frequently delayed, often at the
reputational expense of the implementing organization, by inadequate
software testing. Since software testing is not a glamorous operation
and since software developers are notoriously optimistic about the quality
of their code, there is often not enough time or resources allocated to
installation verification and validation (IVV).

When assessing the risk associated with a particular IT project, an
analyst should evaluate the Software Test Plan (STP). The STP should
feature a mixture of:

  1. Functional tests
  2. Performance tests
  3. Integration tests (where two or more program elements are combined)
  4. User tests (frequently referred to as pre-production “beta” tests)

Programmers and other system developers should not participate in the
“official” software testing process; it is a conflict of
interest. Software testing should be conducted by the enterprise
Quality Assurance department, backed by third-party testers (as needed).

For customer-facing applications or applications available over the
Internet, security is a major concern. To help hacker-proof the
software, these applications should be subjected to “penetration testing”
or “pen testing.” In a pen test, an outside expert (often referred to
as an “ethical hacker”) attempts to penetrate application
defenses using the same tools and techniques that hackers normally
employ. The objective is to identify and permit the plugging of any
security holes before any malevolent forces can exploit them.

Pharmaceutical firms frequently admonish their customers to use their
drugs “as directed.” In many cases, software tests are designed to
verify that an application will work properly when used as
directed. A comprehensive testing regimen includes exercises that
reveal how an application will work when NOT used as directed; in other
words, how the application will work under “real” usage. A commitment
to robust software testing reduces IT project risk.

GDPR Compliance

The European Union (EU) General Data Protection Regulation (GDPR) builds
on the EU Data Protection Directive of 1995, which aimed to protect the
fundamental rights and freedoms of natural persons, focusing on their
right to privacy with regard to the processing of their personal data.

The GDPR not only applies to organizations located within the EU but it
will also apply to organizations located outside of the EU if they offer
goods or services to, or monitor the behavior of, EU data
subjects. It applies to all companies processing and holding the
personal data of data subjects residing in the European Union, regardless
of the company’s location.

As, arguably, the world’s most stringent regulation affecting data
security and privacy, IT project teams would be wise to adhere to GDPR
requirements, especially as GDPR compliance would likely ensure compliance
with most other security and privacy rules.

Cybersecurity

Virtually all IT projects today have an Internet component. Even
so-called legacy or backroom applications are being “Web-enabled” to
enhance their functionality and increase their availability. In this
atmosphere, cybersecurity is a top-tier risk, so much so that any project
manager who fails to incorporate adequate information-protecting
countermeasures is guilty of project management malpractice.

To ensure that cybersecurity receives sufficient attention, all IT
project teams must actively engage with the enterprise security department
during project design, development, and deployment; in other words, during
the entire project lifecycle.

IT Risk Management

To help aggregate, store, and process risk management data, IT project
teams should consider the acquisition of an IT Risk Management (ITRM)
solution. As described by Gartner, “ITRM solutions are deployed to
establish a central hub that facilitates business-related decision-making
and risk management.”

Among the leading providers are:

  • ServiceNow
  • Galvanize
  • RSA
  • NAVEX Global
  • IBM
  • MetricStream

According to Gartner, “MetricStream stands out in the market for its
vision to include risk owners from different parts of the organization to
voluntarily submit anomalies and observations to be considered for risk
assessment or incident analysis.”9

Engagement Leader

Finally, in managing the risks related to a large-scale IT project, it
may be productive – and prudent – to hire a third-party engagement leader.
As analyst Dave Ebert explains, “Sometimes, it can be too difficult to
align people and processes by yourself. External partners such as
engagement leaders are dedicated to delivering the best possible solution
in a timely manner and help you manage all of the moving parts (and
people) in your organization. Most importantly, they will help you manage
potential risks.

“Stakeholders in larger organizations often react to a review of risks
like the students at Hogwarts react to the word ‘Voldemort’, and they will
apply any means necessary to depress or challenge a citation of risks.
They may try to inhibit the risk discussion both verbally and formally,
because they don’t want their project to be on the ‘at risk’ project list
reviewed by their leadership. Some don’t even want to name a risk because
it could cast the project in a negative light.

“Rather than pretending potential problems don’t exist, your engagement
leader can lead an organized method to jump these hurdles.”10

References

[return to top of this
report]

  • 1 Henny Portman. “Review Standish Group – CHAOS 2020:
    Beyond Infinity.”
    Henny Portman    . January 6, 2021.
    2 Mike Cohn. “Succeeding with Agile – Mike Cohn’s Blog:
    Agile Succeeds Three Times More Often Than Waterfall.”

    Mountain Goat
    Software    . February 13, 2012.
  • 3 Jamie Johnson. “Project Risk Management: All You Need to
    Know.”
    Tallyfy    . November 22, 2017.
  • 4 “How Do You Manage Project Risk?”

    EIRE Systems K.K.
    2021.
  • 5 Krzysztof Szukiec. “Risk Management in IT Projects.”

    Stepwise.pl.
    November 10, 2020.
  • 6
    Ibid    .
  • 7 Daranee Pimchangthong and Veera Boonjing. “Effects of
    Risk Management Practice on the Success of IT Project.” Procedia
    Engineering     182 (2017). 2016:585.
  • 8 Bart Jutte. “10 Golden Rules of Project Risk Management.”
    Project Smart. 2000-2010.
  • 9 Khushbu Pratap, Brent Predovich, and Claude Mandy. “Magic
    Quadrant for IT Risk Management.”
    Gartner, Inc    . August 11, 2020.
  • 10 Dave Ebert. “How an Engagement Leader Can Help You Make
    Friends with Project Risk.”
    TandemSeven    . 2017.

[return to top of this
report]

About the Author

[return to top of this
report]

James G. Barr is a leading business continuity analyst
and business writer with more than 30 years’ IT experience. A member
of “Who’s Who in Finance and Industry,” Mr. Barr has designed, developed,
and deployed business continuity plans for a number of Fortune 500
firms. He is the author of several books, including How to
Succeed in Business BY Really Trying, a member of Faulkner’s
Advisory Panel, and a senior editor for Faulkner’s Security
Management Practices. Mr. Barr can be reached via email at
jgbarr@faulkner.com.

[return to top of this
report]