BBC programming for failure?

The splintered wreckage of huge IT projects seems to break on our shores with tragic regularity, the NPfIT debacle being the most notable recent example. Such tragedy tends to be the result of the long lead times of some of these massive waterfall-managed projects.

Now there is one more shipwreck to add to our register. The BBC’s Digital Media Initiative (DMI) was axed by new director general Tony Hall in May, five years after it was launched with the aim of modernising the Corporation’s production and archiving methods using connected digital production and media asset management systems.

The financial impact is well-documented: the BBC’s losses in the first two years amounted to £10.7 million, with another £98 million wasted since the project was taken away from Siemens and brought in-house in late 2009. Now we have almost nothing to show for the equivalent of an entire Radio 4 annual budget.

Who is responsible for this sorry state of affairs has yet to be determined, but a review already ordered by the BBC Trust, and a probable probe by the Parliamentary Public Spending Committee will no doubt point some fingers.

BBCCTO John Linwood has already been suspended pending review, but BBC senior executives past and present must take some part of the responsibility.

What can CIOs learn from this sorry mess? It seems improbable that the only big projects in train over the last five to seven years are public sector ones, so how come we aren’t hearing about similar foul-ups in the private sector? It can’t just be because the public sector is more accountable – shareholders can also be very demanding. No, through five years of sustained recession, the private sector has had no choice but to look at every project, re-assess their viability and value and then re-engineer them where necessary.

Breaking big projects down into large assemblies of small projects, each capable of delivering their own demonstrable value, has become the norm in a lot of development projects – it’s the agile approach and it really works. With 100 small projects on your to-do list rather than one huge one, you are in a better position to prioritise your work on the things that will yield immediate results. You may well elect not to do some of the projects further down the list, but you’ll still have extracted the real value from work already done, and your overall project can still be deemed a success.

The DMI’s demise looks very much like a development issue, in that iterative development did not happen in this case. It’s impossible to avoid the conclusion that, had the BBC’s DMI project been so disassembled, the BBC would at least be deriving benefit from every bit of work already done. As it is they have virtually nothing to show for it.

Of course it’s too easy to comment without the awkward reality of actually having to implement, and the BBC’s decision to move a lot of its production to Salford was, we suspect, a major factor here. A big logistical move is one thing that cannot be done iteratively, and it would seem that the DMI initiative was hung on the back of this huge move.

The other factor at play here is that of the technology itself. This particular area of technical development has maintained a fast pace throughout the five years of this project, meaning that what looked cutting edge at the start looks commonplace now. Another argument for having done this, and all similar, projects iteratively, since you can then simply change direction as and when the technology requires it.

“Ambitious technology projects like this always carry a risk of failure,” said Hall when he announced the axing of the project. That’s as maybe, but the biggest shock here is not that the project failed, but that BBC management allowed such a large amount of taxpayers’ money to be spent over five years in pursuit of no demonstrable benefit.