December 31, 2012 | John Rusk | 1 Comment I spent over 16 years working for IT consultancies. Organisations who needed software would come to us, generally negotiate an up-front price, and we’d write the software for them. This kind of work, outsourced software development, was the focus of my working life… until 9 months ago. That was when I moved to an internal role at the Animal Health Board. The Board is not an IT organisation, but rather a registered charity tasked with the single job of eradicating bovine tuberculosis from New Zealand. It turns out that, to eradicate a microscopic bacterium from an entire country(!), you need a lot of software to keep track of everything. We’re re-developing one of our core applications, and we’re doing it in-house. After 9 months in this very different world of in-house software development, I can share several observations: I like it. In outsourced development, there was always an invisible “wall” between the developers and the customer – caused by contract and price negotiations, sensitivity over whether acting on user feedback was chargeable or implicit in the original price, and a tendency for both organisations to think in terms of “us versus them”. With in-house development, the wall is gone. Gone also are the considerable costs and frustrations the “wall” used to create. Making sure the “wall” stays gone requires conscious effort from managers and staff at all levels. In some organisations it would be easy to slip back into “us and them”, between the “business” and “IT” functions of the single organisation. At the Animal Health Board, we’ve been blessed with management who started the project off on the right foot, and with users and team members who kept it heading in the right direction. No matter how you run your project, you need good people. I feel very lucky that good people were brought into key roles before I joined, and that we’ve been able to continue attracting good people as the project has continued. My advice, to any organisation starting in-house development for the first time, would be to be very careful with your initial hiring choices, since so much will depend on them. As for continuing to attract good people, I think it helps that we are a unique, focussed organisation, which does good both for the New Zealand economy and for wildlife conservation and biodiversity. So my suggestion would be that, if your organisation has tangible benefits in the real world, promote that fact to attract staff. I believe the team, which is a mix of contract and permanent staff, is at least as good as what we would have got through any outsourcing vendor – and quite possibly better. Plus, we have the bonus of better contact between team and business, and lower costs per developer-hour. A challenging project is still a challenging project, no matter how you do it. Bringing this major project in house hasn’t guaranteed we’ll get an effective system at an affordable cost, but it has improved the odds. Conclusions In-house development has been effective and enjoyable. It would now be my preference for projects that meet the following criteria: The project is big enough to justify the costs of recruiting and building a team. (E.g. there’s at least 12 months’ worth of work for the team) But it’s not too big. (E.g. building a team of between 10 and 20 people, as we have done, is OK, but if you think you need 100 people, and your organisation has never built an IT project team before, maybe it’s safer to find a large vendor who already has the 100 people! Having said that, a 100-person project is risky no matter how you do it, so maybe it’s worth looking for ways to cut scope, extend timeframes, and do it with a smaller team.) There’s a workable resourcing plan for after the project goes live. For instance, if you expect maintenance to require no more than one full-time person, after go-live, how will you keep someone on to do that work? If they are your only programmer, won’t they get lonely and leave? What if you need them less that full time? In such cases, outsourced maintenance may be a better option – although bear in mind that your vendor will also struggle to maintain expertise in your system if your needs are low or intermittent. (Since they, like you, can’t devote a full-time person to the system if there’s not enough work.) In our case, at the Animal Health Board, we know we have significant IT work beyond this project, so running an on-going internal IT team was always part of the plan. (And in fact, we’ve already had such a team for several years.) Throwing Down the Gauntlet For many years, my career goal was to make outsourced development work better. I wanted to solve the problems of the “wall” that gets between customer and supplier. But now I see many of those problems can often be sidestepped, by moving the development in-house. So I’d like to propose two challenges to IT consultancies: What value do you add, over and above what your customer could do in-house? Years ago, it used to be easy for IT consultancies to possess rare knowledge. For instance, before the internet there were only two ways to learn how to develop with complex product like Oracle: read the manuals, which took up about 1 metre of shelf space, or sit next to an experienced user. I found both at an IT consultancy. But today, I’d use the internet instead. In the internet age, an IT consultancy must do more than simply possess people and documentation. How much of your day-to-day activity, and your fee structure, is devoted to simply ensuring the survival of your organisation? There may be a significant cost to ensuring your organisation survives – in sales, marketing and management. Ultimately, your customers pay that cost though the fees you charge them. Is the survival of your organisation worth that much, to your customers? I’m not saying that outsourcing is always a bad choice, just that the inherent advantages of in-house development raise the bar for those who wish to sell outsourcing. For customers, investing in IT might make sense even when its not your core business.