It's pretty well established that Agile and Lean IT are more operationally efficient than traditional IT. Agile teams tend to commit fewer unforced errors, and don't defer work. This results in fewer surprises - and with it, fewer surprise costs - in the final stages of delivery. Agile practices unwind the “requirements arms race” between business and IT, while Lean practices reduce waste throughout the delivery cycle. And Agile teams are organized around results as opposed to effort, which enables more prudent business-IT decisions throughout delivery.
This operational efficiency generally translates into significant bottom line benefits. From a financial perspective, Agile IT:- Can capitalize a greater proportion of development costs
- Consumes less cash and manages cash expenditure more effectively
- Has higher yields and offers better yield protection on IT investments
- Is less likely to experience a catastrophic correction that takes everybody by surprise (e.g., appear to be a Black Swan event)
While all this sounds good, there’s no such thing as a free lunch. No surprise, then, that fully agile IT brings a new set of risks. A leaned-out IT organization capitalizing a significant proportion of its discretionary spend is highly susceptible to a perfect storm of (a) SG&A contraction, (b) IT project write-off, and (c) suspended IT investments.
The "Perfect Storm" of a Lean-IT Financial Crisis
The meteorology of this perfect storm happens more often than you might think. Consider the following scenario. Suppose at the end of the first half of a fiscal year (H1), we face the following:
- SG&A spend on data center operations runs higher than forecast because more mainetnance work is done than forecast, and contractor costs rise unexpectedly
- Effort has to be written off a capital project because the project team didn't achieve anything meaningful (and therefore there's no asset to capitalize)
- An early stage investment is suspended pending a re-examination of business benefits
Then the CEO pops by to say that H1 results are disappointing, and asks us to cut the IT SG&A budget significantly for H2.
We now have a lot of things competing for our reduced SG&A budget in H2. Meanwhile, our capital investment portfolio is underperforming.
Our Lean IT organization faces a two-phase exposure similar to the credit crisis that struck Wall Street in 2007. Initially, we face a liquidity crisis. This quickly gives rise to a solvency crisis.
Phase 1: Liquidity Crisis
A liquidity crisis is triggered by the contraction of SG&A (also known as Operating Expense, or OpEx). Whether our business is govered by GAAP or IAS, the rules that govern capitalization of intangible assets such as software require us to define our investment intention. That is, we need to be able to explain that we're making a capital investment in software because we expect to achieve this return or business benefit. In IT, investment intention is defined by a project inception phase of some kind. Accounting rules dictate that inception has to be funded out of SG&A. What this means is that before we can spend out of a capital budget, we must spend some SG&A money first. It's also important to bear in mind that the same is true at the other end of the delivery cycle: last mile tasks such as data migration can't be capitalized; they also must be funded out of SG&A.
In effect, our SG&A budget (also known as operating expense, or OpEx) is leveraged with capital expense (CapEx). A contraction of OpEx proportionally reduces the CapEx accessible to us. This puts IT capital investments at risk. If we have less OpEx to spend, we may not be able to start new projects because ramp-up activities like project inception must be funded out of OpEx. We also may not be able to get capital investments into production because the things we need to do to get them across the finish line must be funded out of OpEx. Depending on how highly we're leveraged, even a small loss of OpEx may create liquidity seizure of our IT portfolio. This will force us to make difficult investment decisions to defend our portfolio returns.
Phase 2: Solvency Crisis
Just as happened on Wall Street, a liquidity crisis soon becomes a solvency crisis. In IT, “solvency” is capability. IT departments invest in people to learn how to get stuff done both in the business context (what are the critical business drivers?) and the IT context (how do all these systems actually work together?) IT people master the situational complexity necessary to keep the systems that run the business humming. They know not only which bit to twiddle, but why.
With this in mind, think back to our two funding sources: OpEx and CapEx. Capitalizing development of IT assets is an exercise in funding salaries and contractor costs out of CapEx budgets. As described above, an IT department that experiences a liquidity seizure loses access to its capital budgets. With capital funds inaccessible for payroll, an IT department faces very uncomfortable staff retention decisions. The people who know how to get stuff done may have to be released. If that happens, the very solvency – that is, the ability of the IT department to meet business demands – is in jeopardy.
While transferring from one budget to another may appear to be a simple way to protect IT solvency, it’s an option of last resort. Capitalization distributes the cost of an investment over many years, because the asset is depreciated. Depreciation increases corporate profitability for the year in which an IT investment is made because costs are deferred. Conversely, expensing recognizes the cost of an investment as it occurs, which decreases profitability for the year in which an investment is made. Moving money from CapEx to OpEx, then, will have a negative impact on current FY profitability. “IT Impairs Earnings” is not the sort of headline most CIOs aspire to see in the annual report. In fact, going hat in hand to the CFO is a career limiting move for the CIO.
Mitigation
This “perfect storm” is more common than you might think. Mitigating exposure is done through a variety of different mechanisms.
One is to hedge the project portfolio by bringing several investments into the early stages of delivery and then putting them into operational suspense. This creates a deliberate OpEx expenditure at the beginning of a fiscal cycle (before risks of OpEx impairment are realized over the course of a year) to multiple project inceptions, and then rendering some of those investments dormant. This diversifies the IT project portfolio, allowing IT capability to shift among different projects should one or more of those projects be cancelled.
Another is to align the project financing window with the Agile delivery window. A lot of this risk results from the incongruity of a long budgeting cycle that is matched with short Agile delivery windows. Following the lead of the sustainable business community, businesses should move to adopt micro-finance for IT projects. This is very difficult to achieve. Among other things, it requires an active investment authority (e.g., an investment committee actively involved in portfolio reviews) as well as a hyper-efficient inception process.
Yet another is to encourage people to think like “active traders” as opposed to “passive investors”. Each person must look for “trades” that will improve a team position overall. This can be anything from the priority of specific requirements or the people in the team (e.g., aggressively rooting out net negative contributors).
Finally, and most importantly, we’ve learned that Agile IT requires Agile governance. We may have all the data in the world, but optimal investment decisions don’t happen of their own volition. Just as Agile delivery teams require tremendous discipline, so, too, does the Agile executive. Liquidity and solvency crises are averted not through mechanical processes, but through meta-awareness of the state and performance trajectory of each investment in the portfolio.
