How To Build a Better Business Case for the Cloud

“Get your facts first. Then you can distort them as you please.” — Mark Twain

I learned a lot about business cases over the years, simply by working in the space of enterprise strategy and digital transformation.

I want so share what I learned at Microsoft about building business cases for the Cloud to help more leaders succeed when it comes to driving digital transformation.

You can use this set of guiding principles and a frame to help you think about, structure and build a better business case for the Cloud. Note that you can use many of these business case building ideas for more than just the Cloud.

Keep in mind that to create an effective business case, you need to tailor it to the needs of your specific organization and the key stakeholders, and each business case is unique (like a snowflake, and snowflakes share patterns).

Objectives

When learning how to build a better business case for the Cloud, it helps to keep the following objectives in mind:

Identify the key components of a business case for the Cloud
Use proven techniques and tools when building a business case for the Cloud
Identify the appropriate business case approach for a specific Cloud opportunity
Understand what’s needed to prepare a solid business case for the Cloud

What is a Business Case?

Before we begin, let’s define what a business case is. You can think of a business case in very simple terms:

A business case provides justification for an investment.

The business case evaluates the benefits, costs, and risks of alternative options, while providing a rationale for the preferred solution.

Overview of Building a Business Case for the Cloud

The business case for the Cloud is not purely an IT issue nor is it outsourcing by a different name. Motivations for Cloud migration are not purely about reducing total cost of ownership (TCO).

Increasingly, Cloud motivations involve both IT and business stakeholders and relate to the provisioning of flexible capabilities to meet current and future business needs.

Business agility is an ever increasingly critical driver for the Cloud.

The goal of the business case for the Cloud is to qualify and quantify the benefits, risks, costs and savings expected as outcomes from a Cloud initiative.

Your goal in writing a business case is to gain acceptance for one or more Cloud initiatives in the form of a customer go-ahead for a project or the next phase of a Cloud engagement.

A business case may or may not require a detailed ROI analysis, depending on who you are developing the business case for and at what stage they are in the buying cycle.

Keep your stakeholder’s needs in mind. Different amounts of detail will be needed and the focus of the business case will vary depending on what information the stakeholders need in order to make a decision.

How To Check the Quality of a Business Case

The business case is structured based upon what the customer needs in order to make an investment decision.

The core of any business case is a description of the realizable improvement that will be created over time and delivered to stakeholders.

Use the following questions to check the quality of a business case:

Does the business case demonstrate a strategic fit to the organization’s business goals, KPIs and measures?
Is the proposed Cloud solution going to be able to meet the customer’s key requirements and are there any specific barriers to be addressed?
Are the costs and time figures realistic and accurate?
Are both migration and ongoing costs included?
Are risks and mitigations included?
How do the costs compare to industry norms?
Are short, medium and long term benefits called out?
Is the IT infrastructure mature enough to make a move to the Cloud?

A Simple Approach to the Business Case

A business case can be simple or complex as long as it enables your stakeholders to make an investment decision.

A simple business case may need no more information than:

A measurement of weakness for the business. For instance, too much IT spend, lack of agility, low customer satisfaction, etc.
An argument showing that an approach has worked for other similar customers. Show proven potential improvement in the area of weakness.
Cost/Benefit analysis that shows a positive return on investment over a specific period of time.

The key questions you need to consider are who the decision maker is and what elements of a business case need to be present for that decision maker to gain their agreement to make the investment decision?

While rigorous business cases are sometimes warranted, sometimes it is better to keep them simple by applying rigor to address the customer’s needs and manage exposure to risk.

Why the Business Case

The purpose of the business case is to make a case for investment in a Cloud initiative. The business case is aimed at business decision makers and should be written in their language.

In order to present a successful business case you need to know your audience, who makes the business decision, and you need to know what information they need in order to make a decision.

Common Business Case Scenarios

What is required for the business case will vary based on the scenario. Here are some examples of common business case scenarios:

Simple help to align technology to business objectives.
Help provide input on costs, benefits to an internal business case.
Create a full 5 year business case for the sponsor.
Realization planning that uses the output of the business case to define deliverable measures based on adoption.

Note that what is required will also vary depending on where your stakeholders are in the investment life cycle. For example your stakeholders may be looking to test out a high level value proposition before going to the next step, versus a final business case and realization plan for program sign off.

Guiding Principles for a Business Case

All organizations are different; however, there are common themes that result in a successful evaluation to adopt Cloud-based solutions:

Identify key drivers and objectives. Identify the stakeholder expectations and verify that they line up with the value delivered by the identified solution. Attempt to maximize the set of stakeholder expectations that can be met with the solution.
Associate benefits with specific stakeholders. Consider each benefit and identify the most relevant stakeholder to whom the benefit will be delivered as well as the timeframe in which the benefit will be delivered. The more senior the stakeholder the simpler and more focused the material must be for their role and level of interest. For example, a Sales Director is probably not interested in IT virtualization savings.
Consider the impact of change. Identify the scope of changes needed to enable the changes.
Consider the timing. Is this the right time for an investment in Cloud solutions based on investment cycles, business needs and levels of sponsorship? Factor in timelines for migration, adoption and introduction of new services as well as de-commissioning and alignment with other investments and milestones.
Define your assumptions. Create and provide clear assumptions across stakeholders. When presenting quantitative information, document the source of data along with assumptions of trustworthiness if appropriate.
Leverage customer terminology, templates and language. Do not confuse the stakeholders with terminology. Use customer terminology and templates where possible. Focus purely on what the decision makers need in order to make a decision.
Peer review your figures. Ask others to peer review your figures to ensure they are realistic and make sense. Do not present metrics you do not understand and cannot explain.
Pilot and test. Use the Cloud to pilot the program, prove the benefits and expose the risks early.
Support the business case with financial models and data. Tell a compelling story in the business case, and then back it up with financial models and comprehensive data.
Leverage a Customer’s Process or Tools. Does your customer already have a process or set of tools they prefer to use to construct business cases? If they do, then use them. By using customer methods, you give stakeholders a higher level of familiarity and therefore more comfort and confidence in the results.

Steps for a Business Case

The following is an example process for creating a business case:

Step 1 – Define Benefits and Measures Aligned to Business Drivers
Step 2 – Quantify the Benefits
Step 3 – Quantify the Costs
Step 4 – Quantify the Risks
Step 5 – Review/Refine Financial Metrics
Step 6 – Presenting the Business Case

Bear in mind that these steps may be modified by the customer, based on their processes and constraints.

Steps for a Business Case Explained

Let’s go ahead and walk through each step, focusing on the main idea…

Step 1 – Define Benefits and Measures Aligned to Business Drivers

A business case should recognize both financial and non-financial benefits. Identify an owner for each benefit – to ensure that the business changes are achieved and make sure you link benefits explicitly to both the IT and the business changes required to deliver them.

Step 2 – Quantify the Benefits

Identify measures for all benefits, including subjective or qualitative benefits and include evidence relating to the size of the benefits. Align benefits with the organization’s key drivers and objectives.

Step 3 – Quantify the Costs

Identify and quantify the costs needed to implement the desired changes. Costs refer to the expenses involved in implementing and managing the proposed IT initiative.

Step 4 – Quantify the Risks

Evaluating risk is critical to overcoming hidden objectives to an initiative. If the decision-maker perceives risks that have not been addressed, they may not approve an initiative even if the ROI is strong and the benefits are clear.

Step 5 – Review/Refine Financial Metrics

Ultimately, the client should find credible the numbers supporting the financial metrics. This step effectively becomes the sign-off on the financial justification.

Step 6 – Presenting the Business Case

The final deliverable for a business case has two components – a Word document containing prose, diagrams and figures to document the business case and a PowerPoint presentation to help you convince stakeholders of the value of the proposed Cloud initiative.

Financial information is computed using a spreadsheet but the results should be included in the Word document. Be sure to use customer terminology and any templates if they have them.

Use language your stakeholders will understand and avoid confusing them with terminology.

Cost, Risk, and Value

Any robust business case needs to include costs, risks and value.

Cost

To evaluate the potential benefits of a Cloud solution, review current costs and services against what a Cloud service can provide over time.

For example, an organization may have a messaging system that has a basic 250MB mailbox and calendaring that relies on third-party archiving, email security and makes do with ad hoc updates.

Comparing this to Microsoft’s Office 365 Cloud productivity service you find that it provides a sizable mail box plus searchable archive, access/mail security and provision of an automatic update (evergreen) service.

A Cloud service may provide additional capabilities that are not provided by the legacy system, such as collaboration and unified communications. The benefits will need to be established even though there are no current costs in the legacy system.

Consider using a 1-year, 3-year, or 5-year period to measure benefits, mapping the organizational costs for people, third-party software, support, licensing, security, data center charges and refresh costs to establish a realistic cost per user. Then compare these numbers with the Cloud solution, including migration and cash-flow costs.

The benefit may not be cost reduction but an accelerated set of capabilities and lower capital investment. Other benefits may include creating common services across global business units reducing refresh costs, and providing cost transparency.

To develop both comparison costs per user and a view of the financial model for ROI calculations, the migration costs and other investments need to be factored in to the model along with cost of capital.

Typically, the migration costs will have two main components. First, a service provider charge, perhaps per mailbox or user to migrate current data, and second, the on-premise costs for the organization associated with remedial work for directory consolidation, access management, coexistence and synchronization.

By creating a five-year financial model, cost can be assessed with regards to phasing of migration, decommissioning, refresh avoidance, required volume of users and required services per user group. This approach provides a clear view of the investment phasing while also factoring in the timing of business needs

Risk

There are well-established mechanisms for estimating the financial and technical risks associated with an investment in IT. Keep in mind that it is often the reluctance or inability of the staff within an organization to make the necessary business or organizational changes that prevent benefits from being achieved.

By assessing the difficulty of making each change required to deliver a particular benefit, an organization can assess the risks of not achieving the business case. The development of a Benefits Dependency Network can help by providing a means of assessing not just overall project risk but risk in relation to each benefit.

The value of the particular benefit at risk will then suggest the importance of taking action to avoid or mitigate the risk.

Value

There are many ways to define value. Value to the business can be represented in tangible terms such as financial value or intangibles such as agility, reputation, customer satisfaction or even employee satisfaction. Value to stakeholders may or may not align with business values.

Decision making or budget holding stakeholder values should be considered carefully.

In financial terms, value is equal to (Benefit – Cost).

Benefits may be spread over time and may be hard to represent in dollar amounts. Costs may also be spread over time and may include one time as well on-going costs.

ROI and Payback

Return on Investment (ROI) and payback period analysis are tools you can use to compare multiple investment scenarios. ROI measures the expected performance of an investment in percentage terms.

Payback period measures how long it will take for an investment to break even.

A strong investment scenario will have a high ROI and a low payback period.

Customer priorities will dictate whether ROI or payback is more important. For instance a customer may be looking to reduce capital costs in exchange for operational costs, in which case a high ROI and long payback may be the priority.

Alternatively if the customer is looking to reduce operational costs, then a fast payback period may be the priority.

ROI – Return on Investment

ROI is used as a measure against performance. It evaluates investment efficiency or efficiency to compare a number of different investment scenarios. ROI is expressed as a ratio of the return on investment divided by the cost of the investment, where the return on the investment is the gain minus the cost as shown below:

ROI = (Gain from Investment – Cost of Investment) / Cost of Investment

ROI is useful in two primary ways.

A negative figure indicates net loss on investment.
A higher figure indicates a higher relative return.

Payback Period

The payback period is defined as the amount of time that is needed to recover the cost of the investment. Payback period can be represented as:

Payback Period = Cost of Project / Annual Cash Flows

The payback period allows you to compare time to recover costs for multiple investment scenarios, where the lower duration payback period is generally the better investment.

In general in today’s IT environment investment decisions will usually target shorter timeframes of 3 years or less. This means that longer payback periods will require significantly higher rates of return in order to justify the investment.

A $250,000 project that returns $25,000 per year will have a payback period of 10 years.

As a rough measure of value, payback suffers because it ignores durable benefits and the time value of money.

Due to these deficiencies, alternate methods of capital budgeting are usually preferred. Such measures might include net present value (NPV) or Internal Rate of Return (IRR). NPV and IRR are both derived from Discounted Cash Flow (DCF) analysis.

Net Present Value (NPV)

The NPV of a project is the present discounted value of all future net cash flows from the project. Whereas ROI and Payback are better suited towards simple business case discussions, NPV is a possible measure for discussions with CxO level stakeholders on initiatives where future value must be predicted.

It is important to note that NPV by itself is insufficient to tell the full story surrounding an investment opportunity.

Examining the value exclusive of the contributing factors can mask important details about the investment. For example, a given investment might have a favorable NPV value, but the bulk of the returns might occur at the very end of the 3 year investment calculation. In this case NPV will have hidden the fact roughly 2.5 years of operating will yield no significant returns, which would likely make the investment unfavorable.

When presenting NPV, be sure to support the calculation with the important contributing factors such as the payback period, rate of return, and cost. These factors should be the basis of the evidence, and NPV can be used to support them.

Economic Value Added (EVA)

Shareholder Value is best measured by Economic Profit, or Economic Value Added (EVA). Accounting profit, or Net Income, only deducts the cost of debt financing; interest expense.

EVA deducts the (opportunity) cost of giving shareholders a minimum acceptable return on their equity investment in the firm. Thus, a positive EVA means that the firm has covered all its financing costs, both debt and equity. It has covered the full cost of capital.

The EVA framework takes into account the tradeoff decisions between Growth, Cost Efficiency and Capital Productivity.

Common Business Case Examples for the Cloud

Frequently, Cloud initiatives can be split between two buckets:

Migrate an existing workload
Develop a new workload

Correspondingly, these types of initiatives align to business case models as follows:

Migration: Workload migration is generally a discussion of ROI and payback time. ROI allows you to compare costs and benefits of an existing workload compared to Cloud migration.
New Development: New efforts are generally a discussion of Net Present Value (NPV). NPV allows you to measure the total value of the project over time.

Common drivers for Cloud migration that can be addressed in a business case include:

Agility. We’re in a world of real-time data and real-time opportunities, we need more agility in our business.
Better Service. We want to be able to offer software to non-traditional consumers. We need to provide seamless experiences that span a diversity of devices. The Cloud helps us do that. We have short term or periodic work streams that could be delivered in an elastic, pay as you go environment.
Business Reality. We need to do things daily that we used to do monthly. The Cloud is the realistic future for us as the costs to satisfy the growing demand is cost prohibitive.
Cost. We can’t afford to build more data centers. We can realize better utilization and savings by virtualizing our workloads. We want to lower the cost of management/maintenance. We don’t know what success will look like and want to move away from overprovisioning and move to a pay as you go model.
View of IT. If you’re not in the IT business; you want to focus on your core competencies. For example, why have specialists in a commodity workload?

Key Questions that a Business Case Addresses

Here is a set of questions that an effective business case will address:

Why should we do this?
What’s the strategic reason for doing this?
What’s the competitive reason for doing this?
What’s the cost of doing this? What’s the cost of not doing this?
What’s the Economic Value Added (EVA) of doing this?
What’s the risk of doing this? What’s the risk of not doing this?
How big is the pie?
What’s our slice?

Sponsor

When working on a business case, it is important to be connected with the proper sponsor. The sponsor must be able to make the decision to proceed, and define what is needed in a business case.

The sponsor should define the level of detail, focus/scope, objectives, metrics and measures for the business case. Business case parameters will vary between commercial and public sector, industry, and the state of the markets.

The sponsor must also define the deliverables. Determine if you are expected to create a business case ready to be presented to a board of directors or something less rigorous. Determine what the review process is for the business case. Identify any specific template requirements.

The sponsor must also indicate where the data will come from. Will some of the data be sourced from a 3rd party, or will it come entirely from the customer’s organization? Determine if the business case or data will become part of a wider internal business case created by stakeholders.

Stakeholders

A business case can range from simple to highly detailed. The right level of detail to a large extent depends on where the stakeholders are in the buying cycle. During the early stages of the buying process, a rough estimate business case is often developed to get an idea of value justification.

As the buying process unfolds, a more robust business case is usually required.

Cloud decisions normally require a high-level decision maker to sponsor and drive them. Therefore the business case is usually oriented towards a CxO-level stakeholder.

The sponsor is typically a business decision maker, not an IT decision maker. You will however also need the support of IT decision makers at some point in the process, but your sponsor usually is a business person with a business need that can be met by the proposed Cloud solution.

The main thing to know upfront is what the business decision makers need in order to approve the investment. Do they need a thorough business case, a TCO model or something else?

If you’re building a business case that requires sign-off from multiple stakeholders make sure the business case addresses each of their needs and aligns with their values. Bear in mind that some values may not have monetary values associated – for example political gain.

Ensure you have involved all the relevant stakeholders. Also be aware of stakeholders that are not supportive and use the sponsor to help understand the organization culture.

Benefits Types

Determine the types of benefits that will result by achieving the objective and how they will be measured. Benefit types include:

Financial benefits: can you convert it to money?
Quantifiable benefits: have you got the figures available now?
Measurable benefits: can you measure it now?
Observable benefits: can you observe it now?

KPIs

A good source of measures is the organization’s key performance indicators (KPIs). Identify these by interviewing members of the organization’s senior management team and/or using a benefits assessment workshop.

A few samples from a range of industries are shown here:

Retail Banking

# of new products
# of promotions run
% interest margin
Customer satisfaction rating
% cost saving/avoidance ratio
Average number of customers served in a day
Opex % of revenue

Healthcare

Hospital incidents – reinfection and error rates
Post care death rate
Patient satisfaction
Admission process
Medication error
Patient wait time
Average length of stay
Bed and equipment utilization

Oil and Gas

Probable-reserve adjustments
Cycle time
Finding and development cost
Deployment Capital Expenditures (CAPEX)
Exploration CAPEX
Exploration Expenses
Volume of resources brought forward to drillable status
Finding costs
Net income
Cash flow from operations
Total capital expenditure
Total costs

Financial Metrics

Use a range of possible values when presenting the financial metrics, such as:

Migration and other one-time costs
Monthly and other on-going costs
Personnel costs including training
Time issues including potential business disruption

Approaches that are Good to Be Aware Of

The following practices, tools and approaches are good to be aware of:

Benefits Dependency Networks (BDNs)
Business Value vs. Ability to Execute Frame
Cranfield Six-Stage Framework
Economic Value Added (EVA)
IVI Portfolio Prioritization Frame
Val IT Framework (value-driven questions connecting IT with business)
Value Portfolio

Benefits Dependency Network (BDN)

A Benefits Dependency Network, or BDN for short, is a great way to visualize a business case.

A BDN helps visually depict and communicate the IT and business changes required to realize the benefits.

BDNs are a first class diagram and underlying modeling technique to help understand strategic intent and traceability of value.

However, if you need to include a more complete Value Management (cost/risk/benefit) approach to your business case, you may need to move beyond the BDN and adopt the full Cranfield Benefits Management Framework, or the Val IT Framework.

An outline BDN is shown here:

The BDN includes business drivers, investment objectives, and benefits together with their interrelationships and ties these to business change, enablers and enabling technologies.

Drivers. Capture business drivers by conducting interviews with the high power stakeholders. Check that you know the business drivers. Are the desired types of improvements to be brought about by the Cloud and their feasibility fully understood and agreed upon?
Objectives. Objectives are the organizational targets for achievement agreed upon for the project, in relation to the drivers and envisioned changes. Use the discussion on objectives to validate the scope of the project and the appropriate stakeholders. Capture objectives by conducting structured interviews with the sponsor and key stakeholders. Check that changes in the ways of working have been defined and that all the stakeholders have been identified and are on board.
Benefits. A benefit is an advantage on behalf of a stakeholder or group of stakeholders. The business drivers say “Why” the investment is being made. The objectives define the end point, or the state at which the investment is aimed. The objectives therefore define the benefits set. The benefits are “What” will appear in the business.

Business Value vs. Ability to Execute

There is no point considering options you can’t execute. This may immediately rule out some options or place them in a different perspective. For example, a company might not be in a position to execute on a Cloud initiative due to its current maturity stage.

It’s more helpful to see the things that can be accomplished.

Cranfield Six Stage Framework

The Cranfield six-stage approach to business case development is based on a systematic exploration of the benefits expected from the investment. While many business cases are based on the expected costs and benefits of the investment, the Cranfield approach differs from this in the following ways:

Non-financial benefits are also recognized.
Measures are identified for all benefits including subjective or qualitative benefits.
Evidence is sought for the size of the benefits.
An owner is identified for each benefit.
Benefits are explicitly linked to both the IT and the business changes that are required to deliver them.
Owners are identified for ensuring the business changes are achieved.

In summary, the six stages are:

Step 1: Define Business Drivers and Investment Objectives

A convincing and robust business case starts with a statement of the current issues facing the organization, the business drivers. The business case must also clearly state what the proposed investment seeks to achieve for the organization i.e. the investment objectives.

Step 2: Identify Benefits, Measures, and Owners

What are the expected benefits that will arise if the objectives of the investment are met? Objectives are the overall goals or aims of the investment, agreed upon by all relevant stakeholders, while benefits are advantages provided to specific groups or individuals as a result of meeting the overall objectives. Once the expected benefits are identified, to essential additional elements are how will the benefits be measured and which individual will own the benefit.

Step 3: Structure the Benefits

The following figure shows the framework suggested by Cranfield for structuring benefits:

This framework structures the benefits according to the type of business change that gives rise to the benefit and the degree of explicitness represented by the benefit.

Step 4: Identify Organizational Changes enabling Benefits

Benefits can always be classified under one of the three headings shown in the figure above. The organization or staff can do new things and in new ways that prior to the investment were not possible. The organization can do things better. The organization can stop doing things that are no longer necessary.

Step 5: Determine the Explicit Value of each Benefit

Having identified which column to place each benefit in, it is then necessary to assign each benefit to one of the four rows.

Financial benefits: Financial value can be calculated by applying a cost/price or other valid financial formula to a quantifiable benefit.
Quantifiable benefits: There is sufficient evidence to forecast how much improvement/benefit should result from the changes.
Measureable benefits: Although this aspect of performance is currently measured, or an appropriate measure could be implemented, it is not possible to estimate how much performance will improve when changes are implemented.
Observable benefits: By using agreed criteria, specific individuals or groups will use their experience or judgment to decide the extent the benefit will be realized.

Step 6: Identify Costs and Risks

In addition to the benefits, a complete business case must also include all costs and an assessment of the associated risks. This should include all recurring IT costs that will occur once the system is live.

VAL IT Framework

Val IT is a governance framework that includes generally accepted guiding principles and supporting processes related to the evaluation and selection of IT-enabled business investments.

It also addresses benefit realization and the delivery of value from these investments.

The investment can be evaluated using the following categories:

Strategic

In line with your vision
Consistent with your business principles
Contributing to your strategic objectives
Providing optimal value, at affordable cost, at an acceptable level of risk

Architecture

In line with your architecture
Consistent with your architectural principles
Contributing to the population of your architecture

Value

A clear and shared understanding of the expected benefits
Clear accountability for realizing the benefits
Relevant metrics
An effective benefits realization process over the full economic life cycle of the investment

Delivery

Effective and disciplined management, delivery and change management processes
Competent and available technical resources to deliver: The required capabilities; Organizational changes required to leverage the capabilities.

Note that the latest release of the framework, published by IT Governance Institute (ITGI), based on the experience of global practitioners and academics, practices and methodologies was named Enterprise Value: Governance of IT Investments, The Val IT Framework 2.0. It covers processes and key management practices for three specific domains and goes beyond new investments to include IT services, assets, other resources and principles and processes for IT portfolio management.

Value Portfolio

The following value portfolio categories are an important consideration when assessing potential benefits and opportunities. Where does your proposed Cloud investment sit and does the business case address the right audience and decision maker?

Strategic. These are investments aligned with strategic goals and essential to sustain future business goals. These decisions are made at senior management levels and are based on the alignment of IT investments to strategic and future delivery or business value and risk avoidance.
High Potential. This is innovative work that could have major impact; investments that might be important to achieving future success. These decisions are made at the business development level and evaluate future business and technology opportunities.
IT Optimization. These are focused on reducing costs or increasing agility. These decisions are made by functional managers aligned to local time and performance KPIs. Investment funds are available if a solid business case based on IT costs, business value, ROI and risk can be produced.
Support. These are focused on reducing support burdens. These investments are valuable to an organization but not essential to its business success. These decisions are often made on the basis of costs such as licensing and TCO by junior mangers with minimal budget overlap.

Map of Useful Models

When compiling data in the areas of Cost, Benefit, and Risks; the following models will likely be useful:

Valuation Frameworks
- Benefits Dependency Network (BDN)
- Cranfield Six-Stage Framework
- Val IT Framework
- Value Portfolio
Financial Metrics
- Economic Value Added
- ROA
- ROI
- Net Present Value (NPV)
Risks
- Business Value vs. Ability to Execute Frame

While this isn’t enough information to help you master business cases, at least it should help give you a better lay of the land, and avoid some common pitfalls and landmines.

The 7 Habits of Highly Effective IT Leaders
How User Stories Help Leaders Learn the Cloud
How To Connect Business and IT
How Business Value Generation is the New Bottleneck
How To Turn IT into an Asset Rather than a Liability