Why Software Projects Escalate - Keil Flashcards
Why Software Projects Escalate - Keil
Introduction?
- reported statistics: one in four IS projects end in failure
Runaway systems: software projects that go wildly over budget or drag on long past originally scheduled completion date
Escalation of commitment to failing course of action: behaviour underlying runaway systems
SURVEY RESEARCH QUESTIONS
1) What is the frequency and duration of software project escalation?
2) How do projects that escalate differ from projects that do not escalate in terms of project performance?
3) Can constructs associated with different theories of escalation be used to create models capable of distinguishing between projects that escalate and those that do not?
1) & 2) = descriptive 3) = primary focus and rather theoretical
Why Software Projects Escalate - Keil
SURVEY RESEARCH QUESTIONS
SURVEY RESEARCH QUESTIONS
1) What is the frequency and duration of software project escalation?
2) How do projects that escalate differ from projects that do not escalate in terms of project performance?
3) Can constructs associated with different theories of escalation be used to create models capable of distinguishing between projects that escalate and those that do not?
1) & 2) = descriptive 3) = primary focus and rather theoretical
Why Software Projects Escalate - Keil
WHAT DOES Escalation mean?
Escalation: continued commitment to previously chosen course of action in spite of negative feedback concerning viability of course of action
Why Software Projects Escalate - Keil
WHAT DOES Negative project status?
Negative project status: significant performance problems in one or more of following areas: cost, schedule, functionality, quality; may or may not be invisible; central to escalation
Why Software Projects Escalate - Keil
WHAT DOES Mum effect mean?
Mum effect: whenever negative project status is present but not available to those in position to terminate or redirect project – individuals in orga conceal negative info from superiors
Why Software Projects Escalate - Keil
WHAT DOES Deaf effect mean?
Deaf effect: whenever managers are aware of negative info but choose to ignore it
* once escalation is recognised, decision maker can take steps to de-escalate troubled project by either terminating or redirecting along new course of action
Why Software Projects Escalate - Keil
THEORIES TO EXPLAIN ESCALATION BEHAVIOUR: Self justification theory
managers continue to commit resources to failing course of action in order to self justify the correctness of an earlier decision. (social pressure -> social self-justification and psychological self justification)
Why Software Projects Escalate - Keil
THEORIES TO EXPLAIN ESCALATION BEHAVIOUR: Prospect Theory?
Managers commit resources to failing project because decision framed as choice between losses which leads to risk seeking behaviour. Sunk cost are believed to invoke a choice between losses leads to escalating behaviour. (sunk cost effect)
-> individuals will chose risk seeking not risk averse behaviour when chooseing between two negative alternatives
Why Software Projects Escalate - Keil
THEORIES TO EXPLAIN ESCALATION BEHAVIOUR: agency Theory?
Managers commit resources to failing project because it is in their best interest to do so due to different goals between manager and his superiors and a condition of information asymmetry
Why Software Projects Escalate - Keil
THEORIES TO EXPLAIN ESCALATION BEHAVIOUR: agency Theory?
Managers commit resources to failing project because the forces encourage them to do so (driving forces) are stronger than. those forces which suggest discontinuation (restraining forces). One key driving force is completion effect which is the pull on an individual due to potential future benefits
Why Software Projects Escalate - Keil
Why Software Projects Escalate - Keil
Research method
- cross sectional survey of information systems audit & control professional collecting information on both escalated & non-escalated projects (IS auditors more objective due to monitoring role)
further methodology not important*
Why Software Projects Escalate - Keil
RESULTS AND DISCUSSION: – FREQUENCY & DURATION OF SOFTWARE PROJECT ESCALATION
- frequency: 30-40% of all IT projects involve some degree of project escalation
Duration of escalation: refers to how long projects are allowed to continue after point at which IS auditor believes they should have been terminated or redirected - duration: average escalation time was 21 months with half of projects escalating for 15 or more months
escalation is frequently and commonly occurring problem
Why Software Projects Escalate - Keil
RESULTS AND DISCUSSION:COMPARISON ESCALATED VS NONESCALATED PROJECT PERFORMANCE
- escalated projects more likely to have performance problems: in terms of implementation & budget/schedule performance (relative to non-escalated projects)
Why Software Projects Escalate - Keil
RESULTS AND DISCUSSION: DISTINGUSHING ESCALATION FROM NON-ESCALATION WITH THEORIES
- ability of classifying both escalated & non-escalated projects: constructs derived from avoidance theory & agency theory
- ability of classifying escalated but not non-escalated projects: constructs derived from self-justification theory & prospect theory
Why Software Projects Escalate - Keil
LIMITATIONS OF STUDY ?
LIMITATIONS OF STUDY
* study relied on self-reported info by IS audit and control professionals subject to bias
* research based on input of single respondent for each case studied subject to method bias
* operationalisation & measurement of escalation-related constructs was problematic (especially for self-justification theory) + chosen to emphasize certain constructs & omit others
Why Software Projects Escalate - Keil
IMPLICATIONS FOR RESEACH ?
IMPLICATIONS FOR RESEACH
* study shows evidence that escalation is frequent problem & escalated projects show worse performance than non-escalated
* variables of escalation theories can be used to distinguish between projects (escalation) + theories that explain escalation phenomenon are not mutually exclusive (can be used complementary)
Why Software Projects Escalate - Keil
IMPLICATIONS FOR RESEACH: MAIN FINDINGS WITH REGARDS TO THEORIES/CONSTRUCTS?
- completion effect construct (from avoidance approach): best discriminator between escalated and non-escalated projects
- model derived from agency theory: good classification but decrease in prediction capability on hold out sample in comparison to estimation sample
- sunk cost effect construct: good at classification for only escalated projects
Why Software Projects Escalate - Keil
Implication for practice
IMPLICATIONS FOR PRACTICE
* managers should be aware that incidence of project escalation is relatively high & that its outcomes are markedly worse than non-escalated projects models developed in study help avoid it
1) managers should implement early warning signs aimed at detecting escalation
2) should define termination conditions at outset of project
3) should embrace one or more models presented and tailor it to own environment
best model in paper classified 77% of escalated projects & 71% of non-escalated projects (both) = model based on constructs of approach avoidance theory
other models classified only the escalated projects better = eg model based on constructs of prospect theory or SJT
* problem of incorrectly classifying a non-e as escalating and the other way around can be considered in terms of type 1 and type 2 errors trade-off with minimising type 2 errors at expense of generating type 1 error and vice versa
trade-off between errors has strategic implications: if firm chooses to devoid escalation at all costs, it might forego some projects that could have provided competitive advantage vs allowing too many cases of escalation will drain resources from organisation
Why Software Projects Escalate - Keil
SUMMARY & CONCLUSION
SUMMARY & CONCLUSION
* completion effect increased chances of project escalation by 21%
* constructs associated with agency theory information asymmetry & goal incongruence increased chances of project escalation by 7 and 3.6 times respectively
theories and models are based on behavioural factors that provide more useful information about probability of project escalation than traditional structural variables such as project size
