Archive for the ‘IT Project’ Category

Success Factors in IT Projects (Fortune & White 2006 and Nasir & Sahibuddin 2011)

Donnerstag, Juli 26th, 2012

Fortune, J. & White, D., 2006. Framing of project critical success factors by a systems model. International Journal of Project Management, 24(1), pp.53-65. Available at:

Nasir, N.H.M. & Sahibuddin, S., 2011. Critical success factors for software projects : A comparative study. Scientific Research and Essays, 6(10), pp.2174-2186.

I have come across many bits of work in progress now that try to make a selection of what are the success factors in IT projects. Well, these two articles of note publish a fairly comprehensive literature review that spans the plethora of studies on this topic. Fortune & White reviewed 63 articles in total, Nasir & Sahibuddin 43. The first one includes also reviews of hard to find conference papers and case studies that have not made it on the web yet, so the details of some of these studies are hard to verify.

Here is a google spreadsheet with the key comparison between what are the success factors in both reviews ordered by the amount of evidence the authors found to support each factor.

Link to the spreadsheet

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.

Human Effort Dynamics and Schedule Risk Analysis (Barseghyan, 2009)

Dienstag, April 21st, 2009


Barseghyan, Pavel: Human Effort Dynamics and Schedule Risk Analysis; in:  PM World Today, Vol. 11(2009), No. 3.

Barseghyan researched extensively the human dynamics within project work.  He has formulated a system of intricate mathematics quite similar to Boyle’s law and the other gas laws.  He establishes a simple set of formulas to schedule the work of software developers.

T = Time, E = Effort, P = Productivity, S = Size, and D = Difficulty
Then W = E * P = T * P = S * D, and thus T = S*D/P

But and now it gets tricky S~D~P are correlated!

The author has collected enough data to show the typical curves between Difficulty –> Duration and Difficulty –> Productivity.  To schedule and synchronise two tasks the D/P ratio has to be constant between these two tasks.


Barseghyan then continues to explore the details between Difficulty and Duration.  He argues that the common notion of bell-shaped distributions is flawed because of the non linear relationship between Difficulty –> Duration  [note that his curves have a segment of linearity followed by some exponential part.  If the Difficulty bell curve is transformed into the Diffculty–>Duration probability function using that non-linear transformation formula it looses is normality and results in a fat-tail distribution.  Therefore Barseghyan argues, the notion of using bell-shaped curves in planning is wrong.  

Understanding software project risk – a cluster analysis (Wallace et al., 2004)

Mittwoch, Januar 14th, 2009


Wallace, Linda; Keil, Mark; Rai, Arun: Understanding software project risk – a cluster analysis; in: Information & Management, Vol. 42 (2004), pp. 115–125.

Wallace et al. conducted a survey among 507 software project managers worldwide.  They tested a vast set of risks and tried to group these risks into 3 clusters of projects: high, medium, and low risk projects. 

The authors assumed 6 dimensions of software project risks –

  1. Team risk – turnover of staff, ramp-up time; lack of knowledge, cooperation, and motivation
  2. Organisational environment risk – politics, stability of organisation, management support
  3. Requirement risk – changes in requirements, incorrect and unclear requirements, and ambiguity
  4. Planning and control risk – unrealistic budgets, schedules; lack of visible milestones
  5. User risk – lack of user involvement, resistance by users
  6. Complexity risk – new technology, automating complex processes, tight coupling

Wallace et al. showed two interesting findings.  Firstly, the overall project risk is directly correlated to the project performance – the higher the risk the lower the performance!  Secondly, they found that even low risk projects have a high complexity risk.

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

Dienstag, Januar 13th, 2009


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

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

Dienstag, Januar 6th, 2009


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

Protecting Software Development Projects against Underestimation (Miranda & Abran, 2008)

Montag, November 3rd, 2008

Protecting Software Development Projects against Underestimation (Miranda & Abran, 2008)

Miranda, Eduardo; Abran, Alain: Protecting Software Development Projects Against Underestimation; in: Project Management Journal, Vol. 39, No. 3, 75–85.
DOI: 10.1002/pmj.20067

In this article Miranda & Abran argue „that project contingencies should be based on the amount it will take to recover from the underestimation, and not on the amount that would have been required had the project been adequately planned from the beginning, and that these funds should be administered at the portfolio level.“

Thus they propose delay funds instead of contingencies. The amount of that fund depends on the magnitude of recovery needed (u) and the time of recovery (t).  t and u are described using a PERT-like model of triangular probability distribution, based on a best, most-likely, and worst case estimation.

The authors argue that typically in a software development three effects occur that lead to underestimation of contingencies. These three effects are (1) MAIMS behaviour, (2) use of contingencies, (3) delay.
MAIMS stands for ‚money allocated is money spent‘ – which means that cost overruns usually can not be offset by cost under-runs somewhere else in the project. The second effect is that contingency is mostly used to add resources to the project in order to keep the schedule. Thus contingencies are not used to correct underestimations of the project, i.e. most times the plan remains unchanged until all hope is lost. The third effect is that delay is an important cost driver, but delay is only acknowledged as late as somehow possible. This is mostly due to the facts of wishful thinking and inaction inertia on the project management side.

Tom DeMarco proposed a simple square root formula to express that staff added to a late project makes it even later. In this paper Miranda & Abran break this idea down into several categories to better estimate these effects.

In their model the project runs through three phases after delay occurred:

  1. Time between the actual occurence of the delay and when the delay is decided-upon
  2. Additional resources are being ramped-up
  3. Additional resources are fully productive

During this time the whole contingency needed can be broken down into five categories:

  1. Budgeted effort, which would occur anyway with delay or not = FTE * Recovery time as orginally planned
  2. Overtime effort, which is the overtime worked of the original staff after the delay is decided-upon
  3. Additional effort by additional staff, with a ramp-up phase
  4. Overtime contibuted by the additonal staff
  5. Process losses du to ramp-up, coaching, communication by orginal staff to the addtional staff

Their model also includes fatigue effects which reduce the overtime worked on the project, with the duration of that overtime-is-needed-period. Finally the authors give a numerical example.

Making a difference? Evaluating an innovative approach to the project management Centre of Excellence in a UK government department (O’Leary & Williams, 2008)

Donnerstag, Oktober 23rd, 2008

Making a difference? Evaluating an innovative approach to the project management Centre of Excellence in a UK government department (O’Leary & Williams, 2008)

O’Leary, Tim; Williams, Terry: Making a difference? Evaluating an innovative approach to the project management Centre of Excellence in a UK government department; in: International Journal of Project Management, Vol. 26 (2008), No. 5, pp. 556-565.

The UK has rolled out the ambitious programme of setting-up IT Centres of Excellence in all its departments. Focal point of these Centres of Excellence are Programme Offices.

The role of these Programme Offices has been defined as: Reporting, Recovering & Standardising.
The objectives for the programme offices are monitoring and reporting the status of the IT initiatives in the department, and implementing a structured life cycle methodology. This methodology ties in with a stage-gate framework that needs to be introduced. Additionally hit-teams of delivery managers have been set-up to turn-around ailing projects.

O’Leary and Williams find that the interventions seem to work successfully, whereas the reporting and standardisation objective has yet to be fulfilled. Moreover the authors analyse the root causes for this success. They found that the basis of success was:

  • Administrative control of department’s IT budget
  • Leadership of IT director
  • Exploitation of project management rhetoric
  • Quality of delivery managers

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.

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.

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
  • Requirements specification
  • Dyadic leadership
  • Group dynamics
  • Linked dyadic-group processes
  • Technical difficulties
  • Re-prioritisation
Management Leadership

Images as action instruments in complex projects (Taxén & Lilliesköld, 2008)

Montag, Oktober 20th, 2008

Images as action instruments in complex projects (Taxén & Lilliesköld, 2008)

Taxén, Lars; Lilliesköld, Joakim: Images as action instruments in complex projects; in: International Journal of Project Management, Vol. 26 (2008), No. 5, pp. 527-536.

Images are quite powerful. I hate motivational posters which a distant corporate HQ decorates every meeting room with, but I once saw the department strategy visualised by these folks, they include all employees and the group dynamic is unbelievable. Later on they cleaned the images, blew them up, and posted them around the company – of course, meaningless for an outsider but a powerful reminder for everyone who took part.

Taxén & Lilliesköld analyse the images typically used in project management. They find that these common images, such as PERT/CPM, Gantt charts, or WBS are increasingly difficult to use in complex projects, in this case the authors look into a large-scale IT project.

Based on Activity Domain Theory they develop alternative images better suited for complex projects. Activity Domain Theory, however, underlines that all tasks on a project (= each activity domain) have a motive, fulfils needs, modifies objects, and has actors. Outcomes are produced by activity domains and are at the same time prerequisites for activity domains. Activity domains have activity modalities, which can be either manifested as resources or as communal meaning. These activity modalities are

  • Contextualisation = situation of human action
  • Spatialisation = need for spatial orientation in human action
  • Temporalisation = need for certain order in human action
  • Stabilisation = need for certain rules and norms in human action
  • Transition = need for interaction between activity domains

Useful images, the authors argue, need to fulfil these needs while being situated in the context of the activity. Traditional images focus on optimisation and control, rather than on coordination and action. Thus alternate images need to focus on dependencies and integration; on value comprehensibility and informality over formality and rigour.

Alternative images suited for complex project management are

  • Anatomies – showing modules, work packages and their dependencies of the finished product, e.g., functional node diagrams
  • Dependency diagrams – showing the incremental assembly of the product over a couple of releases, e.g. increment plan based on dependencies (a feature WBS lack)
  • Release matrices – showing the flow of releases, how they fit together, and when which functionality becomes available, e.g., integration plan
  • Information flow diagrams – showing the interfaces between modules, e.g. DFD

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

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

Project management approaches for dynamic environments (Collyer, 2009)

Donnerstag, Oktober 9th, 2008

 Project management approaches for dynamic environments (Collyer, in press)Collyer, Simon: Project management approaches for dynamic environments; in: International Journal of Project Management, in press (2008). this article has been published in: International Journal of Project Management, Vol. 27 (2009), No. 4, pp. 355-364. There it is again: Complexity, this time under the name of Dynamic Project Environments. I admit that link is a bit of a stretch. Complexity has been described as situations, where inputs generate surprising outputs. Collyer on the other hand focuses special project management strategies to succeed in changing environments. The author’s example is the IT project, which inherently bears a very special dynamic.He discusses eight different approaches to cope with dynamics. (1) Environment manipulation, which is the attempt to transform a dynamic environment into a static environment. Examples commonly employed are design freezes, extending a systems life time, and leapfrogging or delaying new technology deployment.(2) Planning for dynamic environments. Collyer draws a framework where he classifies projects on two dimensions. Firstly, if their methods are well defined or not, and secondly if the goals are well defined or not. For example he classifies the System Development project as ill-defined and ill-defined. This is a point you could argue about, because some people claim that IT projects usually have well-defined methodologies, but lack clear goals. Collyer suggest scaling down planning. Plan milestones according to project lifecycle stages, and detail when you get there. He recommends spending more time on RACI-matrices than on detailed plans.(3) Control scope, which is quite the obivious thing to try to achieve – Collyer recommends to always cut the project stages along the scope and make the smallest possible scope the first release.(4) Controlled experimentation. The author suggest that experimentation supports sense-making in a dynamic environment. Typical examples for experimentation are prototyping (Collyer recommends to always develop more than one prototype), feasibility studies, and proofs of concept.(5) Lifecycle strategies, although bearing similarities to the scope control approaches he proposes this strategy deals with applying RuP and agile development methods, to accelerate the adaptability of the project in changing environments.(6) Managment control, as discussed earlier in this post every project uses a mix of different control techniques. Collyer suggest deviating from the classical project management approach of controlling behaviour by supervision, in favour for using more input control, for example training to ensure only the best resources are selected. Besides input control Collyer recommend on focussing on output control as well, making output measurable and rewarding performance.Collyer also discusses a second control framework, which distinguishes control by the abstract management principle. Such as diagnostic control (=formal feedback), control of beliefs (=mission, values), control of interactions (=having strategic, data-based discussions), and boundary control (=defining codes of conduct).Lastly the author discusses two more approaches to succeeding with dynamic environments which are (7) Categorisation and adaptation of standards and (8) Leadership style.

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

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.

A comprehensive model for selecting information system project under fuzzy environment (Chen & Cheng, in press)

Dienstag, Oktober 7th, 2008

A comprehensive model for selecting information system project under fuzzy environment (Chen & Cheng, in press)Chen, Chen-Tung; Cheng, Hui-Ling: A comprehensive model for selecting information system project under fuzzy environment; in: International Journal of Project Management, in press.doi:10.1016/j.ijproman.2008.04.001Update: this article has been published in:  International Journal of Project Management Vol. 27 (2009), No. 4, pp. 389–399.Upfront management is an ever growing body of research and currently develops into it’s own profession. In this article Chen & Cheng propose a model for the optimal IT project portfolio selection. They outline a seven step process from the IT/IS/ITC project proposal to the enterprise success

  1. IS/IT/ITC project proposal
  2. Project type classification
  3. Individual project analysis
  4. Optimal portfolio selection
  5. Portfolio adjustment
  6. Successfully selection
  7. Enterprise success

Behind the process are three different types of selection methods and tools – (1) crisp selection, (2) strategy development, and (3) fuzzy selection.The crisp selection is the first step in the project evaluation activities. It consists of different factual financial analyses, e.g. analysis of discounted cash flow, cost-benefits, total investment, payback period, and the return on investment.Strategy development is the step after the crisp selection, whilst it also impacts the first selection step by setting guidelines on how to evaluate the project crisply. Strategy development consists of a project strategic status analysis. According to Chen & Cheng’s framework a project falls in one of four categories – strategic, turnaround, factory, or support.The last step is the fuzzy selection. In this step typical qualitative characteristics of a project are evaluated, e.g., risk, feasibility, suitability, and productivity improvements. In this step lies the novelty of Chen & Cheng’s approach. They let the evaluators assign a linguistic variable for rating, e.g., from good to poor. Then each variable is translated into a numerical value, e.g., poor = 0, good = 10. As such, every evaluator produces a vector of ratings for each project, e.g., (0;5;7;2) – vector length depends on the number of characteristics evaluated. These vectors are then aggregated and normalised.[The article also covers an in-depth numerical example for this proposed method.]

Organisational control in programme teams – An empirical study in change programme context (Nieminen & Lehtonen, 2008)

Freitag, Oktober 3rd, 2008

 Organisational control in programme teams - An empirical study in change programme context

Nieminen, Anu; Lehtonen, Mikko: Organisational control in programme teams – An empirical study in change programme context; in: International Journal of Project Management, Vol. 26 (2008), No. 1, pp. 63-72.

Nieminen & Lehtonen search for control mechanisms and modes in organisational change programmes. Therefore the authors investigated four cases of organisational change programmes with a significant share of IT in them. Overall they identified 23 control mechanisms, which are used complimentary rather than exclusively.

The identified control mechanisms fall into three basic categories – (1) Bureaucratic Control, (2) Clan Control, and (3) Self Control. For each of these Nieminen & Lehtonen describe the focus, basis, and mechanisms of control.

Bureaucratic Control focuses on performance, i.e., behaviour, and outcomes, i.e., results and actions. The basis of bureaucratic control are rules and surveillance. Mechanisms typically employed are boundary and diagnostic mechanisms.

Clan Control focusses on socialisation, i.e., values, attitudes, and beliefs. The basis of clan control are interactions, values, and norms. Mechanisms typically employed are belief mechanisms, interactive mechanisms, and team control.

Self Control focusses on self-regulation, i.e., own actions vs. perceived organisational goals. It is based on self-monitoring and typically useses autonomoy as control mechanism.

In their empirical study Nieminen & Lehtonen find that a broad mix of control mechanisms is found in any programme, though significant differences exist between programmes. Furthermore the level of self-control seems to be positively related to other control mechanisms. Lastely the authors show that the physical environment strongly impacts the control mechanisms.

In their managerial implications Nieminen & Lehtonen conclude, that although ease of implementation is lowest for bureaucratic control – environments with ambigous goals need mechanisms of clan- and self-control.

Enterprise information system project selection with regard to BOCR (Liang & Li, in press)

Dienstag, September 23rd, 2008

 Enterprise information system project selection with regard to BOCR (Liang & Li, in press)

Liang, Chao; Li, Qing: Enterprise information system project selection with regard to BOCR; in: International Journal of Project Management, Article in Press, Corrected Proof

Lots of consultants earn their money with selecting the right IT system. I have seen the most bizarre total-cost-of-ownership (TOC) calculations to get to it and witnessed the political madness which comes with buying-center decisions in never ending rounds of assessment workshops.

Liang & Li claim that „a comprehensive and systematic assessment is necessary for executives to select the most suitable project from many alternatives.“ Furthermore they claim that „This paper first proposes a decision method for project selection.“ However, the authors apply a analytical hierarchy/network process (AHP/ANP) to this decision-making predicament. They suggest breaking down the decision unsing their mulit-criteria BOCR framework, with the dimensions of benefits (B), opportunities (O), costs (C), and risks (R).

In the case of an manufacturing system, described in that article, the benefits consist of time gained, costs saved, service improvements, capacity increase, and quality improvements. The opportunities are an increased market share, fast ROI and payback period, and the ability for agile manufacturing. The risks associated with this MES are budget overruns, time delays, and several technological risks, e.g., reliability, flexibility, ease of use. Lastly Liang & Li break down the costs into software, implementation, taining, maintenance, upgrade, and costs for existing systems.

The mechanisms of project management of software development (McBride, 2008)

Montag, September 22nd, 2008

The mechanisms of project management of software development

McBride, Tom: The mechanisms of project management of software development; in: Journal of Systems and Software, Article in Press.

McBride covers two aspects of tools and techniques for the management of software developments. Firstly the monitoring, secondly the control and thirdly the coordination mechanisms used in software development.

The author distinguishes four categories of monitoring tools: automatic, formal, ad hoc, and informal. The most common tools used are schedule tracking, team meeting, status report, management reviews, drill downs, conversations with the team and the customers.

The control mechanisms are categorised by their organisational form of control as either output, behaviour, input, or clan control. The most often used control mechanisms are Budget/schedule/functionality control, formal processes, project plan, team co-location, and informal communities.

Lastly the Coordination mechanisms are grouped by which way the try to coordinate the teams: standards, plans, formal and informal coordination mechanisms. The most common are specifications, schedule, test plans, team meetings, ad hoc meetings, co-location, and personal conversations.

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.