Business Cases: Simplicity over Sophistry

In textbook portfolio management, we have a thorough and well researched business case that details the features, costs, and ROI we expect to achieve for each initiative.

Even if this did describe how most businesses start IT projects (and it does not), it is futile. Business cases are easily co-opted, marginalized, and bypassed in the normal course of day-to-day business.

Let's look at the theory behind having a business case. A business case defines why we want to make an investment. Beyond just being a rational thing to do, policy dictates that we have a business case: the rules governing capitalization require that we explicitly define what we expect to achieve, at what cost, for what benefit, over what time. A well formed business case satisfies the preliminary (pre-capitalization) obligations that allow an investment committee to approve or reject a proposed investment.

But most software investments are never pitched to an investment committee. We only need investment committee approval when spend is expected to exceed a set threshold, which in some businesses can be as high as $10m. Most IT projects are projected to cost far less than this. Funding for these projects is secured through the annual budgeting cycle. The temporal nature of financing decreases the demand for a business case. That, in turn, means a whole lot of IT investment is going on without a clearly articulated statement defining why it is being done in the first place.

We tend to assume that the more thoroughly it is researched and written, the stronger the case. This tends to lead to lengthy and elaborate justifications (perhaps they are lengthy and elaborate to justify both the investment being proposed and the time required to produce the business case itself). But rather than insight and wisdom, we get rationale that is highly suspect. This is true for all kinds of investments. John Kay pointed out that the economic cases for the HS2 rail project in the UK and the trams in Edinburgh are strangely precise, wildly optimistic, and ultimately justified by impact ancillary to the problem they should seek to solve: it makes no sense to offer a 25 minute journey from the center of town to the airport on a GBP1b tram when you can offer the same journey in the same amount of time on a far less expensive bus. They are vanity projects justified by complex, black box analyses. We see this same phenomenon in IT: people will go to great lengths to justify technology projects as a means of career advancement, job protection, skill acquisition, or organizational power building.

Nothing erodes the credibility of a business case faster than overstated benefits. Academic examples of business cases use hard figures such as revenue increases or cost decreases to calculate project ROI. But most corporate IT investments don't directly increase revenue or directly reduce costs. They make people "more productive" or they "improve customer service". These are worthwhile things to do, but they are soft benefits. Since these usually do not become hard benefits such as staff reductions or additional sales, we use proxies, things like "positions not hired" or "customers retained", to make them more tangible. Although it's good to acknowledge potential strains and risk of losses, these make for weak justifications when they are unlikely (projecting an un-needed job is only valid if there is funding for a position) and when they are hard to quantify (we generally don't know with any accuracy what customers we stand to lose if we don't make this investment).

The disparate nature of these measures often drives us to consolidate our projected benefits into a single index of "business value." As covered previously, this confuses and weakens our case. Better that we communicate projected hard and soft benefit independently, and do not overstate either our optimism or the precision with which we can measure.

Finally, change doesn't happen in isolation. Technology investments are usually implemented in conjunction with a broader package of business initiatives that may stretch from marketing to fulfillment to accounting policy. Although one specific investment may be the focus of a business case, we have to keep in mind that businesses are constantly changing how they operate, interact with suppliers, and appeal to customers. Market forces also take their toll, forcing us to react to changes in our operating and competitive landscapes. This makes it hard to trace with any accuracy the impact any single change has on any specific outcome. Most often, the best we can say is that a solution is a contributing factor to a changed state of the business. That is still reason enough to make an investment, but it dulls the confidence we can responsibly have in a projected ROI.

All told, writing elaborate business cases is tilting at windmills.

This is not to say that business cases lack value. A good business case is critical to governance, portfolio management and execution. They capture the best information that we have at the time. They provide a foundation to "why" we elect to make an investment, guidance as to "what" it will mean to fulfill that investment, and an ability to assess both the attractiveness, viability and success.

But we should think about our business cases a little bit differently than the textbook would have us do.

Thomas Lissajoux makes the point that it shouldn't take more than a day to write a business case, and it shouldn't require more than a single sheet of A4 to make your case. A business case may be multi-faceted, but it need not be overly verbose. We should also follow John Kay's advice and be less concerned with precision and more concerned with clearly and simply expressing our expectations. If we're investing too much time, or being elaborately descriptive, or pursuing precision, or building too complex a model, we are reaching for justifications. Short and simple will also mean that our business case is accessible, understandable and believable to a wide audience of stakeholders and participants over the life of an investment.

Elaborate models developed in support of precise justification are not business cases, but sophistry. The textbook business case is best left to academics to debate. Those in business are best served by simple statements of wants, needs and expectations.

Business Value is a Weak Currency

Investments in infrastructure, whether public transport or IT applications, tend to lack hard numbers because they are a means to an end and not an end in themselves. We have transport to enable people to travel to work and allow goods to reach markets. Captive IT departments produce systems that enable us to conduct business faster and more efficiently and at larger scale.

In the absence of hard measures, we concoct soft ones. Since the 1960s, transport improvements such as HS2 have been justified by cost-benefit analysis of things such as accident reduction and time savings. In IT, we use "business value", a nebulous catch-all for any and all types of economic benefit a business will conceivably derive from an IT solution.

Any given IT investment will be expected to yield a hodge-podge of benefits as diverse as revenue increases, efficiency gains and improved customer satisfaction. It is appealing to combine these into a single measure of business value because it makes it easier to compare costs with benefits. It is also appealing to sum up business value across all projects as a way of expressing the impact that IT has on the business. In practice, though, business value makes for poor coin of the realm because it suffers two serious deficiencies.

First, it attempts to aggregate benefits that have fundamentally different economics. Not every dollar of business value is the same: a dollar of revenue has much different value to a business than a dollar of cash flow, or a dollar of profit, or a dollar's worth of increased productivity, or a dollar's worth of improved customer service. Rolling these up into a single metric of value is akin to aggregating apples and corn syrup into "sweet foodstuffs". It does less to upgrade the perception of the intangible benefits from an IT solution than it casts doubt over the more tangible ones.

Second, business value is prone to runaway inflation. Suppose we create a shoddy but effective solution to solve an urgent business problem, and sometime later we take on the important task of replacing that shoddy solution with a more robust one. How much business value do we get from the re-implementation? Since we cannot accrue the same business benefit multiple times, about all we get is greater reliability and lower maintenance costs. These have merit in their own right, but the benefits may not exceed the costs of the re-development. This encourages people to play loose and free with what "business value" means to justify an investment. That might mean taking credit for solving unintended process inefficiencies of the shoddy solution, or increasing the alleged risk that the shoddy solution fails in spectacular fashion. This makes business value a weak currency: because it is so easily conjured, it is easily inflatable, and it quickly loses value.

Some firms go as far as to track their annual business value delivered. I once worked with a firm that reported a total business value delivered that was greater than their market capitalization. Since nobody working there felt the firm was undervalued by investors, everybody dismissed the business value metric for what it was: an imaginary measure of imaginary benefits.

We should always base IT decisions in context of value to the business, but wanton overstatement undermines IT's perceived business value. If we delineate value by its underlying economics, we make a more compelling case for investing in the business through IT at all.

Strategic IT: Picking Winners is Hard, Cutting Losers is Harder

Previously, we looked at how we can separate Strategic IT from Utility IT, position the Strategic portion as an investment arm of the business, and manage it as a portfolio. Successful portfolio management requires that we have investment flow (regular promotion and demotion of opportunities), hedging strategies, and to behave as activist investors. If we do this well, Strategic IT becomes "investment" rather than "operations", a driver of business returns, and a source of innovation to the business.

But "doing this well" is hard. It's worth looking at why that is.

Let's start with the basic premise of portfolio management. Most descriptions of IT portfolio management go something like this:

1. We put all the ideas for IT solutions into a review/approval funnel.
2. Only the Very Best Ideas get approved.
3. Those that do get developed and delivered.
4. We reap massive profits.

If only it were so simple.

If you've ever managed investments of your own - even just a periodic redistribution of your retirement account - you know how difficult it is to manage a portfolio. We have very accurate historical data on the performance of specific companies, funds, and indexes, but we have no idea how any specific investment will perform in the future. Every investment is a leap of faith that our assessment of the opportunity and attendant risks is accurate, that governance is true and honest, that management have the expertise, that regulation is effective, and so forth. These might be informed leaps of faith, insofar as we've done our due diligence on the opportunity and its competitive landscape, as well as alternative investment opportunities before us. But as we don't know what tomorrow holds, it's still a leap of faith.

These same characteristics apply to Strategic IT investing, if to differing degrees. Compared to a securities investor, the Strategic IT investor has a more intimate relationship with the people managing execution of an investment, and is in a position to apply hands-on governance. But the Strategic IT investor doesn't have anywhere near the diversity of investment vehicles. The Strategic IT investor is essentially making very specific, targeted investments.

This means that Strategic IT investing is a business of picking winners. And if there's one thing we know about investing, it's hard to pick winners. Many researchers have argued that random walk investing performs no worse than picking winners. With index and sector ETFs making it easy for investors to match the market, it comes as no surprise that most capital is managed passively, not actively.

There are no passive instruments in Strategic IT investing. We're investing in a specific business through IT. Our investments are active by definition. We have to pick where and how we're going to place our bets, and just as importantly where and how we're not. We're in the business of picking winners. And no matter how much somebody touts their "rigorous and high standards for choosing investments", active investment management is hard. Go as John Paulson or Jon Corzine how hard it is to always pick winners.

And the challenge in portfolio management goes beyond simply picking winners. In our pursuit of picking winners, we're going to pick losers. In fact, we're going to pick a lot of losers.

So it is more apt to say that portfolio management is a process of picking winners that sufficiently outperform our losers. The objective isn't to avoid picking losers and only pick winners, but to recognize our losers quickly and minimize their impact on our portfolio.

Investors tend to hang on to losers for too long. It's tough for investors to admit a loss, because it's tantamount to admitting a mistake. Jason Zweig described it best: "it isn't that I've been proven wrong, it's that I haven't been proven right yet." For the Strategic IT investor, the emotional difficulty of parting with a loser is going to be reinforced by corporate cultures that insist that "our projects never fail". It will be impossible to fail fast and frequently if we can't come to grips with our mistakes.

Although we may very well need "rigorous and high standards" for choosing Strategic IT investments, it's perhaps more important that we have the discipline to quickly exit losers. This is why it is important that we have investment flow in our portfolio: as a portfolio manager I want to be able to fluidly enter and exit investments so that I can quickly cut my losses and redirect people and capital toward things I believe to be better opportunities. It also makes the case for activist investing: as a Strategic IT investor, I want to be able to continuously and consistently scrutinize my portfolio so I can continuously reassess and reinforce the viability and relevancy of my investments.

Even if we do this well, we still may never have an "optimal" portfolio. Our results will still be subject to forces and events we cannot foresee at the time we make an investment. And we'll pass on opportunities that turn out to be winners. But we will be much better at scuttling our losers. We'll be better at failing fast.

Annual Budgeting and Agile IT, Part III: Operational Predictability versus Financial Rationality

We've seen how Agile IT conflicts with the CFO's goals, and why the latter tends to trump the former. What can we do about it?

Conceptually, our starting point is to hive off IT investment activity from utility services. If the CIO doesn't draw this distinction, the CFO isn't going to, either. Making this separation allows us to talk about strategic IT in financial terms as opposed to operational ones. Not to become more coin-operated, but to level the playing field between IT and the rest of the business.

Let's look at capital for a minute. Firms acquire capital through many different means. There’s the capital accumulated through retained earnings. There’s also the capital we can raise by getting loans and selling bonds (debt) or issuing shares (equity). At any given time, a firm has many different ways to deploy capital, such as investing in operations, awarding bonuses, or paying a dividend to shareholders, just to name three. The Board of Directors, CEO and CFO will use existing capital, or raise new capital, and deploy it where it is expected (or just plain hoped) it will provide a return.

From an operations perspective, some of those uses of capital may seem unusual. For example, it's not uncommon for a firm to borrow money to make a dividend payment to shareholders. By doing so, the firm is simply borrowing against future cash flows to compensate shareholders. While this may seem counter-intuitive and even risky from an operations perspective, it illustrates the point that capital formation is dynamic: a business will raise funds to go after an opportunity. By comparison, budgets are static: we will constantly look to squeeze money out of a business.

Strategic IT must be seen as investments competing for capital against all other uses.

Every capital investment a firm makes has a business case that comes down to a simple question: “we're investing y capital in pursuit of x result". There are countless candidates for “x” that a business can throw a limited “y” at. Not every result is financial. There may be no quantifiable ROI. We could be looking to make social or political impact, or improve employee retention. The point isn't to measure financial returns, but to ask: how much are we willing to pay to get something in return? And in the extreme, how far are we willing to stretch our balance sheet to achieve a collection of “x” outcomes?

This would seem to make things a lot more complicated for IT. IT can't write the business case, it has to come from the business. And before we get something into production, we don’t really know what an IT investment will do for a business (what business impact it will have), let alone what it will actually take to get it into production. We can study, analyze and guess, but we really don't know. Why not just leave the business to the business, and the tech to IT?

Because in Strategic IT, we're doing the latter in pursuit of the former, and what's true for IT investments is no different from any other investment a business makes. We can do all the market research we want, but marketing doesn't know whether a new product will sell well or not until that product makes it to market. We can agonize over population demographics, but we won't know whether we’ll find skilled labor to staff a new manufacturing facility we've built until we set up and start hiring. An acquisition may look good on paper, but we may never realize the expected cost savings from a merger.

The fact is, every capital investment is subject to uncertainty. 'Twas ever thus. The best we can do is to make well informed decisions and do everything in our power to minimize the things that operationally impair our success.

This helps IT tremendously. In this context, IT doesn't need to be operationally predictable, but financially rational. That's a better way to run a business. It levels the playing field for Agile IT: even a business with low tolerance for fluctuations in cash flow from operations will invest in itself. This means it has higher tolerance for investment variability than it does operational variability.

If Strategic IT is financial more than it is operational, it needs aggressive, Agile portfolio management. There are a lot of things that go into this, too much to cover in this blog post, so we'll focus on three: investment flow, hedging strategies, and activist investing.

Investment Flow

There are countless IT investment opportunities for a business. As technology continues to evolve, the number of those opportunities will only increase. This gives us a very broad portfolio of ideas we might pursue.

Clearly, some ideas are better than others. We can take a closer look at those ideas that look a little more promising by putting them through an initial inception: make a broad survey of the opportunity, perform some due diligence, and produce a business case and an initial estimation of cost. This will filter out the plainly bad ideas, and give us a portfolio of candidates that appear to be good ones. Agile inception practices are well suited for targeted, short duration discovery and for producing relevant (not to mention short and focused) artifacts. Agile inception gives us a simple litmus test to apply to any candidate investment, and it doesn’t cost a lot to apply it.

Those ideas that clear the first hurdle are subjected to a second, more rigorous inception. The objective is to refine the business case and fulfillment details such that business and IT are comfortable presenting an investable decision to an investment committee. To be clear, the objective is not to produce a definitive, closed-ended, detailed plan. Our facts, forecasts, expectations and assumptions are going to be wide of the mark. We're not trying to be predictable, we're trying to determine if there's an investment case given the information that we have today. In this second stage, we want to produce a sufficiently refined assessment of benefit, cost, execution expectations and risk guidance so that an investment committee can determine if this opportunity looks like a good use of capital given there are known and unknown risks.

Some opportunities will fail to live up to their promise and fail during the second stage of inception. Some will be rejected by the investment committee. Some will be approved and become investments that the business agrees to make.

Although we promote opportunities, investment flow is not linear. Continuous assessment of investment opportunities means a new arrival may cause an existing investment to be demoted or curtailed, while others previously deemed unviable yesterday may look attractive tomorrow. The portfolio of investable opportunities do not follow a one-way promotion from idea through fulfillment, but will fluctuate relative to each other.

The goal is to be constantly performing inceptions so that we get a healthy churn of our investment opportunities. This has residual benefits as well. It partners IT with the business to secure an investment. It gives us a defined collection of investments we want to make that will deliver some expected value (financial or otherwise) for some expected investment. It gives us a portfolio of things the business “intends to invest” in through IT, sufficiently well defined to satisfy guidelines for capitalizing intangible assets. It gives the CFO guidance on IT's expected capital needs.

Hedge The Investments

An investment that makes it into the portfolio of investable opportunities may still never be developed. It’s simply in the investment portfolio. Like any portfolio, we need to hedge our positions.

Suppose 10 opportunities are currently in the “approved to invest” portfolio. We don’t have to secure funding for all 10. Perhaps we work with the CFO to secure funding for 8, with 2 at the ready. We can still have all 10 “approved” by an investment committee because in just about every business, “approved” is not the same as “funded”.

Why leave 2 on the table? From a business perspective, this seems ridiculous, especially for the person leading the business unit holding the odd project out.

Let’s look at what happens when we’re delivering against this portfolio. All of these investments will be at-risk of losing viability during development for any number of reasons: because the business case becomes shaky, sponsorship fades, or we get into execution and find out it’s going to cost far more than our prior looks led us to believe. Not having a hedged position would put us right back in the long-range budgeting trap that we’re trying to avoid. Strategic IT is an investment arm of the business. Investments contain an element of risk. A good investment manager hedges his or her risks.

Which is why we have a hedged position in the form of other investments which have been approved, and why we’re constantly looking for new investment opportunities (inception flow) to promote. That reduces the overall volatility of our portfolio, which, in turn, gives us operational flexibility to reassign staff with minimal SG&A impairment. Should one investment fall out, we have another at the ready, and we're able to quickly move people (the most important thing we've got) into that next investment. This is important: maintaining liquidity in our project portfolio prevents an erosion of our solvency (that is, our capability to get things done) by avoiding a spending squeeze. Looking at it another way, hedging within the IT portfolio means operational continuity doesn't suffer as a result of misguided portfolio maximization.

It's worth pointing out that hedging financial risks is a big change from pursuing operational predictability, efficiency, or optimization. The CFO is directly accountable to the board and to shareholders for business returns. Performance is at the mercy of all kinds of factors outside the CFO's control: currency fluctuations, macroeconomic events, and political change just to name a few. The CFO will not be held accountable for failing to predict the future, but will be held accountable for hedging to a reasonable level of risk awareness, even of some Black Swan events. Sometimes risks will exceed expectations, and sometimes hedges will be excessive and appear to be waste. CIOs with responsibility for an investment portfolio would be held to this type of accountability. Being seen as responsible only for operating costs, however, the CIO is relegated to cost control.

Another hedging strategy is to have short-term horizons for every investment. The longer the time we spend delivering any single investment, the greater the risk accretion, the greater the risk of default. Large capital projects that default either need additional cash injections to keep them solvent, or face being written off. Making several small investments allows us to actively revisit the business case, viability, and priority of a large investment. Smaller investments keep our portfolio much more liquid, and increases our resiliency to operational default.

Activist Investing in IT

An IT portfolio must be reviewed and assessed with the same rigor as any financial portfolio. The span of time over which human effort is applied to convert capital to an intangible asset requires a lot of attention. We do this through continuous governance, to align operations with financial intent. These mechanisms allow us to continuously ask whether an investment is still viable, or whether it is being operationally impaired, or has lost business justification. This is no different from what we do with investments in a financial portfolio. This is a subtle but critical difference with traditional IT: we're not trying to "meet plan", we're constantly assessing whether an investment is viable and, if not, what we can do without having to go hat in hand back to an investment committee to ask for more capital.

But there's a difference between mechanical governance and investing. Too often, IT portfolio management is staffed with little more than project reporters. Continuous governance is only effective if we have activist investors: people experienced with technology investments who not only scrutinize the data but manipulate it, reframe it, challenge it, supplement it by getting their own, and interrogate the people behind it. There's a fine line between fulfilling a duty of curiosity and just plain meddling, so think before you act(ivist). Take cues from successful activists (one could do much worse than to do your homework as thoroughly as David Einhorn), engage outsiders as board members for investment governance, and above all challenge silence and rubber-stamping.

Portfolio Management

Our strategy, then, is to separate strategic IT into an investment arm, and manage it like an investment portfolio: inception flow that continuously screens and revisits investable opportunities, have a diverse and hedged portfolio of small capital investments, bringing continuous governance and activist investing practices to bear on those investments, and rebalancing the portfolio when necessary.

In general, this is how IT portfolio management should be practiced.

Doing these things gives IT investments a robustness they don’t typically have:

• We continuously assess new investment opportunities.
  
• We have continuous assessment of the viability of in-flight opportunities.
  
• We have a pool of funds out of which we can fulfill IT investment activity (an expectation for what we’ll spend on “human effort”).
  
• It makes capex more liquid (accessible at a more coarsely grained level), protecting any expectation we set for payroll funding out or capex and reducing the risk of a solvency (a/k/a “capability”) crisis should several projects be suspended (the equivalent of our “tier 1 capital” of IT).
  
• It decouples the budgeting decision from finely-grained (and inaccurate) project planning exercises, and roots our budgeting in value as opposed to cost.
  
• We can link the financing of the investment opportunity to the investment itself (e.g., we may raise capital specifically to fund a tech investment if we think it represents a major business opportunity or we need to stave off a threat to our business), and feed that directly into our portfolio management.
  
• We talk in financial terms and solve problems of the firm's capital allocation, instead of asking the CFO to talk in operations terms and solve (and often, over-simplify) IT's operational problems.

It’s worth looking at pure-play software investing as a useful comparison to captive IT investing. Generally speaking, software firms have low capital intensity (lower now especially with cloud) and little debt (the volatility of tech makes financing via fixed income instruments unattractive). They also tend to throw off copious amounts of cash (e.g., Microsoft, Google, etc.) This gives tech firms several degrees of freedom that firms in other industries simply don’t have.

People accustomed to the low-debt-high-cash tech investing environment tend to bring the same set of expectations of captive IT departments. Those expectations are well intentioned but wide of the mark, as illustrated in previous posts: because IT is seen by the business as part of operations, it is subservient to, not a component of, the financing demands of the business.

As I stated at the beginning, the fundamental concept is to have IT separate its investment activity from the utility services it provides. That seems like a conversational non-starter. But in most firms, there's a pretty good business case for doing that.

To put things in perspective, if the entire $350m discretionary IT investment [of this firm] had been retained as profit instead of spent on projects, the company’s earnings per share would have risen, creating more than $5bn of additional shareholder value.

Richard Bhanap, Managing Director, KPMG Europe writing in the Financial Times

A board doesn't have to invest in the business through IT. It can use capital to retire debt or buy back shares, invest in other securities, buy other companies, or make a dividend payment to shareholders. As Mr. Bhanap points out, when a company does invest in IT, those investments have a very high standard to meet. We lose sight of that standard when Strategic IT is thought of as "operations" as opposed to "investment". IT stands to benefit by taking on responsibility for investment performance.

Decoupling Strategic IT from operations, and instead casting it as an investment arm, gives us an opportunity to get Strategic IT out of the annual budgeting cycle and into an investment cycle. Doing that creates a more conducive atmosphere for Agile IT.

As a post-script to this series, we'll look at IT portfolio management - and what we're really asking IT to do.

Updated 29 December 2011

Annual Budgeting and Agile IT, Part II: Why Agile Gets Compromised When It Goes Corporate

In the first installment, we had a look at how the CFO is primarily concerned with consistent cash flow so that the business can service long-term financing obligations. As a result, when the CFO is first introduced to Agile, he or she will not be terribly pleased to hear that we’re doing away with predictive planning in favour of continuous reprioritization, even if we allege to be doing it in pursuit of maximizing capital allocation. To the CFO, although IT is a capital investment, it's also a drag on cash flow – cash that the business needs to meet its finance obligations.

In this installment, we’ll take a closer look at this discrepancy. We'll start by looking at what IT does for a business.

Most of IT consists of utility services, the things we need to run the business, such as laptops, virus protection and an office productivity suite. IT utilities become running or operating costs to the business, just like water and electricity: we pay maintenance fees for virus protection and office suite licenses, and buy new laptops when we add a new FTE to the payroll.

Replacing a utility, such as substituting Google Mail for Lotus Notes, can be expressed in investment terms: for the cost of migration, we expect our license fees and maintenance costs to be lower in the future. But replacing utilities is highly invasive to the business, and typically brings with it little capability gain. Firms don't have infinite capital and utility investments tend to offer low payback. Since there's limited upside (we'll squeeze only a little more cost out of the business) and there is significant downside should something go wrong (such as a loss of data or long-term interruption of service), we do these things when business is otherwise calm and we have nothing better to do.

But what about non-utility IT, investments in custom solutions that give us an edge in customer service, makes our supply chain more resilient, or builds our brand strength? Martin Fowler calls this "strategic IT": the investments into technology that gives a business a competitive advantage.

At first glance, these look like they should be treated differently. We don’t always know when an investment opportunity will arise or when we’ll get an idea. We don’t know what that investment will look like until we roll up our sleeves and get on with creating it. From an IT perspective, it would seem a business would be well served by being able to finance a strategic opportunity at the drop of a hat. This also seems like precisely where the Agile would appear to shine.

Unfortunately, it isn’t as simple as that.

Software development is the act of converting capital into intangible assets by way of human effort. Let’s look at what it means to finance IT effort.

Human effort is a payroll cost, which is a running cost to the business. If that human effort comes from our FTEs or direct contractors, it's our cash covering our payroll. If that human effort comes from a firm we've contracted with, it’s our cash covering somebody else’s payroll. As CFO, you don't miss your own payroll, and it doesn't do you any good if you cause a key supplier to miss one of theirs.

Payroll, like debt servicing, requires consistency. If software development is going to be a core capability, the CFO needs to know how big that capability is going to be and what impact it's going to have on cash flow. The CFO will also tell us if we’re building a captive IT organization that we simply can’t afford.

In strategic IT, meeting payroll isn’t just a matter of people and salaries. We have multiple funding buckets to be concerned with.In many businesses, software is treated as an asset. Even though it's intangible, software shares many of the same properties as tangible assets such as trucks or machinery: we can't operate the business without it, it tends to be expensive, we get multiple years' use out of it, we might make improvements to it, and it requires ongoing service and maintenance.

When we treat software investments as assets, we capitalize them. Software is capitalized over a 3 year period. Since we're going to get multiple years of use out of something, it's acceptable to distribute the cost of acquiring it over multiple periods. This reduces the volatility of the income statement: as they tend to be expensive, taking the full cost of acquisition in period 1 would excessively depress earnings, while having already reported the cost would mean earnings in periods 2 and 3 would be that much higher. This means capitalization has income statement impact for future periods - something the CFO is going to be particularly interested in.

Before we go any further, let's be clear about the accounting going on. For income statement and balance sheet purposes, we're going to capitalize the cost of developing software. This is a long-term treatment of software assets. But we still have payroll costs to meet, which impacts our cash flow. This is a short-term treatment of the effort used to develop those software assets.

We saw a lot of this in 2009: record cash balances allowed companies to cover costs, while moving more spending to capex contributed to strong earnings. Depending on a firm's experience of the financial crisis, this either deferred difficult decisions such as layoffs until cash became too tight, or, if they rebounded relatively quickly, it allowed them to emerge a much stronger competitor because they were able to retain experienced people throughout the crisis.

In practice, though, this two-speed accounting introduces a bit of friction. A CIO can’t simply choose a finance bucket out of which they’ll pay for salaries. Payroll allocated from a capital account is incurred against a specific asset in the general ledger, something the CFO must authorize. The rules governing capital expenditure are pretty strict. Labor costs can only be capitalized if they are demonstrably performed in the fulfillment of the expected characteristics of the asset itself. Labor costs incurred in R&D and administrative work always go to operating expense. So must any labor costs associated with defining what the asset is to be in the first place, work typically associated with early stage analysis. The devil is in the details, and in large corporate IT organizations, knowing that we're tracking the right effort to the right bucket gets cumbersome very quickly. We must be able to show that we're consistent and in compliance with these accounting guidelines. If we can't satisfy the auditors, we'll face a financial restatement. That's career limiting.

Where it gets really complicated is when there is a volatility in the IT portfolio. If the business pulls the plug on an in-flight capex project, we have to figure out how we're going to cover payroll of the people who were working on that project. We either have to have another capital investment ready for them to work on, we have to have sufficient unallocated opex to cover their payroll costs, or we have to lay them off. In finance terms, this is equivalent to a liquidity squeeze (inaccessible budget or insufficient budget) that can cause a solvency crisis (loss of skills and capability).

This brings us back to the question of how we finance "human effort". Human effort isn’t as liquid as capital. We steadily bleed cash from the business to meet payroll costs of the effort we’re buying, with only an occasional delivery of a software asset that enters use and has an impact on our business. The effort that we’re financing hasn't the financial properties of the capital we pour into it nor of the asset that it produces.

When we choose to fund salaries out of capex, we are beholden to that effort yielding a result. If that's going to happen, the effort has to be reasonably framed (estimates are valid, scope well defined, etc.) and that the business environment has to be static (the business will still want the intangible asset we’re delivering). Capex spending further binds IT to the financing structure of the business. The annual budgeting cycle that still governs companies sets an expectation that operations, IT included, will perform consistently with a big, up-front plan.

This is a contributing factor to why we see CIOs resorting to terms such as “control” and “predictable” rather than “fail fast” when explaining Agile to the CFO: it's a capitulation to the over-riding realities that drive a company. Being "predictable" reinforces the operational objective to produce consistent cash flow for finance; failing fast is a threat to it. It comes as no surprise that by the time Agile reaches the most senior levels of the business, it's been co-opted into the language of industrial management, just substitute "Scrum" and "burn-down charts" for "Waterfall" with "Gantt charts". Agile is rolled-out as a means of "guaranteeing predictability", or greater efficiency, not as a means of making better use of capital, or being more resilient to unforeseen events.

It's worth drawing a comparison between captive IT that engages in application development, and technology firms. Tech firms typically have highly volatile earnings and cash flow, which means they tend not to rely on debt financing. It's no coincidence that tech firms tend to be hotbeds of innovation, while captive IT departments in large corporates are not. Large tech firms are typically debt free, while tech startups tend to go one step further by trading equity for salary. Because tech firms aren't beholden to consistency, let alone predictability, independent tech firms have the luxury to pursue discovery. Discovery tends not to come from the mundane, and is amplified by creative freedom.

Which brings us back to the fundamental disconnect between Agile and the CFO. In corporate IT, the CFO isn't trying to solve a "make better use of capital" problem in the business. He or she is trying to solve a "consistent cash flow from operations to service our capital obligations" problem. When Agile goes corporate, it is subservient to, and most often compromised by, that latter problem.

In the final installment of this series, we’ll look at what we can do to make Agile IT appealing to the CFO, without compromising the core characteristics of Agile.

The Tech Bubble: A Cool Breeze in Blistering Times

Reading the headlines, tech is showing some signs of relaxing a bit.

• The first is a slowdown in corporate capital formation. Businesses hold record amounts of cash, but have nowhere to put it: a stagnant economy doesn't encourage investment for growth, while real interest rates on Treasurys are negative. Why raise more capital?
• Next are signs that captive IT spend is slowing amid general economic uncertainty in the US and Europe.
• Public sector austerity will reduce government spending on tech, softening demand further.
• Investment capital is also getting a bit tighter. Volatile equity markets don't make for the best of times to IPO. Also, market uncertainty has triggered a run for cash, depleting high-risk investments. That is cooling off venture backed businesses.
• Finally, H-P pulling the plug on WebOS devices (if not the OS) may portend an inevitable shakeout in smartphone & tablet platforms, while market battles waged with patents threaten to make innovation an early victim.

After setting such a blistering pace during the first half of the year, a breather isn't all together a bad thing.

But it is likely to be a short breather. The overall trend in tech remains inflationary.

Demand is still strong. Businesses are still spending on technology as a way to lock-in productivity gains to protect margins in a period of flat revenues. Business spending on software is forecast to increase nearly 10% this year. Smartphones and tablets are selling in copious volumes. Mobile as well as social media platforms are spawning new applications and new categories of applications.

Investment remains strong, too. M&A in the tech sector is back to pre-crisis levels. VC firms late to the game will add more froth to valuations. Some tech firms - encouraged by moribund investment banks - may still believe the time is right to IPO. Tech behemoths such as Oracle, Microsoft and Google are sitting on large cash piles.

There is also a sea-change in tech from hardware and services to software. H-P paid a juicy 78% premium for UK software firm Autonomy, and is shopping WebOS as a platform for automobile and appliance makers. H-Ps desire to reinvent itself as a software firm might portend The Great Software Pile-in, inducing other tech firms to migrate out of low-margin hardware and high-touch services in favor of highly-scalable software.

In a broader economy plagued by deflation, tech is still robust. A bit of capital tightening and demand slacking probably isn't a cooling off as much as it's just a cool breeze. Still, it's a welcome respite, particularly if it blows through tech labor markets. High labor costs don't just drive up development costs, they also make project rescues and bailouts that much more expensive. Any reduction in labor market pressure would make tech investments more resilient to failures, particularly important in a line of work notorious for spectacular ones.

Best of all, it would give tech leaders the opportunity, however brief, to adjust and reposition for another round of tech inflation.

Annual Budgeting and Agile IT, Part I: Why the CFO Isn't Impressed with Agile

I’ve been asked by a number of people recently how we can reconcile Agile IT, which shuns long-range deterministic planning, with annual budget & planning cycles, which are dependent on it. This 3 part series will look at the CFO's perspective on the business, the inherent conflict in IT investments financed through business operations, and what CIOs can do to decouple IT finance from IT operations.

Let’s look at things from the perspective of the CFO.

The CFO needs to be in front of a lot of things over the course of the year, notably earnings and cash flow. He or she wants as much future indication of what we want to spend and when we want to spend it, so he or she can determine how that spending will be financed: from cash already in the bank, from collections made throughout the year, through a short term credit facility, long-term debt, paid-in capital, or any of a number of sources of funds.

Businesses are held to specific reporting cycles, but not every month or quarter is going to be the same: businesses that are seasonal such as retail or cyclical such as railroads will go through longer spans of time before they know whether their forecasts about revenue prove true or not. Of course, many businesses are neither cyclical (most of the luxury sector seems immune to the fact that there is a recession) nor particularly seasonal (airlines spike with holidays and such, but revenues are consistent quarter-on-quarter). These businesses have far more immediate indication of the accuracy of their revenue forecast and collections. More frequent feedback might allow people in a company to reprioritize more frequently what they buy and how much they spend month-on-month, but CFOs of such firms will still err on the side of making decisions consistent with long-term expectations.

When operations are consistent in their financing demands, the CFO doesn’t have to crisis-manage the checkbook day-to-day; they can instead guide the business by getting in front of financing needs or investing opportunities. Clearly, it isn’t good if we spend money in anticipation of cash flow from future sales only for those future sales to fail to materialize. CFOs tend to not to like to go hat in hand to credit markets to raise cash, or immediately contract spending across the business. They particularly don't like having to answer questions from analysts during earnings calls about having needed to make such sudden changes, because it indicates those in charge of the business aren’t very capable at running it.

Consistency is particularly important for CFOs of capital intensive firms, companies with high asset value and a lot of equity or debt. The people who financed the acquisition of those assets will want to know that the firm earns more from what it does with the assets than the assets themselves are worth, and those to whom the firm owes money (such as bondholders) want to know that the company is going to be able to service its debt. The CFO is, in many ways, the voice of those who provide capital to the business, and has a fiduciary duty to them all.

The CFO perspective is also compounded by the fact that we are increasingly financing businesses with complex instruments to provide working capital and hedge risks. While this may reduce the cost of capital, complex corporate treasury operations leave the CFO with less time and less patience for cash flow from operations being inconsistent with expectations.

This isn’t to say that our numbers are locked for the year. We revisit the numbers every month and quarter But those numbers are still revised to a baseline, for the aforementioned reasons: e.g., we need to hit a target return to satiate bondholders or equity holders, we don’t want to overheat spend before our big revenue cycle in the event our forecasts are wide of the mark. Only if the business environment has completely changed – think about what firms in everything from retail apparel to investment banking did in Q3 2008 - will we throw out the baseline.

Banks make money by borrowing short and lending long. Most businesses follow the same pattern, using month-to-month cash flow (short) to meet the demands of the firm’s investors and creditors (long). This requires a very well oiled short-term cash generating machine to sustain the demands placed on the firm from their long-term financing. This is particularly obvious in firms that are highly leveraged e.g., where private equity has taken out money from a business by borrowing against future cash flows, and then sweating the business to maximize cash flow quarter-on-quarter. But this is true in any business beholden to outside capital.

Along comes the CIO with the good news that we're adopting Agile practices, which will do away with predictive planning and instead constantly re-scope and re-prioritize to maximize use of capital.

To a CFO, the prospect of financing captive IT operations that can only determine their financing requirements by muddling through is not particularly attractive. Vague financing requirements threaten to introduce volatility in financial demands of business operations. The CFO doesn't have a lot of tolerance for anything that could upset the tuning of the short (cash flow) / long (debt and equity) financing behind the business. Any short-term capital optimization the firm stands to gain from Agile is appreciated, but it pales in comparison to the long-term capital monster that needs to be fed.

If anything, the CFO wants greater certainty in operational forecasting so that he or she has one less thing to worry about. Not less.

Financing Agile IT thus has a steep hill to climb.

In the next part, we'll take a look at the conflict in financing day-to-day IT operations as capital investments.