Monday, February 03, 2025
- Labels: Strategy Implementation, Technology
IT Outsourcing: A Strategic Decision, Not a Default Choice
Sunday, May 02, 2021
- Labels: Strategy Implementation, Technology
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.
Saturday, March 13, 2021
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.
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.
Sunday, December 13, 2020
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.
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.
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.
Sunday, October 18, 2020
- Labels: Leadership, Strategy Implementation, Technology
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.
Sunday, October 11, 2020
What Executives Need to Know About Project Management
Monday, July 06, 2020
However Beautiful the Strategy, You Should Occasionally Look at the Results
What is a Balanced Scorecard?
The four perspectives of a Balanced Scorecard
The benefits of a Balanced Scorecard
Closing thoughts
Sunday, June 07, 2020
Most Good Strategies Are Not Planned
“How can the two views complement one another to give us a better understanding of strategy making and implementation?”
Tuesday, May 26, 2020
Is Your Strategy Bad? A Simple Checklist
Why do we see so much bad strategy?
Saturday, May 16, 2020
The Difficult Act Of Balancing Your Project Portfolio
Maximizing Value
Risk to Realize Value
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).
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.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.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
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.
Strategic Objectives
Investment Types
Monday, May 11, 2020
People, Process, Technology (In Exactly That Order!)
Sunday, May 03, 2020
- Labels: Project Economics, Strategy Implementation
Show Me Your Budget and I’ll Tell You What You Value
“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.
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.