Keys to Successful Integration Projects

 

The world gets more complex and intertwined, which creates more projects involving complex integrations. What is an integration? It’s when separate systems or components are brought together to build a seamless solution. For example, building a satellite means integrating a propulsion system, navigation component, scientific instruments for research, communication components, and others. Here are crucial keys to managing an integration project successfully.

• Approach the project in four phases: Define-Decompose-Build-Recompose.

1. Define the entire integrated solution in detail. 
2. Decompose that solution into pieces that separate expert teams can work on. 
3. Build the solution, where the expert teams construct those pieces (systems or components).
4. Recompose the components or pieces into a solution. 

Less experienced project managers might try to shortcut these steps. For example, they don’t decompose the solution fully and overlook an integration element. Let’s take our satellite example. Say the communication component is combined with the scientific instruments. That could lead to overlooking the integration between the communication system and the propulsion system (so people on the ground can reposition the satellite).

• The best management flow is Centralize – Decentralize – Recentralize. Experienced integration project managers understand that success means giving up some control.
•  As the total solution is defined, management is centralized and controlled by the project manager. 
• When the product is decomposed and the expert teams are working on their components, management is decentralized. The project    manager releases control. Teams still report status and risk status to the project manager. But the teams work under their own management, exercising their specialized expertise. 
• When components are integrated (recomposed), control is re-centralized. This affirms the accuracy of integrations. It also resolves any discrepancies between the expert teams. 

You can hamper the build effort and increase time and cost if you try to exercise too much control while components are under construction.

• Understand the start-and-stop points of each component. The project phases and management flow depend on one critical element: the clear definition of components. It’s crucial to know where each team’s responsibilities begin and end, and where the technical component integration points lie. Using our satellite example, the scientific experiments include a communication element to share the output from the research performed. The overall communication module shares those research results and other data with staff on the ground. So you need to define in detail where the communication role of the scientific experiment modules end and where the primary communication module takes over. 

Integration projects amplify the risk of errors occurring, particularly when the expert teams are not co-located. Risks expand further when multiple unrelated vendors need to come together to integrate an overall solution. Carefully define your components and integration parameters!

• Ownership of testing needs to be defined specifically. Don’t try to ask two teams to build their individual components and be responsible to “test the integration.” That usually ends badly. Project managers need to decide who specifically will take the lead on testing each integration in the solution. Often, an independent test owner works best. This person isn’t a member of either team with integrated products. With an independent test owner, you reduce the occurrence of pre-conceived ideas about how the integration should work. Also, the independent test owner will evaluate results more objectively. 
• Add a lot of time and money to manage integration risks. This is the most under-estimated aspect of any project. Be conservative when estimating the cost of testing and completing integrations. Add at least 50% (yes, 50%) of the cost of building the separate products that will be integrated — to accommodate testing and correcting integration. Lots of unexpected things can happen. Errors often take a lot of time and effort to resolve. It’s better to surprise stakeholders with a less costly integration event than to explain why you need more time and money to make something work. 

Have any good stories about integration projects to brag about? How about horror stories that we can all learn from? Share with us in the comment section.

_______________________________________

This article belongs to the Bonnie’s Project Pointers newsletter series, which has more than 34,000 subscribers. If you like this article, you can subscribe to receive notifications when a new article posts.

Want to learn more about the topics I talk about in these newsletters? Watch my courses in the 

LinkedIn Learning Library and tune into my LinkedIn Office Hours live broadcasts.

_______________________________________