Understanding the Iron Triangle and Projects

The concept of the iron triangle as a framework for managing projects has long past its use-by date, almost everyone, including PMI, recognize the challenges faced by every project manage are multi-faceted, and multi-dimensional – three elements are not enough. But dig back into the original concepts behind the triangle, and you do uncover a useful framework for defining a project, and separating project management from general management.

The Iron Triangle

The origin of the project management triangle is accredited to Dr. Martin Barnes. In 1969[1], he developed the triangle as part of his course ‘Time and Money in Contract Control’ and labelled three tensions that needed to be balanced against each other in a project: time, cost, and output (the correct scope at the correct quality). The invention of the iron triangle is discussed in more depth in The Origins of Modern Project Management.

The concept of the triangle was widely accepted, and over the years different versions emerged:

• The time and cost components remained unchanged, but the ‘output’ became variously scope or quality and then to scope being one of the three components and quality in the middle of the triangle (or visa versa). These changes are semantic:
  • you have not delivered scope unless the scope complies with all contractual obligations including quality requirements
  • achieving quality required delivering 100% of what is required by the client.
    
    
• The shift from tensions to constraints changes the concept completely. A constraint is something that cannot be changed, or requires permission to change. Tensions vary based on external influences, the three tensions can work together or against each other.  
   
• The introduction of iron!  It seems likely, the iron triangle, based on the concept of the iron cage from Max Weber’s 1905 book The Protestant Ethic and the Spirit of Capitalism’s English translation (1930). The iron cage traps individuals in systems based purely on goal efficiency, rational calculation, and control[2].

So, while the concept of the iron triangle and/or triple constraint has been consigned to history, the original concept of the triangle, as a balance between the three elements that are always present in a project still has value.

Defining a project

Understanding precisely what work is a project, and what is operational (or some other forms of working) is becoming increasingly important as various methodologies such as Lean and Agile span between the operations and project domains. 

Some of the parameters used to define or categorize projects include:

• Hard -vs- Soft projects, see:
  https://mosaicprojects.wordpress.com/2023/01/21/hard-v-soft-projects/
  
  
• Size and Complexity usually seen as a continuum:

• The Methodology used to manage the work, ranging from Agile to Directed, see How should the different types of project management be described?

There are many other ways to categorize projects, some of which are discussed in the papers at: https://mosaicprojects.com.au/PMKI-ORG-035.php#Class. But these classifications do not really provide a concise definition of a project. And, while there are many different definitions, we consider the best definition of a project to be: 

Project:  A temporary organization established to accomplish an objective, under the leadership of a person (or people) nominated to fulfil the role of project manager[3].

The two key elements being:

1. The project is temporary, the project delivery team or organization closes and its people reallocated, or terminated, when the objective is achieved, and
   
   
2. The project is established to accomplish an objective for a client which may be internal or external to the delivery organization.

The concept of a project being temporary is straightforward (even though it is often ignored). Departments that are set up and funded to maintain and enhance plant, equipment and/or software systems on an ongoing basis are not projects, and neither is most of their work. We discussed this several years back in De-Projectizing IT Maintenance, and the concept seems to be becoming mainstream with the concept of ‘flow’ being introduced to Disciplined Agile.

The value of the project management triangle is identifying the three mandatory elements needed to describe the client’s objective. There are usually a number of additional elements but if any these three are not present, the work is not a project:

1. The expected outcome is understood. The project is commissioned to deliver a change to the status quo. This may be something new, altered, and/or removed; and the outcome may be tangible, intangible or a combination.  The outcome does not need to be precisely defined to start a project, and may evolve as the project progresses, but the key element is there is an understood objective the project is working to achieve.  
     
2. There is an anticipated completion time. This may be fixed by a contract completion date, or a softer target with some flexibility.  However, if there are no limitations on when the work is expected to finish (or it is assumed to be ongoing), you are on a journey, not working on a project. 
    
3. There is an anticipated budget to accomplish the work. Again, the budget may be fixed by a contract, or a softer target with some flexibility.  The budget is the client view of the amount they expect to pay to receive the objective. The actual cost of accomplishing the work may be higher or lower and who benefits or pays depends on the contractual arrangements. 

Conclusion

Understanding the difference between project work and non-project work is important.  Project overheads are useful when managing the challenges of delivering a project, including dealing with scope creep, cost overruns, schedule slippage, and change in general. The mission of the project team is to deliver the agreed objective as efficiently as possible.

The objective of an operational department is to maintain and enhance the organizational assets under its control. This typically needs different approaches and focuses on a wider range of outcomes.  Many techniques are common to both operational and project work, including various agile methodologies and lean, and many management traits such as agility are desirable across the spectrum.  The difference is understanding the overarching management objectives, and tailoring processes to suite.  

For more on project definition and classification see:
https://mosaicprojects.com.au/PMKI-ORG-035.php#Overview

---

[1] We published and widely circulated this claim after a meeting with Dr. Barns in 2005 at his home in Cambridge. So far no one has suggested an alternative origin.  

[2] For more on the work of Max Weber, see The Origins of Modern Management: https://mosaicprojects.com.au/PDF_Papers/P050_Origins_of_Modern_Management.pdf

[3] The basis of this definition is described in Project Fact or fiction: https://mosaicprojects.com.au/PDF_Papers/P007_Project_Fact.pdf 

Costain vs Haswell Revisited

One of the ways the law tries to maintain consistency across multiple court cases in literally hundreds of court rooms is by following the same decision-making process used in previous cases to decide an outcome where similar matters are in dispute. This has the advantage of providing a degree of certainty, or at least consistency in the way laws and contracts are interpreted. But can make the law relatively slow to change when business practice changes. However, there are times when the Judges identify problems well before the practitioners! Costain Ltd v Charles Haswell & Partners Ltd [2009] EWHC B25 (TCC) (24 September 2009) is one example. This case related to the construction of the eleven separate structures, that constitute the Lostock and Rivington Water Treatment Works in Lancashire, UK.

As part of this court case, the design and construction contractor, Costain Limited, sought costs from its consulting civil engineer, Charles Haswell & Partners Ltd (Haswell), for the cost of delays caused by incorrect geotechnical advice provided by Haswell. Costain alleged that Haswell’s original design for pre-foundation ground treatment works failed to achieve the specified design criteria for two of the eleven project structures. This resulted in the need for unplanned piling works to support the two structures, which Costain alleged caused a critical delay to the project. As a consequence, Costain was seeking to recover the costs of the delay (prolongation costs) from Haswell.

The quantum experts in the case agreed on two tests for establishing Costain’s entitlement to prolongation costs:

• First, whether the assumed delay to completion caused by the remedial piling had crystallised into the same actual delay to the completion of the project some sixteen months later, and
• Second, whether all of the project’s activities were delayed by the piling to just two of the eleven structures.

The parties’ programming experts agreed on a common methodology for assessing the delay, which the judgment refers to as a ‘time impact analysis’ or ‘windows slice analysis’. The method described in the judgement appears the same as the Time Impact Analysis defined in the SCL Delay and Disruption Protocol and AACEi MIP 3.7 (for more detail on this see: https://mosaicprojects.com.au/PDF_Papers/P216_Assessing_Delay_The_SCL_Options.pdf).

There were some points of disagreement between the experts but ultimately, the Court found that the remedial piling on two structures was critical to the project at the time considered in the ‘windows analysis’  noting the experts have agreed that the delays to the RGF and IW were critical delays since those buildings were on the critical path of the project at the relevant time.  Ordinarily therefore one would expect, other things being equal, that the project completion date would be pushed out at the end of the job by the same or a similar period to the period of delay to those buildings.  However, as experience shows on construction sites, many supervening events can take place which will falsify such an assumed result.  For example, the Contractor may rearrange his programme so that other activities are accelerated or carried out in a different sequence thereby reducing the initial delays. [Clause 233]

The assumption underpinning the expert’s ‘window’ analysis showing that a critical delay had occurred and the entitlement to a delay was based on the premise that the work on the rest of the project would follow the logic as shown in the CPM network. The Court rejected this assumption because the assumed flow-on of the delay to the overall completion of the works was not demonstrated: ‘I find that it has not been shown by Costain that the critical delay caused to the project by the late provision of piled foundations to the RGF and IW buildings necessarily pushed out the contract completion date by that period or at all’. [Clause 200 (ii)]

The second test asked whether a delay to work on part of the project would cause all of the project’s activities to be prolonged. In considering this test, the Court rejected Costain’s assumption that the remedial piling to two of the structures on the project prolonged all eleven structures: ‘If the contractor establishes [a critical, excusable delay], he is entitled to an extension of time to the whole project including, of course all those activities which were not in fact delayed … But the contractor will not recover the general site overheads of carrying out all the activities on site as a matter of course unless he can establish that the delaying event to one activity in fact impacted on all the other site activities’. [Clause 183-184]

The Court also found ‘no evidence has been called to establish that the delaying events in question in fact caused delay to any activities on site apart from the RGF and IW buildings.  That being so, it follows, in my judgment, that the prolongation claim advanced by Costain based on recovery of the whole of the site costs of the Lostock site, fails for want of proof’. [Clause 185]

Costain failed in its claim for time related prolongation costs and only recovered the additional costs of installing the piled foundations, because ‘In the absence of any analysis between all the operative delays from the start to the finish, which is absent in this case, in my judgment it is simply not possible for the Court to be satisfied on the balance of probabilities that the assumption upon which this part of Costain’s case depends, is correct’. [Clause 235]

Conclusion – Distributed Projects are Different!

The fundamental problem outlined above was caused by the distributed nature of the project work. The Critical Path Method (CPM) assumes there is one best way to accomplish the work of the project and this is described in the schedule. In distributed projects there are multiple different ways the work could be accomplished. Therefore, any delay analysis technique based on the assumption that the sequence of work shown in a CPM schedule is the only way to accomplish the work is unlikely to prove the delay.  A different approach is needed!

We are working on this challenge.

• Scheduling Challenges in Agile & Distributed Projects defines the problem and classifies four different types of project from a CPM and controls perspective. Using this classification, the Lostock and Rivington Water Treatment Works was a ‘Class 4’ project where a CPM schedule was imposed, but is unlikely to prove effective. Distributed projects fall under Class3, where a detailed CPM schedule is not accepted as an effective controls approach – different processes are needed.
  
  
• Predicting Completion in Agile & Distributed Projects (due for publication in the May edition of PMWJ) will define a process for measuring progress and predicting completion in Class 3 projects.
  
  
• Assessing Delays in Agile & Distributed Projects (due for publication in the June edition of PMWJ) will define a process for reliably determining the effect of delay or disruption in Class 3 projects.  

As work progresses, we will be updating the Schedule control in Agile and Distributed projects section of the Mosaic website and welcome feedback: https://mosaicprojects.com.au/PMKI-SCH-010.php#Issues-A+D  

The full Costain judgement can be downloaded from: https://mosaicprojects.com.au/PMKI-ITC-020.php#Cases

Scheduling Challenges in Agile & Distributed Projects

Our paper looking at the scheduling challenges in agile and distributed projects has been published in the February 2003 edition of PM World Journal: https://pmworldjournal.com/

Critical path theory is based on an assumption that to deliver a project successfully there is one best sequence of activities to be completed in a pre-defined way. Consequently, this arrangement of the work can be modelled in a logic network. However, while CPM has proved to be an effective controls tool for many types of projects, it is equally apparent the CPM paradigm does not apply to a wide range of other project types including soft projects and distributed projects.

The focus of this paper is to:

• Briefly define the management assumptions that support the use of CPM scheduling, its origins, and limitations
• Develop a classification framework of project characteristics to help define the potential usefulness of CPM scheduling
• Briefly describe some of the management approaches currently used in non-CPM projects including agile and lean, their benefits and limitations
• Consider the application of the framework discussed above applied to a typical wind farm project
• Develop general recommendations for the management of non-CPM projects focused on optimizing the efficient use of resources.

Based on this foundation, two additional papers will look at:

1. Implementing a robust system for reporting progress and predicting completion in agile and distributed projects that can be applied to any class of project.
2. Assessing delay and disruption in agile and distributed projects where the use of a CPM schedule is not viable.

Download Scheduling Challenges in Agile & Distributed Projects: https://mosaicprojects.com.au/PDF_Papers/P208_Scheduling_Challenges_in_Agile_+_Distributed_Projects.pdf  

For more on this topic see: https://mosaicprojects.com.au/PMKI-SCH-010.php#Issues-A+D

Hard -v- Soft Projects

We are working on a couple of paper where a concise definition of hard and soft projects would be helpful.  Most commentary on the subject seems very imprecise and based on tangible v intangible outputs.

Tangible means perceptible by touch, but a piece of artwork (say a painting) can be touched! However, if the creation of the artwork is treated as a project, in almost all other respect the project is a soft project, the same goes for most design projects. The concept of a soft project is one where stakeholder engagement and change are welcome, with a focus on achieving the greatest value or stakeholder satisfaction at completion.

We suggest the primary differentiation between the two, is the various components of a hard project have to literally fit together, this required a detailed design to be finalized for each subassembly, before necessary parts can be procured and assembled. Furthermore, the overall design has to be progressed to a stage where there is a high degree of confidence the subassemblies will fit together into components and the components will fit together to create a final product that functions correctly and meets the specified requirements.

This means a hard project needs the detailed design of each subassembly or component to be completed before the project team can start working on the component and each component has to be built to the design.  Change is a complex and often expensive process.   

In contrast, the detailed design of components in soft projects can be, and very often is, done as part of the work involved in developing the element. While the function of the component is likely to be set in the overall design, how the functionality is delivered is flexible and most changes can be accommodated comparatively easily. In essence, agile is designed to deliver soft projects.  

There is of course the added complication that most hard projects include a significant element of software, and many soft projects include some hardware.

These factors suggest the definition of hard and soft projects should be:

A hard project is one where the majority of its subcomponents require the detailed design of the subcomponent to be finalized before work on the subcomponent commences, and the subcomponent is expected to be built to conform to its design.

A soft project is one where the majority of its subcomponents require the functionality of the subcomponent to be defined before work on the subcomponent commences, but there is significant flexibility in how the required functionality is achieved.

These definitions could be reduced to:

A hard project is one where the majority of the work is dependent on a finalised design being complete for each element of the project, prior to work starting on that element.

A soft project is one where the majority of the work has a degree of flexibility on how the required functionality is achieved.

What do you think??

Differentiating normal, complex and megaprojects

The days when projects were simply projects and project success was defined by the ‘iron triangle’ are long gone.  The intention of this post is to try and bring together four aspects of current thinking and their embedded concepts into an overall model of project management in the 21^st century.  The starting point is traditional project management as defined in the soon to be published 6^th Edition of the PMBOK® Guide; the major change (incorporated in the 6^th Ed.) is ‘Agile Project Management’.  The two significant extensions to traditional project management that go beyond the PMBOK® Guide are ‘Complex Project Management’ and ‘Megaproject Management’. The focus of this paper is on the skills and competencies needed by the ‘managers’ of these different classifications of ‘projects’ rather than the scope of the different concepts (more on this later).

As a starting point, there seems to be a generally accepted view that the competencies needed to be a successful project manager underpin all of the other concepts. There are some distinctly different techniques used in Agile, only some of which flow into traditional project management, but in other respects ‘agile’ and ‘good project management’ are very closely aligned.  Managing complexity requires a significant additional set of competencies that build onto the traditional requirements.  Then, whilst many complex projects do not meet the definition of a ‘megaproject’, every megaproject is by definition a complex project with an additional layer of management capabilities needed to deal with its impact on society.  This basic framework is outlined below:

Stakeholders

All forms of project management recognise the importance of the project stakeholders. Projects are done by people for people and the ultimate success or failure of a project is defined by people – all ‘stakeholders’.  My work on the PMBOK® Guide 6^th Edition core team was very much focused on enhancing the sections on stakeholder engagement and communication (which is the primary tool for engaging stakeholders). And as the scale of projects increase, the number of stakeholders and the intensity of public focus increases dramatically.

A heuristic suggested by Prof. Bent Flyvbjerg is as a general rule of thumb: ‘megaprojects’ are measured in billions of dollars, ‘major projects’ in hundreds of millions, and ‘projects’ in tens of millions or less. To quote the late Spike Milligan, ‘Money can’t buy you friends but you do get a better class of enemy’ – and while many stakeholders may not be ‘enemies’, the ability of stakeholders to organise around a megaproject tends to be far greater than around a small internal project. Consequently, the focus on stakeholders should increase significantly in excess of the increment in cost as you flow from small to megaprojects.

However, regardless of size, the need to identify, engage, manage, and deliver value to stakeholders, through the realisation of beneficial change, is consistent through all of the concepts discussed below. This and the temporariness of each ‘project organisation (ie, team)’ are the two consistent factors that underpin the concept of project management; and ‘temporariness’ is the key factor that separates projects and programs from other forms of management and ‘business as usual’.

 

Traditional Project Management.

The recognised guide for traditional project management is the PMBOK® Guide augmented to a degree by ISO 21500. The publicly released information on the 6^th Edition highlights the need for flexibility in applying its processes, including the requirement to actively consider ‘tailoring processes’ to meet project requirements, and the value agile thinking can bring to the overall management of projects (see below).

The frame of traditional project management starts once the project is defined and finishes once the project has delivered is objectives. While this scope is somewhat limited and there may be a need to expand the scope of project management to include project definition at the ‘front end’, and benefits realisation and value creation after the outputs have been delivered (this will be the subject of another post), the knowledge, skills and competencies required to manage this type of project management are well understood.

Each project has four basic dimensions, size (usually measured in $), technical difficulty, uncertainty and complexity (these are discussed in detail in: Project Size and Categorisation). In the right circumstances, Agile can be an effective approach to resolving uncertainty. However, at an undefined point, the increase in complexity reaches a point where the concept of ‘complex project management’ becomes significant and really large projects are the realm of ‘megaproject management’. But the underpinning capabilities required to manage all of these extensions remains the conventional project management skills.

 

Agile Project Management

Agile has many facets. The concepts contained in the Agile Manifesto basically reflect a shift away for a ridged focus on process towards a focus on people (stakeholders) and adapting to change to achieve a successful outcome.  These concepts are now firmly embedded in the PMBOK® Guide 6^th Edition and apply to every project. Where agile projects separate from traditional projects is recognising that in a range of soft projects, including software development, taking an iterative and adaptive approach to understanding the scope can often achieve a better outcome. Understanding what is actually helpful to the client develops based on learned experience from earlier iterations and these needs are incorporated into the next iteration of the development allowing a better outcome to be delivered to the client. This is not significantly different to much older concepts such as ‘rolling wave planning’ and progressive elaboration – there really is little point in making detailed plans for work you don’t know much about. The difference is Agile actively expects the scope to be adapted to the emerging requirements of the client, the other approaches seek to add detail to the plans at an appropriate point in time whilst the overall scope remains fundamentally unchanged.

Agile does not even need a project to be useful. Many of the Agile techniques work in any situation where there is a backlog of work to get through and can be effectively used outside of the concept of a ‘project’, this particularly applies to routine maintenance work of almost any kind.  A discussion on the value of Agile, and its limitations, are contained in our paper Thoughts on Agile.

However, for the purposes of this post, the key aspects Agile brings to the discussion, that are essential for effectively managing most types of project, are contained in the Manifesto – a preference for:

• Individuals and interactions over processes and tools.
• Customer collaboration over contract negotiation.
• Responding to change over following a plan.

The Manifesto recognises there is value in the items on the right, but values the items on the left more.

 

Complex Project Management

Complexity is a facet of every project and program. Complex project management skills become important at the point where complexity becomes a significant inhibitor affecting the delivery of a successful outcome from the project (or program). This point may occur well before ‘complexity’ becomes the defining feature of the project.

Complexity is a very different concept to a complicated project, technically complicated work can be predicted and managed; launching a new communication satellite is ‘rocket science’, but there are highly skilled rocket scientists available that undertake this type of work on a routine basis. As with any traditional project, the costs, resources and time required can be predicted reasonably accurately.

The dominant feature of complexity is the non-predictability of outcomes. Non-linearity, ‘the tipping point’, and emergence describe different ways outcomes from a slightly different starting point can vary significantly compared to previous experience or expectations (for more on the concepts of complexity see: Complexity Theory).  Complexity arises from various forms of complex system, these may be organic (eg, a river’s eco-system), man-made (eg, an overly complicated system-of-systems such as too many interconnected software applications automatically interacting with each other), or interpersonal (eg, the web of relationships within and between a project team and its surrounding stakeholder community).  In all of these situations, the ‘system’ behaves relatively predictably, dealing with the effects of stresses and stimuli up to a point (and normal management approaches work satisfactorily); but after that point adding or changing the situation by a small increment creates completely unexpected consequences.

Interestingly, from the perspective of managing a project, these three areas of complexity are closely interlinked, the complex behaviour of the environment and/or man-made systems-of-systems feeds back into the perceptions of stakeholders and the activity of stakeholders can impact on both the environment, and the way complex systems function. Similarly, dealing with emerging anomalies in the environment or in a complex system needs the active cooperation of at least some of the project’s stakeholders. Consequently, the focus of complex project management is dealing with the consequences of the inherently unpredictable and complex behaviours and attitudes of stakeholders, both within the team and within the surrounding stakeholder community.

Some projects and programs, particularly large ones, are obviously complex from the outset and can be set up to make effective use of the ideas embedded in complex project management. Others may be perceived as non-complex ‘business-as-usual’ and tip into complexity as a result of some unforeseen factor such as a ‘normal accident[1]’ occurring or simply because the perception of ‘straightforward’ was ill-founded. Underestimating complexity is a significant risk.

Where the project is perceived to be complex from the outset, a management team with the competencies required to deal with the nuances of managing a ‘complex project’ can be appointed from day one (and if appropriately skilled people are not available, support and training can be provided to overcome the deficiencies) – this maximises the probability of a successful outcome.  When a project unexpectedly falls into a state of complexity the situation is far more difficult to manage primarily because the people managing the work are unlikely to be skilled in complex project management, will try to use normal management techniques and most organisations lack the resources needed to help rectify the situation – skilled complex project managers are in short supply globally.

One initiative designed to overcome this shortage of ‘complex project managers’ and build an understanding of ‘complex project management’ is the International Centre for Complex Project Management (ICCPM).  ICCPM’s approach to complex project management is to see this capability as an extension of traditional project management (as inferred in the diagram above). The ICCPM view is that while traditional approaches are insufficient to effectively manage a complex project on their own, you cannot manage a complex project without a strong foundation based on these traditional skills and processes. The relationship is described by the ICCPM as:

What changes is in part the way the traditional capabilities such as scheduling and budgeting are used, overlaid with the expectation these artifacts will need to adjust and change as the situation around the project changes, augmented with a range of ‘special attributes’ particular to the process of managing a complex project. These ‘special attributes’ are valuable in the management of any project but become essential in the management of complex projects.  These capabilities and competencies are defined in the ICCPM’s Complex Project Manager Competency Standard available from: https://iccpm.com/.

Complex projects can vary in size from relatively small undertakings involving factors such as updating a complex systems-of-systems, or a high level of political sensitivity, through to the megaprojects discussed below. A complex project may not be a megaproject or even a major project, but every megaproject and many major projects will also be a complex project requiring complex project management capabilities for a successful outcome.

 

Megaproject Management

Megaprojects are defined as temporary endeavours (i.e. projects or programs) characterised by:

• A large investment commitment;
• Vast complexity (especially in organizational terms); and
• A long-lasting impact on the economy (of a country or region), the environment, and society.

They are initiatives that are physical, very expensive, and public. By definition, megaprojects are complex endeavours requiring a high degree of capability in the management of complex projects.  In addition megaprojects typically involve a number of other facets:

• Megaprojects are by definition a program of work (see: Defining Program Types).
• Many are implemented under government legislation, requiring skills and knowledge of government processes and the ability to operate within the ambit of ‘government’. This is a very different space in terms of accountability and transparency compared to private enterprise.
• Most interact with a range of government agencies at all levels of government from local to national. These stakeholders often have a very different set of agendas and success criteria compared to the organisation running the megaproject.
• The size of a typical megaproject involves large amounts of money and therefore increases the risk of corruption and other malfeasance – governance and controls need to be robust[2] to maintain high ethical standards.
• The ‘political attractiveness’ of doing a megaproject (eg, hosting the Olympics) distorts decision making; care in the megaproject development process is required to reduce the effect of optimism bias and strategic misrepresentation (see: The reference case for management reserves).
• Megaprojects are financially fragile[3] and fragility is typically irreversible. Once broken the fragile entity cannot be readily restored to its original function. Financial (or investment) fragility is defined as the vulnerability of a financial investment to becoming non-viable, i.e., losing its ability to create net economic value. For example, the cost risks for big dams are significant; the actual costs more than doubles the original estimate for 2 out of 10 dams; triples for 1 out of every 10 big dams. But managers do not seem to learn; forecasts today are likely to be as wrong as they were between 1934 and 2007.

Recognising the scope and complexity of managing a megaproject and training people appropriately can mitigate the risks, the UK experience around Terminal 5 and Cross Rail (both £4 billion projects) suggest that achieving a good outcome is viable provided the organisation commissioning the megaproject is prepared to invest in its management. It’s probably no coincidence the management of megaprojects and their associated risk has been the focus of the Saïd Business School, University of Oxford for many years.

 

Summary

The competencies needed to manage projects grows in line with the increase in complexity and the increase in size. There are definitely additional elements of competency needed at each step in the framework outlined above.  What is far less clear is how to demarcate between normal, complex and megaprojects! Every project has a degree of complexity and a degree of size.  The values suggested above to separate normal, major and mega projects are arbitrary and there is even less clarity as to the transition between normal and complex projects.

I suspect the domain map demarcating the different disciplines will end up looking something like this but there’s a lot of research needed to define the boundaries and assign values to the axis (especially in terms of measuring the degree of complexity).  Hopefully, this blog will serve to start the discussion.

______________________

 

[1] Normal accidents are system accidents that are inevitable in extremely complex systems. The three
conditions that make a system likely to be susceptible to Normal Accidents are:
–  The system is complex
–  The system is tightly coupled
–  The system has catastrophic potential
The characteristic of the system leads to multiple failures which interact with each other, despite efforts to avoid them.

[2] For more on governance and ethics see: http://www.mosaicprojects.com.au/PM-Knowledge_Index.html#OrgGov1

[3] From: Big Is Fragile: An Attempt at Theorizing Scale, in Bent Flyvbjerg, ed., The Oxford Handbook of Megaproject Management (Oxford: Oxford University Press)

Project Management 2.0

Project Management 2.0 (PM 2.0) seems to be going the same way some Agile anarchists are trying to take software development which is essentially not to do project management and hope a group of people with good will and good luck will create something useful.

Not doing ‘project management’ is a really good idea if you and your client have no idea what’s needed, when its required, or how much budget is available. Journeys of exploration can be fun and can be highly creative but are nothing to do with managing projects.

Wikipedia (retrieved 27/9/2009 from: http://en.wikipedia.org/wiki/Project_management_2.0) lists the following differences between PM 2.0 and ‘traditional’ project management.

PM 2.0 -v- Traditional PM

Whoever wrote this has absolutely no idea what good traditional project management looks like and has probably never worked on a successful major project. Good traditional project management differs from this highly subjective and biased list in many ways:

• Control is not centralised, authority and responsibility are devolved to the appropriate management levels.
• All good project management is based on collaboration.
• All good project management requires open access to the plan both as an input to its creation and to know what needs doing during delivery.
• Access to information is vial when and where needed.
• Open and effective communication is critical.
• Project are,  by definition, separate management entities – a holistic approach (ie, not doing projects) is called general management.
• Tools, see: A fool with a tool is still a fool, and you need the right tools for the right job. Amateurs try to do jobs with inappropriate tools. Easy to use and flexible are fine if you know exactly what you are doing, it is a recipe for wrong information and wrong decisions if you don’t.

The table is correct in so much as project management involves a degree of top down planning. Project management is about delivering a required output to the specifications requested by the client. The product or service is a failure if it does not meet the quality requirements set by the customer; which may include time, cost and scope parameters.

It is also correct in respect of the implied structure – projects work because there is an implied structure that sets a framework for collaboration. If you don’t know who is doing what it is nearly impossible to collaborate. Even Wikipedia and Linux have structure in their collaborative frameworks.

I have emphasised good project management throughout this post. Bad project management involves excessive attempts to ‘control the future’, lack of stakeholder involvement, excessive bureaucracy, and many other problems. These traits are bad management full stop.

One comment on the Wikipedia article is important though: PM 2.0 is good for small jobs. This is consistent with a survey of construction projects in the UK undertaken by the Chartered Institute of Building, focused on time management, which found that on ‘simple projects’ there was no difference in performance between those projects with a properly developed and managed schedule and those without. The same proportions finished early, on time and late.

However, as soon as the projects became ‘complex’; there was a marked difference in performance. Projects with effective schedule control performed significantly better than those without, and the bigger/more complex the project, the more significant the difference. ( I will put up a post on the CIOB’s work and its new practice standard for scheduling in a few days).

The CIOB’s findings and a closer look at many of the blogs and comments on both PM 2.0 and Agile seem to fit this trend. I would suggest two conclusions could be drawn:

1. If the work is small, simple and easy to understand there is no need for much in the way of traditional project controls. Knowledgeable people know what needs to be done and can just get on with the work.
2. If the required output is not capable of being determined by the client and the objective is to ‘create something wonderful’ it is very difficult to apply too many project management techniques – basically you don’t know what needs to be planned, costed and scheduled, etc. Time and cost are secondary to creativity and the exploration of problems.

In both of these circumstances traditional project management may not be appropriate. In fact I would question if either circumstance is actually a project given the definition of a project is to produce a defined product, service or result that meets the needs of a customer.

The challenge for senior organisational management is recognising the threshold where PM 2.0 and ‘free form Agile’ cease to be appropriate and more traditional forms of project management are needed. Traditional project management does not mean ridged control, the type of project influences what’s needed (see: Projects aren’t projects – Typology) but appropriate systems do help optimize cost, time and quality to deliver client satisfaction.

This does not mean dumping the new ideas, rather melding them into an improved project management process. Agile software development fits in nicely to ‘rolling wave’ planning. Similarly some aspects of PM 2.0 can really help enhance team communication and collaboration. Used wisely, these ideas and technologies simply help improve the way projects work to deliver quality outputs to their clients. This change is really no different to the shift from faxes and carbon copy paper to emails. Good project management has always adapted to use improvements in processes and technology to improve the quality of service provided to the project’s clients. This next wave of improved technologies should be no different.

However, be wary of the zealots suggesting the ‘old ways’ don’t work and should be abandoned and use examples of really bad project management to prove their point. This is even more important if the zealots also advocate employing them to solve all of your problems for a fee. Management fads come and go – modern project management has been generally successful in achieving positive outcomes for well over 50 years now and continues to evolve and improve. For further comment see Glen’s post on: Herding Cats

Complexity

As readers of this blog and our published papers would know I have a passing interest in complexity theory and its application to project management. This seems to be an expanding area of interest world wide.

Last night I was at the PMI Canberra Chapter presenting a summary of my paper ‘Scheduling in the Age of Complexity’ [download the paper] – another good reception for the ideas but more importantly several people in the audience were involved in parallel lines of enquiry. Possibly of most interest is the ideas of Graham Durant-Law see his blog at http://www.durantlaw.info.

Another interesting development is a new publication from PMI, Exploring the Complexity of Projects written by Svetlana Cicmil, Terry Cooke-Davies, Lynn Crawford and Kurt Richardson [see: http://www.pmi.org/Marketplace/Pages/Default.aspx] A quick skim suggests this is a comprehensive round up of the current state of complexity theory in project management. More on this once I have had a chance to read it.

What is gratifying is seeing the confusion created by the so called ‘College of Complex Project Managers’ and Prof. David Dombkins receding rapidly into obscurity. Rather than the confusion caused by the ‘college’ treating large complicated programs of work as a synonym for complexity theory (as Dombkins did in the original College manifesto); thought leaders world wide seem to be:

• Agreeing the difference between projects and programs [see: Understanding Programs and Projects]
• Appreciating the various ‘dimensions’ of a project [see: Projects aren’t Projects]
• Developing structures for differentiating and classifying projects [eg, Project Categorization Systems published by PMI http://www.pmi.org/Marketplace/Pages/Default.aspx]
• Recognising different dimensions of project uncertainty and complexity
   –  The ‘uncertainty’ view outlined by Eddie Obeng and Rodney Turner discussed in Projects aren’t Projects – Typology
   – The ‘complexity’ view defined by David Snowden that draws on research into complex adaptive systems theory and explores the relationship between man, experience and context [see: The Cynefin framework]

The work on understanding complexity in project management has a long way to go and will undoubtedly be the subject of future blogs. Your contribution to the discussion will be welcome.

Complex Projects

Further to two earlier posts on the subject projects aren’t projects I have run across an interesting journal paper from Jon Whitty focused on Complexity.

A number of organisations are promoting the concept of ‘complex project management’; many other commentators, including me, feel complexity is a factor in every project. The elements of complexity theory include non linearity, emergence and unpredictability. In project management space, this translates to the interactions of people involved in and around the project to each other and to the project work (for more on this see A Simple View of Complexity in Project Management).

Jon’s paper reinforces the argument that projects have multiple dimensions and additionally projects and programs are quite different. Whilst there is likely to be a correlation between size and complexity, the two dimensions are not directly related! To read more see:

• Whitty, S.J. & Maylor, H. (2009) And then came Complex Project Management (revised). International Journal of Project Management, 27 (3) 304-310.
• Projects aren’t projects
• Projects aren’t projects – Typology

What is a project??????

The current definitions of a project have a common theme, but generally fail to differentiate projects from on-going operations. With governments world-wide starting to legislate about ‘projects’ we need to tighten up these definitions from within our profession before lawyers do the job for us!

There seems to be two elements of a project that clearly separate the practice and profession from operational work. These are:

• Projects are about creating change. Turning a block of land into a building, developing a new business process, or writing a software program. At the end of the project there’s something significantly different in the world.
• Projects are also temporary organisations. The key role of a project manager is to develop the temporary team, lead them in the work of the project and then dissipate the team at the end as the output from the project is transitioned to the client or operational users.

If these two factors are present, the endeavour is almost certainly a project. If one is present, it may be a project.

How do these ideas compare to the current definition of a project? The PMBOK® Guide has the following key elements in its definition:

• It is a temporary endeavour*. Whilst this is true of a project, all endeavours are temporary. Endeavour is synonymous with ‘work’ and all work is temporary. The work by the accounts department to process the end of month accounts in a business is temporary but highly unlikely to be a project.
• To create a unique product, service or result. Again whilst this is true, virtually every product, service or result is ‘unique’. Every Ford motorcar rolling off a production line is unique; it has a unique chassis number, a unique engine number, and has been made at a different time to the cars before it and after it. The difference between a project and an operational production item is the project is intended to create a distinct change. Producing a routine set of monthly accounts or another car from a production line is business as usual – the operation’s management may be looking for incremental improvements in their process but not change. The result of a project is a change in the environment (eg, a new building) or a change in the way the organisation works.

Other standards add additional factors to the PMBOK’s starting point such as the need for coordinated activities over time (dates), the use of resources and the presence of risk. None of these additional factors differentiate a project from operational work; all endeavours involve coordinating the activities of resources over time to achieve the intended outcome, and the outcome is always at risk.

The change needed to existing definitions of a project to actively differentiate projects from operational work is not great. The PMBOK definition could be amended from:

A temporary endeavor to create a unique product, service or result.

to:

An endeavor, undertaken by a temporary team to create a new or changed, product, service or result.

This definition may not be perfect but it’s a lot closer to differentiating projects from operational work. 

Your comments will be appreciated.

*Definitions of endeavour (various sources)=
 – a purposeful or industrious undertaking
 – an earnest and conscientious activity intended to do or accomplish something
 – an effort to do something
 – an attempt by employing effort

Projects aren’t projects – Typology

Following on from my first post on ‘projects aren’t projects‘; one of the more established ways of describing projects is a typology that maps the interaction of uncertainty and technical difficulty. Knowing both ‘what to do’ and ‘how to do it’; or more importantly knowing how much you know about these two elements. The typology was developed by Eddie Obeng in the Project Leader’s Secret Handbook.

Project Typology

The typology asks two questions:

• Are you clear about what to do (the outcome to be achieved)?
• Do you know how to do it (processes, methods, experience)?

Painting by Numbers
Traditional project management works well when both ‘what’s to be done’ and ‘how to do it’ are well understood by all key stakeholders including the client and the project team. Closed projects (panting by numbers) can be fully defined, estimated, planned, etc. There are low levels of uncertainty and ambiguity, risks are largely known and manageable. Value is largely achieved by delivering the requirements on time and on budget.

A typical software project of this type would be installing a software upgrade into an office where the same upgrade had been previously installed in several other locations.

Going on a Quest
In these projects, the objective is clear but the way to achieve the objective is uncertain. At the end of the day, success or failure is clear cut; the objective has been achieved (or not). The challenge is optimizing the way forward. Process and system improvement projects tend to fall into this category. The objective is to reduce processing time by 20% – this is easily measured on the completion of the project. The difficulty is knowing what’s the best way to achieve the objective. Improving the user interface, simplifying the work flow, speeding up network traffic and processing times or a combination? Ambiguity is low – we know what’s needed, uncertainty is high – we are not sure how to achieve it.

Before committing major resources to the main work of the project adequate time has to be allowed to prototype solutions and test options before a final design solution can be determined and then implemented. The project needs to be developed in phases with go/no go gateways as the design is firmed up. There are risks associated with any creative design process and most software projects are ‘quests’ requiring creative solutions to identified problems to achieve the desired objective.

Making a Movie
In these projects the tools and techniques are well known but the final outcome is uncertain. Only after the project is complete can the results be measured and the success or failure of the project determined. Most culture change projects and marketing projects (and making movies) are in this category. The tools to be used including: training, communicating, advertising, etc are well known and the traditional (if not optimal) mix of techniques understood for most situations. What no one can predict is if the ‘public’ will acclaim the final result, merely accept the final result or dump the final result.

Traditional project management is not enough in these projects; there is a continual need to measure results, feedback information and adapt the mix of activities to optimize the likelihood of success. The key value measurement is attempting to answer the question is it worth spending more or should we cut and run? Efficient stakeholder communication and relationship management is crucial. Whilst there will be some outstanding successes (block busters) and some total flops most projects in this category finish somewhere in the middle. The art is spending just enough effort to achieve an acceptable outcome – dealing with shades of grey.

Lost in the Fog
I actually prefer Prof. Rodney Turner’s version ‘a walk in the fog’. This project is a journey towards a desired new state. No one is sure of the optimum outcome, or how best to achieve it. The only option is to proceed carefully, stop at regular intervals to check exactly where you are and re-plan the way forward. Exactly the way you navigate through a thick fog. Both ambiguity and uncertainty are high.

Project management is about making sure at each ‘stop point’ the value achieved to date is locked in and then refocus on the next increment. Agile software development is ideal for this type of project. Each iteration builds new capability and value and the learning provides a platform for the next iteration of development.

Management is both easy and difficult. It is easy because there is no point in setting fixed plans (you have no idea what to plan). It is difficult because decisions on value and whether to stop or continue are subjective and need to be made in a collaborative environment of trust. Traditional measures of success such as on-time and on-budget are largely meaningless; typically there are no statistics to base this type of measure on. Consequently these projects are the realm of cost reimbursable contracts and partnerships; stakeholder relationship management, and a clear understanding of value are the only effective tools for building to a successful outcome.

Two final thoughts
The skills required of a project manager change from largely technical if the project is ‘painting by numbers’ to almost completely relational to manage a ‘walk in the fog’. For more on this see: Tapping the Power Lines and The Accidental Project Manager – The Getting of Wisdom

Both the client/sponsor and the project team need an understanding of the type of project and agree to configure the project management processes appropriately. The more uncertainty and ambiguity, the more important the project  client is to achieving project success!

More later.