Copyright 2021, Faulkner Information Services. All
Publication Date: 2106
Report Type: TUTORIAL
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.
[return to top of this
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.
| 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
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,
- More software is customer-facing, as opposed to traditional “back
- Software in all forms is under persistent – and often sophisticated –
cyber attacks, which seek to exploit any code- or logic-related
[return to top of this
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
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
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
[return to top of this
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
- 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.
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
- 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.
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
|Related Negative Risk
Users Request Additional or Modified Software Features or
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
|Users Request Expedited Software Delivery
Rigorous software testing may be sacrificed to save development
|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.
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
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
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
[return to top of this
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,
Control & Monitor.
Figure 1. The Enterprise Risk Management Process
Source: Captive Planning Associates (Creative Commons
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
- “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
Outsourced IT Projects
When outsourcing an IT project, the chief information officer (CIO)
- Inquire about the outsourcer’s approach to risk management, and
reject any candidate companies that exhibit a cavalier attitude toward
- Include reasonable risk management standards in the outsourcing
contract or associated service level agreement (SLA).
- 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.
- 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.
- 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:
- Start with a few small projects before tackling any large-scale
- Secure expert guidance from a consulting firm that specializes in the
- Engage seasoned business partners, like IBM or Microsoft, where
project deliverables demand extra-enterprise resources.
- Establish realistic return on investment (ROI) measures tailored to
the target technology. What is success and how will it be measured?
- Secure management backing. Let enterprise officials know that
new technologies present new risks, and that higher levels of risk
tolerance may be required.
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:
- Functional tests
- Performance tests
- Integration tests (where two or more program elements are combined)
- 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.
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.
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:
- NAVEX Global
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
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
“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
[return to top of this
[return to top of this
About the Author
[return to top of this
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
[return to top of this