Showing posts with label Strategy Implementation. Show all posts
Showing posts with label Strategy Implementation. Show all posts

Monday, February 03, 2025

IT Outsourcing: A Strategic Decision, Not a Default Choice

IT Outsourcing: A Strategic Decision, Not a Default Choice
Outsourcing, nearshoring, offshoring—these buzzwords get thrown around as if they are the silver bullet to IT cost reduction and efficiency. 

But here’s the harsh truth: If your IT is a key asset or a differentiator, sending it far away from your headquarters is a strategic disaster.

Would you offshore your product strategy? No? Then why would you offshore the very technology that runs your core business? Banking, insurance, or any industry where technology is an essential competitive advantage needs IT close to home, embedded within the business, and deeply aligned with strategic objectives. If it’s far away—whether by geography or corporate structure—it will never be more than a cost center, and that’s a race to the bottom.

If, however, you’re talking about non-differentiating IT—commodity services, back-office systems, or standard support—then, by all means, find the most cost-effective way to get it done. But let’s be clear: outsourcing should be a conscious, strategic choice, not an automatic reflex to cut costs.

And yet, outsourcing is only one piece of the puzzle. The other is how you manage your workforce. 

If you keep IT in-house, filling critical roles with external consultants instead of internal employees creates the same risks.

Too many companies play the headcount game, setting KPIs to limit full-time employees while hiring an army of external consultants at a premium. The irony? This ‘savings’ approach ends up costing more while ensuring that the company never retains critical knowledge in-house.

If a capability is strategic, it needs to be built and maintained internally. Otherwise, your company becomes dependent on an endless rotation of consultants who, conveniently, never transfer their expertise before moving on to their next contract. It’s a cash burn wrapped in a short-term illusion of flexibility.

Yes, external expertise has its place—think temporary spikes in workload, specialized knowledge, or transformation initiatives. But outsourcing your core competencies to third parties is like renting your brain: eventually, you’ll forget how to think.

In a nutshell:

> If IT is your competitive advantage, keep it close. Offshoring core technology is a strategic failure.
> Only outsource what is non-differentiating. Everything else belongs in-house.
> Managing by headcount KPIs while overspending on externals is financial nonsense.
> Build internal knowledge for long-term success, don’t rent it short-term at a premium.

Read more…

Sunday, May 02, 2021

The Biggest Challenge of Postmodern ERP - Cloud Integrations

The Biggest Challenge of Postmodern ERP - Cloud Integrations

Gartner originally coined the term “enterprise resource planning” (ERP) back in 1990 to describe a new breed of integrated software solutions. These solutions included modules for Material Requirements Planning (MRP), Manufacturer Resource Planning (MRP II), Financials, Human Resources (HR) and Customer Relationship Management (CRM).

During the 1990s and 2000s, these single monolithic ERP solutions became an essential part of most corporate IT strategies. But by the mid-2000s, such ERP solutions started to get a bad reputation. The very high price tag, the relative inflexibility of an integrated solution and the droves of ERP implementation failures that made headlines in both the tech and business world clearly showed the shortcomings of this strategy. It became hip to proclaim that “ERP is dead” or “the end is near”. 

Companies started implementing best-of-breed applications to replace individual modules within larger ERP solutions. For example, using Salesforce instead of the CRM module bundled with their ERP solution, or Workday to replace the HR module. Others ditched their ERP solution altogether and started using only best-of-breed applications and started connecting them with each other. 

Gartner coined the term “postmodern ERP” in 2014 to describe this new ERP strategy.

Postmodern ERP is a technology strategy that automates and links administrative and operational business capabilities (such as finance, HR, purchasing, manufacturing and distribution) with appropriate levels of integration that balance the benefits of vendor-delivered integration against business flexibility and agility. 

To put it another way, a traditional ERP solution is like the new car you buy every 10 years. A postmodern ERP solution is like owning the same car indefinitely, but with various components that can “easily” be changed out as needed.

Around the same time that postmodern ERP strategy became hip, we see the cloud strategy of both vendors and clients taking off. This means many of these best-of-breed applications are consumed in a SaaS model with all its advantages and disadvantages.

Whilst this all sounds like great ideas it gives us one very big challenge to solve; cloud integrations.

Why Cloud Integrations Are so Difficult

Cloud integration means integrating data used by disparate systems, between or within public or private clouds, or between cloud-based and on-premise systems. The goal is to create unified data stores that can be accessed efficiently and transparently by all relevant users and applications.

There are mature tools for data integration within public cloud providers or private cloud platforms, for example within AWS, Azure or an OpenStack data center. The main challenge begins when organizations need to integrate multiple public clouds, set up hybrid cloud environments, integrate legacy on-premise systems with cloud workloads, or lift and shift legacy workloads into the cloud.

You can increase flexibility and agility, or reduce complexity, but you can’t do both. Despite the rigid nature of traditional ERP solutions, they solved some key issues, including the need for consistency and integrity of data and processes. 

Let’s have a look at some aspects you have to deal with when implementing a postmodern ERP solution. 

Release Management
Each SaaS application that is part of your postmodern ERP solution will have a different maintenance and upgrade cycle. This means that you will have continuous change in parts of your end-to-end solution without you being able to stop this. This means you have to have a solid plan in place for regression testing. Does the end-to-end solution still work after each upgrade? Do your integrations still work? Are the data semantics still the same?

Environment Management
Tied to the previous point is environment management. In order to do development and testing you will need to have a development and test environment. This works a little differently for each SaaS application that is part of your postmodern ERP solution. And just as the production environment, they will all have different maintenance and update cycles, meaning it will be very difficult to have a stable environment for long.

Backup and Disaster Recovery
It is safe to assume that each SaaS application that is part of your postmodern ERP solution will have a solid backup and disaster recovery strategy in place. But they all will be different. Do you understand the impact of such an event on your integrations? On your data integrity? Did you test this?   

Firewalls
In hybrid cloud environments, when moving data between the cloud and on-premise systems, opening the firewall is a necessity that most network administrators anxiously resist. You will have to carefully evaluate the requirements for data integration flows that cross the firewall to find the solution that minimizes the exposure of enterprise systems and data.

Network Latency
Cloud environments are often preferred to on-premises because of their scalability: you can easily increase or decrease your usage of compute and storage resources in just a few minutes. But scaling your cloud environment will have limited effect if your network latency is too high, which puts a firm cap on the data integration workloads you can run.

Data Transfers
Moving data between clouds, and between cloud and on-premise systems, can be time-consuming and error-prone, or even unfeasible in some cases, depending on the data volumes and the required data transfer frequency. Cloud data integration won’t work without solid strategies to transfer data in a timely manner. There is a huge difference between 10 messages a second and a 100 -- trust me.

Data Integrity
How are you monitoring all points of integration and logging the data on the move? Depending on the method used, the process of monitoring and capturing data changes on source systems can increase the load on the source system causing slowdowns in operational systems.

Data Conversion
In traditional data integration projects, complex Extract Transform Load (ETL) workflows were set up to clean data and transform it into the precise format needed by target systems. Many SaaS applications work with unstructured data or provide a flexible data model for structured data. However, they still need data to be cleaned, treated and converted into the desired format. Integration strategies must consider how ETL can be performed without slowing down the integration or adding a lot of complexity.

Data Synchronisation
SaaS applications are often architected with scalability or performance in mind, not around data integration. For example, in a system that rapidly scales up or down, with data stored on dozens or hundreds of cloud instances, it may be challenging to synchronise with external systems.

Standardization
There is no standard approach or protocol for integrating data between SaaS applications, not to mention cloud and on-premise systems. Each cloud platform, service or resource tends to have different data schemas and formats. Data connectors or adaptors need to be constantly updated, as new cloud services are introduced or as applications are updated or modified.

Security and Compliance
Consider the security requirements and industry standards applicable to each of your datasets. Both your integration platform and all connected applications need to fulfil those requirements, both for one-time data transfers and ongoing data synchronisation.

In a nutshell: You can increase flexibility and agility, or reduce complexity, but you can’t do both. 

Read more…

Saturday, March 13, 2021

Create a Lighthouse to Drive Your Transformation

Create a Lighthouse to Drive Your Transformation

I’m a firm believer in transformation through delivery. In my experience real change cannot be implemented without a vehicle that is used to drive it through the organisation and crash through existing barriers. 

Transformation is far more than just deploying new technologies for the sake of it. A genuine competitive advantage can only be gained through the combination of an organization’s culture, its strategic choices and way of operating. 

It’s about continuously enabling new and leaner operating models underpinned by flexible business processes, connected platforms, analytics and collaboration capabilities that enhance efficiency and effectiveness. 

It’s about searching, identifying and developing new technology supported business models and, above all, ensuring that customers and employees are at the center of whatever a company does.

A good way to start transformation through delivery is by defining a so-called lighthouse project early on in the process and letting your best people make it a success. A lighthouse project is a short-term, well defined, measurable project that serves as a model — or a “lighthouse” — for other similar projects within the broader transformation initiative.

Create a Lighthouse to Drive Your Transformation

This technical delivery project will show new ways of working and doing business combined with the use of technology and will help to identify organizational challenges that hinder you to do the same in the rest of your organization.

The 4 key attributes of such a lighthouse project are:

> It has high business value and visibility so it is less likely to be cancelled. A lighthouse project doesn’t need to directly benefit everyone in your organisation. But its value should be something that everyone in the organisation can appreciate and understand. It should have obvious results, such as “we have reduced the hardware purchasing budget by 70 percent” or “we have managed to increase our application uptime from 95 percent to 99.9 percent.”

> It has clear metrics. You’ll notice that the results mentioned above involve hard numbers. Collecting quantifiable data about your lighthouse project is important in order to make the demonstration of value as clear as possible.

> It touches multiple business units and silos to enable the identification of barriers and influence change.

> It has a hard deadline in the near future to focus the business and delivery team to provide pressure to break down barriers. You don’t want to wait years for your lighthouse project to be complete. Choose a project that can be implemented within a reasonable period of time—a year at most. Of course, you should be careful to balance time-to-completion with sophistication; don’t make the project too simple in order to make it faster to complete.

In a nutshell: A lighthouse project is the key to transformation because it shows everyone in your organisation what they can achieve by leveraging new ways of working, new ways of thinking, and using new technologies.

Read more…

Sunday, December 13, 2020

Project ≠ Program ≠ Portfolio ≠ Strategy

Project ≠ Program ≠ Portfolio ≠ Strategy

I have had many heated discussions around these terms. People mix these up and it confuses your organization and its people. 

This is my take on it. 

If your organization is running many projects at the same time it is impossible to make the right decisions if all projects are performed in isolation. Therefore projects are managed in logical groups to use resources efficiently and effectively. 

There are two kinds of such groups. Programs and portfolios.

The distribution of projects under a program or portfolio depends on the nature and the type of project. Programs are managed through program management and portfolios are managed through portfolio management.

Let’s start with the diagram below. It shows very clearly the relationship between the three P’s of Project Management.

Three P's of Project Management

Project

A project is the lowest level in the hierarchy of project, program, portfolio, and organization.

According to the PMBOK Guide, “A project is a temporary endeavour undertaken to create a unique product, service or result.”

So, you can say that the nature of a project is temporary; once the project achieves its objective, it no longer exists, and the objective of the project is to create a unique product, or develop a system to provide you with a service or the result.

Project management is the application of people, process, technology, knowledge, and skills to achieve successful completion of specific project goals and objectives.

Good project management means teams and team members are constantly developing and improving, giving the business a competitive advantage. Good projects are typically short and fat.

Program

A program is a group of related projects and program activities managed to contribute to the same business objective or benefit. The program as a whole has clearly defined goals, and each project within the program assists in meeting those goals. 

So please do not call a large project a program. It is not.

Program management allows your organization to have the ability to align multiple projects for optimized or integrated costs, schedule, effort, and benefits. 

Program managers look at cross-project dependencies, risks, issues, requirements, and solutions, and may coordinate with individual project managers to achieve these insights and keep the overall program healthy. They’re less concerned with the success of every single individual project, and more focused on the success of the overall initiative and achieving the larger benefit. 

Program managers are also concerned with making sure the right projects are chosen or prioritized in order to achieve the most business value. Successful programs work towards improvements that will have a long-term impact on your organization, and unlike projects that have a specific end date, programs may be ongoing initiatives.

Portfolio

Portfolio is a collection of projects, programs, and sub-portfolios managed as a group to achieve strategic objectives. All these items may not necessarily be interdependent or directly related. 

For example your organization has different investments, products or services, but has a global strategy to maximize the ROI. The four goals of portfolio management are:

1) Maximizing the value of your portfolio

2) Seeking the right balance of projects

3) Creating a strong link to your strategy

4) Doing the right number of projects

Portfolio management provides a big picture of your organization's projects and programs and supports leadership to analyse and make the right decisions.

Project management is about executing projects right, portfolio management is about executing the right projects. It is a way to bridge the gap between strategy and execution.

Strategy

As stated before, a portfolio is a collection of projects, programs, and sub-portfolios, managed as a group to achieve strategic objectives. So it comes naturally that for each strategy there exists a portfolio to achieve this strategy. This is reflected in the diagram below.

Strategy Execution through Project Portfolio Management

This also means that if you only have one strategy you should manage all your projects in one portfolio.

In a nutshell: A project is focused on creating a unique product, service, or result. A program is a collection of projects that need to be managed and coordinated together. And, a portfolio is a collection of projects and programs that are managed as a group to achieve strategic goals and a business value.

Read more…

Sunday, October 18, 2020

The True Cost of Excluding Executives from the IT Decision Making Process

The True Cost of Excluding Executives from the IT Decision Making Process

Throughout the past 15 years that I’ve been working as an independent project recovery consultant and interim CIO, I have observed executives’ frustration – even exasperation – with information technology and their IT departments generally. Some of the more common refrains are: 

“I don’t understand IT well enough to manage it.” 

“Although they work hard, my IT people don’t seem to understand the very real business problems we’re facing.”

In fact, the complaint I hear most often from CEOs, COOs, CFOs, and other high-ranking officers, is that they haven’t reaped the business value of their high-priced technology. Meanwhile, the list of seemingly necessary IT capabilities continues to grow, and IT spending consumes an increasing percentage of their budgets. 

So why is this happening, and what can you do to prevent it?

Though it may come as a surprise, one of the most effective measures you can take is to ensure a senior business executive plays a leadership role in a handful of key IT decisions. I say this because when business executives hand over their responsibility for these decisions to IT executives, disaster often ensues. You need look no further than my project failure case studies to see the sheer number of botched adoptions of large-scale customer relationship management (CRM) and enterprise resource planning (ERP) systems. 

It would be easy to assume that the CRM and ERP disasters resulted from technological glitches. However, the problems generally occurred because senior executives failed to realize that adopting the systems would create business challenges – not just technological ones. 

To be clear, IT executives are the go-to people for numerous managerial decisions, including choosing technology standards, advising on the design of the IT operations center, providing the technical expertise the organization needs, and developing the standard methodology for implementing new systems. But an IT department should not be left to their own devices to determine the impact these choices and processes will have on a company’s business strategy.

In an effort to help executives avoid IT disasters, and, more importantly, generate real value from their IT investments, I have made a list that outlines the measures they should take and the decisions they should oversee. Whereas the first three bear on strategy, the latter items relate to execution. At the risk of a spoiler: IT people should not be making any of these decisions, because, in the end, that’s not their job [or their area of expertise].

1) How much should we spend on IT?

Given the uncertain returns on IT spending, many executives wonder whether they will reap the benefits of their investment. So the thinking goes: If we can just get the dollar amount right, the other IT issues will take care of themselves. For this, they look to industry benchmarks to determine “appropriate” spending levels.

In my experience, they should be approaching the question very differently. First, executives should determine the strategic role that IT will play in their organization to establish an organization-wide funding level that will enable technology to fulfill their objectives. After all, IT goals vary considerably across organizations – from streamlining administrative processes to feeding a global supply chain, providing flawless customer service, or cutting-edge research and development. 

Clearly, fulfilling these objectives requires different levels of spending, planning, and administrative oversight. 

2) Which projects should be funded?

I’ve seen relatively small companies with 100 IT projects underway. Despite the fact that they are not equally important, executives are often reluctant to make choices between the projects that will likely have a significant impact on the company’s success, and those that will provide some benefits but aren’t essential.

Leaving such decisions in the hands of the IT department means that they will be the ones prioritizing business issues, or, just as troubling, they will attempt to deliver on every project a business manager regards as important. When presented with a list of approved and funded projects, most IT units will do their best to carry each of them out. But this typically leads to a backlog of delayed initiatives, not to mention overwhelmed and demoralized staff.

3) Which IT capabilities need to extend company-wide?

Business leaders are increasingly recognizing the significant cost savings and strategic benefits that come with centralizing IT capabilities and standardizing infrastructure throughout an organization. Leveraging technological expertise across a company enables cost-effective contracts with software suppliers, just as it facilitates global business processes. On the other hand, standards can restrict the flexibility of individual business units, limit the company’s responsiveness to diverse customer segments, and give rise to strong resistance from managers.

When IT executives are left to make decisions about what will and will not be centralized and standardized, they typically take one of two approaches. Depending on the company’s culture, they either insist on standardizing everything to reduce costs, or they grant exceptions to any business unit manager who raises a stink (recognizing the importance of business unit autonomy). Whereas the former approach restricts flexibility, the latter is expensive, limits business synergies, and drains human resources. 

It’s worth keeping in mind that, in some instances, using different standards can be counter-productive – resulting in a corporate IT infrastructure whose total value is less than the sum of its parts. Knowing this, executives must play a lead role in weighing these crucial trade-offs.

4) What IT services do we really need?

I’ll get right to the point: An IT system that doesn’t work is useless. Reliability, responsiveness, and data accessibility come at a cost, but that doesn’t mean every system must be wrapped in gold. Ultimately, executives must decide how much they are willing to spend on various features and services.

For some companies, top-of-the-line service is non-negotiable. As a case in point, investment banks cannot afford to engage in a debate over how much data they would be willing to lose if a trading system crashes. They require 100% recovery. Similarly, Cloud providers cannot compromise on response time or allow for any downtime, because their contracts penalize them when their system becomes unavailable. This not only incentivizes the provider to ensure that their services will continue to run despite floods, tornadoes, power outages, and telecommunications breakdowns, it gives the client peace of mind and justifies higher costs.

Granted, not every company is a Google or a Goldman Sachs. Most can tolerate limited downtime or occasionally slow response times, and they must weigh the problems this creates against the costs of preventing them. Once again, decisions concerning the appropriate levels of IT service need to be made by senior business managers. Left to their own devices, IT units are likely to opt for the highest levels – i.e., Ferrari service when that of a Ford will do – because the IT unit will be judged on such things as how often the system goes down.

5) What security and privacy risks are we willing to accept?

Like reliability and responsiveness, companies must weigh the level of security they want against the amount that they are willing to expend. In doing so, there’s another trade-off to consider: Increasing security involves not only higher costs but also inconveniences users. As global privacy protections are increasingly mandated by governments, security takes on a new level of importance because well-designed privacy protections can be compromised by inadequate system security. Executives must assess these trade-offs. 

Bear in mind that many IT units will adopt the philosophy that absolute security is their responsibility, and thus deny access anytime safety cannot be guaranteed. They would do well to float that idea by a bank’s marketing executives, who are counting on simplified online transactions to attract new customers.

6) Can we assign blame when an IT project fails?

Finger-pointing often ensues when teams fail to benefit from new systems. There must be something wrong with the IT function in our company, they presume. More often than not, there is something wrong with the way that non-IT executives are managing IT-enabled change in the organization.

I invite you to reflect on the well-publicized examples of ERP and CRM initiatives that failed to generate quantifiable value. Invariably, the failures resulted from assumptions that IT units or consultants could implement the systems while business managers went about their daily tasks. The bottom line is that new systems have no value; they derive their value from new or redesigned business processes. 

Quite simply: To avoid disasters, executives must take responsibility for realizing the business benefits of an IT initiative. These “sponsors” need the authority to assign resources to projects and the time to oversee the creation and implementation of their projects. 

This includes scheduling regular meetings with IT personnel, organizing training sessions, and working with the IT department to establish clear metrics for determining the initiative’s success. Such sponsors can ensure that new IT systems deliver real business value.

In a nutshell: one of the most effective measures you can put in place is giving senior business executives a leadership role in a handful of key IT decisions. 

Read more…

Sunday, October 11, 2020

What Executives Need to Know About Project Management

The Role of Executives in Projects
I work exclusively with executives and when there is one thing that I have learned over the years is that effective executives have at least a basic understanding about project management and their roles in it. 

When you look in a dictionary for the word "executive" you will find an entry similar to the one below. 

noun - a person with senior managerial responsibility in a business.

“a C-level executive”

adjective - relating to or having the power to put plans or actions into effect.

"an executive chairman"

An executive directs, plans, and coordinates operational activities for their organization and are normally responsible for devising policies and strategies to meet the organization's goals.

Executives hold executive powers delegated to them with and by authority of a board of directors and/or the shareholders. 

Generally, higher levels of responsibility exist, such as a board of directors and those who own the company (shareholders), but they focus on managing the senior or executive management instead of on the day-to-day activities of the business. 

The executive management typically consists of the heads of a firm's product and/or geographic units and of functional executives such as the Chief Financial Officer (CFO), the Chief Operating Officer (COO), Chief Information Officer (CIO), and of course the Chief Executive Officer (CEO). 

Almost all organizations use projects to implement their strategy and drive change. So projects are an important tool for executives to do their job. 

And in the organization's most important projects and programs it are executives that have the following roles and/or responsibilities.


Project support is priceless. Engaged executives help organizations to bridge the communications gap between influencers and implementers, thereby increasing collaboration and support, boosting project success rates, and reducing collective risk.

In a nutshell: In order to be an effective executive you should have a basic understanding about how project and project portfolio management works. You should also understand how to be a great Project Sponsor, Project Champion and/or Steering Committee Member.

Read more…

Monday, July 06, 2020

However Beautiful the Strategy, You Should Occasionally Look at the Results

However Beautiful the Strategy, You Should Occasionally Look at the Results
The title of this article is frequently credited to Winston Churchill (1874-1965), but he never said it. The saying first appears from about 1981, many years after Churchill’s lifetime.

The saying is used to stress that one needs to look at results and shouldn’t fall in love with one’s designed strategy if it doesn’t work.

The 2007 Financial Times obituary for UK Conservative politician Ian Gilmour (1926-2007) stated that he had used the line in a cabinet meeting in 1981.

In the end it doesn't matter who came up with the line, he or she was absolutely right! 

But how do we actually measure the results of our strategy? 

One very good answer to this question is the Balanced Scorecard. This article will show you what this is and how you can use it to drive strategy execution.

What is a Balanced Scorecard?

The Balanced Scorecard (BSC) is a business framework used for tracking and managing an organization’s strategy.

The BSC framework is based on the balance between leading and lagging indicators, which can respectively be thought of as the drivers and outcomes of your organization’s goals. When used in the BSC framework, these key results tell you whether or not you’re accomplishing your goals and whether you’re on the right track to accomplish future goals.

With a Balanced Scorecard, you have the capability to:

> Describe your strategy
> Measure your strategy
> Track the initiatives you're taking to improve upon your results

It was originally published by Dr Robert Kaplan and Dr David Norton as a paper in 1992. And then formally as a book in 1996. Both the paper and the book led to its widespread success. It is interesting to note that although Kaplan and Norton published the first paper, they were anomalously referenced in a work by Art Schneiderman who is believed to be the BSC creator.

BSC is more than just financial measures. The major difference that Kaplan and Norton introduced into this methodology is the ‘balance’ across all organisational functions. The problem back then, and still today, is that most companies focus on financial measures only. For example, revenue growth and profitability. 

By looking at an organisation across four ‘Perspectives’ a causal relationship between investment and financial outcome can be defined, measured and managed.

The BSC is not just a scorecard, it is a methodology. It starts by identifying a small number of financial and non-financial objectives related to strategic priorities. It then looks at measures, setting targets for the measures and finally strategic projects (often called initiatives). It is in this latter stage where the approach differs from other strategic methodologies. 

It forces your organisation to think about how objectives can be measured and only then identifies projects to drive the objectives. This avoids creating costly projects that have no impact on the strategy.

Objectives
Objectives are high-level organizational goals. When you create an objective, you should focus on what your organization is trying to accomplish strategically. A very general example would be: “Become an internationally-recognized brand.” The typical BSC has 10-15 strategic objectives.

Key Results
Key results help you understand if you’re accomplishing your objectives strategically. They force you to question things like, “How do I know that I’m becoming an internationally-recognized brand?”. Over time your key results might change, but your objectives will remain the same. You might have 1-2 key results per objective, so you are aiming to come up with 15-25 measures at the enterprise level of your strategy.

Initiatives
Initiatives are key action programs developed to achieve your objectives. You’ll see initiatives referred to as “projects,” “actions,” or “activities outside of the Balanced Scorecard.” Most organizations will have 0-2 initiatives underway for every objective (with a total of 5-15 strategic initiatives).

Balance
The ‘balance’ is brought about by a focus on financial and non-financial objectives that are attributed to four areas of an organisation. These are the Perspectives. They are: Financial, Customer, Internal Processes and Organisational Capacity

The four perspectives of a Balanced Scorecard

Questions often arise about the four perspectives described in the methodology. Why should we only look at Financial, Customer, Internal Processes and Organisational Capacity? Why not include Health and Safety? 

The answer is, of course, there is nothing stopping us. The four perspectives are simply a framework. However, over decades of use it has become clear that they work.

More importantly, there is a causal relationship between the perspectives. Working from the bottom to the top: Changes in Organisational Capacity will drive changes in Business Processes that will impact Customers and improve Financial results. The causal relationship may not be guaranteed if a new perspective is added. The result might be a useful scorecard, but it would not, by definition, be a balanced scorecard.

In brief, the four scorecard perspectives are:

Financial
The high-level financial objectives and financial measures of the organisation that help answer the question – How do we look to our shareholders? Financial objectives are usually the easiest to define and measure. However, creating a financial objective, for example, Improve Profit, rarely provides a clue as to how to achieve the objective. by linking objectives from the lower levels in the model, we begin to see exactly where to define projects and make investments.

Customer
Objectives and measures that are directly related to the organisation’s customers, focusing on customer satisfaction. To answer the question: How do our customers see us? It is always important to take a step outside and view your company or organisation from your customers view point. You need to understand what they want from you, not necessarily, what you can do for them.

Internal Processes
Objectives and measures that determine how well the business is running and whether the products or services conform to what is required by the customers, in other words, what should we be best at? Some of the biggest cost items can be reduced by streamlining internal processes. This is also the best area to focus on new and creative ideas.

Organisational Capacity
Objectives and measures concerning how well our people perform, their skills, training, company culture, leadership and knowledge base. This area also includes infrastructure and technology. Organisational Capacity tends to be the area where most investment takes place. It answers the question: How can we improve and create value?

The real value of the perspective approach is that it provides a framework to describe a business strategy. It focuses on objectives and key results that both inform us about progress and allow us to influence activities to achieve the strategy.

Over time, the concept of a strategy map was created. A BSC Strategy Map is a one-page visual depiction of an organization’s scorecard. It has the ability to show the connections between all four perspectives in a one-page picture.
The four perspectives are in a specific order and contain strategic objectives that contribute to a Vision and Mission. The objectives are linked in a causal way from the bottom to the top. The Strategy Map provides a very powerful tool allowing the user to talk about the causal impact of investment at the bottom to improved financial results at the top.

The benefits of a Balanced Scorecard 

A Balanced Scorecard is most often used in three ways:

> To bring an organization’s strategy to life. Those in the company can then use this strategy to make decisions company-wide.

> To communicate the strategy across the organization. This is where the strategy map is critical. Organizations print it and include it in interoffice communications, put it on their intranet, communicate it with business partners, publish it on their website, and more.

> To track strategic performance. That’s typically done through monthly, quarterly, and annual reports.

Closing thoughts

There must be a direct relationship between what an organisation is trying to achieve (the strategic objectives) and what is being measured to determine progress towards the objective. 

Clearly, there will be a lot of operational measures and some of these may contribute data to the key results, but operational measures (KPIs) should be considered as ‘housekeeping’ and ‘good practice’ and should not be confused with key results.

The approach gives us the framework to take a ‘balanced’ view across an organisation and define strategic objectives in the four perspective areas together with the associated KPIs.  We must be careful not to define too many strategic objectives.

Read more…

Sunday, June 07, 2020

Most Good Strategies Are Not Planned

Most Good Strategies Are Not Planned
Many people are discussing strategy and strategizing as if they were the sole outcome of a rational, predictable, analytical process.

But reality is often the opposite; emotional, unpredictable, and chaotic.  

How organizations create and implement strategy is an area of intense debate within the strategy field.

Famous researcher on management and strategy Henry Mintzberg has a very clear position in this debate. He distinguishes between intended, deliberate, realized, and emergent strategies.

These four different kinds of strategy are summarized in the figure below. 
Emergent Strategy
Intended strategy is strategy as conceived by the top management team. Even here, rationality is limited and the intended strategy is the result of a process of negotiation, bargaining, and compromise, involving many individuals and groups within the organization. 

Realized strategy—the actual strategy that is implemented—is only partly related to that which was intended. Mintzberg suggests only 10%–30% of intended strategy is realized. This part is named deliberate strategy.

The primary driver of realized strategy is what Mintzberg terms emergent strategy—the decisions that emerge from the complex processes in which individual managers interpret the intended strategy and adapt to changing external circumstances. 

Emergent strategy is a set of actions, or behavior, consistent over time, “a realized pattern [that] was not expressly intended” in the original planning of strategy. The term “emergent strategy” implies that an organization is learning what works in practice.

Thus, the realized strategy is a consequence of deliberate and emerging factors. 

The battle between those who view strategy making and implementation as primarily a rational, analytical process of deliberate planning (the design school) and those that envisage strategy as emerging from a complex process of organizational decision making (the emergence or learning school) is still very much ongoing.

But instead of joining this battle on one of the sides, the question you should ask yourself is:

 “How can the two views complement one another to give us a better understanding of strategy making and implementation?” 

Because in reality, both design and emergence occur at all levels of the organization. 

The strategic planning systems of large companies involve top management passing directives and guidelines down the organization and the businesses passing their draft plans up to corporate. 

Similarly, emergence occurs throughout the organization—opportunism by CEOs is probably the single most important reason why realized strategies deviate from intended strategies. 

What I think we can say for sure is that the role of emergence relative to design increases as the world and business environments becomes increasingly volatile and unpredictable.

The world events of the last few months make this pretty obvious.

In a nutshell: Many strategies emerge instead of being planned.

Read more…

Tuesday, May 26, 2020

Is Your Strategy Bad? A Simple Checklist

Is Your Strategy Bad? A Simple Checklist
Recognizing good strategy is hard. 

You need to understand the organization, the market(s) it is operating in, its competitors, its strengths, and its challenges. 

On the other hand, recognizing bad strategy is easy. 

Richard Rumlet coined the term “bad strategy” in 2007 at a short Washington, D.C., seminar on national security strategy. He later explained the concept in detail in his must read book “Good Strategy Bad Strategy”. He is one of the world’s most influential thinkers on strategy and management and has always challenged dominant thinking.

Bad strategy is not the same thing as no strategy or strategy that fails rather than succeeds. It is an identifiable way of thinking and writing about strategy that is, unfortunately, still practised at many organizations. 

Bad strategy is long on goals and short on policy or action. It assumes that goals are all you need. It puts forward strategic objectives that are incoherent and, sometimes, totally impracticable. It uses buzzwords and phrases to hide these failings.

Once you develop the ability to detect bad strategy, you will dramatically improve your effectiveness at judging, influencing, and creating strategy. 

To detect a bad strategy, look for one or more of its four major signs:

1) Bullshit bingo

Rumlet calls it fluff, which is a nicer way of saying the same. Fluff is a restatement of the obvious, combined with a generous sprinkling of buzzwords that masquerade as expertise to create the illusion of high-level thinking. 

Guy Kawasaki has written extensively about this in his excellent book on startups “The Art of the Start” and brings the illustrative example of Wendy’s.

“The mission of Wendy’s is to deliver superior quality products and services for our customers and communities through leadership, innovation, and partnerships.”

Don’t get me wrong. I love Wendy’s, but I’ve never thought I was participating in “leadership, innovation, and partnerships” when I ordered a hamburger there.

2) Failure to face the challenge

A strategy is a way through a difficulty, an approach to overcoming an obstacle, a response to a challenge. If the challenge is not defined, it is difficult or impossible to assess the quality of the strategy. And, if you cannot assess that, you cannot reject a bad strategy or improve a good one.

For example when a leader characterizes the challenge as underperformance, it sets the stage for bad strategy. Underperformance is a result. The true challenges are the reasons for the underperformance.

If you fail to identify and analyze the obstacles, you don’t have a strategy. Instead, you have either a stretch goal, a budget, or a list of things you wish would happen.

3) Mistaking goals for strategy

Many so-called strategies are in fact goals. “We want to be the number one or number two in all the markets in which we operate” is one of those. 

It does not tell you what you are going to do; all it does is tell you what you hope the outcome will be. But you’ll still need a strategy to achieve it.

Many bad strategies are just statements of desire rather than plans for overcoming obstacles.

4) Bad strategic objectives

A strategic objective is set by a leader as a means to an end. Strategic objectives are “bad” when they fail to address critical issues or when they are impracticable.

A long list of “things to do,” often mislabeled as “strategies” or “objectives,” is not a strategy. It is just a list of things to do. Such lists usually grow out of planning meetings in which a wide variety of stakeholders make suggestions as to things they would like to see done.

Rather than focus on a few important items, the group sweeps the whole day’s collection into the “strategic plan.” Then, in recognition that it is just a big pile of random objectives, the label “long-term” is added so that none of them need be done today.

Others may represent a couple of the firm’s priorities and choices, but they do not form a coherent strategy when considered in conjunction. For example, consider “We want to increase operational efficiency; we will target Europe, the Middle East, and Africa; and we will divest business X.” These may be excellent decisions and priorities, but together they do not form a strategy.

Good strategy, in contrast, works by focusing energy and resources on one, or a very few, pivotal objectives whose accomplishment will lead to a cascade of favorable outcomes. It also builds a bridge between the critical challenge at the heart of the strategy and action—between desire and immediate objectives that lie within grasp. 

Thus, the objectives that a good strategy sets stand a good chance of being accomplished, given existing resources and competencies.

Why do we see so much bad strategy?

Bad strategy is everywhere around us. Rummelt offers three reasons for this.

Unwillingness or inability to choose

Any strategy that has universal buy-in signals the absence of choice. Because strategy focuses resources, energy, and attention on some objectives rather than others, a change in strategy will make some people worse off and there will be powerful forces opposed to almost any change in strategy. 

For example a department head who faces losing people, funding, support, etc., as a result of a change in strategy will most likely be opposed to the change. 

Therefore, strategy that has universal buy-in often indicates a leader who was unwilling to make a difficult choice as to the guiding policy and actions to take to overcome the obstacles.

Template-style “Strategic Planning” 

Many strategies are developed by following a template of what a “strategy” should look like. Since strategy is somewhat nebulous, leaders are quick to adopt a template they can fill in since they have no other frame of reference for what goes into a strategy.

These templates usually take this form:

> The Vision: Fill in your vision of what the school/business/nation will be like in the future. Currently popular visions are to be the best or the leading or the best known.

> The Mission: Fill in a high-sounding, politically correct statement of the purpose of the school/business/nation. Innovation, human progress, and sustainable solutions are popular elements of a mission statement.

> The Values: Fill in a statement that describes the company’s values. Make sure they are noncontroversial. Keywords include “integrity,” “respect,” and “excellence.”

> The Strategies: Fill in some aspirations/goals but call them strategies. For example, “to invest in a portfolio of performance businesses that create value for our shareholders and growth for our customers.”

This template-style planning has been enthusiastically adopted by corporations, school boards, university presidents, and government agencies. Scan through such documents and you will find pious statements of the obvious presented as if they were decisive insights. The enormous problem all this creates is that someone who actually wishes to conceive and implement an effective strategy is surrounded by empty rhetoric and bad examples.

New Thought

The New Thought movement is a movement that developed in the United States in the 19th century, considered by many to have been derived from the unpublished writings of Phineas Quimby. 

It is the belief that you only need to envision success to achieve it, and that thinking about failure will lead to failure. The problem with this belief is that strategy requires you to analyze the situation to understand the problem to be solved, as well as anticipating the actions/reactions of customers and competitors, which requires considering both positive and negative outcomes. 

Ignoring negative outcomes does not set you up for success or prepare you for the unthinkable to happen. It crowds out critical thinking.

In a nutshell: Bad strategy is not simply the absence of good strategy. 

Read more…

Saturday, May 16, 2020

The Difficult Act Of Balancing Your Project Portfolio

Opportunity cost should be one of the biggest factors in your project portfolio valuation
Balancing your project portfolio is like juggling one hundred balls... in a storm... on a boat. 

Project portfolio management is not necessarily complex. The goals are clear and simple. 


2) Seeking the right balance of projects 



Achieving these goals, on the other hand, is not such an easy task. 

Especially balancing your portfolio is more an art than a science. Key considerations for your portfolio should include managing risk. Risk should be balanced across the portfolio, and risk should be diversified so that all projects are exposed to different risks. 

Breadth of strategic objectives and benefit types is also important; if every project is a cost-cutting project, then that has an impact on business performance and revenue growth will be reduced. 

It is only by treating projects as a portfolio that these trade-offs can be managed effectively. This article shows you a number of dimensions and visualizations you should consider when balancing your portfolio.

Maximizing Value

Let's start with the first goal: maximizing the value of your portfolio. Assuming you have your list of projects for the portfolio sorted by their value, as well as guidance on your available funding, project selection based only on the first goal is easy. 

If the available funding will cover all of the proposed projects, you will be in the enviable position of moving forward without further portfolio adjustment. However, this is rarely the case. 

The cost vs. value chart as shown below helps in allocating the budget efficiently by ranking projects by their ROI, or return-to-cost ratio. In the example, the budget is sufficient to fund projects E, O, D and C, and no other combination would yield greater total value. 

The vertical lines indicate that management can choose to cut the budget to just fund those four projects without losing potential value, or choose to increase the budget to capture the value from funding Project G.

When you would not balance your portfolio your job would be done right now. But it is not.
Portfolio View - Cost vs Value

Risk to Realize Value

The risk vs. value portfolio bubble chart as shown below represents a portfolio view of all (or selection of) projects and puts projects into one of four quadrants based on value and risk; this is important for identifying projects that drive overall greater value to the organization compared to other projects as well as highlight projects that should likely be screened out.

There are four primary data elements needed to build the risk-value bubble chart: value scores for each project, risk scores for each project, categorical data, and the project cost or financial benefits of the project (commonly used for bubble size). 
risk-value portfolio bubble chart

Difficulty to Realize Value

Another view on your portfolio should be on the difficulty to realize value. Difficulty is as different as costs. It is an estimation based on scarcity of skills and knowhow. It ties directly into goal number 4: Doing the right number of projects.
Portfolio View - Difficulty to realize
Scarcity of technical resources, such as engineering and marketing hours, affects each project’s chances of technical success, its potential value, or both.

At the top of this view by difficulty are easy projects that require less effort: Bread and Butters offer small returns and Pearls offer large returns. At the bottom are difficult projects requiring a great deal of effort that may not pay off: White Elephants offer small returns for the extra risk and Oysters offer potentially high returns.

Pursuing White Elephant projects creates opportunity cost in the form of resources that could be used to drive growth through creating and cultivating Oysters. Examine each White Elephant project to determine if it can pivot to be a high-potential Oyster; if it can’t, cancel it and redirect those resources to other projects to increase the overall upside potential of the portfolio.

Time to Realize Value

The third view you should have on your portfolio is time to deliver vs. estimated value. Cash velocity — the rate at which cash invested in business operations generates revenues and billings that replenish that cash — is relevant for your project portfolio.
Portfolio View - Time vs Value
Some projects require a few months to turn R&D investment back into cash-generating products or services; others may take years. A small-return project that completes quickly frees up development resources for the next project: the quick turnaround boosts cumulative returns.

Conversely, a small-return project that ties up resources for years creates the opportunity cost of preventing you from conducting several small projects in the same span of time.

Slow projects are Snails (small returns) or Tortoises (large returns); fast projects are Rabbits (small returns) or Racehorses (large returns).

Resource Spread

Many organizations have realized that a good approach for research spread is aiming for a project portfolio of short and fat projects. Short and fat projects imply that the company runs a small number of short projects in parallel, armed with sufficient resources.

The alternative is running many long and thin projects concurrently, which means that the organization’s resources are spread insufficiently between many parallel projects that are having a hard time crossing the finishing line. Portfolios consisting of long and thin projects are what we find in most organizations.

The underlying concept is visualized in the diagram below. At a minimum you should make sure your portfolio does not look like at the left.
Why your projects should be short and fat (and how to get them that way)

Strategic Objectives

In a previous article I explained in detail how to make sure your individual projects are aligned with your strategy. But on a portfolio level you have to take a broader view. Since your strategy is highly likely consisting of multiple objectives you should make sure as much of as possible them are supported by your projects, else certain parts of your strategy will just not be realized.

A simple way to do so is the so called Strategic Bucket Model. It answers the questions: “If this is our strategy, then how should we be spending our funds?” It starts with the individual strategic goals and then moves to set aside funds or buckets of money destined for each of the strategic goals. The goal of the portfolio is to fill as many buckets as possible in order to create a strategically balanced portfolio.

Investment Types

You organization has to strike a balance between Run, Grow, and Transform the business. This RGB model developed in the early 2000s by Louis Boyle at Meta Group, and in increasing use by companies like Gartner and McKinsey, can help you with both seeing and showing what you value.

It offers a business-oriented way to categorize technology investments at a high level in three different "buckets". 
Run, Grow, & Transform Technology Investments
Run the business” investments are about enabling essential, non-differentiated services having the desired balance between cost and quality. Benefits are measured in reduced cost, price-to-performance ratios, and risk. 

"Grow the business" investments are about improvements in operations and performance related to the company’s existing markets and customer segments. 

"Transform the business" investments are about new markets, new products, new customers—in other words, new horizons for the company, and maybe for the entire industry.

In a nutshell: Balancing your project portfolio is difficult but essential for any success.

Read more…

Monday, May 11, 2020

People, Process, Technology (In Exactly That Order!)

People, Process, Technology (In Exactly That Order!)
As an IT or information security professional, you cannot read a blog, book or paper without crossing paths with these three words; people, process, technology. 

Popularized in the infosec world at the end of last century by Bruce Schneier, these three nouns have been at the heart of the ITIL set of practices since their birth in the 1980s, and has its origins linked to Harold Leavitt's Diamond Model theorized in 1965 (with the organization's tasks representing the fourth component). 

It has also been referred to as the “golden triangle”, the 3 keys to successful project implementations and organisational change, and a back-to-basics approach to solving complex business problems.

The reason for this triangular focus comes down to one very important fact: 

To get sh!t done effectively in any organization requires an approach that optimises the relationships between people, process & technology.

By focusing on only one or two areas an imbalance is created. The result will be that you waste lots of money and time, and your best people will look for a job elsewhere. 

Take a new technology for example, many organizations believe that by implementing a new shiny tool, all of their problems will go away. 

But what they’re not seeing is that technology is only as good as the processes that are implemented around it, and processes are only as good as the people who execute them. 


People, Process, Technology (In Exactly That Order!)
But how do you get the balance right?

Always start with your people

> Identify your key players & understand what each of them want, and what they bring to the table.

> Confirm that you have senior management buy-in (right from the start), because without it you will fail.

> Ensure that your team consists of the right people with the right skills, experience and attitude to help you solve your problem. Practical experience is priceless, too many organizations have only theorists and consultants.

Once your people are committed, consider the process

> A process is defined as a series of actions or steps taken in order to achieve a particular end. So with that in mind, ask the question: What processes do we need in order to solve this business problem?

> A good place to start is by identifying the big, key steps. Once those are in place you can then focus on a more detailed level by looking at process variations, exceptions, interdependencies and supporting processes.

> Now review these processes with your stakeholders. Ensure that they’re aware of what’s expected from them and let them guide you with regards to possible gaps and issues.

And as last you select the technology

> With your people and processes in place, you can now look at technologies which will support them.

> It’s never a good idea to force a technology and then attempt to retrofit the people and processes around it. At the same time you should understand and accept that SaaS means “Software as a Service” and is not the same as custom software development.

> Technology should always be the final consideration once the problem is clearly understood and the solution requirements have been clearly defined.

This is all nothing new, but it seems to be forgotten time and again.

In a nutshell: To get sh!t done effectively in any organization requires optimising the relationships between people, process & technology. In exactly that order!

Read more…

Sunday, May 03, 2020

Show Me Your Budget and I’ll Tell You What You Value

Show Me Your Budget, and I’ll Tell You What You Value
Being in the middle of the yearly budgeting process I could not help but think about this quote from former US Vice President Joe Biden;

“Don’t tell me what you value, show me your budget, and I’ll tell you what you value.”

The RGB model developed in the early 2000s by Louis Boyle at Meta Group, and in increasing use by companies like Gartner and McKinsey, can help you with both seeing and showing what you value.

It offers a business-oriented way to categorize technology investments at a high level.

The model classifies investments as having one of three purposes: to Run, Grow, or Transform the business. Hence RGB model. Each classification implies different kinds of benefits.

“Run the business” investments

“Run the business” investments are about enabling essential, non-differentiated services having the desired balance between cost and quality. Benefits are measured in reduced cost, price-to-performance ratios, and risk.

Examples of “run the business” functions for most businesses include audit, payroll, and regulatory compliance. On the technology side, examples include most infrastructure investments, most IT security spending, and most IT operations spending.

“Run the business” investments do not produce revenue. They are essential to staying in business, but they don’t differentiate the business in most cases.

Exceptions include those cases wherein customers begin to perceive a "run the business" function as a differentiator, as appears to be happening now with “green” (environmental) initiatives and has happened recently with IT security in the financial and cloud services industries.

Many CIOs struggle to justify infrastructure investments, but in "run the business" terms the case is usually straightforward.

First, the function is essential and typically does not need justification per se (e.g., the organization is going to be compliant with Sarbanes-Oxley in one way or another), although the level of performance required may vary (how compliant must we be?).

Second, the proposed investment will deliver the best possible price for the required level of performance (e.g., it costs much less to upgrade systems over five years than to hire an army of expensive auditors annually). Price-to-performance benefits such as these are often easily and accurately calculated.

“Grow the business” investments

"Grow the business" investments are about improvements in operations and performance related to the company’s existing markets and customer segments.

The value of such investments may be measured in terms of operational performance improvements, such as cycle time or improved quality, or in financial terms, such as capital expense reduction, increased revenues and margins, increased customer lifetime value, or reduced general and administrative expenses.

Examples include opening a new online or social networking channel for sales and service of existing product lines, or eliminating 10 percent from costs of conducting a key business transaction.

When you’re talking about improved profits or service to customers, in most cases you’re talking about growing the business.

“Transform the business” investments

"Transform the business" investments are about new markets, new products, new customers—in other words, new horizons for the company, and maybe for the entire industry.

Such investments are measured in prospective market share and revenues in entirely new markets. These investments typically involve big rewards and high risk.

They can change the future of the company and even an industry when they succeed, or produce a large hole in the ground when they fail.

Apple changed its own course and that of the music industry with iTunes; Motorola lost billions of dollars and an untold amount of alternative opportunities when the Iridium project failed.

The word transform is often used in businesses to describe a lot of initiatives that would be classified as "grow the business" projects.

In this classification scheme, by definition transformative initiatives involve new markets, new customer segments, and new value propositions, and not merely improved margins or profits.

For example, a supply chain “transformation” that produces 40 percent increased throughput at a 30 percent reduction in costs with 20 percent improvement in quality is a "grow the business" initiative and not a transformation.
Run, Grow, & Transform Technology Investments

Focus on economic benefits of investments

Many projects and initiatives have objectives like “delighting the customer,” “improving time to market,” “happy employees,” or “operational efficiency.”

But hardly any organization will be blessed with unlimited resources to invest, and there’s just no getting around the fundamental challenge that all organizations face: sustaining themselves.

At some point the projects and initiatives you invest your limited resources in should help the organization to sustain itself and possibly even grow. So the question becomes “How do these benefits impact the economics of your organization?”.

The risk of placing too much focus on the economic benefits is relatively small and one can argue that lately it's largely been ignored by many organizations (just have a look at the number of Silicon Valley unicorns that are currently imploding). It is of no help having happy customers and no revenue.

The biggest risk of focusing on the economic benefits of projects is when organizations find opportunities to reduce costs that may ultimately have a negative impact on the customer experience. This is particularly problematic for service organizations, where a more efficient operation often translates to less happy customers.

To make estimating the benefits of a project easier and more realistic, I use a simple model to assess the economic benefits of a project.

It consists of five benefit types (or buckets).

1) Increased Revenue
2) Protected Revenue
3) Reduced Costs
4) Avoided Costs
5) Positive Impacts

Run, grow, and transform are not benefits; they simply point to the types of performance improvement that should be expected from an initiative and thus show you where to look for the benefits.

If you say, “This is a "grow the business" initiative,” it is still necessary to say exactly how the initiative will grow the business.

> Will it increase margins for a key line of business? If so, how—by reducing costs, or by increasing revenues faster than costs?

> Will it increase market share? If so, in which customer segments, in which markets, by how much?

> Will it affect soft measures of value, such as customer satisfaction, that ultimately may translate to customer retention and so to revenue? If so, how will the value be measured?

Or as Gartner states it: "Market leaders track IT spending against strategic planning pillars".

Technology budget conversations

Taking the above into consideration your IT budget conversations should have three dimensions:

1) Investments in IT needed to maintain products or services (Run). The benefits we can expect are reduced costs, avoided costs, protected revenue, as well as some other positive impacts;

2) Investments in IT capacity needed to support organic business growth (Grow). The benefits we can expect are increased revenue and reduced costs, as well as some other positive impacts;

3) Investments in IT needed to support new products or services (Transform). The benefits we can expect are increased revenue and reduced costs, as well as some other positive impacts;

Don’t forget that part of 2) are tools to make your IT organization itself more productive. In a company whose IT-related costs are 25 percent of the overall budget, improvements in IT productivity have a direct impact on IT costs per business transaction.

A classic problem this model brings often to the surface is the disproportionate focus on Run as many CIOs spend more time in running the legacy systems and tend to allocate upto 60% (if not more) of the annual budget to this category due to small business demands and other legacy reasons.

Grow and Transform are not given enough importance thus constraining the ability of the organisation to be ‘future-ready’ and competitive.

In a nutshell: Run, grow, and transform point to the types of performance improvement that should be expected from an initiative and thus show you where to look for the benefits.

Read more…