Limiting Resource Risk in Complex Technology Projects

We will assess and optimize your project and resource management processes.

We will assess and optimize your project and resource management processes.

Optimize resource allocation across the portfolio

Decrease risk of delivery delays and loss of value

Increase organizational knowledge

Limiting Resource Risk: Operations vs Project
Limiting Resource Risk: Operations vs Project

Limiting Resource Risk in Complex Technology Projects

We will assess and optimize your project and resource management processes.

Optimize resource allocation across the portfolio

Decrease risk of delivery delays and loss of value

Increase organizational knowledge

Limiting Resource Risk: Operations vs Project

Introduction

Introduction

Introduction

Identifying and classifying risks in technology projects and programs can be ambiguous and difficult to quantify because of the underlying assumptions. Proactively managing risks hinges on the availability of people involved. Especially, when software is deployed to multiple assets / sites. This article aims to simplify risk management. The framework presented explains how to logically derive technological, controllable risk in terms of Applications and Infrastructure, and provides a classification and tracking mechanism for scenarios where resources are limited in availability, skill, or organizational knowledge. Finally, this article vouches for the “Project Risk Governance Board” to further minimize risks across the organization.

Identifying and classifying risks in technology projects and programs can be ambiguous and difficult to quantify because of the underlying assumptions. Proactively managing risks hinges on the availability of people involved. Especially, when software is deployed to multiple assets / sites. This article aims to simplify risk management. The framework presented explains how to logically derive technological, controllable risk in terms of Applications and Infrastructure, and provides a classification and tracking mechanism for scenarios where resources are limited in availability, skill, or organizational knowledge. Finally, this article vouches for the “Project Risk Governance Board” to further minimize risks across the organization.

Identifying and classifying risks in technology projects and programs can be ambiguous and difficult to quantify because of the underlying assumptions. Proactively managing risks hinges on the availability of people involved. Especially, when software is deployed to multiple assets / sites. This article aims to simplify risk management. The framework presented explains how to logically derive technological, controllable risk in terms of Applications and Infrastructure, and provides a classification and tracking mechanism for scenarios where resources are limited in availability, skill, or organizational knowledge. Finally, this article vouches for the “Project Risk Governance Board” to further minimize risks across the organization.

Classification of IT Projects

The following is a classification framework of different types and sub-types for technology-centric projects.

Software Development
Software Development

Software Development

  • Application Development

  • Software Upgrades

  • Custom Software Solutions


  • Application Development

  • Software Upgrades

  • Custom Software Solutions

Infrastructure
Infrastructure

Infrastructure

  • Network Infrastructure

  • Data Center Projects

  • Hardware Upgrades

  • Telecommunications

Security
Security

Security

  • Risk Assessment

  • Penetration Testing

  • Compliance Projects

  • Incident Response

Data Management
Data Management

Data Management

  • Database Management

  • Big Data Projects

  • Data Analytics

  • Data Warehousing

Digital Transformation
Digital Transformation

Digital Transformation

  • Process Automation

  • Business Intelligence

  • Customer Experience Enhancement

  • Enterprise Resource Planning

Cloud
Cloud

Cloud

  • Cloud Migration

  • Cloud Infrastructure Management

  • SaaS Implementation

AI and Machine Learning
AI and Machine Learning

AI and Machine Learning

  • Predictive Analytics

  • Natural Language Processing

  • Robotic Process Automation

  • Deep Learning Projects

Consulting and Advisory
Consulting and Advisory

Consulting and Advisory

  • IT Strategy

  • Project Management Office

  • Change Management

  • IT Governance

The classification is often determined by the accountable party that is paying for that initiative. This introduces a set of complexities, because most projects incorporate elements from different areas. There can be interdependencies, for example a Software Upgrade project might have dependencies on Process Automation, Business Intelligence, Data Warehousing projects. Those are managed by other departments and thus, communication is key to determine when a dependency can become a risk.


For the above classes, risk can roughly be categorized as follows:

Risk: Strategic
Risk: Strategic

Strategic

  • Market Changes

  • Competitive Threats

  • Technology Obsolescenes

Risk: Operational
Risk: Operational

Operational

  • Process Inefficiencies

  • System Failures

  • Human Errors

Risk: Financial
Risk: Financial

Financial

  • Financial Transactions

  • Investments

  • Economic Fluctuations

Risk: Compliance
Risk: Compliance

Compliance

  • Legal

  • Regulatory

  • Security

Uncontrollable risks are market changes, competitive threats, and economic fluctuations.

Determining Complexity

Determining Complexity

Determining Complexity

Within technology projects complexity is tied to risk, because the type of work done is not atomic (single transaction), but rather chained together until tangible results are achieved. Complex work packages or deliverables introduce higher risks to each stage.


When assessing the requirements and translating potential solutions into specifications complexity can refer to the inconsistent use or abandoned processes that need to be reworked before the project can commence.


Complexity can also refer to dependencies on other projects or vendors during testing, training, deployment and other stages.

Finally, this effect can be exaggerated by delivering the project to multiple sites:

Within technology projects complexity is tied to risk, because the type of work done is not atomic (single transaction), but rather chained together until tangible results are achieved. Complex work packages or deliverables introduce higher risks to each stage.


When assessing the requirements and translating potential solutions into specifications complexity can refer to the inconsistent use or abandoned processes that need to be reworked before the project can commence.


Complexity can also refer to dependencies on other projects or vendors during testing, training, deployment and other stages.

Finally, this effect can be exaggerated by delivering the project to multiple sites:

Multiple Site Deployments
Multiple Site Deployments
Multiple Site Deployments

Taking a closer look at technology, we are left with two distinct classes of technology projects: those that have a physical output while some classes are non-physical. In the following picture it is assumed that most of the projects in the purple colored classes are non-physical:

Taking a closer look at technology, we are left with two distinct classes of technology projects: those that have a physical output while some classes are non-physical. In the following picture it is assumed that most of the projects in the purple colored classes are non-physical:

Software Development (physical)
Software Development (physical)

Software Development

  • Application Development

  • Software Upgrades

  • Custom Software Solutions


Infrastructure (physical)
Infrastructure (physical)

Infrastructure

  • Network Infrastructure

  • Data Center Projects

  • Hardware Upgrades

  • Telecommunications

Security (non-physical)
Security (non-physical)

Security

  • Risk Assessment

  • Penetration Testing

  • Compliance Projects

  • Incident Response

Data Management (physical)
Data Management (physical)

Data Management

  • Database Management

  • Big Data Projects

  • Data Analytics

  • Data Warehousing

Digital Transformation (physical)
Digital Transformation (physical)

Digital Transformation

  • Process Automation

  • Business Intelligence

  • Customer Experience Enhancement

  • Enterprise Resource Planning

Cloud (physical)
Cloud (physical)

Cloud

  • Cloud Migration

  • Cloud Infrastructure Management

  • SaaS Implementation

AI and Machine Learning (physical)
AI and Machine Learning (physical)

AI and Machine Learning

  • Predictive Analytics

  • Natural Language Processing

  • Robotic Process Automation

  • Deep Learning Projects

Consulting and Advisory (non-physical)
Consulting and Advisory (non-physical)

Consulting and Advisory

  • IT Strategy

  • Project Management Office

  • Change Management

  • IT Governance

This is only an approximate classification, because there might be other non-physical project outputs in other classes.
The framework in this article derives risk from the physical components of a technological output and thus, excludes non-physical projects.

This is only an approximate classification, because there might be other non-physical project outputs in other classes.
The framework in this article derives risk from the physical components of a technological output and thus, excludes non-physical projects.


This is only an approximate classification, because there might be other non-physical project outputs in other classes.
The framework in this article derives risk from the physical components of a technological output and thus, excludes non-physical projects.

Simplifying the Framework to Application and Infrastructure

Simplifying the Framework to Application and Infrastructure

Simplifying the Framework to Application and Infrastructure

Application and Infrastructure as increasing risk
Application and Infrastructure as increasing risk
Application and Infrastructure as increasing risk

Modern technology exists through the output of applications. An application is responsible for creating a user experience through some means of an interface and manage the data that it processes. It can be a full-blown desktop application that relies mostly on the computing power of the local desktop PC. Or, an application can be a simple console application that system administrators use to manage infrastructure, yet, this application will - in it's simplest form - still need a runtime interpreter and storage to run on.


Infrastructure manages the physical and virtual world that applications live in. Infrastructure does not only exist for applications, but can also be a revenue driver when leased to third-parties. This can be a purely financial transaction. For example, webhosting providers offer services starting from only providing the bare infrastructure up to managing the full website and application stack on top of it.

Modern technology exists through the output of applications. An application is responsible for creating a user experience through some means of an interface and manage the data that it processes. It can be a full-blown desktop application that relies mostly on the computing power of the local desktop PC. Or, an application can be a simple console application that system administrators use to manage infrastructure, yet, this application will - in it's simplest form - still need a runtime interpreter and storage to run on.


Infrastructure manages the physical and virtual world that applications live in. Infrastructure does not only exist for applications, but can also be a revenue driver when leased to third-parties. This can be a purely financial transaction. For example, webhosting providers offer services starting from only providing the bare infrastructure up to managing the full website and application stack on top of it.

Application

Application

Anatomy of an application: data entry, processing, output
Anatomy of an application: data entry, processing, output
Anatomy of an application: data entry, processing, output

Applications are managing data through process. Although there can be parallel processing of the data with multiple outcomes, most of the time the objective is to produce an output, display, or visualization of the end result after the rules of the application were applied to the data. At each of the steps of an application the data must be secure as it is designed (could be more or less secure). This stringent thread of security rules should apply to the data sources, manual entry, streaming, enrichment of the data, the processing, as well as the outputs.


There is inherent risk in harmonizing all security, but the application is only concerned with the very content of the data. The physical data center, network controls, operating system, etc. are layers of infrastructure and do not count towards the application itself, unless the application exists to control these layers.


Finally, data management controls how data flows between systems and applications. This can include API development, advanced security and sharing controls. For example "in-flight data tracking" of commercial airlines vs. private planes or executive transportation, where data is handled on different infrastructure due to confidentiality regulations, while the applications are sharing the same structure, process and similar components.


Applications are managing data through process. Although there can be parallel processing of the data with multiple outcomes, most of the time the objective is to produce an output, display, or visualization of the end result after the rules of the application were applied to the data. At each of the steps of an application the data must be secure as it is designed (could be more or less secure). This stringent thread of security rules should apply to the data sources, manual entry, streaming, enrichment of the data, the processing, as well as the outputs.


There is inherent risk in harmonizing all security, but the application is only concerned with the very content of the data. The physical data center, network controls, operating system, etc. are layers of infrastructure and do not count towards the application itself, unless the application exists to control these layers.


Finally, data management controls how data flows between systems and applications. This can include API development, advanced security and sharing controls. For example "in-flight data tracking" of commercial airlines vs. private planes or executive transportation, where data is handled on different infrastructure due to confidentiality regulations, while the applications are sharing the same structure, process and similar components.


Infrastructure

Infrastructure

Infrastructure with responsibilities: SaaS, PaaS, IaaS, On-Prem
Infrastructure with responsibilities: SaaS, PaaS, IaaS, On-Prem
Infrastructure with responsibilities: SaaS, PaaS, IaaS, On-Prem

To manage infrastructure risk it is paramount to understand that there might be shared responsibility across between the contracting parties, depending on the risk appetite of the consuming party (client). By default, the provider of the deepest layer of infrastructure (datacenter, network, hosts) assumes the largest risk, because the value of physical assets is pre-determined and the impact of any risk to hardware is critical and/or costly. The direct correlation between minimizing risk and infrastructure cost can be determined by the level of control over the higher level layers of infrastructure and applications:

  • Do we have or can identify a trusted provider to balance the legal, compliance, security, and other requirements (according to ISO norms) while maintaining enough control over the remaining infrastructure and application?

  • How critical is the data in our application? Who should be liable for the availability of the application?

  • Is it worth expensing administrative cost to keep control over the lowest layer of the infrastructure that our application runs on?


With questions similar to these you can go up the pillar to determine the amount of risk you want to take for any given technology project.


Note that "Applications" in this context refers to the runtime of the applications that are running on the infrastructure. For example, for an application using a runtime such as .NET or NodeJS, this runtime needs to be installed, securely configured, and up to date.

To manage infrastructure risk it is paramount to understand that there might be shared responsibility across between the contracting parties, depending on the risk appetite of the consuming party (client). By default, the provider of the deepest layer of infrastructure (datacenter, network, hosts) assumes the largest risk, because the value of physical assets is pre-determined and the impact of any risk to hardware is critical and/or costly. The direct correlation between minimizing risk and infrastructure cost can be determined by the level of control over the higher level layers of infrastructure and applications:

  • Do we have or can identify a trusted provider to balance the legal, compliance, security, and other requirements (according to ISO norms) while maintaining enough control over the remaining infrastructure and application?

  • How critical is the data in our application? Who should be liable for the availability of the application?

  • Is it worth expensing administrative cost to keep control over the lowest layer of the infrastructure that our application runs on?


With questions similar to these you can go up the pillar to determine the amount of risk you want to take for any given technology project.


Note that "Applications" in this context refers to the runtime of the applications that are running on the infrastructure. For example, for an application using a runtime such as .NET or NodeJS, this runtime needs to be installed, securely configured, and up to date.


To manage infrastructure risk it is paramount to understand that there might be shared responsibility across between the contracting parties, depending on the risk appetite of the consuming party (client). By default, the provider of the deepest layer of infrastructure (datacenter, network, hosts) assumes the largest risk, because the value of physical assets is pre-determined and the impact of any risk to hardware is critical and/or costly. The direct correlation between minimizing risk and infrastructure cost can be determined by the level of control over the higher level layers of infrastructure and applications:

  • Do we have or can identify a trusted provider to balance the legal, compliance, security, and other requirements (according to ISO norms) while maintaining enough control over the remaining infrastructure and application?

  • How critical is the data in our application? Who should be liable for the availability of the application?

  • Is it worth expensing administrative cost to keep control over the lowest layer of the infrastructure that our application runs on?

With questions similar to these you can go up the pillar to determine the amount of risk you want to take for any given technology project.

Note that "Applications" in this context refers to the runtime of the applications that are running on the infrastructure. For example, for an application using a runtime such as .NET or NodeJS, this runtime needs to be installed, securely configured, and up to date.

Complexity across Applications and Infrastructure

Complexity across Applications and Infrastructure

Looking across the stages of any project with an output of application and infrastructure it becomes apparent that risk is a cross-functional element:

Looking across the stages of any project with an output of application and infrastructure it becomes apparent that risk is a cross-functional element:

Complexity across applications and infrastructure
Complexity across applications and infrastructure
Complexity across applications and infrastructure

This effect is exaggerated when deploying to multiple sites:

This effect is exaggerated when deploying to multiple sites:

Complexity in multiple site deployments
Complexity in multiple site deployments
Complexity in multiple site deployments

Even with higher degrees of standardization and automation it should be apparent that the overhead of management will allow for risks to slip through the cracks of the overall scope and schedule.

Even with higher degrees of standardization and automation it should be apparent that the overhead of management will allow for risks to slip through the cracks of the overall scope and schedule.

The Risk of Limited Resources

The Risk of Limited Resources

The Risk of Limited Resources

There is controllable and uncontrollable risk. Uncontrollable risk refers mostly to macroeconomic factors and other factors determined through a PESTLE analysis. This is not the concern of this article. Here, we focus on controllable risk.

Applications and infrastructure are controllable risks that are either managed by contracts and SLAs with providers or using the organizations' own resources. Risk that is transferred to a provider is calculated and therefore scoped. Using human resources to avoid or mitigate risk is more challenging. Especially, larger organizations tend to stretch their resources thin between operations and project work. Re-organization and evolving career opportunities lead to shuffling resources into different positions, horizontally within the organization. This increases risk overall, because resources might only partially be available.

There is controllable and uncontrollable risk. Uncontrollable risk refers mostly to macroeconomic factors and other factors determined through a PESTLE analysis. This is not the concern of this article. Here, we focus on controllable risk.

Applications and infrastructure are controllable risks that are either managed by contracts and SLAs with providers or using the organizations' own resources. Risk that is transferred to a provider is calculated and therefore scoped. Using human resources to avoid or mitigate risk is more challenging. Especially, larger organizations tend to stretch their resources thin between operations and project work. Re-organization and evolving career opportunities lead to shuffling resources into different positions, horizontally within the organization. This increases risk overall, because resources might only partially be available.

There is controllable and uncontrollable risk. Uncontrollable risk refers mostly to macroeconomic factors and other factors determined through a PESTLE analysis. This is not the concern of this article. Here, we focus on controllable risk.

Applications and infrastructure are controllable risks that are either managed by contracts and SLAs with providers or using the organizations' own resources. Risk that is transferred to a provider is calculated and therefore scoped. Using human resources to avoid or mitigate risk is more challenging. Especially, larger organizations tend to stretch their resources thin between operations and project work. Re-organization and evolving career opportunities lead to shuffling resources into different positions, horizontally within the organization. This increases risk overall, because resources might only partially be available.

Organizational Context of Portfolio Management (OPM 2013)
Organizational Context of Portfolio Management (OPM 2013)

Executing the strategy to increase value production capabilities through portfolio management needs to be aware and balance the availability of resources with the timeframe they are given to fulfill a strategic objective. Depending on how authority is distributed in an organization, portfolio managers might be able to offset some risk from internal employees to contractors or vendors. Nevertheless, there are more or less severe types of limitations of resources.

Executing the strategy to increase value production capabilities through portfolio management needs to be aware and balance the availability of resources with the timeframe they are given to fulfill a strategic objective. Depending on how authority is distributed in an organization, portfolio managers might be able to offset some risk from internal employees to contractors or vendors. Nevertheless, there are more or less severe types of limitations of resources.

Resource Risk: Limited Availability
Resource Risk: Limited Availability

Limited availability

  • Turnover / Attrition

  • Vacation

  • Extended period unavailable (i.e. medical leave)

Resource Risk: available, but not the right skill
Resource Risk: available, but not the right skill

Availability, but not the

right skill

  • Risk for Scope, Time, Budget, Quality, etc.

Resource Risk: Available, but limited in communication
Resource Risk: Available, but limited in communication

Available, but limited in

communication

  • Risk for stakeholders, expectations, resource management, etc.

Operational-work-precedence-over-projects
Operational-work-precedence-over-projects

Limited available because operational work takes precedence over project work

Limited available because operational work takes precedence over project work

When limited resource risk materializes it increases the schedule risk and can lead to monetary losses due to delayed value delivery. If something doesn't finish on time, the forecast of budget becomes invalid and risk of slippage is high.


The most common type of limited availability is when a resource is simply not available due to physical restrictions - vacations, medical leave, turnover (the resource simply left), etc. This can be mitigated by sharing process responsibilities, being able to back two resources up with each other. Given, that another resource is available.


In other cases the next available resource is selected to do the job, or was selected by personal preferences, disregarding limitations of skill. This poses risks for hard-skilled project management work like scope or quality. By using vendors or sourcing contingent labor with the skills needed this risk can be mitigated.


If the resource has the correct skill, but does not properly communicate process inputs, actions / process steps, or outputs the issue is a psychological hurdle to commit to the project. The resource might do the work to "get it off their plate", which affects quality and potentially scope. Some common reasons are work culture, career opportunities or obstacles, specific personal relationships with stakeholders. The resource in question might be of critical essence and therefore it is important to include their objections into any processes of the projects and programs that they are involved with.

When limited resource risk materializes it increases the schedule risk and can lead to monetary losses due to delayed value delivery. If something doesn't finish on time, the forecast of budget becomes invalid and risk of slippage is high.


The most common type of limited availability is when a resource is simply not available due to physical restrictions - vacations, medical leave, turnover (the resource simply left), etc. This can be mitigated by sharing process responsibilities, being able to back two resources up with each other. Given, that another resource is available.


In other cases the next available resource is selected to do the job, or was selected by personal preferences, disregarding limitations of skill. This poses risks for hard-skilled project management work like scope or quality. By using vendors or sourcing contingent labor with the skills needed this risk can be mitigated.


If the resource has the correct skill, but does not properly communicate process inputs, actions / process steps, or outputs the issue is a psychological hurdle to commit to the project. The resource might do the work to "get it off their plate", which affects quality and potentially scope. Some common reasons are work culture, career opportunities or obstacles, specific personal relationships with stakeholders. The resource in question might be of critical essence and therefore it is important to include their objections into any processes of the projects and programs that they are involved with.

When limited resource risk materializes it increases the schedule risk and can lead to monetary losses due to delayed value delivery. If something doesn't finish on time, the forecast of budget becomes invalid and risk of slippage is high.

The most common type of limited availability is when a resource is simply not available due to physical restrictions - vacations, medical leave, turnover (the resource simply left), etc. This can be mitigated by sharing process responsibilities, being able to back two resources up with each other. Given, that another resource is available.

In other cases the next available resource is selected to do the job, or was selected by personal preferences, disregarding limitations of skill. This poses risks for hard-skilled project management work like scope or quality. By using vendors or sourcing contingent labor with the skills needed this risk can be mitigated.

If the resource has the correct skill, but does not properly communicate process inputs, actions / process steps, or outputs the issue is a psychological hurdle to commit to the project. The resource might do the work to "get it off their plate", which affects quality and potentially scope. Some common reasons are work culture, career opportunities or obstacles, specific personal relationships with stakeholders. The resource in question might be of critical essence and therefore it is important to include their objections into any processes of the projects and programs that they are involved with.

The effect of Operations over Projects

The effect of Operations over Projects

operationas-vs-projects-psychology
operationas-vs-projects-psychology

When operational work is related to safety or mission critical, the resource that is most knowledgeable will most likely also be responsible or accountable for these operational tasks. Projects will need to wait. While this is generally understood, the value of project-related work for an operations-centric resource tends to be deprioritized more often than necessary.


In manufacturing and commodity industries HQ is far from the money while the physical assets - where the value is created - have the tendency to behave like independent Business Units. Operational activities supersede project-related activities (like training, deployment of hardware / software, etc.). The primary mission of the company is driven by asset-based revenue from their operations. Additionally, asset leads understand that new technology and project outcomes have unknowns and risks.


Because operations is orchestrated by schedules and might take on multiple roles, resources get moved around and might not be available as planned. The lack of backup resources might cause delays in project deployments.


Exceptions are seen when projects come from highly visible programs within the company, like Work Elimination, Digital Transformation, Cost Reduction programs, etc. where the pressure to deliver value through innovation or the use of current technologies is higher. Here, the implicit authority is granted by the criticality of the program. Asset leads are more likely to collaborate.


Some quotes from project managers that faced challenges when trying to deploy innovation projects at assets:

"The area lead change the agreed upon deployment timeline one week before we should have deployed on site."

"There was only one specialist for this task on site, and due to his extended unavailability, we lost value."

"My initiative owner was unresponsive to my attempts to talk about the projects issues and therefore the delay became substantial."


It can be derived that each program and project manager should opt for:

  • High visibility of the value and returns of the project or program.

  • Getting early buy-in.

  • Securing and affirming leadership backing from planning through to post-deployment.

When operational work is related to safety or mission critical, the resource that is most knowledgeable will most likely also be responsible or accountable for these operational tasks. Projects will need to wait. While this is generally understood, the value of project-related work for an operations-centric resource tends to be deprioritized more often than necessary.


In manufacturing and commodity industries HQ is far from the money while the physical assets - where the value is created - have the tendency to behave like independent Business Units. Operational activities supersede project-related activities (like training, deployment of hardware / software, etc.). The primary mission of the company is driven by asset-based revenue from their operations. Additionally, asset leads understand that new technology and project outcomes have unknowns and risks.


Because operations is orchestrated by schedules and might take on multiple roles, resources get moved around and might not be available as planned. The lack of backup resources might cause delays in project deployments.


Exceptions are seen when projects come from highly visible programs within the company, like Work Elimination, Digital Transformation, Cost Reduction programs, etc. where the pressure to deliver value through innovation or the use of current technologies is higher. Here, the implicit authority is granted by the criticality of the program. Asset leads are more likely to collaborate.


Some quotes from project managers that faced challenges when trying to deploy innovation projects at assets:

"The area lead change the agreed upon deployment timeline one week before we should have deployed on site."

"There was only one specialist for this task on site, and due to his extended unavailability, we lost value."

"My initiative owner was unresponsive to my attempts to talk about the projects issues and therefore the delay became substantial."


It can be derived that each program and project manager should opt for:

  • High visibility of the value and returns of the project or program.

  • Getting early buy-in.

  • Securing and affirming leadership backing from planning through to post-deployment.


When operational work is related to safety or mission critical, the resource that is most knowledgeable will most likely also be responsible or accountable for these operational tasks. Projects will need to wait. While this is generally understood, the value of project-related work for an operations-centric resource tends to be deprioritized more often than necessary.

In manufacturing and commodity industries HQ is far from the money while the physical assets - where the value is created - have the tendency to behave like independent Business Units. Operational activities supersede project-related activities (like training, deployment of hardware / software, etc.). The primary mission of the company is driven by asset-based revenue from their operations. Additionally, asset leads understand that new technology and project outcomes have unknowns and risks.

Because operations is orchestrated by schedules and might take on multiple roles, resources get moved around and might not be available as planned. The lack of backup resources might cause delays in project deployments.

Exceptions are seen when projects come from highly visible programs within the company, like Work Elimination, Digital Transformation, Cost Reduction programs, etc. where the pressure to deliver value through innovation or the use of current technologies is higher. Here, the implicit authority is granted by the criticality of the program. Asset leads are more likely to collaborate.

Some quotes from project managers that faced challenges when trying to deploy innovation projects at assets:

"The area lead change the agreed upon deployment timeline one week before we should have deployed on site."

"There was only one specialist for this task on site, and due to his extended unavailability, we lost value."

"My initiative owner was unresponsive to my attempts to talk about the projects issues and therefore the delay became substantial."

It can be derived that each program and project manager should opt for:

  • High visibility of the value and returns of the project or program.

  • Getting early buy-in.

  • Securing and affirming leadership backing from planning through to post-deployment.

Solution 1: Asset Deployment Report and Meetings

To facilitate deployments and coordinate with multiple assets across multiple projects and programs, a critical event schedule should be maintained per site. Then, a central resource at HQ facilitates weekly meetings with area and asset leads, program managers, sponsors, and resource manager(s) for those projects that intend to deploy within a reasonable period in the future (for example within the next 60 days).

To facilitate deployments and coordinate with multiple assets across multiple projects and programs, a critical event schedule should be maintained per site. Then, a central resource at HQ facilitates weekly meetings with area and asset leads, program managers, sponsors, and resource manager(s) for those projects that intend to deploy within a reasonable period in the future (for example within the next 60 days).

Asset-deployment-report-and-meetings
Asset-deployment-report-and-meetings

In this example, an organization is rolling out major enhancements to their SAP Material Management Module to assets by country. Through a facilitator that is using a report the weekly meeting shall resolve conflicts on project-related work and make sure that the value of the projects is understood. The resource manager eventually can resolve resource conflicts.

The limitation of this approach is transparency. The Country Operations Leads might have different facilitators from other projects/programs across the organization. The prioritization might happen on a first-come-first-serve basis instead of a risk-based or value-based approach.

In this example, an organization is rolling out major enhancements to their SAP Material Management Module to assets by country. Through a facilitator that is using a report the weekly meeting shall resolve conflicts on project-related work and make sure that the value of the projects is understood. The resource manager eventually can resolve resource conflicts.

The limitation of this approach is transparency. The Country Operations Leads might have different facilitators from other projects/programs across the organization. The prioritization might happen on a first-come-first-serve basis instead of a risk-based or value-based approach.


In this example, an organization is rolling out major enhancements to their SAP Material Management Module to assets by country. Through a facilitator that is using a report the weekly meeting shall resolve conflicts on project-related work and make sure that the value of the projects is understood. The resource manager eventually can resolve resource conflicts.

The limitation of this approach is transparency. The Country Operations Leads might have different facilitators from other projects/programs across the organization. The prioritization might happen on a first-come-first-serve basis instead of a risk-based or value-based approach.

Solution 2: Automation through a Site Availability Schedule

By maintaining an availability schedule per site important milestones can be aligned with critical events and conflicts can be reasonably resolved.

In this example, the Country Operations Leads are entering availability of their resources into a schedule, while the project/program managers are marking up tasks with the country (GHAN, BR, MEX, MYS, USA). A central report is available in real-time and potential conflicts across all projects/programs at all sites are visibile.

By maintaining an availability schedule per site important milestones can be aligned with critical events and conflicts can be reasonably resolved.

In this example, the Country Operations Leads are entering availability of their resources into a schedule, while the project/program managers are marking up tasks with the country (GHAN, BR, MEX, MYS, USA). A central report is available in real-time and potential conflicts across all projects/programs at all sites are visibile.

Automation-through-site-availability-schedule
Automation-through-site-availability-schedule

Primary benefits of this regular approach:

  • Potential events and impacts to projects are visible early on.

    • Project stakeholders are well informed about major events at sites and projects or programs.

    • Site leads are well informed about value, criticality, impact, and other benefits of their piece of the project or program.

  • Projects can decide to switch timelines with other assets/sites to keep the project/program deadlines on track.


One restriction could be the willingness of the site leads for this additional, regular touch point.

Primary benefits of this regular approach:

  • Potential events and impacts to projects are visible early on.

    • Project stakeholders are well informed about major events at sites and projects or programs.

    • Site leads are well informed about value, criticality, impact, and other benefits of their piece of the project or program.

  • Projects can decide to switch timelines with other assets/sites to keep the project/program deadlines on track.


One restriction could be the willingness of the site leads for this additional, regular touch point.


Primary benefits of this regular approach:

  • Potential events and impacts to projects are visible early on.

  • Project stakeholders are well informed about major events at sites and projects or programs.

  • Site leads are well informed about value, criticality, impact, and other benefits of their piece of the project or program.

  • Projects can decide to switch timelines with other assets/sites to keep the project/program deadlines on track.

One restriction could be the willingness of the site leads for this additional, regular touch point.

Solution 3: The Project Risk Governance Board

When companies run many highly visible programs, touch points with only the assets might not be enough to cover potential risk to deliver value to the share- and stakeholders. A larger scale approach is the creation of a Project Risk Governance Board with authority to define and control overarching risk controls. This results in the following benefits:

  • Risk Appetite and Tolerance: Defines the level of risk the organization is willing to accept while understanding the vision due to leadership involvement.

  • Prioritizing strategically: Risks and projected values are prioritized so that resources are available where the highest value can be generated.

  • Risk Culture: Fosters a culture of risk awareness and strong leadership to guide risk management efforts (control, mitigation, transfer, etc.).

  • Adaptive Risk Management: Continuously adapts risk management practices to address emerging threats and changing business environments.

  • Risk Governance: Ensures that all risk management practices comply with relevant regulations and standards.

When companies run many highly visible programs, touch points with only the assets might not be enough to cover potential risk to deliver value to the share- and stakeholders. A larger scale approach is the creation of a Project Risk Governance Board with authority to define and control overarching risk controls. This results in the following benefits:

  • Risk Appetite and Tolerance: Defines the level of risk the organization is willing to accept while understanding the vision due to leadership involvement.

  • Prioritizing strategically: Risks and projected values are prioritized so that resources are available where the highest value can be generated.

  • Risk Culture: Fosters a culture of risk awareness and strong leadership to guide risk management efforts (control, mitigation, transfer, etc.).

  • Adaptive Risk Management: Continuously adapts risk management practices to address emerging threats and changing business environments.

  • Risk Governance: Ensures that all risk management practices comply with relevant regulations and standards.

Project risk governance board example
Project risk governance board example

Conclusion

Conclusion

Conclusion

Most controllable risks stem from limitation of human resources, especially when technology outcomes need to be deployed at multiple assets. Critical initiatives will manage their risk by increasing touch points with assets that they eventually will deploy the technology to, but an overarching approach saves these touch points in favor of increased visibility through risk management. This could be more informal through a report and meeting between site leads and a facilitator or through a more formal Project Risk Management Board, which, equipped with authority can proactively manage to minimize risks, especially in companies with programs that have many dependencies on each other.

Innovation is Change is Risk: Developing and/or deploying large projects with innovative elements will be a differentiating factor in the future.

Application and Infrastructure as elements of Risk: Risk might be derived from the physical elements that are implemented.

Resource Risk is critical: Large projects / programs stand and fall with availability of resources.

Proactive Risk Management: Having a central system, report, and regular touchpoint that focuses on resource availability can steer the schedule to avoid still stand.

Risk Governance Board: Including Finance, Procurement, and Legal fosters a culture where risks can be more confidently categories, assessed, discussed and managed.