Conversations oneffectiveit management

Computer Aid, Inc. presents

Conversations on
Effective IT
Management

Welcome
Effective IT Management:
A Bridge Over Troubled Waters
Every task we undertake and every project respect to IT projects, the experience of the result of human nature: people don’t
we initiate encounters some degree of risk. the project manager, the maturity of the like to think about, discuss, or expend
Successful managers identify and evaluate management processes, the completeness much effort on risk mitigation. Project
risks in order to determine if the risks of the requirements, and the cooperation teams focus their attention on risks that
should be accepted or mitigated. The risk of business executives are examples of risks impact schedules (“Will we meet our
assessment process should measure the that cannot be mathematically calculated. deadline?”) rather than the future impact
probability (likelihood) of the risk occur- of undetected errors. In the world of
How do we measure the potential impact?
rence and the resulting impact or severity software maintenance, where business
Most failures occur as a partial failure, i.e.,
of the occurrence. impact is more immediate, the focus is on
a single defect, often a single line of code.
containment and recovery after a failure
Calculating the probabil- How do you measure the “failure” of a
rather than prevention.
ity of a risk is difﬁcult line of code, when its impact on business
especially when there is depends on precisely which line of code Risk assessment is both an art and a
little historical data. With has failed? It can be argued the time lag science. The science requires a deﬁned
between occurrence and detection results process to consistently evaluate, measure,
in the greatest impact. and mitigate risk. The art involves apply-
ing subjective values and experience to the
This release of Conversations on Effective
various components under evaluation.
IT Management includes interviews with
subject matter experts from the academic The interviews in this report discuss the
and business world who discuss risk and value of communicating uncertainties and
the processes involved in evaluating and evaluating the probability of failure in the
measuring it. Many of the issues are software development life cycle.

ii Computer Aid, Inc. presents CONVERSATIONS ON EFFECTIVE IT MANAGEMENT

Contents
01
Tim Lister
Changing Your View of Risk
A great risk manager is one who not only watches the risk at hand but
also searches through consultation with others for new risks likely to
appear as the project’s environment changes.

03
Dr. Victor Basili
A Question of Measurement
The Goal Question Metric (GQM) paradigm is the most popular way
to measure a model. The idea is to build an “experience factory” that
will let you predict and optimize everything you’ve got.

05
Dr. Robert Charette
No Time to Waste
When you’re looking at risk management, there are two things you
need to do. First, you need to prioritize your risks. Second, you need to
mobilize [your solution] against them.

09
Dr. Robert Charette
Why Software Fails
As our society comes to rely on IT systems that are ever larger, insight is
needed into what may go wrong and what can be done to eliminate or
mitigate the risk.

15
Tony Salvaggio
IT Risk Management
An insightful perspective that deals with how organizations address
IT Risk Management on individual projects as well as throughout the
global enterprise.

Computer Aid, Inc. presents CONVERSATIONS ON EFFECTIVE IT MANAGEMENT iii

A CONVERSATION WITH:

Tim Lister
Changing
Your View
Tim Lister is a principal of the
Atlantic Systems Guild, Inc. He is
presently involved in assisting organi-
zations with IT risk management and

of Risk
in tailoring methodologies and select-
ing tools for software development
groups to increase project productiv-
ity and product reliability.

Mr. Lister is also a Fellow of the
Cutter Business Technology Council,
a member of the Leadership Group
of Cutter Consortium’s Enterprise
A great risk manager is one who not only watches the risk
Risk Management & Governance
at hand but also searches through consultation with oth-
practice, and a Senior Consultant
ers for new risks likely to appear as the project’s environ-
with Cutter’s BusinessIT Strategies, ment changes.
Agile Software Development & Proj-
ect Management, and Sourcing and Extracted from an interview more often than not you have to ﬁght
Vendor Relationships Practices. conducted by Michael Milutis early problems rather than late ones.

Mr. Lister and Tom DeMarco are A classic early problem occurs when a
CAI: How would you actually deﬁne
looming deadline looks tight and you
coauthors of Peopleware: Productive risk management and its key compo-
nents? may need to hire more people to make it.
Projects and Teams and the risk man-
Getting people early and integrating them
agement book Waltzing with Bears: TIM LISTER: Risk management is the pro- into the project can help you enormously,
Managing Risk on Software Projects. cess of unearthing both uncertainty and whereas waiting too long to hire and
They are also authors of the popular risk in projects. It asks what the unwanted train additional people is often wasteful
Achieving Best of Class seminar as possible consequences of an event or a and useless. Risk management is about
decision are. The essence of risk manage- understanding when to make decisions. It
well as the course and video sequence
ment software is to help us decide whether involves a conversation among all of the
Controlling Software Projects:
to deal with problems before they appear stakeholders – the technical people, the
Management, Measurement, and or to wait till they clearly emerge and then sponsors, the users, the managers about
Estimation. deal with them as problem management. the best time to make decisions. At risk
I’ve been in software all my life, so I may time, we ask the question of whether to
be biased, but I think software particularly spend some money to lower the prob-
lends itself to risk management because ability of a problem or how to lower the

1 CONVERSATIONS ON EFFECTIVE IT MANAGEMENT

cost should the problem occur, or some and pay for it later if we judge there is no ing real risk management. A small minor-
combination thereof. advantage in tackling it now. ity do it very well. There are also some
who say they do it, but what they do is
Risk management assumes that careful Another aspect of evaluation is judging
identify risk and go back to business
study of a plan will result in someone the probability of a risk becoming a prob-
as usual. They may have a little
spotting a potential problem. Risk lem. Are we looking at a one in a thou-
step early in their process
management says, “Let’s identify and sand or a 50/50 risk? And then there’s cost
that says, “Identify risk,
understand the risks early, determine their evaluation. If the risk hits, what’s it going
evaluate risk,” but
root causes, and decide whether it makes to cost us in terms of manpower, delay
there is no
good business sense to spend money on schedule, money? In the prioritization
evidence
before or when the problem hits.” There is component, we ask what are the most
they
no way to identify all the risks at the start important risks in terms of probability
of a large project and manage them down. and cost. Finally, there is the strategizing
A great risk manager is one who not only component where we ask such questions
watches the risk at hand but also searches as the following: When do we make the
through consultation with others for call? What are our options here? How
new risks likely to appear as the project’s long can we delay before we take action or
environment changes. should we act immediately and mitigate
the risk up front?
The major components of risk
management are identi-
fication, evaluation,
prioritization,

do anything with that information.

In genuine risk management, you change
something on a big project based on
rigorous risk assessment. You change your
development strategy, you change the
sequence, the definition of the project, the
schedule, the staffing, and you keep a de-
tailed record and rationale of the decision-
CAI: How then would you character- making which led to such changes. This
ize the current state risk manage- kind of risk management is rather rare.
ment practices throughout corporate
and strategizing. Just because somebody IT organizations?
identifies or “nominates” (a term I prefer)
a risk early doesn’t mean we are going to TIM LISTER: Sadly, I would say the vast

do anything about it. We might accept it majority of organizations are not practic- Continued on Page 19
Computer Aid, Inc. presents CONVERSATIONS ON EFFECTIVE IT MANAGEMENT 2


Dr. Victor Basili
A Question of
Measurement
Dr. Victor R. Basili is Professor of
Computer Science at the University
of Maryland. He holds a Ph.D. in
Computer Science from the Univer-
sity of Texas and honorary degrees
from the Universities of Sannio
(Italy) and Kaiserslautern (Ger-
many). He was Executive Director The Goal Question Metric (GQM) paradigm is the most
of the Fraunhofer Center Maryland popular way to measure a model. The idea is to build an
and a founder and principal of the “experience factory” that will let you predict and optimize
Software Engineering Laboratory everything you’ve got.
(SEL) at NASA/GSFC.

He is a recipient of numerous
Extracted from an interview was developed in the mid-70s. It’s still the
awards including a NASA Group conducted by Michael Milutis most popular way in the world to measure
Achievement Award, a NASA/GSFC a model – any kind of model. The concept
Productivity Improvement and Qual- CAI: What is the value of process and behind it is really rather straightforward.
ity Enhancement Award, the 1997 measurement? Why is it so important? GQM essentially states that before you de-
Award for Outstanding Achievement cide what you measure, you need to ﬁgure
VICTOR BASILI: Whatever the product,
out what you want to know. Therefore,
in Mathematics and Computer Sci- whether it’s software or something else,
you have to constantly track your goals,
ence by the Washington Academy of process is important, because it is the only
and that’s how you track the data. This
Sciences, the 2000 Outstanding Re- way to optimize what you are doing. And
makes it sound simpler than it really is.
measurement is important because it’s the
search Award from ACM SIGSOFT,
only way you can observe and get feed-
and the 2003 Harlan Mills Award
back about what is really happening. CAI: To what extent is a successful
from the IEEE Computer Society.
measurement initiative contingent
upon standard processes? How do
Dr. Basili has authored over 200 these two things hang together?
CAI: There are so many different
papers, served as Editor in Chief of organizations and so many different
consumers of metrics within all of VICTOR BASILI: I have a slightly contrar-
several journals (IEEE TSE, Journal
these organizations. In light of this, ian perspective on this. I think process is
of Empirical Software Engineering) how are we supposed to determine a variable that needs to be tailored to the
and program chair and general chair what to measure and why we should speciﬁc problem at hand. Although you
of several conferences (ICSE). He is be measuring?
may have lots of commonalities in your
an IEEE and ACM Fellow. VICTOR BASILI: Actually that’s the Goal processes, they each have to be a little bit
Question Metric (GQM) paradigm which different for various projects.


While we were at NASA Goddard, we de- The seventh step is to package all of this what is happening, what should have hap-
veloped an approach to this called quality knowledge so that it becomes part of your pened, and what will happen. And you’re
improvement. The ﬁrst step in using this processes, part of your organization, part making changes to the way you under-
model is to collect data that doesn’t neces- of the way you think about how you solve stand your organization.
sarily tell you where you are or what you’re all of your problems. And then the next
At the end of all of this you will end up
doing. We called it “characterized” data project comes through and you keep go-
with a lean and optimized set of processes
but I heard you guys call it “visualized” ing. You build up and save this knowledge
for various classes of problems. Your
and I like that term. I like it because that’s in what we call an experience base.
future projects will be different, but that’s
what you are doing – you are visualizing
The idea at the root of all of this is to OK because you’ll have classes of processes
what’s going on in your environment.
build an “experience factory” within that will work for different kinds of proj-
The second step is to set your goals for an organization. Such an experience ects. You will be able to conduct predic-
particular projects and also for the entire base can tell you at any given point tions and optimize everything you’ve got,
organization. Where does this organiza- how your projects are being developed. including code.
tion want to be and how will this project But while all of this is happening, you
contribute to the overall knowledge that is are also learning that every project is an
within the organization? experiment. You’re testing and observing

In the third step you choose your process,
one that allows you to achieve your
goals relative to your environment,
relative to what the business is about,
and relative to what you’ve got in the
present moment.

The fourth step is to do it.

The ﬁfth step is to try to do as
much feedback and analysis as
you can in real time in order to
help manage the project and to
help increase learning from that
project. Your real goal is to learn
from every project you perform
at a particular organization.

The sixth step is about the
analysis you do after the project
has been completed. You’ve
done as much analysis as you
can in real time, and that’s
usually very complicated.
But now you must do more
analysis. With post-project
analysis we try to recognize
what really happened, what
was a success, what wasn’t a
success, etc.



Dr. Robert Charette
No Time to
Waste
Dr. Robert Charette is an interna-
tionally acknowledged authority
and pioneer in information systems
and technology, systems engineer-
ing, risk management, and the lean
development and management
of large-scale software-intensive
When you’re looking at risk management, there are
systems. He is currently President
of the ITABHI Corporation, an
two things you need to do. First, you need to prioritize
international high technology
your risks. Second, you need to mobilize [your solution]
company involved in information
against them.
and telecommunications systems
management consulting. Extracted from an interview To understand this linkage, you ﬁrst of all
conducted by Michael Milutis need to worry about principles. What is
Dr. Charette is also on the advisory it, for instance, that you are trying to ac-
board of the Project Management CAI: How would you deﬁne software complish in terms of managing risk? What
risk management? Can you break it are the things that you really value as an
Institute’s Special Interest Group
down into key components for us? organization when it comes to risk? For
on Risk Management. He has instance, are you a risk-taking company or
served, additionally, as an elected ROBERT CHARETTE: I look at software a risk-averse company? Which one will de-
chairman of the U.S. Software risk management as I look at risk manage- termine your risk tolerance? What are the
ment as a whole. It’s all about making things that you value as an organization
Engineering Institute Risk Advisory
high quality decisions through high in terms of managing risk? For example, is
Board (1995-1997), as a member
quality risks. Risk management is just an open and honest communication of risk a
of the National Research Council’s element of decision making and software core organizational principle?
Review Committee of Space Shuttle risk management is just a sub-component
The second thing you need to worry
Software Safety (1992-93), and as of systems engineering risk management
about is the risk management process
Vice-Chairman and Chairman of which, in turn, is a sub-component of
itself. What do you need to have in place
business or enterprise risk management.
the National Security Industrial that is visible, repeatable, and measurable
I don’t believe that you can say there’s
Association Software Committee in terms of a risk management process?
something called software risk management
(1988-89, 1990-91). He is currently without also saying that you’re involved in The third thing is behavior. Behavior is
on the editorial board of Software systems risk management or in business risk critical because when we make choices, we
Quality Professional magazine. management. The three are really intimately intend to act. When it comes to risky situ-
interconnected. This gets back to the linkage ations, we need to think about what we
between strategy and technology. want people in our organization to do as
well as what we don’t want them to do.


When you’re looking at doing risk man- pen, couldn’t (and shouldn’t) you also be And if you manage to mobilize the right
agement, you need to create a principle- applying those same resources to things resources to deal with one set of risks, you
based, process-focused, behavior-driven that you know really are happening? will simultaneously be making a conscious
system — a system in which any two of its choice not to mobilize against some other
As you can see, the process can quickly
pillars support the third. For example, the set of risks, which effectively means that
become very messy. It is often quite
principles and processes you create must you are accepting those risks. In this
counter intuitive, and that is something
condition the risktaking behaviors you respect, knowing what your opportunity
that is eternally fascinating to me, because
desire within your organization. Similarly, costs are is going to be key.
were dealing here with potentialities,
the behaviors and processes should rein-
with trade-offs, with futures, and to really
force the risk principles you value.
understand what is going on with these CAI: The Standish Group reported
You have to understand what it is that intricacies, your thought processes have that over 70% of software projects
you want people to do when they are to be broad, deep, and quick. It’s like the undertaken by large, small, and mid-
faced with risk, when they are faced with old saying “cheaper, faster, better - pick any size organizations came in over-time,
something that may make it look like two.” In managing risk, you often
they’re not going to succeed. You have to can identify and prioritize the
convince people to look at things differ- risks, but you may not
ently than they normally do. But within a be able to mobilize
framework; otherwise you risk making the to actually deal
kinds of mistakes that ensue from more ad with them.
hoc approaches.

What has always been intriguing to me
about risk management is that, superficial-
ly, it appears extremely easy. You simply
look at what might occur, you clarify how
these things might hurt you, and then you
develop some approaches to keep the bad
outcomes from coming into being.

However, while the process itself can
appear to be quite superficial, it quickly
becomes extremely subtle and complex.
That’s because risks are perceived and
unreal. They are only possibilities. They
are not actual things. By the time risks
become actual things, they are already
problems and at that point they cease to
be risks.

Furthermore, when you try to manage
or reduce these probabilities, you quickly
come up against a perplexing problem:
if one allows resources to be spent on
the reduction of risk, will the probabil-
ity of project success be increased or, in
fact, reduced? In other words, if you are
spending finite resources to reduce mere
probabilities, things that might not hap-


over-budget, or not at all. What is the of Defense, where risk management prac-
relationship, in your opinion, between CAI: Would you be able to quantify tices have been mandated now for almost
the practice of risk management and the percentage of IT organizations 30 years, is that although a large number
these success and failure rates? Do that are using risk management
of organizations are using risk manage-
you think that risk management can practices properly and getting posi-
ment, its practice is really just pro-forma.
and should be used to address these tive benefits from them?
types of problems? In other words, they’re applying a tick-
ROBERT CHARETTE: One of my side jobs in-the-box risk management process, and
ROBERT CHARETTE: Risk management is that I am the Director of Enterprise it’s not affecting organizational decision
is very important for creating successful Risk Management and Governance for making in any way.
projects. Effective risk analysis and man- the Cutter Consortium. We did a study
agement will help you identify what your back in 2002 that took a look at orga-
assumptions are, what your constraints nizational risk management practice. To CAI: Could you highlight for us what,
are, what your real objectives are and what answer your question, we found that 51% in your opinion, might represent the
of the organizations we surveyed claimed top three software development risk
can go wrong. Effective risk manage-
factors?
ment will also highlight the perspectives to be using some sort of formal approach
and expectations of the various project to assess or manage risk. In other words, ROBERT CHARETTE: How about the top
stakeholders involved. It is a superb tool 51% had some sort of repeatable process 100?
for bringing issues to the surface that that they were following. Nevertheless, of
the organizations we surveyed, only 39% The primary factor I see is the lack of real-
traditionally get glossed over.
were applying software risk manage- ism. Our industry likes to over-promise
That being said, I think we need to make ment practices. In fact, risk management and under-budget. We seem addicted to
a distinction between project failures was still a fairly new practice within the unrealistic objectives and unrealistic goals,
and project blunders. Many of these so- organizations we surveyed. On average, we even in the face of very complex projects.
found that companies had been using risk We pretend that we know more than we
called project failures are actually, in my
management for only four or five years. do, and then feign surprise when things
experience, blunders. A blunder is when
Consequently, program and project risk don’t go as planned.
we don’t do the things that we know we
should be doing and that we are also able management has yet to be integrated into The second major factor lies in the fact
to do. We know how to create success- a corporate approach to managing risk. that, as an industry, we tend to be very
ful IT systems, for instance, but in most What was interesting, though, is that sloppy in terms of our development prac-
cases we simply don’t bother to apply the although there was a minority of people tices. If you take a look at the Software
practices that are out there for increasing using software-specific risk management Engineering Institutes CMM or CMMI
our project success rates. practices, 90% of the people in our survey results, you will see that the vast majority
agreed that managing IT risk was either of organizations are still employing undis-
Moreover, if you look at the relationship be- ciplined or chaotic development practices.
important or very important for achiev-
tween risk management and project success Poor project management practice is
ing project success. In fact, 75% believed
— and Dr. Bill Ibbs over at UCal Berkeley pervasive throughout the development
that software risk management made their
has been doing a lot of research in this area world today. And poor project manage-
projects more successful than projects that
— you will find that risk management is ment will take a project down faster than
didn’t employ risk management practices.
the least used of all the project management any other type of risk factor except the
disciplines. Not surprisingly, it’s least used However, if I were to refer simply to my lack of realism.
in the IT community. The IT community own personal experiences, I would say that
the number of people who are using soft- The third major factor revolves around
simply does not apply risk management ef-
ware risk management practices effectively politics. Projects do not sit in an objec-
fectively. The corollary, of course — and this
is probably in the 20-30% range, and I’m tive, purely rational vacuum. They are
is reflected in Bill’s research, too — is that
probably being optimistic here. One of part of a greater whole, one involving
those organizations that do use risk manage-
the problems that I regularly encounter the political realities of an organization.
ment tend to have a higher level of project
even in organizations like the Department Most people don’t manage organizational
success than those that do not. politics well, nor do they recognize their
7 Computer Aid, Inc. presents CONVERSATIONS ON EFFECTIVE IT MANAGEMENT

importance to project success. because you’ve allocated resources to try to blown risk assessment they should at least
avert it. You’re not done until your mitiga- conduct an assumptions analysis, because its
Each of these three factors, and there
tion strategy has actually accomplished its the assumptions that underpin your project.
are certainly more, must be examined,
goals. So once again, in the short term, You need to constantly test those assump-
understood, and managed in a very ag-
attack those things that are going to cause tions against reality.
gressive, realistic, holistic, and honest way.
the most amount of damage to you soon-
And we should not ever underestimate the
est. Second, be aware of the great danger
importance of honesty. We must always CAI: You mentioned the importance
posed by the medium risks, too. The
ensure that our objectives are both realistic of having measures, of being able to
medium level risks are the ones that really
and honest. The paradox with honesty, of
can hurt you because they are the ones objectively measure against things
course, is that you might have a hard time in order to develop a starting point.
that you tend to accept. And if you have
getting your project supported if you are What do you think of the relative
enough of them, they can overwhelm you. value of external versus internal
totally honest about the risks that exist.
The worst thing in the world, in my opin- benchmarking data?
The temptation to over-promise is rooted
ion, is having lots and lots of medium level
in this paradox. To be unrealistic, however, ROBERT CHARETTE: You have to get
risks on your project. I’d much rather man-
is to court disaster. That is far worse. information from the inside of your orga-
age a project that has lots of reds and greens;
don’t give me one with lots of yellows. nization. Set up your measurement pro-
What this means is that until we get a
grams, start getting data, and at that point
development environment both at the
Finally, keep in mind, despite their very compare what you have with the external
business end and at the technical end, a
low corresponding probability, that there world. I should also mention that I rarely
fact-based environment in which we can
are still some extremely high consequence see organizations that have effective risk
be honest, then all of our risk factors will
risks that may be able to take you out. management programs in place without
just be exacerbated.
Keep a close eye on them. also having very effective measurement
programs as well. It’s kind of a chicken
CAI: Once identified, organizations and egg problem, though. Do you start
CAI: How would you characterize
could spend years investigating their with a measurement program first and a
the importance of processes in all
own risk items. In light of this, what risk management program second, or vice
of this? From a process perspective,
is the most practical approach for versa? I’m not sure, but if your leadership
what in your opinion are the critical
proceeding, once the risk identifica-
success factors for effective software is willing to simply state “Where are we?”
tion phase has been completed?
risk management? that’s a good start.
ROBERT CHARETTE: There are two
ROBERT CHARETTE: First of all, you
things you need to do. First, you need to
need to have some measures. You need
prioritize your risks. Second, you need to
to have information that is fact-based
mobilize against them.
or evidence-based. Whether or not
Regarding prioritization, there are two you call them software measures, or
simple questions that you can ask yourself performance measures, it doesn’t
here: 1) what is going to hurt me the really matter to me. What I’m
most; and 2) what is going to hurt me interested in is having something
soonest? You must deal with these risks that I can objectively measure
right away; specifically, the ones that are against, and then predict against.
going to keep you from accomplishing I also need a process that’s going
the next milestone or the next objective in to help me evaluate not only my
your schedule. objectives, but also my assump-
tions and constraints. We tend not
Regarding mobilization, and this is an area to look at our assumptions. One of
that people tend to forget about, you must the things that I frequently tell organi-
remember that a risk hasn’t gone away just zations is that if they can’t perform a full-


Dr. Robert Charette
Why Software
Fails
As our society comes to rely on IT systems that are ever
larger, insight is needed into what may go wrong and
what can be done to eliminate or mitigate the risk.

Excerpted from IEEE Spectrum information technology industry for 20-
Magazine, September 2005 Issue some years. It’s probably apocryphal, but
for those of us in the business, it’s entirely
Have you heard the one about the plausible. Why? Because episodes like this
disappearing warehouse? One day, it happen all the time. Last October, for
vanished — not from physical view, but instance, the giant British food retailer J
from the watchful eyes of a well-known Sainsbury PLC had to write off its U.S.
retailer’s automated distribution system. $526 million investment in an automated
A software glitch had somehow erased supply-chain management system. It
the warehouse’s existence, so that goods seems that merchandise was stuck in the
destined for the warehouse were rerouted company’s depots and warehouses and
elsewhere, while goods at the warehouse was not getting through to many of its
languished. Because the company was in stores. Sainsbury was forced to hire about
financial trouble and had been shuttering 3,000 additional clerks to stock its shelves
other warehouses to save money, the manually.
employees at the “missing” warehouse kept
This is only one of the latest in a long,
quiet. For three years, nothing arrived
dismal history of IT projects gone awry.
or left. Employees were still getting their
Most IT experts agree that such failures
paychecks, however, because a different
occur far more often than they should.
computer system handled the payroll.
What’s more, the failures are univer-
When the software glitch finally came to
sally unprejudiced: they happen in every
light, the merchandise in the warehouse
country; to large companies and small; in
was sold off, and upper management
commercial, nonprofit, and governmen-
told employees to say nothing about the
tal organizations; and without regard to
episode.
status or reputation. The business and
This story has been floating around the


societal costs of these failures — in terms of wasted taxpayer and government IT projects underway that totaled $20.3 billion. In
shareholder dollars as well as investments that can’t be made — 2004, the U.S. government cataloged 1,200 civilian IT projects
are now well into the billions of dollars a year. costing more than $60 billion, plus another $16 billion
for military software.
The problem only gets worse as IT grows ubiquitous. This year,
organizations and governments will spend an estimated $1 tril- WHEN A PROJECT FAILS, it jeopardizes an organi-
lion on IT hardware, software, and services worldwide. Of the zation’s prospects. If the failure is large enough,
IT projects that are initiated, from 5 - 15% will be abandoned it can steal the company’s entire future. In
before or shortly after delivery as hopelessly inadequate. Many one stellar meltdown, a poorly
others will arrive late and over budget or require massive rework- implemented resource planning
ing. Few IT projects, in other words, truly succeed. system led FoxMeyer Drug
Co., a $5 billion wholesale drug
The biggest tragedy is that software failure is for the most part
distribution company in Car-
predictable and avoidable. Unfortunately, most organizations
rollton, TX, to plummet into
don’t see preventing failure as an urgent matter, even though that
bankruptcy in 1996.
view risks harming the organization and maybe even destroy-
ing it. Understanding why this attitude persists is not just an IT failures can also stunt economic
academic exercise; it has tremendous implications for business growth and quality of life. Back in 1981,
and society. the U.S. Federal Aviation Administration began
looking into upgrading its antiquated air-traffic-
SOFTWARE IS EVERYWHERE. It’s what lets us get cash from an
control system, but the effort to build a replace-
ATM, make a phone call, and drive our cars. A typical cell phone
ment soon became riddled with problems. By
now contains 2 million lines of software code; by 2010 it will
1994, when the agency finally gave up on the
likely have 10 times as many. General Motors Corp. estimates
project, the predicted cost had tripled, more than
that by then its cars will each have 100 million lines of code.
$2.6 billion had been spent, and the expected
The average company spends about 4 - 5% of revenue on delivery date had slipped by several years. Every
information technology, with those that are highly IT dependent airplane passenger who is delayed because of
— such as financial and telecommunications
companies — spending more than 10% on
it. In other words, IT is now one of the
largest corporate expenses outside em-
ployee costs. Much of that money goes
into hardware and software upgrades,
software license fees, and so forth, but
a big chunk is for new software proj-
ects meant to create a better future for
the organization and its customers.

Governments, too, are big consum-
ers of software. In 2003, the United
Kingdom had more than 100 major


gridlocked skyways still feels this cancel- and problems and increase the likelihood to correct the error will likely be many
lation; the cumulative economic impact of failure. times greater than if they’d caught the
of all those delays on just the U.S. airlines mistake while they were still working on
Consider a simple software chore: a pur-
(never mind the passengers) approaches the initial sales process.
chasing system that automates the order-
$50 billion.
ing, billing, and shipping of parts, so that And unlike a missed stitch in a sweater,
Worldwide, it’s hard to say how many a salesperson can input a customer’s order, this problem is much harder to pinpoint;
software projects fail or how much money have it automatically checked against the programmers will see only that errors
is wasted as a result. If you define failure pricing and contract requirements, and are appearing, and these might have
as the total abandonment of a project arrange to have the parts and invoice sent several causes. Even after the original error
before or shortly after it is delivered, and to the customer from the warehouse. is corrected, they’ll need to change other
if you accept a conservative failure rate calculations and documentation and then
The requirements for the system specify
of 5%, then billions of dollars are wasted retest every step.
four basic steps. First, there’s the sales pro-
each year on bad software.
cess, which creates a bill of sale. That bill In fact, studies have shown that software
WHY DO PROJECTS FAIL SO OFTEN? is then sent through a legal process, which specialists spend about 40 - 50% of their
Among the most common factors: reviews the contractual terms and condi- time on avoidable rework rather than on
■ Unrealistic or unarticulated project tions of the potential sale and approves what they call value-added work, which
goals them. Third in line is the provision pro- is basically work that’s done right the first
■ Inaccurate estimates of needed cess, which sends out the parts contracted time. Once a piece of software makes it
resources for, followed by the finance process, which into the field, the cost of fixing an error
■ Badly defined system requirements sends out an invoice. can be 100 times as high as it would have
■ Poor reporting of the project’s status been during the development stage.
Let’s say that as the first process, for sales,
■ Unmanaged risks
is being written, the programmers treat If errors abound, then rework can start
■ Poor communication among every order as if it were placed in the to swamp a project, like a dinghy in a
customers, developers, and users
company’s main location, even though storm. What’s worse, attempts to fix an
■ Use of immature technology
the company has branches in several states error often introduce new ones. It’s like
■ Inability to handle the and countries. That mistake, in turn, you’re bailing out that dinghy, but you’re
project’s complexity
affects how tax is calculated, what kind of also creating leaks. If too many errors are
■ Stakeholder politics
contract is issued, and so on. produced, the cost and time needed to
■ Commercial pressures complete the system become so great that
■ Sloppy development The sooner the omis-
going on doesn’t make sense.
practices sion is detected and
■ Poor project management corrected, the better. In the simplest terms, an IT project
It’s kind of like knitting usually fails when the rework exceeds the
Of course, IT projects rarely
a sweater. If you spot a value-added work that’s been budgeted
fail for just one or two rea-
missed stitch right after for.
sons. The FBI’s VCF project
you make it, you can simply unravel
suffered from many of the All of which leads us to the obvious ques-
a bit of yarn and move on. But if you
problems listed above. Most tion: why do so many errors occur?
don’t catch the mistake until the end,
failures, in fact, can be traced
you may need to unravel the whole SOFTWARE PROJECT FAIL-
to a combination of techni-
sweater just to redo that one stitch. URES have a lot in
cal, project management,
common with airplane
and business decisions. Each If the software coders don’t catch their
crashes. Just as pilots
dimension interacts with the omission until final system testing —
others in complicated ways or worse, until after the system has
that exacerbate project risks been rolled out — the costs incurred


never intend to crash, software develop- tle luggage around frequently derailed. changing fast and promising fantastic new
ers don’t aim to fail. When a commercial Eventually, United Airlines, the airport’s capabilities, it is easy to succumb. But
plane crashes, investigators look at many main tenant, sued the system contractor, using immature or untested technology is
factors, such as the weather, maintenance and the episode became a testament to the a sure route to failure.
records, the pilot’s disposition and train- dangers of political expediency.
The IT debacle that brought down Fox-
ing, and cultural factors within the airline.
A lack of upper-management support can Meyer Drug a year earlier also stemmed
Similarly, we need to look at the business
also damn an IT undertaking. This runs from adopting a state-of-the-art resource-
environment, technical management,
the gamut from failing to allocate enough planning system and then pushing it
project management, and organizational
money and manpower to not clearly beyond what it could feasibly do.
culture to get to the roots of software
establishing the IT project’s relationship to
failures. A project’s sheer size is a fountainhead of
the organization’s business.
failure. Studies indicate that large-scale
Chief among the business factors are
Frequently, IT project managers eager to projects fail three to five times more often
competition and the need to cut costs.
get funded resort to a form of liar’s poker, than small ones. The larger the project,
Increasingly, senior managers expect IT
overpromising what their project will do, the more complexity there is in both its
departments to do more with less and do
how much it will cost, and when it will be static elements (the discrete pieces of
it faster than before; they view software
completed. Many, if not most, software software, hardware, and so on) and its
projects not as investments but as pure
projects start off with budgets that are too dynamic elements (the couplings and in-
costs that must be controlled.
small. When that happens, the developers teractions among hardware, software, and
Political exigencies can also wreak havoc have to make up for the shortfall some- users; connections to other systems; and
on an IT project’s schedule, cost, and how, typically by trying to increase pro- so on). Greater complexity increases the
quality. When Denver International ductivity, reducing the scope of the effort, possibility of errors, because no one really
Airport attempted to roll out its auto- or taking risky shortcuts in the review and understands all the interacting parts of the
mated baggage-handling system, state testing phases. These all increase the likeli- whole or has the ability to test them.
and local political leaders held the project hood of error and, ultimately, failure.
Sobering but true: it’s impossible to
to one unrealistic schedule after another.
AFTER CRASH INVESTIGATORS CON- thoroughly test an IT system of any real
The failure to deliver the system on time
SIDER the weather as a factor in a plane size. Roger S. Pressman pointed out in his
delayed the 1995 opening of the airport
crash, they look at the airplane itself. Was book Software Engineering, one of the clas-
(then the largest
there something in the plane’s design sic texts in the field, that “exhaustive test-
in the United
that caused the crash? Was it carrying too ing presents certain logistical problems...
States), which
much weight? Even a small 100-line program with some
compounded the
nested paths and a single loop executing
financial impact In IT project failures, similar questions
less than twenty times may require 10
manyfold. invariably come up regarding the project’s
to the power of 14 possible paths to be
technical components: the hardware and
Even after the executed.” To test all of those 100 trillion
software used to develop the system and
system was com- paths, he noted, assuming each could be
the development practices themselves.
pleted, it never evaluated in a millisecond, would take
Organizations are often seduced by the
worked reliably: 3,170 years.
siren song of the technological impera-
it chewed up
tive — the uncontrollable urge to use the All IT systems are intrinsically fragile. In a
baggage, and the
latest technology in hopes of gaining a large brick building, you’d have to remove
carts used to shut-
competitive edge. With technology hundreds of strategically placed bricks to
make a wall collapse. But in a 100,000-
line software program, it takes only
one or two bad lines to produce


major problems. In 1991, a portion of because they involve tradeoffs based on nizational environment. Does the airline
AT&T’s telephone network went out, fuzzy or incomplete knowledge. Estimat- have a strong safety culture, or does it em-
leaving 12 million subscribers without ing how much an IT project will cost phasize meeting the flight schedule above
service, all because of a single mistyped and how long it will take is as much art all? In IT projects, an organization that
character in one line of code. as science. The larger or more novel the values openness, honesty, communication,
project, the less accurate the estimates. and collaboration is more apt to find and
THE PILOT’S ACTIONS JUST BEFORE a
It’s a running joke in the industry that IT resolve mistakes early enough that rework
plane crashes are always of great interest
project estimates are at best within 25% of doesn’t become overwhelming.
to investigators. That’s because the pilot is
their true value 75% of the time.
the ultimate decision-maker, responsible A recent report by the National Audit
for the safe operation of the craft. Simi- There are other ways that poor proj- Office in the UK found numerous cases of
larly, project managers play a crucial role ect management can hasten a software government IT projects’ being recom-
in software projects and can be a major project’s demise. A study by the Project mended not to go forward yet continuing
source of errors that lead to failure. Management Institute, in Newton Square, anyway. The UK even has a government
PA, showed that risk management is the department charged with preventing IT
Back in 1986, the London Stock Ex-
least practiced of all project management failures, but as the report noted, more
change decided to automate its system
disciplines across all industry sectors, and than half of the agencies the department
for settling stock transactions. Seven
nowhere is it more infrequently applied oversees routinely ignore its advice. I call
years later, after spending $600 million, it
than in the IT industry. Without effective this type of behavior irrational project
scrapped the Taurus system’s development,
risk management, software develop- escalation — the inability to stop a project
not only because the design was excessive-
ers have little insight into what may go
ly complex and cumbersome but also be-
wrong, why it may go wrong, and what
cause the management of the project was,
can be done to eliminate or mitigate the
to use the word of one of its own senior
risks. Nor is there a way to determine
managers, “delusional.” As investigations
what risks are acceptable, in turn mak-
revealed, no one seemed to want to know
ing project decisions regarding tradeoffs
the true status of the project, even as more
almost impossible.
and more problems appeared, deadlines
were missed, and costs soared. Poor project management takes many oth-
er forms, including bad communication
Bad decisions by project managers are
which creates an inhospitable atmosphere
probably the single greatest cause of soft-
that increases turnover; not investing in
ware failures today. Poor technical man-
staff training; and not reviewing the proj-
agement, by contrast, can lead to technical
ect’s progress at regular intervals. Any of
errors, but those can generally be isolated
these can help derail a software project.
and fixed. However, a bad project manage-
ment decision — such as hiring too few THE LAST AREA THAT INVESTIGATORS
programmers or picking the wrong type of LOOK into after a plane crash is the orga-
contract — can wreak havoc.

Project management decisions are often
tricky precisely


even after it’s obvious that the likelihood practices known to avert mistakes are line of code is written, both the customer
of success is rapidly approaching zero. shunned. It would appear that getting and Praxis agree on what is desired, what
Sadly, such behavior is in no way unique. quality software on time and within is feasible, and what risks are involved,
budget is not an urgent priority in most given the available resources.
IN THE FINAL ANALYSIS, big software fail-
organizations.
ures tend to resemble the worst conceiv- After that, Praxis applies a rigorous devel-
able airplane crash, where the pilot was Even organizations that get burned by opment approach that limits the number
inexperienced but exceedingly rash, flew bad software experiences seem unable or of errors. One of the great advantages of
into an ice storm in an untested aircraft, unwilling to learn from their mistakes. In this model is that it filters out the many
and worked for an airline that gave lip a 2000 report, the U.S. Defense Science would-be clients unwilling to accept the
service to safety while cutting back on Board, an advisory body to the Depart- responsibility of articulating their IT
training and maintenance. If you read the ment of Defense, noted that various requirements and spending the time and
investigator’s report afterward, you’d be studies commissioned by the DOD had money to implement them properly.
shaking your head and asking, “Wasn’t made 134 recommendations for improv-
SOME LEVEL OF SOFTWARE FAILURE
such a crash inevitable?” ing its software development, but only 21
will always be with us. Indeed, we need
of those recommendations had been acted
So, too, the reasons that software projects true failures — as opposed to avoidable
on. The other 113 were still valid, the
fail are well known and have been amply blunders — to keep making technical
board noted, but were being ignored, even
documented in countless articles, reports, and economic progress. But too many of
as the DOD complained about the poor
and books. And yet, failures, the failures that occur today are avoid-
state of defense software development!
near-failures, and plain able. And as our society comes to rely
old bad software Some organizations do care about software on IT systems that are ever larger, more
continue to quality, as the experience of the software integrated, and more expensive, the cost
plague us, development firm Praxis High Integrity of failure may become disastrously high.
while Systems, in Bath, England, proves. Praxis
Like electricity, water, transportation, and
demands that its customers be committed
other critical parts of our infrastructure,
to the project, not only financially, but
IT is fast becoming intrinsic to our daily
as active participants in the IT system’s
existence. In a few decades, a large-scale
creation. The company also spends a tre-
IT failure will become more than just an
mendous amount of time understanding
expensive inconvenience: it will put our
and defining the customer’s requirements,
way of life at risk. In the absence of the
and it challenges customers to explain
kind of industry-wide changes that will
what they want and why. Before a single
mitigate software failures, how much of
our future are we willing to gamble on
these enormously costly and complex
systems?

We already know how to do software well.
It may finally be time to act on what we
know.



Tony Salvaggio, CEO of CAI
IT Risk
Management
Anthony (Tony) Salvaggio is CEO
and President of Computer Aid,
Inc. (CAI), an international IT
outsourcing firm that is currently
managing active engagements with
over one hundred Fortune 1000
companies and government agencies
around the world. CAI employs
Extracted from an interview array of technologies and projects that
over 2,500 associates across the conducted by Michael Milutis we are working with at any given time,
United States, Europe, and Asia. and the various cultural and regulatory
Mr. Salvaggio founded CAI in 1981 CAI: What is your perspective on Risk environments within which we function,
and since then CAI has been lever- Management in the IT sector? How both domestically and internationally. It
do you address this on individual requires continual organizational learning
aging the lessons of manufacturing projects and also, throughout the along with the rigorous documentation
in their development and mainte- enterprise?
and institutionalization of that learning.
nance of software. Prior to founding This is also tied to another principle, and
TONY SALVAGGIO: Risk Management
CAI, Mr. Salvaggio spent 22 years is something that has real meaning for a strong corollary; namely, how do we get
at IBM. In 2003, Mr. Salvaggio us. On any given day, CAI is managing our teams to continually perform close to
was a recipient of Ernst & Young’s approximately 2,500 IT professionals their highest levels, on a daily basis, given
“Entrepreneur of the Year” award. around the world who are charged with our total organizational knowledge and
executing very specific software develop- experience over two decades?
In 2004, he founded the IT Metrics
ment and maintenance projects. In all
and Productivity Institute.
of these initiatives, CAI is contractu-
ally bound, either partially or totally, to CAI: Could you share with us some
of the specific strategies that you
execute to specific targets, objectives, SLAs
have employed for addressing these
or deadlines. As a result, our organiza- challenges?
tional survival is dependent upon making
sure that none of our people do anything TONY SALVAGGIO: Please recognize that

that will get us sued or lose customers. I whatever strategies I share with you come
get frightened just thinking about it. from over two decades of continuous
learning, experience, and evolution. As a
We have survived over the course of two result, how we function today is dramati-
decades by focusing very carefully on the cally enhanced from how we functioned
implementation of Risk Management best five years ago. And this will be true once
practices. This is no small challenge given more in another five years.
the size of our organization, the broad


Nevertheless, to answer your ques- person, something that is known in
tion, we have stayed focused over the the industry as the “expert judgment”
years on several overarching strategies method. Moreover, estimates can be
for mitigating IT risk. These strategies politicized, so any estimate should be
are primarily a response to the project validated and scrutinized by a second
failure statistics that have plagued the or third party, independent of the
IT industry since its inception. Such origin of the initial estimate.
failures represent a major risk for all IT
You must also make sure that you are
and software organizations, but they
always tracking the estimate versus the
also represent an enormous opportunity
actual, at a work component or module
and by developing strategies that address
or project level, and you must have a
this directly, we’ve been able to trans-
method for feeding these actuals back
form such risks into an area of competi-
into your estimation process, so
tive advantage.
that you can continually learn
First of all, and perhaps most importantly, from experience and history
it is almost impossible to recover from and so that you are able to
systemically poor estimation and bad adapt on a daily basis.
scope management. Consequently, it is of This data should also be
the utmost importance to be continually very visible to all
building up the best possible estimation members of the
and scope management practices within project team
the organization, given the total amount
of organizational knowledge, past and
present, that is available.

Consistent with this, estima-
tion should never be
the product of an
individual


and to management. And whatever
the project size, a project plan must be
updated with actuals and reported to
all key stakeholders on at least a weekly
basis.

We are also very big believers in work
review processes and methodologies.
Wherever possible we use a project
office approach. Depending on the
size and inherent risk of each project,
this approach has evolved into vari-
ous management and reporting sys-
tems. We believe that with projects
that are only managed and reviewed
by the project team and the project
team’s direct management, serious
trouble may not be recognized until
it is too late.

What ties all of this together? Time
reporting. It’s not glamorous, but
your estimates and project manage-
ment techniques can only be as
good as the data that goes in, and
all of this ties back to how people
are measuring themselves, what
tasks they are working on, and how
long they are taking to complete
these tasks. Consequently, time
tracking must be task based and it
must be detailed, thorough, and
immediate. By immediate, I mean
“in real time.” Time and task data
entered at the end of the work
week is essentially meaningless and
will not provide the same level of
insight as real time task data.

Finally, we have learned that
we will make mistakes. We will
occasionally estimate a project
badly or badly scope a project,
especially when dealing with new
technologies or unique projects.
We treat these experiences and
these lessons learned as “valuable


corporate assets” that must be stored
in our corporate memory and lever- Time tracking must be task based and it must be
aged throughout the enterprise. This
detailed, thorough, and immediate. Time and task
is clearly where we have done our best
work over the years. Wherever possible,
data entered at the end of the work week is essen-
we have put what we have learned tially meaningless.
about estimating, tracking, reporting,
planning, and management into we completed the development of an to. Darwin famously said that it is
real time software systems “Automated Project Office,” which is not the strongest of the species who
that institutionalize our essentially a software system that brings survive, but the ones most responsive
collective learning aggregate organizational knowledge and to change. I would counter that it is
and that can be review processes to bear on every one not necessarily the ones most respon-
leveraged through- of our activities and projects in a real sive to change, but the ones most able
out the enterprise. time, internet based manner. This ef- to learn and to keep learning. Certainly
We use these fort has been a five year, multi-million learning is a form of change, but in our
systems continu- dollar project from conception through industry, it is the most critical and it
ally to manage our development and is now implemented will remain so as long as the technolo-
projects and our within our business. gies and projects we face in the 21st
work and we insist century continue to increase in scope
that our aggregate In short, I would say that we have
and complexity and as long as the pro-
organizational knowl- developed a strategy for managing the
cess of globalization continually forces
edge must be totally risk of IT project failure that is rooted
us to find new and innovative ways to
available to all proj- in the automation and institution-
do more with less.
ects and all individu- alization of organizational learning.
als. Most recently, This is really what it all comes down

CAI is the creator of Automated Insight®, Tracer ®, and the IT Metrics and Productiv-
ity Institute.

Automated Insight provides a convenient, proactive, and quantitative approach for
enabling project governance and managing risks throughout project lifecycles.

Tracer is a process configuration management tool for IT organizations. Tracer defines
and enforces processes that can vary based on the type of service event; it logs and tracks
specific events, allows detailed tasks to be defined, and provides detailed time tracking.
Additional capabilities include automated estimating, scope change management, and
SLA management.

The IT Metrics and Productivity Institute is an international consortium of industry
experts, fully funded and supported by CAI, and dedicated to the creation and dis-
semination of best practice standards in the IT and software industry. The Institute’s
research focus areas include software development methodologies, software maintenance
methodologies, software project management, software risk management, software
estimation, and the science and practical application of software measurement.


Fix it Now, or Fix it Later
Continued from Page 2

shape them from there or cancel them. Fi-
CAI: Could you give us a list of the nally, there is the risk factor of communi-
most common project risk factors? cation. I see failures of communication all dangerous to be frank and say, for exam-
TIM LISTER: The first one is technical
the time, particularly with the growth of ple, “I think we are very unlikely to finish
risk. Most commonly this involves using a multi-site projects over the last 10 years. this new project in 10 months.” People
new product or tool for the first time. You Not only multi-site but multi-nation. I’ve will say, “You haven’t even tried, come on,
know you’re not an expert at it and you’re got a project right now that’s in Massachu- give it a whirl; you’re just trying to get out
trying to figure out whether the tool does setts, Ireland, and India – all at once! You of work; you’re whining.” There’s a very
what it says it does or whether we’ll have want to have one architecture, one design, strong, “Rah, rah, we can do it” attitude,
to find something else because we don’t one product and you discover that there’s especially in top management. If you can’t
know how to use it. We also have to esti- a huge risk that these teams won’t stay say what you believe without incrimina-
mate the cost of the learning curve. This locked together. You have a lot of extra tion, you have a big problem. I remember
issue of technical novelty is very common work to keep them coordinated. talking to one organization about risks
in our business. I like to joke with my The problem is always in the interfaces. and having them tell me, “You know if
clients about the fact that once you get Each team thinks they are doing fine but you bring up a problem here, you own it.”
really good at something, you never use it they may be out of whack with the others. This happens on major performance is-
again. We finally master a tool and boom Consequently, you have to do a lot of sues where the boss typically says, “You’re
– the world changes and there are new work to prevent large scale problems at absolutely right. I want you to handle
toolsets, new ideas, and new messages that the end. Then each team thinks it has its that.” When that happens, no one is going
confront us. piece done and we discover that they just to open his mouth. Instead he will think,
do not hook together. I guess I’m getting “I’ll act shocked and surprised when the
The second big risk category is a set of problems hit because I’m not going to be
organizational risks. Schedule risk is one old but I feel it’s nice occasionally to find
a project where everyone’s in the same the person responsible for a performance
of the most common and serious of these. miracle with an underpowered system.”
With almost all projects, a deadline is building. Then you can talk to each other
every day and brainstorm when problems So I think it’s largely cultural. I am not
set too early. From a risk point of view, a sociologist, but I think Americans
you need to keep a sense of humor about arise. That this is so rare now adds enor-
mous complexity and increased chances have the hardest problem in the software
this. Typically, an organization decides industry with risk management. I think
they have to release a product by, say, for communication risk.
it is used more often and more effectively
the second quarter of 2007 even though in Europe. Years ago I was in Finland and
they have very little understanding of the
CAI: Must organizations have stan- they were so good that I had nothing to
process. This creates a whole family of dard processes and tracking in place say to them. They are much more frank
risks on expectations. Then the parameters to be successful with risk manage- about problems. It’s the same in The
are set: for example, we think 10 people ment?
Netherlands at Philips: the way they talk
should be able to do this in the next 10 about their problems and make their deci-
TIM LISTER: I think I’m going to surprise
months. From a risk management point sions is very straight-forward, dispassion-
you. Practical tracking and planning is, of
of view, the schedule and budget may be ate, realistic. I wish we could bring that to
course, valuable. But the big issue is really
based on mere wishful thinking. the early stage of our projects as well. On
cultural rather than quantitative or metric.
A good risk manager discovers this as the There’s not just Brownian motion going the other hand, what makes America great
definition of the project’s work is revealed. on out there. The fundamental issue is is the way we do things because we don’t
He then calls for real estimates rather than how well the people in your organization know we can’t do them.
guesswork. I think we get horrible prob- deal with straight talk. Too many orga-
lems in our business from childishly set nizations just have a hard time learning
deadlines with no credentials. We need to about what might go wrong before it does
do reasonable estimations and then either go wrong. In too many companies, it’s


Closing Thoughts
Where we go from here
As Lister notes, risk management is about The art of good risk management involves Computer Aid, Inc. (CAI) is a key player
understanding when to make decisions. naming or “nominating” a risk, assessing in risk management and process improve-
Risk analysis usually deals with nebulous its probability, and defining/quantifying ment. We provide tools and services that
concepts such as probability of occur- impact – and only then deciding what (if help technical managers gain visibility into
rence and the impact of failure. Failure anything) to do about it. And it is infi- their projects and provide clear insight
to deliver the software “on time” creates nitely better to name and choose to finesse into potential risk.
a business risk, but so does delivering the a risk than to avoid it by ignoring it. As
Contact CAI at (800) 691-5208,
software with defects. Given the statistical Charette says, “Bad decisions by project
contact@compaid.com, or
improbability of creating error-free soft- managers are probably the single greatest
visit us online at
ware, engineers have to assess the cost and case of software failures today.”
www.compaid.com.
effort required to identify errors compared
In other words, no amount of testing,
to the cost and impact that may result
sign-offs, and traceability matrices can
from undetected errors, delays, or missing
mitigate the risk of poor judgment. One
functionality. The resulting cost-benefit
of the most effective ways to improve a
analysis must be used to accept the risks
software environment is by establishing
or expend additional effort to mitigate the
risk management within the development
risks.
and support process – and modifying it,
when necessary, based on the professional
judgment of involved parties.


Computer Aid, Inc.
Corporate Headquarters
1390 Ridgeview Drive
Allentown, PA 18104 U.S.A.

(610) 530-5000

www.compaid.com

MKT00106-COC00003 20090327 P

Conversations oneffectiveit management

More Related Content

What's hot (20)

Viewers also liked (6)

Similar to Conversations oneffectiveit management (20)

More from Computer Aid, Inc (20)

Conversations oneffectiveit management