Why Projects Fail? Karl Reed’s views..

1. Why Projects Fail? Karl Reed’s views.. Omitting technically impossible projects.. Q1 What makes a project technically impossible?

2. Project Attributes..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

3. Soft Projects… Great places to use ontologies Business Processes and IT Projects can be heavily in these areas *UTS (2008). UTS: PROJECT MANAGEMENT Types of Projects. University of Technology Sydney. http://www.projects.uts.edu.au/

4. Well defined projects vs fuzzy projects Iteration needed ! ? These steps not needed? Note the differences *UTS (2008). UTS: PROJECT MANAGEMENT Types of Projects. University of Technology Sydney. http://www.projects.uts.edu.au/

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

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

7. Some Definitions of Failure… from our intro.set 1.

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

9. Why IT Projects Fail (assuming it was “possible”)…….,

10. Why IT Projects Fail (assuming it was “possible”)…….,

11. Why IT Projects Fail (assuming it was “possible”)……., The Domain Expert

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

13. Implications of Extreme Views Looking at this slide.. What are the various implications and outcomes? Lets dicuss..

14. A Formulation of an Extreme View E-Type systems Lehmman, M.M. Software Evolution - Cause or Effect,Stevens Memorial Lecture, 2003 http://www.cs.mdx.ac.uk/staffpages/mml/listing.html

15. A Knowledge Acquisition Based Approach to Software Project Planning Or 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

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

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

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

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

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

21. Design Docs Feasibility Problems 1. Everything can actually be done when its phase occurs. These are all essentially KABA issues! System Design Module Design 2. Nothing can be done before its phase is due. Module Coding 3. Nothing in phase j can invalidate decisions in phase j-i. Module Testing 4. Nothing (assumed) in phase i will prove impossible in phase i + j. System Integration System Testing Using a classic Software Project Model.. Code 5.1 Waterfall (Royce)

22. 6. Earlier and other work … 6.1 DOMAIN ENGINEERING 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.

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

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

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

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

27. 7. KABA Domains and Components 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?)

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

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

30. 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 PROJECT ESTIMATING AND WHY PROJECTS FAIL..

31. Discussion…

32. Why Projects Fail Additional Topics..