Paying for value rather than activity

Since the 1980s the costs associated with functions that are shared have been increasingly allocated to business units in such a way as to drive accountability.

For information technology this was relatively easy in the late 1980s as the majority of costs were associated with the expense of infrastructure or processing.  Typically the cost of the mainframe was allocated based on usage.  Through the 1990s, costs moved increasingly to a project focus with a model that encouraged good project governance and the allocation of infrastructure based on functions delivered.

Arguably, the unfortunate side effect of the allocation of project costs has been that many business units see information technology as being unnecessarily expensive – whereas many of the costs are really just reflecting the sheer complexity of business technology (see my previous post: CIOs need to measure the right things).  Such an approach to cost allocation has allowed business units to execute projects of increasing sophistication; however it may not be ensuring that information technology is being used in the way that will achieve the greatest possible strategic impact.

The other problem with the project-focused approach to cost recovery is that the CIO’s role is diminished to being that of a service provider.  In some organisations this has gone so far as to result in the CIO seeing external service providers as competitors.

Refocusing the cost recovery to the value achieved has the potential to deal the CIO back into the strategic debate.  As I’ve said before, information technology is extremely complex and requires experience and insight in order to identify the real opportunities to use it effectively to support and differentiate any business.  During the next decade, we are likely to see the continued blurring of the lines between internal business technology, joint ventures and the products that consumers use.  For instance, joint venture partners expect to see detailed financial reports across boundaries and consumers are used to helping themselves through the same interfaces that were previously restricted to call centre operators.

Recently on the web there has been some discussion on whether information should be valued.  At the same time there has been good progress in the development of techniques to value information assets (for instance, see the MIKE2.0 article on Information Economics).  The value of information is a very good way of predicting likely business value, even when the way that value will be realised has not yet been determined.  The disruption to previously stable businesses, such as retail, telecommunications and manufacturing, are very good examples of why it is important to understand value beyond the horizon of current revenue models.

Allocating at least some of the cost of an effective information technology department based on value focuses the budget debate on the development of revenue earning products that will leverage these new capabilities.  It also ensures that those units receiving the greatest potential value are motivated to realise it.  Finally, the move away from a largely activity-based approach to measuring cost reduces the tendency to continually cut project scopes to keep within defined budget.

Advertisements

About infodrivenbusiness

Robert Hillard is the author of Information-Driven Business, available through John Wiley & Sons. Find out more at www.infodrivenbusiness.com. Robert was an original founder of MIKE2.0 which provides a standard approach for Information and Data Management projects. He has held international consulting leadership roles and provided advice to government and private sector clients around the world. He is a Partner with Deloitte with more than twenty years experience in the discipline, focusing on standardised approaches to Information Management including being one of the first to use XBRL in government regulation and the promotion of information as a business asset rather than a technology problem. Find out more at www.infodrivenbusiness.com. The opinions expressed in this blog are entirely his own.
This entry was posted in Information Management and tagged . Bookmark the permalink.

One Response to Paying for value rather than activity

  1. Jason Bell says:

    Paying for value means being able to measure value. Measutring the value of software or improved information management after the fact is hard enough let along predicting it before hand to establish a “value proposition” related budget.

    I like the idea of paying for value and used properly it should see projects use the value proposition drive scope discussions, and hopefully even the methodology.

    I am interested in the comment “ensuring that information technology is being used in the way that will achieve the greatest possible strategic impact”. To me that is a common goal but seldom achieved successfully. I have thoughts on why. I think it is easy to achieve from a developers perspective, but I doubt many CIO’s would have the courage to do it: Agile Methodology.

    Understanding the value proposition up front can help set the budget but achieving the value outcome is all about the end product. Is it usable? Does it suit the business needs? Is there room in the project governance to shift the design when needed to achieve the best outcome?

    Too many projects go the same way:
    1. We want quality and usability
    2. We dont know the software but have been asked to specify how it should work it in detail up front
    3. You delivered what we asked for, but it turns out it is not what we wanted – we did not know better since we are new to this
    4. We will all pretend we are happy because it cost so much and the CIO needs to feel good about his purchase

    People are scared of agile because they think the cost will blow out. That happens on any project due to poor management – Agile is no different.

    But agile realises that value becasue the product is refined in cycles to ensufre the customer can change their mind as they go without affecting the budget. Agile welcomes change – waterfall resists it. In the end both customer and implementation partner are happy because the outcome is awesome.

    Outcome: value achieved.

    And yes I think this can be done for packaged software implementation like SAP. I hope someone has the guts to try some day.

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s