Monthly Archives: June 2013

Four Reasons for a Business Case – And Why Three of Them Are Wrong!


business_case2Most Business-IT initiatives require some type of Business Case (cost-justification) to be prepared.  The common purposes for these Business Cases include:

  • Clarify the initiative
  • Justify the cost
  • Prioritize the initiative against other activities competing for limited resources (e.g., funds, people)

As sensible and worthwhile as these sound, the dirty secret is that most business cases fail to achieve their highest purpose – to help drive value realization from IT investments! Let’s explore this phenomenon.

1. The Business Case as a Clarification Tool

Most (but by no means all!) business cases do a decent to good job at clarifying initiatives:

  1. What problems are we trying to solve?
  2. How will this solution solve them?
  3. What will the solution cost?
  4. What benefits – tangible and intangible will the solution bring?
  5. What other solutions were considered?
  6. Why is this solution recommended?
  7. What happens if we do nothing?

2. The Business Case as a Cost-Justification Tool

Here is where business cases typically start to fall down:

  1. Costs are often short-sighted, failing to really anticipate ongoing maintenance, operating and retirement/decommissioning costs.
  2. Costs are often narrow-minded, failing to really anticipate the cost of change to business processes, competencies and unintended consequences.  Most initiatives cost more than you think they will!
  3. Benefits are often unrealistic, hard to quantify and make all sorts of unstated or unrealistic assumptions.

3. The Business Case as a Prioritization Tool

Given the weaknesses in the business case as a cost-justification tool, it is not surprising that the business case typically does a poor job in helping prioritize initiatives:

  1. Prioritizing one case against others might be very misleading.  Individual projects often become (by initial intent or in retrospect) parts of overarching programs.  It is as if my auto service shop tells me I need my front right tire replaced – it will cost me $50 but give me another 5 years of safe driving for that wheel. Oh, by the way, you need your front left tire replaced as well, another $50 for 5 years of safe driving. And so on for the rear tires. Oh, by the way, you will need a wheel alignment—that’s $50. But, we’re running a special: buy 3 tires and get the 4th free, plus we will throw in the wheel alignment for free. Now, do I prioritize 5 separate investments, one for each of the 4 tires plus the option of having all 4 done? Obviously not. The deal would be pitched to me not as 5 investment options, but as one integrated safety ‘program.’  IT business cases, however, are often pitched as separate ‘tire’ investments with the logic that it might be an easier “sell” or because each ‘wheel’ is the responsibility of a different business unit!
  2. Prioritization at the project level often means juggling and evaluating hundreds of projects. Most business-IT governance bodies are unable to reasonably evaluate so many initiatives.
  3. Investment prioritization is better handled at the program level—interdependent projects that together achieve an important set of business outcomes. But many Project Management Offices (even if they bear the name Program or Portfolio Management Offices) don’t really work at a program level – they work with laundry lists of individual projects.
  4. While prioritization at the program level is significantly better than at the project level, even then, program level prioritization often ignores portfolio implications. For example, what I really want from my business-IT investments is some sort of balance between short and long term investments, between high risk, potential high reward and low risk, low reward opportunities. I want some sort of strategic balance—which business units or product lines do I want to be investing in and which am I harvesting? Rarely is the portfolio perspective taken into account—a technique that is just about universal for the personal investment portfolios of all of the business and IT folk involved in the initiatives!

4. The Business Case as a Value Realization Tool

And the most valuable reason for the business case is the one that is almost always absent—value realization!

  1. What are the tangible sources of value this initiative or program will enable?
  2. How will these value sources be felt?
  3. How will we track and measure them and who owns the measurement plan?
  4. How will we account for them on the books?
  5. Who is accountable for them?
  6. What are the consequences of achieving them or failing to achieve them?
  7. Who are the key beneficiaries and what is their commitment to value realization?
  8. How will we capture and incorporate lessons learned?

How are you using business cases to drive value realization?

 

Enhanced by Zemanta

IT Organization Circa 2017 – 5 Year Countdown (Part 2)


countdownIn Part 1 of this post I pointed out why I’d named this blog “IT Organization Circa 2017” and why I’d picked 2017. I then offered some musings about the nature and shape of the IT Organization Circa 2017.

I set this up by examining the major disruptive forces acting on the IT organization today:

The bottom line is that many IT organizations are at risk of being disintermediated – victims of the inextricable forces mentioned above.

“You cost too much and add too little value!”

is the familiar cry – but one that is more about the IT organization than it is about information technology.

The End of the IT Organization?

My view of the next five years is that in extreme cases, the IT organization as we know it will be gone – supplanted by a constantly shifting landscape of outsource providers, consultants, cloud solutions and “shadow quasi-IT groups” embedded in business units and taking care of local business needs. I can safely predict this because it’s already happened. In fact, when I started my IT career in 1970, working for International Computers Limited, (ICL) one of our major national accounts was British retailer Marks & Spencer. At that time, Marks & Spencer had no computers or IT department, even though they were highly computerized. Founder Michael Marks believed the firm should stick to what it knew – retailing – and hire experts to do the things it needed but did not know how to do. Consistent with that philosophy, ICL ran all Marks and Spencer’s computing. Nowadays, we call that “core competence.” As an aside, contrast that with another great British retailer and food manufacturer, J. Lyons & Co. who in the early 1950s had developed their own computer, the LEO, which eventually became part of my employer, ICL!

Already today, many companies around the globe have slashed the size of their IT organizations – some by 80-90%, taking advantage of global sourcing options and shifting the headache of running an IT shop to one or more outsourcing partners. There has, of course, been some backlash, and a small proportion of these outsourced IT shops bring their work back in house. In some cases, this is part of a long term strategy – pass your IT capabilities over to an outsourcer (or several) for a few years to have them “fix it” then bring those capabilities back in house. But even with the ebb and flow of the outsourcing movement, the trend is clear.  As companies become more networked and try to become more agile, they are less inclined to sustain large internal IT groups.

Similarly, the value proposition for cloud computing and the rapidly growing base of ‘software as a service’ is just too compelling, and the general satisfaction with internal IT capabilities too underwhelming. Why make huge capital investments in core systems, and carry the depreciation, maintenance and operational costs when I can ‘rent’ these and ‘pay by the drink’? Just as application packages have tended to supplant custom software development, software as a service is tending to supplant applications packages. As more computing moves to mobile, costly application packages become relatively inexpensive (or at least, value priced) “apps.” And the key issue with emerging computing models such as cloud and mobile is that they do not necessarily depend upon a permanent, in-house IT department.

The Ebb and Flow of Centralization and Decentralization

Organizational models tend to go through cycles of centralization and decentralization. There is always a tension inherent in finding the proper balance between the efficiency and scale of centralized, shared capability models and the responsiveness and customer-intimacy of decentralized models. This tension is never resolved – it is simply held in some sort of uncomfortable balance until the forces on one side outweigh the forces on the other side. This imbalance is often triggered by changing market conditions or by other disruptive forces such as new technologies.

The Mainframe Era – Centralization Rides High!

We’ve seen this through many cycles of technology shifts and their impact on IT organizational models. Back in the early days of the mainframe computer (early 1960s) virtually all IT professionals either worked for vendors/solution providers or worked in a centralized IT group.  (Back then it was typically called Data Processing.)

The Minicomputer Era – Departmental Computing Catches On!

With the advent of the minicomputer in the mid-1960’s, so-called “department computing” came of age, sometimes with the blessing of central IT groups, but often behind their backs.

Enter the Personal Computer – Departmental Computing Evolves into Decentralization of IT

As minicomputers gave way to personal computers and with IBM‘s launch of the IBM PC in the early 1980’s, the genie was further out of the bottle and the swing to what was euphemistically referred to as “distributed computing” was all but unstoppable. IT was becoming decentralized!

Inevitably, cracks in the distributed computing wall quickly appeared as users tackled issues such as mainframe connectivity and enterprise data management, and wrestled with the practical realities of back-up, security, integrity and privacy.

The Realities and Complexity of Enterprise Computing Surface – Centralization of IT Makes a Comeback – Sort Of!

By the early 1990’s the pendulum had begun to swing back to centralization. It seemed on the face of it that the old guard of the central IT group had returned in force.  But look under the covers, and what you see is not simply a return to the monolithic central IT group.  The new IT operating models had novel features such as:

  • Business-IT governance boards that moved ownership of prioritization and, in the best cases, value realization out to the business.
  • Business relationship managers bridging between the IT organization and business groups.
  • Business and Enterprise Architects focused on Business Operating Models and process management.
  • Sourcing and Vendor Management Groups.
  • Security and Privacy Groups reporting to senior business executives, embracing IT but not limited to it.

In other words, the centralized IT model of the early 1960’s had given way to a hybrid model that sought a more even-handed balance between local and global computing models. With the ascendance of cloud and mobile computing and the rise of global sourcing, I believe we are on our way to a new generation of computing model.

The Emerging IT Operating Model

I think it’s important to think of an IT Operating Model as an enterprise-wide construct – i.e., an IT organization is but one component. Many more IT functions are being distributed and dispersed – witness the so-called rise of Bring Your Own Device (BYOD). Here, functions that were performed by a central IT group are being performed by the business individual.  And this move towards ‘self-service’ and ‘business embedded’ functions will only expand with emerging technology. As such, we can think about IT Operating Model components as comprising centralized, decentralized and hybrid components. These might fall along the following lines:

Centralized Capabilities: Shared IT Services; Value Proposition = Standardization, Operational Excellence

  • Enterprise Architecture
  • Enterprise Shared Infrastructure
  • Enterprise Shared Solutions
  • Security and Privacy
  • Sourcing and Vendor Management

Decentralized Capabilities: Business-dedicated IT Services; Value Proposition = Customer Intimacy, Innovation)

  • Business Architecture
  • Local and Departmental Solutions
  • Business Analytics

Hybrid Capabilities: Networked IT Services, Communities of Practice; Value Proposition = Integration, Shared Learning

  • Business-IT governance/value realization boards
  • Innovation Centers
  • Organizational Development and Change Leadership Centers
  • Business Relationship and Sourcing Management
  • Data Visualization
  • Integration
  • Process Management

Why This Is Good News for the IT Profession

I will explore some of the implications of this shift for the IT profession in a future post, but by and large, given the many ways that I’ve seen IT professionals trapped in the past by their employers, I’d say the changes we are experiencing, while painful, will be beneficial at many levels.

 

Related articles

countdown5 IT Organization Circa 2017 – 5-Year-Countdown – Part 1

Enhanced by Zemanta

Free Webinar: The Changing Business Relationship Management Role: Past, Present and Future


iStock_000008462699SmallWhat is a Business Relationship Manager?

The BRM is a crucial role that bridges a business partner with an internal provider. The role evolved from both the Customer Relationship Management discipline that focuses on all aspects of an organization’s customer interactions, and the Service Management discipline, designed to optimize complex service-intensive supply chains. The BRM role has been embraced by the IT Infrastructure Library (ITIL®) and the ISO/IEC 20000 standard for IT Service Management as a new best practice and an international Service Management standard requirement. The most common BRM represents an IT organization, but BRMs can also serve internal HR, Finance, Legal and other shared services functions.

Rooted in, but Not Constrained to Customer Relationship Management and Service Management

While its relationships with Customer Relationship and IT Service Management are important aspects of the BRM role, especially as it is commonly described today, the nature of the BRM role and its capacity to identify and help realize strategic opportunities goes well beyond these realms.

So, How Is the BRM Role Evolving?

Through Business Relationship Management Institute, I will be presenting a Free 60-minute webinar that will explore how the BRM Role is evolving and how it is becoming a vital strategic enabler. I will be covering the following topics:

  • The Emergence of the BRM Role
    • Explores the forces that led to today’s rapidly growing BRM professional community and the common variations in role scope and positioning.
  • Current State of the BRM Practice
    • Examines the typical responsibilities for the BRM role and how these are changing with business demand and provider supply maturity.
  • BRM Futures
    • Presents the latest thinking and research about how the BRM role is evolving and what this means to today’s BRM professional.

Webinar Logistics

The one-hour free webinar will be held on Thursday, August 1, 2013 at 10am EDT, and repeated on Monday August 5, 2013 at 7pm EDT.  It will be delivered via Citrix GoToWebinar.  All that is required is a computer with a browser and a high speed Internet connection, with either a telephone, or a microphone and speakers or a headset.

To register for the Thursday, August 1 session at 10am EDT, please click here.  (Webinar ID: 117-570-139).

To register for the Monday, August 5 session at 7apm EDT, please click here.  (Webinar ID: 117-661-379)

Related articles
Enhanced by Zemanta