How complexity affects project delivery

05. 06. 19 John Chapman

Project complexity blog by John Chapman

At Touchstone, we have many years of experience in implementing software for organisations of all different shapes, sizes and industries. One of the questions we are usually asked in the early stages of a project, or even in the early stages of pre-sales is “How long will it take?”

Now, this is a very valid question, and not least because it may well have an impact on the other big question “How much will it cost?” The answer to both of these questions will be affected in no small way by the complexity of your project.

When putting together a proposal for an implementation project, there will always be a number of “known-unknowns”, the experience and knowledge of our team means that we can often account for these and build contingency into our proposals, we would always rather give you a nice surprise at the end of your project, coming in under time and budget, than the nasty shock of running well over time and budget. We pride ourselves on the quality of our service and products, and our proposals will always be put together from knowledge based on time taken to understand your requirements and project need, as well as to understand any potential complexities for your implementation.

John Chapman, Touchstone’s Programme Director discusses the possible complexities of your implementation project, as well as the risks involved, and steps that can be taken to mitigate these risks.

There are three types of Complexity to consider:

  • Structural Complexity
  • Emergent Complexity
  • Socio political Complexity

Structural complexity

Structural Complexity also termed as Blue Bucket ‘This type of complexity is related to traditional ways of assessing a project in terms of size and scope for example:

  • How technically complex is the project?
  • How much work needs to get done?
  • How many people are involved?
  • How many sub-contractors need to be engaged and across how many locations?

In other words, structural complexity is a measure of how many moving parts there are on your project’.

Types of project:

  • Finance system upgrades,
  • Spend control system upgrades,
  • Additional software module implementations,
  • Single software solution implementations where the system is a replacement (not greenfield sites) such as a new finance system

Management of structural complexity

For the project delivery we will define the work breakdown structure, develop the responsibility assignment matrix, a detailed project plan, resource plan, risk register and a fairly rigid approach to work. Project progress reviews will be based on % complete assessment against each deliverable. The individuals involved will understand the nature and scope of work. There will be few new processes implemented.

Emergent Complexity

Emergent complexity, also termed as Green Bucket. ‘How much is your project and its surroundings changing as you are trying to manage it? Is the client or the team constantly changing or new stakeholders emerging? We already know that change is inevitable on projects, but some projects are more subjected to change than others. If you’re working on a highly innovative project or a project that is dependent on external world events, the emergent complexity will be high’.

Types of project:

  • New system implementations where multiple modules are being delivered. An example is Finance, Spend Control, Document Management with early and late archiving, integrations across solutions, process automation and job descriptions changing.
  • Spend Control implementations with automated purchase order / receipting procedures
  • Supplier relationship management system implementations
  • Education and Effectiveness: Training requirements will change, new individuals need to be educated in the system and business processes. Education may also be needed in a wider context an example being finance for non-finance people to understand how budgeting and forecasting works from a theoretical perspective.
  • Business process requirements: Definition of new business processes, amendment to existing business processes to deal with new organisation structure need to be understood from the ‘As Is’ to the ‘To Be’ state
  • Requirements and Configuration: updates to system setup, such as additional analysis codes for new cost centres, new departments are likely to require incorporating as the project is delivered. Change freeze on configuration is not an option.
  • Data migration: incorporation of legacy data into the system as new business are acquired, legacy systems decommissioned, data content and structure may be an unknown.
  • Project management: additional levels of planning and resourcing to be provided for, budget changes to reflect the management of the above. Management of Project Board expectation at initiation to expect changes to the project profile. Consider increasing levels of tolerance that the project manager has (risk, budget, time).
  • Multiple solution delivery with many interdependencies, processes difficult to define upfront
  • Business intelligence implementations where the outputs are unclear (e.g. BI reporting where users are asking ‘what is possible?’, and / or the replacement of hugely complex spreadsheets that have evolved over time)
  • Contract Management System implementations with business processes changes including supplier performance analysis based on end user feedback.

Management of Emergent complexity

In addition to the planning activities that are required for Structural Complexity, be prepared for changes to the implementation workstreams of:

Socio political Complexity

Socio political Complexity also termed as Red Bucket. ‘This type of complexity is about soft skills, relationships, personalities and behaviours that arise under stress. It’s not obvious how to manage a group of clients and stakeholders who change their minds and who behave in infinitely complex ways, especially under pressure’.

Types of project:

Management of Socio Political complexity

In addition to the planning activities that are required for Structural Complexity and to an extent Emergent Complexity consider what would be the appropriate delivery method. Waterfall is unlikely to be effective, a more ‘Agile’ approach with definitions of time and cost but not functionality.

  • Project management: perform a detailed stakeholder analysis at initiation to identify the impact on their working. How easy will it be to work with that stakeholder group e.g. external suppliers connecting to a portal. Is more elapsed time required to get consensus on decisions? Do the end users understand what is being asked of them? Will the Project Board need educating in how to deal with uncertainty. Will there need to be more stakeholder engagement at initiation and stakeholder monitoring during project delivery?
  • Requirements and configuration: Is prototyping a better method for defining what the end solution will look like? Should there be an iteration of build and structured walkthroughs.
  • Quality management: If prototyping / iterative configuration is the preferred approach, how will the system be tested?
  • Education and effectiveness: Assess the competencies of the individuals in their roles. Does there need to be more education in a wider context? Will they need extra support during implementation and post go live to fully embrace the new systems?


‘Complexity is a subjective notion, reflecting the lived experience of the people involved. … highly dependent on perception and influenced by conscious, subconscious, and affective factors’.

At project initiation we need to look at which type or types of complexity are relevant, and what activities to undertake to seek to minimise its impact. During delivery to continually reassess the complexity for it is likely to change as new information comes to light, unknown risks manifest themselves and the environment changes. On project closure to reflect, as part of our lessons learned, what can be learnt, and taken forward to the next projects.

  • Share on:
John Chapman

Written by:

John Chapman

Programme Director