Archive for the ‘Project Strategy’ Category

Governance Frameworks for Public Project Development and Estimation (Klakegg et al., 2008)

Montag, November 3rd, 2008

 Governance Frameworks for Public Project Development and Estimation (Klakegg et al., 2008)

Klakegg, Ole Jonny; Williams, Terry; Magnussen, Ole Morten; Glasspool, Helene: Governance Frameworks for Public Project Development and Estimation; in: Project Management Journal, Vol. 39 (2008), Supplement, pp. S27–S42.
DOI: 10.1002/pmj.20058

Klakegg et al. compare different public governance frameworks, particularly the UK’s Ministry of Defense, UK’s Office of Government Commerce, and Norway’s framework. The authors find that „the frameworks have to be politically and administratively
well anchored. A case study particularly looking into cost and time illustrates how the framework influences the project through scrutiny. The analysis shows the governance frameworks are important in securing transparency and control and clarifies the role of sponsor“ (p. S27)

Their analysis starts with the question of „Who are governance relevant stakeholders?„. The authors show two different general approaches to public governance stakeholders – Shareholder Value Systems and Communitarian Systems. The Shareholder Value System is based on the principle that only shareholders are legitimate stakeholders – a system which is used in the US, UK, and Canada. On the other hand the Communitarian System is based on the idea that all impacted communities and persons are relevant stakeholders – a system typically found in Norway, Germany, and numerous other countries. A secondary line of thought is the difference between Western and Asian stakeholder ideas, whereas the Asian idea is underlining the concept of family and the Western idea is underlining the relationship concept.

To pin down the idea of public project governance the authors draw parallels to corporate governance with it’s chain of management ↔ board ↔ shareholder ↔ stakeholder. The APM defines project governance as the corporate governance that is related to projects with the aim that sustainable alternatives are choosen and delivered efficiently. Thus the authors define a governance framework as an organised structure, authoritive in organisation with processes and rules established to ensure the project meets its purpose.

The reviewed governance frameworks show interesting differences – for example in the control basis, reviewer roles, report formats, supporting organisation, and mode of initiation. The principles they are based on range from management of expectations, to establishing hurdles to cross, to making recommendations. Focus of the reviews can be the business case, outputs, inputs, or used methods.

Tailored task forces: Temporary organizations and modularity (Waard & Kramer, 2008)

Montag, Oktober 20th, 2008

Tailored task forces: Temporary organizations and modularity (Waard & Kramer, 2008)

Waard, Erik J. de; Kramer, Eric-Hans: Tailored task forces – Temporary organizations and modularity; in: International Journal of Project Management, Vol. 26 (2008), No. 5, pp. 537-546.

As a colleague once put it: Complex projects should be organised like terrorist organisations – Autonomous cells of highly motivated individuals.

Waard & Kramer do not analyse projects but it’s fast paced and short lived cousin – the task force. The task force is THE blueprint for an temporary organisation. The authors found that the more modularised the parent company is, the easier it is to set-up a task force/temporary organisations. Waard & Kramer also found that the temporary organisations are more stable if set-up by modular parent companies. They explain this with copying readily available organisational design principles and using well excercised behaviours to manage these units.

The more interesting second part of the article describes how a company can best set-up task forces. Waard & Kramer draw their analogy from Modular Design.

„Building a complex system from smaller subsystems that are independently designed yet function together“

The core of modular design is to establish visible design rules and hidden design parameters. The authors describe that rules need to be in place for (1) architecture, (2) interfaces, and (3) standards. The remaining design decisions is left in the hands of the task force, which is run like a black box.
In this case Architecture defines which modules are part of the system and what each modules functionality is. Interface definition lays out how these modules interact and communication. Lastly, the Standards define how modules are tested and how their performance is measured.

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.

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)

Montag, 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)

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


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.

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

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

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

What is Project Strategy? (Artto, K.; Kujala, J.; Dietrich, P.; Martinsuo, M.; 2008)

Sonntag, Juli 6th, 2008

WIPS? (Thumb)

Artto, Karlos; Kujala, Jaakko; Dietrich, Perttu; Martinsuo, Miia: What is Project Strategy?, in: International Journal of Project Management, 26 (2008), pp. 4-12

Artto et al. do have a very nice article in the first issue of this year’s IJPM. The authors look into behavioural strategies of projects. They see projects being ’sort of‘ autonomous of their organizational environment and that projects not always follow directions and decisions set-up by their mother corporations.

They do map 4 distinctive types of project strategy/behaviour on two axes. (1) Strength of link to parent organisation. (2) Degree of independence. Thus creating a 2×2-Matrix (what consultants usually love – „there is no problem which can not be shown in a 2×2-Matrix“) with 4 strategy types: (a) Obediant Servant, (b) Independent Innovator, (c) Flexible Mediator, (d) Strong Leader.

Their article closes with recommendations for future research on: (1) empirically validating these 4 strategies; (2) the question how strategies are formulated, what are the routes of development; (3) Empirical studies of strategy shaping factors, to address the dynamics and evolutions of projects‘ strategies; (4) Empirical investigations into different environments, aka application areas (innovation, organizational transformation, IT etc.); (5) Connection to mainstream strategy research and ops management; (6) bringing this to a stakeholder perspective: What kind of influences, levers, tactics are used by different stakeholders to formulate and implement a project’s strategy?