Double standards, triple costs

According to a recent white paper produced by Oracle’s BI Consulting Group (“The Great Debate: buy versus build”) it costs between two-and-a-half and three-and-a-half times as much to build your own business intelligence and analytics system than buy and adapt an off-the-shelf solution. It must be admitted, the white paper concerned is a marketing piece to support this firm’s services in – you guessed it – adapting standard Oracle systems to provide BI solutions. But their figures are based on experiences with some 250 large-scale implementations, which is a decent number to conjure with.

They also found that such projects when built from scratch by system developers averaged 34 weeks from start to finish and consumed 925 person days, whereas implementing then adapting a generic platform took half the time – 17 weeks – and less than a third of the effort, with an average of 290 days required. When you consider the amount of effort involved in managing a project twice as long, and the drain that this has internally on the stakeholders involved with prototyping and early adoption, there are also likely to be sizable hidden internal costs that can be avoided. MR applications may differ in some respects, and the development projects around them may be smaller in scale, but the experience is unlikely to be radically different from this scenario.

There is a surprisingly large amount of custom-built MR software around, developed in-house from scratch. It’s not all legacy stuff either. I continue to hear of firms developing their own tools across the range of research applications, from panel management through to dashboards and portals. As the article from Oracle points out, their experience is that the out-of-the-box solution tends to meet between 70% and 80% of needs, so development effort is concentrated instead on the 20% to 30% that needs to be accommodated.

Of course, it is always possible that, lurking in that 20-30% are some very nasty problems that require almost infinite resource to resolve, but that remains true whatever route you take. Perhaps decision-makers are not comparing like-with-like when opting for own-grown. An off-the-shelf solution has known limitations – these limits are usually cited as reason for rejection. Despite this, they are limitations that may often be overcome through customisation. Open systems now make it readily feasible to customise rather than bribe your software vendor into changing their core software product or live with the limitations. Yet it is a choice that is often neglected.

The build-your-own route is seductive – theoretically, it appears to have no limits in what is achievable. The danger lurks in those obscure user requirements where effort starts to spiral towards infinity in achieving them, and where hard decisions are needed – always assuming you’ve noticed in time.

If you can find something where 70% of the work was already done without having to think about it, surely that’s a good thing? Yet, “it only met 70% of our requirements” is often the siren call that lures project teams into the unfathomed depths of what astute system developers call “the vanity project”. It’s flattering to be told your requirements are so special that a system must be built from scratch to meet them. It’s also very very unlikely. But to counter vanity with vanity, who likes finding out they paid more than three times over the odds?