by Ross Pettit - 25 July 2008
Capital markets firms are holding a lot of paper – primarily collateralized debt obligations – that have been subjected to massive writedowns in recent quarters. Among the reasons for the writedowns is the difficulty in valuing the assets that back the paper. These securities are not simple bonds issued against a single fixed income stream, they're issued against collections of assets, sometimes spanning classes: a bond may be backed by a pool of jumbo California residential mortgages as well as a pool of credit card debt from cardholders all over the United States. This makes it difficult to assess risk of the bonds: all the moving parts mean there could be little – or substantial – exposure to different types of market dynamics, obfuscating the risk premium these securities should yield.
Assets like this have been valued – or marked – to a model. In turbulent markets, the models quickly show their limitations because they fail to account for events outside of the rigid, static universe codified by the model. Mass dumping of the securities (and concomitant evaporation of buyers), mass defaults of the underling assets (e.g., mortgage defaults), and loss of market value for the underlying assets (e.g., declining residential home prices) are rarely baked into valuation models. When these events do occur, confidence erodes quickly and the market for these securities declines precipitously.
This forces those holding these assets to make one of two decisions. One is to sacrifice liquidity by holding the paper to maturity. By taking a long position and expecting that the investments will pay off (itself an act of finger-crossing) the holder is able to keep it on their books at a high value. Unfortunately, they can’t trade the position or use it as collateral for short-term credit because no counterparty will value the asset as highly as the model does. The other option is to sacrifice value by accepting a market price for the position: if the holder needs liquidity, they must mark the asset down to reflect what the market will pay for it.
Traditionally managed IT projects are not materially different. They are opaque investments that stifle organizational responsiveness.
Project plans consist of technical tasks (“create database tables” and “create QA plans”) collected into abstract phases of execution (“technical infrastructure” and “detailed design”). Because there is at least one degree of separation from task to business deliverable, traditionally managed IT projects are inherently opaque. They also assume that the business is taking a long position: the asset under construction isn’t designed to come together until “maturity” of the project.
Progress is measured as the percentage of abstract tasks that have been completed, and this is where the trouble begins. This is marking to model. Project plans are just models, and they typically don’t take meta-risks into account: e.g., the sudden exit of people, or a change in business priority. Worse, the work remaining isn’t necessarily a linear expenditure of effort because they’re things that have not yet been performed, and they assume a high degree of quality from previous deliverables. As a result, traditional IT tends to overstate the value of an investment. If we shut down a project that alleges to be 65% complete will not have 65% of its promised functionality; we will have far less. We may have performed a lot of technical work, but we can't run the business on technical tasks. This is, in effect, a market writedown on that project. By marking to model, we’re marking to myth.
There is a better approach.
Agile practices require that we continuously deliver small units of functionality. To do this, we must express requirements as short statements of business need, create and automate execution of unit tests with the code delivered, build the project binary and release it to an environment continuously. By doing these things, we are completing units of business functionality, not just completing an inventory of technical tasks. Progress is measured by functionality delivered. This means that Agile projects mark to market: if we shut down an Agile project, we face no write-down.
Many argue against marking to market. A thin market doesn’t mean investments are without value: provided the underlying assets don’t default, securities issued against them can provide significant return if held to maturity. So it goes with IT traditionalists: IT projects require a lot of purely technical work that make incremental deliveries difficult to make. They must be “held to maturity” to achieve their payoff.
Common sense tells us otherwise. The absence of a market for financial instruments tells us that there are tremendous risks and uncertainties in the assets themselves. This means there is little appetite for them outside of highly adventurous capital, and we expect low asset values with steep risk premiums. The problem with long IT investments lies in the faith placed in their deterministic valuation when so much is simply unknown. IT projects – particularly those capable of driving outsized returns – are not exercises that can be solved by elaborate planning. They can only be solved by incrementally coming to grips with change and uncertainty.
Long positions restrict financial agility if we have to mark down the value of a financial position to get capital out of it. So it is with IT: taking long positions in IT projects bind people to projects for long periods of time. This makes us capability illiquid across our IT portfolio. We face a writedown should we need to move people from one project to another to prop up performance.
“Models are by definition an abstraction of reality.”1 By marking to model, we may very well end up with a rapid deterioration of a long position. Catastrophic project failures are never at a loss for models: by repeatedly grafting models on top of highly dynamic situations, they’re wantonly marking to a meltdown. Confidence in assertions should never pass for facts of actual performance. By marking projects to market we know the value and understand the volatility of our IT investments.
1 Carr, Peter. "The Father of Financial Engineering." Bloomberg Markets Magazine. April 2008.
About Ross Pettit: Ross has over 15 years' experience as a developer, project manager, and program manager working on enterprise applications. A former COO, Managing Director, and CTO, he also brings extensive experience managing distributed development operations and global consulting companies. His industry background includes investment and retail banking, insurance, manufacturing, distribution, media, utilities, market research and government. He has most recently consulted to global financial services and media companies on transformation programs, with an emphasis on metrics and measurement. Ross is a frequent speaker and active blogger on topics of IT management, governance and innovation. He is also the editor of alphaITjournal.com.
No comments:
Post a Comment