Why Projects Fail? Karl Reed’s views

Karl Reed

isufi 2008 Lecce wpf rev 2. p 1

Why Projects Fail? Karl Reed’s views..Why Projects Fail? Karl Reed’s views..Omitting technically impossible projects..

Q1 What makes a project technically impossible?

Karl Reed


Project Attributes..Project Attributes..Lots of definitions… this is from UTS*Lots of definitions… this is from UTS*

*UTS (2008). UTS: PROJECT MANAGEMENT Types of Projects. University of Technology Sydney. http://www.projects.uts.edu.au/stepbystep/project_type.html

Karl Reed


Soft Projects…Soft Projects…

Business Processes and IT Projects can be heavily

in these areas

Great places to use ontologies

*UTS (2008). UTS: PROJECT MANAGEMENT Types of Projects. University of Technology Sydney. http://www.projects.uts.edu.au/

Karl Reed


Well defined projects vs fuzzy projectsWell defined projects vs fuzzy projects

Note the differences

? These steps not needed?

Iteration needed !

*UTS (2008). UTS: PROJECT MANAGEMENT Types of Projects. University of Technology Sydney. http://www.projects.uts.edu.au/

Karl Reed


1. Failure to meet a defined objective Complete project on budget/on time

2. Completed activity does not work on cut-over/installation/adoption

A new business process/plant/etc is completed but does not have acceptable outcomes

As above, but cannot be used

3. Completed activity “works” but has negative consequences that become apparent over time

4. BUT THE PILOTS/LIVE TRIALS WORKED.. in real world situations, the new activity has unacceptable outcomes

Buried failures are discovered.. Errors discovered in work-products that need to be referred to months after their creation

Activity does not scale… Destroys some existing, working activity Output from the activity is defective and unacceptable

Some Definitions of Failure… from our intro.Some Definitions of Failure… from our intro.

Karl Reed


Project Attribute SE Failure (one or more..)

Build To Spec It was not

Passes Acceptance Tests

It didn’t, but was deployed

Built to Budget Large overrun

On Time Very Late

Deployed Successfully Not very

Post Adoption Drama Irrelevant

Post Adoption Trauma case*

Yes

Yes, very well

No overrun

Yes, right on time

Yes, early results with early adopters great!

YES, soon after

general deployment

*Some would argue that this is a requirements failure, but it may not be seen as such.-[Larsen 1999] describes this happening for an ERP installation

**Reed 2007

Two Types of failures-”Software Engineering” and “Process-Fit” a simplified view..**

Karl Reed


Some Definitions of Failure… from our intro.set 1.Some Definitions of Failure… from our intro.set 1.Delayed Discovery problems time bombs

Examples Consequences

Buried failures are discovered..Errors discovered in work-products that need to be referred to months after their creation

Error discovered in stored customer charges, shown as correct on screen

Company bills customers for less/more than actual amounts

Activity does not scale… Initial early adoption group was 20 people and low transaction rate. Failed when 500 users and high transaction rates

Frustrated staff, lost business, unhappy suppliers, customers go elsewhere

Destroys some existing, working activity

New customer update deletes tax file number (but ok on update screen)

Unable to process sales tax payments

Output from the activity is defective and unacceptable

Emergency dispatcher does not show mismatch between same address in two different towns of the same name

Someone dies waiting for ambulance

Karl Reed


Some Definitions of Failure… from our intro.set 2.Some Definitions of Failure… from our intro.set 2.

Post Adoption Problem Examples Why not detected as problem

Normal operators find precise input difficult and error recovery really hard

A screen with a lot of product descriptions all which must be precise, recovery is to re-input complete screen

Acceptance tests used very simple cases, low transaction rate and staff committed to the projects success

Post adoption processing rates unacceptable

Airline booking system based upon normal web interfaces causes loss of income-takes too long to one booking when customer changes mind

Hard to know, may be demonstrations to investors NOT users, trials using company execs NOT booking agents

Accounting system cannot deal with either small purchases or urgent purchases

Extra work to record small, low frequency transactionslaboratory equipment which fails every 5 years cannot be repaired

System designed for v. large company, the people who knew about the equipment and the repairer left the laboratory!

Karl Reed


Why IT Projects Fail (assuming it was “possible”)……., Why IT Projects Fail (assuming it was “possible”)……., Failure Type ReasonsProject development failure--Budget/resource failure-cost/schedule over-run

1. Poor project definition

2. Unrealistic expectations

3. Staff lacking in experience

4. Poor tools

5. Resource estimates WRONG

Completed project lacks quality (buggy,unreliable,slow)

-Poor design/programming

-Poor testing

-Poor infrastructure (in a COTS) world

-Poor User Interfaces

Karl Reed


Why IT Projects Fail (assuming it was “possible”)……., Why IT Projects Fail (assuming it was “possible”)……., Failure Type Reasons CommentsProject development failure--Budget/resource failure-cost/schedule over-run

1. Poor project definition

2. Unrealistic expectations

3. Staff lacking in experience

4. Poor tools

5. Resource estimates WRONG

-Developing requirements is hard in many cases..

-User and developer may be too optimistic

-The analysts and the project team may be new to the application domain, tools, etc.

-Languages/run-time systems may not be appropriate

-Estimating is extremely hard!

Completed project lacks quality (buggy,unreliable,slow)

-Poor design/programming

-Poor testing

-Poor infrastructure (in a COTS) world

-Poor User Interfaces

-See 3,4. In Reasons



Karl Reed


Why IT Projects Fail (assuming it was “possible”)……., Why IT Projects Fail (assuming it was “possible”)……., Failure Type Reasons Sources of

Knowledge Available

-Essential Functions omitted or unusable

-Existing work processes become more complex and take longer

-”Work arounds” needed to achieve previously existing essential functions

-Function not noticed as existing or needed during specification

-Failure to detect actual work practices..”But I asked the user..”

-As above

-Users

-Managers

-Customers

-The current system (i.e. the procedure manuals, screens, artifacts, code etc)

-Existing workflows and process steps

-Helpdesk reports, CRM logs

-User manual

-Specifications

-Informal notes

The Domain Expert

Karl Reed


The Nature of Software Projects… The Nature of Software Projects… Two very extreme views..Two very extreme views..

A. Any Software/IT “need” can be formulated precisely and having done A. Any Software/IT “need” can be formulated precisely and having done this, if it is “technically feasible”, can be successfully implemented.this, if it is “technically feasible”, can be successfully implemented.

B. All software/IT “needs” involve outcomes with human actors whose B. All software/IT “needs” involve outcomes with human actors whose understanding (and hence “need”) is changed by their interaction with understanding (and hence “need”) is changed by their interaction with the system produced. Hence NO such need can be formulated precisely!the system produced. Hence NO such need can be formulated precisely!

B.1 (In any case, software development is a personal, creative activity B.1 (In any case, software development is a personal, creative activity which depends upon personal skill and hence cannot be formally planned which depends upon personal skill and hence cannot be formally planned .. The so-called agile community, by implication..).. The so-called agile community, by implication..)

Karl Reed


Implications of Extreme ViewsImplications of Extreme ViewsA. Any Software/IT “need” can be formulated precisely

All software/IT “needs” involve outcomes with human actors.Hence NO such need can be formulated precisely!

(Software development is a personal, creative activity … cannot be formally planned)

Planning

Estimating Effort

Estimating Delivery Time

Resultant Quality

Looking at this slide.. What are the various implications and outcomes?

Lets dicuss..

Karl Reed


Lehmman, M.M. Software Evolution - Cause or Effect,Stevens Memorial Lecture, 2003http://www.cs.mdx.ac.uk/staffpages/mml/listing.html

A Formulation of an Extreme View E-Type systems

Karl Reed


By Karl Reed, FACS, MSc, ARMIT

(Based on a Presentation to the Politechnico de Milano,1991 and work by Shivraj Sabale*)

* Sabale, S. (2006). Knowledge Loading as a Factor in Software Project Planning and Estimation - A Consequence of KABASPP, MSCW Thesis, La Trobe University Department of Computer

Science and Computer Engineering

A Knowledge Acquisition Based Approach to Software Project Planning

Or

A Five Layer Model of Project Knowledge

A Way of Controlling the Predictability issues

Karl Reed


3. Knowledge Acquisition As An Issue p163. Knowledge Acquisition As An Issue p16

This basis of our approach is that skill and knowledge must be acquired since …

“No element of a system can be completed until …

a) required characteristics are known

b) the skills necessary to complete it are acquired

Given the above, the planning of a “project” or can be determined by the initial “state” of these “items”.

Karl Reed


4. The KABA Domains …...4. The KABA Domains …... We came up with a Five Layer Knowledge We came up with a Five Layer Knowledge Model for Software Projects…..Model for Software Projects…..

Domain IT Definition

APPLICATION What exactly is the problem?

What physical/organization/social/laws/ models govern it?

APPLICATION-SOLUTION

Machine executable algorithms related to above;

Particular (m.e.) algorithms/system structures/architecture…..

DEVELOPMENT ENVIROMENT

Languages, tools, utilities, methodologies, (CASE, CM, Loaders, libraries, test systems, S.A., methodologies, etc.)

RUNTIME O.S, D.B.M.S., H/W, external interfaces, resource constraints (cpu time, I/o, mem), response time.

PROJECT MANAGEMENT

Estimating, project organisation, resource acquisition, customer liaison, quality control.

Karl Reed


4. The KABA Domains …...4. The KABA Domains …... We came up with a Five Layer Knowledge We came up with a Five Layer Knowledge Model for Software Projects…..Model for Software Projects…..

Domain IT Definition Business Process Definition (for you?)



Business Goals and End to End tasks and Processes and their nature




The actual individual activities and rules



???


Organisational infrastructure needed for the process to execute

PROJECT MANAGEMENT


The business process planning process

Karl Reed


The basis of the arguments is as follows …..

A) No (software) system can be implemented (built) in a purely mechanical (straight-forward, deterministic) fashion UNTIL appropriate levels of knowledge exist in each domain OTHERWISE significant effort is expended acquiring this “knowledge” … causing massive estimating errors.

B) The process of knowledge acquisition in some cases may proceed in parallel with other cases (Domains or parts of Domains).

ALLOWS FOR the possibility of independent and overlapping project activity.

AND

C) THERE MAY EXIST sub-problems, spanning domains, but requiring quite vast amounts of KA in one or more Domains

This leads to the doctrines of “Separable Design” and “Re-trofitting Architecture”.

4. The KABA Domains … p18...4. The KABA Domains … p18...

Karl Reed


The concepts are fairly clear, but can they be used to explain the failures of other models (or their properties) … AND

Can they be used to make decisions about project planning?

I believe the answers in both cases are “YES”.

In general business planning, applying these ideas allows knowledge gaps to be identified, planning problems to be dealt with by asking the question..

What is the state of our knowledge about X?

4. The KABA Domains …... Re word for context. p19.4. The KABA Domains …... Re word for context. p19.

Karl Reed


Using a classic Software Project Model..Using a classic Software Project Model..

5.1 Waterfall (Royce)

Feasibility

System Design

Module Design

Module Coding

Module Testing

System Integration

System Testing

DesignDocs

These are all essentially KABA issues!Problems

1. Everything can actually be done when its phase occurs.

3. Nothing in phase j can invalidate decisions in phase j-i.

2. Nothing can be done before its phase is due.

4. Nothing (assumed) in phase i will prove impossible in phase i + j.

Code

Karl Reed


6. Earlier and other work …6. Earlier and other work …

It would be nice if this was all totally new - but not so!

Seeds exist in much prior work … e.g.

6.1 DOMAIN ENGINEERINGWidely reported, but focuses only on the Application Domain.N.B. a paper by Simos actually drew a diagram with the domains but proceeded to ignore them!!

6.2 BROOK’s Mythical Manmonthrecognises implications of KABA in terms of skill acquisition in Environment Domains and Solution Domains while Specification progresses. (1991?)

6.3 STUDIES of Software Development (Silverman, Siddiqi and MCC) suggest KA dominates actual practice.

Karl Reed


7. KABA Domains and Components7. KABA Domains and Components

Basic Domains as evident in Software Development

• APPLICATIONS DOMAIN

- Acceleration characteristics of a train

- Organisational structure of business

- Rules for issuing air-line tickets or degrees

- Procedures for organising work flow

- Procedures for design of pressure vessel etc.

SOURCES OF THIS KNOWLEDGE

- Commercial Systems Analysis

- Engineering Design Analysis

- “Knowledge” Engineering

and a well understood process

Karl Reed


7. KABA Domains and Components for IT Projects7. KABA Domains and Components for IT Projects

APPLICATION SOLUTION DOMAIN

- Approx. method for calculating acceleration of train

- Procedure for allocating positions on a vehicle given multiple access

- Path optimisation procedure for routing of information

- Algorithm for rotating graphic images

- Procedure for recovering disc-space

- Sorting procedures

- Algorithms for searching lists

- Business process for issuing airline tickets

Currently Computer Science, graphics, A.I., S.E., etc.

Karl Reed


7. KABA Domains and Components Software and IT Projects7. KABA Domains and Components Software and IT Projects

• DEVELOPMENT ENVIRONMENT DOMAIN(What competencies are needed to actually build the system)

-Programming languages-Methodologies {JSD, SD, Modular Design}-Tools - CASE, other development aids, Test tools-O.S and control language - Shell, MCD, DOS, JCL, etc.-Utilities - Loaders, File manipulation, editors, configuration managers.Files memory, DBMS

Currently handled byComputer Science, Software Engineering.

(How does this change for Business Processes?)

Karl Reed


4. RUN-TIME DOMAIN (The infrastructure that makes the process possible..)

- O.S. interfaces

- DBMS calls

- Instruction set, external interfaces

- Resource constraints (i.e. profile of available cpu-time, i/o, mem for the system).

- Response time

- Device peculiarities

-Hardware Reliability vs Design goal

Currently computer science and hardware plus S.E.

(How is this different for Business processes?)


Karl Reed


5. PROJECT MANAGEMENT DOMAIN- Estimating- Project Planning- Project Organisation- Resource acquisition- Project Tracking- Customer liaison- Quality Assurance- System Delivery- Maintenance Planning- Risk assessment- ROI assessment

Currently Commercial EDP and Software Engineering and KABA

(How is this different for a Business Process project?)


Karl Reed


8. Impact of KABA Project Plan Construction8. Impact of KABA Project Plan Construction

A) Set the plan to correct for deficiencies in the knowledge-skill state.

(This can be used to predict difficulties)

B) Use the above process to identify independent tasks hence maximising parallel activity. (I.E. to improve and perhaps verify the PERT/CPM plans..)

Karl Reed


Study Ecercise.. Re work the KABASPP layers for Business Process Changes..Study Ecercise.. Re work the KABASPP layers for Business Process Changes..

Domain IT Definition Business Process Definition (for you?)



Business Goals and End to End tasks and Processes and their nature




The actual individual activities and rules



???


Organisational infrastructure needed for the process to execute

PROJECT MANAGEMENT


The business process planning process

Karl Reed


PROJECT ESTIMATING AND WHY PROJECTS FAIL..PROJECT ESTIMATING AND WHY PROJECTS FAIL..

One implication of the previous work is that..

A/ IT projects may be commenced with imperfect knowledge and hence imperfect plans.

B/ As a result, there will heaps of iterative, uncontrolled re-work as this knowledge is acquired during the project progresses (See Sabale, S 2006, Hesse 1996, Benedictsson et al 2003)

C/ As a result, estimates have low reliability..

We’ll look at that soon..

Karl

Karl Reed


Discussion…Discussion…

Karl Reed


Why Projects Fail Additional Topics..Why Projects Fail Additional Topics..

Topic Notes

Estimating Difficulty-If one cannot define the project, estimating will be unreliable

-Standard estimating techniques have massive variances..

Governance, Stakeholders and Risk Assessment

-Is the project run under a proper governance framework?-Have the impact of the stakeholders been assessed and dealt with?

Documents

Why Projects Fail? Karl Reed’s views