Archive for the ‘Critical Success Factors’ 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: http://linkinghub.elsevier.com/retrieve/pii/S0263786305000876.

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

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.

Decision Making Within Distributed Project Teams (Bourgault et al., 2008)

Montag, November 3rd, 2008

ecision Making Within Distributed Project Teams (Bourgault et al., 2008)

Bourgault, Mario; Drouin, Nathalie; Hamel, Émilie: Decision Making Within Distributed Project Teams – An Exploration of Formalization and Autonomy as Determinants of Success; in: Project Management Journal, Vol. 39 (2008), Supplement, pp. S97–S110.
DOI: 10.1002/pmj.20063

Bourgault et al. analyse group decision making in virtual teams. Their article is based on the principles of limited rationality, i.e. deciding is choosing from different alternatives, and responsible choice, i.e. deciding is anticipating outcomes of the decision.

Existing literature controversially discusses the effects of virtualising teams. Some authors argue that virtual teams lack social pressure and thus smaler likelihood of showing escalation of committment behaviour, whilst making more objective and faster decisions. Other authors find no difference in working style between virtual and non-virtual teams. Generally literature explains that decision-errors are mostly attributed to break-downs in rationality, which are caused by power and group dynamics. Social pressure in groups also prevents efficiency. In any team with distributed knowledge the leader must coordinate and channel the information flow.

Bourgault et al. conceptualise that Formalisation and Autonomy impact the quality of decision-making, which then influences the team work effectiveness. All this is moderated by the geographic dispersion of the team.
They argue that formalisation, which structures and controls the decision making activities, helps distributed teams to share information. Autonomy is a source of conflict, for example with higher management due to a lack of understanding and trust, ultimately it weakesn a project decision-making because it diverts horizontal information flow within the team to vertical information flow between project and management.
Quality of decision-making process – the authors argue that groups have more information resources and therefore can make better decisions, but this comes at an increased cost for decision-making. Geographical distributed teams lack signals and have difficulties in sharing information. Thus high quality teamwork benefits from more dispersed knowledge but low quality teamwork suffers from a lack of hands-on leadership.
Teamwork effectiveness – this construct has mostly been measured using satisfaction measurements and student samples. Other measures are the degree of taks completion, goal achievement, self-efficacy (intent to stay on the team, ability to cope, percieved individual performance, perceived team performance, satisfaction with the team). Bourgault et al. measure teamwork effectiveness asking for the perceived performance on taks completion, goal achievement, information sharing, conflict resolution, problem solving, and creating a prefereable and sustainable environment.

The authors‘ quantitative analysis shows that in moderated teams all direct and indirect effects can be substantiated, with exception of the autonomy influencing the quality of decision-making. Similarily in highly dispersed teams all direct and indirect effects, but the direct influence of formalisation on teamwork effectiveness, could be proven.

Bourgault et al. conclude with three points of recommendation for the praxis – (1) Distribution of a team contributes to high quality of decisions, although it seems to come at a high cost. (2) Autonomous teams achieve better decisions – „despite the fear of an out of sight out of control syndrome“. (3) Formalisation adds value to teamwork especially the more distributed the team is.

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.
http://dx.doi.org/10.1016/j.ijproman.2008.05.013

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

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.

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.http://dx.doi.org/10.1016/j.ijproman.2008.03.001Update: 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

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.
http://dx.doi.org/10.1016/j.ijproman.2008.02.005

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

Post-project reviews as a key project management competence (Anbari et al., 2008)

Mittwoch, September 17th, 2008

 Post-project reviews as a key project management competence

Anbari, Frank T.; Carayannis, Elias G.; Voetsch, Robert J.: Post-project reviews as a key project management competence; in: Technovation, Vol. 28 (2008), No. 10, pp. 633-643.
http://dx.doi.org/10.1016/j.technovation.2007.12.001

George Santayana was the wise guy who said: „Those who cannot remember the past are condemned to repeat it.“ At university I learned that 2 strategies exist to make an organisation remember it’s past – Internalisation and Codification. While internalisation usually happens anyway and an organisation only needs to keep track on who did which projects in the past, so that he can be interviewed, the codification bit is tricky.

Anbari et al. describe which interest are held by which stakeholder group and how that is going to impact any knowledge management or lack thereof. The authors also outline useful techniques and critical aspects, plus when project reviews are most usefully held during the project lifecycle.

Furthermore, the paper discusses where post-project reviews fit into the project life cycle and project management processes. It assesses how such reviews can assist an organization in improving the manner in which its projects are conceived, planned, implemented, reported, and evaluated.

Finally Anbari et al. outline a 3-fold growth model for organisations
(1) Vicious circle = no real reviews
(2) Functional circle = reviews which no one knows about
(3) Virtuous circle = reviews everybody knows.

Best Project Management and Systems Engineering Practices in the Preacquisition Phase for Federal Intelligence and Defense Agencies (Meier, 2008)

Dienstag, August 12th, 2008

 Best Project Management and SE Practices

Meier, Steven R.: Best Project Management and Systems Engineering Practices in the Preacquisition Phase for Federal Intelligence and Defense Agencies; in Project Management Journal, Vol. 39 (2008), No. 1, pp. 59-71.

Scope Creep! Uncontrolled growth in programs, especially public acquisitions is nothing new. [I highly suspect that we only look down on public projects because private companies are much better in hiding their failures.] Meier analyses the root causes for scope creep in intelligence and defense projects and proposes counter actions to be taken.

The root causes for creeping scope are

  • overzealous advocacy
  • immature technology
  • lack of corporate technology road maps
  • requirements instability
  • ineffective acquisition strategies, i.e. no incentives to stick to the budget
  • unrealistic baselines and a high reliance on contractor baselines
  • inadequate systems engineering, e.g. no concept of operations, system requirements document, statement of work, request for proposal, contact data requirements list
  • workforce issues, e.g. high staff turnover, no PMO

Meier’s remedies for this predicament are quite obvious. Have a devil’s inquisitor or a third party review to get rid of the optimism bias. Wait until technology maturity is achieved or factor in higher contingencies. Set investment priorities. Put incentives into the contracts. Estimate own costs prior to RfP. Follow systems engineering standards, e.g. INCOSE’s. Manage your workforce.

User diversity impact on project performance in an environment with organizational technology learning and management review processes (Wang et al. 2006)

Montag, August 11th, 2008

 User Diversity and Project Success

Wang, Eric T.G.; Wei, Hsiao-Lan; Jiang, James J. ; Klein, Gary: User diversity impact on project performance in an environment with organizational technology learning and management review processes; in: International Journal of Project Management, Vol. 24 (2006), pp. 405-411.

Does user diversity improves the performance of an information system-development project? Wang et al. use management review as a base process to examine whether user diversity is significant to the success of a system either directly or with learning as
a mediator. The authors find that success depends on management review and learning, but show user diversity to be fully mediated by organizational technology learning. Thus the authors conclude that user diversity should be considered an environmental factor to promote learning, but it may not be important in the completion of any particular project.

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.

A Framework for the Life Cycle Management of Information Technology Projects – ProjectIT (Stewart, 2008)

Donnerstag, Juli 17th, 2008

 ProjectIT

Stewart, Rodney A.: A Framework for the Life Cycle Management of Information Technology Projects – ProjectIT; in: International Journal of Project Management, Vol. 26 (2008), pp. 203-212.

Stewart outlines a framework of management tasks which are set to span the whole life cycle of a project. The life cycle consists of 3 phases – selection (called „SelectIT“), implementation (called „ImplementIT“), and close-out (called „EvaluateIT“).

The first phase’s main goal is to single out the projects worth doing. Therefore the project manager evaluates cost & benefits (=tangible monetary factors) and value & risks (=intangible monetary factors). In order to evaluate these the project manager needs to define a probability function of these factors for the project. Then these distribution functions are aggregated. Stewart suggests using also the Analytical Hierarchy Process Method (AHP) and the Vertex method [which I am not familiar with, neither is wikipedia or the general internet] in this step. Afterwards the rankings for each project are calculated and the projects are ranked accordingly.

The second phase is merely a controlling view on the IT project implementation. According to Stewart you should conduct SWOT-Analyses, come up with a IT diffusion strategy, design the operational strategy, some action plans on how to implement IT, and finally a monitoring plan.

The third stage („EvaluateIT“) advocates the use of an IT Balanced Score Card with 5 different perspectives – (1) Operations, (2) Benefits, (3) User, (4) Strategic competitiveness, and (5) Technology/System. In order to establish the Balanced Score Card measures for each category need to be defined first, then weighted, then applied and measured. The next step is to develop a utility function and finally overall IT performance can be monitored and improvements can be tracked.

Management competences, not tools and techniques: A grounded examination of software project management at WM-data (Rose et al., 2007)

Dienstag, Juli 15th, 2008

7 Competencies of SW Project Mgrs

Rose, Jeremy; Pedersen, Keld; Hosbond, Jens Henrik; Kræmmergaard, Pernille: Management competences, not tools and techniques – A grounded examination of software project management at WM-data; in: Information and Software Technology, Vol. 49 (2007), No. 6, pp. 605–624.
http://dx.doi.org/10.1016/j.infsof.2007.02.005

Rose et al. approach software management with a competence perspective and identify 7 competencies for a successful software project management by using an qualitative approach of grounded theory. They investigate the project managers of a medium sized software development company in Denmark. The 7 competencies they find are

  1. Technical management (code and techniques)
  2. Process management (traditional project mgmt. processes)
  3. Team management (form and develop a team)
  4. Customer management (maintain customer relationships)
  5. Business management (achieve financial results)
  6. Personal management (develop soft skills)
  7. Uncertainty management (manage interrelated complex problems)

Managing Knowledge and Learning in IT Projects: A Conceptual Framework and Guidelines for Practice (Reich, 2007)

Dienstag, Juli 15th, 2008

Knowledge gaps and risks

Reich, Blaize Horner: Managing Knowledge and Learning in IT Projects – A Conceptual Framework and Guidelines for Practice; in: Project Management Journal, Vol. 38 (2007), No. 2, pp. 5-17.

This paper won the PMI award for the best paper in 2007. She identifies 10 risks on the projects which arise due to knowledge gaps. Reich structures the risks from a systems and process perspective. Risks 1&2 are project inputs, Risks 3&4 are linked to the project governance, Risks 5-8 are operational risks, Risk 10 is an output risk.

  1. Previous lessons are not learned
  2. Team selection is flawed
  3. Volatility in the governance team
  4. Lack of role knowledge
  5. Inadequate knowledge integration
  6. Incomplete knowledge transfer
  7. Exit of team members
  8. Lack of knowledge map
  9. Loss between phases
  10. Failure to learn

Since learning the way to bridge knowledge gaps, Reich concludes that the best way to address the risks is 4-fold (1) establish a learning climate, (2) establish and maintain knowledge levels, (3) create channels for knowledge flow, and (4) develop a team memory.

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

Determinants for external communications of IT project managers (Müller 2003)

Montag, Juli 14th, 2008

 Determinants of Communication

Müller, Ralf: Determinants for external communications of IT project managers; in: International Journal of Project Management, Vol. 21 (2003), No. 5, pp. 345-354.
http://dx.doi.org/10.1016/S0263-7863(02)00053-4

Müller analysis empirically the determinants of external communication of IT project managers in a business-to-business market. The study is based on the concepts of Media Richness Theory (which postulates that the richer the medium the more effective the communication) and Transaction Economics.

Müller finds no evidence for an influence of the organisation’s structure. The risk in the project has a negative impact on communication frequency and communication contents in general. Specifically he finds that higher risk increases communications frequency and preference for face-to-face meetings whilst decreasing the preference for written reports.
Relational norms have a positive influence on communication frequency, media, and contents.

Project management and business development: integrating strategy, structure, processes and projects (Van Der Merwe, 2002)

Montag, Juli 14th, 2008

Business development

Van Der Merwe, A. P.: Project management and business development: integrating strategy, structure, processes and projects; in: International Journal of Project Management, Vol. 20 (2002), No. 5, pp. 401-411.
http://dx.doi.org/10.1016/S0263-7863(01)00012-6

Van Der Merwe outlines organisational theories and configurations. Furthermore he applies systems and process theory to explain the relationship between strategy, structure, processes, and projects. The author shows that projects in business development are used to transform a vision into results by bringing together diverse teams. He concludes with this [delightful] paragraph:

„This aspect [projects bringing together diverse people] revealed project management as the point of departure for management theory, where management manages the behavioural processes of people who manage the continuous incremental improvement of business procedures in the organisation, through projects that guide the business process to address the change in the strategic direction of the organisation. If business is to develop then the successful outcome of any change in the organisation can only be achieved when business processes and human behavioural processes converge in the person of the project manager.“ (Van Der Merwe, 2002, p. 411)

[Amen.]

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

Managing public–private megaprojects: Paradoxes, complexity, and project design (van Marrewijk et al., in press)

Montag, Juli 14th, 2008

Megaproject Culture (1) Megaproject Culture (2)

van Marrewijk, Alfons; Clegg, Stewart R.; Pitsis, Tyrone S.; Veenswijk, Marcel: Managing public–private megaprojects: Paradoxes, complexity, and project design; in: International Journal of Project Management, in press.
http://dx.doi.org/10.1016/j.ijproman.2007.09.007

Marrewijk et al. compare the project designs, daily practices, project cultures and management approaches in two case studies. The authors explore how actors on these megaprojects make sense of uncertainty, ambiguity and risk. They show that project design and project cultures influence cooperations between key players on the project.

They argue that each project has a specific project culture with subcultures, conflicts, powers, and cultural ambiguity. Thus making the staff of a project a modern tribe distinguishing themselves from the rest of the working world (and the parent corporation) via artifacts, practices, and values. Projects show multiple cultures, power relations, conflicts, and abnormalities just like any larger society. Post-Positivism research has shown the impact of the project culture on project’s success or failure. Unfortunately the authors found that megaprojects have a higher tendency than normal to develop a dysfunctional project culture.

Moreover Marrewijk et al. analyse the cultural strategies of change and the cultural forms, practices, and content themes found in their two megaproject case studies. Finally they outline how culture and project design influence a public-private partnership project. They conclude that there are 2 critical success factors on how to design a project organisation which can create a non-dysfunctional project culture.

  1. Design power relations between all players in the project in a way that balances these
  2. Design accountability in way that is NOT a zero-sum game and which serves the self-interest of all involved parties and individuals