User Groups | Interface Insight

Software Platform User Groups

As outlined here, Interface Insight is developing an innovative approach for Interface Control and Change Management, based on 'whole-systems-thinking'.

This has involved the creation of a bespoke new software platform, because there did not seem to be any software product commercially available that fulfilled the holistic needs of the new approach. The approach spans multiple technical and non-technical disciplines, and enables proactive identification of hidden interface problems both within and between those disciplines. It combines elements of Graph Theory, diagrammatic representations of projects, and analysis of project data: it is highly visual, and it outputs meaningful insights - fast.

Version 1 of that online platform - sufficient for demonstration purposes - has been built and tested. A library of example case studies is currently being compiled. Once ready for full-scale launch, the platform is expected to be made available through two routes:

directly through commercial licences;
indirectly through consultancy services.

In both cases, the platform will sit alongside any other proprietary/third-party Project Management or Document Management software that a Project Team chooses to use.

The method and the platform are relevant for many types of projects, across a wide spectrum of sectors and industries. Despite the formative ideas growing from experiences gained in offshore renewables projects, the underlying principles of the approach and the mathematics and logic behind the software's functionality are just as relevant and applicable elsewhere - for example, from planning new transportation networks, through to refurbishing an historic building: the method is extremely flexible.

Therefore, the tabs below outline a few of the currently anticipated 'User Groups' for the platform, once it is ready for launch. In the meantime, a variety of consultancy Services are outlined here.

The initial ideas for the software platform were based around the needs of 'Project Developers'.

In large and complex infrastructure projects, Project-delivery-companies often opt for a multi-contracting strategy. This allows commercial competition to be maximised for discrete packages of specialist work, in a bid to minimise baseline delivery price. One consequence of dividing up contracts like this is that the responsibility for managing all the interfaces between those contracts often falls to the Client - along with all the commercial risks associated with any mis-alignments between them.

Once those high-value contracts are signed, the counter-productive effects of silo-management can inadvertently take over. When this happens, time-consuming and expensive problems are almost inevitable. This is partly because offshore energy infrastructure projects currently represent an industry of superlatives.

In this respect, disruptive technologies are likely to keep emerging in response to increasingly challenging project contexts: further from shore; in deeper waters; with larger components; in colder climates; etc. Almost by definition, these disruptive technologies make it difficult to simply 'rinse and repeat' previous projects' successes.

Interface Control and Change Management activities for energy infrastructure projects will therefore be a continually evolving field for the foreseeable future.

Rather than multi-contracting, some 'Project Developers' may opt for an 'EPCI' approach (Engineer, Procure, Construct and Install: all through one single contract), so that they only have one main contractor to deal with. An 'EPCI' (which may or may not be a single company: it may itself be a consortium or Joint Venture (JV), etc.) then 'takes the commercial risk' regarding all the interfaces between the different aspects of the project delivery.

Whether 'EPCIs' and 'Project Developers' define the same Work Packages or use different terminology is unimportant here: the main point is that there will still be many different parts of the project that interact with each other, with many different types of dependencies between them. If one part of an 'EPCI' delivery team changes something, then there will usually be implications on other parts of the project: especially if the EPCI is a JV between different organisations in different parts of the supply chain.

In this scenario, the points outlined in the description of 'Project Developers' as a User-Group are largely relevant for 'EPCIs' as well. The risks are usually still there, even if the people responsible for managing them are different.

Many 'disruptive technologies' tend to be developed by small, specialist start-ups: teams of people with specific expertise focussed on their particular technological areas. Accordingly, they tend to focus on their technical niches, because their time and resources are precious and it makes sense for them to 'play to their strengths'.

One down-side to this is that broader 'system-wide' positive impacts might not be realised at the start, and therefore not fully leveraged when show-casing their disruptive technology: a case of 'not seeing the wood for the trees'. That is not to discredit the highly skilled experts developing such technologies, it's simply a recognition that no-one can be an expert at everything all at once.

For example, the design and construction of a large-scale offshore wind project requires specialist knowledge and experience in a huge number of different disciplines. It would be difficult for any new 'Technology Developer' to have, early in their development journey, a full understanding of all the positive ripple-effects that their new product/service could have across a whole project. Some benefits could stay hidden for a long time.

Mapping out those positive ripple-effects can lead to new insights about larger system-wide benefits, which ultimately expand the view about how much positive impact their disruptive product/service could bring. Recognising these broader benefits earlier on can enable enhanced sales and marketing strategies, accelerating their journeys to commercialisation.

Since starting this journey, a few unexpected conversations have occurred with people - from seemingly very different backgrounds - who have noted the outputs could be useful in their own 'Other' lines of work.

This is strangely (recursively?!) representative of points made under 'Technology Developers': i.e. not necessarily realising the full applicability of a new idea, and therefore its potential value to other people, until those unexpected and eye-opening conversations have happened.

An example of this involved someone working in the field of 'dispute mediation, commercial claims/counter-claims and settlements relating to construction of offshore renewables'. Dispute professionals may have to switch between many different areas of technical detail during each and every claim that they work on.

The person in question noted it would generally help to have a 'map' of inter-relationships between different parts of the overall project-specific 'system' when starting a new claim. This is because it would expedite the learning of a new technically-detailed subject quickly, at least in terms of gaining an outline understanding how the different organisations involved would view their role within the wider context of the overall delivery effort.

This is one example that will be explored and unpacked further - along with others - in due course. There may well be other 'User Groups', yet to be uncovered.

If you can relate to this, or you think you may be able to help identify other 'User Groups', we would be delighted to have a conversation - please use the Contact page.