Select Page

This is the second part of a 2-part series of articles covering the relationship between information technology (IT) and capital projects, highlighting a few key aspects that need to be taken into account by the owner project team, relating to information technology and business systems.  

  • Part 1 was published in February 2016 and covered some background and the business context of IT.  
  • Part 2 covers the nature of IT projects and how these can be managed together with the main project.

By Gavin Halse


Project teams involved in capital projects are primarily focused on delivering a complex plant and have a lot to contend with.  As a result, they sometimes pay scant attention to IT during the early stages of a project.  The result can be that, towards the end of the project, IT has been poorly scoped and a number of last minute requirements and related costs are required to support the running business.  These can cause the project to be overspent, or even delay beneficial operation.

How then should owner project teams ensure that the owner’s IT requirements are properly incorporated into a capital project, and how can the business be assured that they’ll get a working IT system when the new plant is handed over?

IT projects are the same, but different

In many respects, IT projects are very similar to capital projects.  In line with the APM definition they are a unique, transient endeavor undertaken to achieve the planned objectives defined in terms of outputs, outcomes or benefits.

However, having said this, there are also several important differences that need to be considered.  IT projects have notoriously high failure rates.  The risk/reward profile of a small IT project is vastly different from a multi-billion capital investment in plant.  Maizlish and Handler (2005) suggest that, with the increased velocity of technological change, IT projects should be broken into smaller projects that will fail fast when not viable.

Managing different types of project using a one size fits all approach does not always make sense.  For example, software should be developed in accordance with an established SDLC (software development life-cycle).   As another example, business systems should be implemented in accordance with specific implementation methodology that is normally recommended by the vendor.  Support, upgrades and maintenance should be executed in line with recognised best practice frameworks such as ITSM (IT Service Management), and so on.

There are other key differences.  For example, the estimating techniques for an Agile software project are constrained by time, cost and quality, and not by scope.  The way you measure progress of an Agile project would therefore be very different from the traditional waterfall approach, and so on.  Agile methodology is an alternative to traditional project management, typically used in software development.  It helps teams respond to unpredictability through incremental, iterative work cadences, known as sprints.  Agile methodologies are an alternative to waterfall, or traditional sequential development.

Figures 1 and 2, below, illustrate the differences between a typical waterfall project approach and an Agile development model:

Waterfall method


Figure 1:  Traditional sequential (waterfall) method for IT project management




Figure 2:  Agile method for IT project management

In order to manage the risk associated with the high rate of change within the business environment and technology world, techniques are constantly evolving to reduce the probability of IT project failure.  These are also driven by technology advances (for example cloud computing).  Over the life-cycle of a megaproject, it is quite conceivable that several generations of software will evolve, making detailed planning difficult.  Considering that megaprojects could take place over periods up to 10 years and even longer, systems that are implemented will need to form part of a maintenance and upgrade process throughout the rest of the project and indeed the business life-cycle.

Defining and managing the IT scope

When defining the scope of what is included in the main project, it might be helpful to consider the simplified architecture of a typical installed manufacturing system shown in Figure 3.

In our experience, all deliverables that exist below (on the plant side) of the gateway are typically included in the scope of the main project.  These include the deliverables that form part of the process control system, e.g. DCS (distributed control system), SCADA (supervisory control and data acquisition), etc.  They are characterised by relative stability in terms of technology and can be quite easily defined early in the project.


Plant systems

Figure 3:   A simplified physical architecture of a typical installed manufacturing system

Items above the gateway, including enterprise systems can form part of the project, or might be part of the business responsibility.  Obviously this is not always straightforward.  Deciding on the scope of the project vs the business responsibility is made even more complex as the boundaries between the business network and the industrial network are blurred by technological advances (such as the “Internet of Things (IOT)” and increased connectivity.

During the initiation phase of the project, the high level requirements for the IT systems must be broken down and organised into sub-projects.  As mentioned, these projects in turn should be classified as to whether they are included in the scope of the main project, or are run as separate initiatives in the business.  Those with organisational-wide impact are candidates for separate projects.

Recommendation:   Project teams need to determine which IT sub-projects within the scope will be delivered as part of the main project, and which deliverables need to be run within the business IT organisation.  The project management team should also have a basic understanding of the different IT methodologies where there are points of integration.   Progress reporting should accommodate processes such as Agile software development.   Appointing a business integration project manager as part of the project team with a work scope covering the work from the gateway to the enterprise systems can be very beneficial. This person is responsible for managing the interface with IT and ensuring on time delivery. Typically, physical infrastructure and hardware will fall within the scope of the capital project, while software systems and the wider business systems might be run by an IT organisation.   (The exception to this might be a greenfield business where everything could form part of the capital project scope upfront).

Use a programme management framework

Big industrial scale capital projects are not executed in isolation.  They usually form part of a number of related business initiatives that run in parallel.   These business initiatives share resources and overlap in many ways.

What is important is that the integration between all of these projects needs to be carefully planned and actively managed.

As shown in Figure 4, programme management provides a framework to initiate, manage and co-ordinate related projects that have a common strategic goal (van Heerden, Steyn & van der Walt, 2015). A programme is a group of related projects managed in a coordinated way to obtain benefits and control not available from managing them individually (PMI, 2013). By keeping the various constituent projects separated according to type and organisational reach, best practices can be implemented and resources better optimised.


Figure 4:  Programmes in context showing multiple simultaneous initiatives (van Heerden, Steyn & van der Walt, 2015)

Recommendation:  Use a programme management framework to co-ordinate between the main project and associated IT projects that are aligned to the same strategic goal.  Ensure that all IT projects, impacting on the capital project, are properly directed and managed and not left to chance.

Greenfield projects – where nothing exists yet

In situations where a company is building a greenfield facility and there are no IT or business systems in place, it might be sensible to include the entire new IT system in the main project scope.   However, there are risks with this approach that then need to be mitigated, including:

  • Obsolescence before start up:  The IT systems planned initially could fail to meet the requirements of the more evolved business at the end of the project, due to the fast changing competitive and technology environment over several years;
  • Timing:  There will be a need to run the business while the project ramps up.  The timing for going live with the business system may be far ahead of the commissioning of the plant itself;
  • Roles and responsibilities: There could be ambiguities in roles and responsibilities between the project management team and the business IT organisation, and;
  • System maintenance and support:  The longer-term support and maintenance of the systems, as well as the ability to extend and grow them, might be inadequate if the project does not adequately consider how to future proof the technologies in the design.

Recommendation:   The IT organisation that will be responsible for the systems needs to be defined and brought into the business early enough to be part of the design.  Roles and responsibilities between the project team and the IT organisation need to be determined fairly early on.  IT budgets need to be established for the business and be clearly demarcated against the IT budgets belonging to the project; with clear responsibility and accountability for these budgets.  The IT organisation needs to work closely with the owner representatives in developing the requirements for the project.  Careful planning must ensure that there is a clearly defined roadmap for rollout of business systems at the right time, in parallel with the project deliverables.

Integrating with existing enterprise systems

Linking the new IT systems from a project into existing enterprise systems must also be carefully considered.  Often these existing systems are well established across the rest of the organisation.   The project may want to introduce design changes to processes, architectures and technology standards that have wider implications beyond the scope of this article.  On occasion, it may be necessary to restrict the choice of technology by the project to an older one in order to prioritise enterprise level standardisation.  Not all projects need be leaders of technological change in the business.

Mature IT organisations will find a balance between the need to introduce new systems and the risks of disrupting the existing operation.    Less mature IT organisations may resist changes from the project and even actively prevent these.   Here having the right leadership in place will make the change process easier and keep all stakeholders aligned to the ultimate business goals.

Recommendation:  When defining requirements for project related systems, carefully consider the wider implications on the enterprise.  These can include aligning with existing technology roadmaps, standardised processes, ways of working with customers, established technology service providers and so on.  Enterprise level integration should be clearly determined in the project scope and allowance for this made in the capital estimates and operating budget.  A senior level Executive should be involved in this process, who has the necessary decision making influence across the whole organisation.

Closing comments

As indicated in Part 1, IT has a vital role to play in helping the business achieve strategic goals.  When capital projects are implemented, either as greenfield, or integrated into existing business, there will be a significant impact on the existing IT and business systems, as well as the IT organisation. This, in turn, impacts on all stakeholders.  The impact needs to be carefully managed in order to reduce risks and achieve the stated benefits.

While certain IT deliverables like infrastructure can easily be incorporated into the main project, it is often better to select certain IT projects and manage these separately as part of an overarching programme focused on the strategic business goals.  This introduces some flexibility and increases accountability and visibility of the individual projects.  It also enables the adoption of best IT practices in the IT projects.

Careful integration between the projects in a programme remains critical.  In designing the programme and project structures, executive management needs to be aware of the importance of proper integration of IT projects and incorporation of the appropriately skilled people in the project structures


Maizlish, B, & Handler, R., 2005, IT Portfolio Management Step-By-Step, John Wiley and Sons, Hoboken, NJ.

PMI (Project Management Institute), 2013, The standard for program management, 3rd edition.  Project Management Institute, Inc., Newtown Square, Pennsylvania.

van Heerden, F.J., Steyn, J.W. & van der Walt, D., 2015, Programme management for owner teams- a practical guide to what you need to know, OTC Publications, Vaalpark, RSA.

You can download this and other Insight articles from our website at