The Agile Manager
Friday, February 29, 2008
  Minimising the Speculative Risk of IT Investments

The cost of IT is often confused with its value. Consider earned value management: delivery, time and cost are combined in an attempt to better represent project performance. This might show the rate of cash burn to total expected effort by a development team, but it isn’t an indicator of value as the name might imply. This is simply another way to present cost. Cost is a measure of money out of pocket, whereas value is a measure of returns. The cost of an IT project is at best the liquidation value of a project – the capital that could be raised by selling the intellectual property produced. But it is not value. Value is return, and like any use of capital, an IT investment has to provide a return that exceeds the firms cost of capital.

So what is the value of an IT project? Equities are valued by asking, “what is the market willing to pay for a dollar of profitability.” Equity is far more liquid, and more sophisticated in its measures: for example, we have P/E ratios that help us to gauge whether or not a firm’s valuation is overweight or underweight relative to forward expectations of returns (specifically through the increase of market capitalisation and dividends). IT projects don’t offer this much technical analysis, but conceptually we can borrow some concepts.

The intrinsic value of an IT asset under development is the net present value of future profitability that is expected to be derived from putting the asset to work. From an IT perspective, intrinsic value has both tangible and intangible components to it.

All IT solutions are of speculative value until they are delivered and expectations of returns are shown to be viable. Tens of thousands of person hours and millions of dollars may be expended in development of millions of lines of code, but unless that code is in production, the firm derives no value from the investment.

Like all speculative investments, returns are at risk. The risk with which IT must be most concerned is delivery risk. Until an asset is released to production, there is a probability that the asset will fail to be developed correctly. The possibility of failure in delivery creates the threat of reduced returns. Delivery risk is eliminated once software is in production.1

The speculative component of an IT asset is at greater risk the further into the future it is expected to be completed. The probability that business, people or technology will change increases with each additional day that an IT asset is being developed. The probability of slippage in functionality, time and investment introduces volatility to the IT portfolio.

Volatility can generate windfall returns in finance. Market speculation can wildly change the value of a stock or bond relative to its purchase price. The holder can exploit this delta (up or down) to book a profit. By comparison, returns driven by operations are rarely so flexible. Software delivery is work performed over time, and time cannot be recovered. Experience has shown that an IT project is more likely to suffer delays in delivery and depress returns, than it is to accelerate delivery and increase returns. Volatility in delivery is thus a downside force, and needs to be minimised.

Traditionally, IT has attempted to apply deterministic management as a means of reducing volatility. We build elaborate project plans, we map out a predefined collection of tasks, we plot a task order down to the hour, and we track activity of what people do day by day as our barometer of progress. This top-down approach to management has low tolerance for anything that happens in the “left-to-right,” or over the course of time. This approach offers little more than wishful thinking. “Plans are useless,” said Dwight D. Eisenhower, “but planning is indispensable.” Intricate plans that forecast future activity in detail have low tolerance or complete disregard for the impact of changes that occur over time, such as staff, capability, business or technology. Indeed, deterministic project planning holds the business solution static, any staff interchangeable, and any technology change turnkey. Experience has shown overwhelmingly that this is not the case. Projects with intricate plans tend to have continuous cycles of replanning as things change. Deterministic management doesn’t decrease volatility; it simply adds overhead to the IT project, and drives down returns.

A plan cannot increase the tangible value of an IT asset. Only the asset can do that. We should therefore focus energies on rapid and incremental delivery. Tangible value is realised when some functionality is delivered that produces value. With each incremental delivery, and every increase in tangible value, the intangible or speculative value decreases.2 The reduction in speculative value at risk represents a reduction in the total value that can be depressed through delays in delivery. Thus, early delivery reduces the risk of speculative value not being realised. Simultaneously, it reduces the volatility of returns.

By itself, IT doesn’t generate business value. The business must consume the assets that IT produces in such a manner that it can put them to work efficiently and profitably. But that doesn’t mean IT is just a cost center. It can, in fact, drive alpha returns for a business. Corporate capability is largely driven by technology. IT is often the plurality, if not the majority, of spend on business initiatives. Incremental delivery of system components can increase returns on corporate investments where time is more important than cost. With capital under management that is expected to deliver returns, IT governance has a portfolio management obligation. As portfolio managers, IT must do things that maximise yield of invested capital. Concomitant with maximising yield is minimising risk. Risk is minimised through asset realisation.


1 Provided, of course, that what is delivered is functionally and non-functionally fit, and of sufficient quality. These should never be assumed outcomes.
2 New information may lead us to conclude that the impact of the asset will be different than originally forecast. For example, an asset under development might suddenly provide more impact to a firm because of changing market dynamics, making some portions of the application of greater value than others. For sake of simplicity, intrinsic value is assumed constant in this example.

Labels: , ,

 




<< Home
Agile approaches to IT leadership, governance and management

About Me
    Name:
      Ross Pettit
    Location:
      Worldwide
 
Recent Work
  • alphaITjournal, 13 May 2009: Governing IT Restructure
  • Baltic Dry Posse, 11 May 2009: Stress Test Grade Inflation
  • Webinar, April 2009: Restructuring IT
  • alphaITjournal, 24 February 2009: Restructuring IT: Changing Fundamentals In-Flight
  • alphaITjournal, 21 January 2009: Come the Hour, Come the Leaders
  • The Cerebral Dad, April 2009: Extraordinary Accomplishments
  • Previous Posts
  • IT Effectiveness is Measured by Asset Yield
  • Mitigating Capability Risk
  • Market Power Increases Exponentially with IT Veloc...
  • IT Governance Maximises IT Returns
  • Investing in Strategic Capability versus Buying Ta...
  • Good Management Can Work Miracles
  • Alpha Returns Require an Alpha IT Capability
  • Strategic IT Does More than Assume Technology Risk...
  • Just as Capital Has a Static Cost of Change, So Mu...
  • Patterns and Anti-Patterns in Project Portfolio Ma...
  • Selected Articles and Publications
  • alphaITjournal, 19 November 2008: States of Governance
  • alphaITjournal, 22 October 2008: Volatility and Risk of IT Projects
  • Webinar, 19 September 2008: An Agile Readiness Assessment
  • alphaITjournal, 17 September 2008: Is Your Project Team "Investement Grade?"
  • alphaITjournal, 25 July 2008: Are You Marking IT Projects to Market, or Meltdown?
  • Press release announcing the launch of alphaITjournal.com, July 2008
  • ThoughtWorks CIO Update Video, June 2008: Taking Agile Maturity to the Next Step
  • Webinar, June 2008: Agile Made Us Better, but We Signed Up for Great
  • ThoughtWorks Studios Blog, June 2008: Metric-Driven Management versus Management-Driven Metrics
  • Webinar, June 2008: Agile Reporting and Metrics: Project Intelligence for Successful Software Delivery
  • Agile Journal, April 2008: Quality Assurance: Value Added Partner, not Blunt Instrument
  • The Wall Street Journal, Letter to the Editor, 25 March 2008: IT Leaders Must Change, Not the Business Side
  • Agile Journal, February 2008: Management Driven Metrics Versus Metrics Driven Management
  • Agile Journal, January 2008: The Dichotomy of Change
  • Agile Journal, December 2007: Building High Performance Capability
  • Agile Journal, November 2007: Mythical Agile Shortcuts
  • Agile Journal, June 2007: The Agile Organization
  • Agile Journal, January 2007: Business Value Applied: Aligning the Day to Day with Business Imperative
  • Agile Journal, December 2006: An Agile Approach to IT Governance
  • Agile Journal, October 2006: So You've Decided to 'Go Agile' - A Pragmatic Approach to Onboarding Agile Project Management
  • Agile Journal, June 2006: An 'Agile Maturity Model?'
  • Agile Journal, March 2006: Agile Processes: Making Metrics Simple
  • A complete listing of articles published on alphaITGovernance on alphaITjournal.com
  • A complete listing of articles published on The Agile Manager on Agile Journal
  • Translator (Spanish to English), 1999. Homestyle Recipes for Financial Management Candioti, Eduardo. 5th Edition (Bilingual). Universidad Adventista del Plata Press.
  • Presentations
  • Webinar, 5 November 2008: The Agile PMO - Real Time Metrics and Visibility
  • Webinar, June 2008: Agile Made Us Better, but We Signed Up for Great"
  • Webinar, June 2008: Metric-Driven Management versus Management-Driven Metrics
  • Zürich, March 2007: Swiss Testing Day 2007 - A Pattern for Continuous Testing in Dynamic Domains
  • Munich, January 2007: OOP 2007 - Forge behind the Firewall
  • San Francisco, December 2006: SDForum - The Future of Open Source Communities: The Impact of Exchanges, Forges and Marketplaces
  • Sydney, Melbourne, November 2006: ThoughtWorks Australia - Quarterly Technical Briefing
  • Toronto, October 2006: e-Financial World Expo - Trends in Financial Services Application Development
  • Webcast, July 2006: Agile Journal - Enabling Global Business Success
  • Blogroll and Links
  • Mike Ward's blog.invoke(m2ward);
  • Mike Ward's Waffle: A faster way to develop Java web apps
  • Paul Hammant's Inversionism
  • Paul Julius
  • Muness Alrubaie's Mundane Essays
  • Adrian's Tech Blog
  • Mike Roberts' Blogtastic
  • Miško Hevery's Testability Explorer
  • Brad Cross
  • Zoonabar
  • Joe Z's The Agile Project Manager
  • Sean Doran's IT is All About the Delivery
  • Shaun Jayaraj's What to do? We are like this only
  • Carl August Simon's Corporate Sex Therapy
  • Carl August Simon's Consulting Adventures
  • Tom Looy's Conversations with Andrew
  • Archives
    July 2006 / August 2006 / September 2006 / October 2006 / November 2006 / December 2006 / January 2007 / February 2007 / March 2007 / April 2007 / May 2007 / June 2007 / July 2007 / August 2007 / September 2007 / October 2007 / November 2007 / December 2007 / January 2008 / February 2008 / March 2008 / April 2008 / May 2008 / June 2008 / July 2008 / August 2008 / September 2008 / October 2008 / November 2008 / December 2008 / January 2009 / February 2009 / March 2009 / April 2009 / May 2009 / June 2009 /


    Content © Ross Pettit 2006-2008

    Powered by Blogger