The BBC’s Digital Media Initiative; how could they spend +100 Million on a CMS and get nothing?

In the wake of British Broadcasting Corporations decision to scrap their Digital Media Initiative and take a write-down of around $100 Million dollars (US) the British government is beginning a major investigation into what went wrong. Begun in 2008, the DMI project was supposed to produce a global content management system that would unify BBC’s vast content assets worldwide. The first phase of the program ended in July 2009 when the initial contract was terminated. Subsequently BBC made the decision to bring the project in-house. It is difficult to pin down exactly how much had been spent up until that time because of the complexities of the no-fault contract termination, but I think it is safe to say that the BBC proceeded to spent a great deal more on the program before closing it down.

Content Management Systems (CMS) have become almost ubiquitous in online systems, to the point where most websites are delivered with some easy method for making updates.  The highly popular WordPress has evolved from simple blog software to a highly effective CMS for example.  Other open source systems such as Drupal and Concrete 5 are also available, as are frameworks for supporting large corporate sites, and many developers offer proprietary highly customizable solutions.  So what happened to the BBC?  And could it happen to you?

It will be many months before an official determination of cause is made. However, we can learn a lot from the initial project launch in 2008. Much of my information comes from a report on the BBC’s website:

This was a response from the BBC trust to an audit from the British National Audit Office, published 13 January 2011. Reading the report, we can see that the project was doomed right from the beginning due to poor planning and communications. Here are the high points of the mistakes made:

  •  Here is a quote from the report’s cover letter:  “By its nature, this was always a high risk project as there was no ‘off the shelf’ technology available”.  I’m sure many major CMS vendors would be shocked to learn this fact, in view of their considerable offerings and the number of large corporations worldwide using them, even in 2008. There was no indication how this determination was made, and I submit that it was very likely untrue.
  • The cover letter also included this jewel: “it was right that we developed the DMI rather than install soon-to-be-obsolete technology”  BBC really had no business demanding cutting edge technology, especially on firm-fixed price, nor could they predict obsolence.
  • No competitive bid process was involved in the selection of the vendor. Instead the job went to Seimens, who had a blanket technology contract with BBC. Seimens is a great company, but has anyone heard of them ever developing a content management system? Part of the justification was that Seimens had delivered a similar system into a single BBC building. Apparently no one involved had ever heard of scale issues. Doing a competitive bid probably would have forced the BBC to author a comprehensive Performance Specification, the basis for any development RFP.  There is no evidence that one existed.
  • The project allowed only 30 days to gather User Requirements. BBC has over 23,000 employees. Anyone care to take that job on?
  • There was no test plan for delivery, and no mention at all of Quality Assurance, which is consistent with there being no Performance Specification. There is a lesson here; written requirements are the basis for everything that follows.
  • According to the NAO, there was no independent technical review of the design.  Apparently that’s because BBC believed a firm-fixed -price contract passed all of the risks to the vendor. The risk of not actually getting the product did not appear to have occurred to anyone. So it seems from March 2008 they let the soup cook until they found out that it was burnt.

The contract with Seimens terminated in July 2009, and in that same month the BBC decided to take the project in-house.  From the timeframe, this decision had to have been made in a few weeks, despite the fact that they had no real visibility into the project (prior to taking it over), lacked the technical expertise to evaluate what had been done, and most certainly did not have the manpower just laying around waiting to take on the management of that massive endeavor. How could they not know which way this was going to go?

The consistent thread in all of this is that there “wasn’t time” to do all of those things (Specifications, reviews, QA, test plans, etc.) if they were to deliver on time. Sadly, we see these same mistakes made all the time, perhaps not on such a grand scale, but just as devastating to a smaller company left poorer and hopefully wiser. So I’m asking you all to keep your ears open for these tell-tale signs when you are part of a technology development project:

  • “There is no off-the -shelf technology that will do what we want, we’ll have to start from scratch”
  • “We need the absolute bleeding edge”
  • “Let’s just give it to those guys that did that other thing for us (what was that?)”
  • “We don’t have time to ask our Users what they want”
  • “We don’t have time to write all this down”
  • “The Vendor knows what we need, and besides, we’re safe because we’ve got an Firm Fixed Price Contract”
  • “We’ll figure out how to test it as soon as we figure out what they gave us”

Maybe they will let you keep some of that $100 Million dollars you saved.