Differentiating normal, complex and megaprojects

June 9, 2017

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 21st century.  The starting point is traditional project management as defined in the soon to be published 6th Edition of the PMBOK® Guide; the major change (incorporated in the 6th 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:


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 6th 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 6th 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 from 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 6th Edition and apply to every project. Where agile projects separate from traditional project 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 scientist 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 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, hosing 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.



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 Risk Management – how reliable is old data

January 28, 2016

One of the key underpinnings of risk management is reliable data to base probabilistic estimates of what may happen in the future.  The importance of understanding the reliability of the data being used is emphasised in PMBOK® Guide Risk Data Quality Assessment and virtually every other risk standard.

One of the tenets underpinning risk management in all of its forms from gambling to insurance is the assumption that reliable data about the past is a good indicator of what will happen in the future – there’s no certainty in this processes but there is degree of probability that future outcomes will be similar to past outcomes if the circumstances are similar. ‘Punters’ know this from their ‘form guides’, insurance companies rely on this to calculate premiums and almost every prediction of some future outcome relies on an analogous interpretation of similar past events. Project estimating and risk management is no different.

Every time or cost estimate is based on an understanding of past events of a similar nature; in fact the element that differentiates an estimate from a guess is having a basis for the estimate! See:

–  Duration Estimating

–  Cost Estimating

The skill in estimating both normal activities and risk events is understanding the available data, and being able to adapt the historical information to the current circumstances. This adaptation requires understanding the differences in the work between the old and the current and the reliability and the stability of the information being used. Range estimates (three point estimates) can be used to frame this information and allow a probabilistic assessment of the event; alternatively a simple ‘allowance’ can be made. For example, in my home state we ‘know’ three weeks a year is lost to inclement weather if the work is exposed to the elements.  Similarly office based projects in the city ‘know’ they can largely ignore the risk of power outages – they are extremely rare occurrences. But how reliable is this ‘knowledge’ gained over decades and based on weather records dating back 180 years?


Last year was the hottest year on record (by a significant margin) as was 2014 – increasing global temperatures increase the number of extreme weather events of all types and exceptionally hot days place major strains on the electrical distribution grids increasing the likelihood of blackouts.  What we don’t know because there is no reliable data is the consequences.  The risk of people not being able to get to work, blackouts and inclement weather events are different – but we don’t know how different.

Dealing with this uncertainty requires a different approach to risk management and a careful assessment of your stakeholders. Ideally some additional contingencies will be added to projects and additional mitigation action taken such as backing up during the day as well as at night – electrical storms tend to be a late afternoon / evening event. But these cost time and money…..

Getting stakeholder by-in is more difficult:

  • A small but significant number of people (including some in senior roles) flatly refuse to accept there is a problem. Despite the science they believe based on ‘personal observations’ the climate is not changing…….
  • A much larger number will not sanction any action that costs money without a cast iron assessment based on valid data. But there is no valid data, the consequences can be predicted based on modelling but there are no ‘facts’ based on historical events……..
  • Most of the rest will agree some action is needed but require an expert assessment of the likely effect and the value proposition for creating contingencies and implementing mitigation activities.


If it ain’t broke, don’t fix it???? 

The challenge facing everyone in management is deciding what to do:

  • Do nothing and respond heroically if needed?
  • Think through the risks and potential responses to be prepared (but wait to see what actually occurs)??
  • Take proactive action and incur the costs, but never being sure if they are needed???

There is no ‘right answer’ to this conundrum, we certainly cannot provide a recommendation because we ‘don’t know’ either.  But at least we know we don’t know!

head-in-sandI would suggest discussing what you don’t know about the consequences of climate change on your organisation is a serious conversation that needs to be started within your team and your wider stakeholder community.

Doing nothing may feel like a good options – wait and see (ie, procrastination) can be very attractive to a whole range of innate biases. But can you afford to do nothing?  Hoping for the best is not a viable strategy, even if inertia in your stakeholder community is intense. This challenge is a real opportunity to display leadership, communication and negotiation skills to facilitate a useful conversation.

Is your steering committee costing $5000 per hour?

December 13, 2015

The loaded cost of running a committee of senior managers can easily exceed $5000 per hour once the opportunity costs are included.  Productive committees offset this by creating value, hopefully significantly greater than their running costs.  Project and program steering committees should be no different!


However, if the steering committee is simply focused on ‘governance’ it is highly unlikely to be generating any significant value.  At the management level where most steering committees operate there is very little governance decision making needed and conformance and assurance usually needs specialists.

The first four functions of governance defined in The Functions of Governance are:

  • Determining the objectives of the organisation: this is done by the organisation’s governing body and implemented through the strategic plan. The project should have been selected because it contributes to achieving the strategic plan, a function of portfolio management, but once the project has started it is rather too late.
  • Determining the ethics of the organisation: this is done by the organisation’s governing body; it is a duty of every manager to support the organisation’s ethical standards and ensure the people they are managing conform. But you do not need a committee to ensure this occurs, just the project manager’s line manager (usually the Sponsor).
  • Creating the culture of the organisation: again this is done by the organisation’s governing body; it is a duty of every manager to support the organisation’s cultural standards and ensure the people they are managing conform. But you do not need a committee to ensure this occurs, just the project manager’s line manager (usually the Sponsor).
  • Designing and implementing the governance framework for the organisation: this should be done before the project is started and include delegations of authority for expenditure and decision making and escalation paths. If it has not been done, one half hour meeting of the sponsor and a few key managers can set the delegations.

In summary, the aspects of governance that determine the way the organisation operates and how the project or program will fit into the overall governance framework does not need a monthly meeting of any type.  There are management responsibilities but these are vested in the responsible line manager, typically the Sponsor (see more on the role of a Sponsor).

The final two functions of governance are ensuring accountability by management and conformance by the organisation.  A steering committee can certainly focus on these aspects of governance but if they do, they are largely wasting their time and most of the $5000 per hour.  There are two fundamental reasons for this:

  1. It is extremely poor governance for a managing entity to seek to provide assurance that the people it is managing are conforming. Assurance oversight should be provided by an independent body.
  2. Most aspects of project surveillance and assurance require high levels of technical skill. It is highly unlikely any of the managers on a steering committee posses these skills (see more on project surveillance).

The organisational entity best suited for the work of surveillance and assurance is a PMO with appropriate support from management. If there is an effective PMO structure in place with the ability to identify shortcomings, backed up by responsible line management there is no need for another committee to second guess the process a few weeks later (see more on PMOs).


Some of the completely unproductive ‘governance’ functions undertaken by ‘steering committees’ include:

  • Validating correct procedures have been followed (properly resourced PMOs are a better and cheaper option).
  • Discussing negative variances and allocating blame (management action is needed not committee discussions).
  • Second guessing management decisions after the event and interfering in the day-to-day running of the project (project professionals are not helped by interference from amateurs – even if they are senior managers).
  • Listening to lengthy reports on what has happened during the last month (effective reporting is all that is needed).

Being involved in this type of activity may make the steering committee members feel important but contributes little or nothing of value in a well governed and structured organisation; if the organisation is not well governed and structured the committee members would be far better off focusing on fixing the real problems.


Steering Committees can be highly valuable!

The constitution of most steering committees creates a real opportunity to add value to the overall management of a project or program, but only if the committee focuses on helping craft success. Steering committees typically include members from a range of areas within the organisational affected by the project and its deliverables. Therefore as a group its members are uniquely placed to assist the project manager and sponsor deliver a successful project by helping them steer a path through the organisational politics and stakeholder issues that confront any project or program.

This objective can be achieved by making the members of the steering committee personally responsible for the realisation of value from the organisation’s investment in project, and in particular for dealing with the organisational change and stakeholder issues that are outside of the project manager’s responsibilities. Some of the key responsibilities allocated to the steering committee may include:

  • Responsibility for preparing the organisation for the changes needed to make use of the project’s deliverables and the realisation of value.
  • Managing the interface between the project and the organisational change management work
  • Being available to assist in the management of stakeholder issues escalated from the project and/or identified in areas outside of the direct influence of the project.
  • Ensuring effective benefits management is in place for the life of the initiative (ie, it continues after the project is closed).
  • Dealing with any other aspect of organisational politics that may affect the work of the project or the on-going change initiative.
  • Making value based decisions on complex change proposals, including contributing positively to the resolution of intractable problems, to optimise the value outcome for the organisation.

Obviously the steering committee also needs to take an interest in the project its steering to success. The problem is these are all management activities, not governance activities (for more on this see Does organisational governance exist?).

Effective steering committees work with the project manager and sponsor to identify the external influences causing problems and help the project successfully navigate the organisational stakeholder environment. They also resist the urge to interfere in the actual running of the project or program. There is a world of difference between a collaborative and supportive approach focused on success and the negative approach adopted by so many steering committees that seems to translate ‘governance’ into giving the project manager a ‘hard time’ to ensure compliance with ‘due process’ even if this adds to the existing problems.

Are your organisation’s steering committees worth their hourly running costs?

What’s in a Name?

May 14, 2015

When it comes to effective communication, a clear, concise and easily defined name for something is essential if you want people who are not directly involved in your special disciple to understand your message.  Jargon and ambiguity destroy understanding and damage credibility.

Potentially one of the major reasons senior executives still fail to understand ‘project management’ within their organisations is the fact that the project management profession uses its special terms in a multitude of different ways……

There are four generally recognised focuses within the overall domain of ‘project management’ Portfolio management, Program management, Project management and the overarching capabilities needed by an organisation to use project, program and portfolio (PPP) management effectively.

The starting problem is implicit in the above paragraph, ‘project management’ can be used as a ‘collective noun’ and mean all four areas of management or specifically to mean the management of a project.

The next problem is if project management means the management of a project, exactly what is a project?  The current definitions for a project are very imprecise and can apply to virtually anything. A more precise definition is discussed in Project Fact or Fiction.

Program management is fairly consistently defined in the literature and involves both the management of multiple projects and the realisation of benefits for the organisation. There are still legacy problems though; the ‘Manhattan Project’ to create the first atomic bombs during WW2 was a massive program of work involving dozens of separate projects.

Similarly, Portfolio management is fairly consistently defined. The core element of portfolio management is deciding on the best investment strategy for the organisation to meet its strategic objective through investing in new selected projects and programs and reviewing current ‘investments’ to ensure the project or program is continuing to deliver value (and closing those that are not to redirect the resources to a better ‘investment option’.

Both Program management and Portfolio management are relatively new concepts and have the advantage of being developed at a time where wide reaching communication was relatively easy allowing a consistency of though and definition. Where the real problems emerge is in the realm of the overall organisational capabilities to use PPP concepts effectively.

The management space around the core PPP management functions includes:

  • Governance
  • Multi-Project management
  • Organisational enablers such as PMOs, etc
  • The ‘management of projects’ (Prof. Peter Morris)
  • Benefits realisation
  • Organisational change management
  • Value creation

In general terms this area of management responsibilities can be picked up if ‘project management’ is used as an overarching term. Some times, some aspects get absorbed into people’s definition of portfolio management and program management. But this ‘absorption’ does not really help develop clarity; for example,  whilst benefits realisation is generally seen as part of program management, this does not help deal with the realisation of benefits for the 1000s of project that are not part of a program, etc.

Apart from project, program and portfolio management as defined I believe the global project management community, including academia and the major associations need to make a focused effort to develop a ‘standard’ naming convention for these various aspects of ‘project management’ – if we cannot be consistent in our use of terms our stakeholders will be permanently confused and confused stakeholders are unlikely to be supportive!

I feel there are three distinct aspects to this ‘fuzzy space’:

  • The second is the ability of an organisation to effectively select and support its project, program and portfolio management efforts. This includes the ‘management of projects’, organisation enablers and multi-project management: The Strategic Management of Projects.
  • The third area is the link between PPP, operations, strategy and value, encompassing benefits realisation, value creation and integration with organisational change management (which is an already established management discipline). I don’t have a good name for this critical area of our professions contribution to organisations but it is probably the most important from the perspective of executive management.

The overall architecture of the discipline of PPP management looks something like this:



The challenge is to start moving towards a consensus on a naming convention for these aspects of ‘project management’ so we can start communicating clearly and concisely with all of our stakeholders.  Hopefully this post will start some discussions.

Mind your language

August 15, 2014

Communicating ideas effectively to another person needs a common language, and a common understanding of the meaning of the symbols used in the language. While this sounds simple, language can take many forms including images, sounds and writing. This post is going to focus on the design and use of images as the language for communication.

The use of images as a language stretches back to the Ancient Egyptians. They developed a written language based on stylised pictures whereas the civilisations in the ‘fertile crescent’ developed cuneiform text.


Whist we may not be able to read the Egyptian script, many of these hieroglyphs are easily understandable.


Whereas the cuneiform script is completely indecipherable. However, just because we can identify a goose at the top of the third column of the hieroglyphs, it does not mean we understand its meaning!

A simplified graphical language can provide a really useful way of communicating complex information but when you use the language, you need to be sure the people you are communicating with have the same level of understanding you do and ‘see’ the same message.

One of the first attempts to stylise complex information and to make it accessible and easy to understand was the development of the London Underground map.

The London Underground Map

The London Underground is one of the most complicated systems in the world.  By the middle of the 20th century the map was becoming too complicated for easy use.

1931 Underground Map.

1930 Underground Map.

The concept of the topological map we all know and use was developed by Henry Charles Beck. ‘Harry’ Beck was an English engineering draftsman at the London Underground Signals Office. He developed the first ‘topological map’ in his spare time, based on an electrical wiring diagram.

London Underground was initially sceptical of Beck’s radical proposal and tentatively introduced to the public in a small pamphlet in 1933. It immediately became popular, and the Underground has used topological maps to illustrate the network ever since. There is even a book on the map: Ken Garland’s, Mr Beck’s Underground Map (Capital Transport Publishing 1994). The book describes the enormous care, craft, thought, and hard work of Harry Beck that went on for decades (exactly what it takes to do great information design).

Beck’s version of the 1930 Map.

Beck’s version of the 1930 Map.

This style of communication has carried through to modern times but is not without its problems – you can easily get to the station you want, but there is no indication of how close or how far apart different stations are ‘on the surface’ – particularly if the stations are on different lines.

The current London Underground Map.

The current London Underground Map.

Success is contagious; most transport maps world-wide follow Henry Beck’s lead and a new universal language has been created.

Part of the new Melbourne Tram Map, using a version of Beck’s language.

Part of the new Melbourne Tram Map, using a version of Beck’s language.

The Melbourne map uses the same style as the underground map – lines are vertical horizontal or at 45 degrees, but unlike the underground stations, tram stops are not shown; the designers believe the street names and route numbers are more important.

Part of the Stuttgart Metro map

Part of the Stuttgart Metro map

Based on your knowledge of the London or Melbourne maps, you do not need to be able to read German to have a good idea how to navigate the Stuttgart metro from the Hauptbahnhof to the Zoo. The language of transport maps has become fairly standard world-wide.

However, design of the communication is still important; the designers of each map need to decide what is important (eg, the route numbers on the tram map), what is emphasised, what is suppressed, and what is left out – bad design can reduce the elegance of the communication and block understanding. Whereas innovation can enhance it – the Tokyo train system has its trains painted the same colour as the line used on the transport map – the orange trains follow the orange route and you ret to the right platform by following the orange signs!

A similar convergence of communication style has occurred with in-car road maps. Most books and electronic sat-nav systems use a stylised language similar to the map of North Sydney (below) – another language designed for a specific purpose.

North Sydney

North Sydney

For the purpose of navigating a car to the ‘Aiki Kunren Dojo’, this ‘simplified road map’ is far more useful than the 100% accurate photograph of the same location!

North Sydney

North Sydney

The style of the road map above has been taken ‘virtual’ and global by several organisations including Tomtom. You do not need to be able to read the street names or understand the spoken advice ‘turn left in ……’ to follow the map – the pictures say it all and are just as effective in Shanghai and Munich as Sydney or Melbourne.


When designing a graphical communication language, useful, accurate and fully detailed are not synonymous! Both of the mapping languages discussed so far are really simple to use provided you have learned to ‘read the language’ and interpret them correctly. But as we all know North Sydney looks like the Google Earth photograph (not the map) and Melbourne’s geography only has a passing resemblance to the tram map – but we have learned how to read the ‘language’ and can then use that knowledge of the language to understand similar maps in different cities.

Project Maps

The same challenge applies to project dashboards, reports, and artefacts such as bar charts and CPM diagrams. Creating an appropriate level of understanding in a person’s mind about the true situation of the project and your intended work plans requires appropriate information to be communicated in a language that is understandable to the stakeholder. In this context, ‘appropriate’ does not mean complete or fully detailed; selecting the right level of detail is in itself an art form.  The bar chart below may be fully detailed and precise but it is not a good communication tool!


And while preferred by many project controls professionals, the CPM logic diagram below is even less likely to work as a communication tool for stakeholders.


These specialist languages are useful to trained project controls professionals and some experienced project management professionals but are too complex for most communication needs.

As suggested above, effective communication does not need fully detailed or accurate representation. What is needed is ‘useful’ information that can be used!  You do not need to be an expert in directional boring to understand the plan for this project (all that is missing is the timing for each stage):


Simple is good, simplistic is dangerous! One of the popular options for reporting project status is using simplistic ‘red-amber-green’ (RAG) traffic lights such as these:

14.RAG health_image

We know there is a scope problem but there is no real indication of the seriousness of the situation or how far into the ‘red zone’ the project actually is.  Rather than the simplistic 3 point RAG scale, the same information can be displayed using more insightful tools:

15.Beter option

Any of the ‘gauges’ will tell you where within each band the project is situated, add in a simple ‘change’ report and the trend becomes apparent as well. The art is knowing how much information is enough.


From the hieroglyphs of the Ancient Egyptians to the Tomtom road map, the art of using pictures for effective communication is creating a set of symbols that communicate your ideas and information simply and accurately, and then taking the time to teach your stakeholders how to read the language.

Effective communication, focused on obtaining the understanding and buy-in from a stakeholder needed to deliver a successful project requires:

  • Understanding who are the key stakeholders at ‘this point in time’ that you need to influence;
  • Understanding their needs and the best way to communicate with them (the Stakeholder Circle®  methodology is designed for this purpose);
  • Communicating the appropriate amount of information in a way that can be understood by the stakeholder; and then,
  • Taking the time to help the person reach a proper understanding.

The communication challenge is recognising that some concepts will be easy to communicate in some communities of stakeholders, others will be more difficult; and people are frightened of things they don’t understand.

Designing an effective communication strategy requires the project team and project leaders to firstly derive a common understanding between themselves, then determine what the key stakeholders actually understand, then determine how to communicate effectively with the key stakeholders to build their understanding to the level needed to get the ‘buy-in’ required to make the project successful.

Effective communication is the tool that builds understanding, reduces opposition based in ‘fear of the unknown’ and generates a framework for success – for more on effective communication see: http://www.mosaicprojects.com.au/PM-Knowledge_Index.html#PPM07

Designing effective KPIs

August 5, 2014

KPI1In a couple of posts I highlighted the damage that poorly considered KPIs and incentive payments can cause either to the organisation or its customers:

This post fills the missing link and discusses the practical challenges of creating effective KPIs.

Key Performance Indicators (KPIs) exist to influence decisions and actions; effective KPIs motivate people towards taking valuable, and useful, actions and decisions.  Each KPI is a measure of how well a fundamental part of the project (or organisation) is progressing towards achieving its goals. The elements of a KPI are:

  • Key = something that is important, essential, fundamental.
  • Performance = the execution or accomplishment of work
  • Indicator = a measure, and record of variations

The specific purpose for each KPI is to communicate a relevant summary of the current situation to a particular person, or group; giving an indication of how effectively a particular element of the project (or work) is achieving its objectives. Because the KPI is an ‘indicator’ it does not have to be all encompassing, or provide all of the information about the activity. The purpose of a KPI is to highlight if and when more investigation is needed; they do not replace everyday ‘project controls data’ and other management information.

The challenge with KPIs is to set measures that provide indicators of potential problems in sufficient time to allow investigating and action.  The purpose of most projects is to create value through the realisation of benefits; unfortunately this ‘real measure’ only happens after the project is finished. So whilst tracking benefits realised is important, the information lags behind the actions that affect the outcome. Other leading indicators are needed that focus on the probability of generating value during the course of the work (which is more complex than simply measuring time and cost performance).



The way to design effective KPIs involves six simple steps:

  1. Understand your audience and tailor specific KPIs for different levels and groups within the project and the project’s stakeholder community. Detail should decrease as you move up that structure, what’s useful to a team leader is information overload for a sponsor.
  2. Be clear and concise. Each KPI should be designed to deliver a message that will instigate one of two decisions; either ‘do nothing’ or ‘investigate’! The KPI’s job is to tell you one of these three things (any more information and it is not an ‘indecator’):
    1. Things are looking bad – investigate and fix
    2. Things are looking good – investigate and learn
    3. Things are OK – do nothing.
  3. Make the KPI understandable. The KPI is an indicator of how well specific work is being done, or accomplished; being clear about precisely what work and what goals is critical. This means the KPI has to:
    1. Be well written;
    2. Contain one clear measure;
    3. Set realistic targets;
    4. Be time framed;
    5. Define how the data will be tracked.
  4. Balance the KPIs across the performance window:
    1. Input KPIs – measure the quantity and sometimes quality of inputs to the project.
    2. Process KPIs – measure the quantity and sometimes quality of the work required to produce certain expected outputs.
    3. Output KPIs – measure the quantity and sometimes quality of the goods or services created.
    4. Value KPIs – measure the quantity and sometimes quality of the results achieved through the delivery of the goods and services eg, benefits realised.
  5. Use both types of KPI:
    1. Target KPIs focus on achieving a specific measure (pass / fail), usually within a time frame, eg, units delivered per week.
    2. Directional KPIs measure tends. With many KPIs the precise number is less important than the trend. For example, “Number of days lost to staff sickness” [per month]. Here the exact number of days is not that useful as we can’t control this, however if the trend is rising we can investigate and take action accordingly.
  6. Test and fine tune the KPIs, make sure you are getting the results you want. As both of the referenced posts have demonstrated, it can lead to disaster if you simply design, then implement, a KPI as a way to allocate bonuses without fully understanding if and how it can be ‘gamed’ or how it will affect morale, or any other unforeseen outcomes. Therefore:
    1. Allow some lead time to check that everyone understands the KPIs, if the outcomes being measured are reasonable and the data is easy to collects and accurate.
    2. Trial the KPI to make sure it is driving the behaviours you desire.

Finally, the characteristics of good KPIs are:

  • Simplicity. The metric name should be less than 5 words and the calculation is easily described in under 10 words.
  • Comparability. The measure is comparable to other time periods, sites, or segments.
  • Incremental. A rate or ratio is better than an absolute or cumulative value.

Some good KPIs include:

  • The accident (and ‘near miss’) rate on engineering and other ‘hard hat’ projects, a low rate indicates a safe environment which means a clean, well managed and well planned workplace.
  • Performance measures such as the number of activities completed within 5% of the estimated time (the workers cannot control the start but can control the flow of work once started).
  • The number of open issues (and the trend), or the number of issues that remain open after a ‘reasonable’ period (say 2 weeks).
  • Quality measures.

A final thing is to remember setting two or three effective KPIs and using them effectively across all projects is better than a scattergun approach. You know you have too many KPIs when you hear people saying things such as the “top KPIs” or “most important KPIs”.  Keep them simple, consistent and rigorous for the maximum benefit.

The strategic management of projects

June 20, 2014

WP1074_PPP_ArchitectureOne of the clearest messages emerging from a range of sources is that ‘project management’ as defined by the PMBOK® Guide and other similar documents is simply not enough!  As Professor Peter Morris has been advocating for more then a decade, organisations need to be able to effectively manage projects.

The concept of strategically managing projects describes the organisation’s ability to select, nurture and deliver the right projects and programs effectively. This includes an emphasis on the ‘front end’ of the overall process to ensure the right projects and programs are selected and initiated for the right strategic reasons and the ‘back end’ to make sure the outputs from a project are used effectively by the organisation to realise the intended benefits.  Traditional ‘project (or program) management’ deals with the messy bit in the middle – delivering the required scope efficiently.

Project management skills are well defined as are some aspects of the strategic management of projects such as portfolio management and benefits management. What has still to emerge in the executive management and governance layer of an organisation’s hierarchy is an understanding of the integrated nature of the strategic management of projects. At the moment in many organisations the executives and ‘governors’ who allow their organisations to create failure after failure seem to be able to emerge unscathed by blaming the failures on lower level managers within the organisations they have created.  Some of the reasons projects are ‘set up to fail’ are discussed in this post by Patrick Weaver.

From my perspective, this is a systemic failure of governance and the governing bodies should be held accountable for the destruction of stakeholder value associated with systemic project and program failures. The governing body should not be directly accountable for any specific project failure, rather for failing to develop their organisation in a way that enables the effective development of a realistic and achievable strategy, and then strategically managing the right projects and programs needed to implement the strategy. An overall framework for this type of strategic management of projects is outlined in our White Paper.

Implementing the organisational change needed to create the broad range of capabilities needed to implement the strategic management of projects requires sustained senior executive support and a group of determined, enthusiastic and resilient practitioners to develop the organisations ‘project delivery capabilities’.  The biggest challenge is very few practitioners can explain what they are recommending in a language that is meaningful to executives or really understand the type of information executives need to make the best decisions.

Unfortunately complex detailed reports with dozens of RAG traffic lights and a focus on ‘time and budget’ won’t do the job. A different reporting paradigm is needed that looks at strategic alignment and the delivery of benefits to the organisation and its stakeholders.  Some ideas on the best ways to effectively communicate with executives are discussed in my book Advising Upwards.

It is definitely time to move the strategic management of projects to the next level and that is firmly into the ‘C-Suites’ and board rooms of organisations. Once this is accomplished, professional project managers will be better positioned to deliver their part of the value chain effectively.