Select Page
Practical Guide 12:  Stakeholder Management

Practical Guide 12: Stakeholder Management

Stakeholder management

 

 

This is the second practical guide in the OTC stakeholder management toolkit.   The “Stakeholder Management” practical guide explains why stakeholder management is vital to project success and should never be an add on.  Stakeholder management requires commitment, time, money and resources in order to develop and implement effective engagement and communication strategies.

Following the proper identification and mapping of project stakeholders it is important to ensure these stakeholders are nurtured depending on their power and interest in the project.   This is done through a planned engagement, relationship building and communication process.

(The first practical guide in the series was the “Stakeholder Identification and Mapping” guide which covered the process of identifying who the stakeholders are and their potential impact (positive and negative) on the project).

Here’s what you will discover:

  • How to beneficially move individual stakeholders on the stakeholder map in terms of power and interest
  • Effective stakeholder engagement and communication strategies
  • Why generation theory is so important when developing communication plans
  • Who is responsible for stakeholder management on a project
  • When and how to maintain relationships with stakeholders throughout the project life-cycle
  • What best practices does OTC recommend

You can download your own copy of the guide from the OTC Toolkits Membership site.  (Log-in required).

– The OTC Toolkits Team

What Capital Project Teams Need to Know About Information Technology – Part 2

What Capital Project Teams Need to Know About Information Technology – Part 2

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

Introduction

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

 

Agile

 

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.

Programmes

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

References

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 http://www.otctoolkits.com/download-insight-articles/

 

Practical Guide 11:  Stakeholder Identification and Mapping

Practical Guide 11: Stakeholder Identification and Mapping

Stakeholder

 

Stakeholder management is an important process that requires focused attention throughout the capital project life cycle.

Capital projects will impact individuals and organisations, both internal and external to the organisation. The more people you affect, the more likely it is that your actions will impact individuals with high levels of power and influence over your projects. These people might turn out to be strong supporters of the project or they could block it.

The Stakeholder Management Toolkit has a number of useful resources for project sponsors and project managers, as well as business  executives.  

The “Stakeholder Identification and Mapping Practical Guide” is now available to OTC Toolkit members.  We will soon be following this up with an additional guide on how to develop the stakeholder management plan and show to engage and communicate with stakeholders.   

Here’s what you will discover:

  • How to identify your project stakeholders
  • Why it is important to understand the relationship between the stakeholder and your project,  and their level of influence
  • How to map your stakeholders in order to develop a focussed engagement strategy for each

You can download your own copy of the guide from the OTC Toolkits Membership site.  (Log-in required).

 

– The OTC Toolkits Team

Practical Guide 10:  An Introduction to Project Controls for the Practicing Owner Project Team

Practical Guide 10: An Introduction to Project Controls for the Practicing Owner Project Team

Project Controls for the Owner Team

 

The project controls function has a vital role to play in a capital project.  However “Project Controls” can mean different things to different people.  To some it refers to the team that produces the monthly cost and schedule status.  To others the project controls team is concerned with forecasting the likely outcome of the project,  based on interpreting the current trajectory against the planned work and comparing progress against similar industrial projects.  

Project controls is applicable both in the owner organisation and in the engineering contractor, and there are important differences in the role between the roles and responsibilities in the different contexts.

OTC is planning on releasing a series of practical guides aimed at the project controls professional, as well as other participants on the project.  These guides are intended to complement the published literature with plenty of practical examples, advice born from experience and tips.   This overview guide provides the foundation and introduces the subjects that will be covered in the future project controls guides.

 

Here’s what you will discover:

  • What is project controls in the context of an owner organisation
  • The important differences between the project controls function and the project services function
  • The series of practical guides covering inter-alia
    • Roles and responsibilities within the project controls disciplines
    • Cost management
    • Schedule management
    • Integrating cost and schedule
    • Progress measurement and earned value
    • Change management
    • Analysing, forecasting and reporting
    • Close-out and feedback including project reviews and lessons learned
    • The cost engineering gate readiness model
    • Basis documents for estimating, cost control and planning
    • Project controls plan
    • Audits

You can download your own copy of the guide from the OTC Toolkits Membership site.  (Log-in required).

 

– The OTC Toolkits Team

What Capital Project Teams Need to Know About Information Technology – Part 1

What Capital Project Teams Need to Know About Information Technology – Part 1

This is the first 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 covers 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

Introduction

Manufacturing companies that build and operate industrial plants, rely heavily on business systems and information technology to support, optimise and grow the business. 

Information technology (IT) can help optimise capital spend and maximise the return on assets.  IT can help reduce costs while increasing market share and revenue.  IT can enable companies to manage their operations efficiently and safely.  IT can help companies continuously introduce new processes and take advantage of new technologies.  On the other hand, poorly implemented IT can quickly destroy value.

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 is a core manufacturing business capability

IT systems are used to deliver value and quality of service to customers, suppliers, employees, distributors and partners (Maizlish & Handler, 2005).  When IT is optimised, the business runs efficiently, becomes resilient to change and is competitive.  On the other hand, IT that is managed in a chaotic way can present a real risk to the business by inhibiting necessary change and increasing costs.  At the end of a capital project, a dysfunctional IT system can even prevent the start-up of a new business.

This is the reason that IT should be regarded as a core business capability and not as a mere “utility service”.  The IT strategy, risk and performance must be managed by the business executives at the most senior level.  The King III report on Governance (IoD, 2009) devotes a whole chapter (chapter 5) to the governance and alignment of information technology.  King goes on to state that IT is ultimately a board-level responsibility (IoD, 2009).

In a manufacturing environment, business and IT are inextricably linked, for example:

  • Automated business processes that extend beyond organisational boundaries to customers, suppliers and partners;
  • Linkage of manufacturing execution systems (MES) to align production execution with real time business information;
  • Differentiated products and customised services personalised to each customer;
  • Cost reduction and efficiencies through improving supply chain, manufacturing execution, maintenance and safety, and;
  • Compliance to legislation and regulatory standards, including for example Sarbanes-Oxley, Basel, etc.

Several useful models have been developed to illustrate the multiple points of interaction between IT, manufacturing and business.  Figure 1 shows the IT business/manufacturing model across three main dimensions as developed by the ARC Advisory Group (Chatha, undated).  The value chain domain on the X axis runs between suppliers, manufacturing operations and customers.  The production and operations systems at the bottom connect to the business operations at the top along the enterprise domain (Y axis).  The product life-cycle, on which new products are developed, is shown on the Z axis. 

 

ARC Manufacturing

Figure 1:  ARC Manufacturing collaboration model (Chatha, undated)

 

MESA, in turn, has also developed a model that shows the flow of information from manufacturing systems through operations to support business initiatives. This model is shown below in Figure 2:

MESA Manufacturing

Figure 2:  Production to Enterprise model (MESA, 2016)

Each of these models is intended to simplify a complex landscape and to illustrate the many touch points between IT, manufacturing and business.

Recommendations:   Based on our experience, OTC recommends that project team members should be familiar with the position and architecture of the owners’ IT systems.  Business and IT specialists should work closely together during the development of the early business concept to create a clear vision of the future IT system and exploit opportunities for innovative use of technology during the design. 

During project initiation and early feasibility studies a business integration model should be developed within the project work break-down structure.  This work should ideally be led by a person with the right combination of IT and business skills.  The business IT deliverables should be integrated with the deliverables from the rest of the project.   This work package should be managed like any other project deliverable with clear scope, outputs, schedule and costs, and be reported on at steering committee level. 

IT costs need to be optimised like any other asset

IT can represent a significant capital and operating expense, with expenditure ranging between 0.9 and 2.5% of revenue in industrial plants, and up to 20% and even higher in service environments (Maizlich & Handler, 2005).  With more recent developments in cloud computing and software as a service, a big percentage of IT costs are shifting from capital investments in infrastructure (networks, software platforms and servers) to subscription services delivered through the cloud.

Maizlich and Handler (2005) suggest that the portfolio of IT “assets” should be managed just as any other capital asset.  Each IT investment must be supported by a value statement with a supporting business case.  The value might be financial (cost savings or increased revenue), or strategic (customer retention, customer growth), compliance, tactical (reliability, responsiveness), risk reduction, etc.

However, many companies manage their IT project costs as part of their ongoing operating budget with little visibility of any IT projects and poor understanding of the value created.  This “black hole” of continuous IT expenditure is often perceived to be a necessary evil and resented by many executives who have to fund IT from their own budgets. 

Figure 3 shows typical IT expenditure categories in an internal IT organisation (Maizlich & Handler, 2005).  Obviously the amounts will vary between companies, but it is important for project teams to understand how IT investments will eventually be incorporated into the owner organisation’s operations.

Recommendation:   The business case for all new IT investments, both capital and operating should be treated no differently from other decisions during the project design phase.  This includes trade-off decisions between capital and operating costs, decisions on whether to source in-house or to buy in from external vendors, etc.   The portfolio of IT assets that form part of the project scope should be clearly listed together with the existing systems and the economic value add of each new system quantified during the design phase.

 

Typical IT expenditure

 

Figure 3: Typical IT expenditure in an operating business

IT is a relatively small cost with a big impact

During the execution of large capital projects, IT is not the major consideration or focus of the project team.  After all, the costs are a fraction of a percent of the cost of a major plant.  This dilute focus can become a problem, because IT is always “under the radar”.

IT systems can have organisation-wide impact on the business by virtue of common processes, such as those with external parties (customers and suppliers) and the needs of internal stakeholders e.g. shared business services.  These organisation-wide processes can extend beyond the immediate scope of the project.  They cross the boundaries of plants, sites and different licensor technologies, and therefore need to be integrated carefully.  During the initiation and design phase of a project, any organisation-wide implications need to be identified and catered for.

Recommendation:  During the initiation and design phase of a project, any organisation-wide processes, operating philosophies and standards need to be identified.  Consider the organisation-wide implications of any new IT systems introduced during a capital project.  Clearly define the scope of the IT systems delivered by the main project and the IT systems that fall within the scope of work of the business itself.  

The right skills are critical during initial project stages

An opportunity will exist during the business discovery and initiation phase of any capital project to identify new IT or business systems that will become integral to the whole business.  If these systems are selected early enough, they will have a positive impact on the design itself.  

A key success factor is putting in place IT leadership with the right combination of technical and business skills to develop the scope and the integration model.  These people should work closely with the business development team and have access to business analysts and other IT specialists who can help develop concepts and turn these into clear deliverables. 

Recommendation:  OTC recommends that an IT leader of sufficient seniority, decision-making ability, technical and business skill is appointed for all projects with the potential to impact the business.  Moreover, the IT leader should be able to communicate effectively with the engineering and project management teams.  For major capital projects, this person should be the chief information officer.

Working with an existing IT organisation

Many capital projects are executed with an established IT organisation in place and it is important to coordinate carefully between departments.  This IT organisation might be totally in-house, or more commonly a few key in-house people with several outsourced partners and vendors managed by service agreements.

The existing IT organisation will be responsible for delivering and maintaining business systems.  This is normally managed as a portfolio.  Within the portfolio, IT assets are constantly being acquired, maintained and retired and projects are being executed.  

The chief information officer (CIO) is a key player in leading the IT organisation and aligning outputs with the business.  This is accomplished through a number of key activities, for example: strategic planning, budgeting, programme management, solution delivery, human capital management, purchasing, research and development, vendor management, and IT operations.  The CIO is also an important stakeholder who should be closely involved in a coordinating role with any capital project that will impact on the IT systems.

Remember that the IT organisation is also not a single group of people.  It will normally span many levels of the business (including outsourced partners) with specific roles and responsibilities that are shared between the Board of Directors, risk and governance committees, the IT strategy committee, the CEO, business executives, the CIO, the IT steering committee, technology council and the architecture committee.    These groups are also significant stakeholders in the impact any capital project will have on current and future IT systems.  Good communication and integration of these stakeholders is important.

Recommendation:   If there is an existing IT organisation, then the CIO will normally be the owner representative responsible for taking over the systems delivered by the project.  He or she is therefore an important stakeholder.  If the IT organisation is not yet in place (e.g. a greenfield plant) then the key people in the future IT organisation should be put in place early enough to be involved in systems selection and design.

Closing comments

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, which in turn impacts on all stakeholders.  This impact needs to be carefully managed in order to reduce risks and achieve the stated benefits. 

In Part 2 we will take a closer look at the nature of IT projects and how these can be managed within the scope of the main project and within an overall programme.

References

Chatha, A., Undated, Driving operational excellence thru collaborative manufacturing, ARC Advisory Group, PDF downloaded from http://www.arcweb.com/key-concepts-presentations/Collaborative%20Manufacturing%20Management%20(CMM)%20Overview.pdf on 28 January 2016.

IoD, 2009, King report on Governance for South Africa 2009,  Available from https://jutalaw.co.za/uploads/King_III_Report/#p=1.  Accessed on 20 January 2016.

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

MESA, 2016, MESA Model and strategic initiatives, Available from http://www.mesa.org/en/modelstrategicinitiatives/MSI.asp.  Accessed on 20 January 2016.

You can download this and other Insight articles from our website at http://www.otctoolkits.com/download-insight-articles/