slide1 n.
Skip this Video
Loading SlideShow in 5 Seconds..
Why Projects Fail? Karl Reed’s views.. PowerPoint Presentation
Download Presentation
Why Projects Fail? Karl Reed’s views..

Loading in 2 Seconds...

play fullscreen
1 / 32

Why Projects Fail? Karl Reed’s views.. - PowerPoint PPT Presentation

  • Uploaded on

Why Projects Fail? Karl Reed’s views. Omitting technically impossible projects.. Q1 What makes a project technically impossible?. Project Attributes.. Lots of definitions… this is from UTS*. * UTS (2008). UTS: PROJECT MANAGEMENT Types of Projects. University of Technology Sydney.

I am the owner, or an agent authorized to act on behalf of the owner, of the copyrighted work described.
Download Presentation

PowerPoint Slideshow about 'Why Projects Fail? Karl Reed’s views..' - coty

An Image/Link below is provided (as is) to download presentation

Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author.While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server.

- - - - - - - - - - - - - - - - - - - - - - - - - - E N D - - - - - - - - - - - - - - - - - - - - - - - - - -
Presentation Transcript

Why Projects Fail? Karl Reed’s views..

Omitting technically impossible projects..

Q1 What makes a project technically impossible?


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

*UTS (2008). UTS: PROJECT MANAGEMENT Types of Projects. University of Technology Sydney.


Soft Projects…

Great places to use


Business Processes

and IT Projects can be heavily

in these areas

*UTS (2008). UTS: PROJECT MANAGEMENT Types of Projects. University of Technology Sydney.


Well defined projects vs fuzzy projects

Iteration needed !

? These steps

not needed?

Note the


*UTS (2008). UTS: PROJECT MANAGEMENT Types of Projects. University of Technology Sydney.


Some Definitions of Failure… from our intro.

  • Failure to meet a defined objective
    • Complete project on budget/on time
  • 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
  • Completed activity “works” but has negative consequences that become apparent over time
  • 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

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

*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

why it projects fail assuming it was possible
Why IT Projects Fail (assuming it was “possible”)…….,
why it projects fail assuming it was possible1
Why IT Projects Fail (assuming it was “possible”)…….,
why it projects fail assuming it was possible2
Why IT Projects Fail (assuming it was “possible”)…….,


Domain Expert


The Nature of Software Projects… Two very extreme views..A. Any Software/IT “need” can be formulated precisely and having done this, if it is “technically feasible”, can be successfully implemented.B. All software/IT “needs” involve outcomes with human actors whose understanding (and hence “need”) is changed by their interaction with the system produced. Hence NO such need can be formulated precisely!B.1 (In any case, software development is a personal, creative activity which depends upon personal skill and hence cannot be formally planned .. The so-called agile community, by implication..)

implications of extreme views
Implications of Extreme Views

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

Lets dicuss..


A Formulation of an Extreme View E-Type systems

Lehmman, M.M. Software Evolution - Cause or Effect,Stevens Memorial Lecture, 2003


A Knowledge Acquisition Based Approach to Software Project Planning


A Five Layer Model of Project Knowledge

A Way of Controlling the Predictability issues

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

3 knowledge acquisition as an issue p16

3. 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”.

4 the kaba domains we came up with a five layer knowledge model for software projects

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

4 the kaba domains we came up with a five layer knowledge model for software projects1

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

4 the kaba domains p18

4. The KABA Domains … p18...

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.


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 re word for context p19

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

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?

using a classic software project model





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

These are all essentially KABA issues!





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



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



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





Using a classic Software Project Model..


5.1 Waterfall (Royce)

6 earlier and other work

6. Earlier and other work …


Widely 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 Manmonth

recognises 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.

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

Seeds exist in much prior work … e.g.

7 kaba domains and components

7. KABA Domains and Components

Basic Domains as evident in Software Development


- 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.


- Commercial Systems Analysis

- Engineering Design Analysis

- “Knowledge” Engineering

and a well understood process


7. KABA Domains and Components for IT Projects


- 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.


7. KABA Domains and Components Software and IT Projects

  • (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 by
  • Computer Science, Software Engineering.
  • (How does this change for Business Processes?)
7 kaba domains and components1

7. KABA Domains and Components

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?)

7 kaba domains and components2

7. KABA Domains and Components



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?)

8 impact of kaba project plan construction

8. 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..)

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..