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 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
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
Application Development
Software Upgrades
Custom Software Solutions
Application Development
Software Upgrades
Custom Software Solutions
Infrastructure
Network Infrastructure
Data Center Projects
Hardware Upgrades
Telecommunications
Security
Risk Assessment
Penetration Testing
Compliance Projects
Incident Response
Data Management
Database Management
Big Data Projects
Data Analytics
Data Warehousing
Digital Transformation
Process Automation
Business Intelligence
Customer Experience Enhancement
Enterprise Resource Planning
Cloud
Cloud Migration
Cloud Infrastructure Management
SaaS Implementation
AI and Machine Learning
Predictive Analytics
Natural Language Processing
Robotic Process Automation
Deep Learning Projects
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:
Strategic
Market Changes
Competitive Threats
Technology Obsolescenes
Operational
Process Inefficiencies
System Failures
Human Errors
Financial
Financial Transactions
Investments
Economic Fluctuations
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:
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
Application Development
Software Upgrades
Custom Software Solutions
Infrastructure
Network Infrastructure
Data Center Projects
Hardware Upgrades
Telecommunications
Security
Risk Assessment
Penetration Testing
Compliance Projects
Incident Response
Data Management
Database Management
Big Data Projects
Data Analytics
Data Warehousing
Digital Transformation
Process Automation
Business Intelligence
Customer Experience Enhancement
Enterprise Resource Planning
Cloud
Cloud Migration
Cloud Infrastructure Management
SaaS Implementation
AI and Machine Learning
Predictive Analytics
Natural Language Processing
Robotic Process Automation
Deep Learning Projects
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
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
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
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:
This effect is exaggerated when deploying to multiple sites:
This effect is exaggerated when deploying to multiple sites:
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.
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.
Limited availability
Turnover / Attrition
Vacation
Extended period unavailable (i.e. medical leave)
Availability, but not the
right skill
Risk for Scope, Time, Budget, Quality, etc.
Available, but limited in
communication
Risk for stakeholders, expectations, resource management, etc.
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
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).
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.
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.
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.
Reach Your Targets
Book Initial Assessment
Schedule a call with Jakub M.
Reach Your Targets
Book Initial Assessment
Schedule a call with Jakub M.
Reach Your Targets
Schedule a call with Jakub M.