RISK MANAGEMENT FOR

IT PROJECTS
BENNET P. LIENTZ, LEE LARSSEN

CHAPTER 18
OPERATION AND SUPPORT
Mohsen Mojabi (125422)
ITEC 580
Introduction:
So much of the IT resources is consumed by:

o Support
o Maintenance
o Enhancements

Also:
o Management
o Supervision
o Administration

Fact: Commonly, less than half of the available IT resources
will go into actually doing the project! (35%-45%)
Why so much of the IT resources is drawn
to other areas instead of the real project?
Preference of doing support work by most
people
Unforeseen and Emergency Works
Re-developing instead of Maintenance
Close-relationships
Knowledge and Expertise not evenly distributed
Lack of Measurement
No differentiation between Maintenance and
Enhancement
Lack of a systematic management method

Preference of doing support work by most
people
Why?
o Less pressure
o More praise and applause
o Not much deadlines to meet
o Not much innovation needed
o Work finishes early

Preference of doing support work by most
people
Consequences:
o The actual project will suffer
o Achieving substantial work progress is harder
o May result in unnecessary outsourcing

Preference of doing support work by most
people
How to detect it? Talk to IT staff to realize their
personality type
o Where do they spend their time mostly?
o Which activities theyre into?
o What were the fields of their previous
achievements?
o How and when they feel rewarded, and with
which things they have trouble?

Preference of doing support work by most
people
Countermeasures:
o Focus on young people! Senior IT people highly
resist to change!
o Talk to people; make them realize where is the
need
o Hold weekly meetings

Unforeseen and Emergency Works
Emergencies are unavoidable:
Some Examples?
o Application crash
o Network slow down
o Managements urgent request for a certain report.
o Business Rule changes
o Network failure
o OS issues which cannot be quickly resolved
Unforeseen and Emergency Works
Consequences:
o They can take much longer time than expected
o They can delay the project
o Quick fixes are usually prone to errors
o They can recur
o They can affect the perception of the
management
Unforeseen and Emergency Works
Detection:
o Analyze how much work is done outside the
scope of the actual project
o How many instances of the same problem is
recurring?
Unforeseen and Emergency Works
Actions:
o Diagnose, find the root cause
o Potential solutions must considered
o Changes must be tested before going into
production
o Changes must be documented
o Track should be kept
o Create small projects to counteract

Re-developing instead of Maintenance
Why?
o Innovative/creative people tend to redesign
instead of only fixing the problem
o People want to add features and enhance the
functionalities

Re-developing instead of Maintenance
So, whats wrong with that?
o New errors are being made because of the new
code
o Others are unaware of your changes
o Failed dependencies

Re-developing instead of Maintenance
How to detect it?
o Fixing a program bug is taking longer time than
expected
o New functionalities are being introduced, without
any request
o After the fix, new problems arise
Re-developing instead of Maintenance
Prevention:
o Be aware to whom the fixing of the issue is being
assigned!
o Manage the programming staff
o Assign foreground and background tasks
o Keep programmers busy, dont let them have
enough time to make unnecessary changes!
o Raise awareness among them of the possible
consequences of rewriting the code instead of
debugging it

Close-relationships
Whats wrong with it? What are the consequences?
o People may take advantage
o Less than expected work
o Unjustified use of IT resources, which are always
limited
o Assigning less work to some people because of
relationships

Close-relationships
How can it be figured out?
o Ask of people who are in their positions for long
time, for their perception of IT services
o If theres no complaints and theyre relatively
satisfied, be skeptical!
o See who they work with, and ask the same
questions from them as well!
Close-relationships
Can this be broken?
o Dont even try to! Youd make hostility And
theyd do it underground

Instead:
o Stress to the supervisors that all requests must
be reviewed and approved.
o Review and watch closely what programmers are
doing
Knowledge and Expertise not evenly
distributed
Consequences:
o Becoming overly dependent to certain people
o Those people with high expertise get too busy,
and you cannot assign less qualified people to
help them
o At the same time, some people get much less to
do
Knowledge and Expertise not evenly
distributed
How can you find out?
o Map people to the parts of the Application or
Architecture

Knowledge and Expertise not evenly
distributed
How to prevent?
o Provide Cross-Training
o Share Work
o Assign teams instead of people to a certain part
o Raise awareness that the work must not be
delayed, should they become unavailable for a
certain time (due to sickness for example)


Lack of Measurement of Support and
Maintenance
Consequences:
o People may feel more free to spend time on their
own agenda

Lack of Measurement of Support and
Maintenance
Detection:
o Do we assess how much time people spend on
fixing a certain issue? Can you create a report on
how many hours exactly has been spent on
support and maintenance for different parts of the
project?

Lack of Measurement of Support and
Maintenance
What to do?
o Measure the time spent
o Review the works
o Differentiate between Support/Maintenance and
Enhancements
o Create estimations based on previous cases

No differentiation between Maintenance
and Enhancement
Why there must be a differentiation?
o Enhancements must be controlled; there must be
justification for them
o Maintenance work can show the state and
condition of the system
o User request are being separated

No differentiation between Maintenance
and Enhancement
What if we dont?
o You lose control
o Users make more requests
o More work is put on support side, instead of
projects

No differentiation between Maintenance
and Enhancement
Actions:
o Create evaluation criteria for each
o Create separate forms, and review methods

Lack of a systematic management method
Consequences:
o Instead of a systematic approach, and a defined
agenda, work is generated from the requests
o The support and maintenance becomes ad hoc
o IT effectiveness will decrease
Lack of a systematic management method
How to detect:
o Do users contact IT supervisors directly, instead
of goind through a defined process? (Shadow
Work)
o How are the requests evaluated, assigned, and
then the results reviewed?
Lack of a systematic management method
Actions:
o Treat everything within the project
o Get IT staff to report on any non-project works
o Gather lessons learned
o Assess any recurring issues
o Apply systems and best-practices

Conclusion:

Support, operation and maintenance
is best if managed and treated like
small projects


Any Questions?
THANK YOU!