How much does an offshore developer cost?

Computing Magazine 25th September issue has some interesting costings in an article about Egg Bank setting up an IT academy to recruit and train students: Egg keeps costs down by poaching students (ho ho).

Robin Young, CIO of Citi UK Consumer (owner of Egg) is quoted:

“The motivation for setting up this academy is purely financial … Banks are quickly disappearing from the market and the consequences of the recession are reaching a larger scale, so I think the best way to develop IT is locally, with global architecture principles.

“But to do that, I need to keep staff affordable. It is a simple calculation ­- we found a way to reduce our overall cost base and still have the same output, as we will work on developing workers’ skillsets and get more for our money.”

The hard copy article goes into some more details on the numbers

Citi’s sceme cost about $50,000 (£27,765) to set up and the bank said the daily cost per graduate is significantly lower than the rate it pays contractors, which is about $300 (£167), while offshore costs are eight to 10 percent higher.

I presume of course that the $300 is the daily rate paid to graduates. If so then here are some maths:

Graduate costs $300 a day. Offshore developer is 8-10% higher, say $325 a day. Assuming the offshoring is in Eastern Europe the rate this converts to about €228 or about €28 an hour. Which sounds fairly competitive, if a bit at the top end of rates I’ve seen there.

How you can be on time, on budget and on scope but still FAIL

OTOBOS – On time, on budget, on scope – is the mantra of software project managers everywhere. So many IT projects fail on one or more of these three factors that project management 101 takes  great pains to ensure that aspiring project managers learn how to stick to all three (or at least two).

But being OTOBOS is only the first hurdle to cross. Fail at OTOBOS and you fail, for sure. But there is a much, much bigger picture than simply being on time, on budget and on scope. You can be OTOBOS and still, from a business perspective deliver a big FAIL.

There are a host reasons why this can happen. Here’s one fairly common one, in enterprise software at least.

The project team has forgotten the real objective behind the IT system

There is a subtle, but important, difference between a requirement and an objective.

Here’s how the scenario plays out: A senior individual makes a proposal for an IT system to be built/implemented in order to achieve a particular business objective. Once the proposal is approved a project team is convened to implement the IT system. The team assiduously collects requirements from stakeholders and carefully manages any changes to those requirements. Eventually a shiny new system is unveiled that meets all the requirements … but which fails to deliver the business objective.

What happened?

It could just be a simple breakdown of communication somewhere along the line from the business objective to the requirements to the developed code. Usually any project objective is hidden in a project initiation document or a project charter never to be seen again by anyone until after the project has finished.

Or it could just be that business objectives have shifted since the project was initiated and no-one remembered to tell the project team. As projects get longer this risk becomes more real.

Here’s a story I heard a while ago – and I’m sure those of you in enterprise IT land won’t find it surprising. A software product was supposed to streamline a procurement process by empowering end users to place purchase requests themselves, thereby avoiding paper trails and manual approvals. The system was duly delivered, on time, on budget, on scope. It met all requirements. But it turned out that the system was too cumbersome for end users to use. They continued to place their orders on paper and have them approved on paper, and then it was someone else’s job to input the approved orders onto the new system. Far from streamlining the process you could argue that the system had ended up adding a new step and more time to the process.

How to avoid this issue?

Have a clear, simple business objective for your project that everyone, from the sponsor to the intern knows and uses every opportunity to repeat. This helps people remember what they are really trying to achieve. Team members can identify early any threats that might prevent delivery of the objective. And when business priorities change (as they surely will) these can be filtered to the project team early enough that you stand a chance of doing something sensible.

On the Paulson US Treasury Reverse Auction Process

Assuming the mooted auction does go ahead here are some thoughts as to possible designs.

The US Govt has a lot of experience in forward auctions selling treasury bonds as described here: http://www.newyorkfed.org/aboutthefed/fedpoint/fed41.html. If you have the time, Kenneth Garbade’s history of the treasury auctions is well worth a read – he emphasises the responses to failure as well as the successes in building a solid programme of auctions: http://papers.ssrn.com/sol3/papers.cfm?abstract_id=596966.

For readers who are used to reverse English auctions the US Treasury format is very different from what you might expect. It is a single-round auction. As a bidder you put in one bid up until the deadline. This bid can state a price you wish to pay and how much you will buy at that price, or it can state a quantity you wish to buy at whatever the average price is. The Treasury then allocates the available bonds across the bidders based on who is offering the highest prices.

I expect that the US Treasury would want to use something similar in the proposed reverse auction. But things are not going to be as simple as that. There is some good debate amongst people who know auctions:

• Jason Busch and Sam Kinney discuss the level of optimisation functionality that could be used http://www.spendmatters.com/index.cfm/2008/9/29/Treasurys-700-Billion-Sourcing-Challenge–Is-it-Reverse-Auction-Time.
• NERA have produced a paper contrasting the existing Treasury Bill forward auction process with a potential reverse auction process here: http://www.nera.com/image/Buying_the_Bad_Stuff_Paulson_0908.pdf.
• Sam Kinney – co-founder of FreeMarkets (who pioneered the whole reverse auction space that TradingPartners is now a dominant player in) has some good thoughts here: http://www.uptheeconomy.com/?p=28

On one level the actual design of the auction is of secondary importance. Simple agreement on a bailout plan will be sufficient to soothe many nerves.

But once they start the reverse auctions will be the subjects of intense media and market scrutiny, at least in the early stages. So reverse auctions at the outset will need to be kept very simple. For this reason any real-time complex optimisation will need to be ruled out. At least to start with.

NERA point out in their paper (link above) a good issue: In a procurement reverse auction the buyer would likely only buy from one (or perhaps two or three, but certainly not all) of the bidders in the auction. So the bidders have to compete against each other to push the price down. Under the Paulson plan, if the government is committing to buying all the securities from all the banks (until the money runs out) then what is the incentive for any bidder to place a low bid? They know that the government will bail them out. To avoid this the auction process could include a number of bidders but commit the Treasury to buying securities from a small number of the bidders, or to buy a fraction of the auctioned value, such that all bidders have an incentive to bid.

There is also the question of one-round or multiple-round bidding. The US Govt currently sells Treasury bonds with one round of bidding so I’m sure they will be tempted to use a similar design for the bailout. But given the uncertainty around the value of the assets in question now I would expect the transparency of multiple-round bidding will be better. Paul Klemperer has some great horror stories of single-round bidding events. Search for “Banespa” and “New Zealand” in the document. The Banespa case was a first-price sealed bid auction, the New Zealand case was a second-price sealed bid auction (Vickrey auction). Both led to great embarrassment.

So could an auction work in this US bailout? It’s certainly well known across government and private sectors that auctions are the best way to ascertain a market price when the true market price is not known. I have seen some very successful reverse auctions for pension funds, for example. So perhaps using reverse auctions for mortgage-backed assets is not such a crazy idea after all.

On balance I think a long, regular series of auctions based on a multiple-round descending clock auction design with the government only buying a fraction of the securities on offer in each auction would be a good way to start the process. Then as the purchases become more commonplace, the desperate sellers offload their assets and prices creep up the government could look to add in optimisation technology.