Archive for the ‘Critical Chain’ Category

Images as action instruments in complex projects (Taxén & Lilliesköld, 2008)

Montag, Oktober 20th, 2008

Images as action instruments in complex projects (Taxén & Lilliesköld, 2008)

Taxén, Lars; Lilliesköld, Joakim: Images as action instruments in complex projects; in: International Journal of Project Management, Vol. 26 (2008), No. 5, pp. 527-536.

Images are quite powerful. I hate motivational posters which a distant corporate HQ decorates every meeting room with, but I once saw the department strategy visualised by these folks, they include all employees and the group dynamic is unbelievable. Later on they cleaned the images, blew them up, and posted them around the company – of course, meaningless for an outsider but a powerful reminder for everyone who took part.

Taxén & Lilliesköld analyse the images typically used in project management. They find that these common images, such as PERT/CPM, Gantt charts, or WBS are increasingly difficult to use in complex projects, in this case the authors look into a large-scale IT project.

Based on Activity Domain Theory they develop alternative images better suited for complex projects. Activity Domain Theory, however, underlines that all tasks on a project (= each activity domain) have a motive, fulfils needs, modifies objects, and has actors. Outcomes are produced by activity domains and are at the same time prerequisites for activity domains. Activity domains have activity modalities, which can be either manifested as resources or as communal meaning. These activity modalities are

  • Contextualisation = situation of human action
  • Spatialisation = need for spatial orientation in human action
  • Temporalisation = need for certain order in human action
  • Stabilisation = need for certain rules and norms in human action
  • Transition = need for interaction between activity domains

Useful images, the authors argue, need to fulfil these needs while being situated in the context of the activity. Traditional images focus on optimisation and control, rather than on coordination and action. Thus alternate images need to focus on dependencies and integration; on value comprehensibility and informality over formality and rigour.

Alternative images suited for complex project management are

  • Anatomies – showing modules, work packages and their dependencies of the finished product, e.g., functional node diagrams
  • Dependency diagrams – showing the incremental assembly of the product over a couple of releases, e.g. increment plan based on dependencies (a feature WBS lack)
  • Release matrices – showing the flow of releases, how they fit together, and when which functionality becomes available, e.g., integration plan
  • Information flow diagrams – showing the interfaces between modules, e.g. DFD

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

Dienstag, September 23rd, 2008

Sources and categories of delay in construction

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

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

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

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

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

Non-excusable delays and therefore punishable by fines are

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

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

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

How to build a critical chain!

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

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!