Archive for the ‘Control’ Category

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

Montag, November 3rd, 2008

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

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

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

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

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

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

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

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

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

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

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

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.

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

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.