Skip to main content

Checklist for an infrastructure business case (from ITIL)

This is a checklist for an infrastructure project from the ITIL books.
  • Identification and quantification of all the benefits to the business and its customers.
  • The overall scope, objectives and Critical Success Factors (CSFs) of the proposed solution.
  • The business sponsor, owner and list of stakeholders.
  • A description of the current situation, including strengths, weaknesses, opportunities and threats.
  • The strategic fit and details of how the preferred solution conforms to, or deviates from, existing business and technology policies, strategies and plans.
  • The implications and impact of not proceeding with the business case.
  • A description of the proposed new services, components or technology being considered.
  • Constraints and dependencies.
  • Contractual, legal and regulatory issues environmental issues.
  • An overview of how this proposal support the key strategic objectives of:
    • the business strategies.
    • the technology strategy.
  • Market considerations:
    • The markets involved and their possible geographical variations.
    • External opportunities and threats.
    • Market share and competitors.
    • The key customer segments and business sectors.
    • Present and forecasted volumes, revenues and profit.
    • Regulatory and legislative constraints.
    • Trends in price, quality, standards and technology.
    • Competitive services and products, their quality and performance.
  • Proposed Go Live date.
  • How key strategic objectives and benefits are to be achieved.
  • How the objectives, CSFs and business benefits will be measured
  • Details of the project methodology and approach.
  • Details of all impacts on, and benefits to:
    • Technology structures and processes.
    • The business structures and processes.
    • The market.
    • Internal customers.
    • External customers.
    • Market share and competitors.
    • Other technology systems and services.
    • Human resources: headcounts, operational support and responsibilities.
  • Details of anticipated business volumes and technology volumes
  • Identification and quantification of all risks:
    • Description of the risk
    • Probability of the risk
    • The impact of the risk
    • Analysis of the risk
    • Steps taken to manage and minimise the risk
    • Any necessary contingency plans and expenditure
  • The preferred solution with its advantages, disadvantages, benefits, risks, costs, resources and time-scales, including ongoing requirements and costs.
  • Alternative solutions considered and their advantages, disadvantages, benefits, risks, costs and time-scales, including ongoing requirements and costs, including the ‘do nothing’ option.
  • The reasons for selecting the preferred suppliers and rejecting alternative suppliers.
  • Details of key milestones in the implementation process and the overall dependency upon them.
  • Details of related projects, dependancies and their interfaces and approval status.
  • Details of any dependent programmes or projects and their dependencies and approval status.
  • The authorising, owning or sponsoring body and budget(s) to be used.
  • Details of the approach to be adopted (e.g., in-house development, contracted-in development or outsourced development).
  • What levels of service are expected from the new services, components or technology and whether they are consistent with all existing levels and targets.
  • Procurement plans and policies with details of the preferred suppliers and their costs and comparative alternatives and their costs.
  • Financial analysis:
    • Financial assumptions.
    • Initial costs.
    • Ongoing costs.
    • Financial constraints and budgets.
    • Payback period and return on investment (ROI.)
    • Tolerances and sensitivities.
    • Funding and stakeholders.
    • The effect on the organisation’s financial performance and profitability.
  • The requirements for resources and finances from other areas of the company or externally.
  • The level of authorisation or approval necessary and the required time-scale for approval.
  • Summary and recommendations, clear, concise and unambiguous.


Popular posts from this blog

Why Madge Networks, the token-ring company, went titsup

There I was shooting the breeze with an old mate. The conversation turned to why Madge Networks which I wrote about here went titsup. My analysis is that Madge Networks had a solution and decided to go out and find a problem. They deferred to more incorrect strategic technology choices. The truth of the matter is that when something goes titsup, its not because of one reason only, but a myriad of them all contributing to the negative consequence. There are the immediate or visual ones, which are underpinned by intermediate ones and finally after digging right down, there are the root causes. There is never a singular root cause for anything but I'll present my opinion and encourage everyone else to chip in. All of them together are more likely the reason the company went titsup. As far as technology brainfarts go there is no better example than Kodak . They invented the digital camera that killed them. However, they were so focused on milking people in their leg

Flawed "ITIL aligned"​ Incident Management

Many "ITIL aligned" service desk tools have flawed incident management. The reason is that incidents are logged with a time association and some related fields to type in some gobbledygook. The expanded incident life cycle is not enforced and as a result trending and problem management is not possible. Here is a fictitious log of an incident at PFS, a financial services company, which uses CGTSD, an “ITIL-aligned” service desk tool. Here is the log of an incident record from this system: Monday, 12 August: 09:03am (Bob, the service desk guy): Alice (customer in retail banking) phoned in. Logged an issue. Unable to assist over the phone (there goes our FCR), will escalate to second line. 09:04am (Bob, the service desk guy): Escalate the incident to Charles in second line support. 09:05am (Charles, technical support): Open incident. 09:05am (Charles, technical support): Delayed incident by 1 day. Tuesday, 13 August: 10:11am (Charles, technical support): Phoned Alice.

Updated: Articles by Ron Bartels published on iot for all

  These are articles that I published during the course of the past year on one of the popular international Internet of Things publishing sites, iot for all .  These are articles that I published during the course of the past year on one of the popular international Internet of Things publishing sites, iot for all . Improving Data Center Reliability With IoT Reliability and availability are essential to data centers. IoT can enable better issue tracking and data collection, leading to greater stability. Doing the Work Right in Data Centers With Checklists Data centers are complex. Modern economies rely upon their continuous operation. IoT solutions paired with this data center checklist can help! IoT Optimi