Archive for the ‘Failed Projects’ Category

Research Featured in Harvard Business Review

Donnerstag, Juli 26th, 2012

After 2 years of researching ICT projects the on-going research has been picked up by the Harvard Business Review and is on the cover of their September 2011 issue.

„Why your IT projects may be riskier than you think?“

By now, I collected a database of nearly 1,500 IT projects – in short we argue that the numbers in the hotly debated Standish Report are wrong, but their critics don’t get it quite right either. We found that while IT projects perform reasonably well on average the risk distribution has very fat tails in which a lot of Black Swan Events hide. 1 in 6 IT projects turned into a Black Swan – an event that can take down companies and cost executives their jobs.

Enjoy the read!

More background reading on the HBR article can be found in this working paper.

Standish Chaos Report 2009

Dienstag, April 28th, 2009

Standish 2009

The Standish Group just published their new findings from the 2009 CHAOS report on how well projects are doing.  This years figures show that 32% of all projects are successful, 44% challenged, and 24% fail.  As the website says startling results especially that they still do not hold up to scientific standards and replications of this survey (e.g. Sauer, Gemino & Reich) find exactly the opposite picture.

Failure at the Speed of Light (Hickerson, 2006)

Samstag, April 25th, 2009

[Hot stuff! Not because it is fresh or hot of the press, no but surprisingly "Failed Projects" is the most read category on this blog this year with more than 700 readers, runner-up is "Critical Success Factors" and it is catching up quickly. ]

DSC02123

Hickerson, Thomas B.: Failure at the Speed of Light – Project Escalation and De-escalation in the Software Industry, Master of Arts in Law and Diplomacy Thesis, Tufts University, Medford, Massachusetts, 2006.
http://fletcher.tufts.edu/research/2006/Hickerson.pdf

 

Hickerson analyses three case studies – (1) California’s Department of Social Securities implementation of the California Automated Child Support System (CACSS), (2) Denver International Airport, and (3) FBI’s Virtual Case File.

Firstly, CACSS was planned and started in 1992, the tender went to Lockheed Martin for $75m with a go-live in December 1995.  The whole project was cancelled in 1997 after direct expenses of $100m were incurred.  A new version of the system started development in 2000 and finally went live in June 2008 (see this news snippet) and it is online here.

Second case is the Denver International Baggage Handling system.  This case is infamous to the extend that it made it on wikipedia, the full GAO report can be found here.  In short: BAE won the tender for $193m.  The system development had so many problems that in order to open the airport an alternative manual handling system was installed, which came at a price ticket of only $51m; at the time of opening the airport (Feb 1995, 2 years behind schedule anyway) the delays caused by the baggage handling system were estimated to be $360m.  Before United axed the system it cost about $1m per month in maintenance.

Third case is the FBI’s Virtual Case File.  The project started in 2001, quickly reached the typical 90% complete.  After 4 years the solution was replaced by a commercial off the shelf software and another 3 months later the project was cancelled altogether after $607m were spent.

 

Drawing from Social Justification Theory, Agency Theory, Approach Avoidance Theory Hickerson argues that ‚Internal inadequacies in dealing with external threats‘ was the main reason for the failures.  In case of DIA some project factors contributed to the failure such as the investment character of the project, long-term pay-offs, large size of the pay-offs, resources seen as plentiful, setbacks seen as secondary.

Apart from project factors psychological factors contributed to the failure of these cases, e.g., personal responsibility, ego importance, prior success and reinforcement, irreversibility of prior expenditures.  Thirdly social factors were responsible, such as the responsibility for failure, norms for consistency, hero effects, public identification with the course of action, and job insecurity.  Fourthly, structural factors played a role, e.g., political support, institutionalisation, and bureaucracy.

 

What were the tipping points that tipped the projects into escalation?

  • Change in top management support
  • External shocks to the organisation
  • Change in project champion
  • Organisational tolerance for failure
  • Presence of publicly stated resources
  • Alternate use of funds
  • Awareness of problems
  • Visibility of costs
  • Clarity of failure & success criteria
  • Organisational procedures of decision-making
  • Regular evaluation of projects
  • Separation of responsibility for approving and evaluation projects

What needs to be done to prevent escalation?

  1. Strict timeline
  2. Clear acceptance criteria
  3. Daily meetings between CIO and Managers
  4. Adherence to baseline requirements

Understanding the Nature and Extent of IS Project Escalation (Keil & Mann, 1997)

Dienstag, Januar 13th, 2009

DSC01460

Keil, Mark; Mann, Joan: Understanding the Nature and Extent of IS Project Escalation – Results from a Survey of IS Audit and Control Professionals; in: Proceedings of The Thirtieth Annual Hawaii International Conference on System Sciences, 1997.

"Many runaway IS projects represent what can be described as continued commitment to a failing course of action, or "escalation" as it is called in management literature."  Keil & Mann argue that escalation of projects can be explained with four different factors – (1) project factors, (2) social factors, (3) psychological factors, and (4) organisational factors.

  1. Project Factors – cost & benefits, duration of the project
  2. Social Factors – rivalry between projects, need for external justification, social norms
  3. Organisational Factors – structural and political environment of the project
  4. Psychological Factors – managers previous experience, sunk-cost effects, self-justification

In 1995 Keil & Mann conducted a survey among IS-Auditors, among their most interesting findings are

  • 38.3% of all SW development projects show some level of escalation (Original question: ‚In your judgement, how many projects are escalated?‘).
  • When asked ‚From your last 5 projects how many escalated?‘ 19% of the auditors said none, 28% said 1, 20% said 2, 16% said 3, 10% said 4 and 8% said all 5.
  • Escalation of schedule 38% of projects 1-12 months, 36% 13-24 months, maximum in the sample was 21 years.
  • Average budget overrun of projects was 20%, when projects escalate average budget overrun is 158%.
  • 82% of all escalated projects run over their budget, whilst only 48% of all non-escalated projects run over their budget
  • Success rate of escalated projects is devastating – of all escalated projects 23% were completed successfully, 18% were abandoned, 5% were completed but never implemented, 23% were partially completed, 18% were unsuccessfully completed, and 8% were completed and then withdrawn.

Furthermore, Keil & Mann test for the reasons for escalation behaviour, based on their 4 factor concept.  They found the main reasons for project escalations were

  • Underestimation of time to completion
  • Lack of monitoring
  • Underestimation of resources
  • Underestimation of scope
  • Lack of control
  • Changing specifications
  • Inadequate planning

Why Software Projects Escalate – An Empirical Analysis and Test of Four Theoretical Models (Keil et al., 2000)

Montag, Januar 12th, 2009

DSC01459

Keil, Mark; Mann, Joan; Rai, Arun: Why Software Projects Escalate – An Empirical Analysis and Test of Four Theoretical Models; in: MIS Quarterly, Vol. 24 (2000), No. 4, pp. 631-664.

The authors describe that: "Software projects can often spiral out of control to become ‚runaway systems’…".  Keil et al. define escalation behaviour as constantly adding resources to the project.  Thus escalated projects typically overrun their schedule and budget.  The authors describe the case of the Statewide Automated Child Support System (SACSS) of California’s Dept. of Social Services.  The project was started in 1992 with a projected budget of USD 75.5m and a go-live date in 1995.  The project escalated and did cost an estimated USD 345m and was finally terminated in 1997 without any deliverables in place. 

Based on a large scale survey of IS-Auditors Keil et al. found that 30-40% of all software development projects show some degree of escalation.  Then the authors analyse four different theoretical models how to explain escalation – (1) Self-Justification Theory, (2) Prospect Theory, (3) Agency Theory, (4) Approach Avoidance Theory.

Self-Justification Theory – SJT is grounded in Feistinger’s cognitive dissonance, most easily self-justification can be characterised as a retrospectively rationalising behaviour which is found to violate internal or external beliefs, attitudes, or norms.  As the wikipedia article on SJT describes it self-justification typically manifests in two forms internal SJT or external SJT.  Internal SJT strategies are changing the violated attitude, downplaying or denying the negative consequences; whilst external SJT strategies are all sorts of external excuses from bad luck, to lack of competencies.  Keil et al. argue that two effects are relevant for escalation behaviour – social and psychological self-justification.  Whilst psychological self-justification is a strategy to overcome dissonance, social pressures increase the need for self-justification, e.g., saving your face.

Prospect Theory – Kahneman & Tversky’s Prospect Theory and their Cumulative Prospect Theory describes decision-making under uncertainty and risk.  Keil et al. argue that Prospect Theory explains escalation behaviour, because the theory postulates that when choosing between two adverse events, deciders are seeking greater risks.  Commonly this is also referred to as ’sunk cost effect‘.

Agency Theory – Jensen & Meckling’s concept of principal-agent relationships covers many examples of principals delegating decision competencies or execution of tasks to agents.  A principal-agent relationships turns sour (aka principal-agent problem) when goal incongruence and information asymmetry create a constellation of imperfect contracting and monitoring.  In general terms – the agents maximise their self-interest at the expense of the principal.  Simplest real-world example – the software integrator who you hired to do most of your work never wants your project to finish.

Approach Avoidance Theory – Rubin & Brockner’s concept of approach avoidance which is described that every approach vs. avoidance decisions is driven by the iconic little angel vs. little devil.  In the case of escalated projects, these forces either encourage persistence or abandonment of the project.  Three factors explain why projects are not terminated – (1) size of reward for goal attainment, (2) withdrawal costs, and (3) goal proximity.  Keil et al. argue that especially the third factor ‚goal proximity‘ creates a completion effect which is explained by the need for task closure.  They argue that this is a better conceptualisation of escalation symptoms than the sunk cost effect, aka throw good money after bad money.  They describe that completion effects pull an individual towards the goal whilst sunk cost effects push an individual further.  A beautiful real life example is the 90%-completion syndrome:

This syndrome refers to the tendency for estimates of work completed to increase steadily until a plateau of 90% is
reached. Thereafter, programmer estimates of the fraction of work completed increase very slowly. In some cases, inaccurate estimation leads to situations in which software projects are reported to be 90% complete for half of the entire duration of the project, an obvious impossibility (Brooks 1975).

Keil et al. test 6 constructs taken from these 4 theories which were previously connected to escalation behaviour – psychological self-justification, social self-justification, sunk cost effect, goal incongruence, information asymmetry, and completion effect.
With a series of pairwise logistic regression models between the groups of escalated vs. non-escalated projects – all 6 constructs and therefore all 4 theories can empirically be proven.  However the best classifier for escalation vs. non-escalation is the completion effect.

10 Mistakes that Cause SOA to Fail (Kavis, 2008)

Dienstag, Januar 6th, 2009

DSC01430

Kavis, Mike: 10 Mistakes that Cause SOA to Fail; in: CIO Magazine, 01. October 2008.
I usually don’t care much about these industry journals. But since they arrive for free in my mail every other week, I could help but noticing this article, which gave a brief overview of two SOA cases – United’s new ticketing system and Synovus financial banking system replacement.

However, the ten mistakes cited are all too familiar:

  1. Fail to explain SOA’s business value – put BPM first, then the IT implementation
  2. Underestimate the impact of organisational change – create change management plans, follow Kotter’s eight step process, answer everyone the question ‚What’s in it for me?‘
  3. Lack strong executive sponsorship
  4. Attempt to do SOA on the cheap – invest in middleware, invest in governance, tools, training, consultants, infrastructure, security
  5. Lack SOA skills in staff – train, plan the resources, secure up-front funding
  6. Manage the project poorly
  7. View SOA as a project instead of an architecture – create your matrices, war-room; engage collaboration
  8. Underestimate SOAs complexity
  9. Fail to implement and adhere to SOA governance
  10. Let the vendor drive the architecture

Building knowledge in projects – A practical application of social constructivism to information systems development (Jackson & Klobas, 2008)

Donnerstag, Oktober 23rd, 2008

Building knowledge in projects - A practical application of social constructivism to information systems development (Jackson & Klobas, 2008)

Jackson, Paul; Klobas, Jane: Building knowledge in projects – A practical application of social constructivism to information systems development; in: International Journal of Project Management, Vol. 26 (2008), No. 4, pp. 329-337.
http://dx.doi.org/10.1016/j.ijproman.2007.05.011

Jackson & Klobas describe the constructivist model of knowledge sharing and thus organisational learning. This classical model describes knowledge sharing in organisations as a constant cylcle of

  • Creating personal knowledge
  • Sharing newly created personal knowledge = Externalisation
  • Communication knowledge = Internalisation
  • Acquiring other peoples‘ knowledge = Learning

This cylcle includes the facilitating steps of Objectivation (=creating organisational knowledge), Legitimation (=authorising knowledge), and reification (=hardening knowledge) between externalisation and internalisation.

Jackson & Klobas argue that IT project failure can be explained using this model. The authors outline and discuss three failure factors – (1) lack of personal knowledge, (2) inability to externalise knowledge, and (3) lack of communication.

Project leadership in multi-project settings – Findings from a critical incident study (Kaulio, 2008)

Donnerstag, Oktober 23rd, 2008

 Project leadership in multi-project settings - Findings from a critical incident study (Kaulio, 2008)

Kaulio, Matti A.: Project leadership in multi-project settings – Findings from a critical incident study; in: International Journal of Project Management, Vol. 26 (2008), No. 4, pp. 338-347.
http://dx.doi.org/10.1016/j.ijproman.2007.06.005

Kaulio asked project leaders, who operate in a multi-project environment about critical incidents in their last projects. The idea of critical incidents is, that as soon as a participant remembers the critical incident it must have some importance. Ideally it then is followed by a blueprint analysis followed by measuring the criticality is measured on each contact point. Kaulio focusses only on the elicitation of the critical incidents, without doing the triple-loop of the original research concept. The author shows the frequency of critical incidents happening:

  • Technical difficulties
  • Dyadic leadership
  • Group dynamics
  • Consultant relations
  • Client relations
  • Peer relations
  • Project adjustments
  • Re-prioritisations
  • Liked dyadic-group processes
  • Formation of project
  • Court decisions
  • Dependencies
  • Requirements specification

Kaulio then maps these critical incidents according to the Locus of Control (internal vs. external) and whether they are a Management or a Leadership issue. Thus he argues  most of the critical incidents can be tied back to internal project leadership:

Locus of Control External
  • Project adjustment
  • Court decision
  • Consultant relations
  • Client relations
  • Peer relations
  • Formation of project
  • Dependencies
Internal
  • Requirements specification
  • Dyadic leadership
  • Group dynamics
  • Linked dyadic-group processes
  • Technical difficulties
  • Re-prioritisation
Management Leadership
Focus

Graphical Representation of the Project Management Body of Knowledge

Dienstag, Oktober 21st, 2008

Poster (black, horizontal)

Today I woke up very early and created these beautiful pictures summarising all keywords from the last 5 years in the International Journal of Project Management and the Journal of Project Management.

In my lunch break another thought struck me – you need something on that bare wall you have here. From there on it was a short step to run the PMI’s PMBOK Guide 3rd Ed. through wordle.net and after a lot of tweaking, it created some beautiful posters, reminding me what the PMP is all about. I use Lulu.com to print the poster on demand – I am quite satisfied with Lulu the largest poster measuring 23″ x 36″ (61cm x 91 cm) comes for just $39.95, excluding shipping.

The posters can be ordered at my Lulu Store.

And here are all of the designs I put online:

Poster (white, horizontal - 2nd Version)

Poster (black, horizontal)Poster (white, horizontal)

Poster (black, vertical)Poster (white, vertical)

Creative Commons License
These works are licensed under a Creative Commons Licence.

Stakeholder salience in global projects (Aaltonen et al., 2008)

Montag, Oktober 20th, 2008

 Stakeholder salience in global projects (Aaltonen et al., 2008)

Aaltonen, Kirsi; Jaako, Kujala; Tuomas, Oijala: Stakeholder salience in global projects; in: International Journal of Project Management, Vol. 26 (2008), No. 5, pp. 509-516.
http://dx.doi.org/10.1016/j.ijproman.2008.05.004

In their 1997 article, Mitchell et al. define stakeholder salience as „the degree to which managers give priority to competing stakeholder claims“. Furthermore, Mitchell at al. describe how the salience of a stakeholder is defined by three characteristics – (1) the stakeholder’s power to influence the firm, (2) the legitimacy of the stakeholder’s relationship with the firm, and (3) the urgency of the stakeholder’s claim on the firm.

Aaltonen et al. use the case study of a construction project of a paper-mill in South America to outline what strategies Stakeholders use to influence their salience. In line with typical case studies of construction projects Aaltonen’s stakeholders are environmentalist groups trying to influence the project. [I personally think based on my experience what Aaltonen et al. describe is also true for all sorts of projects, just if I think back to my organisational change and IT projects where we had workers‘ unions and councils as equally hard to manage stakeholders.] The authors observed a couple of strategies used:

  • Direct/indirect withholding strategy
  • Resource building strategy
  • Coalition building strategy
  • Conflict escalation strategy
  • Credibility building strategy
  • Direct action strategy

As per Mitchell’s definition these strategies aim to increase influencing power, legitimacy, and/or urgency. The tactics used to increase power were

  • Affect & influence parties, that provide resources, e.g., lobbying financiers and politicians
  • Affect the resource supply directy, e.g., laws and policies that prohibit imports
  • Build lobbying alliances, e.g., between environmentalist groups and unions
  • Recruit individuals with networks to important resource providers, e.g., ex-regulators, governmental workers, activists

The tactics used to increase legitimacy were

  • Initiate legal and political conflict, e.g., court action, political support
  • Inform the public about impacts of the project, thus damaging reputation of the project and increasing legitimacy
  • Signal illegitimacy of project, e.g., boycotts, counter impact studies
  • Attack supporters, e.g., showing them being partial, exposing lobbyists
  • Use other projects as showcases, e.g., using abandoned projects and withdrawls to show the illigitimacy of the project

The tactic used to increase urgency was signalling urgency, time-sensitivity, and criticality of decisions, e.g., by staging direct actions, protests, sit-ins, road blocks.

An experimental investigation of factors influencing perceived control over a failing IT project (Jani, 2008)

Montag, Oktober 20th, 2008

An experimental investigation of factors influencing perceived control over a failing IT project (Jani, 2008)

Jani, Arpan: An experimental investigation of factors influencing perceived control over a failing IT project; in: International Journal of Project Management, Vol. 26 (2008), No. 7, pp. 726-732.
http://dx.doi.org/10.1016/j.ijproman.2008.06.004

Jani wants to analyse why failing projects are not terminated, a spiralling development also called escalation of commitment (I posted about a case discussion of the escalation of commitment on the TAURUS project).  Jani performed a computer simulated experiment to show the antecedents of a continuation decision.

He rooted the effect of escalating commitment on the self-justification theory, prospect theory, agency theory, and also on sunk cost effects & project completion effects.

Self-justification motivates behaviour to justify attitudes, actions, beliefs, and emotions. It is an effect of cognitive dissonance and an effective cognitive strategy to reduce the dissonance. An example for this behaviour is continuing with a bad behaviour, because stopping it would question the previous decision (= escalation of commitment).

Another example is bribery. People bribed with a large amount of money, tend not to change their attitudes, which were unfavourable otherwise there was nor reason to bribe them in the first place. But Festinger & Carlsmith reported that bribery with a very small amount of money, made people why they accepted the bribe although it had been that small, thus thinking that there must be something to it and changing their attitude altogether. Since I did it, and only got 1 Dollar is a very strong dissonance. Here is a nice summary about their classic experiments. Here is one of their original articles.

Jani argues that all these theoretical effects fall into two factors – (1) self-serving bias and (2) past experience. These influence the judgement on his two antecedents – (1) project risk factors (endogeneous and exogeneous) and (2) task specific self-efficacy. The latter is measured as a factor step high vs. low and describes how you perceive your capability to influence events that impact you (here is a great discussion of this topic by Bandura).

The two factors of project risk and task specific self-efficacy then influence the perceived control over the project which influences the continuation decision. Jani is able to show that task specific self-efficacy moderates the perceived project control. In fact he manipulated the project risks to simulate a failing projects, at no time participants had control over the outcome of their decisions. Still participants with a higher self-efficacy judged their perceived control significantly higher than participants with lower self-efficacy. This effect exists for engogenous and exogenous risk factors alike.

The bottom-line of this experiment is quite puzzling. A good project manager, who has a vast track record of completing past projects successfully, tends to underestimate the risks impacting the project. Jani recommends that even with great past experiences on delivering projects, third parties should always review project risks. Jani asks for caution using this advice since his experiment did not prove that joint evaluation corrects for this bias effectively.

Lee, Margaret E.: E-ethical leadership for virtual project teams; in: International Journal of Project Management, in press (2008).
http://dx.doi.org/10.1016/j.ijproman.2008.05.012

I quickly want to touch on this article, since the only interesting idea which stroke me was that Lee did draw a line from Kant to Utilitarism to the notion of Duty. She then concludes that it is our Kantesian, Utalitarian duty to involve stakeholders.

Success in IT projects: A matter of definition? (Thomas & Fernández, in press)

Donnerstag, Oktober 9th, 2008

Success in IT projects: A matter of definition? (Thomas & Fernández, in press)

Thomas, Graeme; Fernández, Walter: Success in IT projects – A matter of definition?; in: International Journal of Project Management, in press (2008).
http://dx.doi.org/10.1016/j.ijproman.2008.06.003

A lot of IT projects are not successful. One of the problems seems to be that success is a tricky concept. The GAO considers (IT) projects as challenged if they are about to exceed their budget and/or schedule by 10%. As such most projects fail.

Several best practice studies have pointed out that agreeing on success criteria is better down upfront, they should be consistently measured, which includes a proper baseline, and their measurement results must be used.

Thomas & Fernández collect examples for IT project success criteria in three broad categories: project management, technical, and business criteria.

Project Management Criteria

  • On-time
  • On-budget
  • Sponsor satisfaction
  • Steering group satisfaction
  • Project team satisfaction
  • Customer/user satisfaction
  • Stakeholder satisfaction

Technical Criteria

  • Customer satisfaction
  • Stakeholder satisfaction
  • System implementation
  • Meeting requirements
  • System quality
  • System use

Business Criteria

  • Business continuity
  • Meeting business objectives
  • Delivery of benefits

Managing user expectations on software projects – Lessons from the trenches (Petter, in press)

Dienstag, Oktober 7th, 2008

 Managing user expectations on software projects - Lessons from the trenches (Petter, in press)

Petter, Stacie: Managing user expectations on software projects – Lessons from the trenches; in: International Journal of Project Mangement, in press (2008).
doi:10.1016/j.ijproman.2008.05.014

Petter interviewed 12 project management professionals on managing the end-user expectations.  What worked and what did not work?

The conclusions cover three broad areas – end user involvement, leadership, and trust. As far as user involvement is concerned the practices that work included

  • Listening to users
  • Asking questions
  • Understanding concerns about change and actively ease these
  • Working with the user (not at or to them)
  • Let user make tough choices, e.g., on functionality, budget, cost, time
  • Create small user groups to hear them all
  • Giving credit to specific users for ideas
  • Keep users involved and updated throughout the project

What did not work were – not communicating the project status, and trying to outlast difficult users.

On the leadership dimension useful practices mentioned include

  • Ensure project champion
  • Articulate clear vision
  • Motivate team to get it done
  • Educate users on benefits
  • Obtain buy-in from primary stakeholders

Factors leading to end-user dissatisfaction were

  • Scope creep
  • No mission
  • No explanation of purpose/value of the system
  • Follow others

Trust building activities that worked well, were sharing good and bad news, and providing specific times for deliverables. What did not work were hiding the true status of the project, and ‚fake it until you make it‘ also known as hiding knowledge gaps.

Why New Business Development Projects Fail (Burgers et al. 2008) and Interdependencies in Complex Project Ecologies (Newell et al. 2008)

Donnerstag, September 18th, 2008

 hy New Business Development Projects Fail

Burgers, Henri J.; Van Den Bosch, Frans A.J.; Volberda, Henk W.: Why New Business Development Projects Fail – Coping with the Differences of Technological versus Market Knowledge; in: Long Range Planning, Vol 41 (2008), No. 1, pp. 55-73.
http://dx.doi.org/10.1016/j.lrp.2007.10.003

The authors of the first paper  identify five critical success factors for your new business development project (NBD)

  1. Match project autonomy to newness of technology
  2. Align completion criteria
  3. Get an organisational champion, who can overturn autonomy & completion criteria shortfalls
  4. Explore strategic alliances to speed up market knowledge on technlogoy
  5. Align sales force incentives to NBD

Especially point No. 1 is noteworthy for it’s interesting framework and the transfer of their framework onto other projects, e.g., IT. Burger et al.’s framwork spans two dimensions: market knowledge (existing vs. new) and technology knowledge (existing vs. new). If both knowledge areas are new fields to the organisation (technology and market), the project needs maximum autonomy, it’s goal should be the exploration and the product should stay in project mode until it achieved profitability. Whereas a project were both areas of knowldge pre-exist, the project should not explore, needs little autonomy and the product should be handed over into operations as soon as it hits the shelves.
Newell, Sue; Goussevskaia, Anna; Swan, Jacky; Bresnen, Mike; Obembe, Ademola: Interdependencies in Complex Project Ecologies – The Case of Biomedical Innovation; in: Long Range Planning, Vol. 41 (2008), No. 1, pp. 33-54.
http://dx.doi.org/10.1016/j.lrp.2007.10.005

The second article in this post examines innovation projects from a different angle. Newell et al. draw a typology of projects based on their ecology and integration. They state that challenges associated with managing projects that are distributed across time, space and organizations – a common, though under-researched, feature of innovation in numerous high-technology domains.

Like marriage counselors they argue that in a complex project environment (high degree of interdependencies) a high level of interactivity is most fruitful. The reality check, as it turns out in the analysis, shows however that most project run as black-boxes, no knowledge is transferred between projects, and the level of collaboration is low at least. A case example for a bad marriage. Finally Newell et al. explore the reasons for this, and pay particular attention  to the effects of power dynamics and the sector’s dominant knowledge regime.

Information Systems implementation failure – Insights from PRISM (Pan et al., 2008)

Donnerstag, September 18th, 2008

 Information Systems implementation failure - Insights from prism

Pan, Gary; Hackney, Ray; Panc, Shan L.: Information Systems implementation failure – Insights from prism; in: International Journal of Information Management, Vol. 28 (2008), pp. 259–269.

The authors apply a „antecedents — critical events — outcomes“-framework to analyse the implementation process. Pan et al. postulate a recursive process interaction model which repeats throughout critical events in the project. The Process modell flows circular between Project Organisation-(innovates)-IS-(serves)-Supporters-(support)-Project Organisation and so on.

Furthermore the authors identify critical events (positive and negative) to analyse the system failure of the whole project. Generalizing from the chain of negative events, Pan et al. found that recursive interactions lead to a drift of the project. Subsequently that drift leads to a sequence of decision mistakes which accelerated into project failure.

In the 25 years since The Mythical Man-Month what have we learned about project management? (Verner et al., 1999)

Donnerstag, Juli 17th, 2008

Mythical Man Month

Verner, J. M.; Overmeyer, S. P.; McCain, K. W.: In the 25 years since The Mythical Man-Month what have we learned about project management?; in: Information and Software Technology, Vol. 41 (1999), No. 14, pp. 1021-1026.
http://dx.doi.org/10.1016/S0950-5849(99)00077-4

The original Fred Brooks‘ book ‚The Mythical Man-Month‚ (1975) explored why IT projects usually deliver late. It states a couple of reasons

  • Poor estimations and the assumption that everything will go well
  • Estimation techniques which confuse effort with progress and vice versa
  • Managers are uncertain about estimates and the do not stubbornly support them
  • No one publishes productivity figures, thus no one can defend his estimates
  • Poor schedule monitoring and control
  • If slippage occur man power is added, which makes it worse – here Brooks introduces the concept of the n*(n-1)/2 communication channels on a team

Verner et al. revisit the original claims and check them against critical success factor research. They found that most of these claims still hold true – but that ‚recently‘ a lot more factors touching the human side of project management have been discovered, e.g., senior management support, customer relationships, knowledgeable and experienced project manager.

How to fail in project management – without really trying (Pinto & Kharbanda, 1996)

Dienstag, Juli 15th, 2008

 How to ensure failure

Pinto, Jeffrey K.; Kharbanda, Om P.: How to fail in project management – without really trying; in: Business Horizons, Vol. 39 (1996), No. 4, pp. 45-53.
http://dx.doi.org/10.1016/S0007-6813(96)90051-8

Since Pinto popularised the critical success factor and failure factor research, which established a large body of research I wanted to include this paper though it is a bit dated. Pinot & Kharbanda basically illustrate how one can ensure complete and utterly failure as an owner of an IT project:

  • Ignore the environment (espy. stakeholders)
  • Push a new technology in a market too quickly
  • Don’t bother building fall back options
  • When problems occur shoot the most visible one
  • Let new ideas starve to death by inertia
  • Don’t bother conducting feasibility studies
  • Never admit project is a failure
  • Over manage project managers and their team
  • Never ever conduct post-failure reviews
  • Never bother to understand project trade-offs
  • Allow political expediency and infighting dictate crucial project decisions
  • Make sure project is run by a weak leader

Success factors regarding the implementation of ICT investment projects (Milis & Mercken, 2002)

Montag, Juli 14th, 2008

ITC Implementation in Banks CSF

Milis, Koen; Mercken, Roger: Success factors regarding the implementation of ICT investment projects; in: International Journal of Production Economics, Vol. 80 (2002), No. 1, pp. 105-117.
http://dx.doi.org/10.1016/S0925-5273(02)00246-3

 

Milis & Mercken outline critical success factors for IT implementation projects in banks and insurances. They did a literature review and qualitative field research.The authors describe 49 critical success factors falling into the categories of

  • Project selection
  • Project definition
  • Project plan
  • Management involvement and support
  • Project team
  • Change management
  • Project resources
  • Managing relationships

Building on these findings, Milis & Mercken build a framework of 4 categories of success factors. (1) factors that enhance goal congruence, (2) factors that are related with the project team, (3) factors that influence the acceptance of the project, and (4) elements of implementation politics.

 

The first category combines factors that influence goal congruency:

  • Good selection & justification practice
  • Scope/objectives/goals: defined and agreed upon
  • Criteria for judging success: defined and agreed upon
  • Business alignment

The second category contains factors of team management/leadership:

  • Realistic but challenging goals
  • Urgency built in
  • Evaluation and reward mechanisms in place.Effective communication and conflict control
  • Complementary skills (technical & social)
  • Select team players to staff the project team
  • Select a competent and experienced project manager

The third category focuses on the acceptance of deliverables:

  • Definition of the authority and responsibilities
  • User participation.
  • Training
  • Top management support
  • Continuous evaluation and debate among the different parties involved
  • Powerful project manager with sufficient social skills

The fourth category deals with the implementation politics and planning:

  • Functional decomposition
  • Proper level of detail
  • Sufficient resources to execute the tasks planned
  • Resources for change management & contingency planning
  • Built in resource buffers

Are we any closer to the end? Escalation and the case of Taurus (Drummond, 1999)

Dienstag, Juli 8th, 2008

Taurus

Drummond, Helga: Are we any closer to the end? Escalation and the case of Taurus; in: International Journal of Project Management, Vol. 17 (1999), No. 1, pp. 11-16.
http://dx.doi.org/10.1016/S0263-7863(97)00074-4

The Taurus Project is a great case study. First of all it is a failed IT project. It took the project some 500 million GBP and 5 years to fail. And secondly it was a visionary project overhauling the IT of the London financial market. Drummond examines the route to failure. In this article she applies Escalation Theory aka Escalation of Commitment or the Vietnam War Syndrome as it was labelled in Freakonomics.

What did Drummond see? A destructive progression, i.e., one sub-optimal decision leading to another sub-optimal decision, that leading to another sub-optimal decision and so on. This effect was reinforced by an effect first found by Kahnemann & Tversky. They showed that gradual deterioration in a condition is usually underestimated and goes unnoticed. [Therefore addicts need an intervention]

What are the lessons learned?
Avoid the Garbage Can Effect. Don’t let the solution dictate the problem. Especialy if you have a keen vendor.
Make progress tangible. On Taurus experienced managers where struggling with controlling and managing the project because progress in IT systems‘ development can not be touched.
Engage in Second-Order Thinking. First-order thinking is solving the problem with the usual problem solving patterns, aka ‚more of the same‘. This does not help in deteriorating conditions. To break that vicious cycle second-order thinking is needed, which basically examines the assumptions of given decisions, plans, requirements, solutions.
And lastly balance power and responsibility. Politics and outside over steering destroyed the power and responsibility balance in this case. Project Managers had huge responsibilities but no decision power whatsoever to really solve the problem. Even if they saw recognised the problem and asked for project cancellation earlier than it was acknowledged by the project board.