Author Archive

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.

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

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

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

Preparing project managers to deal with complexity (Thomas & Mengel, 2008) and Preparing the mind for dynamic management (Hartman, 2008)

Dienstag, Oktober 7th, 2008

 Preparing project managers to deal with complexity (Thomas & Mengel, 2008) and Preparing the mind for dynamic management (Hartman, 2008)

Thomas, Janice; Mengel, Thomas: Preparing project managers to deal with complexity – Advanced project management education; in: International Journal of Project Management, Vol. 26 (2008), pp. 304-315.

Hartman, Francis: ; in: International Journal of Project Management, Vol. 26 (2008), pp. 258-267.

Complexity is a meme that just doesn’t want to die. I wrote before about articles on the foundamentals of complexity theory and project management, about the use of autonomous cells in project organisations and how they prevent complex project systems from failing, and the complex dynamics of project entities in a programme. Not surprisingly this meme has spread into the coaching and project management education world where there is some money to make of it.

Thomas & Mengel argue that the current project manager education is not suited at all to prepare for complex projects. The focus on standardisation, control, and hard systems thinking stands in direct opposition to the actuality of projects, which show high complexity in roles, high degrees of chaos and uncertainty.
Theoretically Thomas & Mengel base their discussion on three complexity/chaos theory concepts

  • Chaos theory – explaining the behaviour of dynamic and unstable systems
  • Dissipative structures – explaining moment of dynamic stability and instability
  • Complex adaptive systems – explaining behaviour of systems with a large number of independent agents, and organisational evolution and learning

So what does it take to be a Complex Project’s Manager?
Thomas & Mengel propose that understanding the complex environment is far more important than using tools and techniques of project management. Furthermore they outline three key capabilities to manage complexity

  • IQ – possessing the self-knowledge to adapt existing tools
  • EQ – possessing the emotional skills to coach and manage people
  • SQ – possessing the capacity for finding meaning

In their framework Thomas & Mengel see most of today’s project managers as Experts, these are project managers heavy on the IQ side of their IQ-EQ-SQ-Triangle. The authors see two developmental strategies. One is coping with uncertainty by moving towards the sense-making SQ corner of the triangle and becoming a Leader. The other developmental direction is coping with complexity by strengthening the EQ corner and becoming a Manager.

Similar ideas are discussed in the paper by Hartman. Altough he does not call the elephant on the table complex project management but he names it dynamic management. Blink or not Blink – Hartman argues that wisdom and intuition are the two desired qualities in a leader with a mind for dynamic management. Furthermore he identifies three traits absolutely necessary

  • Pattern recognition & decision-making
  • Relationship building & communication
  • Integrity & trust

From organising as projects to projects as organisations (van Donk & Molloy, 2008)

Dienstag, Oktober 7th, 2008

From organising as projects to projects as organisations (van Donk & Molloy, 2008)

van Donk, Dirk Pieter; Molloy, Eamonn: From organising as projects to projects as organisations; in: International Journal of Project Management, Vol. 26 (2008), No. 2, pp. 129-137.

van Donk & Molloy use two case studies to analyse the antecedents of a chosen project structure. Based on the work of Minzberg (1979) the authors identify five different forms of projects which can be mainly distinguished by their coordination mechanism

  • Simple structure → direct supervision
  • Machine bureaucracy → standardisation of processes
  • Professional bureaucracy → standardisation of skills
  • Divisionalised form → standardisation of outputs
  • Adhocracy → mutual adjustment

The authors identify which antecendents impact the choosen project structure

  • Age and size
  • Regulation and sophistication of the technical system
  • Environmental stability, complexity, market diversity, hostility
  • External control
  • Internal power

Multicriteria cash-flow modeling and project value-multiples for two-stage project valuation (Jiménez & Pascual, 2008)

Dienstag, Oktober 7th, 2008

 Multicriteria cash-flow modeling and project value-multiples for two-stage project valuation (Jiménez & Pascual, 2008)

Jiménez, Luis González; Pascual, Luis Blanco: Multicriteria cash-flow modeling and project value-multiples for two-stage project valuation; in: International Journal of Project Management, Vol. 26 (2008), No. 2, pp. 185-194.

I am not the expert in financial engineering, though I built my fair share of business cases and models for all sorts of projects and endeavours. I always thought of myself as being not to bad at estimating and modelling impacts and costs, but I never had a deep knowledge of valuation tools and techniques. A colleague was claiming once that every business case has to work on paper with a pocket calculator in your hands. Otherwise it is way to complicated. Anyhow, I do understand the importance of a proper NPV calculation, to say the least even if you do fancy shmancy real options evaluation as in this article here, the NPV is one of the key inputs.

Jiménez & Pascual identify three common approaches to project valuation NPV, real options, and payback period calculations. Their article focusses on NPV calculation. They argue that a NPV calculation consists of multiple cash flow components and each of these has different underlying assumptions, as to it’s risk, value, and return.

The authors start with the general formula for a NPV calculation
NPV = V0 = -I0 + ∑Qi ∏e-rk = -I0 + ∑Q e-∑rk
This formula also gives the internal rate of return (IIR) if V0=0 and the profitability index (PI) is defined as PI = V0/I0. Furthermore Jiménez & Pascual outline two different approaches on how to model the expected net cash flow Qi either as cash flow Qi = ∑qj,i or as value based period gj,k = ln (qj,k/qj,k-1).

The next question is how to model future values of the cash flow without adjusting your assumptions for each and every period. The article’s authors suggest four different methods [the article features a full length explanation and numerical example for each of these]

  • Cash Flow = Cash Flow + independent variable
  • Cash Flow = Cash Flow + function of the cash flow
  • Cash Flow = Function of a stock magnitude
  • Cash Flow = Change in stock magnitude

Finally the authors add three different scenarios under which the model is tested and they also show the managerial implications of the outcome of each of these scenarios

  • Ratios, such as operating cost and expenses (OPCE) to turnover (T/O), labour costs to T/O, depreciation to TIO, not fixed assets to T/O, W/C to T/O
  • Valuation multiples, such as Sales, Ebitda
  • Financing structure, such as short term, long term debt, after tax interests

Embedding projects in multiple contexts – a structuration perspective (Manning, 2008)

Freitag, Oktober 3rd, 2008

Embedding projects in multiple contexts – a structuration perspective (Manning, 2008)

Manning, Stephan: Embedding projects in multiple contexts – a structuration perspective; in: International Journal of Project Management, Vol. 26 (2008), No. 1, pp. 30-37.

Manning argues that projects are embedded in multiple contexts at the same time. These context facilitate and constrain the project at the same time and dynamically he describes this as „projects partly evolve in idiosyncratic ways as temporary systems, embedding needs to be understood as a continuous process linking projects to their environments“ (p.30).

Manning bases his analysis on Structuration Theory. It’s premise is to analyse action and structure (to interdependent concepts) in practice. Structuration Theory is defined by three key concepts – (1) structure, (2) actors, and (3) reflexive monitoring.

Structure is the set of symbolic and normative rules found in organisations. Furthermore the structure is set by authoritative and allocative resources. Actors are defined as potentially powerful and knowledgeable agents, who apply rules and resources in interactions, thus impacting the flow of events. As such structure impacts actions, which in turn impacts the structure. Reflexive monitoring is exactly this feedback loop from action to structure.

Applying structuration theory to projects Manning builds the concept of the project as temporary organisation, which is characertised by its tasks (=specification), times (=constraints), and teams (=relations). The author furthermore notices a constant process of disembedding and re-embedding into different contexts.

Which contexts are there? Manning identfies three. (1) organisations which are the collecitve actors engagned in coordinating projects, (2) interorganisational networks which are relations of legally independent organisations, and (3) organisation fields which are areas of institutional life by organisations and their members. Projects are embedded in all three of these contexts at the same time.

Lastly, Manning describes two embedding and re-embedding activities. Enactment of social contexts takes place top-down, that is from organisation fields –> interorganisational networks –> organisations –> projects, whereas the reproduction of social contexts takes place bottowm up.

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.

Perceptions of the impact of project sponsorship practices on project success (Bryde, 2008)

Freitag, Oktober 3rd, 2008

 Perceptions of the impact of project sponsorship practices on project success

Bryde, David: Perceptions of the impact of project sponsorship practices on project success; in: International Journal of Project Management, in press.

Bryde investigates in this article the question which impact on the project stakeholder practice has.
The impact on the project is simply measured as perceived performance score of the project. The different practices are operationalised in three factors (with items sorted according to their factor loading)

  • External focus
    • Responsible for defining benefits and requirements
    • Take delivery at completion
    • Establish strategy, set priorities
    • Define success criteria
    • Define project and objectives
    • Monitor benefits
  • Internal focus = supporting
    • Create an environment for projects to succeed
    • Make senior management commitment
    • Give training when necessary
  • Internal/external focus = championing
    • Cancel project if appropriate
    • Champion project, make resources available
    • Monitor business environment

Finally Bryde uses a stepwise regression to quantify the impact of each factor on the perceived project success score. Resulting in a two factor model where ‚External focus‘ (standardised β = 0.373) and ‚Internal focus‘ (standardised β = 0.268) impact the project success. Adjusted R2 is 0.326.

Unfortunately in this article the performance is just scored up although a multi-item measurement exists, factor analysis has not been employed. Furthermore the article does not detail the consistency of scale neither for the antecendents nor consequence (Cronbach’s Alpha) and does not test for heteroscedasticy or distribution. Thus this article falls short in advancing the development of a multi-item measurement of project success from a stakeholder point of view. 

The effectiveness in managing a group of multiple projects: Factors of influence and measurement criteria (Patanakul & Milosevic, in press)

Freitag, Oktober 3rd, 2008

The effectiveness in managing a group of multiple projects: Factors of influence and measurement criteria (Patanakul & Milosevic, in press)Patanakul, Peerasit; Milosevic, Dragan: The effectiveness in managing a group of multiple projects: Factors of influence and measurement criteria; in: International Journal of Project Management, in press, corrected proof. This article has been published inInternational Journal of Project Management, Vol. 27 (2009), pp. 216–233. Multi-project management. I covered a similar topic yesterday looking at it from a Complexity Theory viewpoint. The authors argue that multi-project management is increasingly used in the industry mainly for reasons of better utilisation. [Having worked as a multi-project manager for marketing projects back in the old days, I don’t know if that is really true. My projects always culminated in a week with crazy workload, followed by dry spells, where I bored myself to death.]Patanakul & Milosevic analyse the critical success factors for managing multi-projects from a ‚bundle of projects‘-perspective, i.e., by interviewing a multi-project manager and his/her supervisor. Thus they build six case studies of organisations using multi-project-management. Accordingly the authors define multi-project as the middle state in the project continuum, where single projects are on one end, and programmes are on the other end of the scale.What do Patankul & Milosevic find? The antecedents of multi-project management effectiveness are

  • Organisational field
    • Project assignments
      • Projects‘ strategic importance
      • Required fit to managers‘ competencies
      • Organisational & personal limitations
    • Resource allocation
      • Sufficient resource allocation
      • Sustainable resource allocation
    • Organisational culture
      • Commitment
      • Communication
      • Teamwork
      • Rewards
  • Operational field
    • Project management processes
      • Individual processes
      • Inter-project processes
      • Interdependency management
    • Competencies of the multi-project manager
      • Competencies for leading individual projects
      • Competencies for coordinating between projects

Finally the authors identify the consequences of multi-project management effectiveness as

  • Organisation
    • Resource productivity
    • Organisational learning
  • Project
    • Time-to-Market
    • Customer satisfaction
  • Personal
    • Personal growth
    • Personal satisfaction

Integrating diverse knowledge through boundary spanning processes – The case of multidisciplinary project teams (Ratcheva, in press)

Freitag, Oktober 3rd, 2008

Integrating diverse knowledge through boundary spanning processes – The case of multidisciplinary project teams (Ratcheva, in press)

Ratcheva, Violina: Integrating diverse knowledge through boundary spanning processes – The case of multidisciplinary project teams; in: International Journal of Project Management, in press, corrected proof.

The author argues that diverse, multi-disciplinary teams have knowledge boundaries which make information sharing difficult. An issue even more difficult if the team is geographically separated.

Ratcheva conceptualises the diverse project team as being embedded in the macro environment and organisational environment. The team itself is characterised at its starting point by three factors – (1) interpersonal, interactions & relational capital, (2) knowledge diversity, and (3) establishing workpractice. These three factors influence each other. Starting with this diverse team context or setting the team goes on to integrate it’s knowledge which ultimately leads to a project outcome.

Which knowledge boundaries exist in such a project team? Ratcheva identifies three different knowledge domains and at the edge of these knowledge boundaries. First of all there is the project team, surrounded by it’s projectation boundary, outside this boundary lies the occupational knowledge. Which simply means that each project team member is rooted in a broader knowledge of his profession which goes beyond the boundaries of the current project.
Secondly, the team has contextual knowledge which is confined by the project knowledge boundary. Thirdly, the broader project relevant knowledge lies inside the project’s social boundary.

How does the concept look like in motion? Which boundary spanning activities does the team perform? Ratcheva describes a four step process which combines all knowledge related and boundary spanning activities.

  1. The project core team works on the project, solves problems and issues = understanding occupational knowledge, and realising and spanning the projectation boundary
  2. The team understands the context knowledge, e.g., customer needs, stakeholder requirements = realising and spanning the project knowledge boundary
  3. The team understands  it’s personal diversity, thus understanding which personal knowledge is project relevant knowledge = realising and spanning the project social boundary
  4. The team integrates all knowledge, a knowledge which then feeds back into the first step

Construction client multi-projects – A complex adaptive systems perspective (Aritua et al., in press)

Donnerstag, Oktober 2nd, 2008

 Construction client multi-projects – A complex adaptive systems perspective

Aritua, Bernard; Smith, Nigel J.; Bower, Denise: ; in: International Journal of Project Management, Article in Press, Corrected Proof.

The meme of Complexity Theory is unstoppable in recent project management research. On the other hand it does make sense. Research such as this and, of course, common sense, indicate that the project’s context is a field better not left unmanaged. Since reality is quite complex  and peoples‘ behaviour is anyway – a view like this increases the pre-existing complexity of projects management.

In this article Aritua et al. analyse the special complexity which presents itself in multi-project environments. I posted about complexity theory before and in more detail here.
A quick recap. Complexity theory has 6 distinctive features, which make the outcomes of decisions, actions, and events increasingly unpredictable

  • Inter-relationships
  • Adaptability
  • Self-organisation
  • Emergence
  • Feedback
  • Non-linearity

Aritua et al. model the multi-project environment as being two-fold – (1) strategic environment and (2) tactical environment. The strategic environment builds the business context for the projects, programmes, or portfolio. The authors conceptualise the typical strategic cycle as consisting of vision – mission- strategic blueprint & objectives.

The tactical environment is the project portfolio/programme itself. Consisting of a couple of projects, it does provide a Risk:Value ratio for each project, which leads to an overall risk:value ration for the whole portfolio/programme, as such it feeds back into the strategic cycle in the business context environment.

In a second step the authors analyse the dynamics of such a system – what happens to a mulit-project portfolio if its external environment changes?
First of all, the boundary spanning activity in this conceptualisation is the information exchange with the environment. The information exchange into and out of the project portfolio triggers dynamics inside and between each project. Self-organising local relationships emerge into complex adaptive behaviour which feeds back, positively or negatively into the self-organising relationships. Huh?

Firstly, the project portfolio/programme is a complex system and therefore adapts itself when the environment changes. The one and only pre-requisite for this is, as the authors argue, that information and feedback freely flows inside, into, and out of the system.

Secondly, the self-organising relationships simply imply that individual components of the system affect each other and influence behaviour and actions. That is no project in a portfolio is independent from others. The authors cite the ant colony example, where ants make individual decision based on decisions by their closest neighbours. Thus complex interaction emerges.

Thirdly, self-organisation is the driving force behind creating stability in this open system. As the authors put it: „This aspect of the relationship between complexity theory and multi-project management would imply that programme managers and portfolio managers should not be bogged down with detail and should allow and enable competent project managers to act more creatively and on their own. This understanding also influences multi-project managers to seek a balance between trusting project managers and allowing them to concentrate on details – on the one hand – while seeking the necessary level of control and accountability.“

Fourthly, emergence is the effect that the group behaviour is more than the sum of behaviours of each individual project. Which implies, that risk and value can better be managed and balanced in a portfolio. On the flipside non-linearity shows that small changes in the system have unpredictable outcomes, which might be quite large. Thus management tools which don’t rely on non-linearity are needed. Moreover „it also emphasises the need for the multi-project management to react to the changing business environment to keep the strategic objectives at the fore while providing relative stability for the delivery of individual projects“.

So what shall the manager of a programme/portfolio do?

  • Find a right balance between control and freedom for the individual projects (self-organisation)
  • Enable information flow between the environment and the projects, as well as in between the projects (adaptability)
  • Adapt strategic objectives, while stabilising project deliveries (feedback)
  • Balance risk and value in the portfolio (emergence)
  • Use non-linear management tools (non-linearity), such as AHP, Outranking, mental modelling & simulation

Project management standards – Diffusion and application in Germany and Switzerland (Ahlemann et al., in press)

Dienstag, September 30th, 2008

 roject management standards – Diffusion and application in Germany and SwitzerlandAhlemann, Frederik; Teuteberg, Frank; Vogelsang, Kristin: Project management standards – Diffusion and application in Germany and Switzerland; in: International Journal of Project Management, Article in Press, Corrected Proof. This article has been published in: International Journal of Project Management, Vol. 27 (2009), No. 3, pp. 292–303. This article discusses the use of standards and reasons behind that in detail. Instead of going in to these details I want to quickly focus on the more interesting aspects of this article, with three simple questions (1) Which standards do exist in the industry?, (2) What are the benefits of using them?, and (3) What holds us back?The standards used, and as such included in this survey, were

  • DIN 69901 – 69905
  • IPMA’s (International Project Management Association) International Competence Baseline (ICB)
  • ICB’s German cousin the PM-Fachmann, and PM-Kanon
  • ISO 10006
  • OPM3
  • Kerzner’s Project Management Maturity Model (PMMM)

What are the benefits of implementing and using a project management standards?

Better communication/consistent terminology Project stakeholders are able to communicate about project management aspects without friction. They experience that communication about project management issues becomes easier when there is a shared understanding of fundamental project management terms as expressed in a standard
Faster process implementation (Compliant) project management processes can be planned and introduced faster than without a standard
Better process quality Higher quality in terms of cycle times, process failures and achievement of objectives
Transfer of knowledge and best practices Improvements of project management competencies
Better recognition by customers/marketing effects Compliance as a cue of high project management competence for external stakeholders
Cost savings Costs reductions for setting up and running the project management system
Better team play More efficient project teams with better project results
Comparability with other internal organizational units Standards allow benchmarking/comparisons of processes and results with other internal organisational units
Comparability with other external organizational units Standards allow benchmarking/comparisons of processes and results with other external organisational units

What holds us back in implementing project management standards in practice?

Too theoretical Standards are highly abstract and theoretical, such it cannot be understood easily and applied efficiently
Lack of flexibility Standard not flexible enough for the requirements of a specific organization. Adaptation is either not foreseen or only hard to achieve
Not applicable to the specific implementation scenario Standard is generally not applicable since its premises do not match the characteristics of the affected organisation
Costs of change The costs of implementing the standard are too high
Administrational overheads The operation requires too high administrative overhead
Lack of acceptance The standard is not sufficiently accepted by staff members
Inefficient processes/practices Standard requires inefficient processes or practices. Instead of improving process performance, cycle times and process costs rise

The empirical results of this survey show that PMBOK is the most widely used standard in the sample. The second most commonly used standard is the ICB. Whereby the standard is rarely (in only 11% of cases) used as-is. Instead it is mostly adapted to the organisation or used as a pool of ideas.Secondly the list of benefits was tested against expectations before implementing standards and the captured benefits after the implementation. Expected benefits were

  • Improvement of communication regarding project management issues
  • Better process quality
  • Faster implementation of project management processes
  • Implementation of best practices

Of all benefits tested only the improvement of communications was taking place after implementing the standard.The authors identify lack of flexibility and adaptability as the major shortfall of standards. The main reasons for not applying a standard were

  • High administrative overhead
  • Lack of user acceptance
  • High costs

Investigating the use of the stakeholder notion in project management literature, a meta-analysis (Vos & Achterkamp, in press)

Dienstag, September 30th, 2008

 Investigating the use of the stakeholder notion in project management literature, a meta-analysis (Vos & Achterkamp, in press)

Achterkamp, Marjolein C.; Vos, Janita F.J.: Investigating the use of the stakeholder notion in project management literature, a meta-analysis; in: International Journal of Project Management, Article in Press, Corrected Proof.

Managing the stakeholders is an, if not the most, important part of the project manager’s job. Previously Vos & Achterkamp published articles focussed on the identification of stakeholders, which is a crucial and not so simple task.“Basic, but not trivial“, as one of my Economics professors always used to say.

In this article, however, Vos & Achterkamp reviewed 42 articles in terms of

  • Definition of stakeholders
  • Purpose of stakeholder notion
  • Identification issues
  • Role of stakeholders

Analysing the commonly used definitions of stakeholders the authors identify two key theoretically based definitions – stakeholders could either be persons with an interest in the project, or persons who can or are affected by the project. One or both of these two definitions are used in only 16.6% of articles reviewed, the remaining articles mainly deal with this topic without defining the object stakeholder at all.

Why look at stakeholders? The purpose of the stakeholder notion is first and foremost to sense-making and defining success. Further purposes of stakeholder management are risk management, use as source of information, and using stakeholders as a management instrument.

The review of the identification issue, a topic close to the authors, shows that most articles only recognise the issue, or explain it partly. Only a minority of 4 articles (out of 42) recognises and explains the issue.

Lastly Vos & Achterkamp review the roles of stakeholders. For reasons of not only simplifying complexity down to a managable level, but also for overcoming issues of stakeholder identification stakeholders the authors suggest an explicit, structured, role-based identificiation procedure. Whilst they acknowledge that stakeholder salience model, as discussed in this earlier post, is the leading theoretical model of identifying stakeholder; the authors argue that the role-based stakeholder classification model for innovative projects is more promising.

„Considering stakeholders in terms of roles of involvement in the context of projects then raises the question of whether there is anything new. Indeed, thinking in terms of roles is not new in project management. Could project roles perhaps be used for stakeholder identification?“ (p. 4)

Vos & Achterkamp review three articles in detail, which use a role-based stakeholder classification model. These three articles define the following roles

  • Callan et al. (2008)
    • Controller
    • Executer
    • Constraining advisor
    • Discretionary advisor
  • Turner (2008)
    • Manager
    • Steward
    • Owner
    • User
    • Sponsor
    • Broker
    • Resources
  • Vos & Achterkamp (2006)
    • Client
    • Decision maker
    • Designer
    • Passively involved

Resource allocation under uncertainty in a multi-project matrix environment: Is organizational conflict inevitable? (Laslo & Goldberg, in press)

Mittwoch, September 24th, 2008

Resource allocation under uncertainty in a multi-project matrix environment: Is organizational conflict inevitable?

Laslo, Zohar; Goldberg, Albert I.: Resource allocation under uncertainty in a multi-project matrix environment: Is organizational conflict inevitable?; in: International Journal of Project Management, Article in Press (2008).

Laslo & Goldberg investigate the conflicts associated with resource allocation. They find that the matrix structure has become the organisational from to go for, when it comes to efficiently managing a multi-project firm. Unfortunately the matrix structure has been criticised (see the PMBOK Guide) to inherently spark conflicts between line and project managers about resources. In a mulit-project firm, the authors conclude, this drawback is even worsened by the resource allocation fights between projects.

In order to model the problem Laslo & Goldberg analyse the three most common resource allocation policies, which are (1) Profit & Cost Centres (PC), (2) Comprehensive Allocation Planning (CA), and (3) Directed Priorities (DP). Profit & cost centre are synonymous with the maximum project autonomy. In comprehensive allocation planning each inidvidual project is only part of an organisation wide optimisation of resource allocation. Thirdly, in the policy of directed priorities, projects whose objectives are closer to the organisation’s strategic goals receive addtional resources/funding.

As often claimed 3 types of conflict are inherent in the matrix structure, when managers would fight for the right policy.
(1) DP vs. PC – internal Project would favour DP, whilst sponsored projects and functional units favouring PC
(2) PC vs. CA – functional units favouring PC, whilst sponsored and internal projects favour CA
(3) DP vs. CA – internal projects and functional units favour DP, whilst sponsored project favour CA

Using Foster’s theory of systems dynamics, the authors model these conflicts as a resource flow. The model contains feedback loops to model information flow into planning and runs several what if simulations.
In order to simulate with the model three organisational objectives are defined
a) Minimise delay losses (conflict DP vs. CA)
b) Minimise direct labour costs (favouring CA policy)
c) Minimise functional unit total costs (favouring PC)

As the authors put it: „Findings from the simulation suggest that not all conflict is realistic. For some project objectives, higher organizational performance can be achieved when managers learn that they have no basic differences in real interests and they can agree upon a resource allocation policy.“ That said, the results also show, that alliances between functional managers, internal venture project managers, and sponsored project managers are unstable. If resource scarcity comes into the equation, e.g, if resources can not be obtained externally, conflicts arise for sure.

Foundations of program management: A bibliometric view (Artto et al., in press)

Dienstag, September 23rd, 2008

Foundations of program management: A bibliometric view (Artto et al., in press)Artto, Karlos; Martinsuo, Miia; Gemünden, Hans Georg; Murtoaro, Jarkko: Foundations of program management – A bibliometric view; in: International Journal of Project Management, Article in Press, Corrected Proof The article has been published in International Journal of Project Management, Vol. 27 (2009), No. 1, pp. 1–18. Artto et al. investigate the big question if programme management is much more than project management on a large scale. The authors review 517 programme management articles, 1164 project management articles from 21 years. They look into the various foundations of programme management research such as the level of analysis (organisation and its major parts), object of analysis (change of permanent organisation), outcomes of programmes (ambiguity & long-term impacts). Artto et al. also conclude that programmes might be similar to projects, that both management practices share common concepts, but that programmes should not be treated as scaled-up projects.Some more detail is provided regarding the themes, theories, and system thinking behind programme management. The themes, which the authors identified in the literature, are the origins of programme management. They find that programme management has its roots in manufacturing, quality, work and organisational change, and product development. Moreover they do assess the change of focus in these themes – whereas the organisational change is dominant for programmes and new product development is the dominant theme for project management.What is the specific systems thinking regarding programmes? Programmes are usually conceptualised as open systems. [An approach more and more followed in project management research as well.] Furthermore innovation is a major concern of programmes. As such open systems are typically used to innovate processes, organisations, and infrastructure. In contrast innovation using closed systems is more dominant in product development, which subsequently employs more projects than programmes to innovate.Moreover the authors explore the theoretical basis of programme management. They found this research deeply rooted in organisational and strategy theories. Additional theories used to explore this concepts are product development, organisational change, manufacturing, quality, economic, industrial, and institutional theories.Lastly, Artto et al. identify shortcomings of existing research on programme management, which are

  • Ignorance of original theoretical roots of program and project management
  • Neglect of inter-project coordination
  • Neglect of inter-organizational issues and theories
  • Limited contingency view
  • Lack of industry-specific views
  • Neglect of the interplay between the permanent and the temporary organization

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.

Understanding time delay disputes in construction contracts (Iyer et al. 2008) & Delays in construction projects (Sweis et al., 2008)

Dienstag, September 23rd, 2008

Sources and categories of delay in construction

Iyer, K.C.; Chaphalkar, N.B.; Joshi, G.A.: Understanding time delay disputes in construction contracts; in: International Journal of Project Management, Vol. 26 (2008), No. 2, pp. 174-184.

Sweis, G.; Sweis, R.; Hammad, A. Abu; Shboul, A.: Delays in construction projects – The case of Jordan; in: International Journal of Project Management, Vol. 26 (2008), No. 6, pp. 665-674.

In my recent obsession with delays [it’s quite sarcastic, I know], I read through these two articles on delays in the construction industry.
Sweis et al. analyse sources of delays on construction projects. The authors identify three main categories contributing to delays –  internal environment, exogenous factors, and input factors.
Internal environmental factors are financial difficulties, poor planning & scheduling, and too many change orders. Exogenous factors found are severe weather and changes in government or regulation laws. The input factor causing delay was a shortage of manpower.

In the second article Iyer et al. look into the contractual strings attached to delays. Therefore they categorise delays in excusable vs. non-excusable. Excusable delays are

  • Labour disputes
  • Force majeure
  • Unusual delay in deliveries
  • Unavoidable delay
  • Unforseen delay in transportation
  • Other unforseeable causes

Non-excusable delays and therefore punishable by fines are

  • Ordinary weather
  • Subcontractor delay
  • Contractor’s failure to coordinate the project site
  • Contractor financing problems
  • Contractor failure to ramp-up
  • Delay in obtaining materials
  • Poor workmanship

[On how many IT projects have I seen non-excusable delays which were excused.]
Lastely, Iyer et al. identify the origins of disputed delays, they were due to

  • Handover on site
  • Release mobilisation advance
  • Late receipt/checking of drawings
  • Accidents
  • Temporary stoppage
  • Re-work
  • Extra work