Why IT Projects
Fail
IN PRACTICE
REFERENCES: LIENTZ & LARSSEN
Why IT Projects Fail
Issues detected too late
Management & staff may not be aware of issues -
Issues not managed well – different people,
different ways
Inconsistency leads to problems
Why IT Projects Fail
Experience in resolving issues, doing work,
completing work not used to improve
management of issues in future
Same mistakes
Problems with Systems Development Life Cycle
(SDLC)
Requirements, involvement of senior users (can be
most resistant to change
Why IT Projects Fail
Requirements could have generated new ideas –
resulting in change of scope
Disconnect between training & implementation of
new system & current business process
Lack of understanding & communication
Senior users – Queen & King Bees – seen as great
strength or barriers to change?
Indications of project failure
When IT system does not meet requirements –
invent
Scrapping – project scrapped while in progress
Over-run – project completed, but time or cost
target exceeded
Neglect – project completed but doesn’t meet
user or business needs
Why IT Projects Fail
Requirements Creep:
Gradual changes to specification during project – for
example,
Output information requirements
How these are visualised
Changes to system navigation
Why IT Projects Fail
External issues and risk
Vendors, consultants, and outsourcing
Headquarters
International & subsidiaries
Technology
Business partners
Why IT Projects Fail
Types of issues:
Internal issues and risk
Teams
The work
Business units
Management
Projects
Resistance to change
Why IT Projects Fail
Issues and risk in specific IT activities
Analysis
Software packages
Development
Implementation
Operations and support
Why IT Projects Fail
Problems
Issues on one type different to another
Some controlled within IT or project team
Other issues not as controllable
Issues involve users, vendors, outsiders, or
management
There is a big difference!
Why IT Projects Fail
Problems in issues management:
Want to solve it right away – not always best
way
Decisions made about actions – lack of follow-
through with actions
Assumed issue is unique
No analysis of issues across multiple projects
After decisions and actions management
assume issue taken care of – political issues?
Cannot solve issues using one approach
Areas of Risk
Design and definition failures
Required outputs not described with sufficient clarity
(Scope in Terms of Reference – the problem of boundaries)
Over-ambition – too much of a good thing in project (also a
boundary problem)
Project seen as an IT project (the culture gap problem)
End-goal too distant with too few review points (the
communication gap problem)
Areas of Risk
Decision-making failures
Prime responsibility rests with committees
(delay)
Consensus must be achieved on all issues
(delay)
No single individual in authority (ownership)
Areas of Risk
Project discipline failures
Documentation replaces management – “the fetish of
technique”
Milestones too far apart (slippage)
Weak risk management and contingency planning
Deadlines not adjusted when requirements change
Project beyond capability/experience of Project Manager
Areas of Risk
Supplier management failures
Failure to take account of supplier’s
commercial imperatives (fixed price contracts)
Poor procedures for evaluating and selecting
suppliers
Imprecise contracts (contract management)
Management information not transparent
between supplier and client
Focus on limiting cost – ignoring managing risk
in supplier
Areas of Risk
People failure
Lack of communication between IS project
team
Users/needs of users not understood
(communication/culture gap)
Cover-up culture in IS project team
Too few senior people with authority
Likely Problems…
Initiation
Insufficient time spent on project planning
Insufficient time spent on investigation
Analysis
Insufficient time spent on requirements analysis
Likely Problems…
Design
Unless there are good channels of
communication between analysts, designers
and users, delays will be caused
Requirements will often need further
clarification
Prototyping and Rapid Applications
Development (RAD) approaches will help
overcome this problem
Likely Problems…
Development
Bugs/errors are introduced at this stage.
Early detection is important
Later detection… more expensive to correct
Implementation
There may be unexpected problems which were not
found during system testing
Likely Problems…
Maintenance
Developers generally don’t like maintenance…
Processes for reporting, reviewing, correcting
and notifying problems may not exist…
Maintenance documentation/tracking may be
deficient.
The systems development life cycle!
Importance of objectives
Specific
Measurable
Actionable
Relevant
Time-oriented
Measures of success
Meeting business case requirements
Delivering on time
Delivering within budget
Delivering a system ‘fit for purpose’
Good Management
COBIT:
ControlOBjectives for Information and related
Technology
Satisfy the business requirements
Set priorities to deliver on time, within budget and for
a system ‘fit for purpose’
Good Management: COBIT
Management sponsorship for projects
Project management capabilities
User involvement
Task breakdown, milestone definition and phase approvals
Allocation of responsibilities
Rigorous tracking of milestones and deliverables
Cost & staff budgets, balancing internal/external resources
Quality assurance plans and methods
Programme and project risk assessments
Transition from development to operations
