White paper · March 2019

How to Integrate in a Project Controls Environment

Using a service-oriented architecture and an enterprise service bus to connect cost, schedule, ERP, change and risk. By Juan Grobler, then Managing Director of Global Footprints Inc., and Dr Mark Townley, Managing Director of EVMT ProgRess Ltd.

This is the original 2019 paper. For what has changed since, including AI and large language models, read the 2025 update.

Integration is a concept that has been introduced previously. Within a business context, integration takes on many forms, including integrating people, business processes, and systems. Usually, an organization will require integration of all these elements to some extent. Far too much time is spent finding, extracting, and analyzing data from various systems to provide stakeholders with information on how a program is progressing. Companies have an insatiable need for information, resulting from teams working together over months to gather the data for stakeholders to make informed decisions. So, when considering a project control environment, what drives the need for integration the most?

Systems and business process engineering have been the key elements driving integration within project controls. Cost control systems such as PRISM G2 Cost Management are businesses’ central systems when managing costs within their programs. However, it’s important to note that cost systems do not operate in isolation and often depend on other systems such as Enterprise Resource Planning systems (ERPs), scheduling systems, estimating systems, document management systems, and traditional business systems. When combined, you have a more complete set of data and information for the business to manage its programs better. Some people try to manually integrate all these systems and data points to provide the necessary information.

There is a better way!

Service-oriented architecture

A Service-Oriented Architecture (SOA) is an architectural approach that exposes and encapsulates ‘services’ in a coarse-grained manner. It does not prescribe any technical mechanism or implementation; rather, SOA is related to the integration and interaction between systems.

So, if system A exposes services using an SOA, we can interact with those services from system B. An Enterprise Service Bus (ESB), on the other hand, is a technical implementation that aids in delivering an SOA, i.e., ESB delivers all the inter-connectivity capabilities required for your employees, applications, partners, suppliers, and customers to leverage the other services in the SOA. Some of the critical services the ESB provides are routing, protocol conversion, formatting, event, and mediation services. The ESB is at the core of a Service-Oriented Architecture.

Another essential capability of an ESB is managing the flow and interactions of multiple services, working together to implement business processes. This capability is called “process orchestration.” That is an apt name because you can think of this part of the SOA acting as the conductor of a symphony orchestra, ensuring that all the tasks in a business process work harmoniously. If the service, as the tool, is the instrument in an orchestra, then the ESB is the conductor who coordinates the musicians playing those instruments to produce a symphony.

At this point, you may be asking, “Why do I need an ESB when all I need is to send actual invoice data to my cost system?” I submit that the questions you should be considering instead are:

  • Do I need to integrate myriad information sources across the organization and extend that information to customers and partners?
  • What efficiencies can I leverage when bringing information into a centralized view?
  • Is there value in extending this to our customers and partners?

Answers to these questions will likely lead you to explore a more sophisticated integration discussion than just passing simple invoice data to a cost system.

Interaction with applications

This architectural approach extends the existing capability of cost control applications, such as PRISM G2, and enables other services to integrate with the application, including scheduling tools, estimating tools, contract management tools, and ERPs. The integrator (ESB) exposes the relevant services from the various systems. By defining a business process within the ESB, it brings the data together in a manner that is understandable by both the source and destination systems.

Some examples of the applications that enterprises typically begin integrating include:

  1. Cost control systems
  2. ERP systems
  3. Control account and work breakdown synchronization with the schedule
  4. Change management
  5. Risk management

While we will not discuss each of these integrations in full detail, it is beneficial to highlight a few scenarios to give you an idea of where and how various systems may be integrated into project controls.

1. Integration with cost control systems

Diagram of Global Integrator as the integration engine connecting an asset management system to scheduling, estimating, cost management, contract management, risk management and ERP, with BIM 4D/5D links to CAD and GIS
Global Integrator as the integration engine: WBS synchronisation, change control, payment application, risk and change integration, and BIM 4D/5D.

One of the most interesting business processes we have found to integrate is synchronizing the cost control elements from the cost management system and the work breakdown structure (WBS) within the scheduling system to various other systems. This allows the business to use this standardized (synchronized) code throughout the company. Hence, further services/business processes will be initiated by standardizing a control account structure. Business processes such as change management and risk management can be integrated. This allows the change and risk data to be raised in a contract management system, and the impact is measured through the cost control system. Now, the organization has a single view of cost, change, risk, and schedule throughout the program.

As highlighted above, synchronizing WBS and control account elements is quite a labor-intensive process within a program. Especially when the cost and WBS structures keep growing as the program extends and runs through its lifecycle, each program finds itself mapping and aligning these two elements throughout the program’s lifecycle to ensure the data remains in sync. If this is not kept up to date, manually re-synchronizing the data becomes too time-consuming and eventually abandoned.

2. Integration with ERP systems

Another fascinating business process is integrating with Enterprise Resource Planning (ERP) systems such as SAP. Cost management is not complete without a schedule and financial data, and ERPs hold a lot of financial data. ERPs manage the materials management, professional services, and procurement processes, which are integral to a program controls environment. Capturing actual costs and forecasting costs and commitments within the cost management system certainly completes the information view for business and program directors.

Consider a scenario in which Global Integrator integrates SAP, PRISM G2, and a contract management system. The contract management system initiates a payment certificate based on milestones achieved and sends it to SAP. SAP receives the certificate as a goods receipt voucher and matches it to the invoice and the purchase order within SAP. Once the three-way match is achieved (invoice, purchase order, and goods receipt voucher), SAP processes the invoice for payment.

As you can tell from these processes, we have exposed system-specific services using SOA and integrated these services through the ESB. The ESB is translating the data and ensuring its delivery to the destination system. This is described above, where the contract management system payment certificate is translated into a goods receipt voucher in SAP to facilitate an invoice payment process.

The financial benefits of automating the payment process are quite easily justified. Strict audit controls, managing payments strictly by contract line item, and processing payment certificates at source reduce a business’s and program’s overhead. This also ensures contractors are paid on time, and the program’s budgets, materials, and resources are committed. The benefits go well beyond the average straight-line cost-benefit formula often applied to such scenarios.

3. Control account and WBS synchronization with the schedule

As described in the first scenario, when the Work Breakdown Structure (WBS) and the Control Account structure are defined within a project, they can be aligned by becoming the same or mapping to one another. This provides a centralized structure for orchestrating critical business processes. The centralized WBS/Control Account structure acts much like a chart of accounts in an ERP system.

The benefit of aligning cost and schedule in a project control environment is well understood and an essential discipline that doesn’t need further explanation. The critical point is to provide a platform whereby cost and schedule can be managed together rather than in disparate systems. The ESB identifies the messages and routes them between applications and services, ensuring the two systems remain in sync.

4. Integration with change management

Flowing from the synchronization process of standardizing the WBS and Control Account throughout all the systems within the cost control environment, we are able to unpack a third opportunity for the enterprise: managing programs/projects according to contract. Often, this is done manually by the cost control manager or contracts manager working within their respective systems. The collaboration is often manual, especially when a change is requested on a project/program.

What is the impact of this change on the terms of the contract?

With our standardised WBS/control account structure, a contract can be managed to a granular level that makes sense to the program. This allows for the initiating, approval, and monitoring of changes between the two systems. Changes are no longer seen in isolation, and the risk of missing an important clause or term of the contract is mitigated.

Change is managed at the source, ideally with full visibility of its impact on the contract. A budget is approved for this change, and the cost/budget flows through to all systems impacted by that change.

5. Integration with risk management

The last scenario on which I would like to elaborate is risk. Identifying risks early in a program is essential to its success. Managing risk throughout its life cycle is just as important, as it may lead to a change that impacts the program as a whole, either by increasing cost or impacting time. Either way, not managing risk effectively results in a change of scope.

This change of scope is defined in point 4, so it makes sense to include risk in the equation. By exposing risk and change as services and aligning this with the WBS/control account, we can get a central view of risk, change, and cost within the program.

Integration benefits

As illustrated by the examples above, ESB architecture is a pattern of middleware that unifies and connects services, applications, and resources within a business. The ESB pattern enables the connection of software running in parallel on different platforms and using disparate programming languages and skills, allowing an organization to introduce new applications and updates to its users more quickly and easily.

An ESB is a core component of a service-oriented architecture (SOA), and an SOA can decouple the links between business functions and specific applications by isolating service definition and usage from the underlying service implementation. This flexible connectivity layer helps connect and integrate an organization’s cost control environment, even its IT environment, across many differing systems and locations reliably and securely while reducing application interfaces’ number, size, and complexity. Now, program stakeholders can access the information they need and manage their programs from a central point.

More specifically, an ESB:

  • Identifies messages and routes them between applications and services.
  • Enables messages to flow across different transport protocols as they move from requestor to service and back.
  • Transforms message formats en route between requestor and service.
  • Recognizes and distributes business events from and to disparate sources.
  • Provides robust and secure program-to-program communications for all types of applications.
  • Has an extensible architecture based on pluggable components.
  • Can integrate all types of assets to match the needs of a typical enterprise, including web services and assets not currently based on shared standards.
  • Provides a business with capabilities of intelligent routing and location-independent processing.
  • Manages the messages’ descriptions, definitions, and formats through accessible metadata.

Automated application services and business logic implementations in computerized systems are critical to any integration or SOA solution. Many of these services are provided through existing applications, others in newly implemented components, and others through external connections to third-party systems. Existing enterprise applications and enterprise data are accessible from the ESB through a set of access services or connectors. These services bridge capabilities between legacy applications, pre-packaged applications, enterprise data stores (relational, hierarchical, nontraditional, unstructured sources such as XML and text), and the ESB. Using a consistent approach, these access services expose the data and functions of the existing enterprise applications, allowing them to be fully re-used and incorporated into functional flows that represent business processes. As these applications and data implementations evolve to become more flexible participants in business processes, enhanced capabilities of their underlying operating environments can be fully utilized.

Global Integrator

Global Integrator, offered by Global Footprints Inc., is an integration platform that connects IT systems. It enables you to orchestrate data flows that support your business and program goals and design the business processes that support them. Global Integrator aims to make it fast and easy to provide reliable information to your stakeholders.

Global Integrator is a powerful ESB that enables SOA within the project controls environment and beyond by connecting services, applications, and data stores within the business and supporting the ability to extend beyond the business boundaries to the business partners.

Conclusion

In summary, integration within the project controls environment is more achievable than most program directors think. Using Global Integrator to blend data into a cost control system like PRISM G2 provides stakeholders with richer, meaningful information. This frees up time for stakeholders to design business processes that support their programs, manage cost-effectively, and ensure programs are delivered on time and within budget. Global Integrator effectively orchestrates data and information to make integration easy and can be achieved on time.

So, I challenge you to look within your programs and determine which business processes need streamlining and which information you need to improve when running the program. You are not alone on this journey. We will assist you in analyzing the business processes, determine where the data may reside, and integrate the data so that the information is available for your stakeholders to analyze the business better and streamline processes to ensure time and resources are better utilized.

First published March 2019 by Juan Grobler, Managing Director of Global Footprints Inc., and Dr Mark Townley, Managing Director of EVMT ProgRess Ltd. Product names belong to their respective owners. About Juan Grobler.