We’re not in Kansas anymore, Toto – Mapping the Strange Landscape of Complexity Theory, and its Relationship to Project Management (Cooke-Davis et al. 2007)

August 11th, 2008

Complexity Theory and Project Management

Cooke-Davis, Terry; Cicmil, Svetlana; Crawford, Lynn; Richardson, Kurt: We’re not in Kansas anymore, Toto – Mapping the Strange Landscape of Complexity Theory, and its Relationship to Project Management; in: Journal of Project Management, Vol. 38 (2007), No. 2, pp. 50-61.

Cooke-Davis et al. describe the origins of Complexity Theory as it has emerged from the fields of Life Science, Physical Science, and Mathematics since the 1960s. The authors apply  a selection of interesting concepts first described by Complexity Theory onto Project Management. Among those are Non-Linearity, emergence of organisation, states of chaos vs. stability, stability & fractals, radical unpredictability, complex responsive processes.

What does this mean for project management? Firstly, project managers should be aware of patterns of communication and relating on the project and should engage themselves in these. Secondly project members need to learn to tolerate anxiety and to cope with not having control over the project. The authors recommend a goal driven, enabling organisation instead of a control focussed management.

Projects and programmes as value creation processes: A new perspective and some practical implications (Winter & Szczepanek 2008) and Value-based Management (Töpfer 2000)

August 11th, 2008

Value Creation in Projects and Programmes

Winter, Mark; Szczepanek, Tony: Projects and programmes as value creation processes – A new perspective and some practical implications; in: International Journal of Project Management, Vol. 26 (2008), No. 1 (Special Issue on European Academy of Management (EURAM 2007) Conference), pp. 95-103.
http://dx.doi.org/10.1016/j.ijproman.2007.08.015

AND

Töpfer, Armin (Ed.): Das Management der Werttreiber; Frankfurt 2000.
Amazon Link

Winter & Szczepanek base their article on Normann’s notion of value creation as an overarching goal of the organisation which also emphasises the customer as co-creator, co-producer and co-designer of value. Therefore true customer focus can only be achieved if a project looks also at the customer’s customer and leave behind organisational boundaries. Based on this value creating processes, the authors introduce a two-level customer relationship. The first level is the product creation, the additional second level represents the strategic domain of value creation.

The implications for a project are fourfold. Projects need to set their strategic focus on value creation and the second-level relationships. Secondly, project definition should outline the broader value to be created and the context instead of a narrow product view. Thirdly, projects should be set-up as multi-disciplinary, composite projects. Lastly a focus on value creates different images of the project, which helps understanding and shows the true complex nature of projects.

Finally the authors conclude with linking strategy, programmes, and projects. They outline chains of value creation on the Group level, which are fed by similar chains on the level of the business unit, which are fed by chains of value creation on the project level. On each of these levels the authors show the first-level relationship (product focus) and the second-level relationship (value focus). Furthermore they develop an enriched version of the project management triangle outlining the the strategy implementation in terms of products build, created value, and resource impact for each of the levels.

To contrast these thinking the right picture depicts what I learned about value oriented management at university. Töpfer outlines the value creation process as a chain of

  • Shareholder Value
  • Market Value
  • Customer Value
  • People Value
  • Future Value
  • Company Value

This chain is analysed top-down and managed bottom-up. The tool to manage the chain is the Balanced Score Card (BSC). The BSC consists of 4 dimensions (1) potential for performance/market performance, (2) customer satisfaction/market penetration, (3) entrepreneurial employees/employee satisfaction, and (4) economics/financial results.

Directions for future research in project management: The main findings of a UK government-funded research network (Winter et al. 2006)

August 11th, 2008

Directions of future research in project management

Winter, Mark; Smith, Charles; Morris, Peter; Cicmil, Svetlana: Directions for future research in project management – The main findings of a UK government-funded research network; in: International Journal of Project Management, Vol. 24 (2006), No. 8, pp. 638-649.
http://dx.doi.org/10.1016/j.ijproman.2006.08.009 

To start with Winter et al. give a short overview of the research history. In their conceptualisation of project management’s history research started as a hard systems model forked afterwards into two different foci (1) execution and (2) organisational design. The organisational design stream developed into research of ad hoc & temporary organisations. This stream forked into 4 different streams a) subsequently focussed on major projects and lately on a management of project’s framework, b) analysed strategic decisions, c) viewed projects as information processing entities, and d) researched critical management.

Winter et al. outline 3 distinctive directions for future research – Theory ABOUT, FOR, and IN practice. Theory about practice should focus on complexity theory. The theory for practice on social processes, value creation, and a broad concept of project management. The theory in practice should create practitioners who are reflective practitioners and not merely trained technicians.

Predicting Risk of Failure in Large-Scale Information Technology Projects (Willcocks & Griffiths, 1994)

August 11th, 2008

Risk Managment Framework

Willcocks, Leslie; Griffiths, Catherine: Predicting Risk of Failure in Large-Scale Information Technology Projects; in: Technological Forecasting and Social Change, Vol. 47 (1994), No. 2, pp. 205-228.

Willcocks & Griffiths analyse risk management practice. They find that wrong tools are used, especially statistical and finance tools which create a false accuracy and are insufficient to set risks in the broader context they belong to. Thus risk management focuses on valuation of economical impacts instead of actively managing the risks themselves.

The authors analyse 6 well known ITC projects Singapore’s TradeNet (electronic data interchange (EDI) for all aspects of the flow of goods), UK’s Department of Social Security automation, India’s CRISP project (automate information collection and processing in India’s  Integrated Rural Development program), Videotext (and it’s historical predecessor Minitel in France, Prestel in UK, and BTX in Germany), London Stock Exchange’s Taurus (automate trading, paperless dealing and contracting of shares).

Willcocks & Griffiths present their framework how to predict risk of failure of a large scale IT project more accurately. They develop a 3 step risk management approach (1) history & context, (2) process, and (3) risk outcomes.

History includes previous successes/failures, relevant experience and organizational assets. It also includes internal context, which is defined by characteristics of the organisation (e.g. strategy, structure, reward systems, HR, management), changing stakeholder needs and objectives, employee relations context, and IT infrastructure and management. Furthermore the first step analyses the external context which includes level of government support, environmental pressures, newness/maturity of technology, maturity of consultants/suppliers, and the market demand.

The second step is the project itself as characterised by its processes and content. The risk associated with the project’s content are driven by size, complexity, definitional and technical uncertainty, and the number of units involved. The process risks are influenced by governance structures, project management and succession, management support, user commitment, project time span, team experience, and staffing stability.

Risk outcomes can be described by cost, time, and technical performance. Moreover they include stakeholder benefits, organisational/national impacts, user/market acceptance, and usage of the final ITC deliverable.

A memetic paradigm of project management (Whitty, 2005)

August 11th, 2008

Memetic approach to project management

Whitty, Stephen Jonathan: A memetic paradigm of project management; in: International Journal of Project Management, Vol. 23 (2005), No. 8, pp. 575-583.
http://dx.doi.org/10.1016/j.ijproman.2005.06.005

I am quite fascinated by Richard Dawkin’s ideas and among them the Meme (cultural analogy to Darwin’s genes) is quite an old and a bit controversial one. When I studied Knowledge Management at university a meme was an abstract unit of information which we tried to store meaningfully in some über-cool XML data bases and after a while we might have been able to even find it again, then we retrieved it, and gave it to someone knowledge-worker to think about and to put it in use thus creating knowledge. According to Memetics this process is equivalent to sex in the animal kingdom.

Whitty reflects on project management as a memeplex. He illustrates what that means for  project management in 6 areas (1) project management, (2) bodies of knowledge, (3) project managers/teams, (4) the profession, (5) knowledge creation, and (6) project organisation. In a memetic sense project management is absolutely self-serving and evolves for its own good without serving a higher purpose.
Secondly the project management meme (aka PMBOK) evolves to increase the maximum number of projects and is not a conscious expert design, thus it favours fuzzy definitions and positivist ideas over hard, falsifiable facts.
Thirdly project managers are just a meme created by memes of project management [sounds esoteric but holds some truth, it’s a little like Russell’s chicken] and not some consciously crafted tactics to implement a strategy.
Fourthly the profession of project management is not consciously constructed and skilfully designed but evolved mainly to spread project management memes.
Fifthly knowledge is not created by a social systems (think academia and practitioners) but knowledge processes = memes construct social systems which in turn spread new project management memes.
Lastly project organisations are not human constructs but creations to replicate behaviours of project management memes. [I wrote earlier about Structuration and that according to to this theory: „Repetitions of acts of individual agents reproduce the structure“ – I guess it is time for Occam’s razor.]

Whitty concludes with two recommendations for research practice (1) benchmark ideas and develop best practices, thus spreading project management memes more quickly, and (2) unify the bodies of knowledge letting only the fittest memes survive.

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

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.

The impacts of charismatic leadership style on team cohesiveness and overall performance during ERP implementation (Wang et al. 2005)

August 11th, 2008

 Charismatic Leadership

Wang, Eric; Chou, Huey-Wen; Jiang, James: The impacts of charismatic leadership style on team cohesiveness and overall performance during ERP implementation; in: International Journal of Project Management, Vol. 23 (2005), No. 3, pp. 173-180.
http://dx.doi.org/10.1016/j.ijproman.2004.09.003

„That is so neo-behaviouristic of you!“ how many times have you heard this? Whilst it is true that a multitude of critical success factors were proven IT projects, leadership is typically among the No. 1s of those. In this article Wang, Chou & Jiang ask the question: „How do charismatic leader impact their teams and subsequently project success?“

Wang et al. identify a couple of directs of impact of charismatic leaders. Usually they enthusiast people, develop trust, build confidence, and build commitment. Thus they create a high team satisfaction. Moreover they fulfil their mentor role with empathy. Charismatic leaders impact each team member individually. Team members internalise the leader’s values and goals which leads to transcend the team’s self interest for a higher goal.

Wang et al. showed empirically in a sample of 106 Taiwanese companies that charismatic leadership positively, directly and in-directly influences team cohesiveness and project team performance.
Now all what is left to do is to become a charismatic leader.

Back from Holidays! More posts coming soon this morning!

August 11th, 2008

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

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 Case Study of Project and Stakeholder Management Failures: Lessons Learned (Sutterfield et al., 2006)

Juli 17th, 2008

Stakeholder Management

Sutterfield, J. S. Friday-Stroud, S. S. Shivers-Blackwell, S. L.: A Case Study of Project and Stakeholder Management Failures – Lessons Learned; in: Journal of Project Management, Vol. 37 (2006), No. 5, pp. 26-35.

Sutterfield et al. describe a framework for managing the project’s stakeholders from the perspective of the project manager. Their framework includes the following 9 steps

  1. Identify project vision and mission
  2. Conduct project SWOT analysis
  3. Identify the stakeholders and their goals
  4. Identify selection criteria for strategies on how to manage the stakeholders and identify alternative strategies to manage the stakeholders
  5. Select PSM strategy for each stakeholder (PSM in this case is neither project safety management, nor procurement strategy management, but rather project stakeholder management)
  6. Acquire and allocate resources to manage stakeholders
  7. Implement the selected PSM strategies
  8. Evaluate the implemented PSM strategies
  9. Seek and incorporate continuous feedback

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

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.

On the broadening scope of the research on projects: a review and a model for analysis (Söderlund, 2004)

Juli 17th, 2008

Broadening research of PM

Söderlund, Jonas: On the broadening scope of the research on projects: a review and a model for analysis; in: International Journal of Project Management, Vol. 22 (2004), No. 8, pp. 655-667.
http://dx.doi.org/10.1016/j.ijproman.2004.05.011

Söderlund reviews the research literature on project management. He then illustrates briefly the different developments within this profession. Finally he suggests four different directions on how to broaden the scope of project management research to make it more useful than just adding another project success factor to it.

  • Broaden research to include wider organisational issues (e.g., processes, politics)
  • Broaden research to include inter-organisation aspects and authority system issues (e.g., contracting, cooperation)
  • Broaden the level of analysis (e.g., organisational issues, company-wide issues)
  • Broaden research to include industry-wide matters (e.g., cooperation between firms, network of professionals)

Building theories of project management: past research, questions for the future (Söderlund, 2004)

Juli 17th, 2008

Theories of Project Managment

Söderlund, Jonas: Building theories of project management – past research, questions for the future; in: International Journal of Project Management, Vol. 22 (2004), No. 3, pp. 183-191.
http://dx.doi.org/10.1016/S0263-7863(03)00070-X

Söderlund reviews the ideas around building a theory of project management. He identifies the roots of project management research in the scheduling technique school of Gannt, CPM, and PERT. He argues that these are basically applications of engineering science and optimization theory. Furthermore he identifies two different philosophies right from the beginning. The first one is Gaddis with the notion of a project as an organizational unit devoted to attain a single goal. The second philosophy is Miles et al. who see a project as an organisational form.

Subsequently he identifies three streams of theory building. (1) Universal theory building which focuses on the temporariness of the project as an organisational form and action researc. (2) Normative (Positivist) tradition which is concerned to generate best practices and generic factors of project success, which results in a multitude of textbooks, check lists, and literature on how to optimize the project’s processes. (3) Contingency theory approaches which value the context of projects. These efforts lead to studies into categories of projects and industry specifics of project management.

Söderlund concludes with a set of questions for future research

  • Why do projects exist?
  • Why do they differ?
  • How do project organisations behave?
  • What is the function of the value-add of a project unit?
  • What defines success?

Project management of unexpected events (Söderholm, 2007)

Juli 17th, 2008

Management of Unexpected Events

Söderholm, Anders: Project management of unexpected events; in: International Journal of Project Management, Vol. 26 (2007), No. 1, pp. 80-86.
http://dx.doi.org/10.1016/j.ijproman.2007.08.016

Söderholm qualitatively studies in four cases how unexpected events are dealt with on projects. The author finds three most common root causes for unexpected events, re-openings of topics (mostly due to outside pressure, e.g., new definitions, new issues, politics), revisions of plans, and fine tuning of the project. Furthermore Söderholm identifies four different tactics to manage unexpected events. (1) innovative action, (2) applying detachment strategies, (3) setting up intensive meeting schedules, and  (4) negotiating project conditions.

ad (1) – Innovative action is an inside, short term action to counter the event, examples for this action are the shuffling of resources, delaying activities, and problem solving
ad (2) – Detachment strategies are typical MaxiMin-strategies, the project tries to make itself independent from the event’s consequences as much as possible
ad (3) – Intensive meeting schedules are set up to closely monitor a problematic work package of the project and to assure the best communication flow possible
ad (4) – Negotiating conditions and project safe guarding are mostly used by project managers to gain access to additional resources

Toward a typological theory of project management (Shenhar & Dvir, 1996)

Juli 17th, 2008

Typological Theory of PM

Shenhar, Aaron J.; Dvir, Dov: Toward a typological theory of project management; in: Research Policy, Vol. 25 (1996), No. 4, pp. 607-632.
http://dx.doi.org/10.1016/0048-7333(95)00877-2

Basing their text on the metaphor of incremental vs. radical innovations Shenhar & Dvir develop a typological framework for projects. In their model the two factors System Scope (assembly, system, array) and Technological Uncertainty (low, medium, high, and super high tech) distinguish projects. Furthermore the authors give some example and characterise each of the 12 types of projects.

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

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)

The impact of project portfolio management on information technology projects (De Reyck et al., 2005)

Juli 15th, 2008

De Reyck, Bert; Grushka-Cockayne, Yael; Lockett, Martin; Calderini, Sergio Ricardo; Moura, Marcio; Sloper, Andrew: The impact of project portfolio management on information technology projects; in: International Journal of Project Management, Vol. 23 (2005), No. 7, pp. 524-537.
http://dx.doi.org/10.1016/j.ijproman.2005.02.003

In their article de Reyck et al. argue that project portfolio management (PPM) is essential to create value with IT project. The research focus is the management of resources and risk. Moreover most articles are from vendors of the software, promoting the value of the PPM process, a claim not based on any empirical evidence.

Based on findings from a survey about PPM adoption, de Reyck et al. introduce a three-stage classification scheme of PPM adoption. Furthermore they show that a strong correlation exist between increasing adoption of PPM processes and a reduction in project related problems, and between PPM adoption and project performance.

Their maturity model shows how the elements of PPM (centralisation of project control, financial analysis, risk analysis, interdependencies, constraints, overall portfolio analysis, categorisation/selection/accountability and governance, optimisation, and specialised software) are adopted in each of their 3 stages:

PPM Maturity Model (de Reyck et al. 2005, p. 530)

from: De Reyck et al. (2005), p. 530

In my opinion the question remains if organisations in stage 3 follow a controlling agenda more than they actually empower their project managers.

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

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.

Project management information systems: An empirical study of their impact on project managers and project success (Raymond & Bergeron, 2008)

Juli 15th, 2008

 PMIS

Raymond, Louis; Bergeron, Francois: Project management information systems – An empirical study of their impact on project managers and project success; in: International Journal of Project Management, Vol. 26 (2008), pp. 213-220.

To make a long article short: Project management information systems (PMIS) have a positive impact on project managers and project success. The cause-effect-chain is as follows: PMIS Quality –> PMIS Information Quality –> PMIS Useage –> Project Manager –> Project Success.

How to build a critical chain!

Juli 15th, 2008

This is not a summary of an article per se; but it summarizes the description on how to build a Critical Chain as it was published in
Rand, Graham K.: Critical chain – the theory of constraints applied to project management; in: International Journal of Project Management, Vol. 18 (2000), No. 3, p. 173-177. http://dx.doi.org/10.1016/S0263-7863(99)00019-8

Critical Chain

The Theory of Constraints was outlined by Eliyahu M. Goldratt in his book „Theory of Constraints“, which subsequently Goldratt applied to project management in „Critical Chain“, which interestingly is a novel similar to Tom DeMarco’s Deadline.  Anyway, the basic idea of the Theory of Constraints is according to Wikipedia

[…] every organization has – at any given point in time – at least one constraint which limits the system’s performance relative to its goal. These constraints can be broadly classified as either an internal constraint or a market constraint. In order to manage the performance of the system, the constraint must be identified and managed correctly […] (from Wikipedia)

The Theory of Constraints outlines a 5 step process to tackle the whole problem

  1. Identify the constraint
  2. Decide how to exploit the constraint
  3. Subordinate everything else to above decision
  4. Elevate the constraint
  5. If constraint has been broken, go back to (1) and never allow inertia to cause a system’s constraint

So what is the constraint on a project? Of course it is the time of critical resources. What is the problem with them? They do suffer from something called student’s syndrome – no matter how much buffer they get, the work is only done in the last few days.
The solution? Exploit the constraint – then elevate it. In other words: finish task on time before trying to decrease total time.
How can one exploit the constraint? Remove all buffers into a big one at the end of the project. All tasks or streams which are not on the critical path get a feeding buffer right before they feed into the critical path again.
How do I manage it? Project Management needs to ensure that no time is lost on hand-overs. Furthermore if the time comes everything must be dropped and everyone works on tasks on the critical chain only. Never ever shall multi-tasking occur!