Call it micro-outsourcing. Last August, an outfit called ITSquare.com set up a business-to-business exchange for software development.
They don’t use that term, but what else to call it? You have a software project; you spec it out and post it to the exchange; software development companies bid the job; you do the deal.
ITSquare vets the developers who are bidding, provides tools for managing the projects and figures to make its money by taking a small percentage of what developers get paid for projects. The company claims that it can make almost any software project, no matter how small, a candidate for outsourcing.
ITSquare isn’t alone. Since October, another company, Constructors Inc, has been running a similar exchange just for Web development proj ects at www.econstructors.com. And with B-to-B mania running hot, there could soon be a half-dozen other software-development exchanges out there.
Can micro-outsourcing work? So far, ITSquare and eConstructors can’t wave around long lists of happy corporate IT customers singing their praises. Maybe micro-outsourcing is a solution. Maybe not. Nobody knows.
But right now we need something. We’re telling users we can’t deliver projects because we’re understaffed. And we’re telling Finance we need more money for salaries because the market for key IT skills is so tight. We’re asking for more resources and we’re not delivering results. How long does anyone think we can get away with that?
(Actually, last year we did get away with that — but only because nobody wanted to touch the IT staff until Y2k fixes were done. Now Y2k is old news, and IT is starting to look very expensive again — and a likely candidate to be outsourced itself.)
So why aren’t we at least trying these newfangled B-to-B IT exchanges? Probably for all the wrong reasons.
Maybe we figure we can barely manage our own in-house projects, so micro-outsourcing will be impossible. If we’re lousy at defining the specs, estimating the time and costs and tracking the work, we’ve got a problem all right — but we should be learning to manage, not using that as an excuse.
Maybe we believe the micro-outsourcers will make us look bad because they’re so cheap, or because they can calculate what a project will cost before it starts. Hey, if we get a project on a more solid budgeting foundation, will that really tarnish our reputation?
Maybe we figure micro-outsourcing is a slippery slope, and we’ll end up gutting our in-house development capability. It won’t happen — or shouldn’t, anyhow. There’s no benefit in farming out the most interesting projects — the ones that keep our developers fired up — or the projects that depend on in-depth knowledge of our users and business processes, our company’s technology and internal politics.
The projects to micro-outsource are the plain-vanilla, heads-down, grind-’em-out jobs — or the ones too specialized for our people to handle anyway. The hard jobs we can’t do are the perfect candidates to farm out — and the dull ones we don’t really want to do, but users need, are the perfect jobs for testing the process.
Or maybe we’re really just afraid of change. In that case, we should at least be looking at micro-outsourcing. Change will come anyway — the only question is whether it blindsides us.
Besides, the last thing we need is for some user department to discover a B-to-B IT exchange and use it to bypass us for small projects — and then have the CEO ask us why we in IT aren’t using it too.
If we don’t have a good answer for that one, the outsourcing “opportunity” we face may not have anything micro about it at all.
Hayes, staff columnist for Computerworld US, has covered IT for more than 20 years. Send email to Frank Hayes.