The classes of IT risks are interdependent. Risks in each different class can impact on other classes.
Understanding these relationships will help you capitalize on virtuous- cycles – avoiding upstream risks to eliminate downstream risks, tackling potential problems at source and focusing on prevention rather than cure.
The following series of figures and supporting notes describe these key relationships between IT risks that fall within each class.
Strategic and emergent risk relationships
Poor management of strategic and emergent risks can drive project risks (see Figure 3.1). Key amongst these are the risks in project selection and direction: that the wrong projects are pursued and/or the right projects are not. Also, during the course of IT projects strategic direction corrections or re-alignment may be required. If the corrections do not occur, the project no matter how well conceived at initiation may ultimately be a failure.
Poor management of strategic and emergent risks can drive application and infrastructure risks. Applications and infrastructure components have to be selected but in the absence of a clear strategy and target system architecture these decisions will be made on a tactical or ad hoc basis. Many risks can result from an unmanaged increase in technology diversity, impacting development, maintenance and enhancement activity – difficulties in changing and integrating different systems – and operational support – difficulties in identifying, diagnosing and fixing problems.
Poor management of strategic and emergent risks can drive service provider risks. IT outsourcing decisions are often also IT strategic decisions as their impact will last for many years. A poor sourcing strategy and selection process can drive significant risks into the service transition period and beyond as ongoing service
Figure 3.1—Strategic and emergent risk relationships
delivery by individual providers fails to meet your needs. When multiple suppliers are required to work together, a strategy that guides this ‘multi-source’ arrange- ment is essential – otherwise gaps, overlaps and disconnects occur and assuring the delivery of end-to-end services becomes extremely difficult.
Project risk relationships
Poor management of project risks can drive risks in the implemented service (see Figure 3.2). This translates as IT service continuity and information asset risks, including:
•
A late or undelivered project results in a continued reliance on the existing, unimproved IT services.•
Delivery of new and different vulnerabilities, flaws and weaknesses along with the new system. New and changed systems go through a post-implementation period that requires heightened alertness and responsiveness in the user base and IT support team. Defects that must be fixed may require unwelcome outages.•
Information assets may not retain their integrity when being migrated across to the new system, with the introduction of anomalies and inconsistencies.•
Any gaps in training of the user base can become manifest as service degrada-tion after go-live.
Poor management of project risks can drive risks in the implemented product, translating as applications and infrastructure risks, including:
•
A ‘quick and dirty’ engineering approach within a project can result in a system that is difficult to operate, support, maintain and enhance.•
Even if the new solution has been effectively engineered, it is still new to the operators and a learning curve must be climbed. Ineffective training andhandover from the project team to the operations and support team can create a lasting legacy of risk in the production system.
•
Poor product choices are made in projects – without regard for an overarching strategy and without adequate consultation and involvement of those who will be responsible for the system downstream. Future applications and infra- structure teams can be hamstrung and those reliant on them sorely disappointed when a ‘not invented here’ and a ‘no guarantees’ response is encountered when problems arise.Service provider and vendor risk relationships
Poor management of service provider risks can drive project risks (see Figure 3.3). A major milestone in any project is the successful contracting of the solution delivery partners. This milestone will require a watertight contract for each service provider relationship. This should be a complete and sufficient statement of work and a sufficient level of shared understanding between both parties as to how the service provider’s work will be managed and delivered. Unfortunately in some projects this milestone is not reached until the end; in some projects, never. When ‘delivery to contract’ is unclear, it is no surprise that poorly managed service provider risks may manifest themselves in product and service delivery risks within the context of the project.
The possible risks are as extensive as the set of project tasks and deliverables that may be reliant on service providers, which can extend to responsibility for the entire project. Particularly acute are the interrelationships between project tasks and service provider engagement – for example, the difficulties in defining a full scope of work without having completed analysis, additional details
Figure 3.3—Service provider risk relationships
discovered in technical design that require a change in system and project scope, etc. Management of multiple suppliers, potentially in prime and sub- contractor formation adds another level of complexity and difficulty to project risk management.
Poor management of service provider risks can drive ongoing application and infrastructure risks. When IT services are outsourced and the systems are in the hands of service providers these risks intertwine. Outsourcing is effectively a decision to contract for services, transferring responsibility for applications and infrastructure asset management to providers. They are then held responsible for the delivered service, to a defined standard of performance, for an agreed cost. Even in an outsourcing context, application and infrastructure risks will still exist in their own right (i.e. applications can be flaky, infrastructure foundations shaky), however there will be a reliance on the outsourced service provider to manage these risks on your behalf. While some view outsourcing as transfer of risk, we view it as a transfer of risk management responsibilities. The Australian National Audit Office report that a major outsourcing project did not transfer the risk as intended, but retained most of it (ANAO, 2001).
When a more straightforward vendor relationship exists – i.e. IT products are purchased from a vendor and licensed for use – it is simpler to separate the risks into either a product failure or a vendor failure. If a product fails then the vendor is relied upon to fix it – any vendor service failings in the ‘break–fix’ cycle can have serious consequences. If the vendor fails, then no matter how solid the product, because of various risks associated with the lack of support, lack of an upgrade path and so on, it will be necessary to migrate to a new product, generally much more quickly than planned.
Applications and infrastructure risk relationships
Poor management of applications and infrastructure can drive on-going IT service continuity and information asset risks (see Figure 3.4). Applications and infrastructure exist to support the delivery of IT services and to build and safeguard information assets. Weaknesses and vulnerabilities in applications and infrastructure, when exploited by threats, can cause whole or partial IT
service failures. In many businesses, temporary loss of primary computer systems can cause significant pain through temporary disruption of business processes, while permanent damage to critical application and data servers can truly represent a ‘worst case’ scenario that can cripple business operations. Some organizations are equipped with disaster recovery plans and facilities to allow a re-establishment of applications on a standby infrastructure. In such an instance data back-up and recovery procedures are vital if information assets are to be recovered.
Other relationships exist between the classes of IT risk that are not illustrated on the series of IT risk relationship diagrams, primarily for simplicity. These include: