The legal opinions in this article are the author’s own, not WorldCC’s, and this is not legal advice.
This three-part series focuses on challenges of third-party suppliers and reveals why advanced planning and proper interventions in the precontract, “commercial” phase of a project is essential before we can prevent avoidable problems. Part 1 covers ways to balance buying with integrating advanced technology. Part 2 follows with a critical question: do we consider the integration question properly?
Advanced technology - integrate
Little doubt -- as we enter the fourth industrial revolution1 -- projects will increase and become ever more complex; and commercial teams supporting advancing technologies will soar in numbers and complexities. Also, multi-disciplinary projects will face pressures tied to client-side and supplier-side technical teams relating to many technologies integrating. And yet with forethought and planning, we can eliminate much of this tension.
It comes down to this issue: how much effort does your company invest in resolving technical problems up front at the project definition phase?
Defining what we mean – technology interface
Whenever organizations choose to buy advanced technologies via third party suppliers, they will always encounter integration questions at a practical level. And within that, interface questions will also arise about precisely how do subcomponents or subsystems link up with one another to empower a suprasystem to work as its designers intend?
Technology interface is a key risk area. Where a major project goes wrong it may well be because individual subsystems -- even though they meet contractual requirements and performance specifications -- fail in some way to properly integrate with other subelements of the system. This leads the overall suprasystem either to fail spectacularly, or at least operate below the required expectation. This, in turn, may cause contract disputes and operational problems -- all with associated bad publicity.
So, for this article, we define integration in this way: Subsystems that are component “parts” of a suprasystem work together in the way intended by the system designer (or architect) so that the suprasystem delivers value (outcomes) greater than the component parts.
More prosaically, we can say that the bits work together and the system works as intended! When properly integrated, subsystems “talk” with each other, exchange necessary information – especially data inputs and outputs – so that the suprasystem functions without fault – gets it right the first time!
In a broader sense, integration is all about ensuring that suprasystems incorporate “joined-up” thinking. It means that the delivery of goods or services to end customers involves concerted and detailed thinking about precisely how subcomponents (goods, services, and intellectual property) will work together. Where these elements are supplied under contract from third parties, the interrelationship of all interfaces needs to be identified, specified, and allocated under the terms of the contract between the parties. Further, any interdependencies are fully listed and the entire system of delivery to the end customer is understood to be a system where subcomponent parts must be integrated.
Specific to the above, the word interface, needs deeper definition. An interface is the precise point where two systems, subjects, organizations, etc. meet and interact. In physics an interface is a surface forming a common boundary between two portions of matter or space -- for example, between two immiscible liquids. We can think of interfaces within technology in the same way. So, the project manager and the project team must fully understand how subcomponent systems meet and interact with one another.
We can see, then, that the question of interface and integration is not solely confined to the world of technology or technical stuff! Where two service providers – when providing a service -- interact together, they interface and their efforts and these efforts need to be integrated. A simple non-technology example would be where a janitorial staff interfaces with a restaurant staff -- including cooks and waiters – to prevent cleaning and hygiene operations from interfering either with the cooking process or the practical movement of cooked meals into a restaurant area. In this case, the suprasystem has become a fully operational restaurant, where subcomponent service “systems” are cooking, cleaning, and waiting on customers at the table.The project team’s, integration questions need to be thought of as a strategy. Specifically, what is our corporate strategy in terms of integration? Our schematic below (Figure 1) suggests how we might think through this area:
Figure 1. Integrating who with what to get best output
Figure 1 schematic illustrates that potentially several stakeholders will need to contribute to the early stages of highlighting integration questions. We characterize the process in terms of who (individuals or roles); what (purpose of their interaction); and output (how will we know we have adequately undertaken this subelement of the project?). Although we have used the term engineer in the diagram, we do so loosely. This is not solely an engineering or a technical question. You may have your own preferred term for the role and the task.
The abbreviation “ID” refers to integration data in the schematic. The practical question is what information will each subsystem or subtask need to tell adjacent systems or tasks at the point of interface? Project teams must think through this aspect under the overall guidance of the project manager who will carry day-to-day responsibility for this activity.
Characterizing subsystem maturity
Given that we must integrate various subsystems so that the suprasystem works as intended, we need to assess which subsystem components or services are important relative to others. Doing this helps us avoid focusing resource uniformly across all subsystems but focus instead on where we anticipate difficulties.
Reasons for anticipating difficulties include novelty or complexity of the subsystem, and whether the design or technology is proven or mature versus unproven or novel. Once we understand the subsystems – and perhaps the sub-subsystems – in this way we can characterize the associated project risk associated with these subsystems and how they will integrate.The schematic below (Figure 2) pictures a simple way to help “tease-out” the issues. In this case, the subsystems are characterized by their maturity and familiarity to our organization so we can then map the direct and indirect interfacing requirements.
Figure 2. System control model receives data from each subsystem
There is a generic understanding in this schematic that some information flows are two-way while others are one way. Your task is to understand information flows comprehensively. At the center of the suprasystem in our schematic sits a system control module, receiving feeds from each subsystem. Armed with this sort of information the project manager and/or systems integrator will know where to focus additional attention and management (and perhaps contractual) expertise.
In terms of the key theme of buying and integrating advanced technology, we encourage readers to consider the integration question as a key subelement of any project, especially where the project involves technology components. Can we say that the integration task has its own lifecycle? It may be helpful to think of integration as a subject with a beginning, a middle and an end. The schematic below (Figure 3) helps frame this in context.
Figure 3. The integration task has its own lifecycle
We might consider that the integration lifecycle ends when the project ends and the suprasystem has been handed over to the ultimate client. It is likely, however, that all key decisions (and therefore the key project determinants) will have occurred prior to final hand over.
At a high level, the above illustrates the lifecycle of the task. When a system is being built and integrated, it is possible -- even likely -- that we may need to adjust Integration Data (ID) requirements or re-define them while the project is being executed. Depending on the complexity and nature of the supply contract, this activity may involve remedial work under the terms of the contract. Will this remedial work involve a compensatory payment to the supplier or to the customer for any additional work? It depends inevitably on the nature of the supply contract and on its specific terms.
If an advanced technology project goes wrong (and many do) then one key area where the “rot” originally settled was probably a failure to understand the complexities of interfacing and integrating subsystems potentially sourced from a wide variety of suppliers. Commercial people, including lawyers, tend to think of this as being purely a technical or a project management question. But with a little effort at project definition stage, we can surface and eliminate many potential issues before the contract has been signed -- let alone started!
ASK YOURSELF THE ACTION POINTS
- What is the integration lifecycle in your specific business area?
- Who drives the task?
- What is the project governance to ensure these things happen?
- Do the terms of our supply contract support us in resolving integration questions?
- Does the technical specification specify interface data requirements?
- What audit trail have we created to demonstrate that our project has properly understood the integration lifecycle?
ABOUT THE AUTHOR
Peter Sammons works as a business trainer with Procurement Central in the UK. The author of many books available online, Peter published Contact Management, Core Business Competence in 2017. The preview of this work may be found here. His recent book Right First Time – Buying and Integrating Advanced Technology looks in depth at this subject area. Available as hard or soft copy.
Part 1 - Buying and integrating advanced technology
Part 3 - Where do “stakeholders” fit in?
Content reflects views and opinions of the author and do not necessarily reflect the views and opinions of World Commerce & Contracting.