What This Article Covers
- Injecting Reality into IT Decision Making
- What is the Maximum Tolerable Functionality
Injecting Reality into IT Decision Making
When reading books or articles that explain a functionality I notice that there is a clear orientation to describe the functionality only in terms of its benefits. However, nearly all functionality implies some type of overhead, and a company can only activate so many areas of functionality within an application because there are limited resources on projects, and planners and planning departments have a limited capacity to learn and apply various functionality.
I was recently reading a book on SAP APO, and in the book one area of esoteric and difficult to configure functionality was trotted out after another, and I began thinking “the author can’t possibly believe that clients will be able to implement most of these can he?” Of course that is the problem when an author also works for SAP, and the book is treated as much as a sales device as it is a mechanism to explain how to use SAP software. In SAP consulting /implementation is entirely subordinate to sales and marketing. This is the problem with software vendors that are under the heavy pressure of continually making earnings numbers — it moves most of the power in the organization to those that can make the short-term numbers.
What is the Maximum Tolerable Functionality?
This “maximum tolerable functionality” level is quite evident when one reviews APO implementations that have been live for years. In every case that I have reviewed, the company implemented some functionality that they were unable to maintain, and thus the functionality fell into disuse or was no longer active in the solution at the time I did the review.
Therefore, it is important to pick the most important functionality from all that is available, and to match the company’s ability to pay and maintain functionality versus the benefits of the functionality. This is a completely contrary way to deciding which areas of functionality to activate because for one, most businesses assume they can do more than they can, two, vendors tend to want their applications used as much as possible, and three, consulting companies have a bias to implement more software and more functionality as it maximizes their billing hours.
Financial Bias Disclosure
This article and no other article on the Brightwork website is paid for by a software vendor, including Oracle and SAP. Brightwork does offer competitive intelligence work to vendors as part of its business, but no published research or articles are written with any financial consideration. As part of Brightwork’s commitment to publishing independent, unbiased research, the company’s business model is driven by consulting services; no paid media placements are accepted.
Enterprise Software Risk Book
Better Managing Software Risk
The software implementation is risky business and success is not a certainty. But you can reduce risk with the strategies in this book. Undertaking software selection and implementation without approximating the project’s risk is a poor way to make decisions about either projects or software. But that’s the way many companies do business, even though 50 percent of IT implementations are deemed failures.
Finding What Works and What Doesn’t
In this book, you will review the strategies commonly used by most companies for mitigating software project risk–and learn why these plans don’t work–and then acquire practical and realistic strategies that will help you to maximize success on your software implementation.
Chapter 1: Introduction
Chapter 2: Enterprise Software Risk Management
Chapter 3: The Basics of Enterprise Software Risk Management
Chapter 4: Understanding the Enterprise Software Market
Chapter 5: Software Sell-ability versus Implementability
Chapter 6: Selecting the Right IT Consultant
Chapter 7: How to Use the Reports of Analysts Like Gartner
Chapter 8: How to Interpret Vendor-Provided Information to Reduce Project Risk
Chapter 9: Evaluating Implementation Preparedness
Chapter 10: Using TCO for Decision Making
Chapter 11: The Software Decisions’ Risk Component Model