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.

The Tech Bubble: A Deflation Scenario

We're in the middle of a much-anticipated wave of tech firms listing, and the valuations look a bit frothy. Pandora has 94 million subscribers but doesn't have advertising volume nor premiums to sufficiently monetize them. Groupon has cumulative losses in excess of half a billion dollars, churns 40% of it's paying customers (merchants) and has a high cost of entering new markets. LinkedIn characterized their modest profit as exceptional as they expect to post losses for quite some time, and they're still in search of a sustainable and sizable revenue mix. LinkedIn and Pandora are offering only tiny fractions of their equity (Groupon has yet to disclose the ownership stake they'll offer for the $750m they're seeking), raising governance and investor representation concerns.

These companies are still long-shots. There really isn't anything clever about giving away music at cost and being unable to find sufficient sponsors for doing so. Nor is there in churning 40% of the people who pay the bills. Growth has value but only if it results in a profit, for example, when market share secures long-term revenue stream. It's not yet clear how these firms will capitalize on that growth.

It appears the capital being raised is to be used for share buy-backs that enrich the owners rather than for investment into things that bring these firms into the promised land of profitability. While there's nothing wrong with taking a pay day for one's labours, it does send a signal that those behind the businesses are concerned that the "cusp of success" may be as good as it will ever get for these businesses.

Suppose reality isn't running a faster race than hype, and these businesses never find a way to make their subscriber volumes sustainably profitable, even marginally so. Valuations will turn sour, and tech will lose some lustre.

It isn't that hard to imagine. In the past few weeks, Chinese firms listed in North America have, as a group, fallen in value. Many Chinese firms engineered reverse-takeovers: purchasing publicly traded firms listed in North American markets. By doing so, they escaped the scrutiny applied to freshly-listing companies. Several of these firms, notably MediaExpress and Sino-Forest, have been publicly accused of fraud. These accusations have cast a pall over many Chinese firms that have listed in North America. In the same way, an implosion of just a few highly visible firms could very well have the same effect in tech.

Perhaps these newly-listed tech firms contain the seeds of their own destruction. LinkedIn and Pandora have been at it for a decade, yet still haven't cracked the revenue nut. Groupon's founders have a history of growing firms rapidly and taking money out through share buy-backs, only for the firm to hit the skids. In an investing climate characterized by excess liquidity sloshing about in risk-on / risk-off trades, valuations change rapidly.

Suppose a similar pall is cast over tech equities. What would it mean for tech businesses and captive IT?

It might depress capital raising, but if much of that is being done to enrich owners of unproven businesses, that's no loss. Limited tech share offerings to date means limited wealth depletion, a huge benefit given that households are still suffering from excess debt and substantial wealth erosion from 2008 peaks. All told, a tech sector cool down now would be a far less damaging economic event than the dot-com or housing market collapses of recent years.

Capital remains cheap. Assuming the US doesn't default on its public sector debt, markets should have sufficient liquidity without QE3. Tech is still in the throes of a long renaissance with tablets and smartphones (new capabilities) twined with cloud (cheap infrastructure). Cheap, abundant capital and emerging, highly visible technologies suggests that a tech equity collapse wouldn't be particularly harmful to innovation or the willingness to spend on it.

It would be especially good news for captive IT, and particularly for tech services firms. Tempered enthusiasm would cool off the tech labor market, which is overheated. This would be good for captive IT in that it reduces sector inflation. It would be particularly good news for tech services firms: as tech demand remains strong, reduced labor costs will improve margins.

The most anticipated listing - Facebook - may never happen. Even without listing, it's still the 900 lb gorilla in the tech sector. For example, LinkedIn is seen by many as a proxy for Facebook because it gives exposure to social networking. Facebook therefore has a significant impact on financial markets, even though there is no sign that the company intends to list. Imagine what would happen in markets if it did: Facebook would be the tide that lifted all tech boats, and the bubble would expand that much further.

Which makes the case that it wouldn't be all together bad for the tech bubble to burst right now. Bubbles are best burst when small.

Microsoft and Skype: The Business Value of Protecting a (Cash-Gushing) Utility

Microsoft's acquisition of Skype generated a lot of comment this week, much of it negative. As an investment, Skype has to put up some pretty juicy numbers to justify an $8.5b valuation. Reuters Breakingviews pointed out that the price is 400 times Skype's operating income last year. To achieve an annual ROI of 10%, Skype has to grow 40-fold. Heady numbers, to be sure.

But the Financial Times Lex column took a contrarian view, presenting the acquisition as a defensive manouever intended to protect the core Microsoft business. The argument goes like this. Microsoft buys Skype to protect the core Office / Windows franchise. E.g., if Google or Facebook bought Skype, they would be closer to assembling a suite of products that would shake users loose from Office & Windows. According to Lex, this isn't a "value-add" acquisition for Microsoft but a "protect the business" move.

And Microsoft will spend a lot to protect that business. In that light, the numbers that matter are vastly different. Microsoft throws off $3/share of free cash flow. That's a lot of cash. It's a cash flow yield of 11%. This acquisition barely makes a dent in that. Do one of these deals every 3 years and the cash flow yield drops only marginally, to 10%. That still qualifies Microsoft as a cash machine.

Lex sums it up nicely:

"What investors are actually getting is a very profitable unregulated utility that must spend freely to keep its core business running. ... Of course, this all assumes that these acquisitions succeed in protecting the core business. But that business is so lucrative, it's worth a shot."

This makes clear three very important lessons in tech investing, be it developing custom software or acquiring a technology firm.

First, not every dollar of business value is the same. We do some things to increase revenue. Some to create efficiency. Some to force competitors to react, to spend money they wouldn't otherwise spend and potentially mis-step. Some things we do are insurance policies to protect ourselves should some event happen. Still others - and perhaps Microsoft's acquisition of Skype is an example of this - are purely defensive, to prevent something from happening. The "value" of preventing an outcome is not the same as the "value" of adding a dollar of revenue or the "value" of sweating a dollar of cost out of business operations. Clearly, "business value" decisions are not so neatly interchangable.

Second is Lex' description of Microsoft as an "unregulated utility". Office suites and operating systems with GUIs were once the "killer apps" for personal computers, but they've become utilities, like water, electricity or retail banking. There's nothing wrong with being in the utility business. Utilities are important. The added benefit of having no regulatory burden to satisfy makes a tech utility a lucrative one indeed. But again, as the Lex analysis points out, the management, economics, and risk profile of a utility are not the same as those of a value-added investment.

Finally, Microsoft's acquisition of Skype might be wildly successful on its own merits: perhaps Skype increases their reach, or achieves a monetizable synergy with other Microsoft offerings. Or it might not: the numbers may never materialize, and Skype fades into irrelevancy. (By way of example, consider that Microsoft Live Messenger has a larger active user population than Skype and offers voice & video calling, yet is not relevant in the current social media / tech bubble.) Regardless the outcome of the investment, the counterfactual - what would have happened had another firm acquired Skype? - is unprovable. Maybe Microsoft has stolen Google's thunder here, and maybe they haven't. We'll never know. 'Twas ever thus with business decisions: their outcomes are unpredictable and, sometimes, their impact unverifiable.

This episode offers us critical insight into the business of technology. Every time we make a prioritization decision in IT - from each investment we add or divest from our portfolio, down to each feature we include or exclude in a project - we must recognize that context is everything. We must also continuously reassess the business rationale - as well as our institutional fortitude - to stay the course of each investment.

The Tech Bubble, Four Months In

Earlier this year, we looked at the boom in the US tech sector and what it means for people running tech businesses and captive IT. Four months later, the tech sector has gained momentum. Buyers and sellers of tech services must deal with rising costs and tighter margins, respectively. This is a function of tech wage inflation (Google's 10% across the board pay increase is indicative of this) and increased recruiting and retention pressures (tech employees offered career advancement with other firms).

This is a far cry from where the tech sector in the US was just 3 years ago, so it's worth looking at the near-term durability of the tech sector bull market.

US corporate spending on tech is at its highest since 2001. This is being driven by extraordinarily high corporate profitability and a surge in US manufacturing. This, in turn, is being fueled by a cheap US currency. Meanwhile, the tech investment frenzy continues, with Silicon Valley venture capital fundraising up 76% in Q1 2011 from a year earlier. The demand for tech is very robust.

There are a number of things on the horizon that might affect this. But are any of them serious threats to tech?

• QE2 ends in June, but even without a QE3, there is no shortage of liquidity.
  Sufficient liquidity means there's ample high risk and low risk capital, a lot of which will find its way into tech.
  
• Interest rates can only go up, but they don't look to be going up soon. For one thing, US inflation is being sanitized by high US unemployment. For another, US house prices remain moribund. An increase in interest rates will chase buyers and create more downward pressure on housing.
• The US fiscal future is being debated. S&P rattled sabers by issuing a negative outlook for US Treasurys, but the bond market largely ignored it.

What this means is that in the absence of a seismic event, the tech sector bull market does not have to cool off any time soon.

Now, like anything else, tech is a fickle business. Even if all these things turn out to be true, US tech faces its share of risks.

• A US currency rebound. This could be caused by any number of factors. For example, Greek sovereign default would weigh on the Euro, which could have the effect of driving money into traditional safe haven of US Treasurys, stimulating dollar purchases. The stronger dollar cuts US exports, which cools the US economy.
• Signs of US inflation or bond market vigilantes cause Fed to increase interest rates. An increase in rates will likely cool business investment, which will slow tech spending.
• Failure from within the tech sector itself. Those cartoonishly high valuations don't pan out for one reason or another (e.g., eyeballs don't convert to revenue) and we get another round of dot-bombs.
• Tablet/smartphone revolution fails to live up to it's hype. One critical difference between today's mobile revolution with that of personal computers and the mainframes/minis they displaced was that you can code solutions for a PC on a PC. You can't code solutions for a smartphone on a smartphone. Subserviating the mobile device to the PC could unintentionally impair solution design: by being preventing smartphones from being truly independent devices, their evolution could be stunted. (Which raises the point that perhaps Motorola is onto something with their ATRIX product, but that's another blog post for another day.) Also, tablets are fantastic output devices but they're still not brilliant at input. The point is, if tech underwhelms in the short term - much as home computers failed to live up to their hype in the early 1980s - the tech sector will cool until the capabilities emerge.

Of course, there are many more risks, most of which may not be obvious now but any of which will seem clear as day after the fact.

In the meantime, tech's bull market credentials don't look to be at risk for now. For the tech exec, that means expecting supply constraints and inflation in labor and services to last for some time.

Corporates and Start-Ups: Casual Friends, not Soul Mates

An executive of a corporate behemoth wants to shake up a troubled division. Being both impatient and aggressive, the executive hires somebody with a few start-ups under their belt - or acquires that person's current business - with the intent of having them take over the troubled unit to deliver start-up-like results.

While it looks like a way to inject new strands into the corporate DNA, it may do little more than play kick the can the can on the problem. It might also inflict further damage on their troubled business.

Start-up entrepreneurs do well in the early stages of a corporate turnaround situation: it's not difficult to get some sparks of life from a situation left for dead. A remit to "fix the department" gives license to change relatively obvious things that had left previous leaders immobilized.

Unfortunately, the rate of miracles declines after the first few months and with it the lustre of the miracle worker. The easy changes are made all too quickly. It isn't long before all remaining options require heavy lifting. And heavy they are: untangling a large, messy business requires broad, systemic, fundamental change.

This brings the parachuted entrepreneur face-to-face with their commitment to their adopted team: they didn't hire the people, they had no say in the technology, they're unable to innovate (drowning in problems as they are), they're immersed in corporate overhead they consider a nuisance, and they get nothing but resistance and obstinance from their peers. The mission turns out to be different than it first appeared to be: success requires them to be change leaders, not just execution leaders. This is not what they signed up for: they were told to infect the corporate DNA, yet now they face infection themselves.

This is a big commitment wall to climb.

Some choose to climb it, trading small start-up for large firm. It has been my privilege to know and work with several people who have successfully made this change - with some later reverting to their start-up roots. But for many start-up entrepreneurs the thought of settling in for a long-haul turnaround in a large corporate is not terribly appealing. The most self-aware redefine their mission to make the situation less bad, which is not the same as making it brilliant. They'll steer it through rehab, bringing it to the threshold of the long path of becoming a better corporate citizen, bowing out to let other, more corporate types, take it from there. In effect, an uncommitted person will make the business less unattractive, and flip it to somebody else.

The worst case scenario is when an uncommitted entrepreneur doubles down on trying to make the corporate into a start-up, focusing on immediate outcomes at the exclusion of everything else. This leads to long-term damage because systemic problems are starved for investment, displaced by tactical spend in the mad pursuit of getting something - anything - done. After a few months, people lose the appetite to fix the root problems, having gorged at the feast of the proximate problems and finding themselves out of money, out of energy, out of faith, or out of time. They finish a few sprints, but get nowhere near the finish line of the marathon.

This happens because the things that work in a small start-up tend not to have profound success - and in fact, can backfire badly - in large corporates. Start-ups are guided by a few principles, corporates by voluminous rules. Start-ups are able to rapidly evolve; large corporates move more slowly and deliberately. Start-ups have the luxury of being able to focus on how they start: because of their dynamic nature they may re-start a dozen different things a dozen times each before they finish one thing. A large corporate does not have this luxury: it has too many people, too much specialization, too many geographies, too much low-bandwidth communication. To succeed at anything, the large corporate must concentrate fully on how they finish.

Small start-ups are great at creating things with only intellectual brilliance, time, and a few packages of crisps. But accustomed as they are to shoestring budgets, they rarely manage excessive investment wisely because few can conceive the strategic. Modifying a line from The Simpsons: "the start-up with money is a bit like the mule with the spinning wheel: nobody knows how he got it and dang if he knows how to use it." Survivor bias (firms such as Facebook) leads us to erroneously believe in outsized probability of start-up success. Flashes of tactical brilliance can produce some one-hit wonders (remember when flying toaster screen savers for Windows 3.1 were all the rage?) But the fact is that the start-up that matures into an independent, sustainable success is the exception, not the rule. As a friend of mine who has been CFO for several tech start-ups once pointed out, his prior companies went from being voluminous independent websites to a few bullet points on the website of their acquirer. Start-ups can generate enormous potential, but generally that potential is realized by others.

Pharmaceuticals are a case-in-point. Big pharma firms have large scale manufacturing, distribution, marketing and sales. As the pipeline of blockbuster drugs have dried up, they've dismantled their captive R&D while simultaneously entering high-volume generics. They haven't given up on R&D, they've outsourced it to small start-ups: when a start-up pharma produces a promising drug, big pharma firms enter a bidding war to buy it. Although the winner might over-pay for a specific firm, they'll spend less on R&D as they don't subsidize the failures. Big provides the scale, little provides the creativity, each in their respective corners.

This is not to suggest that corporate bloat is acceptable, that small start-ups are poor businesses, or that start-up entrepreneurs never succeed in corporate environments. It is to say that corporates and start-ups make good casual friends who can share the odd sweaty evening together, but should suppress any thoughts of marriage. The honeymoon ends quickly, the arguments are legion, divorce comes all too soon and the rate is all too high, and their offspring are more likely to have the corporate's obesity twined with the start-up's ADHD.

But what if you're an executive in a large corporate with an under-performing division that begs for an entrepreneurial spark? Recruit a courageous leader with an entrepreneurial streak, someone with the temperament to orchestrate comprehensive restructure while fostering innovation and inspiring people to act, with the self-awareness to realize that the mission is one of change leadership, not simply execution brilliance. Lou Gerstner did it at IBM 20 years ago. Perhaps Stephen Elop will do it at Nokia.

You may very well find that person in a start-up. Just remember that you're hiring the person, not the environment from whence they come.

Sprint's Marathon

There's been a lot of public hand-wringing at the proposed AT&T / T-Mobile USA merger, particularly with regard to Sprint. Sprint is a distant third in subscribers today, but this is a very dynamic market. Today's subscriber count may not be relevant to tomorrow's.

First, most mobile subscribers aren't bound to a network. While a post-merger AT&T/T-Mobile and Verizon Wireless would have most of the customers, there are no switching penalties for long-term handset contract customers. On top of it, many of those subscribers are not using smartphones, but ordinary handsets; little amounts of data trapped in those handsets also means low switching costs.

Second, the mobile platform field is about to get very crowded with RIM (new tablet, vigorously fighting an erosion of their smartphone business), HP (WebOS), Windows Mobile, and Nokia possibly retaining MeeGo for tablets. Along with Apple and Android, that makes as many as 6 different mobile computing platforms. They're each spending billions in pursuit of this market. None of them want to finish in 6th place.

Third, hardware competition is increasingly fierce. Motorola is smarting from losing pride of place in the Verizon stable of offerings, having been displaced by Apple. Nokia needs to protect sales of existing devices while placing their future line of Windows Mobile devices.

While the name of the game is scale, these dynamics suggest it's not a mature market share game for the networks yet, as much as they're caught in the middle. On the sell side, those hardware and platform vendors late to the party are especially motivated sellers. On the buy side, first time smartphone buyers - the market everybody is slugging it out for - have low switching costs, while first-time tablet buyers will be more price sensitive than the first movers.

Being in the middle isn't all together a bad thing, as it means opportunities for organic customer growth. That offers a less expensive alternative to growth through M&A, something to which Deutsche Telecom (Voicestream), Sprint (Nextel), and Verizon (the primary beneficiary of customer defections in the wake of the Sprint-Nextel merger) can attest.

Which brings up Sprint in 2011. Data hungry devices should perform fast and reliably on WiMAX. With a low subscriber base, there can't be as much competition for Sprint's bandwidth as there is for customers on AT&T and Verizon networks. As a means of getting customers hooked, that alone might be attractive to platform and hardware providers. Perhaps Messers Elop and Ballmer do a deal with Sprint because they believe networks are integral to their "3rd platform" strategy. Perhaps HP, more US centric in their mobile offering than the rest of the field, sees the same. Or perhaps hardware and platform vendors going all out in a market share game will find Sprint an attractive channel through which they can provide hardware on the cheap without appearing to be the solution of little value.

If true, this makes the networks more spectator to the action than central to it. For Sprint, that makes it a marathon.

The Tech Bubble, One Month In

In the month since I blogged that tech looks like it could be in a bubble, there have been plenty of headlines to suggest that it is:

• Jonathan Weil/Bloomberg: Cupcake Capitalism Offers Hope for New Bubble
• Robert Cyran/Breakingviews: Web bubble 2.0?
• Dennis Berman/WSJ: "Cartoonishly high valuations" for tech firms
• And just today, the WSJ ran a story titled Twitter as Bubble Barometer

A rise in interest rates will throw a little cold water on the tech fire. Writing in Breakingviews, Martin Hutchinson points out that low rates make capital spending attractive, but capital investments made to improve productivity (e.g., business investment in technology) stifles business hiring. He goes on to explain that the contrary is also true: when capital is more expensive, hiring becomes more attractive than investment. Interest rates may rise for any number of reasons, not the least of which to stifle inflation which may very well be on the rise. When they do, business preference will gradually change from productivity investments to hiring. It behooves the tech exec, particularly in captive IT, to pay close attention to what the Fed does.

Tech firms, particularly start-ups, are less vulnerable to a rate rise than captive IT. As Robert Cyran points out in Breakingviews, the tech entrepreneur calls the shots these days as cloud technology allows the tech firm to rent, as opposed to own, sophisticated infrastructure. This makes tech far less capital intensive. If anything, as Mr. Cyran notes, tech firms have just the opposite problem: excess capital desperately seeking yield is trying to find a way into tech, only to find tech has little use for it. When liquidity declines with QE2 expiry (provided there's no QE3), tech valuations may decline, but tech firms are less likely to suffer from financial starvation.

Not so captive IT, which still owns more than it rents, and thus remains very capital intensive. Last month I mentioned that the tech exec should sweat their revenue. Interest rates are a leading indicator of revenue durability, particularly for captive IT. Know your firm's cost of capital, and know the yield of those tech investments in your stewardship, and you'll know how resilient your revenue is to Fed decisions.

The Tech Sector: Bull, Bubble or Both, and What It Means for IT (Part II)

In the previous post, we took a look at market factors that suggest the technology sector could be on a multi-year bull run, in a bubble, or possibly both. In this post, we'll look at what that means for leaders of captive IT departments and tech firms.

---

If tech is in a bull market or bubble, it means inflation and volatility for a lot of tech businesses and captive IT shops.

Lets look at inflation first.  Excess liquidity fueling a lot of tech companies will create a lot of tech jobs. So will tech investments made by traditionally non-tech firms (e.g., automakers and appliance makers are all in the software business now).  Despite all the progress in global sourcing, labor and jobs aren't universally mobile.  This means that demand (jobs) may outstrip supply (candidates) in specific markets.  When that happens, prices (wages) tend to rise. It's reasonable to expect that salaries and tech are going to inflate.

But inflation takes many forms.  In this case, a bull market for labor will inflate career paths.  When there are more jobs than people, hiring standards tend to decline.  Availability becomes a skill for candidates. This leads to people being over-promoted to fill vacancies, which creates misplaced expectation of competency.  It is just as bad for the hiring firm as it is damaging for the person hired. The more a business hires, the poorer it will perform, the more vulnerable it becomes.  Employees will find themselves in roles or on career paths for which they have few qualifications.

Inflation begets volatility.  When there's both wage and title inflation afoot, firms are likely to see higher staff turnover.  While a little staff change isn't inherently a bad thing, no firm wants to be desperately trying to fill positions in a job market where job seekers have the upper hand.  Staff volatility will obviously impair operations as situational knowledge erodes along with it.

Bull markets and bubbles create volatility of commercial technology.  New technologies such as tablets or rapid replacement markets such as smartphones are contests for market share of new units sold.  A large installed base of legacy customers isn't as valuable as costs of change are relatively low.

Bubbles, though, tend to amplify the effect of volatility with a sharp correction.  Tech marketplace battles can go on for a long, long time, especially when it's a market share game with high customer turnover.  Don't under-estimate the power of the sell side to buy customers, particularly if the sell side has deep pockets laden with investor capital.  Don't underestimate the stars buyers get in their eyes with the idea that they'll be able to get some slick tech capability unique to their business.  And don't underestimate the value-added resellers, custom appdev shops and other middle-men who will willfully exchange the hard money earned by being little dogs in the mainstream for the easy money that comes with being big dogs on the fringe.  The 1980s and 90s saw a lot of fringe technologies carry on for far longer than was economically justified. Investor cash - sometimes it's just excess liquidity, other times it's just dumb money - fuels the party. The longer this cycle perpetuates, the bigger the bubble inflates, the more severe the correction when the money runs out.

Bull or bubble, this will place a lot of demands on tech execs. What can you do?

Create resiliency in your staff.  Get in front of tech inflation by setting expectations with the CFO and head of HR. Reduce the risk of exit of key people and create broader bases of knowledge (less specialization, more generalization).  Recognize that it's one thing to fend off competition with other firms for staff you have, it's entirely another to have your staff poached by headhunters or former employees.  Be hypersensitive to staff targeting and have a plan at the ready (agreed already with the CFO, HR and key partners) should you need to aggressively retain.

Be creative in evolving relationships customers and suppliers.  Inflation and volatility will strain relationships between sell side and buy side, particularly between captive IT and tech services.  A lot of relationships became genuine partnerships in 2008 as firms found creative ways to sustain contracts and projects in what were difficult times for everybody.  But as the economics change in favor of the sell-side, the relationship dynamics will change, too.  Sell-side firms will pass salary increases to customers.  Loss of key people in delivery or relationship roles will reduce customer confidence.  Benevolence and capitulation are rarely rewarded, but creativity is.

Hedge your technology exposure. Take nothing for granted (remember that CP/M was going to be the dominant OS for microcomputers, until it wasn't), and pursue opportunities on alternative platforms to hedge your portfolio of business partners and revenue.  A little exposure to what looks like a short-play platform may provide outsized benefits if the supplier succeeds or if it brings you some long-term customer relationships.

Finally, whether you're a sell-side exec or a CIO, sweat over the durability of your revenue and funding.  Look for risk in your book of business.  A customer or business sponsor prepared to invest in something today may suddenly have that funding cut by mid-year.  For example, a tech services firm doing business with a bank that holds a lot of assets that suddenly turn sour (contracting liquidity and threatening solvency in the process) may find allegedly strategic projects suddenly cancelled. We still face these risks: recall that Irish banks passed the European stress tests in the summer of 2010, only to require recapitalization before the year was out.

When tech is on the rise, it makes everybody in the sector a little more optimistic about the future: new technologies, new career challenges, and a bit more money in the bank. But a rise in tech could put the squeeze on the businesses we run. We would do well to temper our optimism with the pragmatism that there's no such thing as a free lunch.

The Tech Sector: Bull, Bubble or Both, and What it Means For IT (Part I)

There's been a sea-change in the technology sector, from counter-cyclical to pro-cyclical.

Tech, and especially tech services, went counter-cyclical a few months into the last recession (2008). Companies entered the downturn with record levels of cash. With so much uncertainty, most firms didn't bet on expansion. Instead, they elected to preserve cash rather than deploy it, and slashed payrolls to cut operating costs. Cutting payrolls meant firms needed to get the same work done with fewer people, so they spent modestly on IT to increase productivity. As a result, tech, and in particular tech services, has been counter-cyclical to the broader economy for most of the past 2 years. This created modest inflationary pressures in IT, notably on wages, but those were kept in check by the deflationary cycle affecting the host businesses. On the whole, tech went through this recent recession much as it did the 1995-6 recession.

But tech is becoming pro-cyclical. The success of both tablets and smartphones (and to a lesser extent the fringe battlegrounds of e-readers and other specialized devices), as well as the rapid maturation of cloud-based services, has created a tech hardware war, an OS war, a bidding war for tech firms, and spawned a feeding frenzy in application development. This is happening during a period of excess liquidity (a result of Quantitative Easing, low borrowing costs and other loose monetary policies), and low yields on most investments. Put simply, there's a lot of money in search of yield.

A lot of that money is now coming into tech, because tech offers investments with the potential for high yield. Or, more crassly, tech offers "gambling opportunities" for investors. This means the money coming into tech has changed from "we're investing in tech to reduce operating costs" to "place your bets on tech!" This, in turn, is changing the tech space from counter- to pro-cyclical. That's great during a bull market, but painful during a bear market.

There's no certainty of how this will play out. This could simply be the next stage of what may be a multi-year bull run for tech, similar to its 1983-2001 bull run that had several mini-cycles. It could be a bubble, with too much cash chasing more yield than will materialize. It could be both: a bit of excess euphoria during what is otherwise a fundamentally strong bull run in tech.

Such euphoria in any sector tends to come with little in the way of popular recognition of what's behind it, and mass underappreciation for how vulnerable it is. We saw this in the housing bubble, the internet bubble before it, and bubbles going back to the Dutch Tulip trade in the 17th century. But this sudden rise in tech calls for as much caution as enthusiasm. This is true particularly for those who are long tech (e.g., those building wealth by building companies and careers in it) more than those who are comparatively short (those investing capital in pursuit of yield). While investors can be burnt by a bubble, careers can be wrecked.

One of the things that makes tech a potential bubble now is the resilience of that capital coming in. Capital has stayed largely on the sidelines for the last two years because of so much economic uncertainty. That capital, while being deployed now, is still jittery and remains at risk of systemic shock. Problems lurk in peripheral Eurozone debt, US housing debt and US muni debt. China and India are fighting inflation while the US is trying to stoke it. The net effect is, capital is still highly nervous. It's also highly mobile, as evidenced by the volatility of many different asset classes in 2010. Tech can take no capital placement for granted: what the capital markets giveth tech, they can just as quickly taketh away.

As tech has gone pro-cyclical, it will rise and fall with the broader market. Those peaks and valleys will be amplified by the amount of capital coming in. If the broader market is characterized as "volatile" in 2011, tech could be in for a wild ride.

In the next post, we'll look at the different ways volatility manifests itself in tech. We'll also look at what a tech boom, and potential bubble, means for people leading and managing captive IT and tech firms.

Heathrow Mess is Explained by Taleb

Like many thousands of other people, I was forced to stay in London for an extra few days because weather-related factors caused Heathrow and other UK airports to close. Nearly a week after it began, thousands remain stranded.

Most analyses of why this happened have looked at how supply-side factors such as additional snowplows or seat capacity on contract could lessen the impact of an event like this. Hugo Dixon, writing in Reuters Breakingviews, suggested that a better demand management mechanism - one that creates a more efficient market for seat demand under circumstances where seats are at a premium - is just as important to consider.

I took a different perspective, which Breakingviews was kind enough to publish. Here's the abstract and a link to my letter:

Heathrow mess is explained by Taleb.
Europe's main airport is a highly inefficient market with poor and asymmetric information. Snow turned it from a utility to a casino. This wasn't a Black Swan event. But it reflects Taleb's argument that optimized systems are vulnerable to catastrophic failure.

Vulnerability to catastrophic failure makes abundantly clear we would be better served by demanding and rewarding robustness over optimization, especially from utilities.

Regulatory Capture and IT Governance

Industries are regulated by governments so that companies don't compromise the public interest.  Regulatory agencies usually grab headlines because most regulation comes in response to nefarious actions, but it isn't always the case: people in a company may conduct their affairs in what they believe to be a perfectly justifiable manner, only for there to be unintended consequences of what they do to consumers or society.  

In the same way, we have governance within businesses to make sure that management doesn't compromise the interest of investors.  And just as it is with businesses in a regulated industry, management of a well-governed business may have a set of priorities that are perfectly justifiable in management's context, but are orthogonal to investor's interests.

Industrial regulation and business governance are both poorly understood and poorly practiced. Each is also easily compromised. John Kay provided a fantastic example of how easily governance is compromised earlier this month in the FT, describing a phenomenon he referred to as "regulatory capture":

Regulatory capture is the process by which the regulators of an industry come to view it through the eyes of its principal actors, and to equate the public interest with the financial stability of these actors.

Let's think about this in the IT governance context.  We may have good governance instrumentation and a governing body that meets consistently.  But it's still easy for our governance infrastructure to be co-opted by the people it's supposed to be governing.  Mr. Kay explains how:

[T]he most common form of capture is honest and may be characterised as intellectual capture. Every regulatory agency is dependent for information on the businesses it regulates. Many of the people who run regulated companies are agreeable, committed individuals who are properly affronted by any suggestion that their activities do not serve the public good. ... It requires a considerable effort of imagination to visualise that any industry might be organised very differently from the way that industry is organised now. So even the regulator with the best intentions comes to see issues in much the same way as the corporate officers he deals with every day.

In IT governance, management provides and frames governance data.  Overtly or covertly it imposes structural limitations on the presentation of that data.  People in governance roles are all too often lulled into a sense of complacency because integrity of the messenger - management in this case - isn't in doubt.

Yet one of the most critical expectations we have of people in governance roles is that they have a broader picture than management of what should be happening, and how it should be taking place.  Perhaps management doesn't want to look bad, or they're not comfortable delivering bad news.  And all too often, management can do no better than to play the cards they're dealt (e.g., people, scope, technology or something else).  Whatever the underlying situation, we need a governing body that doesn't look at the cards in hand, but at the cards they can get out of the deck.  There's no mechanical process that enables this; it all comes down to having the right governors.

Which leads to Mr. Kay's next point, where he provides some important insight into the characteristics of a good regulator that are very much applicable to somebody in an IT governance role:

You require both an abrasive personality and considerable intellectual curiosity to do the job in any other way.

IT governance requires activist investors: people who will ask challenging and uncomfortable questions, reframe the data provided by management, and propose completely different solutions. This is a specific behavioral expectation, and a high one at that.  But, as Mr. Kay points out:

[T]hese are not the qualities often sought, or found, in regulators.

Sadly, this is all too true for IT governance as well.  

The value of governance is realized by its professional detachment. Whether you're recruiting a board for an IT investment or evaluating the people you have in one today, think very hard about their ability to act independently.

Restructuring IT: First Steps

In this last post in the series on restructuring IT, we'll take a look at some things we can do to get going on a restructure.

The place to start is to establish a reason for restructure that everybody inside and outside the organization can understand. Tech is inherently optimistic, and we have short memories. As a result, we don't have very good self awareness. So it's worth performing a critical analysis of our department’s success rate. That means looking at how successful we are at getting stuff into production. What is our batting average? How does it stack up against those Standish numbers? But it isn't enough to look at the success of delivery, but the impact. Is there appreciable business impact of what we deliver? Is the business better because of the solutions we put in production? These questions aren't so easily answered because IT departments often don't retain project performance history and we very often don't have business cases for our project. A critical self-assessment, while valuable, may not be all that easy to perform.

Of course, the point isn't just to assess how we have performed, but to look at how ready we are for the future. What will be expected of us in 2 years? What business pressures will build up between now and then? How ready are we to deal with them?

To properly frame performance, we need to have a very firm definition of what “success” means. I worked with a firm that had a very mature phase-gated governance system. With maturity came complexity. With complexity came loopholes and exceptions. Whenever a project was at risk of violating one of the phase gates such as exceeding rate of spend or taking too long, somebody would invoke an exception to change the project control parameters to prevent the project from defaulting. As a result, they could report an extraordinarily high rate of success – upwards of 99%. But a 99% success rate of changing the problem to fit their reality is a dubious record of achievement.

In addition to scrutinizing results, take a look at the top 5 constraints you believe your IT organization faces today. Of those top 5 things, very likely most (if not all) will be rooted in some behavioural mis-alignment with results. One quick way to get the contours of the impact of these mis-alignments is to bring business and IT people into a short, facilitated workshop to focus on the mechanics of delivery. This will reveal how people react to those constraints (working within them, working around them, or doing things that reinforce them), and subsequently the full effect that they have on delivery.

Finally, get a professional assessment of your organization, looking at the behaviours and practices behind what gets done and what doesn't get done. It’s also important to engage business partners in this process. While we very often find IT organizations that are being outpaced by their business partners, it’s been our experience that with a little bit of concentrated effort, it doesn’t take much for IT to outpace its host business. That isn’t healthy either. Ultimately, we need a firm peer relationship between the business and IT, so we need to engage business partners in this process. We’re looking to create a symbiotic relationship so that responsiveness is both mutual and durable.

Doing these things will give you the classic look in the mirror, a critical assessment of the "lifestyle" decisions that your organization is making today. That will allow you to speak in firm facts of why the organization needs to change, set the bar for what is acceptable and what is not, and define a target and a set of action items that will create change.

One parting thought.

I hope this series on IT restructure has crystallized some of the thoughts and experiences that you have had as an IT professional, that this gives you perspective on the impact of industrialization on the IT industry, particularly in the people you interview and the skills and experiences they have.

Hopefully, you’ll go back to your office and think, “yeah, I remember being in a team of professional workers, and now I’m with industrial workers.” And you might think being the lone change agent is too much. Maybe if you were more senior, you could pull it off. But as a [insert your title here], you just don’t feel you can pull it off.

Quick story to tell about a securities firm I worked with. Some years ago, the CIO was dev lead of a dozen-person team that created the next gen platform for their trading operations. He now had 2,000 people in NY and India and wondered, “why is it so difficult to get things done around here.” He stepped into a conference room at one point where he'd sequestered the team and got a bit misty-eyed about “the good old days.” Here’s the guy running the IT department - in fact, he created most of it - feeling that same sense of frustration with the industrial model. And, ultimately, he felt trapped by it.

This is coming from the CIO.

The frustration is there, from top to bottom in IT. The people to make change are the people who recognize the difference between industrial and professional IT. It will take time. It will take a lot of convincing and explaining. But it’s there to be done. The time is now. And you’re not alone.

Restructuring IT: Guiding Principles

This is a continuation of a series I left off in December 2009 on Restructuring IT. This post presents a few guiding principles to understand before undertaking a restructuring exercise.

First, don't fool yourself about your ambitions. Come to grips with what you think you want to be: a demonstrably world-class organization, or just less bad at what you do. The prior is easy to say but hard to achieve. If you're wed to any aspect of your current organization, if you think process will make your business better, or if you're concerned about making mistakes or losing staff, you're really no more ambitious than being less bad. There's nothing wrong with that. Minor restructure can have a beneficial impact. Just don't mistake "sucking less" for "software excellence".

Second, be aware of your level of commitment. Change is hard. As liberating an experience as you hope it will be, the people in your organization will find restructuring invasive, divisive and confusing. Some people will resist, some will revert. Some will exit of their own volition, and some you'll have to invite to leave. Change is tiring and frustrating. Staying the course of change through the "valley of despair" requires a deep personal commitment, often in the absence of compelling evidence that the restructure is going well and frequently against a chorus of voices opposed. Fighting the tide is never easy, even from a leadership position.

Third, don’t expect that you’re going to restructure with tools, training and certification. That won’t change behaviours. If you believe change comes about through tools and training, you should release 80% of your staff and hire brand new people every year: just put them in training and give them tools to run your business. Of course you wouldn’t do that, because you’d lose all the experience. So it is with this restructure: you’re developing new experience. Tools can make good behaviours more efficient, but tools alone don’t introduce good behaviours in the first place.

Finally, be less focused on roles, titles and hierarchy and focus instead on what defines business success and what actually needs to get done to achieve it. Tighten up governance scrutiny to verify that people are working to a state of “demonstrably done" and not just "nobody can tell me I'm not done". And prioritize team over the individual. Don't privatize success while socializing failure: incentivize the team, not each person. People focused on a team accomplishment are less concerned with individual accolade. Culturally, make clear that an outstanding individual performance is a hollow (and dubious) victory in a failed team.

The final installment in this series will cover some immediate actions you can take today to restructure.

One-Way Risk and Robustness of IT Projects

Writing in the FT's Long View column, James Mackintosh makes the point that hedge fund managers “appeared smarter than they really were, because they were taking a risk they did not recognize.” That’s an apt description for a lot of what goes on in IT, too.

Despite all of the risks that commonly befall an IT project, we still deal with IT planning as an exercise in deterministic forecasting: if these people do these things in this sequence we will produce this software by this date. The plan is treated as a certainty. It then becomes something to be optimized through execution. As a result, management concerns itself with cost minimization and efficiency of expenditure.

Trouble is, an operations plan isn't a certainty. It's a guess. As Nassim Taleb observed in Errors, Robustness and the Fourth Quadrant:

Forecasting is a serious professional and scientific endeavor with a certain purpose, namely to provide predictions to be used in formulating decisions, and taking actions. The forecast translates into a decision, and, accordingly, the uncertainty attached to the forecast, i.e., the error, needs to be endogenous to the decision itself. This holds particularly true of risk decisions. In other words, the use of the forecast needs to be determined – or modified – based on the estimated accuracy of the forecast. This, in turn creates an interdependency about what we should or should not forecast – as some forecasts can be harmful to decision makers.

In an IT project context, the key phrase is: “This holds particularly true of risk decisions.” We take thousands of decisions over the course of an IT project. Each is a risk decision. Yet more often than not, we fail to recognize the uncertainty present in each decision we make.

This comes back to the notion that operations plans are deterministic. One of the more trite management phrases is “plan your work and work your plan.” No matter how diligently we plan our work in IT, we are constantly under siege while “working our plan”. Developers come and go. Business people come and go. Business needs change. The technology doesn’t work out as planned. The people responsible for the interfaces don’t understand them nearly as well as they believe they do. Other business priorities take people away from the project. Yet we still bake in assumptions about these and many other factors into point projections – as opposed to probabilistic projections – of what we will do, when we will be done and how much it will cost.

Our risk management practices should shed light on this. But risk management in IT is typically limited to maintaining a “risks and issues” log, so it’s never more than an adjunct to our plan.

That most IT projects have only rudimentary risk management is quite surprising given the one-way nature of risks in IT. One-way risks are situations where we have massive exposure in one direction, but only limited exposure in another. Taleb gives the example of trans-Atlantic flight times. It’s possible for an 8 hour flight to arrive 1 or possibly 2 hours early. It can’t arrive 6 hours early. However, it can arrive 6 hours, or 8 hours, a day or even several days late. Clearly, the risks to flight duration are substantially in one direction. IT risks are much the same: we may aggressively manage scope or find some efficiency, but by and large these and many other factors will conspire to delay our projects.

The fact that risk in IT is substantially one-way brings a lot of our management and governance into serious doubt. Having a project plan distinct from the risk log makes the hubristic assumption that we will deliver at time and cost, so we must pay attention to the things that threaten the effort. Given that our risk is substantially one-way, we should make a more humble assumption: odds are that delivery will occur above our forecast time and cost, so what do we need to make sure goes right so that we don't? While such a pessimistic perspective may be in direct contrast to the cheerleading and bravado that all too often pass for "management", it makes risk the core activity of management decision making, not a peripheral activity dealt with as an exception.

In Convexity, Robustness and Model Error in the Fourth Quadrant, Taleb makes the point that one-way risk is best dealt with by robustness – for example, that we build redundancies into how we work. Efficiency, by comparison, makes us more vulnerable to one-way risk by introducing greater fragility into our processes. By way of example, think of the "factory floor" approach to IT, where armies of people are staffed in specialist roles. What happens to the IT "assembly line" when one or more role specialists exit, depriving the line of their situational knowledge? Without redundancy in capability, the entire line is put at risk.

Common sense and statistical analysis both conclude that an optimized system is sensitive to the tiniest of variations. This means that when risks are predominantly one-way – such as in IT projects – it behooves us to err on the side of robustness.

That risk in IT is substantially one-way brings a lot of our management and governance into serious doubt. Having a project plan distinct from the risk log makes the hubristic assumption that we will deliver at time and cost, so we must pay attention to this list of things that could go wrong. Given the one-way risk - and the uncertainty of what those risks are - we should make a more humble assumption: delivery will occur well above our forecast time and cost, so what do we need to make sure goes right? While such a pessimistic outlook may be in direct contrast to the cheerleading and bravado that pass for "management", it makes risk the core activity of management decision making, not a peripheral activity dealt with as an exception.

Robustness is the antithesis of efficiency. Maximum efficiency of execution against a plan calls for the fewest people delivering the most output to a predetermined set of architectural decisions. Building in robustness – for example, redundancy of people so that skills and knowledge aren’t resident in a single person, pursuing multiple technical solutions as a means of mitigating non-functional requirements, etc. – will not come naturally to managers with a singular focus on minimizing cost, especially if, like hedge fund managers James Mackintosh was referring to, they’re blissfully unaware of the risks.

So, what can we do?

First, we have to stop trafficking in the false precision of IT project management. This is no easy task, particularly in a business culture rooted in fixed-budgets and rigid planning cycles, buyers of industrial IT expecting that technology labor is interchangeable, and so forth. We won’t change the landscape all at once, but we can have tremendous influence with current business examples that will be relevant to sponsors and investors of IT projects. If we change the expectations of the people paying for IT projects, we can create the expectation that IT should provide probabilistic projections and take more robust – and therefore one-way risk tolerant – solution paths.

Second, we can introduce risk management that is more sophisticated than what we typically do, yet still easy to understand. If you haven’t read the book, or haven’t read it for a while, pick up Waltzing with Bears by DeMarco and Lister. Their statistical model for risk profiling is a good place to start, quick to work with and easy to understand. Nothing stops us from using it today. Now, the act of using the tool won’t make risk management the central activity of project managers or steering committees, but adding a compelling analysis to the weekly digest of project data will shift the balance in that direction. That, in turn, makes it easier to introduce robustness into IT delivery.

On that subject of robustness, Taleb observed:

Close to 1000 financial institutions have shut down in 2007 and 2008 from the underestimation of outsized market moves, with losses up to 3.6 trillion. Had their managers been aware of the unreliability of the forecasting methods (which were already apparent in the data), they would have requested a different risk profile, with more robustness in risk management …. and smaller dependence on complex derivatives.

Given the success rate of IT projects – still, according to the research organizations, less than 40% - IT project managers should similarly conclude that more robustness in risk management would be appropriate.