Scott Withrow, in this week’s CNET App Dev Manager newsletter, talks about putting appropriate value on IT assets. He says that in addition to function,
Other factors to consider when determining an IT asset’s value include:
- Original development costs, licensing, infrastructure, and other standard tangible costs
- Costs to replace, acquire, or reengineer the asset
- Operational costs to support and execute the asset
- Business value retained by the successful operation of the asset
- Costs related to the operational impact when the asset is unavailable
- Value of the asset to the competition
- Value of the intellectual property associated with the asset
- Litigation costs associated with the unavailability of the asset
- Loss of competitive advantage, sales, goodwill, and market share due to asset unavailability
But do costs, even replacement costs, determine value? I think this is one of those nasty management issues that we have yet to properly resolve in IT. Just because you got me to spend $65M on a project doesn’t mean that its value isn’t a tenth of that. Costs do not determine value but can determine the value of replacement.
Citing any initial costs as determining value is the fallacy of sunk costs, where “I’ve spent too much to back out now.” Actually, whether or not you back out is determined by whether or not it makes sense to spend today’s money. If it doesn’t, you simply made an error. Often a million dollar error, but an error nonetheless.
It may just be how you determine value. Ideally, one would determine what you get vs what you have to spend and get some net return.
Interestingly, as I finally put this up after letting it “age” for about a year, McKinsey announced their new collection, Valuation: Measuring and Managing the Value of Companies, by Tim Koller, Marc Goedhart, and David Wessels. In several of the articles, the authors describe how share price may not reflect the actual value of the corporation, either short- or mid-term, forgetting long-term. “Developing a holistic picture of the health of a companyâ€â€its ability to generate and sustain valueâ€â€is difficult but doable.” Perhaps we need a similar holistic measure of IT health, an acknowledgement of the intangibles such as the mētis of the locals and the adaptability of the systems. Unfortunately, the value of any of these hinges upon other variables. For example, adaptability is good but at what point does it become pathological, always adapting and never “being”?
But let us start by admitting that cost does not determine value in any work.
Image Credit: George Stack. © 2007 BKMD at en.wikipedia (Bill Koslosky, MD) (CC BY 2.5). Via Wikimedia Commons.
Comments 4
Hi, thanks for the invitation to this most interesting weblog.
The phrase “replacement costs” reminds me of Joel Spolsky’s classic article about software rewrites. OK, I’m coming at this as a programmer. It just seems that the idea of “replacing” your current system is likely to grossly underestimate the pain and expense involved. Spolsky gives one of the key reasons for this, which is that there is a lot of hidden experience in existing code: bug fixes, ways of making it work with the hardware you actually have, etc. Some of these are not technical: eg. the work-around someone developed for allowing X to approve behaviour Y, they way you’ve always done it, even though whoever specified the software never thought of anyone with less than access Z needing to touch Y.
Software is self-evidently tied up with processes, and the more all-embracing or prescriptive the software is, the more rigid the process it implies.
A crude example: we have just been told to use a shiny new web-based HR system to book leave. This is great, except (a) only one’s line manager can approve leave, whereas with the matrixish system we have every project manager you might be working for at the time expects the right to approve or veto it; and (b) it does not seem to be possible for an employee to cancel an approved leave request, eg. to change the dates.
We’re back to getting bits of paper signed and putting the request through the web system as an afterthought. The point is that our particular unit doesn’t work the way the software thinks we work.
As a developer, I have seen more than enough examples of system specifications that just don’t understand the limitations of their own assumptions. To say “we won’t just Pave the Cowpaths, we’ll find a better route” too often fails to understand why the cows were there in the first place.
This knowledge (fitting of product to current processes) isn’t IP in any saleable way, but it is part of your investment in any existing system. Therefore, I’d argue that more of the costs of an existing system are relevant than one might initially think.
Author
I’ve posted something before about how the majority of coding is actually done in maintenance, even though almost no one likes admitting it. These “fixes” and kludges are the lifeblood of the development process, just like in any other process. It’s why you may want to wait a year to buy that new model of the Ford Mustang, so they can get all the kinks worked out.
Years ago at university, I studied a bit on urban studies. One of the interesting things is that most good highway developers in the States really did “pave the cowpath”. It normally ran Deer Path -> Native Path -> Settler Path -> Trading Path -> Mud Road -> Wooden Turnpike -> Paved Highway -> Interstate. Put “Canal” in there someplace in the middle and you account for a large majority of the major arteries in America.
There’s something about Development that brings out the revolutionary, overthrowing any existing order without reflecting that it may have been there for a reason. We seem to go through French revolutions” more often than the American kind, it seems, with the same messy shakeout. The American revolution shakeout was quite messy enough, thank you: let’s not invite our own beheading.
This is also the reason why SAP style systems so often fail: they do not take into account local practice and knowledge. There normally isn’t one best way but lots and lots of “it depends”, which is why you want people to stick around, even technical people.
Interesting. I work on transport planning in England these days, and there is a long history behind most roads. Here there is a sort of triple system.
Regular roads, which are the “old” cart roads, now upgraded into A- and B-roads. These are windy, narrow, dependent upon ancient land boundaries, and usually radial from the nearest market towns rather than efficient for long-distance efficient travel. The exception are the Roman roads, the only straight alignments in the system. (If you can lay a ruler along a road on the map, chances are there’s a little “Roman Road” annotation next to it).
The biggest problem is that such roads by nature pass through as many settlements as possible (or conversely, the road created settlements) so they are tedious to drive on. The density of villages is totally unlike most New World patterns.
The second class is the motorway and trunk dual carriageway network, including town bypasses and orbitals. These were built in the 20th century to get around the capacity problems of upgrading existing roads, and are arguably a “French Revolution” style of building. In the quest for efficiency, they have produced an effective and rather soulless network that people find depressing to use but unavoidable. There is still resentment at the destruction of countryside that is perceived to have come out of the motorways program. (Implementation issues!)
The third system is the extensive network of public footpaths, bridleways, and rights-of-way, which impose cowpath efficiency over private land where the road is irrational or non-existent. Since A-roads are often lethal for walkers, cyclists or horses, these have become even more important.
The railways were and are a fourth largely separate system that once connected virtually everything here.
The whole effect is one of careful growth in existing systems culminating in an explosion of new technology and another entirely separate parallel system. One could argue that budget airlines are adding a fifth system in Europe at the moment.
If there were a software analogy, I suppose it would be the kind of shop that has 4 different platforms and operating systems related to historic periods of growth, where it is too expensive to try and replace any of them with the others.
I’m just thinking about your list of criteria above in relation to, say, public sector railway investment. There are some interesting parallels.
You mention that development brings out the revolutionary impulse. That makes me think of Larry Wall’s three chief virtues of the programmer: laziness, impatience and hubris. These are all good things in technical situations, but perhaps they are our undoing in designing software within a social context, that is, within an organisation of real people. (As opposed to, say, a computer science department 😉
Author
For everyone who does not remember Larry Wall (I didn’t) he wrote the amazingly widely read Programming Perl. Read more on “We will encourage you to develop the three great virtues of a programmer: laziness, impatience, and hubris.”
I need to tie up some loose ends about IT and how it shares a hyper-modernist tendency for “the big solution” which most developers don’t buy into.