Hang on a minute. Is it only me or are the conclusions a little disingenuous?<p>a) Is it fairly normal for projects of this size to be over-budget? If so is their overrun more or less than the norm of projects of equivalent size?<p>b) Is it fairly normal for large projects, spanning multiple years, to enjoy some feature creep and specification changes? If so did this project exceed that norm?<p>c) Is there any correlation, with projects in this sort of price bracket, between "in house" and "outsourcing" when it comes to budget or time overruns?<p>In short - it seems to me the conclusions are easier said than done;<p><pre><code> * A senior leader who has a track record of successful delivery of large, complex software development projects
</code></pre>
No doubt there are lots of folk with this on their resume. And I'm guessing they're really cheap. Or perhaps they're really, really scarce and probably don't want to work on a BBC salary. And if they _do_ hire such a person, next there'll be headlines about how he makes more than the Prime Minister.<p><pre><code> * Clear roles and responsibilities
</code></pre>
I'm not even gonna comment on this one...<p><pre><code> * Cooperation between, and integration of, the various functions on a project, including development, deployment and support
</code></pre>
yeah - exactly - and where do you think most of the overruns came from in the first place. This sort of endless "integration" is code-speak for a shifting specification, not exactly the best way to get on budget.<p><pre><code> * Clear and effective project governance with the appropriate representation on each group or board from across the project, business and suppliers.
</code></pre>
yay. Or in other words. More Managers. Yeah. That's the solution - throw more people at it.<p>Now I know nothing about the project, but something tells me that the fact they have a system at all is because all these things were done to some degree, and the fact that it ran over was because, well, big projects have shifting goals, with plenty of people contributing anything they feel like, while some engineers write a program to keep all of them happy.<p>And I bet they don't take this team, and give them another large govt. project to work on. Rather than accept that they've learned a lot, and will do better next time, they'll get an all new group in to do the next one.<p>Of course I, and any other developer reading this, will have huge opinions about how they messed up, and how could _any_ system cost that much in the first place. It's dead easy to design a system when you don't know the specification, or ultimately have to deliver it to the end users.