One for the CEO

An XP project is completely controlled by the customer. At the end of each iteration the customer gets to decide whether they wish to invest in another iteration's work. Each iteration is at most three weeks long. This means that the exposure to risk is the cost of three weeks' work.

If I’m a shareholder in an organisation, I expect the staff of that organisation to take all reasonable steps to maximise the value of my shares. Usually that means maximising profits. I also expect them to minimise the risk on any investment they make, and to minimise the amount of money exposed to any risk.

Does that sound reasonable?

It’s the chief executive’s job to fulfill my requirements as a shareholder – to boost profits without unnecessary risk. That isn’t to say that risks shouldn’t be taken, just that they should be carefully analysed and the return should be commensurate with the level of exposure to the risk.

If the chief executive chooses to invest $1000 on a project with a one-in-a-million chance of returning $1 million, then that’s okay, because the exposure to the risk is relatively tiny and the potential payback is huge. As long as the CEO doesn’t take this sort of risk very often everything’s okay.

If the CEO chooses to invest $1 million on a project with a 75% chance of success and a potential return that is only vaguely understood, that’s different, isn’t it? Any boss who took this kind of cavalier risk with company funds would deserve to be fired – perhaps worse.

Industry analysis suggests that about 50% of biggish software projects – those taking 12 months or more – are cancelled, and that a total of more than 75% fail to meet their planned objectives, either in cost, time or scope.

Given this fact it would appear foolish for any chief executive to invest money in software development. Moreover, as an investor I would have to be insane trusting my money with an organisation that participated in this activity. The only reason most investors continue to invest is because they don’t know the risks, or because they assume that they’re a necessary part of doing business.

It’s always better to buy than build – mostly we accept that. You shouldn’t consider outsourcing development as buying though, because the risks are even higher if someone else is developing your software.

But developing software is a necessity. It has to be, otherwise we wouldn’t do so much of it. But do the risks have to be so high? The answer is yes – ish. Software development is hard; nothing makes it easy. These problems are here to stay for the foreseeable future. However, we have developed techniques that allow us to reduce the capital exposure. For those of you not familiar with the concept of “exposed capital”, it is the sum of money that is exposed to risk at any point in an investment.

On a classical project the investment in the project is agreed up front – the money is effectively spent – and the project team will burn through that money twice as quickly as anyone thought possible, and then request more. The company then has to decide whether it’s going to invest further and finish the project, or whether it’s going to cancel the project and write off the sum invested to date. Usually, not wishing to waste the money already spent, an organisation will invest further. So we can say that 100% of the budget is initially exposed to risk, with a further 100% coming online sometime during the project, and that typical cost is 200% of the budget (figures based upon solid industry analysis by Capers Jones).

An XP project is completely controlled by the customer. At the end of each iteration the customer gets to decide whether they wish to invest in another iteration’s work. Each iteration is at most three weeks long. This means that the exposure to risk is the cost of three weeks’ work. On a one-year project the exposure equals about one-fifteenth of the budget.

XP advocates leaving the system in working order at the end of each iteration. This means that if you do choose to cancel an XP project at any time you’ll get a return on your investment equal to the value of your investment to date. Actually, with XP the project evolves based on diminishing returns per iteration, so cancelling early is a good idea.

Compare this with a classical project which, if cancelled, you’ll get no return from.

This has to be more desirable than classical methods. As a side issue our other practices will allow us to deliver software of higher internal and external quality, faster than any other process. This has the effect of significantly lowering the total cost of owning the software.

We actively address maintenance issues during development so our systems are considerably less expensive to maintain than those produced using classical methods.

This too has to be of interest to organisations that are developing software.

So, lower risk and reduced TCO. That should sell XP to most CEOs immediately. If you are a CEO you should find out why your people aren’t doing this already. If they answer anything other than “we are” then you need to make some changes – before your shareholders do.

Dollery is a Wellington IT consultant. Send letters for publication in Computerworld to Computerworld Letters.

Join the newsletter!


Sign up to gain exclusive access to email subscriptions, event invitations, competitions, giveaways, and much more.

Membership is free, and your security and privacy remain protected. View our privacy policy before signing up.

Error: Please check your email address.

Tags extreme programming

More about TCO

Show Comments