why projects fail? karl reed’s views
DESCRIPTION
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. - PowerPoint PPT PresentationTRANSCRIPT
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
isufi 2008 Lecce wpf rev 2. p 2
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
isufi 2008 Lecce wpf rev 2. p 3
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
isufi 2008 Lecce wpf rev 2. p 4
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
isufi 2008 Lecce wpf rev 2. p 5
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
isufi 2008 Lecce wpf rev 2. p 6
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
isufi 2008 Lecce wpf rev 2. p 7
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
isufi 2008 Lecce wpf rev 2. p 8
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
isufi 2008 Lecce wpf rev 2. p 9
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
isufi 2008 Lecce wpf rev 2. p 10
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
-See 3,4. In Reasons
-See 3,4. In Reasons
Karl Reed
isufi 2008 Lecce wpf rev 2. p 11
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
isufi 2008 Lecce wpf rev 2. p 12
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
isufi 2008 Lecce wpf rev 2. p 13
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
isufi 2008 Lecce wpf rev 2. p 14
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
isufi 2008 Lecce wpf rev 2. p 15
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
isufi 2008 Lecce wpf rev 2. p 16
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
isufi 2008 Lecce wpf rev 2. p 17
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
isufi 2008 Lecce wpf rev 2. p 18
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?)
APPLICATION What exactly is the problem?
What physical/organization/social/laws/ models govern it?
Business Goals and End to End tasks and Processes and their nature
APPLICATION-SOLUTION
Machine executable algorithms related to above;
Particular (m.e.) algorithms/system structures/architecture…..
The actual individual activities and rules
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.
Organisational infrastructure needed for the process to execute
PROJECT MANAGEMENT
Estimating, project organisation, resource acquisition, customer liaison, quality control.
The business process planning process
Karl Reed
isufi 2008 Lecce wpf rev 2. p 19
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
isufi 2008 Lecce wpf rev 2. p 20
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
isufi 2008 Lecce wpf rev 2. p 21
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
isufi 2008 Lecce wpf rev 2. p 22
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
isufi 2008 Lecce wpf rev 2. p 23
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
isufi 2008 Lecce wpf rev 2. p 24
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
isufi 2008 Lecce wpf rev 2. p 25
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
isufi 2008 Lecce wpf rev 2. p 26
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 Components7. KABA Domains and Components
Karl Reed
isufi 2008 Lecce wpf rev 2. p 27
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?)
7. KABA Domains and Components7. KABA Domains and Components
Karl Reed
isufi 2008 Lecce wpf rev 2. p 28
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
isufi 2008 Lecce wpf rev 2. p 29
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?)
APPLICATION What exactly is the problem?
What physical/organization/social/laws/ models govern it?
Business Goals and End to End tasks and Processes and their nature
APPLICATION-SOLUTION
Machine executable algorithms related to above;
Particular (m.e.) algorithms/system structures/architecture…..
The actual individual activities and rules
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.
Organisational infrastructure needed for the process to execute
PROJECT MANAGEMENT
Estimating, project organisation, resource acquisition, customer liaison, quality control.
The business process planning process
Karl Reed
isufi 2008 Lecce wpf rev 2. p 30
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
isufi 2008 Lecce wpf rev 2. p 31
Discussion…Discussion…
Karl Reed
isufi 2008 Lecce wpf rev 2. p 32
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?