Applying systems thinking to project management
Welcome to the first in a series of blog posts that aim to make the case for applying systems thinking to project management. The intention is to start a discussion with the broader APM community to share examples of where systems thinking has made a real difference to their projects and use this in turn to raise awareness of the main benefits and potential cost savings that a systems thinking-based approach can bring.
Why use systems thinking?
Systems thinking recognises that the world is made up of inter-connected entities which often produce behaviours that cannot be predicted by analysing their parts or their sums. While many projects don’t contain inter-connections, an increasing number involve significant inter-connection in the problems they are addressing and/ or the dynamic nature of the environments within which solutions must operate.
APM research, in Conditions For Project Success, found that only 22 per cent of projects are wholly successful, with 12 per cent not meeting their budget and 17 per cent not delivering on time; although 90 per cent of respondents considered their projects successful to some degree. Respondents identified the top three success factors as: 1) clear goals and objectives, 2) project planning and review, and 3) effective governance. These can be paraphrased as “ensure you are doing the right project and then do the project right”. Systems thinking supports both these by enabling the development of a deep understanding of both the complexity of the problem and how the solution will operate.
Research by the APM Systems Thinking SIG into how project managers use systems thinking, in Systems Thinking: How It Is Used In Projects and Project Management, found that the about half of project managers apply some systems thinking about half the time, but do not use the more powerful systems thinking tools. Systems thinking use is slightly greater by more experienced project managers and by those working in sectors delivering complex products (e.g. defence and aerospace).
When application of systems thinking is proposed, business managers ask how much it will reduce current budgets. The answer is that its application will reduce costs, but not from the current budget. It will reduce costs the project doesn’t know about yet (i.e. the overspend).
What is systems thinking?
Systems thinking is a discipline for seeing wholes rather than parts, patterns of change and for understanding the inter-connectedness that gives systems their unique character. It applies the following principles:
- Understand the bigger picture: identify patterns and trends as inputs, outputs and the environment change over time. Analyse events and responses to frame the problem in terms of patterns of behaviour rather than particular events.
- Recognise that a system's structure generates its behaviour: appreciate that connections must be understood and cause and effect relationships identified rather than focusing on details. Appreciate how internal actors managing policies and operations often drive behaviour rather than assuming all behaviour is driven externally.
- Make assumptions explicit and test them: recognise that models are hypotheses with limited applicability. Test them rather than trying to ‘prove’ them with existing or new data.
- Change perspective to increase understanding: regard causality as uncertain, with feedback influencing causes and don’t assume causality only runs one way. Different perspectives on a problem often identify a broader set of causes and relationships.
- Appreciate that mental models/ mindsets define current reality and expected futures: mental models are the assumptions, attitudes and expectations used to ‘understand’ situations and often define the 'truth'. They form the ‘mindset’ through which problems and their potential solutions are filtered. Appreciate that mindsets can be incomplete or incorrect.
A fuller description of systems thinking and its application to project management can be found in this published paper.
How is systems thinking applied to project management?
The systems thinking ‘iceberg’, given below, brings together systems thinking principles and tools.
- Events: the level at which we experience the world and the symptoms of problems. Some problems can be addressed directly, but not all problems can be solved by treating the symptom(s). Deeper analysis is needed.
- Patterns of behaviour: looking below the Events level identifies patterns of behaviour and enables Events to be forecast and hypotheses for their causes developed and tested.
- System structure: consideration of system structure (including elements of the environment within which the system operates) identifies the causes of the patterns of behaviour identified.
- Mental models/mindset: (often sub-conscious) mental models are the assumptions, beliefs and expectations that cause structures to function as they do and are used to drive problem analysis and solution definition.
Structure of the case
The structure of the case for the application of systems thinking to project management is shown below with initial content. Although it is difficult to include precise numbers for some sections, it should be possible to include orders of magnitude for best and worst cases.
Structure and main elements of the case for systems thinking in project management
Better solutions, and more successful projects
In summary, applying systems thinking to project management helps better understand the problem the project must address. This better understanding enables better solutions and more appropriate project management. Better solutions and more appropriate project management results in a more successful project.
Share your thoughts
Please share your thoughts and experiences by joining the discussion using the comments section below, joining the APM Systems Thinking SIG community or via the contact section on the APM SIG website.
Read other blogs in this series:
Using systems thinking to identify the right problem
Using systems thinking to define the right solution
Using systems thinking to establish the right project
Using systems thinking to execute the project right
How Portsmouth council used systems thinking to deliver a better service and reduce costs
Applying systems thinking to project management: summary and last thoughts
David Cole has 30 years experience of managing projects, programmes and portfolios to deliver products, services and business change in private and public sector organisations. As a management consultant he also advised these organisations on the management of their programmes and portfolios. He is a Chartered Engineer, a PRINCE2 Practitioner and a founder member of the APM Systems Thinking SIG.
He currently serves as the APM co-chair of the Systems Thinking SIG.
8 comments
Log in to post a comment, or create an account if you don't have one already.
I have read articles online about the subject of systems thinking. Can some one point me in the direction of any text books or course that might out there.
Hi David, there are many good books on the subject. You could try Systems Thinking, Systems Practice by Checkland, The Fifth Discipline: The art and practice of the learning organization by Senge or Images of Organization by Morgan.
Andrew , thank you I will take a look at those.
David, Andrew's suggestions are good ones. In addition, I'd suggest Donella Meadows 'Thinking In Systems'. Senge's 'The Fifth Discipline Fieldbook' builds on material in his original 'Fifth Discipline'. For more specific articles on aspecs of systems thinking I'd suggest The Systems Thinker (https://thesystemsthinker.com). The Open University has some courses (both free and that result in qualifications). The free ones can be found at https://www.open.edu/openlearn/science-maths-technology/engineering-technology/systems-thinking-free-courses.
David, Thank you as well I will look into these.
Hi David, not sure how to contact you but I was wondering if you were interested in doing a presentation to one of the local APM branches.
David, what are your thoughts on the apparent conflict between the ideas of systems thinking and common planning, controlling and contractual practices of project management? I am thinking in particular about the practice of managing a project by getting a firm commitment from task/work-package mangers, and holding them accountable for this commitment. This is embedded into practices like fixed-price contracting, critical path planning & EVM. The responsibility for managing inherent uncertainty in project work is 'pushed down' the WBS. My understanding of systems theory is that you cant optimise the whole by trying to optimise the parts, in fact the sum of 'optimised parts' is a sub-optimal whole. Meaning you cant get the most efficient project performance by trying making each part efficient and adding the parts together (as a WBS implies). Optimum systems require some parts to be sub-optimal. One practical implication of this is that a project will be better if it aggregates the allowances for uncertainty in time and cost estimates, holding a contingency buffer at the project-level, and not allowing individual tasks and work packages to have their own allowance for uncertainty. But if you do that you can't manage these tasks using simple approaches like holding people to their commitments, and fixed-price contracts are inappropriate. As you point out blaming a part for something that is likely to be the result of something systemic is inefficient and wasteful. But isn't that what we often try and do? If you do manage using aggregated uncertainty allowances, the project overall duration and cost can be significantly lower than holding people to account. Even better if portfolios do the same. Your thoughts?
Ian, Thanks for your comments. You raise a number of interesting points. I don’t see a conflict between systems thinking (ST) and common PM practices. I think ST supports PM processes and makes them more effective rather than replaces them. In terms of your comments: Using firm price contracting depends on the situation, industry and life cycle phase. While often ‘risk transfer’, overall liability associated with the product/ service being developed cannot be transferred and the two get confused. ST is useful to understand the ‘supplier’ perspective and likelihood they can deliver and support their delivery if they have problems delivering. ST is also useful to examine the mindset and assumptions driving the decision to go fixed price. The ST principle of recognising a systems structure generates its behaviour can help define the contract basis. Critical Path Planning is a valuable tool, but can mislead if not used with care as the critical path moves during the project driven by actual delivery and the critical path should be tracked as part of the monitoring and control process. If assumed not to have change, it can mislead at best and damage the project at worst. ST helps by considering the whole of the project , its structure and the relationships between components being developed: its ‘build logic’. It can be interesting to compare the build logic and critical path. Are they different, or the same. In either case, why? In practice, EVM measures the accuracy of initial estimates and is an exercise in geometry. EVM reporting is driven from the BCWP curve and the ACWP overlay (and how value is ‘earned’. The standard 0%/ 100% approach is ‘correct’, but tells the PM about problems after they’ve occurred. ST can provide support by ensuring the scope of the solution that the project is developing has been fully defined before generating the BCWS curves. I agree that uncertainty is often pushed down the WBS, usually to the level where it cannot be easily recognised or effectively managed. However, pushing uncertainty down is not usually done consciously, but driven by pressures higher up the WBS and the confusion between Risk and Liability. It may be pedantic, but I prefer to consider the PBS as it focusses on the ‘What’ rather than the ‘Who’ (and dilutes ‘blame games’). I think this is an area where ST can help by understanding the context of the project to help make these situations visible. I support management by getting firm commitments from task/ work-package managers (WPMs), provided these commitments are essentially realistic (although possibly demanding). If they are not essentially realistic, ‘holding to account’ will not resolve the situation. I also think there are two aspects to ‘commitment’: the first is the commitment to deliver from the WPM (which may or may not be sincere) and the second is the degree to which the WPM is committed to deliver. The first can be imposed, while the second comes from the WPM. The better communication of project context and consideration of the WPM’s perspective provided by ST helps get the WPM committed to delivery rather than just giving commitment to deliver. For optimisation, the best situation is to make the project ‘Pareto optimal’ where resources are allocated such that they cannot be reallocated to make any one area better off without making at least one other worse off. There are situations where this is necessary to achieve scope, quality, time or budget - your comment about sub-optimal elements. In my view, optimisation should to be done in the context of the project’s structure and build logic; although project content changes (hopefully reduces) as work completes and giving a similar situation to calculating the Critical Path. In practice, ‘optimisation’ will be done during initial planning with the PM managing to that plan. ST supports this planning by helping the PM understand the context and scope of the project, together with defining clear objectives with supportive sponsors and organisations. This frees the PM to manage issues during the project and concentrate on one issue at a time rather than several at once. Centralised uncertainty budgets. I disagree that holding centralised contingencies stops the PM holding WPMs to account. The issue is to what account(s) the WPMs are being held. Each work package has defined budgets to which the WPM has agreed. I suggest an approach based on tolerances (as Prince2 (copyright Axelos)), where each work package has a tolerance that, if forecast to be exceeded, the WPM reports an exception together with a plan (may require additional time and/ or budget) for its resolution. Allowances should be held centrally with the process for accessing them defined. This gives the efficiency of central holding and the effectiveness of holding WPMs to account. ST does not have much to say about this other than noting the PM’s and WPM’s mental models/ mindsets will drive the approach.