CT - Topic 13- IT Project Failure Lecture

8/8/2019 CT - Topic 13- IT Project Failure Lecture

http://slidepdf.com/reader/full/ct-topic-13-it-project-failure-lecture 1/45

IT Project Failure

CT050-3-3 Project Management

Prepared by: SMR First Prepared on: June 2008, Last Modified on: XXQuality checked by: MOH

Copyright 2004 Asia Pacific Institute of Information Technology




LET’S START THE TOPIC

IT Project Failures




WHERE WE ARE?

1. Introduction to the module/In-course2. Project Management Basics/Principles3. Project Charter 4. WBS and Organisation5. Scheduling6. Estimating7. Quality Management8. Change and Risk Management9. Monitoring and Control - EVA10. Managing Communications11. Project Close-out

12. Project Methodologies13. Project Failures14. Revision




LEARNINGOUTCOMES

• At the end of this lecture youshould be able to:

– appreciate why IT Project fails – Identify steps to avoid failures






MAIN TEACHING POINTS

• Main Lecture• Defining Project Failure• How to spot failures (10 ways)

• Backup Slides• The Human Element• Technical Limitations• Political Issues• Funding• Failure to apply SDLC Methodologies


http://slidepdf.com/reader/full/ct-topic-13-it-project-failure-lecture 7/45CT050-3-3 Project Management

WHY PROJECT FAIL

Failure to defineobjectives17%

Project Management Problems32%

Technicalissues14%

Inexperiencein scope andcomplexity

17%

Lack of communication

20%



• Project failure can rarely be described in absoluteterms

• Some projects fail so badly that companies go outof business

• Other projects fail, but their impact is hardly felt bythe organization or the people affected

• The following table identifies some events that aregenerally indicative of project failure. The second

column in the table identifies the severity of theproject event:

DEFINING PROJECT FAILURES



Events indicative of project failure

Project event Severity of failure

Cancellation HighLate delivery Medium to HighOver budget Medium to HighLow quality Medium to HighHigh employee turnover Low to Medium




Why do IS projects fail?IS projects have the distinction of being unlike projects inother industries in key areas:

u IS industry is faced with a chronic shortage of staff u IS industry is faced with an ever-evolving and changing

set of development toolsu IS industry is faced with a relatively high rate of employee turnover

Some standard problems result from the high complexityon most IS projects:

u General inability to recognize that a solution is correct.E.g. Sw metricsBecause of the large number of components and

combinations in any application it is a real challenge toidentify what a successful solution should look like. Mostof software metrics defined on a relative basis .




Five broad categories that contribute toproject failure:

HumanIssues

Technological

limitations

PoliticalGames

Funding Methods

Project Failure

Leadto

Leadto

Leadto

Leadto

Leadto




The Human Element• Inability of users to agree on business requirements• Inability of users to communicate business requirements• Inability of users to understand the implications of business

requirements• Inability to accommodate changes to business requirements• Insufficient technical skills• Failure to effectively manage one or more phases of the

development effort

• Insufficient testing• Insufficient resources• Unrealistic expectations• Working with poor performers• Inability to deal with contractors and vendors




Technical Limitations

• Technical limitations can become hugeproblems in the following situations: – Overambitious development – Insufficient benchmarking Inability of users to agree on

business requirements• Migration from development to production

environment (sometimes requires changes tosoftware hardware/software




Political Issues

•Organizational politics• Team politics

• Power and influence• Protection against organizational politics• Individual politics






• Each of the system development methodologies offersimplementation success

• However, there have been cases where project that havefollowed certain methodologies have failed.

• The main reason is that methodologies are at times followedwithout being understood.

• Example, the objective of prototyping in to promote a closer

interaction with the user, not just to develop a dumbprototype system• Besides, there are many activities (in the boxes) that require

experience, analysis and ability

Methodology




SPOTTING FAILING PROJECTS

1. Your team only gives you good news at everystatus meeting

2. The implementation date is only a few weeksaway but, you, the manager, have never seen a

hands-on demonstration of the application3. Most of the memos your team sends to youcomplain about the lack of skills in the other team members

4. Team members continue to play a fine act of protecting themselves at every opportunity

5. Team members are resigning on a regular basis



6. Team members are either frustrated andconstantly on edge, or conversely feel nopressure to get the job done

7. The project has already missed severaldeadlines and is well over budget

8. There have been no detailed walk-throughs of the application design and code by independentreviewers

9. When you think of your project, and there is nothought of team, but only separate individuals

10. The user community is not aware of the project

SPOTTING FAILING PROJECTS



What is the Project Management Maturity Matrix?

The matrix describes four levels of maturity in projectmanagement:

•Level 1: Projects are often delivered through the personalheroics and effort of the project manager and his/her team.They tend to be delivered in spite of the organisation rather than because of it.•Level 2: Anybody can deliver here not just heroes, becausethere is an agreed methodology to be followed that helps repeatearlier successes from similar projects. Courses and trainingcan help at this level.•Level 3: This is not only about delivering projects but alsorealising benefits. This involves knowing what benefits areexpected and when the project has delivered them.•Level 4: Is concerned with whether we are doing the rightprojects and how via those projects we can deliver the business

strategy and add value.



For organisations to understand the level they are

operating at, it is useful to ask these questions:

•Level 1: Project Management Success (cost, time and quality)Did our project produce the desired output?

•Level 2: Repeatable Project Management Success (predictableoutcomes)

Do our projects consistently produce the desired outputs?

•Level 3: Project Success (benefits realised)

Do the project outputs produce the desired outcomes?

•Level 4: Corporate Success (strategies implemented, value added)Do the outcomes produce or have the intended impact on the

business strategy?



Moving from one level to another requiresorganisations to develop processes in anumber of areas:

• A methodology is required to move from level

1 to 2

• Benefits management is required to movefrom level 2 to 3

• Portfolio management is required to movefrom level 3 to 4



REFERENCES

How to Manage a Successful Software Project:Methodologies, Techniques, Toolsby S. Purba, D. Sawh, B. ShahJohn Wiley & Sons, Inc., 1995

Software Project Dynamics: An IntegratedApproach

by T. Abdel Hamid, S. E. MadnicPrentice Hall Inc., 1991



Q & A




WHATS’SWHATS’S NEXT NEXT ??

RevisionRevision

?

??




The following slides assist inproviding more information.

Backup Slides




Defining Project Failure

- Phases in a project receive products from other phases, andcreate ones of their own

1. As the number of phases increase, so too does the complexity

2. Increasing complexity increases the potential points of failure

dramatically3. This creates an added challenge in maintaining the integrity of an IS

project

Phase A Phase B Phase C

ProductA

ProductA+B

Product

A+B+C






The Human Element

Inability of users to agree on business requirementsExample: Users agree that a merchandizing system is required, butcannot agree on the functionality it should support (e.g. multiple

languages, multiple currency, multiply product types, etc.)Suggested solution:u Plan regular meeting session using an impartial facilitator whodraws users and IS staff into constructive discussionsu Document all communications and interpretations so that it is clear

when decisions are being made or avoidedu Use prototyping technique, where an initial design is buildu Prototype is iteratively modifies until stakeholders agree on decisionsu Allows users to see the impact of decision early in the process




The Human Element – cont’d

• Inability of users to communicate businessrequirementsAnother problem that is encountered on IS projects is a general

lack of communication between users, managers, and ISdevelopment teamsSuggested solutions:

u Try to maintain communication by:1) Holding regular status meeting sessions

2) Keeping good documentation3) Keeping centrally located logs of issues4) Recommendations5) Teams members should be mandated to share

information equally




• Inability of users to understand the implications of business requirementsUsers agree on a solution without fully understanding its

ramifications (similar to 1)Example: Everyone may agree that a Canadian Purchase Order System is required, but it may not be understood that it is neededin both French and EnglishSuggested solutions:

u Holding facilitated meeting sessions between the users and theIS staff

u The users should be ‘toured’ through the various levels of thesystem form strategic planning to system design

u Sharing of details of information should be encouraged





• Inability to accommodate changes to businessrequirementsBusiness requirements are subject to change for a variety or reasons, even after they have been agreed by stakeholders and

formally signed off Suggested solutions:

u As changes are discovered information is put in a central ASCII fileu Each change should be numbered, assigned a priority, and describedu Development team browses and updates the file on a routing basis

u Problems are selected based on the priority assigned: urgentproblems must be selected firstu The central ASCII file allows duplicate and contradictory requests tobe quickly discoveredu The file used for reporting purposes to the steering committee





• Insufficient technical skills Insufficient technical skills can result in variety of situations:

u E.g. Hiring resources with mainframe backgrounds for client/server projects, or vice versa

u E.g. Hiring inexperienced peopleu

High turnover:1) Team member leaves,2) Team member gets promoted, or 3) Team member transferred to some other area.

Suggested solutionsu Provide: in-house courses, self training, university/college

educationu Provide the above to people who have demonstrated ability andcommitmentu Examine track records before selection is madeu Ensure development standards are in place, so that team

members have something to emulate





• Failure to effectively manage one or more phases of the development effort Suggested solution:

u The project manager should :1) Develop a comprehensive plan showing clear deliverables

2) Develop criteria for measuring success at each step3) Track against these carefully4) Corrective aations should be taken as soon as a problem is

encountered5) By developing an intrinsic understanding of a project’s issues, a

manager is able to take iterative action that reacts to problemswhen they are identified





• Insufficient testing

Applications that do not go through a cycle of thoroughtesting will probably fail in production or during

acceptance testingSuggested solution:

u Invest time and money for iterative testing phases

u Impress the need for thorough testing on all team members

and associated teams u Consider the implementation of Total Quality Management(TQM) programs







• Unrealistic expectationsThis type of failure occurs when managers are not concerned withfacts, but insist that some dream be fulfilled at some particular point in time of their choosing-blatant impossible situationExamples:

u Expecting someone with a COBOL background to learn C andUNIX overnight, or vice versa

u Some managers think of work day as consisting of 20 hours and awork week as having 7 days

Suggested solutions:u Managers must be realistic in their expectations





• Working with poor performers Some people may have noble intentions, but sadly, lack theexperience or ability to perform well on some projects

Suggested solutions:u Look for opportunities to train and mentor such employeesu Judge people on past performance, but understand that they canimprove or devolve over timeu Give people opportunities in situations that you are able to

control, I.e.u if your trust is not met, this error in judgement should not derail aproject





• Inability to deal with contractors and vendorsContractors and vendors are permanent fixtures on projectsThey augment the organizational staff by providing specializedskills or additional bodies

In dealing with contractors and vendors, managers are faced withthe challenge of ensuring that their organization is properly dealtwith by the vendor and/or contractor Suggested solution:

u Develop a cooperative effort with vendors and contractors u Make it clear that you want regular, honest communication u Develop a service agreement u Understand that contractors/vendors have their business to run





Technical Limitations

• Example:u A software for the greenhouse industry, developed in the 80’su Presentation of prototype well-received… prototype worked fineu In the 80’s PCs horsepower came from INTEL’s 8088 chip

u In the 80’s 5 1/2 inch floppy disks, 360 kb capacity were usedu After several iterations to the prototype the product improved itsfunctionality wellu However, the new added functionality made the product slower u The application quickly exceeded the 360 kb of one floppy, and

grew to fill several diskettesu The user had to swap disks while navigating through certain

featuresu The application was limited by available technology






Migration from development to production environment(sometimes requires changes to software hardware/software

u Perform System Testing (Humphrey)

1) Stress Testing,2) Volume Testing,3) Compatibility Testing,4) Security Testing,5) Performance Testing,6) Installability Testing,

7) Reliability/Availability Testing,8) Recovery Testing, etc.

Inability to identify functionality that cannot be automated withcurrent technology

Technical Limitations – cont’d



P li i l I ’d




Situations of general lack of commitment are extremely frustratingfor every one concernedUsually such systems are never implemented and the team is

reassigned• Team politics

Politics can also be played within teams, with the objective of gaining the following rewards:Tangible rewards:

u Members of a team compete for the manager’s attention to get abetter position, pay rise, better computer, better place etc.u Managers who support this are actually supporting political

games

Political Issues – cont’d

P li i l I ’d




Power and influenceu Human beings love to tell others what to do. This is seen

everywhere in society.u Example: Some managers promote spying within a team. This isdone by having frequent informal one-to-one meetings with team

members to gossip about what other people are doing. u Managers who participate in this sort of management style should not

be surprised at the negative results and the lack of team building

Protection against organizational politicsu Many potentially good project teams are subverted by organizational

politicsu When it is known this is happening, individuals begin to protect their jobs instead of trying to deliver the product

u E.g. self-protecting memos, constant questions about responsibility...

Political Issues – cont’d



Date post:	09-Apr-2018
Category:	Documents
Upload:	alam73
View:	223 times
Download:	0 times

CT - Topic 13- IT Project Failure Lecture

Documents