The Agile Manager

Business Value is a Weak Currency

2011-12-29T13:22:00.000-06:00

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

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

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

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

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

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

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

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

2011-11-30T10:08:00.001-06:00

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

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

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

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

If only it were so simple.

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

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

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

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

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

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

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

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

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

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

2011-10-26T07:20:00.013-05:00

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

2011-09-08T11:20:00.001-05:00

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

2011-08-28T23:13:00.007-05:00

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

2011-07-31T14:29:00.001-05:00

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

2011-06-21T10:20:00.013-05:00

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

2011-05-13T18:02:00.007-05:00

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

2011-04-27T10:05:00.001-05:00

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

2011-04-15T10:55:00.004-05:00

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

2011-03-25T09:05:00.000-05:00

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

2011-02-10T17:18:00.005-06:00

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)

2011-01-12T14:32:00.003-06:00

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)

2011-01-10T12:12:00.020-06:00

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

2010-12-24T17:20:00.008-06:00

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

2010-11-30T17:29:00.005-06:00

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

2010-10-31T20:09:00.004-05:00

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

2010-09-29T05:30:00.005-05:00

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

2010-08-31T11:44:00.006-05:00

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.

Separating Utility from Value Add

2010-07-09T04:45:00.001-05:00

One of the more hotly debated subjects in the recent debate on financial services reform has been the reintroduction of Glass-Stegall. Enacted in 1933, the intent was in part to prevent banks from financing speculative investments with money obtained through deposit and lending. Because of the importance of commercial banking to the stability of the economy (and, arguably, society), it was deemed unacceptable to make it easy for a bank to take imprudent risks with money for which has a stewardship responsibility. The law was substantially repealed in the 1990s. Quite a few people have suggested that it be brought back.

Whether it's appropriate or not for banking isn't the purpose of this blog post. But there is some thinking behind the separation of business activity that's worth considering in the IT context.

Retail banking serves largely a utilitarian purpose in an economy. Deposits give banks the capital to make loans to small businesses, write mortgages, and so on. This banking infrastrucure allows a community to pool its resources to grow and flourish as it would likely not be able to do otherwise. It also provides new businesses with capital at startup, and stabelizing cash through business cycles. Still, you don't loan out money to everybody who asks for some. If a bank makes loans to people and companies that aren't creditworthy, they put deposits at risk. Needless to say, commercial banks have (historically, anyway) held high lending standards because they are expected to be highly risk averse. With low risk appetite come low returns.

While low returns aren't all that exciting, there's an argument to be made that low returns are just fine for this kind of banking. The mission of a commercial bank isn't to produce outsized returns; the mission is to be a financial utility, to be stable and consistent. With stability comes confidence in the financial system (a confidence underwritten by federal deposit insurance), and that confidence is a pillar of a strong society.

Investment banks are vastly different. They are, by definition, far more risk prone. While there are conservative investment banks - banks that engage largely in advisory and research and do a minimum of trading - there is an expectation that bulge bracket investment banks will produce an outsized return by taking outsized risks. They trade their client's capital as well as their own using complex strategies specifically to generate high yield.

Instead of producing large returns, of course, investment banking can produce large losses. Because a lot of investment banks make proprietary investments with borrowed capital (that is, they make leveraged investments), a projected windfall can quickly become a bottomless pit.

Hence one of the the reasons for separating investment and commercial banking. The utility functions of commercial banking provide a fat pile of capital that can be leveraged for investment banking activity. Trouble is, there's no upside for the utility side of the bank if it allows its deposits to be exposed to outsized risk. It still pays the same rate to depositors, still collects the same rate from borrowers. For the utility, there's only downside: in a universal bank, a severe loss in investment banking puts commercial deposits at risk. Putting explicitly risk-averse capital at high risk undermines the stability of the financial system.

So, that's banking. What does any of this have to do with IT?

Just like the banking system, IT has two sides to it's house: a utility side, and an investment side. Comingling them hasn't done us much good. If it's done anything, it's confused the business mission of IT. We should separate them into independently operating business units.

A significant portion - maybe 70%+ - of IT spend is on utility services, things that keep a business operating. This includes things like data storage, servers, e-mail, office productivity applications, virus protection, security and so forth. Obviously, business is largely conducted electronically today, so a business needs these things. Restated, there's a lot of business that we simply can't conduct today without it.

These utilities don't provide return in and of themselves. They're so ubiquitous in nature, and so fundamental to how business is done, it's not an option to try to operate without them. They're the information technology equivalent of electricity or tap water. A firm does not derive competitive advantage from the type of electricity it uses. Nor do we measure return on tap water.

And like electricity or tap water, you don't typically provide your own. You plug into a utility service that provides it for you. Every volt of electricity and every gallon of water are the same.

It actually would seem a bit strange for most businesses to be providers of their own utilities. Still, most companies are in the business of providing their own IT utilities.

One reason they do is because of the stationary intertia of IT. We've injected technology into companies through captive IT departments. Nobody questions "why do we obtain these services this way", because technology has "always been provided this way."

Another is that IT services have complex properties to them that other utilities don't. Every volt of electricity is the same, but not every byte of e-mail is the same. Some contain proprietary, confidential or sensitive information. It's not enough for a firm to outsource responsibility for the protection of that data. If data confidentiality is compromised, the firm contracting for the utility is compromised. All the commercial and service level agreements in the world won't undo the damage.

Of course, these complex properties don't make them "high value added" services. They're still utilities. They're just a bigger pain in the neck than things like electricity.

It's very likely that a lot of what we do in captive IT today will be obtained as a utility service in the future. We'll buy it like tap water, metered and regulated. Obviously, this is the business model of SAAS and outsourced services. While they're still not robust enough for every business, we're seeing advances in things like networking and encryption technology that provide a greater level of accessibility and assurance. We're getting close to (if not already well past) the inflection point where it's less attractive to underwrite the risk of providing these things captively than to get them metered.

But not everything done by captive IT is utility. The remaining 30% of today's IT spend is investment into proprietary technology that amplifies the performance of the business to increase yield. This is "high value added" because it provides unique, distinct competitive advantage to the host business. Investing in these things is one way we build our businesses, and make life difficult for the competition.

Which brings us back to Glass-Stegall: just as those two forms of banking are vastly different, so are these two forms of IT.

Dividing IT along "utility" and "value added" lines is a departure from where we are today. We've put everything from disks to development under the heading of "technology" in most companies, because we've had no other way of looking at it. Technology is still in its infancy, is still relatively foreign to most people, and we're still figuring out how to apply it in business. So anything involving technology is considered foreign to a business, and attached to it as an appendix, or a tumor.

Nor is the common division of IT into "infrastructure" and "application development" the dividing line between utility and value-add. Not all infrastructure is utility, and not all app dev is value add. Firms dependent on low latency for competitive edge are not likely to get competitive advantage by hosting their applications in the cloud. Similarly, payment processing is perhaps not something that a retail site wants to invest money into development of, so it contracts to get those services.

This is not a separation of IT by the nature of the technology, but into what technology does for the host business. That portion of the business that provides outsized return - the "investment banking" portion - is what should remain captive. The rest - the "utility banking" - should be part of facilities or operations management. The expectation must also be that this division is dynamic: today's captive data center may be tomorrow's CPU cycles obtained through the cloud if there's no performance or reliability to be gained from providing it captively.

Separating utility from value add will make IT a better performing part of the business. Because they're comingled today, we project characteristics of "investment" into what are really utilities, and in the process we squandor capital. Conversely, and to ITs disadvantage, we project a great deal of "utility" into the things that are really investments, which impairs returns.

As a business function, IT has no definition on its own. It only has definition as part of a business, which means it needs to be run as a business. The risk tolerance, management, capabilities, retention risks, governance and business objectives of these two functions are vastly different. Indeed, the "business technologist" of value added IT needs a vastly different set of skills, capability, and aptitude than she or he generally has today. Clearly, they're vastly different businesses, and should be directed accordingly.

Separating the utility from the value add allows us to reduce cost without jeopardizing accessibility to utility functions, and simultaneously build capability to maximize technology investments. Running them as entirely different business units, managed to a different set of hiring expectations, performance goals, incentive and reward systems, will equip each to better fulfill the objectives that maximize their business impact.

A Portfolio Perspective on Requirements

2010-06-26T12:43:00.001-05:00

A software application is not a collection of features that create business value. It is a portfolio of business capabilities that yield a return on the investment made in creating them.

This isn't semantics. There's a big difference between "business impact" and "financial returns."

Some software requirements have a direct business impact. But not all of them do, which we'll explore in a little bit. As a result, the justification for and priority of a lot of requirements are not always clear, because the language of "business value" is one-dimensional and therefore limiting. "Financial returns" is far more expansive concept. It brings clarity - in business terms - why we have to fulfill (and, for that matter, should not fulfill) far more requirements. Thinking about "returns" is also more appropriate than "value" for capital deployment decisions, which is what software development really is.

Why is software development a "deployment of capital"? Because a company really doesn't need to spend money on technology. When people choose to spend on software development, they're investing in the business itself. We elect to invest in the business when we believe we can derive a return that exceeds our cost of capital. That's why we have a business case for the software we write. That business case comes down to the returns we expect to generate from the intangible assets (that is, the software) we produce.

This should affect how we think about requirements. As pointed out above, a lot of requirements have a clear and direct business impact. A business requirement to algorithmically trade based on fluctuations in MACD, volume weighted average price and sunspot activity has a pretty clear business value: analysis before we code it tells us some combination of market and cosmic events leads to some occasional market condition that we expect we can capitalize on. And after the fact, we know how much trading activity actually occurs on this algorithm and how successfully we traded.

But not all requirements fit the business impact definition so nicely. We fulfill some requirements to avoid paying a penalty for violating regulations. Others increase stability of existing systems. Still others reduce exposure to catastrophic events.

This is where "business value" loses integrity as an index for requirements. Calling one activity that increases revenue equivalent to another that reduces exposure to catastrophic loss is comparing apples to high fructose corn syrup. They're sweet and edible, but that's about it.

As anybody who has ever run a business knows, not every dollar of revenue is the same: some contracts will cost more to fulfill, will cause people to leave, will risk your reputation, etc. The same is true in "business value": not every dollar of business value is the same. Translating all economic impact into a single index abstracts the concept of "business value" to a point of meaninglessness. Making matters worse, it's not uncommon for IT departments to sum their "total business value" delivered. Reporting a total value delivered that eclipses the firm's enterprise value impeaches the credibility of the measure.

Business value is too narrow, so we need to have a broader perspective. To get that, we need to think back to what the software business is at its core: the investment of capital to create intangible assets by way of human effort.

The operative phrase here isn't "by way of human effort", which is where we've historically focused. "Minimizing cost" is where IT has put most of its attention (e.g., through labour arbitrage, lowest hourly cost, etc.) In recent years, there's been a movement to shift focus to "maximize value". The thinking is that by linking requirements to value we can reduce waste by not doing the things that don't have value. There's merit in making this shift, but essentially "maximize value" and "minimize cost" are still both effort-centric concepts. Effort does not equal results. The business benefits produced by software doesn't come down to the efficiency of the effort. They come down to the returns produced in the consumption of what's delivered.

Instead of being effort-centric, our attention should be requirements-centric. In that regard, we can't be focused only on a single property like "value." We have to look at a fuller set of characteristics to appreciate our full set of requirements. This is where "financial returns" gives us a broader perspective.

When we invest money to create software, we're converting capital into an intangible asset. We expect a return. We don't get a sustainable return from an investment simply if it generates revenue for us, or even if we generate more revenue than we incur costs. We get a sustainable return if we take prudent decisions that make us robust to risk and volatility.

Compare this to other forms of capital investment. When we invest in financial instruments, we have a lot of options. We can invest at the risk-free rate (traditionally assumed to be US Treasurys). In theory, we're not doing anything clever with that capital, so we're not really driving much of a return. Alternatively, we can invest it in equities, bonds, or commodities. If we invest in a stock and the price goes up or we receive a dividend, we've generated a return.

But financial returns are at risk. One thing we generally do is spread our capital across a number of different instruments: we put some in Treasurys to protect against a market swoon, some in emerging market stocks to get exposure to growth, and so forth. The intent is to define an acceptable return for a prudent level of risk.

We also have access to financial instruments to lock in gains or minimize losses for the positions we take. For example, we may buy a stock and a stop loss to limit our downside should the stock unexpectedly freefall. The put option we purchased may very well expire unexercised. That means we've spent money on an insurance policy that wasn't used. Is this "waste"? Not if circumstances suggest this to be a prudent measure to take.

We also have opportunities to make reasonable long-shot investments in pursuit of outsized returns. Suppose a stock is trading at $45 and has been trading within a 10% band for the past 52 weeks. We could buy 1,000,000 call options at $60. Because these options are out of the money they won't cost us that much - perhaps a few pennies each. If the stock rises to $70, we exercise the call, and we'll have made a profit of $10m less whatever we paid for the 1m calls. If the stock stays at $45, we allow the options to expire unexercised, and we're out only the money we spent on those options. This isn't lottery investing, it's Black Swan investing - betting on extreme events. It won't pay off all that often, but when it does, it pays off handsomely.

These examples - insurance policies and Black Swans - are apt metaphors for a lot of business requirements that we fulfill.

For example, we need to make systems secure against unauthorized access and theft of data. The "value" of that is prevention of loss of business and reputational damage. But implementing non-functional requirements like this isn't "value", it's insurance. The presence of it simply makes you whole if it's invoked (e.g., deters a security threat). This is similar to a mortgage company insisting that a borrower take out fire insurance on a house: the fire insurance won't provide a windfall to the homeowner or bank, it'll simply make all parties whole in the event that a fire occurs. That insurance is priced commensurate with the exposure - in this case, the value of the house and contents, and the likelihood of an incendiary event. In the same way, a portfolio manager can take positions in derivatives to protect against the loss of value. Again, that isn't the same as producing value. This insurance most often goes unexercised. But it is prudent and responsible if we are to provide a sustainable return. To wit: a portfolio manager is a hero if stock bets soar, but an idiot if they crater and he or she failed to have downside protection.

We also have Black Swan requirements. Suppose there is an expectation that a new trading platform will need to support a peak of 2m transactions daily. But suppose that nobody really knows what kind of volume we'll get. (Behold, the CME just launched cheese futures - with no contracts on the first day of trading.) So if we think that there's an outside chance that our entering this market will coincide with a windfall of transactions, we may believe it's prudent to support up to 3x that volume. It's a long shot, but it's a calculated long shot that, if it comes to pass and we're prepared for it, provides an outsized yield. So we may do the equivalent of buying an out-of-the-money call option by creating scalability to support much higher volume. It's a thoughtful long-shot. A portfolio manager is wise for making out of the money bets when they pay off, but a chump if he or she all positions aligned with conventional wisdom and a market opportunity is missed.

Neither of these examples fit the "value" definition. But they do fit well into a "portfolio" model.

Of course, just as determining the business value of each requirement isn't an exact science, neither is defining a projected investment return. Even if we ignore all the factors that impact whether returns materialize or not (largely what happens after the requirement is in production), the cost basis is imprecise. We have precise pricing on liquid financial instruments such as options. We don't have precise pricing in IT. The reason goes back to the basic definition of software development: the act of converting capital into intangible assets by way of human effort. That "human effort" will be highly variable, dependent on skills, experience, domain complexity, domain familiarity, technology, environment, etc. But this isn't the point. The point isn't to be precise in our measurement to strain every ounce of productivity from the effort. We've tried that in IT with industrialization, and it's failed miserably. The point is to provide better directional guidance that maximize returns on the capital, to place very well informed bets and protect the returns.

It's also worth pointing out that going in pursuit of Black Swans isn't license to pursue every boondoggle. Writing the all singing, all dancing login component in this iteration because "we may need the functionality someday" has to withstand the scrutiny of a reasonable probability of providing an outsized return relative to the cost of investment. Clearly, most technology boondoggles won't pass that test. And all our potential boondoggles are still competing for scarce investment capital. If the case is there, and it seems a prudent investment, it'll be justified. If anything, a portfolio approach will make clearer what it is people are willing - and not willing - to invest in.

Because it gives multi-dimensional treatment to the economic value of what we do, "portfolio" is a better conceptual fit for requirements than "value." This helps us to frame better why we do things, and why we don't do things, in the terms that matter most. We'll still make bad investment decisions: portfolio managers make them all the time. We'll still do things that go unexercised. But we're more likely to recognize exposure (are you deploying things without protecting against downside risk?) and more likely to capitalize on outsized opportunities (so what happens if transaction volume is off the charts from day one?) It's still up to us to make sound decisions, but a portfolio approach enables us to make better informed decisions that compensate for risk and capitalize on the things that aren't always clear to us today.

Short Run Robustness, Long Run Resiliency

2010-06-11T09:46:00.010-05:00

There is no such thing as a "long run" in practice --what happens before the long run matters. The problem of using the notion of "long run", or what mathematicians call the "asymptotic" property (what happens when you extend something to infinity), is that it usually makes us blind to what happens before the long run. ...
[L]ife takes place in the pre-asymptote, not in some Platonic long run, and some properties that hold in the pre-asymptote (or the short run) can be markedly divergent from those that take place in the long run. So theory, even if it works, meets a short term reality that has more texture. Few understand that there is generally no such thing as a reachable long run except as a mathematical construct to solve equations - to assume a long run in a complex system you need to assume that nothing new will emerge.

- Nassim Nicholas Taleb
Asperger and the Ontological Black Swan

Mr. Taleb is commenting on economists and financial modelers, but he could just as easily be commenting on IT planning.

Assertions of long-term consistency and stability are baked into IT plans. For example, people are expected to remain on the payroll indefinately; but even if they don’t, they’re largely interchangeable with new hires. Requirements will be relatively static, specifically and completely defined, and universally understood. System integration will be logical, straightforward and seamless. Everybody will be fully competent and sufficiently skilled to meet expectations of performance.

Asserting that things are fact doesn’t make them so.

Of course, we never make it to the long run in IT. People change roles or exit. Technology doesn't work together as seamlessly as we thought it would. Our host firm makes an acquisition that renders half of our goals irrelevant. Nobody knows how to interface with legacy systems. The historically benign financial instruments we trade have seen a sudden 10x increase in volume and volatility off the charts. A key supplier goes out of business. Our chief rival just added a fantastic new feature that we don't have.

Theoretical plans will always meet a short-term reality that has more texture.

* * *

After the crisis of 2008, [Robert Merton] defended the risk taking caused by economists, giving the argument that “it was a Black Swan” simply because he did not see it coming, hence the theories were fine. He did not make the leap that, since we do not see them coming, we need to be robust to these events. Normally, these people exit the gene pool –academic tenure holds them a bit longer.

- ibid.

The long-term resiliency of a business is a function of how robustly it responds to and capitalizes on the ebbs and flows of a never-ending series of short runs. The long-term resiliency if an IT organization is no different.

This presents an obvious leadership trap, the “strategy as a sum of tactical decisions” problem. Moving with the ebb and flow makes it hard to see the wood for the trees. An organization can quickly devolve into a form of organized chaos, where it reacts without purpose instead of advancing an agenda. Reacting with purpose requires continuous reconciliation of actions with a strong set of goals and guiding principles.

But it also presents a bigger, and very personal, leadership challenge. We must avoid being hypnotized by the elaborate models we create to explain our (assumed) success. The more a person invests in models, plans and forecasts, the more they will believe they see artistic qualities in them. They will hold the models in higher esteem than the facts around them, insisting on reconciling the irrational behavior of the world to their (obviously) more rational model. This is hubris. Obstinance for being theoretically right but factually wrong is a short path to a quick exit.

Theoretical results can't be monetized; only real results can.

Webinar: Being an Activist Investor in IT Projects

2010-05-19T19:46:00.006-05:00

Please join me on 26 May for a webinar on Activist IT Investing.

An ounce of good governance is worth a pound of project rescue. Agile practices, with their emphasis on transparency, business alignment and technical completion, are enablers of better IT governance. But all the transparency and alignment in the world isn't going to do us any good if we're not equipped to pay attention and act on it.

An Agile organization needs a new approach to governance, one that makes everybody think not as caretakers of a project but investors in a business outcome. This presentation explores the principles of Agile governance, and what it means to be an activist IT investor in a Lean-Agile world.

What you will learn

What are the principles of IT governance?
What kind of governance does Agile enable and demand?
How do we create a culture of activist investors in IT projects?

I hope you can join me on the 26th. Click here to register.

Digital Squalor

2010-05-07T20:30:00.001-05:00

In the not too distant past, storage was limited and expensive. As recently as 1980, 1 megabyte of disk storage cost $200. But this is no longer the case. Today, you can buy 8,000 megabytes (a.k.a. 8 gigabytes) for $1. Storage capacity is now so abundant and compact that you can record every voice conversation you’ll ever have in a device that can fit into the palm of your hand.

What this means is that storage is no longer a physical (capacity) challenge, but a logical (organization) one. We’re maximizing the prior, storing everything we can digitize. Unfortunately, we’re not really making a lot of progress on the latter, as “intelligence” eludes us in an ever-expanding swamp of “data.”

Let’s think about the characteristics of data, just on a personal level.

We have data everywhere. E-mails contain data. So do documents and spreadsheets. So do various applications, such as a local contact manager. So do subscription services, such as Salesforce.com. So do financial management tools (be it Quickbooks or Oracle Financials.) So does Twitter. So digital photos. So do news feed subscriptions. So do voicemails. So do Podcasts and webinars for that matter.
We have a lot of redundant data. How many different booking systems have your frequent flier numbers, know that you prefer an aisle to a window, and know that you prefer a vegetarian meal on long-haul flights? And how much of that has changed since you last edited your profile in each of those systems? Or, think about contact information. How many places do you have your co-worker's (multiple) contact details spread out: in your mobile phone? Corporate directory? Google contacts? Personal e-mail box?
There is data in the inter-relationships among data. This document references this spreadsheet, and both were discussed in this meeting on this date with these people. Copies of drafts under discussion at the time may be attached or referenced to the meeting invitation.
Our data is inconsistent. We have full contact information for some people who attended a meeting because they’re in the company directory, but perhaps we have only personal data for some because we’re connected to them via LinkedIn, and still for others all we have is an e-mail address.
Data has different meaning depending the context. A contract from 2005 between one firm and another is a binding legal document in the context of that relationship. But that document is also a source of language that might be useful when we are drawing up a contract with the same people in that firm, with different people in that firm, or with a different firm all together. Or a specific presentation from 5 years ago may have referenceable content, but at the moment we're only interested in the fact that it encapsulates a template that has elements you want to re-use.
We lug this data around with us. Some of it we carry around with us in the file system paradigm, moving it from laptop to laptop. Some we have in our smart phones and media players. Some is stored in a managed service like LinkedIn. Some is managed for us in a service like iTunes. There have been attempts to corral and manage slices of this data: for example, consolidating contact details, e-mail history, proposals in a single CRM system. None have been runaway successes. They’re either incomplete, inadequate, or simply too much work to sustain.

And that’s just a recon of our personal data. The scope of this is amplified several orders of magnitude on a corporate and societal level. To wit: marketing departments seem perpetually engaged in contact list consolidation and clean-up. Then there are all those automatic feeds setup to get everything from bond prices to today’s weather to city council meeting notes.

The fact is, we already live in digital squalor. In a relatively short period of time, we’ve gone from having very little digitally stored, to having a lot digitally stored. Only, along the way we didn’t give much thought to maintaining good hygiene of it all. We have data everywhere. Some structured, some not. Some readily accessible, some long forgotten, and some we’re not entirely certain have integrity any longer. And the bad news is, we’re accumulating data at an exponentially increasing rate.

We tame the data monster through our mental memories and our synaptic processes. A memory or an idea triggers a recollection, so we know to go look for something and roughly where we might find it. Sometimes we're able pull together distinct pieces of data - possibly squirrled away over a period of several years - to derive some useful information. But not all data is created equally, so when we go mining through data, we have to judge whether it has sufficient integrity for our purpose. Is it current enough? Is it from a credible source? Is it a final version or a draft? The bottom line is, it’s human intervention that allows us to bring order out of ever-increasing data chaos.

We're going to be living in digital squalor for quite some time. There are some interesting conclusions we can draw from that.

Our principal tool for managing the data bloat is search. Search is a blunt instrument. Search is really a simple attribute-based pattern matching tool that abdicates results processing to the individual. Meta-tagging is limited and narrow, so we don’t really have much in the way of digital synaptic processes. As the data behemoth grows, search will be decreasingly effective.

But as our digital squalor expands, it presents opportunity for those who can produce a clear, distinct signal from so much noise, e.g., by bringing data and analyses to bear on problems in ways never previously done. One example is FlightCaster, which applies complex analytics on publicly available data (such as the weather, and current flight status and historical flight data) to advise whether you should switch flights or not. It's a decision support tool providing an up-to-date analysis at the moment of decision where none existed previously.

This marks a significant change in IT. We've spent most of the past 60 years in technology creating tools to automate and digitize tasks and transactions. We now have lots of tools. Because of the tools, we also have lots of data. For the first time in history, we can get powerful infrastructure with global reach for rediculously little capital outlay:

the internet allows us to access vast amounts of specialized data;
cloud computing gives us virtually unlimited, pay-as-you-go computing power to analyze it;
smartphones on mobile internet give us an ubiquitous means to deliver our analyses.

Historically, Information Technology has focused on the "technology". Now, it's focused on the "information".

Digital squalor gives us the first broad-based tech-entrepreneurial opportunity of the 21st century. We're now able to pursue information businesses that wouldn't have been viable just a few years ago. We’re limited only by our imagination: what would I really like to know at a specific decision-making moment?

Answer that, and you've found your next start-up.

Mitigating Corporate Financial Risks of Lean IT

2010-04-26T06:30:00.000-05:00

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.

Supplying IT Mercenaries

2010-03-21T12:22:00.010-05:00

Last month we took a look at the different types of staffing in IT, using Machievelli’s book The Prince as a guide.

Buyers of forces, be they military or IT, have long been advised against employing mercenaries. Strangely enough, nobody has paid this counsel much mind. The buy side still buys mercenaries, more than ever. Just have a look at your own sales lead list. Lots of demand for short-term specialists.

So what’s an IT supplier to do?

Let’s look at this from the perspective of a “supplier of forces” that wishes to be sustainable business, one that aspires to do business for many years. In the parlance of Machiavelli, we want to look at this from the perspective of a firm that wishes to be an independent “state.”

Supplying Mercenary Forces

For IT firms, there are always mercenary opportunities, because there are always buyers looking to fill highly specialized roles for some period of time: an Oracle financials expert, an iPhone app developer, an interim project manager, a Sharepoint specialist.

To the supplier of forces, a mercenary opportunity might look attractive because it appears to offer short-term placement, outsized income, and few strings attached. This is almost always illusory. In fact, mercenary work can cause more harm to the supplier than it’s worth.

Mercenary work is income, not wealth.

When a supplier firm is in need of income, mercenary work can appear to be especially attractive. But income is not wealth.

Income pays the bills, but most income streams are not sustainable. Wealth sustains a business. The sell-side firm accumulates wealth in many ways, including intellectual property, a well-honed social system for delivery, people who are highly capable or have deep industry knowledge, and referenceable, long-term clients. Mercenary jobs do not contribute to the development of any of these. This stands to reason, as the mercenary buyer is looking to exploit expertise, not contribute to its development. As a result, mercenary opportunities don’t contribute to wealth. They are income, and little else.

Income can be useful depending on the needs that the supplier has. However, it must be recognized for what it is, and not confused with wealth.

The cost of mercenary income is very high.

Buyers of mercenaries rent knowledge and expertise in pursuit of their own agenda. In so doing, they exploit, but do not build, the wealth of suppliers.

Let’s think back to Machiavelli for a moment. Machiavelli wrote in terms of princes and the states they govern. In Machiavellian “sovereign state” terms, if a state dispatches too many of its best forces on mercenary missions, it will be unable to defend its home and advance its agenda. The same applies to the would-be sustainable IT supplier.

Suppose a sell-side firm chooses to retain its best and supply untrained or unskilled forces into a mercenary mission. The buyer of mercenaries will recognize the skill level of the forces supplied and conclude they are not getting value for money. The buyer will complain and even threaten the supplier (seeking damages, seeking not to pay, etc.). This means mercenary work draws down senior staff almost exclusively.

Being forced to dispatch senior staff is costly as it stunts the development of the sell-side business. Mercenary engagements rarely offer opportunities for the supplier to incubate new capability as can be done when deploying on “one’s own” missions. By extension, because they’re on mercenary missions, senior staff are unavailable to the sell side firm for the “one’s own” missions – developing deep customer relationships, industry knowledge or intellectual property – that build a business. This makes the sell-side business vulnerable and weak.

Sacrificing business development to accept jobs on offer is to trade wealth for income. That, by definition, makes it expensive income. It is dangerous for the supplier to get caught up in the attractiveness of income, especially if they lose sight of wealth-producing activities.

The worst mercenary engagements are destroyers of wealth.

The people you send into a mercenary mission may not return from the mission. For example, they may elect to quit and work for somebody else. Re-acquiring that capability is not inexpensive as you can’t just hire senior staff off the street: it takes time to recruit and train, build experiences, and mature somebody considered to be among the most senior staff.

But losing somebody in a mercenary mission is not just a loss of capability, it’s an erosion of wealth. Losing senior staff in which you’ve invested undermines the fabric of the supplying firm, especially if that person was a cultural icon, a strong leader, had many years of accumulated experiences, or was woven into the synaptic social processes of the organization itself. This form of wealth destruction in mercenary missions is particularly damaging because it results not from the pursuit of the supplier’s agenda, but in somebody else's agenda. That is, it’s not lost in pursuit of wealth, it’s lost in pursuit of income. Income doesn’t compensate for a destruction of wealth.

If you are going to put capability at risk (e.g., put people in a situation where they may be pushed beyond their limits), it is far better to have wealth to show for it.

Mercenary engagements encourage defection among the ranks.

Mercenary engagements favour the independent contractor more than they favour a firm that supplies mercenaries.

Suppose a member of your forces recognizes a mercenary situation for what it is, and furthermore that it’s likely to be a long-term mission. Since the situation is not likely to change, he or she might as well make the best of it for themselves. By becoming an independent contractor, they can negotiate more favourable terms with the buyer. This is usually nothing more complex than availing themselves at a lower cost to the buyer than their current host firm - that is, your firm - bills them out for. As an independent contractor, they’ll be well positioned to strike this bargain, especially once the mission is well under way and they’re already part of it.

The individual has the upper hand over the supplier firm because realpolitik trumps principles. Even with contractual covenants designed to deny a person going independent and taking a customer with them, the supplying firm will typically not impose them in mercenary circumstances. The sell-side firm already sacrificed pursuit of its agenda in pursuit of income. Also, the sell-side firm won't value mercenary work as highly as it will "one's own" or "auxiliary" work. Subsequently, the sell side firm won't risk future income from the buyer by playing the "principles of conduct" card with the would-be independent contractor. And both the independent contractor and the buyer know this.

Mercenary engagements can quickly become high maintenance.

If you send inferior or inexperienced forces, the buyer is likely to reject them and demand replacements and possibly seek damages. This can be as little as the refusal to pay for those initially fielded to expenses related to any transition work undertaken.

You may staff experienced forces, but they run into factors that curtail their effectiveness, things such as work environment, tools they must use, and the aptitude of those with whom they must work. The buyer of mercenaries is usually not inclined to respond to the demands of the mercenary, so they are ignored. The mercenary, unhappy and restless, may cause all kinds of disruption directly to you, or to the buyer (which will find its way to you). The mercenary may also resign themselves to the situation and mentally check-out. This will undermine the sense of value the buyer believes they are acquiring ("I expected more leadership from your people...") In either case, you will be spending a lot of time with the people deployed in a mercenary situation. On top of it, the buyer will be reluctant to pay, which will delay cash flow.

Alternatively, you may staff an experienced person, but one with the wrong personality. Personality conflicts are often not recognized for what they are, and personality problems completely obfuscate the landscape. So whether suitable to task or not, the buyer will claim he or she is not receiving value for money. In this case, the buyer may ask the supplier to intervene in integrating the mercenary, and will often communicate barbs or jabs stated by his or her "own" forces to undermine the credibility of the mercenary. The buyer may seek to renegotiate terms.

All of these increase the supplier’s cost of doing business, which erodes the margin on the mercenary income.

Mercenary engagements are very rarely closed-ended as promised.

Rarely does a patient tell a doctor the prognosis, what procedures to perform, what staff to have, what medications and treatments to prescribe, and so forth. In fact, in medicine, we do the opposite: doctors provide independent assessments, and proceed accordingly with the patient.

Yet mercenary engagements are defined by the buyer, not by the supplier. Mercenaries are rarely granted an opportunity to assess the battlefield, because they’re simply signing up to fight in somebody else’s battle.

Successful, clean extraction from the mercenary mission requires that the mercenary perform relative to the buyer expectation of the mission, and that the mercenary can explain how he or she has fulfilled consistent with buyer expectation. This requires the buyer to accurately articulate the problem space and how the mercenary will contribute to resolution. It also requires the buyer to completely articulate the problem space and how the mercenary will fit into that solution. Given the intrinsic optimism and selective amnesia that buyers of mercenaries typically have, it’s a stretch to assume that the buyer’s definition of the mission will have any bearing on the reality of what can, let alone what should, be done. The buyer has self-prescribed treatment, and most often, the prescription is well wide of the mark. This will obfuscate the definition of “success” of the mercenary mission, and make it difficult for the sell-side firm to conclude and collect.

The buy side may also wish to retain a mercenary for indefinite periods. People often buy mercenaries because their own forces are not performing well. The buyer can become unusually attached to a mercenary because this is the one person who speaks with clarity and authority and gets things done. The buyer may be unwilling to let the mercenary go, offering both extension and increased income. They may drag their feet on extracation procedures such as hand-off of mercenary work to their own, even if this comes at a cost to their own business. This positive vibe with a buyer may make the “income” more palatable, but it remains income just the same. And that vibe can just as quickly turn toxic due to some change in the buyer's situation.

Regardless the circumstance, a clean extraction from a mercenary mission is the exception rather than the rule.

Very few IT firms succeed as purely suppliers of mercenary forces.

Gaining a reputation as a “good mercenary” is not necessarily wealth building. It may create more mercenary opportunities. It may allow you to increase your fees. But it will not create wealth generating opportunities.

Mercenary skills tend to be highly specialized. The mercenary must be very fluent with a specific technology, a specific technique, or the specific nuances of how a particular company works. But as technology goes through cycles of obsolescence, as management fads come and go, and as companies are bought and sold, mercenary skills are high value for relatively short periods of time. The mercenary must therefore keep skills current and up to date and be in a position to influence technology cycles and management fads.

Conversely, there are few opportunities for generalist mercenaries. There may be people who can figure out a technology or collection of systems given time, but the buyer of mercenaries isn’t looking for generalist skills. They’re generally looking to have a very specific problem (e.g., involving a very specific collection of technologies) solved.

As mentioned above, mercenary work lacks characteristics of sustainability. Mercenaries are brought in to perform closed-ended jobs. While a job may command a high income, it is temporary by definition. The mercenary is removed from the situation at the first opportunity. Using the parlance of Machiavelli, once the battle is over, the mercenary will not be invited to be a “colonist.” The mercenary must therefore have a secure home to which to return and the opportunity to ply his or her trade elsewhere.

This means that a mercenary must always be on the lookout for the next opportunity, which usually means a different buyer. Because mercenary work tends to be very challenging and consuming, the mercenary can usually only go looking for new opportunities once the job at hand is completed. A mercenary is truly fortunate if he or she has a strong enough network that opportunities seek them out. On top of it, a mercenary must constantly evolve his or her skills to remain current, something difficult to do when deployed as a mercenary as opposed to an “auxiliary” or “one’s own” force.

Didn't the Swiss make it work?

What of Switzerland? Famous throughout the centuries as suppliers of mercenary forces (it wasn’t uncommon for Swiss forces to be engaged on opposite sides of the same battlefield), the Swiss were notoriously good mercenaries and converted mercenary income to wealth. Do they not offer a model for the would-be supplier of mercenaries? The Confederatio Helvetica benefits from a natural defensive geography. It is difficult for an invading force to mount an offensive as it’s tough to win an uphill battle, and then have sufficient forces remaining to sustain the victory. Switzerland has abundant natural resources, notably water, meaning an opposing force isn't going to win a war of attrition. A victor would have the unenviable challenge of administrating a government over the fiercely independent Swiss. All in all, the Swiss could avail a greater percentage of their population to mercenary pursuits without putting their own agenda (rather, the agenda set by each Canton) at great risk. Arguably, this was how the Swiss did advance their agenda.

While this model worked, it was also highly situational. There weren't a lot of other regions of Europe that had so many factors creating a natural invulnerability, let alone a population that sought principally to form a sustainable and symbiotic relationship with it. While it's not out of the realm of the possible, there aren't too many businesses today benefiting from market forces that make them similarly sustainable.

The sell-side has to know what it’s buying in a mercenary opportunity.

Clearly, the sell side buys into a mercenary situation, just as the buyer is buying mercenary forces.

The buyer of forces will often try to represent a mercenary opportunity as something other than “mercenary” to the supplier of forces. This can be innocuous: perhaps they don’t understand the distinction themselves, or this is how procurement has taught them services are contracted. It can also be malicious: a buyer can willfully deceive a supplier, perhaps because they’re engaged in a political battle with other people in their business and simply wish to deceive.

Mercenary work is still the most prevalent form of demand on the landscape. There is internal pressure to enter into these engagements as many people in the sell-side business will champion them for reasons ranging from hitting quarterly numbers to the brand association of doing business with those firms. Just ask yourself going in: where's the line between getting a “foot in the door” to build a business relationship and simply opening a short-term income spigot?

Throughout time, the sage advice to those on the buy side wishing to press forward an agenda as an independent "nation state" has been to avoid mercenaries. This advice is just as applicable to those on the sell side who aspire to be sustainable businesses pursuing an agenda of their own.

Mercenaries, Auxiliaries, and how we Staff IT

2010-02-09T21:04:00.002-06:00

I've spent a lot of time reflecting on Brad Cross' blog post on Wages. It got me thinking specifically about Machiavelli's book, The Prince.

Niccolò Machiavelli made some important observations regarding the conduct of a prince, making specific recommendations for what a prince must do to maintain the integrity of a state. Among other things, he wrote about the composition of forces necessary to both defend and advance the interests of a principality.

While military metaphors are in many ways inappropriate for business (business situations are nowhere near as serious as armed conflict), they are among the oldest of human endeavours and provide a rich history of organization and social dynamic. Just as there have been business books that derive lessons from such diverse personalities as Sun Tzu and Attila the Hun, we can similarly draw some interesting lessons from Signore Machiavelli.

Machiavelli observed there are four compositions of troops:

One's own forces (i.e., drawn from the population of the principality)
Mercenaries
Auxiliaries
Mixed from any combination of the above.

This provides an apt metaphor that describes a how technology “campaigns” are commonly staffed.

On the buy side, most businesses aspire to staff with “one’s own forces.” This provides a perception of control, specifically with regard to compensation, promotion, and even daily work activity. Many firms believe they have "one's own" because they staff with direct hires. But there's more to having “one’s own forces” than putting people on the payroll. The interests of the employees (or in military terms, the conscripts) must be fully aligned with the unit. A unit (e.g., a project team or an army) is victorious and with it the sponsoring organization (business or state) and the individual, or the unit is not victorious and with it both sponsoring organization and individual lose out.

If an individual is pursuing a path of personal success that is not aligned with the success of their unit, they are not, from the perspective of the principality, “one’s own forces.” In fact, they fall into one of the next two categories, that of mercenary or auxiliary. In technology, we see this all the time. For example, freshly minted university graduates are typically looking first to acquire skill and experience in a specific technology, expecting to change employer many times in the pursuit of that skill, as opposed to being motivated to fulfill a business mission enabled by the project they’re working on.

By the same token, most businesses engage mercenaries. Mercenaries are often independent contractors, loyal to no leader, and loyal only to themselves. While there can be exceptions, according to Machiavelli they're not good troops in the end because they are not dependable in battle. Specifically, they're the first to desert since they have little on the line. Also, their interests are not aligned once the battle is over. According to Machiavelli, the risk here is "dastardy," or maliciousness. Mercenaries draw income from battle, not wealth from victory. It is in their interest to seek - or to create - conflict. And this is common in the IT industry. How often have we seen an important business initiative beholden to a technology component that is laden with technical debt, the delivery of which is in the hands of mercenaries who are motivated neither by the business impact of the solution nor its reliability and affordability of maintenance? By contrast, how often do we see people develop career "annuities" for themselves, drawing an income for an extended period of time as caretakers of a business critical application that is heavily laden in situational complexity?

Auxiliaries, according to Machiavelli, are particularly dangerous. In military terms, the independent auxiliary unit seeks its own opportunities precisely because it is in a position to create attractive circumstances. In business, if a host company gives a contract firm autonomous leadership on an initiative, the host firm will find a significant portion of its forces are loyal to another. According to Machiavelli, the risk with auxiliaries is "valour". Auxiliaries are motivated by the opportunity to drive wealth from adventurism. If a buy side firm contracts with a sell side firm for an independently-functioning team, it is not out of the question that under competent leadership that sell-side firm will look to strike its own bargain with the market. It may develop expertise, capability, intellectual property or domain knowledge that it can monetize elsewhere. Alternatively, it may hold a customer firm hostage for better terms for some of these things.

The last category of forces - mixed - is in fact the most common in technology. Most firms don’t have a homogenous staffing model. They rely on contractors and outside firms for significant portions of their staff. Also, as mentioned above, there will be inconsistencies in the motivations of their FTEs. “One’s own” forces must be motivated by the wealth of the business (however “wealth” in the situation is defined) as opposed to personal income, to have it at risk, and to have a direct influence on the outcome. Very often, that isn’t the case among badged employees, which means a fair number will be mercenaries. They'll be motivated by individual interests that are not fully aligned, and may even come at the cost of their paymasters. There are also cases where there are auxiliary units lurking about in a business, especially technology: people who have worked together for many years for several different organizations, who form a shadow unit and eventually move to strike their own bargain.

People on the buy side and sell side of technology generally don’t recognize these distinctions. Generally speaking, people on the buy side (a) don’t recognize that their staff are mixed and not "one's own" especially in the absence of contractors; (b) don’t understand the consequences of their staffing mix (e.g., what does it mean from a retention perspective that people aren't first-and-foremost die-hard employees committed to the success of the business imperative?); (c) fail to understand the nuances of how to deal with each group specifically (e.g., in project crises, we tend to see a lot of rah-rah managerial fluff spewed forth from buy-side leadership to sell-side people who are completely disconnected from the business situation at hand); and (d) have no idea the risks and opportunities of each group.

By the same token, the sell side doesn't appropriately approach the market. Sell-side firms that aspire to be "auxiliary forces" talk as if they can be "one's own" (the ubiquitous word "partners” is usually invoked), yet they usually sell themselves as mercenaries to the classic formula of people x time x rate. In this effort based formula the risk is borne by the buyer, but the impact of mercenary pricing cuts both ways. Sell-side firms very often end up in mercenary situations yet fail to price and structure it to reflect the “income” that it really is, mistakenly believing they're developing a vehicle for “wealth” (i.e., a sustainable business opportunity.) Finally, sell-side firms typically fail to understand the full terms and conditions required of both parties for the supplier-vendor relationship to be fully aligned to perform as “one’s own” for the business mission at hand. Very often, they export the problems they have as a sell side business (such as hitting revenue targets or maintaining margin) into the value proposition offered by the sell side. It comes as no surprise that in the end, they default into a cost or "mercenary" engagement model.

The nature of forces – and the consequences – haven’t changed all that much since the dawn of time. The lessons of Machiavelli for the state apply to both technology buyer and seller alike.

The buy side sources staff from a market overwhelmed with sell-side firms offering technology specialists, vertical market expertise and bodies in bulk. The buy side needs to have the right expectation for the right type of firm. The large-scale staff-aug firm has some of the characteristics of an auxiliary, but when it comes right down to it aren't they really just a large mercenary outfit? And does a firm with deep vertical "practices" have aspirations to monetize (possibly to our disadvantage) the expertise derived from the solution we're engaging them for? Alternatively, are we trying to engage a genuine partner firm in a mercenary model? For that matter, do we do things on the buy side to create the circumstances that allow us to engage "one's own" forces? Perhaps most importantly, do we recognize the fundamental characteristics that make a person or a firm suitable for that kind of engagement?

The buy side also needs to consider the project mission. Perhaps the organizational politics have compelled us to go in pursuit of some boondoggle but we know that sooner or later, people will come to their senses and cancel the project. Or perhaps we have a situation where we need to prop up a project deliverable only until we complete negotiations for an alternative solution. In such cases, the buy side firm would be foolish to allocate "one's own" forces, and would be better off to engage mercenaries or auxiliaries.

Curiously enough, a lot of business press has covered this from the perspective of the buy side. It’s worth reflecting on this in greater detail from the perspective of the sell side, or the supplier of “forces.” That will allow sell-side firms to recognize the right characteristics, opportunities, and circumstances for deploying capability across their customer portfolio.

Firms on the buy and sell sides – from established to start-up – experience this phenomenon. Many buy side firms wish to engage, and many sell side firms wish to be engaged, as "one's own." To do that requires trust, which doesn't come easy and must be earned every day. It also requires some form of a shared opportunity model, and very, very few examples of this exist today. This isn’t to say that true partnerships can’t be forged, but instances of this are the exceptions and not the rule in technology. Auxiliary and mercenary buying patterns – transacting for specialized knowledge or bulk capacity (people x time x rate) – are the rule in IT.

A fully aligned partnership - that is, sourcing for "one's own" in Machiavelli's model - is possible only with like minded people who form deep relationships built on a firm foundation of trust and fundamentally aligned interests in achieving a business goal. Those like minded people on whom you can build that trust relationship are hard to find, and they're few and far between, but seek them out and you'll build mutually sustainable businesses.

Sustainability versus Efficiency

2010-01-23T21:34:00.002-06:00

My friend Bradford Cross posted an interesting blog on wages last week. It’s a great piece, particularly his comments on Henry Ford's approach to business profitability.

To a great extent, the Ford model Brad refers to is dependent on the combination of volume and productivity. That aspect of the model came to a screeching halt for Ford in the 1920s when the Model T simply passed its "sell by" date. Once the product outlived its market, sales volume dropped. They not only discontinued production in response to growing inventories, they didn’t have their next product, the Model A, out of the design phase. They were forced to shut down the line for months. That put quite a dent in accumulated profitability. They also lost their lead in market share.

The focus on volume and productivity drives businesses to aggressively remove cost and increase productivity from repeatable processes to maximize profitability. In so doing, they're not focused on sustainability, they're focused on efficiency.

Sustainability requires constant change. We have to constantly think about the surrounding business conditions: labor patterns, competitive threats, customer needs and so forth. Sustainability requires us to be primarily concerned with where the business is going to be tomorrow. Efficiency requires everything to stay the same. We luxuriate in the simplicity of holding everything else constant when we focus solely on efficiency. When we pursue efficiency, we're focused on where the business is right now.

In the extreme, we optimize relative to the circumstances of this moment in the hope - the hope - that time will stand still long enough for us to draw an income, have 2-point-something kids, take a decent vacation every year, and accumulate sufficient wealth to retire.

Hope may be audacious, but it's a lousy strategy.

In efficiency-centric businesses, it’s not uncommon to find people doing substantially the same things that people were doing 10 years earlier. Because the definition of work is consistent, it’s repeatable, and that makes everybody's job that much simpler. That's true for everybody in the business: people on the line do the same tasks, people in HR recruit for the same positions, people in finance forecast costs in the same business model, and so forth. When things don't change all that much - markets, supply chains, etc. – a business can make a lot of money, and individual wage earners draw a steady income. But in an age when things change a lot, you can't make a lot of money this way for very long. A business optimized relative to a set of circumstances that are artificially held constant is a business in a bubble. Production of any sort can't operate in a bubble. At least, it can't operate in one for long. The longer it does, the bigger the mess when the bubble bursts.¹

Brad mentions that Ford's model was more complete than volume and productivity. There's another dimension that, if executed, makes a business sustainable and less prone to seismic interruption: constant innovation in response to external factors. With that must also come invention, which is of course not the same as innovation. This is also not the same as internally-driven innovation. To wit: while shaving a few seconds off the time it takes to tighten a bolt might make bolt-tightening more efficient, it's useless if the market has switched to rivets in place of bolts.

If we aggressively evolve both what we make and how we make it, nobody in production will be doing what people were doing 10 years ago, because those jobs didn't exist 10 years ago. They won't exist 10 years from now, either. In fact, we don’t want entire categories of jobs that exist today to exist a decade from now. This means we have to be less focused on the known (what we’re doing) and more focused on the unknown (what should we be doing?) This makes work a lot harder.

Well, as it turns out, building a sustainable business is hard work.

In innovation-centric firms, production isn't in a bubble. In fact, it's very much integrated with its surroundings. That's where Brad's reference to “worker skill” comes into play. In technology, it’s more than just a question of skills: it’s a question of both capability and the passion to acquire more knowledge.

This may seem to be blatantly obvious: of course those are the workers we want. How hard can it be to hire them? It’s just a recruiting problem, right? Brad specifically makes the point that there’s a (wildly mistaken) school of thought that assumes we can get the best people by spraying a lot of money around.

If only it were so simple, as Brad points out. It's very difficult to succeed at this, not only because it requires a change in recruiting behaviours, but because it means significantly disrupting an internal business process. That's harder than you might think: the efficiency-centric mindset is firmly entrenched in business, government, and the universities that educate the management that run them both.

Efficiency-centric firms are process heavy. The people in these firms - badged, independent contractor and supplier alike - are very heavily invested in that firm's processes. Subsequently they resist change to the processes and practices that they have worked so hard at mastering and making “efficient.” This creates organizational headwinds so resistant to change they can bend solid steel. Any "change initiative" that isn’t blown away by these headwinds is corrupted by it. So, the boss says knowledge is power, and he's told us we’ve got to have the most knowledgeable people in the business? No problem: we’ll show how knowledge-hungry our people are. HR will set up some computer-based training and tie a portion of management bonuses to the number of training hours their people “volunteer” for. Managers will then measure their supervisors on training hours their people receive. Supervisors will set a quota for laborers. Laborers will fill out the necessary form to show they’ve hit their training quota, and circulate answer keys if there’s a test at the end so that nobody fails to meet their quota. The efficiency-centric system returns to balance with no net impact: laborers aren’t inconvenienced, management receives its bonus, and the organization can now measure how much they "value knowledge." Everybody plays, everybody... well, it's complicated. Those who lead the initiative "win" because they can report that a measured improvement took place on their watch. Those who sponsored the initiative are "reaffirmed" because the firm can now prove they have knowledge-hungry people. The rest don't necessarily win, but they certainly "don't lose." And isn't that the point these days, to make sure everybody is a winner?

We see this pattern repeated with all kinds of well-intended initiatives, whether it be a mission for zero defects or a drive to be Agile. People will do everything they can to sustain that which they have already mastered, even to a point - misguidedly or maliciously - of giving the appearance of innovating and changing. Efficiency-centric organizations have stationary inertia that is extremely resilient to internally-initiated change. Only when an external event trumps every other priority - and most often it has to be a seismic event at that, such as the complete evaporation of revenue - will a bubble burst.

This kind of industrial thinking has made its way into IT. We assume our external environment (labor market changes, technology changes and so forth) are static, so we stand up a big up-front design, put together a deterministic project plan, and staff at large scale to deliver. We also see it more subtly when people look to code "annuities" for themselves: systems that are business-critical that they can caretake for many years. This creates an expectation of job security and therefore recurring income. This isn’t just a behavior of employees or contractors looking for stable employment: there are consulting businesses built around this model.

Going back to Brad's blog post, this creates a wage discrepancy and with it, a bubble. People who accept the annuity make the erroneous assumption that the rising tide of inflation will sustain their income levels. It’s actually just the opposite: the minute somebody is working in one of those annuities, their skills are deflating because they're not learning and accumulating new knowledge. So is the asset value of the thing they're caretaking. The people who do this misread the market (e.g., assume an outsized value of the asset to the host firm) and subsequently have a misunderstanding of their wage sustainability. The resultant wage bubble lasts until the "market" catches up: either the host firm takes costs out of maintenance (e.g., by labor replacement) or retires the asset. The person who was earning what amounted to an outsized income by being in this bubble faces that same seizmic correction as Ford did in the 1920s if they're not prepared with their own "Model A" of what they're going to do next.

The mis-fit of the industrial model in technology is that industrialization makes no provision for capability: each person is the same, the only difference being they're either more or less productive than the average, and indexed accordingly. That completely ignores the impact of destabilizing change that people make in what they do and how they do it. Disruptive, externally-driven innovation should be the rule, not the exception. Of all lines of business, this should be the case with technology. And with the right group of people, it is.

Disruptive innovation pops a bubble. A popped bubble threatens entrenched interests (e.g., those who have mastered life inside the bubble). But disruptive innovation is what makes a company sustainable.

¹ I am indebted to my colleague Chereesca Bejasa for using the term "bubble" to describe a team operating to a different set of processes and behaviours within such an environment. Just as a team can be in a bubble relative to the host organization, the host itself can be in a bubble relative to its market.

Is Google to IBM as Apple is to Apple?

2010-01-22T21:08:00.006-06:00

In the late 1970s, the microcomputer industry was still in its emergent stages. Microcomputers weren’t nearly as powerful as mainframe and minicomputers. There also wasn’t clearly a “killer app” for them. But at the time, it was obvious that microcomputers were going to have a significant impact on our lives. People bought computers for home and used them for work. They even brought them from home and used them at work. While the software was primitive, you could solve many different kinds of problems and perform sophisticated analyses more efficiently than ever (e.g., the simple "what if" forecasting that we can perform in an open-source spreadsheet today was a major breakthrough in productivity 30 years ago). Having a microcomputer in the office was something of a status symbol, if a geeky one. And they made work fun.

The microcomputer industry had some other interesting characteristics.

Most corporate technology people (working in a department known as "Information Systems" as opposed to "Information Technology") didn’t take microcomputers all that seriously. They were seen as primitive devices with little computing power. Toys, really. From the perspective of the technology establishment, “micros” were only really useful if they had terminal emulation software (such as VT100, 3270, 5250) so they could connect to a more “serious” computer.

It was a highly fragmented market. There were lots of different combinations of architectures, operating systems and CPUs. There were also lots of different manufacturers, each offering their own standard and going in pursuit of business users, including firms such as Osborne, Sinclair, Commodore, Tandy and a rather unique firm called Apple Computer.

No one microcomputer platform was dominant. Each sought to develop and sponsor a library of applications and add-ons so they could sell hardware. For the most part, each relied on value-added resellers as their primary channel.

IBM took a different tact when they entered the microcomputer market,. IBM didn’t compete against the rest of the microcomputer market. They created a new market for something they called a Personal Computer. Using off-the-shelf components they built an open platform that anybody could replicate. Through the combination of brand, applications and reach, IBM was the standard in the personal computer space. The prevailing wisdom at the time was that “nobody got fired for buying IBM.” This made personal computers a safe corporate investment, and made IBM the standard.

For a few years, Apple and IBM waged a pitched battle. IBM, or perhaps more accurately, the "personal computer" standard as defined by IBM, was victorious and for all intents and purposes remains the dominant platform today. And while they lost control of that which they had created, IBM had strong hardware sales, while Apple was for many years relegated to being a provider in niche markets such as education and desktop publishing.

Fast forward 30 years.

A handheld computer / smartphone industry has emerged in recent years, and it shares many of the same characteristics of the early stages of the microcomputer business.

Smartphones have been underpowered for much of the past decade, but it’s pretty obvious that they'll soon become very powerful and will have significant impact on our lives. The current "killer app" - e-mail - is really a utility function. The equivalent to the microcomputer's “’what if’ scenario” capability hasn't yet been identified for the smartphone. But it will, and these devices will change how we live and work. As with the early microcomputers, a lot of people have bought a personal smartphones, and it’s not uncommon for people to use their personal handheld for work (e.g., using an iPhone for maps/navigation). The smartphone a person carries is something of a status symbol, if a bit of a geeky one. And they’re fun.

Until recently, we’ve been force-feeding big-screen (1440 x 900 pixel) form factors into small handheld devices. That is, until the current generation of smartphone arrived, mobile devices were primarily made useful as “internet terminals” more than application processors, no different from the terminal emulation of a previous generation.

It is a highly fragmented market, with competing CPUs and operating systems. There are also lots of different vendors with proprietary products, such as Nokia, Blackberry, Palm and another called Apple Computer.

No one platform is dominant. Each is seeking to create and sponsor a library of applications as a means by which to gain market share. Most sell through value added resellers.

Google recently entered this market. In many ways they’re taking the same approach as IBM. By offering an open platform, anybody can build a Droid-compatible phone. They’ve built out a sizable applications catalogue in a short amount of time. They also have brand and reach, although it can't be confirmed whether somebody has been fired for buying Google.

It's interesting to see not only the same market phenomenon happening on a different technology, but that Apple Computer (and specifically Steve Jobs) is at the epicenter of it.

Perhaps it will turn out differently this time. Apple has been through this same dynamic once before. They can also learn from Microsoft’s unsuccessful attempts to make Windows Mobile an ubiquitous platform . And Google has entered the hardware business on the Droid platform, but they're not a hardware company. However, none of this may matter. In the 1980s, the value was in the hardware, but the lion's share of revenue in the Android market won't be in hardware sales. This means Google is following a similar pattern, but changing the attributes. They're not pursuing a 30 year old strategy as much as they're updating a strategy to be the dominant provider in a current market.

No matter how this plays out, it's shaping up to be an epic battle for platform supremacy, just as we experienced 30 years ago. The microcomputer industry was highly innovative in the 1980s. It was an exciting business to be in. No doubt the same will be true of the smartphone / handheld computer business in the 2010s.

It was Mark Twain who wrote, “History doesn’t repeat itself, but it does rhyme.” We’re witnessing this now. Best of all, we have a front row seat.

Restructuring IT: Anticipatory Responsiveness

2009-12-24T06:00:00.000-06:00

Michael Milken, the former junk bond king, has a charitable foundation. His foundation did some research a few years ago that determined that 70% of 7 chronic illnesses - things like diabetes, heart disease, lung cancer and so forth - are preventable through lifestyle change. They concluded that if people took better lifestyle decisions, doctors could focus their energies on enhancing and improving the quality and duration of life. But they can’t, because people create so much “remediation work” for them to do through poor lifestyle choices.

This is an apt metaphor for IT. We do a lot of things, such as introduce situational complexity and technical debt, that pile on the work we have to do.

This is at the heart of what we have to pay attention to in our restructure from industry to profession: if we know that we are not doing things that make more work to be done, and if we also know that we are doing things that consistently result in quality outcomes, we’re much less likely to self-inflict more work.

Restructuring IT requires us have a different set of expectations. When we follow traditional restructuring led with org charts and budgets, we take behaviours for granted. We simply can’t. Like US policy on nuclear disarmament in the 1980’s, we must trust, but verify.

The good news is, behaviours are actionable. There are things we can do to bring about the right behaviours in an organization. The bad news is, this is vastly different from everything we’ve been taught about reorganization.

The purpose of this restructure isn't to assign people into roles, but to build an IT organization that is durably, anticipatorily responsive. That’s a mouthful. “Durable anticipatory responsiveness” is the extent to which we’re consistently able to do things that allow us to get things done – complete things, useful things, not just bit twiddling. But it isn’t enough to just “get things done.” We have to avoid launching any self targeted missiles, like creating high-maintenance code and therefore high cost assets. So being responsive means doing useful things, and it means not making work for ourselves.

The “anticipatory” bit means that we’re doing things that allow us to look ahead to figure quickly out where we’re at risk, or where we have an opportunity. Anticipation is important. We’re not simply waiting around for things to happen. That was how IT applied Rapid Application Development. We tried it in the 1980s, and it let us be better, faster, cheaper… pick any two. We need to anticipate. We need to get in front of things. So, dealing with whatever comes through the door isn’t enough; we also influence the business agenda in a meaningful fashion. That means positioning IT as a peer with the business, not in a power struggle with it or subservient to it.

To restructure this way, we have a model . We look at 10 practices, each decomposed into 6 stages, that allows us to assess a team, department or organization. Each practice is explained in sufficient detail to allow us to identify how a team gets things done today, how people behave. We recognize there are behaviours that inhibit responsiveness (“regressive” behaviours), and there are increasingly aligned behaviours. Especially in the early stages of restructure, we want to establish basic collaborative behaviours, because we’re creating new work patterns among people in a team. We're building “muscle memory” of how people in a cross-functional team must work together.

Fundamental collaborative behaviours cannot be taken for granted. I was working with a program team last year that had hundreds of people working in different technology silos, delivering a solution that impacted 4 distinct lines of business. Originally, they were spread out across the building. The only physical organization they had was by area of technology (client-side devs sat together, server-side devs sat together, QA sat on a completely different floor, etc.) So we organized people into line-of-business teams and co-located them in the same physical space. But changing physical layout wasn’t enough to change behaviours, because somewhere along the way people ended up working on missions divergent from that of "develop a software asset."

One example of this was that teams were in the "defect tracking" business more than they were in the "defect fixing" business. Following the relocation, QA analysts were sitting next to developers in the same team, but rather than talk to each other, developers and QA continued to work independently and communicate exclusively via the defect tracking tool. Defect reports, questions, "non-replicatable" and "ready for retest" and so forth we're all communicated via tracking tool. Not surprisingly, this led to re-opens, failed retests, questions, requests for additional documentation, and all kinds of other hand-offs. That not only made the remediation process inefficient, it created very long histories of defect tracking activity that were more noise than signal as a lot of the data captured was irrelevant to the actual problem.

Because it was more important to show effort as opposed to results, they weren't behaving as a team delivering a software asset, they were behaving as a team that needed to track details about defects. By asking people to collaborate on solving defects at time of discovery, we were able to make defect repairs available sooner. In fact, it wasn't unusual for a repair to be available in a build in less time than it took to submit an initial defect report. Getting into a state where this was the de facto behavior did not happen simply because people were physically co-located and had some collaboration tools. It required active intervention by management working directly with developers and QA solving specific problems in a collaborative manner.

Behaviour change is not a one-time action. Team circumstances change: people come and go, technology is upgraded, business needs change, etc. That means we must constantly pay attention to behaviours if they are to be durable. To do that, we can apply the model as often as we need - annually, quarterly or monthly - to ascertain whether people are making good "lifestyle" decisions." This allows us to assess the extent to which we are restructuring the fundamental organizational behaviours to focus on results as opposed to effort.

However, we must be careful. Competent assessment is a capability, not a task. Assessment is not done by questionnaire or checklist, and "objective self-assessment" - asking teams to critically analyze their own behavioural restructure - is most often wishful thinking. It requires an experienced touch to apply a combination of archeology and sociology to separate the opinion of how people aspire to work from the fact of how they are actually working. Creating a competent assessment capability requires investment, but it is critical to success as the assessments provide the telemetry of restructure.

We now know that to be a results-based organization, we must reorganize around behaviours. We have a good idea of what those behaviours are from an established model. We can use this model as both guide to and instrumentation of our restructure. But before we go off in pursuit of restructure, we must first internalize some guiding principles. We'll cover in the next installment of this series.

Restructuring IT: Organizing for Results

2009-11-09T23:37:00.008-06:00

Up to this point in this series on Restructuring IT, we’ve looked at how IT has adopted an industrial model. IT has achieved scale, but at the cost of results, as is clear from the low rate of success of IT investments. We'll now take a look at how we can organize IT for results.

Professional versus Industrial

IT needs to reorganize for results, not scale. Organizing for results requires professionalism as opposed to industrialism.


People in industrial and professional situations each use drills, but you wouldn’t staff an assembly line worker in an operating room to get "capacity" on a surgical team.

To get professionalism, we need to organize less to try to be predictable (which will always escape us) and more to be responsive and accountable.

Let’s think about the things that would professionalize IT.

Instead of scrambling just before a deployment, what if every solution build acted as an internal gatekeeper of quality, continuously executing to validate technical, functional and non-functional completeness of everything we do?

Instead of trying to “inspect quality” into IT, what if testing were a team responsibility, automated and integrated into what we do daily?

Instead of watching big-up-front designs morph from whiteboard masterpiece to over-engineered Frankentecture, what if teams had the flexibility to take design decisions in near-JIT fashion, with a minimum of duplication and the fewest moving parts possible?

Instead of a “requirements arms race” between business and IT, what if we were able to accommodate continuous business involvement, facilitated to enable continuous change management and adaptive project management?

Instead of standing up volumes of impenetrable and unactionable requirements, what if we had short, business oriented requirements that could be quickly steered through development and QA and into production?

Instead of sending round reams of paperwork for PMs to fill out in little more than CYA exercises, what if we were able to govern IT non-invasively, ascertaining from our delivery teams whether they’re delivering value for money, and working in accordance with expectations?

We have the means by which to do all of these things. Today. Right now. But we can’t simply will them into place. To get these things, we need to restructure IT.

What does it really mean to “restructure”?

Before we discuss what restructuring IT is, let’s first understand what it isn’t.

Restructuring IT isn’t a question of org charts. All too often, new reporting lines just rearrange the deck chairs on the Titanic. It also isn’t about budgets, either: we can’t do more with less, because there isn’t that much less with which we can get any more done with.

How about the management cheerleading of recent years, things like “be close to your customer” and “have fewer hand-offs in your work processes.” When folks like Tom Peters started putting those messages forward in the 1980s they were a wake-up call that business had gone adrift. And yes, we need to restructure with this in mind. But we can’t have reorganization by platitude. We need something actionable.

Restructuring IT is about behaviours. Changing behaviours away from industrial thinking to professional thinking is a pretty big shift. Among other things, it means each person is responsible not just for doing the tasks they’ve been assigned, but doing what is necessary for the project to succeed.

Think back to the surgical team metaphor. As my colleague Greg Reiser points out, the surgical team collaborates toward a shared objective, improving the quality of life of the patient. Their primary goal may be to graft blood vessels that bypass a coronary artery blockage, but their objective is to prolong the life of the patient. What does the team do when they discover, as they almost always do, that the condition of the heart and surrounding tissue is not exactly as they expected? They apply their professional expertise and work as a team to adapt in order to achieve the primary objective. This is how professionals behave.

It doesn’t help, of course, that there are so many headwinds to getting things done in IT, ranging from a constant cycle of upgrades that change points of integration to an abundant supply of people without the complete gene in their DNA. Results are hard. Finishing stuff is hard.

This begs a critical behavioural question: why take the risk of getting “results”? Why put yourself on the line, underwriting success with your personal guarantee, especially if you have a built-in scapegoat? I met with a team last year where the PM, BA and dev lead knew a project was going to fail, because the development team simply didn’t have the capability. The project leadership didn’t make any effort to change staff, because the decision of who to staff was somebody else’s: people were supplied to them by procurement. The project was conspicuous because it was late starting as it was, so their priority was to get started. Never mind that they knew it wouldn’t finish. In the end, they could say they simply played the hand they were dealt by the organizational structures – in this case, an industrial-inspired procurement function – that existed to make IT effort “cost effective.”

So rather than work to success, rather than pressing the button and stopping the line and saying “this project is going to fail and we need to do something about it before we make a commitment of capital and time” they simply got on with the work knowing they were going to fail.

This is all too common. There is structural disincentive to achieve results in a lot of IT organizations. This disincentive is supplemented with soft scrutiny. Most measures of “complete” amount to little more than people working to a state where nobody can tell them they’re not done, instead of working to a state where somebody can conclusively tell them they are done.

So what makes us think people will make the effort to get things done?

It also makes you wonder: how much of this is going on in your IT organization today?

In our next installment, we'll take a look at how, specifically, we restructure for results.

Join Your Peers at an Agile Governance or Budgeting Event In October

2009-10-16T08:00:00.007-05:00

October is normally a heads-down month. In addition to being in the home stretch of meeting our yearly objectives, we must dedicate cycles to shaping, communicating and justifying our plans for next year.

October is also a busy month for information sharing. The thoughts and ideas that have percolated through the year reach their maturity about this time, and we want to share them before everybody goes on their winter holidays. ThoughtWorks has no shortage of events coming up, and I am privileged to be a part of many of them.

If you’re in Chicago on Tuesday October 20, ThoughtWorks is hosting a panel discussion on the Budgeting and Financial Implications of Agile. On the panel are experienced IT leaders who head strategy, portfolio management and application development for their respective businesses. They've come to terms with balancing short-term operational flexibility with long-range budget forecasting. Stop by the Aon Center at noon if you can, but please register before you do.

Our first webinar in the Agile PMO series, Real Time Metrics, was very well received. We’re pleased to present Real Time Governance, a follow-on webinar that extends the concepts to their next stage of evolution. I’ve had the opportunity to present the Governance material with my ThoughtWorks colleagues Jane Robarts and David Leigh-Fellows in Calgary, Toronto (which was recorded and is available on InfoQ) and San Francisco. We’re broadcasting this next as a webinar with a full Q&A session on Thursday, October 22nd. The response has again been very enthusiastic, but with virtual seating at a webinar there are unlimited spaces, so please feel free to register and attend.

Members of the Project Portfolio Management Professionals association attended our Real Time Governance presentation in San Francisco last month and invited us to present it to their membership. I’ll be presenting to the PPMP via webinar on Friday, 23 October. If you are an IT leader with project portfolio management responsibility today, I strongly encourage you to look into this association. Take a look at their website or reach out directly to them for an invitation.

If you’re in Dallas on the 27th, I’m hosting an executive roundtable on Financing and Budgeting Agile projects. ThoughtWorks hosted a similar event in Chicago back in August. The people who attended that event have self-organized a micro-community. We’ve had a follow-on event and lots of peer-to-peer conversations as we mutually educate and collaborate on the unique funding and forecasting challenges and opportunities presented by Agile. Reach out to me directly if you're interested in attending the Dallas roundtable.

Finally, ThoughtWorks is sponsoring Agile East at the end of October in Philadelphia on the 29th and New York on the 30th. We have a powerhouse lineup of experienced, thoughtful practitioners, including Martin Fowler, Graham Brooks, Premanand Chandrasekharan, Carl Ververs, Joe Zenevitch, Shyam Mohan, Greg Reiser, Andy Slocum, Tiffany Lentz, Manu Tandon and Alla Zollers. This is an outstanding group of people and I’m humbled to be a presenter among them. I’ll be giving the noon keynote on Budgeting and Financial implications of Agile. Specifically, I'll be looking at how Lean and Agile allow us to maximize capex but require us to be extraordinarily diligent to prevent the perfect storm that can create an IT liquidity - and potentially IT solvency - crisis. I can’t stress enough what a stacked lineup of people this is. Make plans to be in Philadelphia or New York at the end of the month, just be sure to register.

Restructuring IT: The Detroitification of IT

2009-09-25T20:26:00.010-05:00

In previous installments of this series on restructuring IT, we looked at how IT has adopted industrial practices as it has gone in pursuit of scale. As a result, IT bears striking resemblance to Detroit automakers. Let's look at some common characteristics.

Sub-Optimal Quality

Detroit suffers its periodic crises of quality. There was a joke that made the rounds during the 1970s that you know you have an American car when you get the factory recall notice in the mail. In much the same way, industrial IT is notorious for low technical quality of what it produces.

Long Time-to-Market

Detroit has excessively long product development times. It takes years to go from idea to availability. Former Chrysler CEO Lee Iacocca famously went on a tirade when he wanted to see what the LeBaron would look like as a convertible. His design manager told him something to the effect that they first needed to do a scale model, then a wind tunnel, then the prototype, so they’d have it for him in about 6 months. Iacocca’s reply? “Just take a chain saw to the roof!” How many CEOs look at their IT department and ask, “why is it so hard to get anything done in IT?”

Too Much Leverage

Detroit got by for so long because it could “pull demand forward.” Very few people pay cash for their cars. Instead, they finance their purchases. They're buying a car based on future earnings, not on their accumulated savings. Think about what happens in industrial IT, in terms of capability. There’s far less supply of “bankable capability” than there is demand. Instead, the industrial IT model looks for capacity. It puts people new to the IT industry in a position to put code on the line, learning as they go along. In effect, the industrial IT model borrows against future capability development. There’s even a few firms that have bet their entire business on this model.

As my colleague Greg Reiser pointed out recently in a webinar we produced for cio.com:

The extreme case of this are the large IT outsourcers that have rapidly grown over the past 20 or so years. Many firms that have actually bragged about their ability to add over 1,000 new professionals per month! Now while I can comprehend the ability of the US Marine Corps to add new soldiers at that rate, I personally cannot comprehend how a professional services organization can effectively add, develop and assimilate knowledge workers at such a pace. So I am not surprised when clients of these firms complain about the shallow depth of talent assigned to their projects. Remember, although the Marines put all recruits through a rigorous 12-week training program, every single one of those recruits is still just an entry-level soldier at its conclusion. It can take years to train and groom people for more challenging roles. Why should you expect different for software engineers?

Producing Solutions People Don't Want, but Have No Choice But To Use

Finally – and this one is arguably a bit of a stretch – Detroit has suffered eroding market share for many years. In many cases, they’re turning out cars people don’t want to buy, year after year. Increasingly, the people who do buy the cars are the people who have to buy the cars. E.g., they’re people who are in the automotive ecosystem. Sound familiar? IT stands up solutions that business users don’t want but have no choice but to use because they're in the corporate ecosystem.

A Troika of Trouble

There are three factors accelerating the rate of Detroitification of the IT industry.

We have a capability shortage. For one thing, we’re not developing “heroes” in sufficient numbers to prop up this system, the folks who can jump among silos to do the unperformed tasks lost in the handoffs that happen in specialization. For another, IT isn’t the destination employer for people that it once was. (And by the way, neither are automakers.)
We’re overloading on “situational complexity.” To get something done in most IT shops a developer has to be fluent in an esoteric landscape of existing systems, policies and procedures. Somebody might be the smartest developer in the world, but they'll make no impact unless they invest time in mastering the esoterics. That’s not attractive knowledge for somebody to acquire, because it’s not portable. There's not much value in having “I learned all the weird stuff necessary to get things done in this specific functional area of company x” on a resume. It’s also a frustrating experience, as very often the people alleged to have the right information aren’t really authorities themselves.
Quality is assumed. Solutions delivered today are laden with technical debt, but very rarely is anybody looking for it. Apply metrics over just about any codebase in just about any company, and the odds are that you'll find at least one of the following: excessive complexity, excessive duplication, poor encapsulation or excessively long methods.

An increase in situational complexity, plus an increase in technical debt, combined with a decrease in total capability gives us exponential growth of people expending effort but showing little in the way of business results.

We should obsess about results, not scale. Scale is useless if we can’t get stuff done.

We’ve had a look at the problems with industrialization. Next, we'll look at how we can reorganize IT for results.

Restructuring IT: "Too Big to Fail" Doesn't Equal Success

2009-08-21T08:00:00.000-05:00

By going in pursuit of scale, we’ve created an IT function that is “too big to fail” in many businesses. Companies depend on IT – many can’t operate without it – yet they don’t really understand it.

The result is moral hazard. Moral hazard is the proverbial “heads I win, tails you lose” scenario: a person takes boneheaded risks knowing that if they turn sour, somebody will come to their financial rescue. There is tremendous concern that we're witnessing this in financial markets today: banks bought high-risk collateralized debt obligations with borrowed capital to juice returns, only to need the US taxpayer to intervene to rescue them when the value of those assets collapsed and the market for them dried up. The moral hazard of the situation is the disincentive for the banks to be prudent risk-takers in the future: if a person knows somebody will bail them out, there's no reason not to take boneheaded risks again.

This describes IT. We stand up massive projects that fail more often than not. When they fail – 6 out of 10 times mind you – the business sponsoring the initiative bails it out. And there’s no downside risk: those people who were bailed-out continue to hold down their jobs because “they’re the only ones who know the system.” They might even get promoted. This creates moral hazard in IT, as it builds in the expectation that success of the project is optional.

This is the result of industrial thinking. IT defines highly specialized roles that assume people perform repetitive tasks. This allows IT to scale by hiring armies of people, each into a very narrow position, making people expert at one very specific piece of the solution chain. Unfortunately, it also makes the success of a project an abstract goal for each person, and success of each person a relative goal. Restated, in the industrial model each person is less responsible for success of the project, and solely responsible to show that they did exactly as they were told.

Think about an IT project a long-jump team, staffed not with one person who can jump nine feet, but nine people who can jump one foot. Clearly, the results aren't going to be the same.

This is why we’ve hit the limit with industrialization. Industrial IT assumes people are automatons performing specialist tasks in a repetitive fashion. That assumption is diametrically opposed to our business partners' perceptions of IT as a source of innovation. An industrial approach that values specialization and repetitiveness implicitly stifles innovation, invention, initiative and leadership. It bleeds out creativity. I had a colleague tell me the other day that two people on a team he was working with would sit and stare at the wall until told exactly what to do. Once done, they'd go back to staring at the wall. That’s industrial IT in action, and it's devoid of innovation.

We've seen this same industrial phenomenon in other professions. For example, when professional sports leagues expand, the quality of play goes down. Consider baseball. When Major League Baseball expanded a little over a decade ago, players posted outrageous offensive statistics. The reason? There were a lot of pitchers in the major leagues who weren't really "major league." They were just people hired to fill the roster, to hold a spot in the rotation. On the days those people would pitch, the team managers would hope only that they wouldn't hurt them, more than they had any hope that they would actually help.

We have this in IT. They’re called “net negative” people. These are people who create more work for people to do than actually solve the problems we need them to solve. Analysts who write requirements that need to be substantially re-analyzed before they can be turned into code, developers who write code that is of such poor quality that it needs to be rewritten before it can be released to QA, or testers who execute test scripts without being able to pass or fail them because they don't really understand what it is they're testing in the first place all create more work for people to do than they contribute. Overall, they're "net negative" to the project.

Businesses will be restructuring for quite some time. That amplifies the risk of a late-stage project failure to IT, because project bailouts are less likely in this business climate. To come to terms with this new environment, IT needs to be less concerned with industrial scale, and more concerned with bottom-line results.

Before we get into the details of how we need to restructure IT, we'll first take a look at the similarities between the state of mature industrials and the characteristcs IT is showing today. We'll also look at the factors that are accelerating IT toward the same fate as the US automakers.

Restructuring IT: A Different Look at the Business-IT Relationship

2009-07-22T14:00:00.000-05:00

The relationship between IT and its business partners is notoriously bad. Year after year, surveys by different research organizations report that improving that relationship is a top-10 priority for CIOs. But despite being a high priority for many years running, it hasn’t improved all that much.

Before we can make any headway improving that relationship, we must first understand how IT's pursuit of scale is responsible for a lot of the dysfunction.

Let’s take a look at what the business and what IT each want from the relationship.

First, what does the business want from IT? To put that question in perspective, we need to externalize a bit. Let’s think about what we want from the relationships we have with our key suppliers, such as the place where we go to get our coffee in the morning.

We want results from our suppliers. In our example, we want our coffee in whatever configuration we ordered (hot or iced, cow/soy/no milk, etc.) within a reasonable amount of time after we order it.
We want to work with professionals: we don’t want to see people scratching their heads wondering how to grind beans or froth milk. We also don’t want to hear somebody tell us that pouring drip coffee into an insulated cup “isn’t their job.”
We want a relationship. A couple of months ago, the WSJ ran a story that people are less likely to cut back spending at places where they have a relationship with the firm, even if their household income statement tells them they need to make severe cuts. This certainly rings true in our coffee shop example: we like it when people recognize us, and have our drink ready for us before we order.
We want innovation. If somebody offered us a cappo-moca-latte we’d probably give it a try. We want to know people are thinking about our needs and our experience as a customer.
We want to trust the people with whom we do business. Certainly, we want to know that we get a full cup of coffee, with ingredients that aren't spoiled.
We want value for money. We may very well pay $2.75 for a cup of coffee, but we have to feel that the coffee we're getting is worth that $2.75.

This doesn’t really describe how IT has approached its relationship with its business partners. Historically, it's had a different set of priorities.

IT has been in pursuit of “big” as opposed to results. To get “big,” we’ve created specialist roles so we can train and staff armies of people.
IT keeps business partners at arm’s-length: it’s been “you do the business, we’ll do the technology.”
IT prefers predictability over innovation. In technology, Java is the new Cobol. Also, IT project management is most often an excessively detailed project plan that tries to define every action that people will take far into the future.
IT doesn’t look to establish trust, as much as we want people to have faith that we'll overcome whatever problems we may encounter.
People in IT are generally more interested in solving interesting technology problems than they are providing value for money.

What we end up with is a pretty big relationship gap. IT is opaque. IT solutions are laden with technical debt. There aren’t enough cross-trained heroes to bridge the gaps that exist among all those specialists. Each partner in this relationship has an unhealthy dependency on the other: business can't function without IT, and IT reacts more than it leads critical business decisions. The bottom line? IT still has a success rate no better than 4 in 10.

So it really shouldn't be a surprise when we hear a CEO, CFO, COO or even a CIO ask, “why is it so difficult to get anything done in IT?”

The Case for Restructuring IT

2009-06-29T10:17:00.004-05:00

Business is tough right now, and it’s going to be so for a while. In tough times, you want to be very good at what you do. The more “fighting fit” you are, the more likely you are to survive a challenge.

Unfortunately, IT isn’t all that good at what it does. In fact, on the whole, it’s pretty bad. That means that IT isn’t very well prepared for this downturn.

How bad is it? The research organizations have historically reported a pretty high failure rate of IT projects: about 30% of all IT projects fail outright, while another 30% disappoint their business sponsor (e.g., excessive cost, wrong functionality).¹ On the whole, an IT investment has, at best, a 4 in 10 chance of success.

Companies are already reticent to invest in this climate. IT doesn't offer scared capital a safe haven.

It also suggests that IT is on a trajectory of self-destruction. If we want to look ahead to where IT is headed, we need look no further than present day Detroit.

Photo credit: Ben Wojdyla, The Ruins of Detroit Industry

How did this happen? Consider some of the forces that have shaped the current IT landscape in the past 20 years. The steady growth of IT that was accelerating slightly with the advent of client/server gave rise to explosive growth driven by the combination of internet and Y2K. By the mid-1990's, demand for IT was dramatically outstripping supply. To satiate this demand, IT went in pursuit of scale. To get scale, IT took professional jobs and codified them into industrial tasks, because it’s easier to staff vast numbers of people in highly specialized roles than it is to develop professional capability to solve business problems using technology.

Today, businesses buy, recruit, staff, govern, gatekeep, develop, analyze and test following a model that puts a priority on “big.”

Unfortunately, all the time we’ve been in pursuit of scale, we’ve not been in pursuit of results. Results are assumed. We assume armies of specialists will follow an explicitly defined project plan to produce a solution that is technically sound, functionally complete, and financially satisfactory, all with minimal risk of impairment.

With a 4 in 10 batting average, results cannot be assumed.

By placing a priority to scale, IT mistakes effort for results. We often see success expressed as a function of hours to be invested. It isn’t that simple. Successfully delivering an IT solution is a function of a lot of factors, such as clear communication, effective collaboration and capability; well-informed decision making about technology, functionality and commercial viability throughout the life of a project; flexibility and responsiveness; and ultimately, producing meaningful things for our business partners. These can’t be captured in task orders and forecasts of work effort. They’re lifestyle decisions of how IT goes about its business.

It is time to restructure IT, to move away from an effort-centric industrial model, towards result-centric professional one.

¹ As an example, the 2009 CHAOS report from The Standish Group shows that things haven't changed all that much, reporting 44% of IT projects were challenged (late, over budget, and / or with less than required features and functions) while another 24% failed.

Are You Ready to Restructure?

2009-05-13T12:26:00.012-05:00

Global business faces unprecedented changes. Earlier this year, I wrote in an article for alphaITjournal.com:

Revenue forecasts aren’t materializing, capital structures are proving unsustainable, and operations are being scrutinized for inefficiencies. This, in turn, means that businesses are being completely restructured in how they are capitalized, organized, managed and governed. As businesses restructure, so will IT.

The need to restructure will be with us for a while. The financial economy isn't functioning normally, as capital markets remain on life support. The real economy isn't functioning normally either. We're still in the midst of business bailouts. Bailouts will give rise to bankruptcies, which will give way to restructuring. "Restructuring," says Gilles Moec, economist with Bank of America, "is very much the story of 2009." And business leaders seem to expect to face restructuring for some time: in a recent survey, IBM found that 91% of CEOs believe they need to restructure their businesses.

IT won't escape this phemonenon, and it must also restructure. Procurement, management and execution of IT have traditionally been focused on effort. IT has the opportunity to restructure for results, to be a transparent, efficient, responsive and collaborative participant in the business. There is tremendous upside for doing this, as it will make IT less a captive supplier of technical services, and of more an engaged business partner.

ThoughtWorks recently released a webinar I recorded on restructuring IT. I've also posted articles specific to restructuring IT on alphaITjournal.com. One covers challenge of change management during restructure, the other governing restructure. In the coming months, I'll be posting a blog series on IT restructuring that covers the deficiencies in the "industrial IT" mindset, defines a better future state for IT, and ways to go about remaking an IT organization to achieve that.

IT faces unprecedented challenge today. We have our work cut out for us, but we already have many of the solutions at hand that will allow us to meet those challenges. The opportunity is there for IT to get in front of this, and be at the forefront of corporate leadership. In turbulent times, better to be in a leadership role than relegated to a supporting position.

The Agile PMO: Becoming a Real Time PMO

2009-04-14T14:00:00.000-05:00

In the prior installments of this series, we presented a pattern for how PMOs can better bridge the gap between executive and executor:

First, we discussed the need to define progress in terms of business needs met and not technical tasks performed, so that we measure in terms of results, not effort.
Next, we showed how we can track and forecast progress in these same terms – e.g., by using burn-up charts – so that we have unambiguous line-of-sight into what a team is actually doing. Again, consider the spiral diagram: we can dive into the details without any “translation” between a status report and day-to-day execution.
Then we presented how we can measure meaningful attributes on the asset itself so we have strong, clear signals of underlying quality and a more complete picture of what it is we’re creating: harmonious greenfield or toxic brownfield.
Finally, we saw how we can vastly simplify the burden on our delivery teams by automating metrics collection.

By doing these things, we align team execution with the needs of the PMO. This makes us more effective at governing IT:

By reconciling actual results with our business cases, we know the in-flight NPV we’re tracking toward. This gives us a continuous assessment of whether we’re getting value for money of our IT investments.
By exposing the quality of the application itself, we know whether we’re producing IT assets in accordance with expectation.

From the PMO perspective, the instrumentation we have of every project team looks something like this:

A few years ago, the blue boxes in this diagram were disjointed, independent activities. Today, we can automate and integrate collection to a point where in the PMO we can know what’s going on in any given team. If we're using a product like Mingle, our performance reports are updated every time somebody advances status of a story card. If we're using a product such as Cruise, our quality data is updated every time a build is triggered.

This gives us real-time information on what matters the most to us in the PMO. We have visibility into our project situations: scope changes, performance changes, lags, as well as the quality of the asset being created (and by extension, a limited degree of knowing how they’re going about doing it). We have this in near real time. It’s not burdensome: it’s an extension of what people are doing, and it lives within the tools. It’s not conjecture: it’s a reflection of functionality that works and driven right off the asset.

Becoming a Real Time PMO

So, that sounds like a great future state to target, but it won't happen of its own volition. What can we do today that will help us become a “real time PMO?”

If you have no Agile projects in flight now, stand up a couple. There are different adoption patterns, but one very common approach is to start with requirements shaping and “level 1" Agile practice adoption. As you stand up Agile projects, define each of your gatekeepers to be functional, tested, useful and deployable asset. Avoid having any gatekeeper (aside from the project chartering phase) that consists of deliverables that merely describe an asset.

If you have Agile projects, but adoption is inconsistent or you're not seeing the impact from Agile practices that you anticipated, scrutinize the state of Agile adoption in your project teams. Before building out a PMO, it's important for team fundamentals to be in place. Not all change is created equally, and Agile adoption takes time. Perform an Agile Maturity assessment to identify practice gaps and call out actionable items teams can do to bridge those gaps.

If you do have well-running Agile projects, hone in on metrics collection, automation and consolidation. Take a look at Mingle and Cruise from ThoughtWorks Studios. The build pipeline management features in Cruise are pretty impressive. Be aware that there are ramifications to increasing team visibility. Don't assume that this is simply an exercise in implementing tools, and be prepared to iterate to achieve greater degrees of transparency.

If you have well-running Agile projects today with efficient data collection, take your project tracking to the next level. Don’t just report burn-ups, report projected NPV. As things happen in a team - if scope is changing, dates are changing, quality is slipping and needs to be corrected, etc. - report out the business impact of the change in business terms to your business partners.

We do have to be careful not to put too much stock in numbers. We still have to look at code, look at the quality of requirements, run the actual software, and above all else, talk to IT people and businesspeople in the teams. We have to make sure that tasks aren’t masquerading as stories, that unit test coverage isn’t simply being gamed with meaningless tests, that progress isn't being overstated. The numbers are indicators, but they're no substitute for really understanding what’s happening in a project team. Nothing alleviates the need for fundamental project management.

That said, clear line-of-sight into trouble spots and risk areas early in a project allows us to take better decisions about projects, meaning we can avert the spectacular, late-stage blindside. With responsibility for capital investments in a difficult economic environment, we need to win and retain the trust and confidence of our business partners. We need to be on top of our game. We can do that by being an Agile PMO.

The Agile PMO: Automating Metrics Capture

2009-03-16T15:15:00.001-05:00

The last piece of the Agile PMO puzzle is to make the data needs of the PMO non-burdensome to delivery teams. It’s all well and good to be able to get quality and performance data, but it has to be easily accessible. If it isn't, we're just taxing the teams that much more. That means we won't get this data timely or efficiently, if at all.

Automating Metrics Capture

Because they're derived directly from the asset under development, our metrics give us an objective way to index and monitor quality. What’s even better is that these metrics can be automated and run frequently. If we have continuous integration established in our teams (e.g., where the project binary is built as often as every time code is committed) we have the ability to subject the binary just built to a battery of automated quality metrics and tests. Some tests may take a long time to run, while others may run in just a few seconds. This is fine. We can construct a build pipeline to run our metrics and tests in the most efficient manner.

We can collect up-to-the-minute quality data for any project, such as:

What extent of unit test coverage do we have, and are all tests passing?
What extent of functional test coverage do we have, and are all tests passing?
Are we creating code that appears to be high maintenance due to complexity scores, duplication, or other poor coding practices?

And so forth.

This gives us a collection of technical and functional risk indicators that are both comprehensive and current.

By efficiently automating the capture of different quality metrics, we don't need to ask people to generate this data for us: we can lift it right off the binary. This makes data collection non-invasive to the teams, and less prone to collection error.

Tools such as Cruise and Mingle (both from ThoughtWorks Studios) have dashboards that allow people to see first hand current quality and project status across a number of different projects. This allows people in the PMO to look into what's actually happening without burdening the teams, and make far more specific and accurate status reports to project stakeholders.

All told, we're spending less effort and getting greater accuracy of what's happening within each project in the portfolio.

We now have all of the essential components of the agile PMO. Early on in this series, we talked about aligning executive and executor in how we organize, gatekeep and articulate the work to be done. Once we've done that, the data we glean on performance and quality has integrity by virtue of being solidly founded on results achieved, not hope that everything will work out in a future we've mortgaged to late stages of a project. By automating collection of this data, we can see how a project is evolving day-in and day-out with far less effort - and conjecture - than we've traditionally had in IT.

In the next and final installment of this series, we'll recap how all of these concepts and practices fit together, consider some caveats, and present some actionable items you can get started with today.

The Agile PMO: Measuring Quality

2009-02-23T14:52:00.009-06:00

In the last installment we took a look at the project management information we get from results-based organization and execution, and how that provides an unambiguous status assessment. But project status data doesn't give us the complete picture: we also need to know that a team is delivering solutions in accordance with all of our expectations, such as quality and maintainability. For the PMO, that means looking at technical and functional quality along side project status.

Quality Measures

We have no shortage of quality metrics. For example, in the Java world we can measure all kinds of attributes of code: overcomplicated expressions, wasteful use of resources, ghost code, duplicate code, complexity, and so forth. That’s both good and bad. Good in the sense that code quality doesn’t need to be taken for granted, because we can measure attributes of the asset we’re creating. Bad in the sense that with all this data, it’s hard to separate signal from noise. Quality measurements are great to have, but a meaningful assessment of quality is a different matter entirely.

There are many authorities on code quality, so we’ll not dive into them here. But there are a few metrics worth pointing out that are strong indicators that code will be difficult and expensive to maintain: the extent of code duplication, the presence of highly complex code (i.e., cyclomatic complexity), the presence of many large methods (in terms of number of lines), and code that is poorly encapsulated. If any of these are present to a large degree, we have indication that we’re taking on excessive amounts of technical debt. This is material to maintaining viability of a business case: the higher the technical debt, the more expensive the cost of the solution, the lower the yield on the IT investment.

Quality Tests

In addition to measuring quality, we must also test for quality. Quality comes in many different forms. There is functional quality (does the application perform the tasks that it needs to perform?) and non-functional quality (is it fast? does it scale? is it secure?) Our tests can include unit tests, integration tests, and functional tests. A unit test exercises a specific piece of code, while integration tests validate round trips to other systems, and functional tests validate complete scenarios. We can perform these tests manually, or, better still, we can code them. If we code our tests, we can execute them automatically. We can build a library of automated tests and subject an asset to them at any time, meaning we can get up-to-the-minute information on the functional and non-functional quality of a solution at any time.

We must be cautious. Our quality testing is only as robust as our underlying tests, so we also have to validate that our scenarios are thoughtful and meaningfully complete. Some tests are destructive, and require disciplined environments management. But testing has come along way. Functional testing tools have improved in recent years, making functional tests less fragile and easier to maintain when software changes.

The greater and more comprehensive the automated test coverage, the less assumption there is about technical and functional quality. This provides reassurance to the PMO that both functional and technical quality is being maintained over the life of the project, and that incremental functionality previously gained is sustained. This will have a material impact on achieving our business case.

Assessing Quality Information

Metrics and tests give us a collection of data points about our code, each in a different unit of measure. To turn that data into information, we need to structure it in a meaningful way. We have several options for doing this.

One alternative is a scorecard, which I wrote about in the Agile Journal some time ago. To create a scorecard, we must first normalize metrics into consistent scores using simple rules or heuristics that give us degrees of "great" to "poor." We can compare the code in question against a representative but consistent baseline of quality, so we have an absolute point of reference. We can then collect our metrics into broad categories of “indicators of good” (hygienic measures) and “indicators of bad” (toxic measures). By doing this, we can ascertain how good or bad our current state is, and whether or not it becomes better or worse over time.

Another alternative is a technical balance sheet, which Brad Cross wrote about in the alphaITjournal. In this approach, the business value and technical debt of every package is scrutinized to determine whether we’re right-side-up or under water on the solutions we've created. By drawing the line between “value” and “debt” it also tells us where our real risks lie, and what our priority and urgency should be.

Performance and Quality: The Complete Picture

Structured quality data described here paired with project performance data in the last installment gives the PMO what it needs to assess current and ongoing performance of a project. The PMO can answer for each project the two governance questions: Am I getting value for money? and, Am I receiving solutions in accordance with expectations? (n.b. It is a minimal answer because customer satisfaction and staff capability must also be considered, but that's for another blog post.) But this is a lot of data, and if we don't have an efficient means by which to collect it we'll be crushed under the weight of reporting and collection. In the next installment, we’ll take a look at what we can do to automate data capture so that collection is non-invasive to our organization, a by-product of day-to-day operations, enabling us to be an Agile PMO.

Come the Hour, Come the Leaders

2009-01-23T16:42:00.005-06:00

Earlier this week, I published an article called Come the Hour, Come the Leaders in alphaITjournal.com. In it, I point out the acute need for business leadership in today's economic environment and identify six things we can do today to act on a leadership agenda. Today's Financial Times brought some reinforcement to those messages in the first of a four-part series called Managing in a Downturn.

Stefan Stern's Time for Managers to Stand and Deliver contains some good and practical guidance for management leaders. He also sites a Booz & Co. survey that shows that as many as 40% of senior managers said they doubt their leadership have a credible plan to deal with the current crisis, while 46% doubt the leadership team is capable of carrying out its plans, whether credible or not. This data strongly reinforces my point that "how we act and prepare, and how we explain our actions and preparations, inspires confidence more than all the rah-rah optimism in the world will ever achieve."

In Seizing the Upside of a Downturn, Donald Sull makes the point that it is imperative to be organized for consistency, instead of lurching during good times and seizing during bad ones, making reference to Lean practices as a model. He makes excellent points consistent with one of the actions I recommend: "Cutting costs to withstand a downturn in the hope that recovery is around the corner (and with it a return to business as usual) is not leadership. Being sustainably responsive to whatever the economy, the market, governments and the competition deals us is leadership. We can act very boldly to eliminate situational complexity, unaligned gatekeepers, and any other obstacles that make it difficult to get things done. We can also look very closely at Lean principles to not only eliminate waste but to make sure effort is directed toward results."

It is quite satisfying to see reinforcing articles appear within a matter of days of each other. It suggests it is a timely and important topic. I highly recommend that you read all three.

The Agile PMO: Results-Based Execution

2009-01-14T09:20:00.001-06:00

In the last installment we took a look at why it’s important that project gatekeepers be consistent in terms of effort and results. To understand how we can execute on this, we need to take a look at how teams are organized and execute.

How we organize determines how effectively we can define results-oriented “gates." Traditionally, IT teams have organized in silos, working on abstract slices of the business goal (as opposed to the end-to-end). When we organize in silos, we assume that what teams create independently will work together with little effort. When it doesn’t – and that’s the case more often than not – our economies of scale are completely obliterated. Consider the Airbus A380: teams working in complete independence of each other discovered after their sections were "complete" that they couldn’t connect up the electronics.¹ Were the independent sections of the plane “complete” according to the project plan? Yes. Was the plane nearer to completion by virtue of those sections being done? No. It’s entirely possible that Airbus could have built those sections entirely from scratch (to consistent wiring specs) in the time it took to integrate the finished units they had. The lesson learned is that no matter how well we think we define our APIs, no matter how disciplined we think we can work in a silo, integration is never free.

In addition to how we organize, we also need to have some means by which to execute and therefore measure our progress that is directly rooted in the context of the asset. Functionality that is coded and tested is the best measure of "results" that we have.

To act on this, we need requirements expressed as small, actionable statements of business functionality. Agile Stories lend themselves very well to this. Stories are small, granular statements of business need. For the PMO, Stories provide us with the best measure of progress: a Story is either done, or it’s not done. It’s not partially done or kind-of done. If Stories are written in terms meaningful to the business, and if we track progress to Stories, we can assess progress in terms of results. Compare this to how we measure progress in traditional IT: there are long delays between functional deliveries, so the PMO has to rely on surrogates such as timesheet data and collections of technical tasks. Hours spent and completion of technical tasks are measures of effort. Effort doesn't necessarily translate into results. Stories are a measure of results.

The fundamental true/false nature of a Story's completeness lets us measure progress in some very simple but information rich ways. The most common way is the burn-up chart.

These example charts show that scope (in terms of Stories) may expand or contract as new discoveries are made and work is reprioritized. The projected rate of progress through the Stories - that is, how quickly the team is expected to render business needs code complete - is rooted in a simple formula that includes capacity, distraction management, and estimate weight (complexity, etc.) relative to the team.

By tracking progress through Stories, we're measuring accomplishment of meaningful results. With each iteration, the PMO knows the specific functionality that an asset possesses and how much it cost to get it to that point. We also know what functionality the asset does not have and we have a pretty good means by which to forecast how much it's going to cost to complete that functionality. Best of all, in near real-time we can see if a project is showing signs of trouble, we can see almost immediately the impact of changes that we make, and we can communicate all of this in business (as opposed to IT) terms. Traditional IT cannot provide this level of transparency.

The burn-up is meaningful only if we know that it has integrity. Nothing prevents us from defining and tracking technical tasks. If we do that, we're really no better off than we are in current IT practices: it’s just a burn-up of effort, but not of results achieved. We have to make sure teams are relentlessly focused on satisfying business need, from the time a requirement is captured to the time software is certified as production ready. By writing well formed Stories, we're writing the "completion gene" into the DNA of a project team. This aligns the interests of the business (the buyer), the PMO (the buyer's agent and de-facto underwriter), and the development team.

This gives us direct line-of-sight from the unit of measurable work all the way through to the project reporting level, so that when we report upward we know that there is integrity in what we’re reporting. This is deceptively simple, but is the critical component to the Agile PMO: we know what is done, and what isn’t done, not in IT terms but in the terms of what it is we're buying. By extension, we know our investment yield to date and what returns further investment will yield.

The proliferation of Agile Project Management tools, such as Mingle from ThoughtWorks Studios, make it far easier for the PMO to get project performance data from in-flight projects. We don't need to transcribe data from what a PM has told us into what the project sponsors need to know. We're not e-mailing spreadsheets around. We're drilling into a project dashboard to see what’s going on, and we know what’s going on in very granular terms that relate back to the state of the asset.

The combination of team organization and Story-based requirements allow us to work and measure in terms of results. But the results we're looking for go beyond “completed Stories.” We must also have some appreciation for the quality of the solution delivered. Progress – even in “functionality” terms – may be completely hollow if the expected level of quality (e.g., maintainability, technical quality, etc.) isn’t baked in at the same time. This means we are at risk of over-stating our results. In our next installment we’ll have a look at how we can align quality metrics to get a complete picture of solutions delivered, and we’ll look at how to automate capture to make this simple. Once we’ve done that, we’ve defined the fundamental tools necessary for an Agile PMO.

¹ Hollinger, Peggy."In a tangle: How having to wire the A380 by Hand is hampering Airbus." Financial Times. 16 July 2008.

The Agile PMO: Consistent Project Gatekeepers

2008-12-17T08:30:00.007-06:00

In the last installment we took a look at the gap between what the PMO reports out, and what's actually happening in a project team. To begin to understand the nature of this gap, we’ll first take a look at what we use for project gatekeepers.

We need to make a clear distinction in an IT project between the means and the ends. We often confuse this, because what we see day in and day out is that we’re paying for the means of production, when in the end we’re really acquiring an asset. Unfortunately, this tends to skew our thinking about how we execute, organize, measure our progress and assess our exposure.

Traditional IT projects are mass economy-of-scale exercises: once development begins, armies of developers are unleashed. So in Traditional IT we stage large volumes of work to keep the largest and most expensive pool of people – developers – busy in the hopes of maximizing their productive effort. To minimize the chance that development is misdirected (e.g., due to poor requirements) or wasted (e.g., due to poor technical structures), we create checkpoints, or gatekeepers, throughout the project. Satisfy the gatekeeper, so the thinking goes, and we minimize the risk. Traditionally in IT, our gatekeepers are typically several different waves of requirements and specification documents, then software, then test results, then a production event.

This may give us lots of gatekeepers, but they’re inconsistent in both degree of effort and results achieved.

Clearly, a small team delivering documentation is nowhere near as significant an event as a large team delivering executable code. But of bigger concern is the latency between the time when requirements are captured and the time they're available as working code in an environment. We don’t know for fact that our documentation-centric gatekeepers have truly been satisfied until we have a functioning asset. A dozen people can reach a dozen different conclusions after reading the same documentation; the proof of the quality and completeness of documentation is in the delivered software. Inadequacies in documentation may not become apparent until QA or, if we’re lucky, during development. In effect, there’s very little other than opinion to prevent us from developing a toxic asset: bad initial requirements are transformed into flawed derivative artifacts (specifications, code, even tests) as they pass through different stages. And, of course, we not only pass along quality problems, we risk introducing additional quality problems unique to each stage (flawed technical specifications, poor tests). This just adds insult to injury: we’ve not only put ourselves at risk of creating a useless asset, but our interim progress reports are laden with false positives.

One solution often attempted is phased delivery of use cases: the traditional IT steps are still performed, only we make interim deliveries of code to a QA environment and execute functional tests against them. The theory goes that functional success is assured by test cases passing, which, in turn, indicates some measure of “earned value” for the total amount spent. This assumes that the software released to QA on this interim basis is of high functional and technical quality. If it is of low quality – again, think of all the problems that build up when people work in technical or component silos and all that toxicity we’re building up through the “soft” gatekeepers of project documentation – the blowback to the teams in the form of a large number of defects raised will interfere and ultimately derail development. When this happens, it obliterates the economies of scale we were hoping to achieve. Phased delivery of use cases does less to expose problems in a solve-able way early in the lifecycle than it does pile-on work to development teams that are already overloaded. It adds noise to the development cycle and confuses decision makers as to what is going on, and why it’s happening in the first place. This may fail a doomed project sooner, but not by much. The real tragedy is that the idea of incremental delivery will be discredited in the minds of the people involved in the project.

By comparison, Agile maintains a steady pace of progress by having all of functional efforts simultaneously focused on achieving the same result. An Agile team is not an exercise in scale. It maintains a more consistent (or at any rate, less volatile) level of effort over the life of a project. Our gatekeepers are consistent, rooted in certification of the code, not certification of things that describe what will be coded. Either we have delivered the requirements defined or we have not. They either satisfy our technical and functional quality gatekeepers or they do not. They are found acceptable by the business or they are not. We know this with each iteration – every 2 weeks or so – not months or even years after requirements have been penned. Quite simply, because we derive our certification exclusively from the delivered asset and not from things that describe the asset, we’re not confusing the means for the ends.

Just because Agile teams are not exercises in scale doesn't mean they don't scale. To take on a large application, we divide the project into business-focused teams instead of technically-focused teams. "Work completed" is more clearly understood, because we report in terms of business needs satisfied (results) and not technical tasks completed (effort). Reporting progress in a large development program is therefore much more concrete to everybody involved.

However, this doesn’t mean that an Agile project won’t fail. It may. But if it does, it’s far less likely to be a spectacular failure. By paying attention to results as opposed to effort, we spot both trouble and opportunity a lot sooner in an Agile project. This means we can take smaller and less expensive corrective action (reprioritzation, technology change, team change, etc.) much earlier. More importantly, we’ll see the impact of those actions on our bottom line results much sooner, too. This is far better than being surprised into making a large and expensive correction late in the lifecycle.

So what does this mean for the PMO? It means that we have to change what it is we’re measuring – the means by which we can declare “victory” at any gatekeeper – if we’re going to change what it is we’re managing. We don’t want our gatekeepers to be rooted in effort; we want them rooted in results. In IT projects, the results that matter are the code and its demonstrable attributes (performance, technical quality, functional quality, etc.), not assurances about the code. We want to see results-based gatekeepers satisfied from the very early stages of the project, and we want them satisfied very frequently. We can do this across the portfolio to reduce execution risk, and with it reduce the probability that we'll get blind-sided.

Changing our gatekeepers is important, but it’s only the first step. In the next installments we’ll take a deeper look at how we organise and execute for development, and the impact that has on the confidence with which we can measure progress. We also need to be aware of how much work we might unintentionally create for people. Setting up these gatekeepers sounds great, but we need to avoid “metrics tax” burden on the teams, so we’ll also take a look at how we can make this collection non-burdensome to both team and PMO, and get closer to real-time project metrics.

The PMO Divide

2008-11-26T10:55:00.002-06:00

This content is derived from a webinar I presented earlier this month titled The Agile PMO: Real-Time Metrics and Visibility. This is the first of a multi-part series.

We’ve all seen it: the project that reports “green” status on its stop-and-go light report for months suddenly goes red in the late stages of development. This is nothing new to IT, as projects suddenly crater all the time. But it begs the question: why does this happen as often as it does?

Program Management Offices (PMOs) are at the nexus of this. PMOs are responsible for keeping an eye on the performance of the IT project portfolio. They sit between the executives who sponsor IT projects and those who execute those projects. This means the PMO is responsible for bridging the divide between the two groups. But this divide is wider than we think. All too often we end up with overworked project managers frustrated by doing double duty managing a team and filling out status reports on one side, and angry, humiliated business sponsors blindsided by sudden project changes on the other.

Let's look at what it means to sit between executive and executor.

Facing “upward” to project sponsors, the PMO needs to be able to report status. It must show it has control over spend and that there is demonstrable progress being made. Facing “downward” the PMO needs to get spend and progress information from delivery teams. But because of the way most IT projects are structured, these aren’t easy questions to answer, and this creates an information gap.

IT projects are often structured by area of technology specialization (e.g., User Interface, middle tier, server side, database, specialists in things like ERP systems) or by component (e.g., one team works on the rating engine, one team works on the pricing engine, and so forth). This means that development of a bit of business functionality is splintered into independent effort performed by lots of specialists. Those individually-performed tasks need to be integrated and then tested from end-to-end. Integration is an opaque, under-funded phase most often scheduled to take place late in the project. End-to-end testing - the best indicator of success - can't take place until integration is complete. This means that lots of development tasks may be flagged as “complete” but they’re complete only by assertion of a developer, not by “fact” of somebody who has exercised the code from end-to-end.

What this means to the PMO is that when it looks “downward” to get an answer for somebody “upward” there’s a fair bit of conjecture in the answer. By deferring integration and testing, the whole of what we have at any given point in time is less than the sum of the parts. Code has been written, but it may not be functional, let alone useful. Measures of progress and spend are therefore highly suspect, because they are really lagging indicators of effort, not forward looking indicators of results. It also means that when we use effort as a proxy for results, we inflate our sense of progress. In traditional IT, which is effort-centric, there is nothing preventing us from reporting inflated numbers for months on end. The longer we do this, the greater the risk of being blind-sided.

This doesn’t become a serious problem in each and every project because the gap may or may not be a serious risk. The degree of exposure depends on the situation in the team. Since we know from experience that some teams seem to succeed while others fail, it’s worth exploring why this is.

In the best case scenario, reporting up to the PMO is a nuisance to a project manager. The data the PMO is asking for isn't what the PM uses to manage the project, so filling out status reports is a distraction. It can only truly be a nuisance and not represent an outright risk, though, if the team itself has all the behaviours and communications in place to complete their objectives in a business context. That is, the sum of the tasks in the project plan might not describe what needs to be done to complete business delivery, but the team itself may have the right leadership and membership so that it takes responsibility for completing the delivery. So, while there may be “leakage” on the project budget and timeline because not everything that the team does is fully and completely tasked out (and still inaccurately tracked in time entry systems and what not), the impact of this leakage is contained because the team is by its very nature working toward the goal of completion. There may be a lot of reasons why this is the case. Perhaps the team has been working together for many years and knows how to build-in contingency to cover the small overages. Or perhaps it's simply a team with few skill silos. Regardless the reason, leakage is contained when the right team dynamic is in place.

In the worst case scenario, people in silos work to complete their tasks to a point where nobody can tell them that their tasks aren’t done. Working to complete tasks, of course, isn’t quite the same as working to complete functionality. Completing UI code, services, and some server-side code does not necessarily define a complete business solution. In very large projects it's not always completely clear who is responsible for the complete solution. Is it the business analyst? The last person to commit code in support of a use case? The project manager? The QA tester? This responsibility void is made more acute by the fact that the “last mile” is the hardest: the steps necessary to integrate all the bits of code so that everything lines up and technically performs, as well as meets functional needs and satisfies non-functional requirements, is always the most difficult. In a large project structured around technology specialism (and very often made worse by a staff of “passengers” fulfilling tasks and not “drivers” completing requirements), we don’t have leakage, we have full-scale hemorrhage. No amount of contingency can cover this.

This means that in traditional IT, the PMO isn't bridging the divide. The data it gets from teams isn't reliably forward-looking. Reporting against task completion inflates progress, while spend data is simply cost-of-effort that doesn't directly translate into cost-for-results. The reported progress is inflated, and cost control is misleading.

This puts the PMO in a situation where it is underwriting the risk of the development capacity that has been sourced to complete a project. Work is being done – we know this from the timesheet data and task orders – but there’s no map from timesheet data to the degree to which a business need is functionally complete, and no way to know that it’s technically sound. In effect, the PMO is the buyer’s agent for an asset and it is underwriting the risk of developing that asset, but it’s not taking informed decisions with the state of the asset in full view at all times. To get visibility, PMOs typically try to scrutinize the minutia and decompose the project into further levels of detail and precision. Ironically, the greater the specialization baked into the plan, the more likely we are to miss the things that get the software into a functionally complete state. For all of this alleged precision, we may have more data, but in the end we have less information.

How can we bridge this divide? By managing and measuring incremental results, not collective effort. This aligns day-to-day activity with topline reporting. That, in turn, reduces our exposure to late-stage project collapse.

Ultimately, we want the PMO to have real-time and forward looking information about it's project portfolio, and to be able to get that information in a manner that is non-burdensome to project teams. But getting ourselves into this future state will require some re-alignment. In coming posts we'll look at IT organization and practice, as well as what we use as measures for progress and quality, that will allow us to do this. As our first step, we need to reconsider what it is we use for project gatekeepers, basing our decisions not on descriptions of the work we expect to do, but on the actual state of the asset under development.

The Agile PMO - Real Time Metrics and Visibility Webinar - 5 November

2008-10-13T10:29:00.009-05:00

There’s a lot riding on IT in the current economic climate. In tight times, businesses rely on efficiency, and IT investments will be expected to create a lot of that efficiency. But while IT assets may help the business tighten up, IT execution must also tighten up to match the times.

That doesn’t mean IT projects have to execute flawlessly. They never will, as there will always be situations and events that challenge even the most experienced of teams. What it does mean is that the people responsible for IT projects will need to make well-informed decisions throughout the life of a project. That requires current, accurate and clear information about what’s actually happening in eah project.

IT doesn’t excel at this today. The failure rate of IT projects has been discussed for decades. Yet the most important IT initiatives that are subject to the greatest scrutiny still crater suddenly late in their lifecycles, much to the surprise of their executive sponsors. This exposes the very wide divide between what the PMOs need to know to oversight a portfolio (such as total time spent, features complete and functional QA results) and the indicators that the PMs use to manage projects day-to-day (such as technical task orders, defect counts and high-priority issue lists.) This gap also means that the status data that the PMOs eventually get is late and stale.

What this all means is that PMs are doing double duty, executives are getting blindsided, and PMOs are caught in the middle unable to satisfy either. The collective frustration by all parties is unfortunate, but it may also be little more than a tragic sideline. Capital is scarce and increasingly impatient, and IT will find it even more so if its business partners have little confidence that IT can deliver. Historically, executives have felt backed into a corner when an IT project fails, given little choice other than bailing out a project that has suddenly and surprisingly redlined. But as we're seeing in the global economy right now, historical patterns no longer apply.

There is a better way. Join me on 5 November for The Agile PMO – Real Time Metrics and Visibility. We’ll discuss how Agile practices align day-to-day execution with executive needs, and how the PMO is instrumental in making this happen:

Using requirements - not abstractions - as gatekeepers. What does it mean to complete business requirements and not just tasks, and why does this distinction matter?
Transparency. How can the PMO get unambiguous line-of-sight into what’s happening on the ground across the portfolio, both functionally and technically?
Metrics. We need information, not dispirit data points. What is signal, and what is just noise coming out of a project? How does Agile cut through the noise?
Collection. We need to collect project data efficiently, otherwise our projects will suffer under the weight of data generation (or simply not report it). How does Agile align with PMO needs so that collecting status data is not a burden to project teams?

I hope you can attend on the 5th.

Registration Details: The Agile PMO - Real Time Metrics and Visibility
Wednesday, 5 November 2008
Time: 12:00pm Eastern Standard Time (US-New York, GMT-5:00)
Registration URL: https://thoughtworks2.webex.com/thoughtworks2/onstage/g.php?t=a&d=842762110

Agile Readiness Assessment Webinar - 19 September

2008-09-12T08:27:00.006-05:00

Please join me on Friday, 19 September for An Agile Readiness Assessment, a ThoughtWorks sponsored webinar.

Taking on Agile can appear to be an overwhelming commitment with no obvious place to start. For one thing, Agile is often a significant departure from how a team is operating, requiring organisational changes, new practices, and stricter discipline. In addition, because there are so many different things to be done - from continuous integration to Story based requirements - it's difficult to know what changes to make first. Finally, organisational constraints such as phase-based governance and shared QA can create questions about the extent to which Agile practices will have an impact, and raise doubts as to whether they can be taken on in the first place.

In this webinar, we'll discuss how to overcome stationary intertia and plot a course to Agile practice adoption.

How can we critically assess the state of our practices today?
What goals should we target given constraints and organisational realities?
How do we prioritise what we should do first?

I hope you can attend on the 19th.

Registration details:
Friday, 19 September 2008
Time: 1:00pm Eastern Standard Time (US-New York, GMT-4:00)
Registration URL: https://thoughtworks.webex.com/thoughtworks/j.php?ED=108081447&RG=1&UID=0

IT's Identity Crisis

2008-08-30T08:14:00.006-05:00

IT lacks a consistent definition of exactly what it does vis-à-vis its organisational peers.

Accounting is the language of business.
Finance is how business gets capital.
Marketing creates customers.
Sales brings them in.
Operations are how a business creates value.

IT does … what, exactly? Creates new business offerings? Retains customers? Is how business gets done? What do these really mean?

All too often they end up meaning, “would you like fries with that?” When that happens, IT devolves into a cost to be contained, a nuisance to be tolerated.

This ambiguity of purpose is made worse by the fact that IT brings both a language and set of priorities that are of no real interest to the business (e.g., technical "issues"). It’s no wonder IT struggles to justify its annual spend: it has a fundamental identity crisis.

This creates some rather bizarre side effects.

One is that a lot of businesses put IT in a narrow box, giving it a rudimentary but clear definition as a utility that operates at a predictable, consistent cost. The price of this simplification is that IT cannot perform as a competitive capability, but so it goes. Hard costs ("annual IT spend was reduced through strategic sourcing contracts") are easier to present to shareholders than soft language ("IT gives us a transformational capability.") Having clear line of sight as to where IT spend is going trumps vague promises of competitive advantage.

Another are the proliferation of IT firms on the sell side with very odd-sounding offerings: "We radically transform business to invent and reinvent them.” Yes, of course you do. Good luck with that.

But the real tragedy of IT’s identity crisis is that it is significantly responsible for two of its core problems.

One is that IT serves the wrong master (technology) at the cost of the right one (the business). Debates over platforms and tools often overshadow discussions of business need. This is particularly disasterous when the business is drawn in to mitigate a resolution. This is why IT typically lacks a seat at the top table of the business.

Another is that IT lacks both quantity of management practitioners and maturity of management practices. Despite involvement in every part of the business, generally speaking IT is not a destination employer for management talent, certainly not to the extent that other business disciplines are. To wit: finance typically attracts top business talent, while more often than not IT promotes engineers or mathematicians with little business education or acumen into positions of management.

Application development exemplifies this. Purchased solutions such as accounting systems or office tools have become business utilities. However, custom applications that support custom operations from which businesses derive competitive advantage defy a utility model. There’s been effort made to bring commodity thinking into appdev, to a point where we’ve created buying patterns that commoditise people. But skills – especially at the high-end of IT – are not ubiquitous and portable: one firm’s technical architect is another’s junior developer. We’ve abstracted what we’re buying into roles and definitions, and in so doing we've made it cheaper to get what we’re buying, but we’re not buying what we really need.

What we’re buying in appdev, of course, is capability. That’s hard to define. But then again, so is IT in the first place.

So having asked the question, what’s the answer? What is IT relative to its peer group of business disciplines?

IT maximises return on invested capital.

IT investments are made for one reason only: efficiency. We can execute operations (e.g., define and trade exotic financial instruments or run a manufacturing plant), comply with regulation, win and retain customers, and keep track of revenue and cash flows all by hand if we must. IT investments may make many opportunities possible that would otherwise not be economically viable, and it may make the burden of regulation less costly to bear, but it’s an efficiency game. This means IT maximises returns by quickly delivering solutions that create business efficiency.

By extension, it also means that IT should be a destination discipline for business talent. Capital that needs to sweat the assets will do so through efficiency of operations. In most businesses, efficiency will be realised substantially through IT, because IT has a hand in every aspect of a business. Any representative of that capital (e.g., the board, the CEO, the CFO) looking for ways to maximise returns will start by leveraging IT. This requires not technology leadership from IT, but business leadership.

So when capital comes calling for that leadership, IT needs to be prepared with an answer. That answer isn't that IT solves "business technology" problems: arguably, they're all contrived anyway. It isn't that IT achieves the minimum cost-per-role-staffed relative to its industry peers: that's abdication of leadership masquerading as fiduciary responsibility. Nor is it to reinvent business: there are still far more low tech than high tech solutions to business problems. IT must answer in terms specific to what it can deliver that creates business efficiency and therefore returns. This is how it fulfills its organisational role to maximise return on invested capital.

Any other answer misses the point.

Introducing alphaITjournal.com

2008-07-22T22:19:00.008-05:00

alphaITjournal.com

I'm pleased to announce the launch of alphaITjournal.com, an online magazine focused on the execution, management and governance of IT investments that can produce outsized (or "alpha") returns. The mission and purpose are summarised in the welcome message on the site and in the press release that was issued in early July.

There are a few things that I hope stand out about the site.

The first is the site layout. It's designed to give attention to writers and their articles, and make the content easy for readers to navigate without being overwhelmed by a polyglot of messages.

Another is the absence of advertising. Aside from the "Presented by ThoughtWorks" message on the left navigation and bottom menu, there is no advertising on alphaITjournal.com. Being practitioners, this affords us flexibility in dealing with changing project demands and work priorities that will affect content production and editing.

Still another is the continuous release of content. Rather than having monthly editions, there will be one or two articles released each week. This will make it easier for the reader to stay current, and it will also make it easier to sustain fresh content on the site.

Last but certainly not least is the diverse community of writers. While ThoughtWorks is sponsoring the site, the community of writers are from all corners the IT universe. They, in turn, are producing content on a diverse collection of topics, all with a common theme: how to maximise returns on IT investments.

I hope that alphaITjournal.com consistently provides compelling content so that you'll be a regular reader, even a promoter: add it to your RSS news reader, share it with your peers and customers, add a link to it from your blog. I also hope that you'll consider being a contributor. We have a number of writers, but we are always looking for more. If you have ideas for individual articles, a series or a column, drop me an email.

We've just gone live, so there are a few additions we'll make once we establish our rhythm (such as reader comments). Meanwhile, if you haven't done so already please give alphaITjournal.com a visit.

Agile Made Us Better, but We Signed Up for Great

2008-06-29T22:02:00.000-05:00

This content is derived from material presented in a ThoughtWorks-sponsored webcast in June 2008. A two minute video presentation of this material is available. A complete webinar re-broadcast, including audience Q&A, will be available soon.

The popular press makes Agile sound like nirvana. Practitioners speak of it in nearly religious terms. Yet we often find that IT teams are underwhelmed after going “Agile,” even after having expended considerable effort on making the change.

Why is this? Is there too much hype around Agile? Could it be that it doesn’t work? No, it’s because they’ve fought only half the battle: they got some of the practices, but not the behaviours.

When teams or departments decide to “go Agile” they’re typically moving away from what they’re doing now, as much as if not more than they’re moving toward what it is they want to be doing. That is, they’re trying to get away from regressive behaviours where the way work is done impedes responsiveness, or they’re trying to get away from chaotic behaviours, where people are pursuing responsiveness at the cost of consistency and quality.

Changing the way work is performed is no simple task. Making investments in how work is done is extra effort above and beyond what has to be done just to keep up with the day-to-day. And there’s stationary inertia in IT: a lot of practice and theory have roots dating to the Eisenhower and Churchill eras. Getting away from regressive or chaotic states takes a lot of effort, and that effort isn’t necessarily sustainable.

No surprise, then, that many IT teams lose their appetite for change once they’ve shed their bad practices in favour of minimally good ones. But good practices are not the same as good behaviours. And that’s what separates the “functionally Agile” teams from the truly responsive ones. Do developers have a Pavlovian reaction when the alert goes out that the build is broken or are they content to leave it to somebody else? Are people co-located and directly engaged with each other in the execution of team responsibilities, or do they simply sit near each other still working in silos and swim-lanes?

Agile is not a Boolean question. There is no single thing you can do, or tool you can adopt, that will make your team “Agile.” It is a collection of practices. The extent to which these practices are mature in a team determines how responsive the team can be. The more mature states of practice require aligned behaviours.

This isn’t academic. Working with several colleagues, we’ve constructed an assessment tool, called the Agile Maturity Model. We’ve looked at 10 dimensions including project management, requirements, development and configuration management, and identified consistent patterns of progression – or maturity – in the way people and teams move toward more agile practices. For example, a team that infrequently performs its build manually today will not be able to cope with a build that automatically fires with each code commit and fails if code quality levels are below a specified threshold. The same is true for collaboration: a team that communicates requirements or project status by presentation is not going to get much mileage from automated collaboration tools. Durable practice results from taking incremental steps. This is how we gain mastery.

A maturity model helps us understand what it is we are doing as well as what it is we are not doing. That it’s based in experience makes our path to responsiveness less a matter of opinion, and more a matter of fact. But the real value is that it gives us some insight into the cost and the returns of taking the next steps. For example, perhaps if our frequently executing build were a continuously executing gatekeeper of quality, we could eliminate hours of rework, lost productivity and late nights because of bad builds being released into an environment. Or perhaps we wouldn’t have missed a subtle shift in the business priority had we been working as a team to deliver small but complete business requirements instead of technical tasks. A maturity model helps us to clearly pinpoint our best opportunities for change.

Using the model, we can also index where we’re at. There’s merit in an index, in setting some quantitative value for our target, historic and current states. It helps us to be more communicative about our strengths as well as our deficiencies. But the point of having an index isn’t to score or grade. The model isn’t our team, and the model doesn’t give results to our business partners. All it does is gives us an indicator of the extent to which we’re past the point of doing things that undermine responsiveness, and at a point where we’re behaviourally aligned for it. Or, that we’re not yet past that point. An index is an indicator that helps us frame our situation; it is not our sole purpose. Process is important, but we’re on the payroll to deliver solutions; we’re not on the payroll just to have really great processes.

There’s nothing wrong with being “functionally Agile.” Breaking free of the restrictive practices or simply getting some control over chaos is a better situation for an IT team, and usually is the result of significant effort. But don’t mistake it for being organizationally responsive. Recognize there are degrees of practice and find the optimal combination for your team or department. Above all, hold your teams to the expectation that they will not just perform to a set of practices, but behave in such a way that they maintain the highest state of readiness for whatever comes. Achieve that, and your IT organization will be more resilient to threat and better able to capitalize on opportunity.

The Moral Hazard of IT projects

2008-05-27T21:25:00.009-05:00

The longer an IT project is expected to take, the greater the risk of moral hazard: i.e., that IT will provide poor information to its business partners or have incentive to take unusual risks to complete delivery.

This is not borne of maliciousness. People on an IT project are not necessarily out to defraud anybody. It may simply be that people incompletely scope the work, make assumptions about skills and capabilities, or are overly optimistic in estimates. This creates misleading project forecasts, which, in turn, lead to a disappointing asset yield.

This is the raison d'être for the rules-based approach to IT: improve rigor in scoping, estimating and role definition, it is argued, and projects will be on-time and on budget. Unfortunately, this won't accomplish very much: the moral hazard that plagues any IT project is not a product of poor practice, but of behaviours.

Rules-based IT planning assumes that each person in a team has an identical understanding of project and task, and is also similarly invested in success. It ignores that any given person may misunderstand or outright disagree with a task, a technology choice or a work estimate. These differences amplify as people exit and join a project team: those who are present when specific decisions are taken – technical or business – have a context for those decisions that new people will not. The bottom line is, there is a pretty good chance that any action by any person will not contribute to the success of the project.

Complicating matters is the ambiguous relationship of the employee to the project. The longer a project, and larger a team, the more anonymous each individual’s contribution. This gives rise to ITs version of the tragedy of the commons: because everybody is responsible for the success of a project, nobody takes responsibility for its success. The notion that “everybody is responsible” is tenuous: success or failure of the project may have no perceived bearing on their status as employees. And, of course, people advance their careers in IT by changing companies more often than they do through promotion.

But by far, the biggest single contributing factor to moral hazard is the corporate put option. There’s a long history of companies stepping in to rescue troubled IT projects. This means people will expect that some projects are too big or too important to fail, and that the business will bail out a project to get the asset.

All told, this means that the people working in a traditionally managed IT project may not understand their tasks, may perceive no relationship between project success and job or career, and may believe that the company will bail out the project no matter what happens. There might be a lot of oars in the water, but they may not be rowing in the same direction, if at all.

Especially for high-end IT solutions, the rules-based approach to IT is clearly a fallacy: any “precise” model will fail to identify every task (we cannot task out solutions to problems not yet discovered) and every risk (project plans fail to consider external forces, such as dynamics in the labour market). Rules feign control and create a false confidence because they assume task execution is uniform. They deny the existence of behavioural factors which make-or-break a project.

A rules-based approach actually contributes to moral hazard, because the tasks people perform become ends in and of themselves. To wit: writing requirements to get past the next “phase gate” in the project lifecycle is not the same as writing actionable statements of business need that developers can code into functionality.

Work done in IT projects can end up being no different from the bad loans originated to feed the demand for securitised debt. At the time development starts in a traditionally managed project, all we know is that there are requirements to code (e.g., mortgage paper to securitise.) Further downstream, all we know is there are components to assemble from foundation classes (e.g., derivatives to create). Nobody touching the details of the project have responsibility for its end-to-end lifecycle; once a detailed artifact clears the phase gate, that person is done with it. This is supplemented with misguided governance: quality and completeness of intermediate deliverables aren't reconciled to a working asset but to an abstraction of that asset, the project plan.

Just as we don’t discover defaults until long after the bad paper has entered the securitisation process, we similarly don’t discover problems with specifications or foundation code until late in the delivery cycle. There's typically only a minor provision (in IT terms, a “contingency”), meaning we can absorb only a small amount of “bad paper” in the project. And because it comes so late in the cycle, the unwind is devastating.

This does not mean that IT professionals are untrustworthy. What it does mean is that there must be a short impact horizon for every decision and every action. Our top priority in managing IT projects must be to minimise the time between the moment a requirement is articulated and the moment it is in production. That means the cycle time of execution – detailing requirements, coding, testing and releasing to production – should be measured in days, not months and years. This way, the results of each decision are quickly visible in the asset to everybody on the project.

Short impact horizons align behaviour with project success. Each person sees evidence of their contribution to the project; they do not simply pass the work downstream. A project may still go off course, but it won't do so for very long; a small correction is far less costly than a major unwind. And, of course, we can extract better governance data from an asset than we can from a plan.

Best of all, we’re not backstopping the project with the unwritten expectation that the business may need to exercise its put option.

Rules Versus Principles

2008-04-28T06:35:00.010-05:00

In the wake of a credit market seizure, illiquid investments, $245 billion of write-downs and losses¹, collapsing funds and financial institutions, and no indication as to where it’s going to end, US capital markets are facing significant changes in how they're regulated. Hedge funds are a flashpoint. There are about 8,000 funds managing some $2 trillion of assets,² and there is no way of knowing whether or not there’s a large write-down looming somewhere among them. Indeterminate counterparty risk in a highly interconnected financial system means there’s a chance capital markets could get blindsided yet again, so hedge funds are front and centre of the regulatory debate.

There are two schools of thought over how hedge funds should be regulated.

Members of Congress are calling for strict, rule-based regulation. Very few industries have a track record of successful self-regulation, and capital markets firms have incurred more than a few self-inflicted wounds of late. Rule-based regulation calls for tight controls on activity. Transparency is an assumed byproduct: if actions are pre-defined, everybody will know exactly what everybody else is up to. There is also an “I pay, I say” dimension: if the US taxpayer could end up footing the bill, the taxpayer must have the opportunity to set the rules. The champions of rule-based regulation believe this is accomplished through control and regulation, imposed through legislation and agency.

The US Treasury department is agitating for principles to play a greater role in regulation. Because capital is globally mobile, markets must innovate to remain competitive. Financial markets are innovating at a fast clip. Rules can't be written as quickly as markets evolve. Principle-based regulation posits that compliance with best practices is the best way to facilitate innovation while retaining transparency. Advocates of principle-based regulation argue that it is in everybody’s best interests to voluntarily comply, as compliance guarantees consistency – and with it transparency, liquidity and confidence – in capital markets.

This debate mirrors a similar phenomenon in IT.

The traditional approach to IT project management is consistent with “regulation by rule.” This camp values practices such as deterministic project plans, highly detailed task orders, explicit role definitions, and timesheet-based project tracking. The theory is that consistency is achieved through meticulous control; any deviation from plan is visible and immediately correctable. At the other extreme are the Agilists who champion regulation through principle. This camp values practices such as test driven design, continuous integration, co-located and cross-functional teams, short development iterations, and frequent releases of software. They argue that innovation, transparency, consistency and ultimately project success result from compliance with best practices more than they are adherence to a collection of rules.

Not surprisingly, the ideological arguments in IT are similar to their capital markets counterparts. Those who advocate the traditional approach argue that top-down control is essential, and that best practices are ignored by teams when things are going well. How can there be self-regulation in an industry notorious for significant overruns and spectacular project failures? Why would a business abdicate responsibility for oversight if there's a risk it will have to bail out a project? The Agilists argue that top-down control is a myth, and that everybody has a vested interest in adhering to best practices. How can anybody expect that deterministic project planning will keep pace with changes and discoveries made during development? And how can we expect innovation in an environment stifled by bureaucratic control systems that are not aligned with day-to-day execution?

“Control” is elusive in IT, particularly at the high end. Applications with the potential to yield significant business impact typically involve new processes or technologies. In these cases, development is an exercise of continuous problem solving, not rote execution. It isn’t practical to create deterministic project plans for the delivery of solutions not yet formed to problems not yet discovered. Additionally, history has shown that regulation and control do not offer deliverance from failure, let alone disaster. As US Treasury Secretary Henry Paulson commented in the aftermath of the Bear Sterns intervention, “I think it was surprising … that where we had some of the biggest issues in capital markets were with the regulated financial institutions.”³ The same can be said about IT. Rules offer no guarantee of effective risk management, as time and again, we have seen delays or functional mis-fits announced late in the lifecycle of even the most tightly “controlled” IT project.

If IT is to be a source of innovation and business responsiveness, it needs disciplined execution more than it needs imposed rules. Unfortunately, “disciplined execution” doesn’t describe how the vast majority of IT is practiced today. IT has launched its share of self-targeted missiles over the years, and its track record remains poor. On top of it, buying patterns increasingly relegate IT to utility status; they don't elevate it to strategic partnership. Principle-based regulation may be appropriate for IT, but it faces significant headwinds.

This debate will affect the role and relevancy of IT in the coming years. There is an opportunity for IT to take leadership in this debate, but it can do so only if it has its house in order. Without principled execution, IT will increasingly be treated as a utility, regulated by rule. But by adhering to best practices, IT can demonstrate an ability to self-regulate. This will allow IT to strike a balance between effective practices and the rules with which it must comply, and position itself to be a driver of alpha returns.

¹Brinsley, John. Treasury Panels Lay Out Hedge Fund `Best Practices' Bloomberg.com, 15 April 2008.
²Ibid.
³Secretary Paulson as quoted in Paletta, Damian and MacDonald, Alistair. Mortgage Fallout Exposes Holes in New Bank-Risk Rules The Wall Street Journal, 4 March 2008.

A Margin Call on Leveraged Time

2008-03-27T21:22:00.011-05:00

IT is primarily a business of people solving problems during the creation of assets that increase Ebitda. Problem solving requires talent, and most IT organisations have to contend with a shortage of talented people. To some extent this reflects limitations of the labour market. It’s also economic: highly capable IT professionals aren’t inexpensive, and most firms struggle with budgets and costs. To get by, the experience and capability of a core few is expected to support a very large number of staff. Because IT projects are work effort delivered in time, this is, in effect, a leverage of people’s time.

Consider how leverage works. If we invest $4 of our own capital and $6 of borrowed capital into a $10 asset, and that asset increases in value by 20% in one year, we’ll yield $2 of profitability. That will considerably eclipse the $0.80 that our own capital earns in that investment, provided the interest rate on the debt doesn’t exceed 20% annually. The same thinking applies to how we invest the time of our highest-capable IT professionals: if we create teams to take the burden of rote coding off the shoulders of the most capable people, we should be able to produce more IT assets and thus drive greater returns from IT. This can be very attractive, especially if IT is engaging in labour arbitrage, sourcing staff globally at lower costs. Indeed, the cost per hour may permit contracting staff in multiples of 2x, 3x or even 4x. There is also quick impact: the income statement improves as costs drop dramatically, and the notional value of the IT assets that our core (and expensive) capability is producing is quite high relative to their total numbers. There is a powerful temptation to overload on leverage: the higher the leverage, the bigger the payday if our bets pay off.

But our bets don’t always pay off. Suppose that $10 asset drops in value by 20%, to $8. We’re still on the hook for the $6 we borrowed. When assets erode, debt holders will require additional capital as a sign that we’re good for the loan. This is what is known as a margin call. Suppose the margin requirement is 30% - that is, suppose that our broker requires that we cover no less than 30% of a position with our own capital. The erosion of our investment to $8 would mean that our $4 original investment is now worth $2, and our own capital is 25% of the total value of the investment. We need to put up more capital to restore this to a margin minimum of 30% of the now $8 asset, or $0.40. We may have to liquidate positions in other investments to come up with that 40 cents. The higher the leverage, the greater the pain: our own capital in the asset has eroded, and we’re still on the hook for the loan at whatever interest rate we’re paying. We now face a difficult decision: cashing out this investment now will post a loss, while re-investing to maintain our position in the asset might be throwing good money after bad.

Consider this again in operational terms. Suppose a “leveraged team” fails to meet expectation, either because functionality delivered is wide of the mark, or technical quality is sub-optimal, or both. Time has been invested with the expectation that this team would succeed, and that time has been lost. We now need to invest additional time to bring that particular asset into an acceptable state. Most likely, we're going to call on more talented people to do so. Since they are few in number, we're going to have to liquidate a position in another investment, directing those people’s time to shore up this investment. The operational decision is just the same - and every bit as painful - as the financial one: walk away or reinvest.

A leveraged IT project that fails can trigger a capability liquidity crisis. The more we need to invest to rescue this project, the more capability we'll need to draw down from across the portfolio. When this happens, the IT income statement very rapidly sours and the high notional value in the IT portfolio is obliterated.¹

To prevent a rapid de-leveraging, we may need to make a capability "injection.” Ideally, this is an exercise in sourcing top IT talent in a project rescue mission. In addition, the rescue team will very often get that which it needs to succeed: co-located facilities, access to business partners, hardware and tools, etc. Capability injections can be costly, but they prevent a greater disaster across the portfolio.

This assumes, of course, that a project can make effective use of capability. Even when the business domain and underlying technologies are relatively simple, IT projects can become situationally complex if there’s been a team in over its head for a long period of time. Decisions made inexpertly compound over the life of a project. Very often, this means a lot of esoteric knowledge must be mastered before a person can contribute to the project. The more esoteric, the more time it takes for people to become fluent in how to get things done, the less penetrable the project. Top talent will be frustrated in attempts to get work done in an (unnecessarily) complex environment. Meanwhile, those who “get things done” do so through mastery of a set of circumstances (that is, abundant esoteric characteristics) that cause more harm than good for the business. Such a project is capability illiquid and is resistant to rescue efforts. This creates a worst-case scenario in the IT portfolio: maintaining the status quo is perpetually expensive, while the price of rectifying the situation may be staggering. Either way, yield on the asset this team produces will fall far short of expectations.

There will always be some degree of capability leverage in IT projects, if for no other reason than there will always be incongruities in talent, skill and experience among members of a project team. Leverage is most effective when it is used to develop the capability of the entire team through transfer of knowledge and structured skill acquisition, so that individual team members are capable of independently taking competent decisions that are aligned with governance expectations. An investment in people's capability reduces the risk and impact of a margin call. Of course, this doesn’t just happen by itself: skill transfer is a mission objective, and teams don’t necessarily engage in this type of behaviour naturally unless that expectation is clearly set. Simultaneously, capability development isn’t something that can be taken for granted. There is no “capability index” in IT, so it is essential to have a sense of what the desired future state of a leveraged IT team should be once it unwinds – and to have objective criteria that define that state. Otherwise, there is little assurance that any given delivery team is not a margin call waiting to happen.

There are no shortage of opportunities to leverage IT capability, but there are few opportunities to wield it in a risk responsible manner. Prudent governance requires that IT manage itself and its suppliers to mitigate capability risk so that a project isn’t over-leveraged, to be at the ready to source capability to bring to bear on a situation, and to maintain projects to be in a position to do so. Failing to do so is a lapse in governance. Doing so successfully balances risk and reward.

¹ The great de-leveraging we're seeing in the financial world is both rapid and devastating. By way of example is Carlyle Capital: leveraged to 32 times equity, they couldn't meet margin calls as asset values cratered. breakingviews.com produced a splendid bit of analysis titled Carlyle's Comeuppance.

Minimising the Speculative Risk of IT Investments

2008-02-29T21:06:00.013-06:00

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

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

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

The tangible value is the return realised from that portion of the solution that is in production and contributing to EBITDA. Something in production is complete and increasing bottom line results, so the benefit of this asset isn’t ambiguous.
The intangible value is entirely speculative: how much additional profitability does the business expect to derive from what remains to be delivered?

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

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

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

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

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

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

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

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

IT Effectiveness is Measured by Asset Yield

2008-01-28T23:18:00.002-06:00

We tend to consider an IT project successful if it is delivered “on time and on budget.” From an IT governance perspective, however, this doesn’t tell us all that much. At best it is an indicator of basic operational competence, that fundamental project controls are working. At worst it’s a false positive, indicating nothing more than the team was particularly lucky that all assumptions held true, or that their contingency was sufficiently large to absorb the impact of those assumptions that didn’t.

As a measure of IT effectiveness, it is incomplete. The key element missing is whether or not the project met its business objectives. Indeed, measuring systems by their compliance to plan ignores the mission of the project: it focuses on execution, at the exclusion of results. That is, “on time on budget” at best assumes that the business goal was met, at worst abdicates responsibility for it. The objective is to create a business solution, not to simply perform tasks to a forecast.

Business solutions are business investments. These investments are no different from any other use of the firm’s capital. They are made for one reason, and only one reason – to maximise profitability. Sometimes they are initiatives, for example when new systems are developed to support new trading products. Sometimes they are reactionary, driven by the need to comply with a new regulation or respond to competitive market offerings. A firm makes an investment in an IT solution as a way to maximise operational efficiency, and thus EBITDA. If IT application development produces assets which drive EBITDA, we should manage IT projects to maximise asset yield.

Asset yield tells us how effective IT is in its stewardship of the money with which it is entrusted by the firm. With this measure we have a business-oriented way to answer the first governance question: are we getting value for money? This is very powerful. It allows us to take better oversight decisions: we quickly identify where IT is contributing to breakaway results, and where it would be better off putting capital into Treasuries instead of investing in operations because IT is letting the side down. It also improves the day-to-day execution of our different projects: behaviours¹ should align with the business goals (the business solution), not an abstraction of the goals (the project plan.) We thus get a simple litmus test to evaluate day to day decisions we take relative to the first governance question: does it improve asset yield?

By focusing on asset yield, we become aware of something else: time-to-market has a greater impact on yield than cost. In the on time on budget world, it’s usually tolerable for a project to be late in delivery if the budget implications are minimal. This is because in most corporations it’s far easier for a manager to be granted additional time (people are on the payroll anyway, so it’s a committed cost), while securing additional budget is nearly impossible (annual expense controls make it difficult to change allocations). The time value of capital is invisible to most managers, and its impact is noticeably absent from project decision making. To wit, rarely do project managers request additional budget to deliver a project ahead of plan because they can maximise business returns.

The fact that the time value of money is invisible to most middle management has disastrous consequences for a firm. An IT asset that is not in production yields no returns. An IT asset will yield more business benefit than it costs to develop; otherwise, the firm wouldn’t invest in it. That means each month of delay depresses yield, while the incremental cost of accelerating delivery can increase yield. Even further, lethargic delivery within budget will yield far less than aggressive delivery in excess of budget.

The converse is also true: the sooner the asset is in production, the greater the yield. Consider a project with an estimated 12 month / $6mm development cost and 17% annual maintenance that will contribute an annualised $30mm in profitability for a firm with an 8% cost of capital. A “big bang” deployment after 12 months yields a return above the firm’s cost of capital, but it is both lower and realised later than if those returns can be partially realised with incremental releases (e.g., at 3 months and 9 months) that provide modest contributions to EBITDA (say, 10% and 30% of the projected impact, respectively). It is also obvious that the disparity between incremental and single-even delivery is amplified in the event of delay.

To be a strategic capability, IT leadership must shift focus away from cost minimisation in favour of time to market. The effort spent in recent years by IT departments to reduce spend is effort misplaced for strategic IT. This is not only because volatile currency markets have made labour arbitrage tactics less effective, but because we’re focused on the wrong end of the equation: whether we’re spending $200 / hour or $20 / hour for a developer, an asset that the business cannot use is of no value. Time, not cost, is the lever IT should be looking to throw. This means IT must capable of delivering in short timeframes and working in greater collaboration with the business partners to produce assets with a high degree of solution fitness. To maximise yield, it is more important to build this capability than it is to source a low-cost capacity.

Making this the business reality isn’t that easy. IT doesn't typically make incremental deliveries, it makes single deliveries following long development lifecycles. Similarly, most business operations are not prepared to deal with training and workflow changes necessary to consume frequent solution deliveries. But do these things, it must. With a rising cost of capital, M&A, stock buyback and startup investments are out of reach. Compounding this, large debt loads coupled with a soft economy will put even more pressure to achieve bottom line results. Investments in operations are now that much more critical to the success – if not the sustainability – of a business. Hustle will be the order of the day, urgency the imperative. Well governed IT is the centerpiece of executing this strategy.

¹ There is an important distinction to make here. IT is not a business of assets. It’s a business of people creating assets. We can measure results by focusing on asset yield, but those yields are only achieved by the capability and successful execution of the people we have to achieve them.

Mitigating Capability Risk

2007-12-28T14:56:00.000-06:00

With the cost of capital on the rise, the need to focus on returns is much more acute. Unfortunately, IT has not traditionally excelled at maximising returns. Industry surveys consistently show that a third to a half of all IT projects fail outright or significantly exceed their cost estimate.¹ Delays are costly: IRR craters 25% if a $5mm / 12 month project with an estimated annual yield of $30mm is 4 months late. Monte Carlo simulation that factors the most common project risks, including schedule, turnover, and scope inflation, will consistently show that the probability of delivery being made 3 months late or later is greater than the probability that delivery will occur early, on time, or within one month of delivery.²

Given the significant contribution of technology to just about every business solution, IT risk management is a critical practice. But IT risk management practices are not mature. Planning models tend to be static representations of a project universe, regardless the time horizon. Risks are managed as exceptions. When things change, as they inevitably do, we try to force exceptions back into compliance with the plan. Given all the variables that can change – core technologies and compatibilities, emergent best practices, staff turnover, and a business environment that can best be described as “turbulent” - traditional approaches of “managing to plan” have a low risk tolerance.

To manage risk in our environment, we must first understand the nature of risk. Market risk offers the possibility of returns for invested capital. The yield depends on a lot of factors which an investor may influence, but over which the investor likely has little control: that a market materialises for the offering, that the company is not outmaneuvered by competitors, and so forth. Some market risks have potential to generate breakaway returns – yields well above a firm’s cost of capital. These opportunities represent the most strategic investments to a firm. IT doesn’t face market risks, IT faces primarily execution risk: that it can deliver solutions in accordance with feature, time, cost and quality expectations. Execution risk factors that are substantially within the control of an investing company because it had more direct control over them.

Execution risk is the risk of committing an unforced error. Poor execution depresses returns (again, consider the impact to IRR for a late delivery), whereas competent execution does little more than maintain expected returns. Maximising execution can amplify yield. Using the example above, making incremental deliveries beginning at 3 months can increase project IRR between 5 and 10%. This is, obviously, a significant competitive weapon. But this capability can be monetised only if it can be exploited by the business itself. This, then, is the impact of IT on returns: highly capable execution can create extraordinary returns, but only if the business can put it to use, and the market opportunity exists in the first place. The yield ceiling is dictated by the potential in the business opportunity itself, not in how it is executed. Execution risk, then, is a threat to returns, not an enabler of them.

Execution risk is not simply the risk that things don't get done; e.g., that excessive days out of office prevent people from performing tasks by specific dates. It is the risk that the organisation has the fundamental capability to identify, understand and solve the problems and challenges it faces in realisation of a solution. This means that execution risk is substantially capability risk: that IT brings the right level of capability to bear to minimise the risk of execution failure and thus maximise returns.

Breakaway market opportunities present the greatest challenges to fulfillment. They involve things that haven’t been done before: a product, service, or business competence that doesn’t currently exist within a firm or even an industry. The business processes that need to be defined, modeled and automated to fulfill that market opportunity will not be established at the front end of a project. They will change significantly over the course of fulfillment as they become better understood. Breakaway opportunities tend also to be highly sensitive to non-functional requirements, such as performance, scalability and security. It is subsequently highly likely that there will be new or emergent technologies applied, if not outright invented, over the course of delivery. All together, this means that the problem domain will be complex and dynamic. These are not problem domains that lend themselves to a divide-and-conquer approach, they are domains that require a discover-collaborate-innovate approach. This calls for people who are not only intelligent, but strong, open-minded problem-solvers with a predisposition to work collaboratively with others. It isn’t a question of engaging experienced practitioners; it is a question of engaging high-capability practitioners.

If we fail to understand the capability demands of breakaway opportunities, and similarly fail to recognise the capability of the people we bring to bear to fulfill them, we amplify capability risk. Consider what happens under the circumstances described above if we take a “mass production” approach to delivery. We define a static set of execution parameters for a largely undefined domain. We make a best effort decomposition of an emergent business problem into compartmentalised task inventories. We then look to fulfill these using the lowest cost IT capacity that can be sourced, grading it on a single dimension of capability – experience – which constitutes the extent of our assessment of team strength. Because the situation requires a high degree of problem solving skills and collaboration, this approach quickly over-leverages the highest capable people. This leaves the mass of executors wasting effort on misfit solutions, or it leaves them idle, waiting for orders. A recent quote from Shari Ballard, EVP of Retail Channel with Best Buy, highlights this:

'Look at why big companies die. They implode on themselves. They create all these systems and processes – and then end up with a very small percentage of people who are supposed to solve complex problems, while the other 98% of people just execute. You can’t come up with enough good ideas that way to keep growing.'³

Because capability isn’t present in the decision frame, we run a significant probability of defaulting into a state of capability mismatch. This obliterates any possibility of cost minimisation (over-running the mass production model) and jeopardises the business returns.

IT is a people business, as opposed to an asset or technology business. The assets produced by IT – that is, the solutions bought by the business – are the measurable results produced by capability. Capability risk management is a byproduct of effective IT Governance. While it has a stewardship responsibility for the capital with which it is entrusted, IT Governance is primarily concerned with sourcing, deploying and maturing capability to maximise business returns. It looks to trailing indicators – which with Agile practices can be made “real time” indicators – that evaluate the quality of assets produced and the way in which those assets are produced. These allow it to determine whether current capability delivers value for money, and delivers solutions in accordance with expectations. It must also look to leading indicators that assess the skills, problem solving abilities and collaborative aptitude of its people, no matter how sourced: employee, contractor, consultant or outsourcer. By so doing, IT becomes a better business partner as it can unambiguously assess and improve its ability to maximise returns.

¹There is the classic mid-90s Chaos Report by the Standish group that posited that as many as 50% of all IT projects fail. See also, “Reduce IT Risk for Business Results,” Gartner Research, 14 October 2003

²The seminal work in this area is Waltzing with Bears by Tom DeMarco and Tim Lister. They published a Monte Carlo method in a spreadsheet called Riskology that allows you to explore risk factors and tolerances and their impact on a project forecast.

³Ms. Ballard was quoted by Anders, George. “Management Leaders Turn Attention to Followers” The Wall Street Journal, 24 December 2007.

Market Power Increases Exponentially with IT Velocity

2007-11-25T11:58:00.000-06:00

Bernoulli’s Theorem holds that the potential power that can be produced by a turbine or rotor is equal to the cube of the velocity with which the turbine rotates, expressed simply as Power = Velocity³. A basic concept of wind energy systems, it is increasingly relevant in commercial building architecture: specifically, if wind velocity can be increased through building design, the potential power that a building can derive from wind energy is considerably greater. This means that a building can be designed such that it generates a non-trivial portion of its electrical power from wind energy.¹

The exponential relationship of power to velocity is similarly evident in the relationship between business competitiveness and IT application development. Specifically, market power should increase exponentially with increases in IT velocity.

We can define velocity as the measure of the rate of delivery, expressed in the time it takes for a finely grained business need to go from idea to implemented solution. Here, we are interested in assessing the rate at which functionality is delivered: a dozen features² delivered in a 6 month time frame have an average velocity of 6 months, not 0.5 months (12 features delivered in 6 months is not 0.5 months to produce one feature; time to production is 6 months). Restated, we hold time constant to assess the time it takes for new features to go from end to end of the delivery pipeline.

The power derived from this velocity is the ability of the company to exert itself in the marketplace. That is, a company has power in the market if it attracts customers, employees, partners and investors through execution of its strategy; it also has power if it forces competitors react if they are to retain what they have. This could be anything from having a lower cost footprint, features and functionality in solution offerings that competitors simply don’t have, or having the best tools or solution offering that attracts the top talent. The more change that a firm creates in its market, the more influence it exerts over an industry: competitors will be forced to spend resources reacting to somebody else’s strategy, not pursuing their own.

In the aggregate, power is abstract in this definition. An economic model that assesses the extent to which a firm has market power would be substantially an academic exercise. There are, however, tangible indicators of market power that are worthy of mention in the annual report: net customer acquisition, relative cost footprint, and competitive hires and exits are all hard measures of market power. These are real and significant business benefits: indeed, making competitors react by destabelising their agenda is of exponentially greater value than that of the innovations themselves.

Because all of these can be enabled or amplified by IT, velocity is subsequently a key measure of IT effectiveness. It is a particularly critical concept for IT in both Governance and Innovation.

Velocity is a key metric of the first of our two Governance questions: are we getting value for money? Many company's market offerings or cost competitiveness are rooted in applied technology. It stands to reason that the rate at which functionality is delivered increases business competitiveness either by constantly adding capability or by aggressively reducing costs. Sustainable IT velocity maintains market power; an increase in this velocity increases market power. Velocity, then, is a key indicator of the first governance question in that it provides a quantified assessment of IT’s value proposition to an organisation.

It is also an indicator of how effectively IT drives innovation. Business innovation is the consistent, rapid and deliberate maturation of products, services, systems and capabilities. As, again, businesses are increasingly dependent on technology for capability and cost, the rate with which IT delivers functionality will be an indicator of how effective IT is as an enabler of business innovation. While an intangible concept, this allows IT to position itself as a driver of business innovation and not simply a utility of technology services.

This is not simply a question of delivering IT solutions, but of how those solutions are consumed by the business. IT may make frequent deliveries, but if they are not consumed, organisational velocity is reduced. This is not the same as what happens in the market. The opportunities to exploit an innovation or solution delivered may not materialise in the market; in this case, the potential market power achievable by IT velocity will not be realised. If, however, solutions are delivered by IT but not consumed by the business, velocity is never truly maximised. This is an important distinction, because IT is not governed exclusively by how it is delivered; it is governed by how effectively it is consumed. Ignoring the “buy side” makes it too easy for an IT organisation to create false efficiencies or meaningless business results because it is knowingly or otherwise out of alignment with its host organisation. This lack of alignment doesn’t leave power potential unrealised, it undermines velocity.

This is actionable market behaviour with historical precedent. General George S. Patton understood the need to constantly bring the fight to the enemy. “Patton… clearly appreciated the value of speed in the conduct of operations. Speed of movement often enables troops to minimise any advantage the enemy may temporarily gain but, more important, speed makes possible the full exploitation of every favorable opportunity and prevents the enemy from readjusting his forces to meet successive attacks. Thus through speed and determination each successive advantage is more easily and economically gained than the previous one. … [R]elentless and speedy pursuit is the most profitable action.”³ Inciting market change, then, determines whether you follow your strategy or react to another’s.

The ability to disrupt a market by introducing change allows a company to execute its strategy at the expense of its competitors. Business execution, increasingly rooted in technology, thus derives a great deal of its competitive advantage from the rate at which it can change its technology and systems. Velocity, the sustained rate at which business needs mature from expression to implemented solution, is therefore a key IT governance metric. It is, in fact, an expression of ITs value proposition to its host organisation.

¹ I am indebted to Roger Frechette for introducing me to this element of Bernoulli’s theorem. There are a number of articles highlighting his work on the Pearl River Tower, which when completed will be a remarkable structural and mechanical engineering achievement.
² In this context, a feature is the same as an Agile story: "simple, independent expressions of work that are testable, have business value, and can be estimated and prioritised."
³ Eisenhower, Dwight D. Crusade in Europe Doubleday, 1948. p. 176.

IT Governance Maximises IT Returns

2007-10-28T21:42:00.000-05:00

In recent years, Michael Milken has turned his attention to health and medicine. Earlier this year, the Milken Institute released a report concluding that 7 chronic illnesses – diabetes, hypertension, cancer, etc. – are responsible for over $1 trillion in annual productivity losses in the United States. They go on to report that 70% of the cases of these 7 chronic illnesses are preventable through lifestyle change: diet, exercise, avoiding cigarettes and what not.¹ In a recent interview on Bloomberg Television, Mr. Milken made the observation that because of the overwhelming number of chronic illness cases, medical professionals are forced to devote their attention to the wrong end of the health spectrum in the US. That is, instead of creating good by increasing life expectancy and enhancing quality of life through medical advancement, Mr. Milken argues that the vast majority of medical professionals are investing their energy into eliminating bad by helping people recover from poor decisions made. It’s obviously a sub-optimal use medical talent, and through sheer size is showing signs of overwhelming the medical profession. It is a problem that will spiral downward until the root causes are eradicated and new cases of “self inflicted” illness abates.

This offers IT a highly relevant metaphor.

Many of the problems that undermine IT effectiveness are self-inflicted. Just as lifestyle decisions have a tremendous impact on quality of life, how we work has a tremendous impact on the results we achieve. If we work in a high-risk manner, we have a greater probability of our projects having problems and thus requiring greater maintenance and repair. Increased maintenance and repair will draw down returns. The best people in an IT organisation will be assigned to remediating technical brownfields instead of creating an IT organisation that drives alpha returns. That assumes, of course, that an IT organisation with excessive brownfields can remain a destination employer for top IT talent.

This suggests strongly that “how work is done” is an essential IT governance question. That is, IT governance must not be concerned only with measuring results, but also knowing that that the way in which those results are achieved is in compliance with practices that minimise the probability of failure.

This wording is intentional: how work is performed reduces the probability of failure. If, in fact, lifestyle decisions can remove 70% of the probability that a person suffers any of 7 chronic conditions, so, too, can work practices reduce the probability that a project will fail. Let’s be clear: reducing the probability of failure is not the same as increasing the probability of success. That is, a team can work in such a way that it is less likely to cause problems for itself, by e.g., writing unit tests, having continuous integration, developing to finely grained statements of business functionality, embedding QA in the development team, and so forth. Doing these isn’t the same as increasing the probability of success. Reducing the probability of failure is the reduction of unforced errors. In lifestyle terms, I may avoid certain actions that may cause cancer, but if cancer is written into my genetic code the deck is stacked against me. So it is with IT projects: an extremely efficient IT project will still fail if it is blindsided because a market doesn’t materialise for the solution being developed. From a solution perspective, we can do things to control the risk of an unforced error. This is controllable risk, but it is only internal risk to my project.

This latter point merits particular emphasis. If we do things that minimise the risk of an unforced error – if we automate a full suite of unit tests, if we demand zero tolerance for code quality violations, if we incrementally develop complete slices of functionality – we intrinsically increase our tolerance for external (and thus unpredictable) risk. We are more tolerant to external risk factors because we don’t accumulate process debt or technical debt that makes it difficult for us to absorb risk. Indeed, we can work each day to maintain an unleveraged state of solution completeness: we don’t accumulate “debt,” mortgaged our future by needing downstream effort (such as “integration” and “testing”) that accumulates a partial solution which is alleged to be complete. Instead, we pull downstream tasks forward to happen with each and every code commit, thus maintaining solution completeness with every action we take.

One of our governance objectives must be that we are cognisant of how solutions are being delivered everywhere in the enterprise, because this is an indicator of their completeness. We must know that solutions satisfy a full set of business and technical expectations, not just that solutions are “code complete” awaiting an unmeasurable (and therefore opaque) process that makes code truly “complete.” These unmeasurable processes take time, and therefore cost; they are subsequently a black-box: we can time-box them, but we don’t really know the effort that will be required to pay down any accumulated debt. This opacity of IT is no different from opacity in an asset market: it makes the costs, and therefore the returns, of an IT asset much harder to quantify. The inability to demonstrate functional completeness of a solution (e.g, because it is not end-to-end developed) as well as the technical quality of a solution (through continuous quality monitoring) creates uncertainty that the asset that is going to provide a high business return. This uncertainty drives down the value of the assets that IT produces. The net effect is that it drives down the value of IT, just as the same uncertainty drives down the value of a security.

If the governance imperative is to understand that results are being achieved in addition to knowing how they are being achieved, we must consider another key point: what must we do to know with certainty how work is being performed? Consider three recent news headlines:

Restaurant reviews lack transparency: restauranteurs encourage employees to submit reviews to surveys such as Zagat, and award free meals to restaurant bloggers who often fail to report their free dining when writing their reviews.²

Some watchmakers have created a faux premium cachet: top watchmakers have been collaborating with specialist auction houses to drive up the prices by being the lead bidders on their own wares, and doing so anonymously. The notion that a Brand X watch recently sold for tens of thousands of dollars at auction increases the brand’s retail marketability by suggesting it has investment-grade or heirloom properties. That the buyer in the auction might have been the firm itself would obviously destroy that perception, but it is obfuscated from the retail consumer.³

The credit rating of mortgage backed securities created significant misinformation in risk exposure. Clearly, a AAA rated CDO heavily laden with securitised sub-prime mortgage was never worthy of the same investment grade as, say, GE corporate bonds. The notion that what amounted to high-risk paper could be given a triple-A rating implied characteristics of the security that weren’t entirely true.

Thus, we must be very certain that we understand fully our facts about how work is being done. Do you have a complete set of process metrics established with your suppliers? To what degree of certainty do you trust the data you receive for those metrics? How would you know if they’re gaming the criteria that you set down (e.g., meaningless tests are being written to artificially inflate the degree of test coverage)? We must also not allow for surrogates: we cannot govern effectively by measuring documentation. We must focus on deliverables, and the artifacts of those deliverables, for indicators of how work is performed. A recent quote dating to the early years of CBS News is still relevant today: “everybody is entitled to their own opinion, but not their own facts.”⁴ Thus, IT governance must not only pay attention to how work is being done, it must take great pains to ensure that the sources of data that tell us how that work is being done have a high degree of integrity. People may assert that they work in a low-risk manner, but that opinion may not withstand the scrutiny of fact-based management. As with any governance function, the order of the day is no different than administration of nuclear proliferation treaties: “trust, but verify.”

This entire notion is a significant departure from traditional IT management. As Anatole France said of the Third Republic: “And while this enfeebles the state it lightens the burden on the people. . . . And because it governs little, I pardon it for governing badly.”⁵ On the whole, IT professionals will feel much the same about their host IT organisations. Why bother with all this effort to analyse process? All anybody cares about is that we produce "results" - for us, this means getting software into production no matter what. This process stuff looks pretty academic, a lot of colour coded graphs in spreadsheets. It interferes with our focus on results.

Lackadaisical governance is potentially disasterous because governance does matter. There is significant data to suggest that competent governance yields higher returns, and similarly that incompetent governance yields lower returns. In a 2003 study published by Paul Gompers, buying companies with good governance and selling those with poor governance from a population of 1,500 firms in the 1990s would have produced returns that beat the market by 8.5% per year.⁶ This suggests that there is a strong correlation between capable governance and high returns. Conversely, according to this report, there were strong indicators in 2001 that firms such as Adelphia and Global Crossing had significant deficiencies in their corporate governance, and that these firms represented significant investment risk.

As Gavin Anderson, chairman and co-founder of GovernanceMetrics International recently said, “Well governed companies face the same kind of market and competitor risks as everybody else, but the chance of an implosion caused by an ineffective board or management is way less.”⁷ The same applies to IT. Ignoring IT practices reduces transparency and increases opacity of IT operations, reducing IT returns. Governing IT so that it minimises the self-inflicted wounds, specifically through awareness of “lifestyle” decisions, creates an IT capability that can drive alpha returns for the business.

¹DeVol, Ross and Bedroussian, Armen with Anita Charuworn, Anusuya Chatterjee, In Kyu Kim, Soojung Kim and Kevin Klowden. An Unhealthy America: The Economic Burden of Chronic Disease -- Charting a New Course to Save Lives and Increase Productivity and Economic Growth October 2007
²McLaughlin, Katy. The Price of a Four Star Rating The Wall Street Journal, 6-7 October 2007.
³Meichtry, Stacy. How Top Watchmakers Intervene in Auctions The Wall Street Journal, 8 October 2007.
⁴Noonan, Peggy. Apocalypse No The Wall Street Journal, 27-28 October 2007.
⁵Shirer, William L. The Collapse of the Third Republic Simon and Schuster, 1969. Shirer attributes this quote to Anatole French citing as his source Histoire des littératures, Vol. III, Encyclopédie de la Pléiade
⁶Greenberg, Herb. Making Sense of the Risks Posed by Governance Issues The Wall Street Journal, 26-27 May 2007.
⁷Ibid.

Investing in Strategic Capability versus Buying Tactical Capacity

2007-09-26T21:41:00.000-05:00

US based IT departments are facing turbulent times. The cost efficiencies achieved through global sourcing face a triple threat to their fundamentals:

The USD has eroded in value relative to other currencies in the past 6 years¹ – this means the USD doesn’t buy as much global sourcing capacity as it did 6 years ago, particularly vis-à-vis its peer consumer currencies.

The increase in global IT sourcing is outpacing the rate of development of highly-qualified professionals in many markets² – salaries are increasing as there are more jobs chasing fewer high-qualified candidates, and turnover of IT staff is rising as people pursue higher compensation.
Profitability growth in the high end of the IT consumer market remains strong – As the returns of firms at high end of the IT consumer market continue to be strong – Goldman Sachs just had its 3rd best quarter in its history³ – demand will intensify for highly capable people.

This could significantly change labour market dynamics. Since the IT bubble, the business imperative has been to drive down the unit cost of IT capacity (e.g., the cost of an IT professional per hour). This has been achieved substantially through labour arbitrage – sourcing IT jobs from the lowest cost provider or geography. However, the reduced buying power of the USD, combined with increasing numbers of jobs chasing fewer people, plus an increase in demand at the high end of the labour market, means that simple labour arbitrage will have less impact on the bottom line. As IT costs change to reflect these market conditions, US-based IT organizations will face an erosion of capability.

In one sense, labour is to the IT industry as jet fuel is to the airline industry: IT is beholden to its people, just as airplanes don’t fly without fuel. For quite some time, we’ve attempted to procure labour using a commodity approach: somebody estimates they have x hours of need, which means they need y people, which will then globally sourced from the least expensive provider. The “unit cost optimisation” model of pricing IT capability defaulted into success because of the significant cost disparity in local versus offshore staff. The aforementioned market trends suggest that the spread may narrow. If it does, a number of the underlying assumptions are no longer valid, and fundamental flaws in most labour arbitrage models is exposed: specifically, that IT needs are uniform, and IT capabilities are uniform and can be defined as basic skills and technical competencies.

Unlike jet fuel, labour isn’t a commodity. Not every hour of capacity is the same. There are grades of quality of capability that defy commoditisation. This means there is a quality dimension that is present yet substantially invisible when we assess capacity. Macro-level skill groupings are meaningless because they’re not portable (e.g., one organisation’s senior developer is another’s junior). They also fail to account for labour market trends: if the population of Java coders increases in a specific market but new entrants lack aptitude and experience and their training is inferior, we have a declining capability trend that is completely absent from our sourcing model. Nor is capacity linear – two people of lower capability will not be as effective as one person of high capability, and too many low capability people create more problems than they solve. An IT organisation which stabilised around simple unit-cost optimisation will find itself at the mercy of a market which it may not fully understand, with characteristics which haven’t factored into its forecasts.

The commodity model also ignores how advanced IT systems are delivered. High-return business solutions don’t fit the “mass production” model, where coders repetitively apply code fragments following exacting rules and specifications. Instead, business and IT collaborate in a succession of decisions as they navigate emerging business need whilst constantly integrating back to the tapestry of existing IT components and business systems. This requires a high degree of skill from those executing. It also requires a high degree of meta knowledge or “situational awareness,” that is, domain knowledge and environmental familiarity necessary to deliver and perpetuate these IT assets. This includes everything from knowing which tools and technology stacks are approved for use, to how to integrate with existing systems and components, to what non-functional requirements are most important, to how solutions pass certification. Combined, this meta knowledge defines the difference between having people who can code to an alleged state of “development complete” versus having people who can deliver solutions into production.

Because the assets that drive competitiveness through operations are delivered through a high-capability IT staff, unit cost minimisation is not a viable strategy if IT is to drive alpha returns. Strategic IT is therefore an investment in capability. That is, we are investing not just in the production of assets that automate operations, we are investing in the ability to continuously adjust those IT assets with minimal disruption, such that they continue to support evolving operational efficiencies. This knowledge fundamentally rests with people. The value of this knowledge is completely invisible if we’re buying technology assets based on cost.

This brings us back to current market conditions. At the moment, tactical cost minimisation works against the USD denominated market competitor. The EUR, CHF, AUD, CAD or GBP competitor can afford to increase salaries wherever sourced without as much bottom-line impact as their USD competitors. They subsequently have an advantage in attracting new talent, and are better positioned to lure away highly capable people from US based competitors. In addition, the increased cost of IT for the US based competitor might mean more draconian measures, such as staff reductions, to meet budget expectations. To avoid the destruction of capability, a US IT organisation may look to simply shift sourcing from international to local markets. But this shift is not without its risk in durability (will the USD rise again to match historical averages?), competitive threat (other firms will follow the same strategy and drive up local market salaries), or cost of change (nothing happens in zero time, and the loss / replacement of meta knowledge comes at a cost.) Clearly, global sourcing is no longer a simple cost equation. It is complex, involving a hedge on investing in sustainable capability development relative to competitive threats and exchange rate fluctuations.

Responding to this challenge requires that the IT organisation have a mature governance capability. Why governance? Because surviving the convulsions in the cost of the “jet fuel” of the IT industry requires that we frame the complete picture of performance: that value is delivered, and that expectations (ranging from quality to security to regulatory compliance) are fully satisfied. IT doesn’t do this especially well today. It suffers no shortage of metrics, but very few are business-facing. The absence of so few business-oriented metrics gives “cost per hour” that much more prominence, and fuels the unit cost approach to IT management.

Breaking out of this requires assessing the cost of throughput of IT as a whole and of teams in particular, not of the individual. IT is only as capable as the productivity of its cross-functional execution; specifically, how effectively do IT teams steer business needs from expression to production, subject to all the oddities of that particular business environment. If the strength of currently sourced teams can be quantitatively assessed, the organisational impact of a potential change in IT sourcing can be properly framed. The lack of universal capability assessment, and the immaturity of team-based results analysis mean that an IT governance function must define these performance metrics for itself, relative to its industry, with cooperation and acceptance from its board. Without it, IT will be relegated to a tactical role, forever chasing the elusive “lowest unit cost” and perpetually disappointing its paymasters, struggling to explain the costs of execution which cannot be accounted in a unit cost model.

If an IT organisation is focused on team throughput and overall capability, it can strategically respond to this threat. Just as jet fuel supply is secured and hedged by an airline, so must labour supply be strategically managed by IT. This means managing the labour supply chain⁴ to continuously source high capability people, as opposed to recruiting to fill positions as they become vacant. This requires managing supply and demand by doing such things as anticipating need and critically assessing turnover, creating recruiting channels and candidate sources, identifying high-capability candidates, rotating people through assignments, understanding and meeting professional development needs, setting expectations for high-performance, providing professional challenges, offering training and skill development, critically assessing performance, managing careers and opportunities, correcting poor role fits and bad hiring decisions, and managing exits.

Doing these things builds a durable and resilient organisation – attributes that are invisible in a cost center, but critical characteristics of a strategic capability. This is, ultimately, the responsibility of an IT organisation, not an HR department. HR may provide guidelines, but this is IT’s problem to solve; it cannot abdicate responsibility for obtaining its "raw materials." Clearly, building a labour pipeline is a very challenging problem, but it's the price of admission if you're going to beat the market.

IT drives alpha returns not just through the delivery of strategic IT assets, but by investing in the capability to consistently deliver those assets. If capability moves with the labour market, an IT organisation will yield no better then beta returns to the business. Current market indicators suggest that it will be difficult for US based firms to maintain their current levels of capability, thus the business returns driven by an IT capability that moves with the market are likely to decline. Tactical buyers of IT are facing a cost disparity, and will have few cards to play that don't erode capability. Strategic investors in IT can capitalise on these trends to intensify strengths, and even disrupt competitors, through aggressive management of its labour pipeline.

¹ Comparing August 2001 to August 2007 monthly averages, the USD declined 28% to the GBP, 34% to the EUR, 28% to the CHF, 37% to the AUD, 31% to the CAD, 13% to the INR, 8% to the CNY. Exchange rate data was pulled from Oanda.

² Technology job growth and salaries are on the rise worldwide. Two recent articles highlight India
and the US. Also, I’ve referenced the following two previously, but Adrian Wooldridge makes a compelling argument for the increased competition for talent, and there’s ample data on the gap between job growth and volume of new entrants. There’s some recent articles evaluating the quality of talent but I don’t have those handy.

³ Profitability among market leaders and overall technology sector growth continues to be strong globally.

⁴ I am indebted to Greg Reiser for this term.

Good Management Can Work Miracles

2007-08-24T00:02:00.000-05:00

Pharmaceutical companies do not successfully deliver drugs just because they hire a lot of highly skilled researchers in lab coats. They deliver drugs because they have people to secure funding for research of some drugs over others, to take them through lab and clinical trial, to steer them through regulatory approval, to manufacture, to make doctors aware of them, to distribute them to hospitals and pharmacies, and to follow-up on results. When it all comes together, the overall benefit of the resulting system can be incredible, such as an increase in life expectancy. As Thomas Teal wrote succinctly, “Good management works miracles.”¹

The same applies to an Information Technology organisation that is core to achieving alpha returns: it needs the management practices to match high-capability people. Consider Xerox PARC. In the 1970s it spawned tremendous innovation in personal computing technology. From those innovations came products, solutions, and even categories that didn’t previously exist. Billions of dollars of revenue and profitability were generated – for everybody but Xerox. Why? Bright people were inventing and innovating, but nobody was there to monetise their work.²

In general, IT has structural and social deficiencies that conspire against development of a management capability. Technical IT jobs offer individual satisfaction on a daily basis, with frequent feedback and acknowledgement of success at solving a very specific problem or challenge. IT reward systems are also often based on individual performance tied to granular and highly focused statements of accomplishment. This is contrary to IT management positions where the results of decisions made may not be realised for weeks or months, measures of success are often less tangible, and rewards based on the performance of a large collection of individuals. It is also not uncommon for a company to belittle the value of management by defining it as a collection of supervisory or hygienic tasks e.g., to ensure everybody on a team has taken requisite compliance training each quarter and submits their timesheet each week. In other instances, line management may simply have all decision-making denied it, relegated to polling subordinates to find what’s going on to summarise and report upwards, while also being given messages from higher up to deliver to the rank and file. These aren’t management practices, they’re tasks of administrative convenience masquerading as management.

These deficiencies are supplemented by an IT industry that, on the whole, doesn’t place much value on management. Technical people promoted into management positions will very often resist management responsibilities (e.g., electing to continue to perform technical tasks), and also be highly unleveraged in a team (one manager to dozens of direct reports.) There is more precise definition and greater mobility of technical jobs than of management jobs. The same is true for skill acquisition: there are a wealth of IT oriented books, magazines, journals and publications on very specific technologies or applications of technologies, but not nearly the depth on matters of management. And all too often, what passes for management guidance in books and publications are lightweight abstractions of lessons learnt wrapped in layers of cheerleading and self-esteem building directed at the reader, not principles of sound management science. No surprise, then, that it can be far more attractive for an IT professional to prefer a career path of “individual contributor” over “manager.” Collectively, this doesn’t help increase in number the ranks of capable managers.

One of the root causes is that IT is considered a technology-centric business, as opposed to a people-centric one. ³ By definition, IT solutions – what the business is paying for – are not delivered by technology, but by people. The misplaced orientation toward technology as opposed to people means that management tends to focus not on what it should – “getting things done through people” – but on what it should not – the “shiny new toys” of technology assets. This misplaced focus creates a deficiency in management practices, and widens the capability gulf relative to the demands being placed on IT today. It is a structural inhibitor to success in delivering solutions.

Top-down, high-control management techniques have proven to be orthogonal to the IT industry. Amongst other things, this is because of a high concentration of highly-skilled and creative (e.g., clever at design, at problem solving, and so forth) people who don’t respond to that style of management. It is also because top-down practices assume an unchanging problem space, and thus an unchanging solution space. Unfortunately, this is not a characteristic of much of what happens in technology: IT solutions are produced in a dynamic, creative solutions space. For one thing, most projects are in a constant state of flux. The goal, the defined solution, the people, and the technologies constantly change. This means day to day decisions will not move in lock step with initial assumptions. For another, in most projects there is not a shared and fully harmonised understanding of the problem: if anybody on the team has a different understanding of the problem, if there is latency in communicating change to each member of the team, or if somebody simply wants to solve an interesting technical problem that may or may not be of urgent need to the business problem at hand, decisions on the ground will be out of alignment with overall business needs.

Each IT professional takes dozens of decisions each day. The principal objective in managing a highly-capable organisation is not to take decisions for each person, but to keep in alignment decisions people take. Management of a professional capability is thus an exercise in making lots of adjustments, not pushing blindly ahead toward a solution. But facilitating lots of adjustments isn’t a simple problem because management doesn’t just happen by itself in a team. As Dr. George Lopez found out, changing to self-managed work teams isn’t a turnkey solution:

With no leaders, and no rules, "nothing was getting done, except people were spending a lot of time talking." After about a year and a half, he decided teams should elect leaders.⁴

But that, too, isn’t enough. The basic management tools and structures must be present or this simply doesn’t work. Consider this description of Super Aguri’s F1 pre-race meetings:

"The process is very formal," says Super Aguri sporting director Graham Taylor. "I chair our meetings and ask the individuals present to talk in turn. Anyone late gets a bollocking, only one person is allowed to talk at a time, and it absolutely is not a discussion. It … is absolutely the best way to share a lot of information in a short passage of time. … If you don’t need to be there, you’re not."

… While the briefing process has always been with F1, the structure has evolved to absorb the increasing complexity of cars and the concomitant increase in team size. "When I started in F1 there were 50 people in the team, now there are 500," says [Sam] Michael, […Williams technical director]. "If you don’t have a firm hold, not everyone gets all the information. You need to have structure.”⁵

Consider how many layers a team, or even an individual developer, may be removed from a large IT programme. The lack of upward transparency from the individual and downward visibility from the programme management makes it nearly impossible to keep decisions aligned. This is where good management delivers tremendous value: the basic, focused structures of Agile project management – the daily stand-up, the iteration planning meeting, the retrospective, the iteration tracking report, the release plan – provide focus, structure, and discipline that facilitate maintaining alignment of individual and group goals. A salient point in the example from Super Aguri is that greater team capability makes the need to do these things that much more acute: the higher the degree of professional capability in the team, the more adjustments there can be to make, if for no other reason than the rapidity with which the highly capable will work a problem space.

“We are not a family,” Robert Lane, the CEO of Deere & Co, recently said.⁶ “What we are is a high performance team.” If IT is to deliver high-performance results – to be an alpha capability that contributes to alpha business results – it requires not only high-capability people but the management practices to match.

¹ Teal, Thomas. "The Human Side of Management." Harvard Busines Review. April, 1996. I highly recommend reading this article. He deftly summarises the gap between the impact management has relative to the investment made into developing talent completely. It has arguably become more pronounced in the 11 years since this article first appeared.
² Gross, Daniel. “How Xerox Failed to copy Its Success.” Audacity. Fall, 1995. Audacity, the business journal, has long since ceased publication which is a shame: it provided excellent snippets on business decisions, both successful and unsuccessful, in the broader context of their market conditions.
³ The change in moniker from “Information Systems” to “Information Technology” was, arguably, a step in the wrong direction. The word “systems” is expansive, and extends to solutions with partial technology component to them - or none whatsoever. “Technology” narrows the remit, and thus the business impact, of what we now call “IT.”
⁴ White, Erin. “How a Company Made Everyone a Team Player” The Wall Street Journal, Monday 13 August 2007.
⁵ Grand Prix Tune-Ups” F1 Racing Magazine. August 2007. As perhaps the first among high-performance industries, it’s interesting to see what sounds very much like a stand-up meeting being core to race day execution - and how it has allowed them to scale.
⁶ Brat, Ilan and Aeppel, Timothy. “Why Deere is Weeding Out Dealers Even as Farms Boom” The Wall Street Journal, Tuesday, 14 August 2007.