In the wake of a credit market seizure, illiquid investments, $245 billion of write-downs and losses1, 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,2 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.”3 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.
1Brinsley, John. Treasury Panels Lay Out Hedge Fund `Best Practices' Bloomberg.com, 15 April 2008.
2Ibid.
3Secretary 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.
Labels: Agile Management, IT Governance, Strategic IT
¶ 6:35 AM
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.1
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.
1 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.
Labels: IT Governance, Risk Management
¶ 9:22 PM
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.1
The speculative component of an IT asset is at greater risk the further into the future it is expected to be completed. The probability that business, people or technology will change increases with each additional day that an IT asset is being developed. The probability of slippage in functionality, time and investment introduces volatility to the IT portfolio.
Volatility can generate windfall returns in finance. Market speculation can wildly change the value of a stock or bond relative to its purchase price. The holder can exploit this delta (up or down) to book a profit. By comparison, returns driven by operations are rarely so flexible. Software delivery is work performed over time, and time cannot be recovered. Experience has shown that an IT project is more likely to suffer delays in delivery and depress returns, than it is to accelerate delivery and increase returns. Volatility in delivery is thus a downside force, and needs to be minimised.
Traditionally, IT has attempted to apply deterministic management as a means of reducing volatility. We build elaborate project plans, we map out a predefined collection of tasks, we plot a task order down to the hour, and we track activity of what people do day by day as our barometer of progress. This top-down approach to management has low tolerance for anything that happens in the “left-to-right,” or over the course of time. This approach offers little more than wishful thinking. “Plans are useless,” said Dwight D. Eisenhower, “but planning is indispensable.” Intricate plans that forecast future activity in detail have low tolerance or complete disregard for the impact of changes that occur over time, such as staff, capability, business or technology. Indeed, deterministic project planning holds the business solution static, any staff interchangeable, and any technology change turnkey. Experience has shown overwhelmingly that this is not the case. Projects with intricate plans tend to have continuous cycles of replanning as things change. Deterministic management doesn’t decrease volatility; it simply adds overhead to the IT project, and drives down returns.
A plan cannot increase the tangible value of an IT asset. Only the asset can do that. We should therefore focus energies on rapid and incremental delivery. Tangible value is realised when some functionality is delivered that produces value. With each incremental delivery, and every increase in tangible value, the intangible or speculative value decreases.2 The reduction in speculative value at risk represents a reduction in the total value that can be depressed through delays in delivery. Thus, early delivery reduces the risk of speculative value not being realised. Simultaneously, it reduces the volatility of returns.
By itself, IT doesn’t generate business value. The business must consume the assets that IT produces in such a manner that it can put them to work efficiently and profitably. But that doesn’t mean IT is just a cost center. It can, in fact, drive alpha returns for a business. Corporate capability is largely driven by technology. IT is often the plurality, if not the majority, of spend on business initiatives. Incremental delivery of system components can increase returns on corporate investments where time is more important than cost. With capital under management that is expected to deliver returns, IT governance has a portfolio management obligation. As portfolio managers, IT must do things that maximise yield of invested capital. Concomitant with maximising yield is minimising risk. Risk is minimised through asset realisation.
1 Provided, of course, that what is delivered is functionally and non-functionally fit, and of sufficient quality. These should never be assumed outcomes.
2 New information may lead us to conclude that the impact of the asset will be different than originally forecast. For example, an asset under development might suddenly provide more impact to a firm because of changing market dynamics, making some portions of the application of greater value than others. For sake of simplicity, intrinsic value is assumed constant in this example.
Labels: IT Governance, Risk Management, Strategic IT
¶ 9:06 PM
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: behaviours1 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.
1 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.
Labels: Agile Management, IT Governance, Strategic IT
¶ 11:18 PM
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.1 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.2
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.'3
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.
1There 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
2The 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.
3Ms. Ballard was quoted by Anders, George. “Management Leaders Turn Attention to Followers” The Wall Street Journal, 24 December 2007.
Labels: IT Governance, Risk Management, Strategic IT
¶ 2:56 PM
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 = Velocity3. 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.1
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 features2 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.”3 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.
1 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.
2 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."
3 Eisenhower, Dwight D. Crusade in Europe Doubleday, 1948. p. 176.
Labels: Innovation, IT Governance, Strategic IT
¶ 11:58 AM 0 comments
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.2
- 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.3
- 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.”4 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.”5 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.6 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.”7 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.
1DeVol, 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
2McLaughlin, Katy. The Price of a Four Star Rating The Wall Street Journal, 6-7 October 2007.
3Meichtry, Stacy. How Top Watchmakers Intervene in Auctions The Wall Street Journal, 8 October 2007.
4Noonan, Peggy. Apocalypse No The Wall Street Journal, 27-28 October 2007.
5Shirer, 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
6Greenberg, Herb. Making Sense of the Risks Posed by Governance Issues The Wall Street Journal, 26-27 May 2007.
7Ibid.
Labels: IT Governance, Risk Management, Strategic IT
¶ 9:42 PM 0 comments
